SafariのLabelエレメント.

　ちょっと仕事中だけど忘れない様にメモ.
　さっさと書きなぐります.

　Macの標準ブラウザであるSafari.
　会社には古いPowerPC系のMacしかないんだけど、そいつに入っているSafari（1.3.x系）ではLabelエレメントに対するJavascriptの取扱がちょっと変（もしかすると、この挙動が正規の動きなのかもしれないけど）.

<form name="test_post" method="post">
<label onclick="javascript: alert(this.form.name)">テスト</label>
</form>

　こんな感じで書くと、Formの名前は拾ってくれません（Labelエレメントの「this」そのものが無効. IEやFirefoxは拾います）.
　私の中ではこの状態を「Safariの挙動」として把握していたのですが、ふとWindows版のSafariで同じ様なJavaScriptを動かしてみると、正常（？）に動作しやがります.

　…で、結局どの挙動が正常なんだ？ orz

　今回はWindows版しか試してませんが、もしかしてIntel Mac用（MacOS X 10.4.x）のSafari（2.0.x）でも普通に動くのか？？
　むしろ1.3.x系Safariには、こんな下らないバグがずーっと残ってたとでも言うのか？？

　うーん…今現状Intel Macが手元に無いから試しようが無いしなぁ～
　ちらっと検索しても、なかなか該当する記事を見つける事が出来ませんでしたし.
　これを口実に会社でIntel Mac買ってもらうかなｗ

PDF出力が一対一の直つなぎ環境で出力されなかった問題.

　先日書いた一対一の直つなぎ環境だとPDFが出力されない、と言う問題.
　なんの事は無い、単にサーバー側のDNS設定がおかしかっただけでした orz

　誤設定　→　ルータ環境下でのDNS設定のまま
　正設定　→　直つなぎ相手または自分

　…って…んが？
　何でだ？
　そう言うもんなのか？
　DNS設定がおかしいと、HTML/PHPは正常に表示されるが、PDF出力（PHPから生成）の場合は表示されないって？
　そんなバカな話あるのか？

　うーん…と言う事で、やっぱりコードが悪いのかもｗ

　これは後日要確認！（と書いて調べてない事が山ほどある事は忘却の彼方へ…時間見て遣り残してる確認事項終わらせないとなぁ）.

今宵は愚痴を.

　18日22時現在…36時間起きっぱなし、ついさっきまで仕事しっぱなしの状態 orz
　昨日は祝日なのに現時点で36時間…そう、休日仕事からのブチ抜きと言う最悪状態ですｗ

　いや、自分が悪い部分もあるからある程度仕方ないと思うけど、流石に36時間頭フル回転の状態を続けると心身ともにぐったりです.
　ただ、不思議な事に眠気はさほどありません.
　朝が眠気のピークで、後はダルイだけです.
　しかも余り普段と変わらないダルさ.
　それどころか、さっきシャワーを浴びながら「このまま今日も徹夜で行けるんじゃ？」と思ったから自分が怖い.

　因みに、仕事の山場を過ぎて終焉を迎えようかと言う時に「PDFがインターネットに繋がっている環境だと出力されるが、一対一の直つなぎ等のクローズドなネットワーク環境だと出力されない」と言う意味不明な現象に出くわしましたが、思考回路が焼き付きそうだったので放棄してきました orz
　他のマシンだと問題無いので、たぶんコードじゃなくてネットワークの設定だとは思うんですけど、PDFが出力されないクローズドなネットワークでも普通にページ（スクリプト）の表示は出来るんだよなぁ…何だろ？？
　正に意味不明.
　寝てすっきりすれば直ぐ解決と言う楽な話に…はならないか orz

　さ、悩みは明日に回してさっさと寝よ.

PHPの配列によるメモリ消費.

　久々更新.

