enbug diary

_ 四年目

今日で在仏四年目突入です。 石の上にも何とやらと言いますが、 三年が過ぎて、 まあいろいろあったなあと感じます。

去年のエントリー を見ると、

フランス文化を楽しめるようになる

とか抱負が語られてますが、 まだまだ程遠いなあ。 フットボールをフランス語の解説で楽しめるようになったのだから、 良しとしますか。

滞在許可証の更新は現地で行えなくなって、 パリに頼まなきゃいけなくなったらしく、 遅れてます。 おかげでしばらくフランスから出国できません。 そろそろ十年カードが貰えないのかと訊いてみましたが、 まだ駄目だそうです。 確かに 海外移住情報 フランス査証編 によると、

通常労働許可証を取得し、更新によって5年間を経た人（6年目に申請できます） ※以前の「4年間を経て5年目に申請」から変更。

ともろに書いてあって、 おいおい、まだ二年もいないといけないのか！と驚いてしまいましたね。 先は長い... 果たして自分がそこまで留まっていたいかはよく分からんです。

最近動きたい気分が昂じてきて、 どっかまた別の国に行ってみたい気分もするんですね。 今のところ、特に興味のある転職先があるわけでもないんで、 気分がするという程度なんですけど。 一応うちの会社でも私のこうした気まぐれに応じて、 ちょくちょく某国に出張させるとか画策しているようですが、 自分がそれで満足できるかどうかは定かでありません。

さて、今年度の目標ですが、 前と同じは芸がないんで、

もっと仕事に関連しない現地の知人を増やす

とでもしておきます。 やっぱり全然違う土地に来ると、 幼なじみとかも居ない訳で、 仕事以外で誰かと知り合う機会って、 極めて少ないんですよね。 じゃあどうすれば良いかっていうと、 ちょっと見当も付かないんですが。 外国人ってのはやっぱ難しいもんですよ。

_ W杯

ポルトガル、またGKのRicardoで勝っちゃいましたねえ。 デジャブですな。 二年前とほぼ同じ展開だったし。

フランスは完全に作戦勝ちでしたな。 ブラジルの作戦負けとも言える。 今大会を通じて初めてZidaneをフリーにしてもらえた。 こんなZidaneを見るのは何年ぶりでしょう。 序盤の立上りはブラジルが今までと違う戦略に切替えてきたので、 意表を突かれてやばい感じでしたが、 中盤は完璧に封じ込めてしまいました。 乗ってきたフランスを小手先の技術だけでかわすのは無理な話で、 ブラジルは研究不足、逆にフランスは充分に研究をつんだ事が伺えました。

しかし私の予想は全く当たらないことが明らかとなったので、 もう行けるだけ行ってくれとしか言えませんね。 次はポルトガルとだから、個人的にはどっちが勝ってもいいんですが、 良き市民としては、フランスが勝つ方が嬉しい。 だから、次もフランスは勝てないだろうと予測しておきます。 Decoも出てこれるしね。

_ 夢と発想

私はときどきすごい夢を見る。 すごいにもいろいろあるけれど、 普通覚醒している時には思い付かないようなことを思い付く、 という意味ですごいことがある。 しかもほどほど筋道立っていることが多くて、 夢とは思えん程である。

最近見た夢では、 私は日本のどっかの地下街みたいなところを歩いていた。 周りは飲み屋ばっかりで、 どうやら私はただそこを通り抜ける道として考えているらしい。 ところが突き当たりの戸を開けると、 そこも店である。 なぜか私はそのまま店の中を通り抜けていけると考えているのだが、 実際には通り抜けられない。 店は店である。

そこで私は居直って、 そのままそこで何か食べることにする。 日本に帰ってきて、一週間ちょっと経ったのに、 実家では食べたい魚を出してくれないと考えて （現実にはそういうことはないが、夢ではそういう設定になっている）、 とにかく魚が食べたくて仕方がない。 これは現実に最近よく感じていることなので、 脈絡はよく理解できる。

店の人が何か言って、 よく聞き取れないのだが、 多分飲物を適当に選んでくれたのだろうと考えて、 適当に返事する。 注文を取りにくるが、 その店には少々のネタを壁に張ってある程度で、 メニューがない。 その人に何があるか訊くと、 紙を三枚ばかり持ってきて、 それらにいろいろ書いてある。

最初の紙に、かますが書いてあって、悪くないなと思う。 かますはフランスにはいない。 ところがその次の紙を見ると、 見たこともない魚が書いてある。 「しみれ」という。 一体何なのだろう。 ご丁寧に説明まで書いてあって、 これはどこそこの湖に住む魚で、 こういう風に調理する云々と記述されておる。 しかしそんな魚は私の知る限り存在しない。 でも興味が湧いたので、それを頼んでみる。 あと、まぐろとさんまを頼んだ気がする。 結局かますは忘却の彼方に消え去った。

