うってないよDoccica
昨日発売したDoccicaを買いに札幌ヨドバシに行った。
しばらく分かる人が出てこなくて待って、結局売り切れ。
なんでも、１個しか入荷してないらしい、、、って、やる気出せよ日本通信！
Webで買えると聞いたのでのぞいてみたが、なんだ、電話番号しかないぞ。
オンライン通販ですらないのか、これ。
時間単位の課金はたまにちょっとだけ使う僕なんかには合っていると期待しているので、
どうにかまともに販売して欲しいと思う。
みんな古典読まないのかなぁ
従来のソフトウェア工学が決定的に間違っている点とその周りのやりとりを見ながら思ったこと。本人の対応は生暖かく見守るとしても、こう言うのに疑問を持つのはいいことですよね。ただ、みんな、あまり古典を読まないのかなぁ。「人月の神話」の外科手術チームが似た話だと思うのですが、これって20年前からある本なんだけど。どうせなら、そっからの差分の意見を知りたい。
僕は、前の職場が、いわゆる「ソフトウェア工場」として一定の成功を収めたところで、みなさんソフトウェア工学的な話への関心も高く色々勉強させてもらいました。
個人的な感触としては、「ソフトウェア工場」的アプローチはある問題領域（という定義は正しくないかな）では非常に有効。もちろん、あまり有効でないと思えるケースも多い。
あと、大規模開発にも作業自体は濃淡があって、優秀な人間は濃いところに投入したい。よく言われるのがアーキテクチャ設計。IBMのSIでは、コアメンバを集めたアーキテクトチームがまずアーキテクチャ設計を行って、それからじゃないと見積もり回答しないって話をちらっと聞いたけど、事実なんだろうか。
経験からは他に、プロジェクトの「ツール屋」って仕事もハッカーを投入したい箇所だと思う。例えば、プロジェクト固有の排他処理手順をツールとしてまとめて、他のプログラマはその枠組みに乗っかるだけにする。セマフォを触るややこしいところはツールの中に押し込めることで、他のコードの品質が上がる、とか。
全体的に、ハッカーはレバレッジが効くところに使えってことでしょうか。
話が脱線気味なので引き戻すと、自分も含めてもっと勉強しなきゃあかんなぁ。（いまのソフトウェア技術者は不勉強だってぼやいていたのはアラン・ケイだったっけ？）
あと、古典を読でおくと、おじさんたちと話す道具にもなるのでオススメです。
アラインメントをとってプチフリ対策
CF-R3 + SSD + Windows7 はそれなりに使えるのだが、やはりメモリ768MBはさすがに厳しい感じもあるので、XPに戻すことにする。
XPのプチフリ対策で、前回未実施だったのがアラインメントの対応。
結論からいうと、アラインメントはそろって、プチフリも結構軽減され、、たのかな。そこまで変わってないかもしれんが、スパシーボ効果ってことで。
前置き
アラインメントとるってことは、一般に、規定の境界にそろえてあげることです。例えば主記憶（メモリ）に4byteのデータを置く場合、4の倍数のアドレスに置くきます。そろってなくてもアクセスできないことはないけど、読み出しに必要な命令が2回になって遅くなったりします。
HDDの場合には、64KBで最適パフォーマンスが出やすいらしく、SQL Severで性能を稼ぐときには気にするみたい。SSDの場合にもそれがあるようで、どうも4KBなどが境界のようです。
参考：http://www.tomshardware.com/news/ssd-hdd-sata,6719.html
どうしたいか
普通にインストールすると最初のパーティションは63セクタから始まります。これが非常にバッド。これを64セクタに変更します。
そもそも
なんで63セクタなんかになっているのか？どう考えても半端すよね。
初期のハードディスクはCHS (Cylinder Head Sector) という物理構造に基づいたアドレッシングをしてました。最小単位である１セクタは512byteでこれは現在でも一緒。ディスク１周（トラック）は1-63(6bit)で最大63セクタです。パーティションを分けるツールはCHSの区切りのよいところに置こうとするため、通常最初のパーティションをC/H/S=0/1/1。2つ目以降はn/0/1。（※セクタは1始まり）
このCHSのアドレッシングはHDDをMBで数えていた頃の遺産で、現在のHDDはこんな単純な物理構造してませんし（トラック辺りのセクタ数は内側と外側で違う）、SDDにいたってはシリンダも何もありません。決定的にはアドレス用のbit数が足りないため、LBAと呼ばれるアドレッシングに変わっており、通し番号（こっちはどうやら0始まり)でセクタを数えます。
で、現状は（ディスクのコントローラから来る？）制約で4KB境界でそろえるのが良いようです。すると、デフォルトのスタート位置であるCHS:0/1/1はLBA:63であり、１セクタ512Bなので、32KBの最後のセクタです。64KBのど真ん中と言うことになります。いけてない。
1トラックが64セクタだったなら、問題なかったのに。結局、なんで1スタートになっちゃったのかよく分からず。
手順
普通の手順は下記（もしくはその最初でリンクされているページ）が詳しいです。
参考：http://www.ocztechnologyforum.com/forum/showthread.php?t=48309
ここでは、パーティションツールを使わずに、Linuxの手頃な道具でアラインメントをとってみます。
(1) パーティション1 の内容をダンプ
$ sudo dd if=/dev/sda1 of=XP10GB.img bs=512 count=20971520
※ntfscloneなんかを使うと、もっと安全かつ効率的にダンプできるらしい
(2) パーティションを変更
(2-1) sfdiskでパーティション情報を出力
※最初のパーティションがWindows XP
$ sudo sfdisk -d /dev/sda > diskconfig.txt $ cat diskconfig.txt # /dev/sda のパーティションテーブル unit: sectors /dev/sda1 : start= 63, size= 60002712, Id= 7, bootable /dev/sda2 : start= 60002775, size= 1558305, Id=82 /dev/sda3 : start= 61561080, size= 57319920, Id=83 /dev/sda4 : start=118881000, size= 6313545, Id= c
(2-2) エディタで書き換え
$ cp diskconfig.txt newconfig.txt $ nano newconfig.txt $ cat newconfig.txt # /dev/sda のパーティションテーブル unit: sectors /dev/sda1 : start= 64, size= 60002711, Id= 7, bootable /dev/sda2 : start= 60002775, size= 1558305, Id=82 /dev/sda3 : start= 61561080, size= 57319920, Id=83 /dev/sda4 : start=118881000, size= 6313545, Id= c
(2-3) パーティション変更
$ sudo sfdisk --no-reread -N1 /dev/sda < newconfig.txt $ sudo reboot
(3) データ書き戻し
$ sudo dd if=XP10GB.img of=/dev/sda1 bs=10M
(4) Partition Boot Sector(Partition Boot Record)を書き換え（結構はまった）
ディスクの先頭に特別なセクタ=MBRがあるように、Windowsパーティションの先頭にはPartition Boot Sectorがあります。勝手にパーティションを移した場合、ここのいくつかの値を書き換えて整合をとる必要があります。バイナリエディタでごりごりと修正。
参考：http://lets-go.hp.infoseek.co.jp/discpara.html
$ dd if=XP10GB.img of=pbs.dat bs=512 count=1 $ bvi pbs.dat
(4-1) Total Sectorsの修正
パーティションを短くしたので、ここもあわせて修正。
offset: 0x28, size: 8byte
現状値 : 97 91 93 03 00 00 00 00 (= 60002711)
変更値 : 96 91 93 03 00 00 00 00 (= 60002710)
(4-2) Hidden Sectorsの修正
先頭からのオフセット。
offset: 0x1C, size: 4byte
現状値 : 3F 00 00 00 (= 63)
変更値 : 40 00 00 00 (= 64)
今回もっともはまったのがこのパラメータ。だって、MicrosoftのNTFSの解説には「Not used or checked by NTFS.」って書いてあったのに！ 放っておいたらブートしなかった。。。
参考？：MSのNTFS解説：http://technet.microsoft.com/en-us/library/cc781134.aspx#w2k3tr_ntfs_how_dhao
参考：PBRの命令レベルで解説：http://bootmaster.filerecovery.biz/appnote3.html
(4-3) 更新
$ dd if=pbs.dat of=/dev/sda1 bs=512 count=1
Trac Lightning でcommit時にMERGEエラー
Trac Lightning 2.0.9をWindows XP に入れたところ、svn commitでMERGEエラーが発生。
ただし、commit自体は完了しているらしくファイルは更新されている。
ファイルのデータを送信しています .svn: コミットに失敗しました (詳しい理由は以下のとおりです) svn: MERGE リクエスト (相手: '...') が失敗しました
バージョン2.1 beta2を上書きしてみるも変わらず。
典型的にpost-commitスクリプトでおかしくなっているらしいということで調べると、
\TracLight\bin\post-commit.sh
の改行コードCR+LFがいかんらしい。エディタでLFだけに変換したら、普通に動作。
、、、。なにかインストール方法を間違ったのだろうか。
SSDでプチフリ
ようやくセットアップしたXPだけど噂通りプチフリーズが発生。
というか、想像していたよりも結構ひどくウェブ見ているだけでちょこちょこ止まる。
しょうがないので、対策を探してみる。
どうも仕組み上random writeが遅いのだが特定のSSDのコントローラではread/writeが混ざったりすると極端に遅くなるらしい。
つーわけで、対策はrandom writeを減らすことになる。
参考：Lansenの現実逃避日記
(2)Windows SteadyState
参考：ドメインパーキング
対策
SteadyStateというMicrosoftが出しているツールを使う。元は公共のPCで勝手に内容を書き換えられたりするのを防ぐためのツールで、この中のHDD保護機能を使う。
全てのwriteをキャッシュファイル（DBで言うところのジャーナルログ）に書きためて、次回起動時に適用するか元に戻すか(commit/rollback)を選べる。
ジャーナルに書きためるときにrandom writeがsequencial writeに変わるのでうれしいというわけ。
結果
インストール後、空き容量の半分＝10GBがキャッシュに割り当たる。プチフリはきれいに解消♪
すばらしい、、、と思ったが起動時に変更をcommitするのに数分かかる。考えたら当たり前で、random writeはなくなったのではなく、後にとっておいただけ。つーわけで、爆速だった起動が極端に遅くなり、本末転倒感が漂う微妙な対処。
(3)アラインメントをアロケーションサイズ4KBに最適化
参考：http://www.ocztechnologyforum.com/forum/showthread.php?t=48309
結果
未実施。
試すには
a)現在のデータを一旦別な場所に移して、上記実行、書き戻す。もしくは
b)上記実行後、再インストール。
a)を実施するには、適当なディスクイメージ系のツールと、それを動かす別PCが必要。
あいにくメインマシンにはIDEのコネクタはないので、ソフト買うだけじゃデータが移せない。
b)の場合、リカバリ領域から再インストールした際に、フォーマットが再度上書きされそう。
アロケーションサイズを指定する箇所なんかなかったので。
これで直るなら、制限の少ない方法なのでなんとかやってみたいのだけどなー。
追記1/11
1ブロック分移せばいいのかにゃーっと思って512バイト後ろにずらして見るも、
Windowsが起動せず「Starting Up...」のまま
(a) ddでダンプ
$ sudo dd if=/dev/sda1 of=XP10GB.img bs=512 count=20971520
(b) fdiskで64からに変更、再起動
(c) 書き戻し
$ sudo dd if=XP10GB.img of=/dev/sda1 bs=1M count=10240
