気づいたらあっというまに8月も終わりそうだ。ありがたいことにまだ仕事が忙しい。

そんな中、aoyue 852A+ Hot Air Stationを買った。要はノズルの先から数百度の熱風を出す装置だ。

これで何が出来るかというと、足の多いICを外したり付けたり、熱収縮チューブを縮ませるのにライターを使わなくて良くなったりする。うちでも早速可哀想な古いマザーボードから何枚かICを剥いでみた。

普通にやったらかなり手こずりそうなこのサイズのICがものの１分もかからないくらいで外せてしまう。ちょっと探したらaoyueのデモ映像もあった。こんな感じ。

購入元はownta.comというところ(商品ページはここ)。香港なので送料が言うほど高くない(はず)なのと、支払いが訳のわからないサイトではなくpaypal経由で行えるということでここにした。価格は本体が120.95USD(110V電源対応のカスタマイズ費用10.20USD含む)に送料が45.87USDで合計166.82USDだった。日本円で決済された金額を見ると14,605円。

ちなみに、Payment Confirmされてから24hで発送と書いてあったのに全然発送の連絡が来ないので問い合わせたところ、問い合わせから１時間足らずで返事が来た。曰く、110Vカスタムには3営業日追加でかかりますよ、とのこと。
そんなこともあって、発注してpaypalで支払い完了したのが8/17 21:50、Payment Confirmedされたのが22:50、New shipment was createdされたのが8/21 11:16、物が到着したのが8/23 10:16(JST)と、およそ一週間での到着となった。

まだ買ってちょこっとしかいじっていないのだが、自分で割とこまかい面実装作業をするような人なら、是非持っておくべき道具だと思う。

symfony1.4.6、doctrineで、migrateしつつ開発、のテスト中。思いの外はまりどころが多いので個人的メモ。誤解している、使い方がオカシイなどありましたらご指摘ください。ちなみに、正しい使い始めのための手順はこちらが詳しい。

型にtextだとかdatetimeだとか書いておくとはまる
型にtype: textだとか書いておいても、普通に使う分には使えてしまう。ただ、doctrine:migrateすると、syntax errorが出てしまう。どうも、textとだけ書いておくと、hoge: { type: text } をSQLにするとき、hoge text()と構築してしまってエラーになる模様。string(長さ)と指定しておけばOK。
同様に、datetimeもmigrateを使わないかぎり通るのだけど、migrate使うとエラー。timestampとしておく必要がある。

トランザクション使ってないのでエラー出たら面倒
migrateタスクの中でトランザクション処理を行っていない模様(嘘。ちゃんと書いてあった)。そのせいで、上記のようなエラーがでると中途半端にクエリが通った状態になってしまう。運用データがなければ(開発サーバであれば)、doctrine:drop-dbしてdoctrine:create-dbして、doctrine:migrateすればいいが、そうでない場合は結構注意が必要。つうかトランザクションくらい走らせてください＞中の人

お気軽に使えそうで思ったよりはまる。ただ、継続的に開発し続ける手合いにはこれがないと困るので、はまらないように使ってみようと思う。

追記：
sfDoctrineMigrateTaskとMigrateを読んでみると、beginTransactionがちゃんと書いてあった。クエリログを見てみると確かにトランザクションは掛けている。なんでdry-runするだけで問題が起こったのかちょっとわからず。

100716 20:30:38     2 Connect   shell@localhost on shell
                    2 Query     SET NAMES utf8
                    2 Query     SET NAMES 'UTF8'
                    2 Query     CREATE TABLE migration_version (version INT) ENGINE = INNODB
                    2 Query     SELECT version FROM migration_version
                    2 Query     START TRANSACTION
                    2 Query     SELECT version FROM migration_version
                    2 Query     CREATE TABLE (略
                    2 Query     ALTER TABLE (略
                    2 Query     CREATE INDEX (略
                    2 Query     commit
                    2 Query     SELECT version FROM migration_version
                    2 Query     UPDATE migration_version SET version = 12
                    2 Quit

追記：

おそらく、MySQLのautocommitを殺していないからだと推測していて、接続時にまずautocommitをオフにするクエリを投げる方法を調査中。symfonyそのもののソース書き換えちゃうのが早いのだけどそれはちょっとねぇ。

追記：

もっと根本的な話だった。MySQLはCREATE TABLE的なDDLをrollbackできない。なんだそれ。あほかい。テンポラリテーブルこさえるような実装だったりするとｇｄｇｄになるってわけで。

メモリ買ってうわーい、と喜んだのも束の間。不安定さにずーっと悩まされていた。

結論から言うと、ThinkPad W500(4058-CTO)にメモリを8GB載せた状態でWindows7 64bitを突っ込むと、何が悪いのか不明だが、不安定になって使い物にならなくなる。
確かにスペック的には4GB上限ということになっているのだが、チップセットも8GBまで対応しているし、動いているという報告も見る。それでもメモリの問題かと思ってMEMTEST86+ Ver4.10を延々回したのだが全くエラーは発生しないので、おそらくどれかのドライバが腐っているか、IO空間的に引っかかっているのかもしれない。ひとまず、現状ではオススメする、とは言い難い。

同じ轍を踏む人を減らすために詳細メモ。

うちのThinkPadはThinkPad W500(4058-CTO)。メモリはTranscendのTS512MSK64V1Nを２枚。このメモリは256MB*8構成、7-7-7-20動作。同シリーズの2GB品であるTS256MSK64V1Uは128M*8構成で他のパラメータは同じ、ThinkPadには問題なく入るとのこと。

不具合はどこで発生するか予知できないが、ビデオカードドライバ、USBドライバあたりで頻発しやすい傾向があった(そのせいで余計原因がわからなかったというのもある)。さんざんドライバを入れ替えてみたりしたのだが、そこには原因が一切ない模様。とにかく、BSOD(Blue Screen of Death /ブルースクリーン)になったり、一切入力を受け付けない状態にフリーズしたり、時には画面がぐっちゃぐちゃに崩れたりとおもしろい現象が多発する。

対応はとりあえずメモリ減らす。これだけ。

いらっとしてついうっかりほぼ同型機(4061-xxx)を発注してしまったので、そちらでも同一現象が起こるかは追って検証してみる予定。この本体だけに起こる問題であるかどうかはそこで判断できるはず。

いくら対応してないメモリ量だからってテスト省くのはよくないと思います。><

2010/7/15追記：

ThinkPad W500(4061-xxx)でテストしたが、こちらもアウトだった。半日ほどきちんと動いていたのだが、やはり落ちる。先ほどWindows7 SP1 Betaが公開されたので、そちらも試してみようとは思うがオススメはできない。

若松でやっているThinkPad T61にメモリ8GB載せよう、というのはそういう観点での安定性はあるのだろうか？

2010/7/19追記：

チップセット内蔵のディスプレイを使ってるとかなり安定する感じがする。あまり長時間試していないが、やはりATIのドライバがくさいなぁ、と。まだ断定するには早いが。