その後は店の中の、自分の席斜め後方のお座敷に友達がいることを発見して、 全く異なる話に展開していくのだが、 それは恥ずかしいので書かない。 おかげで「しみれ」なるものがどういう魚であるのかは分からず仕舞いであった。

ともかく、私はこの手のどっかドラマじみた、 それでいて変な発想の混じった夢を見ることがしばしばある。 昔学生の時分はバカみたいによく眠っていたので、 今より頻繁に珍妙な夢を見ていた。 ある本で、ある数学者は夢で見た思い付きを現実に生かすため、 枕元に紙と鉛筆を置いておき、忘れないうちに書き留めていた、 と書かれていた。 私も真似してみようかと思ったこともあったけれど、 私は元来不精な質であるし、 夢の内容を反芻して楽しむ程が面白いので、 結局そういうことはやらなかった。

昔部室で早朝までデバッグしていて、 結局分からなくて帰って寝て、 夢の中でも再び同じデバッグを続けていて、 夢の中で解決して、 実際にその解決が正しかった、 だから同じパッチをまた当てないといけなかった、 ということがあった。 あれはいくら解決しても悪夢だと思った。 夢ってのはちょっとぐらい現実とずれてくれないと気が休まらないものなのだろうか。

_ 求人

職場の話をここに持ち込むのはちっとも好きになれないのですが、 どうしてもと言うので、 一応消極的に書いてみます。

うちの会社や関係の深い会社で人材を募集してます。 内訳は Zope/ERP5 Positions Open at Nexedi あたりを御覧ください。 国籍、学歴、その他、特に気にしません。 とりわけ研究開発する人を募集してます。 リンク先には英語で、と書いてますけど、 日本語で送ってくれても構いません。

外国に行くことになるので、日本をしばらく出てもいい方限定ですね。 労働許可を取得するノウハウは蓄積されているので問題ありません。 私を見れば分かるように、現地の言葉がほとんど分からなくても、 案外何とかなります。

どんなメリットがありますかね。 人それぞれでしょうが...

• 外国で働ける
• フリーソフトウェア／オープンソースに専念できる
• 技術力の高いチームで働ける、ハッカー多数
• 日本と比べると山程休みがあるし、時間の縛りも緩い
• 世の中に浸透している等といった理由でJavaを使わされたりしない
• いろんな職種の人や現場と関わりが持てる
• 成長中の企業を体験できる
• EU内なら簡単に外国旅行ができる
• W杯を当り前の時間に観戦できる

_ W杯

さてはて、今日でW杯も終わりですね。 準決勝では私が勝てないと予測したおかげで（？）、 フランスが勝ってくれました。 その夜はさらに大変なことになってましたが、 今日は一体どうなるでしょうか。

とりあえず再びフランスは勝てないだろうと言っておきます。 イタリアもTottiの引退があるので、 花を咲かせようと頑張るでしょう。 この試合の命運はここまでいまいちなThierry Henryがいかにしてオフサイドにならずに球を受けられるかに掛かっていそうです。

_ ふと思ったことなど

最近さすがにあまり聞かなくなったが、 それでもGPLやFSFは共産主義だと主張して憚らない輩がいる。 昨今の業界の流れを見てもわかるように、 全く事実無根、荒唐無稽な主張である。

私が思うに、共産主義的活動が名指しされるべきなのは、 ファイル共有などで違法コピーにはまっている連中だと思う。 これこそ、みんなで共産してハッピーになろう、の典型だと感じるんですね。

まあ大抵の人は特に主義があるわけではなくて、 ただ手に入るからやってるだけだと思うんですが、 ときどき本気で「自分たちのやっていることは正しい」と主張してくる人がいる。 法律が常に正しいとは言えないので、 必ずしも間違っているとは言わない。 しかし「音楽業界がおかしいから、彼らには金を払わない」などと宣っているのを耳にすると、 おいおいって思ってしまう。 じゃあ、その業界の放出する作品と付き合うのを止めれば、と。 あるいは、業界を変えさせる努力をやれば、と。 私には単なるエゴにしか聞こえない。

もっともレッドパージの時代じゃあるまいし、 共産主義を頭ごなしに徹底的に否定するのもどうかと思う。 「○○は共産主義だ」と主張する人の頭の中には、 「共産主義 = 悪」と方程式が成り立っている。 が、現実のシステムは常に折衷であって、 純粋な資本主義もまた悪であろう。

私しては、いろんな主張があって、 それらが常に自由に存在し続けられ、 弾圧も受けない社会が一番だと思う。 自由が必ずしも善とは言えない、 という哲学的研究も数世紀に渡って繰り広げられているので、 自由でない方が良いという主張も受け入れられなければならないのですが、 それが多数派になると、システムが崩壊してしまうので、 自由主義も万能とは言えない。 でもどうしたらこの問題を解決できるか見当も付かないし、 私は自由が重要であると信じているから、 今のところ私は自由を尊重するしかないと思っている。 もっとも私は新しい考えを聞くと、 案外簡単に考えを変えてしまうことがありますが。

