iceweaselがあまりに重いので調べたところ、次の記述を見つけました。

• http://debian.fam.cx/index.php?Software%2FMozilla#content_1_10

この対処(Pangoサポートを無効化)でまともな速度になりました。この速度差は異常です。 ついでに(体感上は関係ないのですが)、IPv6のDNSも無効にしてしまいました。カズ山本とマスター浜岸に怒られそうです。

巷で話題のsodexを使ってみました。

Debian Etchです。

# aptitude install qemu
$ qemu -fda sodex-0.0.1/fsboot.bin -boot a

証拠のスクリーンショット。

スクリーンショットはpsをしたところです。psの出力がコマンド履歴のようになっています(プロセスが死んでいない?)。

catが使えるという噂ですが、catで中身を見られるようなファイルがありません。しかし、cdとlsとpwdだけでも感動できます。

何度かここでも書いていますが、アリエル開発の入社面接を通るのはある意味簡単です。 ある技術を究めようとしていて、その理由が、楽しいから、好きだからと答えれば、面接は友好モードに入ります。 技術に関してのぼくの個人的な好き嫌いはありますが、それは関係ありません。 例えばExcelのマクロであっても、それを究めようとしていて、それがいかに楽しいかを切々と語れば、たぶん好意的に感じると思います。Excelマクロの良さを語る人がいれば、ぼくはUnixコマンドの直交性の良さを語って対抗しますが、議論を楽しむためで、友好モードには変わりありません。 究めたと言いながら、浅いレベルで満足していたらダメです。基本的に、簡単に満足するような人はあまり好きではありません。持っている技術がどうであれ、まだ何か足りない、と思っている人の方が好きです。究めようという心意気が重要です。

一方、アンチパターンは、「就職/転職に有利そうだからJavaをやっています」や「将来性がありそうだからJavaをやっています」と言った回答です。Javaの部分が本質ではなく、その前の動機の部分が本質です。きっかけはどうあれ、そこからJavaを究めようという方向に向いていれば友好モードですが、上っ面をなめて、とりあえずできますのレベルに到達することしか目が向いていない人の場合、攻撃モードがオンになります。面接なので、表面上は温厚そのものですが、密かに攻撃モードに入っています。技術の将来性などという未来予測をどういう根拠でしているのか、と突っ込みます。理路整然と持論を披露してくれば見直して友好モードに切り替わるかもしれませんが、どこかのIT系ニュースサイトの記事や、もっと悪いことに、どこかの広告記事を無批判に受け入れたような主張をしてきたら、相手の年令にもよりますが、説教モードに入ります。

この2項対立が適切か分かりませんが、後者をリアリストと呼ぶなら、前者はドリーマーと呼べるかもしれません。この2項対立のもとでは、ぼくは一貫してドリーマーに優しい面接者です。

しかし、ソフトウェアの開発グループの中にリアリストが不要かと言えば、そうではない、が自分の答えです。こういうタイプも採用すべきと思いつつ、いざ面接の場で、「業務で困らないのでこれ以上深く調べようとは思いません」と答えられると、かちんと来て、「もっと深く調べればいつか何かの役立つかもしれないし、なぜ深く調べる前に必要ないという判断ができるんですか」と言ってしまいます。

AirOne v4.8βのGNU/Linux版をリリースしました。

• http://dev.ariel-networks.com/alphaproduct

β版と言っていますが、コードベースはWindows版と同じです。

数年前はg++の過渡期で、バイナリ互換性に問題がありました(g++2.9、g++3.0、g++3.1の頃の話)。 g++のバイナリ互換性の問題もなくなり、配布バイナリはひとつで済むかと思っていたら、思わぬ罠がありました。GNU libcのバージョン問題です。

Ubuntu6でビルドしたバイナリを古いFedoraで動かそうとするとlibcにGLIBC_2.4シンボルが無いと怒られて起動しません。 結局、ふたつのバイナリを配布することになりました。

$ strings /lib/libc.so.6 | grep GLIBC

で、GNU libcのバージョンを調べて、必要なバイナリを取得してください。

ぼくの記憶では、shared libraryがバイナリ互換性を失うメジャーアップグレードの場合は、ファイル名のバージョン番号(上の例では6の部分)を変える仕組みだった気がします。記憶ではSVR4由来の仕組みだったと思いますが、GNUにとってはどうでも良い慣習なのでしょうか。

• http://www.senshu-u.ac.jp/School/network/news/event/rms.html

専修大学にrmsを見に行きました。 rmsの話すことは事前に分かっていますが、それでも聞きます。

聴衆の数の違いか(今日は500人ぐらい? 超満員でした)、話している時のrmsは随分落ち着いた感じでした。質疑応答に入ると、自由奔放ぶりを発揮してくれました。質問はだいたい途中で遮って答え始める、いつものスタイルです。

