イー・モバイルが認識しない
実家に帰る前にと思って、今日7.2MBのイーモバイルを契約した。プランは「いちねん」の「データプラン」で、契約時に9,980円と月々5,980円の支払いになる。
さっそくノートPC（Vista / Thinkpad X61）に繋いでみると、どうもうまく認識しない。ユーティリティソフトは自動で入らないのでCD経由で入れることができたのだけれども、USBの認識具合が良くない様子。
結局、どのUSBの口に差してもだめだったので、オンライン経由でデバイスの更新をすると、あっけなくうまくいった。
ということで難はあったものの、かなり快適。家にADSLを繋ぐくらいなら、イー・モバイルだけでも良いかもと思うくらい。
MySQLがどのくらい長いSQL文を許容するのか
max_allowed_packetの設定値に依る、というのが答えっぽい。実際に大きなSQL文を実行すると
ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes
というエラーになる。
はてなダイアリーブック欲しい！
はてなダイアリーブック欲しい！
今年の自分の日記でいちばんおすすめのエントリーはこれ。
http://blog.cloned.jp/20070905
理由は書くのに一番時間がかかったから。
LTemplateをバージョンアップ
http://clonedoppelganger.net/javascript/LTemplate.html
テンプレートを評価するときに毎回パースを行っていたのを、オーバーヘッドを少なくするためにコンストラクタでパースだけはやってしまうように修正。
LTemplateは郵便番号検索でもGuitar Scalerでも利用していて、自作自演ながら結構良い感じに動いている。
燻製罪
煙草のこと。自分は煙草は吸わないとはいえお酒が大好きなので、愛煙家が生き残れる方向で極力は考えたいのだけれども、副流煙だけは解決した方が良いと思う。
解決しない理由が煙が煙であるためだと思う。酔っ払いの嘔吐なら皆の共通認識が得られそうなものなのに。
煙は空気に混ざって判らなくなる。いや、視覚的にも嗅覚的にも判るのだけれども、形に残らない（このヤニがとかを言えないというレベルで）。それが良くないと思う。
人が吸ったときに片方からしか煙の出ない煙草の開発も一つの手段だなと思うけれども、吸った後に人が吐く煙はやはり副流煙となってしまう。
なら判るようにしてしまえばどうだろうかと思う。方法としては煙に着色するのが手っ取り早い。そうしたら、コートにこんな色付けやがってという乱闘はさておき、煙の影響が判り易い。過失燻製罪という訳だ。
まぁ半分以上は冗談。会社の同僚とかで煙草吸う人は多いけれど、気になったことはほとんどないかな。恐らく一部の人なんだろうと思う。飲み屋とかで他の客のテーブルに向けて煙を排出みたいな（ちなみに今日の夜のお話）。銭形のとっつあんの声で「逮捕する」って言いそうになったよ。
もうちょっと工夫して欲しいなと思う。
自作楽器製作勉強会に参加してきました
くじらはんどぶろぐ : 自作楽器製作勉強会のお知らせ
とてもレベルの濃い高い内容でした。自分もGuitar Scalerについて簡単に発表させて頂いたのですが、もっと濃い話題に言及できるように精進します。発表資料はこちら。せっかくなので、感想などを簡単に。
- 「自作MIDI楽器ウダーの製作」
独創的な新楽器であるウダーについて宇田さんが直接解説。主にMIDIと絡めて、単純なMIDI楽器の作り方などを回路図付きで説明。とても興味深い内容でした。ウダーの動画は見たことがあったのですが（見たことのない方はウダーのページにあるので是非）、実際に本物を触らせて頂いて感激。見た感じよりも手頃な重さで持ち易かった。ウダーのパーツ作成もご自身でやっているとのことで、本物手作り楽器で素晴らしかった。
くじらさんによる今までの歴代自作楽器たちの紹介。特にテキスト音楽「サクラ」は有名だと思うけれども、ランダム音階作成等の作曲支援ツールも独特。最近はMMLが熱いということでサクラのウェブ化やその他、色々取組中とのこと。
adasさんによるVSTの作り方チュートリアル。プレゼン資料がかなり詳しいし、量が素晴らしい。VSTのプラグインをCで書いてみましょうという趣旨でその場で空のVSTプラグイン用のCファイルを頂いて、みんなでワイワイ。かなりハマリそうな内容もきっちりまとめて下さっているので非常に貴重な資料。
- その他
naoya_tさんの占星術と音楽理論の関連性は素晴らしい。その発想はなかった。デスクトップでトランペットも見た目が素敵。adasさんのFlexの音再生はCPUパワーの問題こそあれど可能性がある感じ。MIDIの新規格は普及するかどうかがちょっと疑問だけど、現行のMIDIは転送速度がかなりネックになっているのはその通りなので何とかなって欲しい。
ということで、かなり有意義なイベントでした。会場を貸出頂いた八角研究所をはじめ、皆様お疲れ様でした。
headタグベンチ
「あなたのページを最速にする14の掟」と「High Performance Web Sites」のこと || パフォーマンス・チューニングBlog: インターオフィス
これ（もしくは原文）を読んだことのある人は多いと思うけれども、どうも「Move JS to the bottom」がまだまだ普及していないように思う。
何を速くするべきかを考えるならばscriptタグを下に持ってゆくことこそまずやるべきだと思う。
ユーザーが体感する速度で重要視されるのは何だろうか。自分としてはまず描画することが何よりも重要だと思う。特に検索エンジン等から初めて訪れた人は、どんな色でどんなロゴで何ができるサイトなのか、というようなことを無意識に心待ちにしていることだろう。そんな中でheadタグ内でscriptの読み込みをしている時間というのはとんでもないロスではないだろうか。描画しないと何も判断できないのだから。
ヘビーユーザーにはキャッシュ見せれば良いのだから、少なくともgzip圧縮するよりも先にscriptのロード自体をコンテンツ描画の後にするために、scriptタグを下にもってゆくべきだろう。
と、言っても説得力がないらしいので、たった数行のheadタグのためにどれだけ時間がかかっているのかを調べるBookmarkletを書いた。
ページにアクセスしてキャッシュを消してこれを実行すると、検索エンジンなどから来たときに如何に重いのかがわかるのではないかと思う。
普通はheadタグを読み込みしている間にはコンテンツの描画は一切されない。もしそんなheadタグの読み込みに1秒以上かけていたらパフォーマンスの悪いサイトに感じられても仕方がないと思う。
otsuneさんの日記も合わせて読むとより良いと思う。とにかく別段の問題がなければscriptタグをコンテンツよりも下に配置することを主張したい。
PHP懇親会に参加してきた
http://events.php.gr.jp/event.php/event_show/29
発表資料はこちら
プレゼン資料の操作は、jとかenterとかspaceとかで進む、kとかbackspaceとかで戻る、右でページ進む、左でページ戻るな感じです。プレゼン資料自体を自作していますが、賢明なあなたはS6とかを使った方が良いでしょう。
さて、風邪がひどかったので、終了後は名刺交換もろくにせずに退散しましたが、とても楽しかったです。みなさんの発表もコンパクトながら味があって面白かったです。また、時間が合えば是非参加したいと思います。
LINDさんをはじめ、運営やってくださった方は本当にお疲れ様でした。