自由と言えば、 「自由 = やりたい放題」と信じている連中にも閉口する。 自由をどう定義するかという問題なわけだが、 私は自由は自らの決定に責任を負い、 自らの決定が可能であること、だと思う。 これは私のオリジナルではなくて、随分昔の哲学者が言ってたことなんですが。 名前は失念。 そして、自由な社会とは、それが分け隔てなく誰もに公平に機会が与えられる社会であると思う。

ときどきGPL嫌いな人は「ソースを公開しない自由がないから、自由でない」などと頓珍漢なことを言ったりする。 ソースを公開しないということは、他人がソースを弄る自由は奪ってるわけだ。 自分は弄っているのに。 こういうのは私にとっては「自由」ではなくて、 「我儘」である。

しかしその一方で、 GPL好きな人にも心の狭い人がたまに居て、 copyleftでないライセンス、例えば、BSD-style ライセンスなんかを、 極端に毛嫌いしていることがある。 これにも閉口する。 バイナリしか受け取れなかったら憤慨するのも分かるけれど、 ソースを手に入れて、それがBSD-styleでも問題はなかろうに。 GPLと同じく、自由に弄れるんだから。

コントリビュートするかどうか決める時にライセンスによって気分がぐらつく、 というのは大いに分かる。 GPLとBSD-style Licenseの同等のプロジェクトが二つあって、 さてどっちに関わりたいですか？と訊かれたら、 私ならGPL側に付く。 その方が自由に結び付く可能性が大きいから。 copyleftでないライセンスの場合、 初めから不自由なソフトウェアに転用したい気持ちがありまくり、 というケースが割とあって、 下心が見え透いていると気力が萎えますね。

しかし多くの場合、私は一向に気にしない。 自分にとって都合がいいと思ったら、寄付する。 思わなかったら、やらない。 ただそれだけ。

私自身でライセンスを決定できる場合は、 私も下心ありまくりなことだってあるから、 どのライセンスを採用するかはまちまち。 私の場合は他の人のコードを流用して、 それと同じライセンスにしてしまうという機会が一番多いかな。 ある意味、節操がない。

いずれにしても、心が狭い、無根拠で害のある主張を繰り広げる、 といったことはよろしくないですねえ。 世の中、全部白黒付けられるわけでなし、 直情的に善悪決めてかかるのは謹むべきですよねえ。

_ W杯

なぜか最後だけ当たってはならない予想が当たってしまいましたが、 しかしこんな成行きでイタリアは喜んでていいのかしら... Zidane、一体どうなるんですかねえ。 フランス人や多くの記者は同情的ですけど。

さて、次からのフランスはどうなるのでしょうか。 Thuramは進退を決め兼ねているようですが、 MakeleleとZidaneは引退確定。 Vieiraは微妙だけど、この状態で抜けるのは辛いでしょう。 Riberyは予想外の活躍で脚光を浴びてますが、 技術的にはまだいまいちなので、 指揮を取るには早すぎると思います。

二年後、果たして失った経験豊かな選手の分を取り戻せるか、 今後に注目です。

_ 法律関係

最近またいろいろありますが、 糞みたいなEUCDをフランスに持ち込もうとして、 DADVSIが強行採決、 しかも、DRMをうっちゃってしまった修正案を投げ捨て、 一体何考えてるんだか。 まあこれで終わりではないのが慰みですね。

ソフトウェア特許関係も、またEPOを中心して、 再燃中。 各国の特許局を潰して、 EPOに権力集中させ、かつ、屁理屈でソフトウェア特許を認めちまえ、 っていう、もう呆れるしかないようことを仕でかそうとしてますね。 そう簡単に行くわけないっつーねん。

_ failmalloc

私は立場上いろんな人のプログラムを見る必要がある。 しかし、とりわけ経験不足な人が書いたコードはエラーチェックが無茶苦茶である。 要するに、失敗することを考えていない。 これには非常にうんざりさせられるが、 そもそも何が原因なのか考えてみた。

失敗するのを見ることがないのがいけない。

これが私の辿り着いた結論である。 実のところ、malloc が本当にこけるところなんて、熟練者でさえ滅多に見たことがないんじゃなかろうか。 今日のようにメモリが潤沢になると、その傾向にますます拍車がかかることになる。

そこで、いっそのこと、わざと失敗させてみることにした。 何で今までこういうものがなかったのか、多少不思議ではあるが （私が知らないだけ？）、 30分ぐらいのハックで出来上がった。 それよりウェブページを作成する方がよっぽど時間がかかってしまった。