　前から思っていましたが、何故PHPの配列はあんなにメモリを消費するんだろ.
　大きいデータの場合、文字列→配列へexplodeなりすると、メモリ消費量が一気に10倍程度まで跳ね上がります orz
　この傾向は当然ながらデータサイズが小さい物より大きいものの方がより顕著です.
　迂闊に大きいデータを配列化しようものなら、貴重なメモリ資源が喰い散らかされてしまいます（終了時には解放されますが、Linuxのメモリ最適化処理なんかの環境下だと、終了後も一見掴みっぱなしに見えるから気持ち悪い…）.
　例えばデータベース.
　データベース回りの機能をクラス化すると、大抵SELECTクエリの結果データを配列へ格納する様に作ると思いますが、この時も直接mysql_fetch_xxxxで処理を回すより結構なメモリ消費量となってしまいます.
　更に、データベースから取得した配列データのエンコードを変換して出力したいとした時、利便性から「mb_convert_variables」（配列データ中のエンコードを指定のエンコードに一括変換する関数）を使うケースが多いと思いますが、この「mb_convert_variables」も曲者で、処理後のメモリ消費が処理前の倍近くになってしまいます.
　分かり易く書くと↓こんな感じ.

echo "MEMORY0 : " . number_format(memory_get_usage()) . " byte（初期値）<br>";

$strBuffer = str_repeat("ABCDEFG,", 10000);
echo "MEMORY1 : " . number_format(memory_get_usage()) . " byte（文字列生成）<br>";

$aryBuffer = explode(",", $strBuffer);
echo "MEMORY2 : " . number_format(memory_get_usage()) . " byte（配列生成）<br>";

unset($strBuffer);
echo "MEMORY3 : " . number_format(memory_get_usage()) . " byte（文字列解放）<br>";

mb_convert_variables("SJIS-win", "UTF-8", $aryBuffer);
echo "MEMORY4 : " . number_format(memory_get_usage()) . " byte（mb_convert_variables実行）<br>";

unset($aryBuffer);
echo "MEMORY5 : " . number_format(memory_get_usage()) . " byte（配列解放）<br>";

　※PHP5.2.1以前の場合、「memory_get_usage」は「--enable-memory-limit」付きでメイクする必要があります.

　結果↓

MEMORY0 : 59,160 byte（初期値）
MEMORY1 : 139,568 byte（文字列生成）
MEMORY2 : 1,045,532 byte（配列生成）
MEMORY3 : 965,600 byte（文字列解放）
MEMORY4 : 1,637,344 byte（mb_convert_variables実行）
MEMORY5 : 91,424 byte（配列解放）

　内部で単純に複製して変換しているからなのかもしれませんが、メモリ消費が変換対象の配列変数を解放するまで掴みっぱなしになるのは如何なものかと…

　まぁそんな事言い出すと、全部変数解放した後の消費量も気になるじゃねーか！って話になりますけどw

　こうして考えると、世にあるPHP用Frameworkがそれぞれどの程度のメモリ消費なのか、見比べてみるのも面白いかもしれません.
　同等の機能を実現出来るFrameworkなら、エコなコードの方がいいに決まってますから.

Windows Live Writerで試し書き.

　と言う事で、タイトル通りWindows Live Writerで試しに投稿しようとしてます.

　実際に上手く行くかは分かりませんがｗ

　と言うか、共通APIを使っているからなのか、カテゴリまでインポートしてくれるんですねぇ.

　…私が時代遅れなだけか orz

　所々動きがおかしいですが（まだBeta版だから仕方ないけど）、Windowsで書くならいいかも（他のblogエディタ使用経験なしｗ）.

　何よりbloggerでも自動認識したのが好印象.

　MSにしてはやりますな.

　さて、投稿実行実行っと.

/**
 * 2007-08-23 23:33追記.
 */

　…改行するのに、Shift+EnterじゃないとPタグで改行されるんだ orz
　この辺は使い難いです.
　まぁ、よくよく考えたら、普段Linuxで投稿してるから関係ないっちゃー関係ないですねｗ
　と、微妙に追記動作テスト.

MySQLで数値データを桁区切り（3桁区切り）.

　to_charが無いMySQL.

　◆ FORMAT(X[データ],D[小数点以下桁数])
　　Select FORMAT(suchi, 0) as suchi From TestTable;

　100%何を今更って話ですがｗ

　今までデータの成型はコード側で行う事が多かったんですが、諸事情でSQL文で成型する事に.
　「SQL上で成型する場合はto_charを…ってMySQLには無いんだった orz」と言う、常人にしてみれば馬鹿馬鹿しくて俄かには信じられない状況に.
　まぁ、私の脳みそレベルが垣間見れる訳です.