前の席で聞きましたが、女子大生たちがカメラを構えてrmsを待つ姿に感動しました。隣の女子大生はせっせとメモを取っています。隣の隣の女子大生もメモを取っています。専修大学の女子大生は英語が得意のようです。すごいです。

rmsの主張はかなりの暴言なのですが、彼女たちは大丈夫なのでしょうか。何の注釈もなしに、DRMはdigital restrictions management (http://www.fsf.org/campaigns/drm.html)です。試験に出ても自信を持って答えてほしいものです。独占的ソフトウェアを使ってはいけない、というメッセージは彼女たちに伝わったのでしょうか。ありがちな、マイクロソフトをけなして笑いを取る芸と違うことに気づいているのでしょうか。rmsは、本気でWindows使うな、と言っているのです。rmsの話を聞いた後には、iPodをごみ箱に捨てるぐらいの気概が必要です。

まあ、rmsの話を聞けたことは彼女たちの大きな財産であることに違いはありません。

• http://www.stallman.org/photos/vietnam/tamcoc/

Tamcoc(@vietnam)。rmsが行ったと思えば、もう少しありがたみが感じられたかもしれません。

性懲りもなく暗い話題で、今日もソフトウェアの品質の話です。過去の経験(*)と試行錯誤の結果、「テストまでの距離感を近くすべし」というのが、今の結論です。これだけでは意味不明なので、説明します。

テストまでの距離感は、主に時間と人に関連します。

時間の距離感は、コードを書いてからテストをするまでの間隔です。これを短くすべし、というのは比較的受け入れやすい意見だと思います。実装終了後、翌日にテストされるのと1ヵ月後にテストされるのはどちらが良いかと聞けば、ほとんどの実装者は前者を選ぶはずです。この距離感を究極的に短くしたものが、コードを書いた後すぐに自動化された単体テストです。ここでは自動化されたテストはとりあえず置いておきます。品質改善の手段に関して言えば、テストを自動化できる部分はそもそも議論対象外だからです(手段ではなく実践の問題)。

実装からテストまでの距離感を短くすることの正しさが自明かと言うと、事はそう簡単ではありません。機能Aを実装してテストした後、機能Bを実装した時、機能Aが壊れているかもしれない、という場合、機能Aのテストをやり直す必要があります。少なくとも、壊れていないことをある程度確信できない限り、テストが必要です。これを聞くと、機能Aのテストは機能Bの実装後にした方が良い、と考える人がいても不思議はありません。一方、どうせ一回のテストで完全なバグの発見はできないので、最初に機能Aのテストをしっかりやって、機能Bの実装後にまた別の視点で機能Aのテストをすれば更に品質が良くなるはず、という考え方もできます。個別の話になれば、結局はトレードオフの問題になります。

このように距離感を詰めることの弊害はありますが、基本線としては、距離感を近くすべきだという意見です。経験上、距離感をあけてしまう弊害の方が大きいからです。

人の問題はもう少しデリケートです。正直、時々自信がなくなり自問自答しますが、それでも距離感を近くすべし、が結論です。人に関して距離感が最も近いのは、実装した人間が自分でテストをするパターンです。これだけが不十分なのは流石に自明で、これを良しと言う気はありません。「ソフトウェアテスト293の鉄則」(http://dev.ariel-networks.com/Members/inoue/software-testing)での一番の収穫「多様な視点の重要さ」は今回の記事とは直交して、依然として最重要な鉄則だからです。多様な視点は置いておいて、ここでは、実装者と良くコミュニケーションできている人ほど、より距離感が近いと定義します。最も距離感が遠いパターンが、いわゆるテスト責任者(とテストチーム)を置いて、各実装者がその人にお任せ状態になるパターンです。心理的には、どこかの誰かがバグを見つけてくれるだろう状態です。一方、テストをする人の距離感を近くするスタイルにも異論があります。距離感の近さは、実装者と同じような見落としや盲点を抱えこむ危険があるからです。

時間同様、それでも結論は、人に関しても、テストの距離感は近くすべし、です。経験上、距離感をあけてしまう弊害の方が大きいからです。

見て分かるように、実際には、両者とも距離が近ければ近いほど良いというほど単純な問題ではありません(**)。本当の正しい答えは、適切な距離感がある、なんだと思います。しかし、適切な距離感と言うだけでは、何のなぐさめにもなりません。なので、より近い距離感、という姿勢は、適切な距離感を導くためのプラクティスだと考えています。例えて言えば、現役時代の落合が内角高めの一番速い球にタイミングを合わせていたようなものです。

(*)ロータス時代までは自分の書いたコードにバグが無いかしか考えていませんでした。全体の品質なんて気にもしませんでした。Notesはバグが多いなあ、と思ってもそれは他人事でした。他人の書いたコードも含めてソフトウェア全体の品質をまじめに考えだしたのはアリエル以降です。そういう意味では、ソフトウェアの品質管理に関する経験は6年程度です。長いと言えば長いし、短いと言えば短い時間です。

(**)単純な問題でないことは初めから自明ですが。