詳細はウェブの方を見てほしいのだが、 ハックそのものより、結果の方がずっと面白い。 いろんなプログラムにLD_PRELOADで注入して遊んでみたが、 世の中で幅広く使われているプログラムでさえ、御覧の通りである。 初心者に限って...等と考えた私がバカだったらしい。

ちなみにではあるが、 私は最近GRUB以外でCやC++みたいな低レベルの言語で開発することがほとんどないため、 自分自身のプログラムにはあんまり使えないのが残念だ。 ちなみにGRUBシェルには試してみたが、 結果は完璧だった（自画自賛）。

ところで、 posix_memalignが失敗した時にNULLで埋めてくれるか なんて、 とってもタイムリーなことを井上さんが書いてくれたが、 これこそfailmallocを使えば一発で分かることなので、 さくっとやってみたのでした。 もっともposix_memalignの場合には、 alignmentに1を指定するとか、もっと手っ取り早い方法もあるにはあるのだが...

_ Ruby On Railsによって考えさせられた事

Ruby On Railsは一部で結構盛り上がっているようで、 こうしたフリーソフトウェアを用いた技術が広がりを見せることに対し、 非常に嬉しく感じている。 しかしその一方でいろいろと考えさせられる事が多いのも事実である。

私が出現当初に感じたのは、 技術的に特に秀でているとは言えない、 ということだった。 Zopeでも同様のことが簡単にできるし、 遥かに完成度も高いではないか、と。

複雑さに金が落ちる時代は本当に終わるのか？ において、essa氏は

Railsの個々の機能の過不足を問題にするのはあまり意味が無い。仮に不足があったとしても、オープンソースなんだから、そういう問題点はたくさんの人が使っていくうちに自然とフィードバックによって直っていく。

と語っておられるが、 この手のフレームワークとなる技術は成熟に随分時間がかかるものであり、 その途上で頓挫してしまうことが少なくない。 Linuxは業務で使えるレベルに達するまで10年近い年月を要したし、 カーネルと比べればずっと小さいZopeも5年程かかった。

しかしながら、私は後日この第一印象を改めなければならない、と感じた。 結局のところ、技術的成熟に必要なのは、 「長期間に渡って開発に没頭してくれるユーザ」をどれだけ確保できるかにかかっている。 Ruby On Railsの上手さとは、技術ではなく、 宣伝、マーケッティングにこそあり、 それは学ぶべきものなのだ、と。

振り返ってみれば、 一時期マニアの間で話題となり、巷を席巻したZopeを、 私は業務で必要となるまで一度も使ってみたことがなかった。 それはなぜなのか。

まさにマーケッティングの一言に尽きる。 もっともZopeの場合には業務に浸透してしまったので、 あえて新し物好きの注目を惹きつける必要性がないともいえる。 しかしZopeの宣伝の不味さ加減は端から見ていて、 非常によく分かる。 実力が充分に理解されていないと感じる。

こういうマーケッティングの巧拙は、 ヨーロッパにいると、しばしば目に付くものである。 とにかくアメリカは宣伝がうまい。 ヨーロッパ、特にフランスやドイツは、 同等以上のものを作っておきながら、 宣伝活動で敗れることが多々ある。 ZopeとRuby On Railsの場合には、両方ともメイド・イン・USAなので、 これには当てはまらない。 全てのアメリカ人がうまいというわけではない。 だが、しばしばアメリカの個人や企業にはやたらと宣伝がうまくて、 宣伝能力によって市場を勝ち取ってしまう例があるのだ。 Google然り。

エンジニアはこういうのを政治活動云々等と忌避する傾向があったりするけれど、 優れた技術だけで選ばれるほど世の中甘くない。 いくら優れていても、 その事実が知らしめられなくてはユーザを得ることはできず、 つまるところ技術的にも遅れを取ってしまうことになる。 趣味の開発ならそれでもよいけれど、 ビジネスが噛んでいる場合はそうはいかない。

まあこういう技術以外の点を学んでいかなければいけないなあ、 と感じる今日この頃なのでした。 日本でZopeやっている人、もっと頑張って宣伝してあげてください。

_ メモリ確保の失敗に関する考察

今日はフランス革命の祝日で時間に余裕があるので、 久々にいっぱい書きます。

思い切りウケ狙いで作った failmalloc であったが、 狙い通りに ウケてくれて、 非常にありがたい。 まさにハック。

しかしせっかくウケてくれた人もいるので、 少し真面目な考察を加えておきたい。

そもそもなぜ失敗を確認しなければならないのか、 NULLが返って、Segmentation Faultでくたばるなら、 それでいいではないか、という向きもあるかもしれない。 しかしながら、それは「メモリ保護機能がきちんとした」システムにのみ適用できることだ。 MMUのないハードウェアやMMUを利用しないOSでは、 自動的にプロセスを止めてくれたりはしない。 ポインタ演算を含む場合には、より上位のアドレスに悪影響を及ぶこともあるだろう。 Segmentation Faultなんて出て強制終了させられるソフトウェアが全くユーザに優しくないのは言わずもがな、である。 だから、何らかの対処をしなくてはならないのだ。

