ひげろぐ

仮想化というとKVMとかの方が盛り上がって来てるような気がする昨今に今更なんだけれども。

CentOS 5.3ではXENがとても簡単に導入できる。
OSインストール時に仮想化にチェックを入れたらそれだけで入るし、後からでも

$ sudo yum install xen

これで依存するパッケージなど必要なものも全部入る。
後から入れた場合はxen用のカーネルで立ち上がるようにgrub.confの修正とかは必要だけど。

まあここらへんはぐぐればいくらでも出てくるので詳細は割愛。
なおパッケージのXENのバージョンは3.0.3になる。

仮想マシンの構築は最初はCUIでがんばろうとしたけれども、イメージ作る途中でインストーラのカーソルが明後日の方向行ったりしてワケがわからなくなったので、あきらめておとなしくGUIで。
GUIのUIはよく出来ていて、簡単に仮想マシンのイメージファイルが作れてOSもインストールすることが出来た。

イメージをひとつ作ったらsudoの設定とかどのサーバにも必ず入れるパッケージを入れたりとか基本的な部分をある程度セットアップ。
そしたらあとはそのイメージファイルコピーして/etc/xen以下に設定ファイルを仮想マシンの台数分作って6台くらい作ってみた。

同じ構成の仮想マシンをコピーでさくっと作れるし、実マシンへの束縛がなくなったので身軽になった気がしていい気分。
ディスク以外はリソース割り当ても柔軟にできていいかんじ。

ただひとつだけ気になることとして、仮想マシンの一台がディスクI/Oを大量に発生させると他のマシンも巻き込んで遅くなる、ということがあった。
例えば一台が割り当てのメモリを使い切ってスワップをガリガリ発生させようものなら、他のマシンでもスワップが発生したかのように遅くなる。

これは最近某VPSを使っていて経験したことと同じだ。
そこでは深夜にバッチが動く時間帯になるとひどくパフォーマンスが落ちる。
こういうことがあるのでVPSも自由度は高いけど所詮共有サーバーだよなって思う。

ここらへんの問題って何か回避するノウハウとかあるんだろうか。

最近思うところあって自宅のインフラを整備中。

その一環として安売りで1年前くらいに買った110GeのCPUをもともとついていたCeleronからCore2Quad 9400に上げることに。
このときBIOSのバージョンをアップする必要があった。
そのためにはFDドライブが必要になる。
しかし今時フツーはFDドライブとかついてない。

• NEC Express5800／110Ge – wiki@nothing

上記のサイト（多謝！）で調べてみるにUSBのFDドライブが使えるらしいが、使えないモデルもあるらしい。
で、更にぐーぐる先生に聞いてみると最近売ってるものは、どのメーカーから出てても、ほとんどその使えないモデルのOEMっぽい。
要するに今から新品のものを買ってきても高確率で使えないようだ。

ここで押し入れにしまってあるおたから箱から内蔵のFDドライブを発掘するという手もあったが、最近はパーツ類と格闘するのがちょっと億劫になっているので最後の手段と言うことでひとまずパス。
よく見てみるとアップデートツールにWindows版があるのでそれを使ってみることにした。

このツールはWindows 2003と2008に対応しているとのこと。
それぞれ評価版がダウンロードできるのでそれを使ってみることにした。
Windows 2003はインストール途中にHDDが認識されなかったので終了。こっちはドライバを別途準備する根性も必要だった。
根性はとりあえず出し惜しみしてWindows 2008を入れてみたらちゃんとすんなり入った。

BIOSのアップデートもツールを起動しただけでさくっと終了。
善哉。

せっかく入れたんで2008をちょっとだけ触ってみたけれど、なんか小ぎれいになってますな。
Windows Serverなんて2000以来久しぶりに触りました。
ということなので大した評価はできませんでした。小ぎれいになってる。以上。

しかしそうだひとつだけ。
シャットダウン時にその理由を聞いてくるとか大きなお世話って気がするんですけど。
こういう挙動が固いところで使うにはいいのかな。

さて今回はOS再インストール予定だったのでこういう手段も使えたが、絶賛運用中のもののBIOSを上げることになったらいちいち2008入れるのもめんどくさいですな。
それにこんな使い方してるとMSから怒られそうだ。

個人的に大好きな『Joel on Software』の続編。

More Joel on Software

posted with amazlet at 09.05.24

Joel Spolsky
翔泳社
売り上げランキング: 4363

Amazon.co.jp で詳細を見る

特にこの本から何かを得ようとしなくても語り口自体が軽妙なので単純に読み物として面白い。
開発者としてだけでなくソフトウェア会社の経営者としての視点からの記事もあるので、いろんな人にオススメできる本。

エビデンスベースのスケジューリング

今回の『More Joel on Software』ではエビデンスベーススケジューリングという考え方が興味深かった。

これは開発者の見積もりに対して過去の時間記録から求めた補正を加えてより正確なスケジュールを見積もる仕組み。
エビデンスは辞書によると形跡とか物証とかそう言う意味だそうだ。

簡単に言うといつも見積もりよりも二倍の時間がかかる開発者がいれば、その開発者の見積もりを二倍にすれば正しいスケジュールが求められるという考え方だ。

