11/29に、監訳した書籍 が発売となります。

本書はこれまでの Code シリーズと若干趣きが異なっており、どちらかと言えば「コード」そのものよりも「コード」を実践的に書く際に必要となる「場」「技法」「やり方」などに焦点をあてている本です。具体的には「コメントや関数の書き方」から始まり「各種プログラミング分野の特徴」や「開発メンバの傾向とその付き合い方」まで、実に広範囲に渡ります。一歩踏み込んでコードを書き始めると気付く様々なポイント。本書にはそれら様々な事柄が分りやすい言葉で凝縮してある貴重な本ではないでしょうか。

また、本書は楽しく読めるような工夫が随所に入っています。たとえば使用されている用語は比較的分りやすい言葉が選ばれています。パスタやモンキーの絵やイメージを使うことで上手な例えをしているところもありますし、章末にはモンキー達のしみじみおかしなマンガが用意されています。

今回も引き続き翻訳については気合いが入っています。分かりやすく読みやすい日本語にすることはもちろん、英語直訳の意味がとれないジョークについては日本語の分りやすい別の内容に置き換えるなど細かい工夫もしてあります。カバーにもちょっとした仕掛けがしてあります。試しにカバーを外してみると別の図柄と文書が…。

若干分厚いのですが、読みやすいのでそれほど苦なくページを進められるはずです。プログラミングを本職とする人から、プログラミングはしないけれど多少関係はあるという人まで、様々な人が読める一冊になっているのではないでしょうか。

他人のプログラムを読む機会があった人なら誰しも、インデントが揃っていないなどの基本的な問題で卒倒しそうになるコードを見たりすることがあるのではないでしょうか。あるいは、まったく違う分野のプロジェクトに入ってとまどったりといった経験があるかもしれません。本書がそういった状況で少しでも助けになることができれば幸いだと思う次第です。

書店で見掛けたら是非手に取ってみてくださいませ。

emacs では、オンザフライでスペルチェックを行ってくれる「flyspell-mode」が存在する。 使い方は M-x flyspell-mode とするだけ。いちいち ispell-buffer を実行しなくて良いので非常に便利。

さらに、以下を .emacs ファイルに書いておくと、あるモードに入ったら自動的に flyspell-mode を起動してくれるようにもできる。このコードは znz さんの日記: にあるものをそのまま頂いた。

; flyspell-mode
  (mapc
   (lambda (hook)
     (add-hook hook 'flyspell-prog-mode))
   '(
     c-mode-common-hook
     emacs-lisp-mode-hook
     ))
  (defun my-flyspell-mode-enable ()
    (flyspell-mode 1))
  (mapc
   (lambda (hook)
     (add-hook hook 'my-flyspell-mode-enable))
   '(
     changelog-mode-hook
     debian-control-mode-hook
     text-mode-hook
     wl-wl-mail-setup-hook
     ))

znz さんのとは少し異なり、私は wanderlust でメールを書く際にも利用するよう変更を加えている。 これで wanderlust を使ってメールを書くときも、 スペルミスに気付かないままメールを送らなくても済む。

あけましておめでとうございます。本年もよろしくお願い致します。 さて、今日は先ほど起きたちょっと気をつけたい出来事について。

普段、カーネル・glibc・Debianパッケージ構築など各種開発メインマシンとして Athlon 1.2GHz マシン（メモリ512MBx2、VIA KT133A）を使用していた。 しかし、流石に購入後5年程度の年数が経ってきたこと、今となっては遅いこと、 ルートパーティションのディスクがエラーを吐き始めていたので、 ディスクの交換作業 + 主要開発環境を新マシンへ移行している最中である。

ところが、全150GB程度のHDDデータをコピーした後、正しくコピーできたか差分を確認したところ、 ビット化けが2ファイルで発生しているようであった。

 $ cmp /disk/hdc2/debian/sample/openoffice/openoffice.org-1.1.0/sd/res/imagelst/lc27046.bmp \
 /disk/hdc2-cp/hdc2/debian/sample/openoffice/openoffice.org-1.1.0/sd/res/imagelst/lc27046.bmp \
 異なります: バイト 304、行 1

  元データ:  00 00 CC 00 00 00 0C FF FF FF FF FF F7 FF FF FC 00
  コピー後:  00 00 CC 00 00 00 0C FF FF FF FF FF FF FF FF FC 00
                                                 ^^

また、diff -Nuarpqを実行してディレクトリ毎の差分をとったところ、 コピーは正常に終了していたにも関わらず差分がおかしいという報告が2ファイルで発生した。 そこで memtest86 (v3.2) を動作させたところ、メモリエラーが検出されてしまった。

Tst  Pass   Failing Address          Good       Bad     Err-Bits  Count Chan
---  ----  -----------------------  --------  --------  --------  ----- ----
  6     0  0001fcf80a8 -   508.5MB  00000080  00000880  000008    3   1
  6     1  0001213bc98 -   289.6MB  ffffffef  ffffffee  00000001      1

これが新しく買ってきたメモリなら交換すれば良いのだが、 問題は、このマシンを構築した時に memtest86 でしっかりとメモリチェックをかけてエラーがないことを確認していたことである。 年数が経つと、メモリだって壊れるものらしい。 このDIMMメモリはバルクで買った安いものだった。 案外永久保証のついているメモリだったら、こういうことはないのかもしれない。

また、このマシンでビット化けが発生して恐ろしく感じるのは、 Debian glibcパッケージやlinux-kernel-headersパッケージを含む、多数の Debianパッケージをビルドし、アップロードするのに頻繁に使用していたことである。 今さらだが、ビット化けによってデータが壊れたパッケージがアップロードされていなかったことを祈りたい。

教訓としては:

• メモリ購入後5年も経つとメモリは壊れることがある。
• メモリを買うときは、できれば永久保証があるようなまともなやつの方が良さそう。
• 大規模なファイルのコピーを行って、データ化けが発見された時、ほとんどの場合はメモリが壊れているのですぐmemtest86を走らせること。
• Debianパッケージなど、他人に影響のあるバイナリを生成するマシンはちゃんとメンテして、 おかしな挙動を見つけたらすぐmemtest86を走らせること。

ここ数年の年末年始は、普段使っているマシンの設定・構築やトラブル対処に明け暮れて終ることが多いのだが、 今年も例年に漏れずこのまま休みが明けてしまいそうである。