この対処法がなかなか難しいのが現実である。 ちょっとしたプログラムであれば、lsみたいにエラー表示して終了すればよいだろう。 だが、そう簡単に死なれては困るソフトウェアは数多い。 例えば、システムの重要な機能を担っているプログラムの場合、 そう簡単に死なれては困る。 また、昨今のデスクトップ・アプリケーションでは、 セッションや設定の終了時保存機能が当然のものとして受け入れられている。 いきなり死んではその暇がない。 あるいは、 データベースやトランザクション、ジャーナリングに関わるプログラムでは、 中途半端な状態にすると、再起不能に陥りかねない。

私の知識の範囲内では、以下のような手段がある。

• プロセスを監視し、死んだら再起動する。Squidなど。
• 変なことが起きたトランザクションはとっと諦めて、初期状態に回帰する。Apacheなど。
• 緊急時用にいくらか余分に前もって確保しておく。Linuxなど。
• 途中で死んでも不整合が起きないアルゴリズムやデータ構造を組んでおく。多くのデータベースやジャーナリング・ファイルシステムなど。
• 始める前に全部確保しておく。多くの組込み系アプリケーションやGRUB Legacyなど。
• ガーベッジ・コレクションなどで空きを増やして、粘る。多くの言語処理系やGRUB 2など。
• 他のプロセスに続きを任せる。多くのデータベースなど。
• 諦める、無視する。多くの駄目プログラム。

どういった手段を用いるかはケース・バイ・ケースだが、 おそらく一番難しいのはフレームワークとなるソフトウェア、 特にカーネル、データベース、言語処理系などだろう。 こういった汎用目的のソフトウェアはさまざまな要求に対応しないといけないため、 どんな回復手段にも対応できる柔軟性が必要とされる。 私がインタープリタ（python、perl、ruby）を例に出しているのは、 そういった部分が実際にどうなのか知りたかったからでもある。 別に特定のプロジェクトを槍玉に上げたかった訳ではないので、 誤解なきよう。

現実にはどれも十分には信頼できないことが伺えた。 だから、こうしたソフトウェアの上位にアプリケーションを作り上げる場合、 いきなり死ぬ可能性があることを常に考慮に入れなければならない。 私はよく「本質的に複雑な問題はどうやっても複雑だ」と言っているが、 これはあくまでコーディングに関することであって、 ユーザ・インターフェースのことではない。 残念ながらスクリプティング言語をもってしても、 この問題は解決できていないようだ。 将来この「突然死」問題を解決、あるいは、少なくとも軽減するような能力を、 言語処理系に実装されていくことを希望したい。

もっとも「電源断」や「CPU炎上」にはソフトウェアだけではどうにもならないから、 いきなり死んだ場合の対処が消失することはなさそうではあるが...

_ failmallocの続き

あんまりもう弄る気はなかったのだが、 まつもとさんに指摘された問題を修正し、 zundaさんのパッチに触発されて最大失敗回数の指定、 更に、安全に確保できるサイズの指定をサポートした。 自分は好みがうるさいので、コードは自前で書いた。 すんません。 バージョンは 1.0 です。 二進法ですから。

しかしこれで何やら ls の不思議な挙動に気づいてしまった。

$ LD_PRELOAD=.libs/libfailmalloc.so FAILMALLOC_TIMES=4 ls
Makefile    config.status*         failmalloc-1.0.tar.gz.sig  failmalloc.o      libtool*
config.log  failmalloc-1.0.tar.gz  failmalloc.lo              libfailmalloc.la

なぜかちょっとぐらい失敗があっても、死なない。

$ LD_PRELOAD=.libs/libfailmalloc.so FAILMALLOC_TIMES=40 ls
ls: memory exhausted

いっぱい失敗すると、死ぬ。

$ LD_PRELOAD=.libs/libfailmalloc.so FAILMALLOC_INTERVAL=40 FAILMALLOC_TIMES=2 ls
Makefile    config.status*         failmalloc-1.0.tar.gz.sig  failmalloc.o      libtool*
config.log  failmalloc-1.0.tar.gz  failmalloc.lo              libfailmalloc.la

40回目で死ぬだけなのかと思ったが、どうもそうではない。

$ LD_PRELOAD=.libs/libfailmalloc.so FAILMALLOC_INTERVAL=40 FAILMALLOC_TIMES=4 ls
Virtual memory exhausted.

でも四回繰り返すと死ぬ。しかもエラーメッセージが違う。

