Journal InTime

_ FMトランスミッターBSFM18BK

バッファローコクヨサプライ iBUFFALO 【iPhone,iPod,Walkman,スマートフォン,携帯】対応FMトランスミッターステレオミニプラグ接続ホルダー付ブラックBSFM18BK

レビューで雑音がひどくて使えないとあったのでちょっと気になったが、ホルダーと充電だけでも 使えればいいか、ということで、東京出張のついでにヨトバシで購入。

エクシーガ/xperia arcで使ってみたけど、FMトスンスミッタとしては問題ないレベルの音質だと思う。 ステレオミニプラグで接続するタイプなので、携帯側のボリュームが大きすぎると音が割れたりするので、レビューした人はそのあたりの調整がうまく行ってなかったのかもしれない。

_ 100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊

100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊

前に書いた記事が載っている本がAmazonで予約できるようになったみたい。

「来年度からプログラムを書く仕事をすることになってしまった不幸なおまえらの道標となるべき書籍十冊」みたいなエントリは読むな。という人もいるけど、まだ読んでないのでこの本にもあてはまるのかどうかよくわからない。

実は、紹介する本として最初に思い付いたのはThe Craft of Text Editing―手作りのテキストエディタだったんだけど、やはり絶版だったので、さすがに紹介するのはどうかなと思ってやめておいたのであった。 The Craft of Text Editingはエディタの本なのだが、多くの本と異なり、エディタを使う人のためではなく、作る人のために書かれている。 これを読んで、いつかRubyでエディタを作ってみたいと思いつつ、早十数年…ほら、やっぱり年寄の昔話になってしまった。

以下のサイトで英語版のPDFやEPUBを入手できるので、「NHK出版 ラジオ基礎英語1」の後で読んでみたら面白いかもしれない。

• The Craft of Text Editing

_ Rubyのfor式の失敗

前に書こうと思って忘れてたのだけど、shiroさんの記事を読んで思い出した。

Rubyにはfor式というものがあって、最近だとあまり好まれていないようだが、それはたぶん主に見た目の問題で、eachに対するたんなる構文糖だと思われている（ので直接eachを使った方がシンプルだと思われている）せいではないかと思われる。 しかし実は、Rubyのfor式はたんなる構文糖よりも少し罪が重い。それは、for式は変数のスコープを導入しない、つまり、ループ変数の破壊的な変更を前提にしている構文だということだ。

shiroさんの昔の記事の例でいうと、