　そして何を血迷ったのか「さっさと調べよう」と検索エンジンへ.
　…んが、まったく出てきやしません orz
　検索の仕方がまずかったのか、30分ほどネットを彷徨うlightmaterial.
　しかも、最終的にドキュメント読んだらすぐに見つかると言う駄目っぷり orz

　あ～アホらしい.
　体調悪いしさっさと帰ろう.

　なんちゃってデータベース使い（要するに素人）から、本当のデータベース使い（MS SQLでもOracleでもPgSQLでもMySQLでも何でも来いや！な玄人）に成りたいと心底思った今日この頃.

Eclipse3.3.

　…久しぶりの更新だ orz
　まぁ、もう一個のblogは半年ほど放置状態なので、まだましと言う事にしておきます.


　更新をサボっている間にEclipse3.3が正式リリースされました.
　今日から微妙にずれた夏期休暇が取れたので（取れたのでと言うか、取るために仕事三昧の日々を送って「取った」んですが）、今日は朝からEclipse3.3をインストールして自宅で仕事の続きをやってました♪
　… orz

　いや、そんな話は置いておき.
　Eclipse3.3ですが、自宅のPen4 1.5GHzと言う廃棄一歩手前でも現役で頑張っているWindowsマシンでは、少々もたつきが発生しました.
　今の所、これまた普通だと廃棄候補にあがる2GHzのFedora Core6マシンだと普通に使えるので、自宅で仕事するには問題なさそうです…悲しい話ですが orz

　lightmaterialにとって一番実用的なのが、各コードタブをダブルクリックした際の挙動.
　今までもダブルクリックでコードエディタ部分がウィンドウいっぱいに広がりましたが、今回からOutlineなどのサブペインが完全に隠れず、クイックアクセスアイコンとして表示されるようになり、すばやくサブペインを復元できます（下画像の赤囲み部分）.

　未だにワイドなディスプレイを持っていないlightmaterialには必須機能ですw
　逆にワイドディスプレイ使っている人には、そんなに恩恵が無いかもしれませんが.

　あと、VisualStudio（.Net）の様に、コードの選択範囲をD&D移動出来るとかって言う記事をどこかで見かけましたが、何が悪いのか上手く動いてくれません orz
　Professionalな方はキーボードだけで殆んどの操作を行うんでしょうが、lightmaterialの様な低レベル人間には結構役に立つんですけどね.
　どっか設定の変更が必要なんだろうか？
　後で設定項目を見直してみる必要があるかもしれません.

　その他、細かいけどかなり良くなったのがタブ.
　非アクティブなタブもアイコンとタイトル両方が描画されるようになって、非常に便利になりました.
　便利になりましたと言いますか、今までが不便でした orz

　と、まだ全然触れてませんが、3.2系よりも「使っていて心地よい」改善が気に入りましたので、休み明けには会社の環境も3.3系へ乗り換えようかと計画中.


　所でまったく関係ありませんが、某会社が販売している.Net系コンポーネントを見つけたんですが、Firefox（Firebug付き）でサンプルを試すとすごい状態になります.

　これは何もしていない状態のJavaScriptエラー数です.
　ただ…ただページを表示しただけです orz
　まぁ、確かに対応ブラウザはIE限定となってはいるんですが……ここまで特化したコードも珍しかったので一応メモ.

　上記コンポーネント自体は業務系で使用されるケースが多いような分類なので、今のところIE限定でも問題無いんですが、この先いつまでIE限定のWebアプリケーションが受け入れられるのか…
　仕事で足突っ込んでますが、正直この辺の切り分けってまだまだ不確定要素が多いです.

　来年の今頃もまだIE限定で行けるのか？
　未だに「対応ブラウザはIEとNetscapeで」とか言う状況で行けるのか？（lightmaterialの会社は違いますけど）
　FirefoxやらSafari対応にまで踏み込まないと淘汰されて行くのか？
　と、不安が募るばかり.

　まぁ、そうは言いつつ日本ではまだまだIEオンリーで大丈夫なんでしょうけどねw
　IE天国日本ですから.

　嗚呼恐ろしや恐ろしや…