$ LD_PRELOAD=.libs/libfailmalloc.so FAILMALLOC_INTERVAL=43 FAILMALLOC_TIMES=2 ls
Makefile    config.status*         failmalloc-1.0.tar.gz.sig  failmalloc.o      libtool*
config.log  failmalloc-1.0.tar.gz  failmalloc.lo              libfailmalloc.la

だからと言って、43回目あたりで死ぬわけでもない。

これ以上真面目に追ってないので、なぜかはよく分からない。 暇な人がいたら、調べて教えてください。

とりあえずこれ以上弄る気は全くないので、 もっとやりたい人がいたら言ってください。 Project Adminの権限あげますから。

_ Perlはやっぱもう駄目か

failmalloc に関して、 Rubyについては作者のまつもとさん自身が対応してくださったり、 PythonについてもNealさんから個人的に連絡を受けたりと、 プロジェクトの勢いを感じさせる展開でありました。 私は例に出さなかったにも関わらず、 いろいろ他に試してくださったプロジェクトもあるようです。

しかし何かひとつだけ全く動きのないプロジェクトがあって、 それはPerlなんですよね。

私自身、確か4、5年ぐらいはPerl使いでした。 途中で一度Rubyいいよーと勧められたけれど、 「Perlで出来てるのに何でまた別のを勉強しなきゃいけないのだ」 と、よくあるパターンで、Perlを長年使い続けていたのでした。

しかしPerlで書いたコードは全部ゴミにしかならないのは痛感していて、 前に書いたものを解読するぐらいなら、 また一から書き直した方が手っ取り早いという状況に、 何か間違っているよなあという思いを抱きつつ、 面倒臭さが先に立っていた、ある日のこと。 何かの理由で一年ぐらい放置していたスクリプト群を洗い出さなくてはならなくなりました。 それらは全部自分で書いた物であったけれど、 全然意味分かりません。 何だか生ゴミの容器から貴重品を見つけ出そうとしているかのような気分がしました。 しかもスクリプトが分からないと、溜っているデータの意味も分からないので、 放り出す訳にもいきませんでした。 これで結局ふんぎりがついたと言うか、そういうことだったんですね。

私が思うに、RubyはPerlの守備範囲を何なくカバーしてしまっているので、 Rubyが使えるとPerlは要らないんですよね。 すでにPerlで書かれているプログラムを別にすれば。 それ以来、Perlはawkと同様に「使えるけれど、大して要らないプログラム」となりました。 と言いつつ、 私はsedやawkは結構使ってますけど。

多分こういう感覚は私に特有のものではなく、 世の中全体でもPerlの人気は急下降状態にあると思います。 比較的若い連中に訊くと、 もうあんまりPerlを使える人はいなくて、 Python、Ruby、Java、C++なんかがほとんど。 まあJavaの人気はマーケッティング以上の何者でもないと信じてますけど、 Perlの不人気は純粋に技術的であると思いますね。

ちなみに、Nealさんは結構こまごま報告してくれたので、 代わりにfailmallocをより汎用化するアイデアを教えてあげました。 大したアイデアではないけれど、 誰か適当に作ってくれると嬉しいな、と。

_ ヨーロッパに熱波、３１人死亡

うーん、確かに最近やけに暑い。 私は暑いのが好きなので、これぐらいが調度いいとか感じてますけど。 大体日本の暑いのと比較したら、湿度が低い分、何てことない。 ヨーロッパ人は寒いのに平気な代わりに、 暑いのには対処できないらしい。

この二年はひたすら寒い夏で、非常にがっかりしていたところなので、 個人的にはもっと暑いのが続いて欲しいっす。 食べ物がすぐ腐るのが玉に瑕なのだが。

_ 働き甲斐

Anthyで「はたらきがい」が変換できないっす。

私もmatzさんに同意見だなあ。 そりゃあ金に釣られて引っ張られていく人を何人か見てきたけれど（うちの会社ではない）、 数少ない個人的観測の範囲では、 優秀なエンジニアほど金の優先順位は低い気がする。 優秀な人っていうのは、自分のやっていることが好きな人だから （好きこそ物の上手なれ）、 金銭的収入が主な要因にならないことは自然に思える。 そもそも収入が目当てなら、技術者になった時点で間違っている気がするのだが...

個人的には、収入は、ほどほどの生活水準が保証されているならば、 あまり大きい理由にはならないなあ。 私は貧乏が身に付いてしまっているから、その基準も一般よりかなり低い方だろうし。 そうなると、仕事の内容、仕事場の雰囲気や環境、自由裁量の認められる範囲、 会社の方針と自分自身の価値観の一致の程度、 なんかの方がずっと重要性を増してくる。

今の会社では、私には通常認められるとは思えないぐらいの自由裁量が許容されていて、 さすがにこの「快適さ」を凌駕できるような会社は他にはそう簡単に見付からないだろう、 と思う。 うちの会社もベンチャーだから、 まだ「ベンツ乗り回して豪邸でメイド雇って..」みたいなことが出来る程の給料は期待できないが、 現在の恵まれた労働条件を金に替えるとしたら、ちょっとやそっとでは納得できないだろうな。