ソフトウェア開発の見積もりを正確に行うのは難しい。
同じ内容のタスクをこなすのでも開発者の技量によってかかる時間は違うし、各々の開発者が開発以外に取られる時間の考慮も必要になる。
性格的な差もあり、楽観的な開発者は実際よりも少ない時間に見積もるし、慎重な開発者は多く見積もる傾向がある。

ただこうした傾向はあっても多くの開発者は相対的には正しい見積もりをする。
多くの開発者の見積もりと実際にかかる時間が異なるのは見積もり能力が欠如しているからというわけではないのだ。（ただし中には本当にまったく参考にならないまずい見積もりをする開発者もいる）

エビデンスベースのスケジューリングはそういった「開発者は相対的には正しい見積もりをする」という考え方に基づいている。

最初に開発者が立てた見積もりに対して、あとは坦々と実際かかった時間を記録していく。
この時開発のために使った時間だけではなく、開発以外に取られた時間も込みで記録する。

例えば突発的な打ち合わせとか不意のサーバダウンによる復旧作業に取られた時間も込みで。
そうすることで作業開始から完了までの全て込みの正確な時間が得られるというわけだ。

それで得られた見積もりと実際かかった時間の差から、次回の見積もりに加える補正が求められ、見積もりからより実際に近いスケジュールが得られる。
そしてこの精度は記録を蓄積するに従って高まっていき、スケジューリングのための強力なツールになる。

自分も勘で似たようなことをしているし（直感的な見積もりを2倍か3倍したらだいたい正しい見積もり）、経験的に同じことをやっている開発者はけっこういると思うけど、このようにきちんと計測してやる考え方は初めて知った。
第20章にもっと詳しくわかりやすく書いてあるので興味を持った人は是非どうぞ。

ジョエルさんの会社（Fog Creek社）が出してるFog Bugzにはこのエビデンスベースのスケジューリングの機能があるそうだ。
Redmineでもこういうプラグインとかないのかな。

ほかにも面白いと思った話がたくさん

盛りだくさんだった。

第1章 はじめてのBillGレビューのこと

なんか笑えるｗ

第15章 ユーザビリティがすべてではない

確かにひどいUIでも多くの人に使われてるソフトウェアとかサイトとかあるよね。

第23章 間違ったコードは間違ってみるようにする

良いハンガリアン記法と悪いハンガリアン記法の話とか。

第26章 ソフトウェアにおける高音域

凡庸な歌手は最高の歌手がいつでも出している高音域を決して出すことができない。100人集まっても。

第29章 シンプルさ

シンプルさへの的外れな信仰について。

第32章 心に残るカスタマサービスへの7ステップ

ホコリを払うように勧める。責めを負う。強欲ではどこにもたどり着けない。とかとか。

というわけで2GBから4GBになりました。ワーイ。

昨年10月の購入当初から2GBでがんばってきたけれど、開発のメインマシンに定着してサーバーなども込みでいろんなソフトを立ち上げっぱなしにしてると、たまにスワップが発生するようになってきた。
そこでメモリも昨今安いので増設を決意。

MacBook Proのメモリスロットが2つで1GBのメモリが2枚収まっている。
なので4GBにするには2GBのメモリを2枚用意して2枚とも交換する必要がある。

買ったのは以下のメモリ。

• 価格.com – サムスン SODIMM DDR3 PC3-8500 2GB (サムスン) 価格比較

純正と同じモジュールらしい？
MacBook Proでの動作報告が多いのがいいかんじ。

最安のショップの評価がアレだったので二番目に安かったグッドメディアで購入。
注文した次の日には発送でその次の日には到着。速やかな対応でよかった。
クレジットカードが使えなかったので代引きにして送料手数料込みで総額¥7,809也

メモリ交換作業の参考にしたのは以下のページ。

• ASCII.jp：新MacBook・MacBook Proのメモリーを交換しよう

精密ドライバーがなかったのでコンビニで買ってきて、手先の不器用さには定評のある自分でも20分程度で交換完了。
無事認識されてめでたし。
これでメモリの残りを気にせず仕事できそうです。

# ところでもともとついてた1GBのメモリ二枚ってなんか使い道ないんかな。

RailsのconsoleでActiveRecordを使って大量のレコードを処理しようとする場合、とりあえずコントローラ内に書くのと同じように以下のように打ってみると思う。

Item.all.each {|item| item.update_price }

ところが経験ある人も多いと思うけれども、これをやるとレコード数が1000程度でも大量のメモリを食う。
自分の経験を言えば、開発マシンのMacbook Proがスワップを大量発生させてコマ送りのようなレスポンスになった。

それぞれのレコードに対応するオブジェクトがループ終了までガベージコレクションによって破棄されないのでこんな風になる模様。
処理が進むにつれだんだんメモリ消費量が増えていく。
メモリリークのようだけどメモリリークではないんですと。

で、この敵に立ち向かうためにしばらくの間は勤勉さを発揮してある方法を採った。
一度に取得するレコード数にlimitを指定して↑キーとエンターを連打するという頭が悪いけど力技で確実な方法。

Item.all(:limit => 100, :order => 'updated_at').each {|item| item.update_price }

しかしながらさすがにこれを数十回繰り返さないとダメとなった段に勤勉さが底をついた。
というわけでいろいろ試して、これを以下のように書いてみたらメモリ消費は少ないということに気がついた。

(Item.count).times { Item.first(:order => 'updated_at').update_price }

これだとループごとにガベージコレクションがちゃんと働いてくれるみたいだ。