irb(main):001:0> a = []
=> []
irb(main):002:0> for i in 0..4 do a.push(lambda { i }) end
=> 0..4
irb(main):003:0> a
=> [#<Proc:0x2265df20@(irb):2 (lambda)>, #<Proc:0x2265ded0@(irb):2 (lambda)>, #<Proc:0x2265dea8@(irb):2 (lambda)>, #<Proc:0x2265de80@(irb):2 (lambda)>, #<Proc:0x2265de58@(irb):2 (lambda)>]
irb(main):004:0> a.map {|i| i.call}
=> [4, 4, 4, 4, 4]

のようにlambdaでクローズしたつもりの変数の値がすべて最後の値に変更されてしまう。 eachを直接使うと、ブロックパラメータは毎回の呼び出し毎に別の変数になるので、こういう心配はない。

irb(main):005:0> a = []
=> []
irb(main):006:0> (0..4).each do |i| a.push(lambda { i }) end
=> 0..4
irb(main):007:0> a
=> [#<Proc:0x2270c124@(irb):6 (lambda)>, #<Proc:0x2270c0fc@(irb):6 (lambda)>, #<Proc:0x2270c0d4@(irb):6 (lambda)>, #<Proc:0x2270c0ac@(irb):6 (lambda)>, #<Proc:0x2270be18@(irb):6 (lambda)>]
irb(main):008:0> a.map {|i| i.call}
=> [0, 1, 2, 3, 4]

C#でも今から直すそうなので、（もっとユーザが少ないと思われる）Rubyでもたんなるeachの構文糖にしてしまうとか、Scala風のfor式にしてしまったらどうだろうか。

_ ZENBOOK UX31E-RY256S

ASUSU U31シリーズ ウルトラブック 13.3型 HD液晶 U31E-RY256S シルバー

かれこれ4〜5年くらい使っているType TZのディスクが怪しくなってきたので、買い替えた。

色々迷ったけど、MS Office Home and Businessが付いて9万6千円くらいという価格に惹かれてASUSのUltrabookを購入。 11.6インチと13.3インチのモデルがあったが、解像度とバッテリ駆動時間を考えて13.3インチの方にした。

以下簡単なインプレ。

いいところ

• 薄い
• 解像度が高い（1600x900）
• SSDの容量がそこそこ（256GB）
• SATA3.0でSSDの性能がまあまあ（シーケンシャルリードは速いけど、ランダムアクセスはちょっと遅い）
• 見た目がよい（個人的には、MacBook Airの丸みを帯びたデザインよりZENBOOKみたいに直線的な方が好き。天板も意外と悪くない。）
• 付属品が充実している（VGAアダプタ・LAN→USBアダプタや本体ケースが付属）

悪いところ

• ロゴがSONYじゃなくてASUS
• メモリが4GBで増設不可
• CPUが超低電圧版Core i5
• キーボードがいまいち
• 幅がかなり広い（今使ってる一番小さい鞄にぎりぎり入ったのでセーフ）
• 付属ソフトが不安定（ETDCtrl.exeのCPU使用率が25%をキープしたりする）
• 液晶のドット抜けが1コあった（ZENBOOKはZBD保証というのがあって、輝点については30日以内なら無償で液晶交換してくれるらしい。赤い点に見えるけど送料かかるしどうしようかなあ…）

何か悪いところの方が多くなってしまったけど、実際はわりと気に入っている。

_ ETDCtrlKiller

ZENBOOKにはETDCtrl.exeというタッチパッドの制御ソフトウェアが付属していて、タスクトレイに常駐しているのだが、VirtualBoxを使っているとCPU使用率がずっと25%くらいになる。 msconfigのスタートアップタブで起動しないようにすればCPU消費の問題はなくなるが、ETDCtrl.exeが起動していない状態だと、起動時やスリープからの復帰時にタッチパッドの設定がデフォルトに戻ってしまうので、タップが有効になってしまったり、マルチタッチが効かなくなって、使いにくいことこの上ない。

一度ETDCtrl.exeを起動すると、ETDCtrl.exe終了後もスリープするまではタッチパッドの設定は反映されたままのようなので、スリープから復帰する度にETDCtrl.exeを起動したり終了したりしていたのだが、面倒なので自動化するソフトウェアを書いた。

• ETDCtrlKiller.exe
• ソース

インストールは、msconfigでETDCtrl.exeを無効にした上で、ETDCtrlKiller.exeをスタートアップにコピーしておけばよい。 ETDCtrlKillerの起動時に、ETDCtrl.exeが起動され、一分後に終了される。スリープからの復帰時にも同様にETDCtrl.exeが起動され、一分後に終了される。 ETDCtrlKillerもタスクトレイに常駐するので、ETDCtrlKillerを終了する時はアイコンをクリックしてメニューから終了を選べばよい。

今のところ上手く動いているようだけど、かなり乱暴な対策なので、試す人はat your own riskでお願いします。

_ ドット欠け

ASUSのZBD保証は輝点だけが対象で黒点は対象外のようなので、ドット欠けチェッカーというツールで確認してみた。

その結果、背景色を黒・白・緑にすると点が確認でき、赤・青にした場合は点が確認できなかった（正確には斜め上からはうっすら点が見えた）のだが、これは輝点（赤・青の画素が常時点灯している）と考えてよいのだろうか（2/20追記: いや、違うな、緑の画素が点灯しないのかも）。 仮に液晶を交換してもらったとしても、輝点がなくなる代りに黒点が増えたりしたら嫌だなあ…とか考えて結局交換しない人が多いのかもしれない。

_ Unity 2Dの設定

Ubuntu 11.10ではUnityがデフォルトになっているが、なかなか上手く動かないのでUnity 2Dを使っている（別にGNOMEでもよかったんだけど何となく）。

デフォルトではランチャーが常に表示されるが、VirtualBoxをシームレスモードで使うとうっとうしい。 UnityではCompizConfig設定マネージャで設定できるが、Unity 2Dだとdconfで設定しないといけないようだ。

$ sudo apt-get install dconf-tools
$ dconf write /com/canonical/unity-2d/launcher/use-strut false
$ dconf write /com/canonical/unity-2d/launcher/hide-mode 1

hide-modeは0だとランチャーが常に表示され（use-strutはtrueにする）、2だとランチャーにウィンドウがかかった時だけ隠れるようになる。

参考: <URL:http://askubuntu.com/questions/32667/how-do-i-configure-unity-2d>

_ returnすべきか、せざるべきか

Rubyについてよくある議論で、returnを書くべきか、省略すべき(途中でreturnするケースは除く)か、というのがある。 いつだったかのRubyConfでコードの書き方についてのパネルみたいなのがあって、会場からTwitterで質問できたので聞いてみたら、会場のほとんどの人がreturnを書かない派で、returnを書く派のパネリストがJava guy!と罵られていた。もっと英語ができたら援護してあげられたのだけど。

僕がreturnを書くのは、

def foo
  bar
  baz
end

みたいなコードがあった時に、bazが値を返すことを期待しているのか、たんに副作用のために呼んでいるのかを区別しにくいからだ。 単純なgetterなんかではreturnを省略しても問題ないと思うけど。

return書かない派の話を聞くと、例えば関数型言語ではreturnがない(Haskellにはreturnがあるけど全然別物)じゃないか、といった意見が出ることがあるが、関数は値を返すに決まっているからそもそも上記のような問題はない。でもRubyは命令型言語なのだ。

Rubyでも関数型っぽいコードでreturnを省略するのは違和感がない。例えばこんなコード。

def sum_of_squares(ary)
  ary.map { |i| i ** 2 }.inject(&:+)
end

でも次のコードはちょっと不恰好に見える。

def sum_of_squares(ary)
  result = 0
  for i in ary
    result += i ** 2
  end
  result
end

injectを使う時も似たようなことがあって、上のsum_of_squaresのinjectはすっきりしているけど、

def to_hash(ary)
  ary.inject({}) do |h, (k, v)|
    h[k] = v
    h
  end
end

みたいなコードはむしろ格好わるい。

副作用を使うなら割り切って

def to_hash(ary)
  ary.each_with_object({}) do |(k, v), h|
    h[k] = v
  end
end

とした方が潔い。

結局、結論としては「読みやすければいいんじゃないの?」というところで、何か面白くなくなってしまったな。