_ Pythonが 忘れられている

私がPythonのことをあんまり書かなかったというのもあるでしょうね。 私自身はPerlの代替という意味でPythonを使い始めた訳ではないし、 Pythonを覚えてからは次第にRubyの使用頻度が減少している... というのも、あの文脈では関係ありませんでしたから。

Perl vs. Pythonという文脈では、 オタワLinuxシンポジウム：1日目 にて、Martinさんがこう述べておられたそうです。

プログラミング言語としてのPythonがこのシステムの要件を満たす理由として、変更および管理が簡単、ライトオンリーではない、例外処理がある、必ずしも高速ではないが強力、習得が容易、多岐に渡るモジュールが利用できる、といった点をBligh氏は挙げている。

Perlはライトオンリーな言語であり、そのシェルを使えばすばらしいことができるが、自動テストの実装にはふさわしくない、というのがPerlに対するBligh氏の説明だった。彼は笑みを浮かべて、Perlシェルを使って可能なことは大いに尊重しているが、最初からシェルで自動テストを行う必要はない、と述べていた。

また、Pythonについては、特にインデンテーションの使い方が気に入っている、と語っていた。ほかの言語とは違って、コンピュータはPythonを人が読むのと同じ方法で解釈するため、結果としてバグが少なくなるという。

コメントで指摘されてますけど、 なぜか翻訳ではPythonがPHPに誤変換されているので（訳者はPHPの回し者なのか？）、 勝手に直して引用しました。

今まで何人もPerlから他の言語に転向する人を見てきましたけれど、 結局行き着く結論はみなさん同じなようで。

あー、ちなみに

Java はマーケティング以上の何者でもない、は言いすぎ

は全くその通りです。 「Javaの人気は9割方マーケッティングの賜である」と修正しておきます。 マーケッティングと言うと相変わらず気を悪くする人がいるみたいですけど、 以前書いたように 私はマーケッティングを否定的には捉えておらず、 むしろ積極的に押し進めるべきものだと考えてます。

_ memcached

memcached + pythonで遊んでみました。 何だか変に遅い気がしたので、 python-memcached のコードを覗いたところ、 かなり不味いコードが書かれていたので、 手っ取り早く改善して、メーリングリストに投げておきました。 当社比1.2倍の高速化。 これ以上は簡単には速くならないと思います。

ところでMySQLと比較してみたんですけど、 MySQLはやっぱり激速ですね。 memcachedは極力オーバーヘッドを無くして高速処理のみを目指して作られているにも拘らず、 さほど大きな差は生じません。 MEMORYエンジンだと高速化済みバージョンと比較しても30%遅いだけ。 InnoDBだと90%ぐらい。 アクセスパターンやデータ量でかなり変化するとは思いますけど、 ネット上だとI/Oのオーバーヘッドが結構効いてくるはずなので、 実用ではもっと差は縮まるかも。 もっともMEMORYエンジンだとBLOBが使えないので、 InnoDBかNDBを使うことになるでしょうが。

_ 最近読んだ本

ここのところ書くのをさぼっていたので、 また段々分からなくなってきましたが、 結構読んでます。

ダーク

OUT

柔らかな頬

桐野 夏生ばっかり。

ミロのシリーズを全く読んだことがないのに「ダーク」を読んでしまったので、 全く「このキャラクタがこんなことを！」なんて感慨に耽ることが出来なくて、 ちっとも面白くありませんでした。 はっきり言って、単にグログロした世界なら、この世だけで十分満足しているので、 だから？って感じ。

「OUT」は「このミステリーがすごい！」に選ばれただけあって、 そこそこ面白かったです。 でも感銘を受ける程ではないなあ。

「柔かな頬」はちょっと苛つく作品ではあるが、 ストーリーに深みがあってよろしいです。

虚貌

火の粉

雫井 脩介ばっかり。

「虚貌」は良い作品だと思います。 本格推理ファンにウケが悪いのは当然ではありますが、 ストーリーの完成度が高く、人間ドラマで楽しめます。

「火の粉」はねえ、何だかどっかの二時間サスペンスでTV化したら調度よさそうな、 えらいこじんまりした作品ですね。 作り上げようとしている舞台は面白いんだけれど、 どっか薄っぺらい印象。

湖水

これはね、地元ネタね。 貰ったから読んだけど、うーん、これはちょっとね。 あまりに古風なおじいさんが書かれた作品だから、作風には目をつぶるにしても、 これ、矛盾が多いんだよ！

例えば、主人公は大学入ったばかりで1996年頃。 妹は辰年だっていうんだけど、内容から推して、高校生なのよね。 でもね、それって不可能じゃん。 近い範囲で言うと、1976年か1988年生まれ。 つまり、20歳か8歳。 20歳だと妹になれないから（まあ浪人しまくれば別だが）、8歳だが、 日本だとこの年齢では高校生になれない。

後ねえ、時代錯誤っていうかねえ、そういうのが多いの。 辰年をこの際無視して考えて、妹は1980年以降の生まれだろう。 なのに、「当り前田のクラッカー」なんて死語を使うかよ！ 藤田まことは元々コメディアンだった、なんて今時の女の子が知っているのか？！

ワイルド・ソウル

この作品は文句無しに面白い！ 序盤の雰囲気から後半の展開が全くイメージできませんでした。 この人の他の作品も読んでみたいですね。

パプリカ

単に筒井康隆読みたかったので。 まあ相変わらず意味不明なオチになっていくが、 話の本体はとても面白いですね。 世界を潰さない程度に権力闘争を描けば、相当シリアスな話ができそうだけれど、 それじゃ彼の作風ではなくなってしまうか。

日本沈没

何やら映画化とかで盛り上がっているらしいですけど、 それとは全く関係なく読みました。 買ってから映画化の話を知ったぐらいでして。 小松左京をなぜか一度も読んだことがなくて、 たまたま読んでみようかと思ったんですが、 何でそう思ったかは忘れてしまいました。

この作品のテーマって民族意識だと思うんですが、 作品の中では案外冷静に民衆や政府が振る舞っていて、 ちょっと意外でした。 小松左京ってもっと悲観的なのかと思い込んでましたよ。 きっと私が書けば圧倒的に悲観的な展開になるでしょうね。

おーいでてこーい—ショートショート傑作選

未来いそっぷ

星新一もちっとも読んだことがありませんでした。 実写化されたものをいくらか観たことがあるとは思いますが。

作品によって質はまちまちですけど、 ものによっては確かに気が利いていて面白いですね。 しかし個人的にはあんまり「ショートショート」と思える作品は多くないなあ。 ほとんどは「ショート」なんだなあ。 私が思う「ショートショート」って、 「電話連絡」みたいな、ほんの2、3ページで収まってしまうような作品なんだろうなあ。

Javascript: The Definitive Guide

これは読んだ本じゃなくて、これから読むはずの本。 もうすぐ新版が出版されるそうなので、予約しておきました。

本当はもっと読んでいるんだけど、 何を読んだかあまり覚えていないので、これぐらいで。

_ やる気の維持

高名かどうかは知らないが、それなりに長くやっている者としてエラそうな事を言わせてもらえるならば、

• 時間が本当に無い時はやらない
• やる気が湧かない時はやらない
• やりたくない事は無理にやらない
• 義務だと捉えない
• 本当に自分が面白いと思えるプロジェクトを行う
• そういうことができる職場を選ぶ

というところか。 限られた時間の中で開発するには、

• 開発環境の改善を惜しまない
• さっさと書く
• 初めからなるべくバグのないコードを書く
• 初めから見通しの良いコードを書く
• 設計を軽視しない
• 他人にやってもらえることはなるべくやらせる

そもそもソフトウェアを自由にする動機って、 最後に挙げた項目が大きい位置を占めているのではないか。

つーか、あんたら、勤務中にも、オープンソースなコード書いてんちゃうんかい、こら。

オープンソースで開発する職場だから、当然書いてますが？

_ 日本のエンジニア

最近日本ではエンジニアの待遇の悪さがネタ的に流行しているようだが、 敢えて私の立場から言わせてもらうと、 本当にどこもかもそんなに酷いのかな？ そりゃおかしな職場も結構あるんだろうけれど、 不満のある人の方が声が大きいので、 錯覚させられているのではないかと危惧する。

仮にそれが本当のことだとすると、 何でそこまで不満がありながら、 日本に固執するのかなあ。 愛国心？ だとしたら、しょーがないかなと思うけど。

エンジニアという職業は数少ない、国際的に通用する技能の持ち主だ。 その他の、特定の国の事情にべったりくっついている職業、 例えば、会計士とか裁判官とかと違って、 同じ技術がそのまま適用できる珍しい職業である。 もちろん日本語処理しかできない...とかだと無理かもしれないけど、 それしかできないという人はいないだろう。 普遍的な部分もたくさん身に着けていると思う。

人材の流出だとか、政府なんかは騒ぐかもしれないけど、 個々人が自分の人生を犠牲にしてまで気にする事では無いと思う。 無理しないで快適に働ける国に移ればいいのに。 うちの会社はフランス人からはやたら働いているように評されることもあるけれど、 日本の忙しい会社と比べれば、そんなのお笑い種だと思う。 ほとんどの社員は7時までに毎日帰るし、土日は休むし、 有給休暇も山程ある。 国民意識なんだろうね。 忙しくないのがデフォルトっていう。