Matzにっき

_ April Fool's Day

今年も良いジョークは思いつかなかった。 だいたい嘘をつくセンスはなくって、 逆に毎年奥さんにだまされたりしてるんだけど。

妻: 雪が積もってるわよ
私: え、うそっ
妻: ええ、嘘よ。今日は4月1日。

とかね。あまりにもだまされやすいって気もする。 そういえば、今年は奥さんも嘘つかなかったなあ。 来年あたり、事前にしっかり準備してデカいのを出すかなあ。

_ [本]Curlプログラミングエッセンシャルズ

4839908834

入手した。なかなか面白い。まだ全部は読んでないけど、 プログラミング言語としては、LispとTclとJavaを全部足して4で割ってから、 なにか(PHP?)を付け加えたような言語。

文法的には「変わってるなあ」という感じだが、 まだ読んでいない後半の機能リファレンスの辺りは楽しみ。

現時点での印象は、

• 言語オタクとCurlの潜在的ユーザにはお勧め
• それ以外の人にはちょっとお高いかも。

_ [会社]新人歓迎会

おかげさまで会社も順調に発展して、 今年は新卒を三名も採用した。

で、今日は新人歓迎会。中華料理。 アルコールを飲まない私は、損をしまいとがんがん食べてたら、 つい食べ過ぎてしまって、お腹がぱんぱん。やり過ぎ。

若い連中はこの後ボーリングだそうだ。私は付き合わないで、そのまま帰る。

_ [本]インターネットマガジン

突然送られてくる。Blogツールの紹介でほんのちょっとだけ書いたのが直接の原因だ。

今月の特集は、Blogツール(MovableType, Nucleus, Bolosxom, tDiary)の紹介。 どうみてもtDiaryだけ毛色が違うだろう、という点は置いておくとして、 なかなか面白い記事であった。tDiaryの部分は、たださんが書いてるから安心だしね。

実は「インターネットマガジン」を読むのは久しぶりなので、 なかなか楽しめた。創刊当時はプロバイダの接続地図が面白くて(いつ破綻するかと(苦笑))毎号読んでいたのだが、 巻末のデータ編は健在らしい。

話題の「Ｗ社問題」も取り上げられているし、当たりの巻だったかもしれない。 いや、当たりは今月に限らないのかもしれないけど。

来月からはしばらくチェックしよう。

さて、見本誌に同封されていた手紙には、

今回見本誌をお送りさせていただいたのは、ブログでインターネットマガジンをご紹介いただきたい というお願いによるものです。

ブログが一般に定着しつつある昨今、...<中略>...、 「ブログを活用したマーケティングの実験」とでも言いましょうか、 ブログの口コミパワーを確認してみたい、という目的もございます。

<中略>

突然の一方的なお願いで申し訳ありません。まずは本誌をご覧いただいて、 「おもしろい」と思っていただけたら ブログ上でご紹介いただければと存じます。<後略>

とあった。本誌も面白かったが、このなんというかストレートなお願いが一番面白かったので、 紹介してみた。私の文章にどれだけの効果があるか疑問だが、 できるものなら、私もブログの口コミパワーを確認してみたい。

_ [教会]継続は力なり

昨日バプテスマを受けた子供の按手礼の儀式があった。 自分が受けた頃のことを思い出すが、なんと今月でちょうど30年も経つことを改めて認識して愕然とする。 思えば歳をとったものだ。継続は力なり、とは言うが、どこまで力がついたことだろうか。

まあ、継続しなかったよりはマシくらいにはなったかなあ。 30年もやってりゃ。

_ [本]SEの現場2004

これまた送られてくる。先日受けたインタビューの結果が載っているのだ。 まあ、オープンソースな生き方について簡単に紹介した、というような感じだろうか。

読んで印象に残ったこと。

• 自分の写真(p.24)を見て「石塚さんみたい」と思った。ぼくらって似てたっけ。
• 妻に「もうちょっとマシなシャツ着てけば良かったのに」と言われた。確かに。
• 「いわゆるSE」の生活は悲惨なことが多い。『13歳のハローワーク』に載らないわけだ。

そういう会社から離れて久しいので、「ああ、そうだったなあ」とおぼろげに思い出した。

あと、Tom DeMarcoのインタビューは面白かった。

-- デマルコさんは、マネジメントの才能のない人が優れたプロジェクト・マネージャーになることが可能であるとお考えですか？

私は、可能だと思っています。..<中略>..才能があるとは言い難い私自身もまた、マネージャーとして成功できました。..<中略>..偉大なマネージャーが自然にやっていることを真似たのです。もちろん偉大なマネージャーにはなれませんでしたが、良きマネージャーにはなれました。

そうかあ。私も良きマネージャーになれるかな。正直、あんまりなりたくないけど。

_ [OSS]Firebird日本ユーザー会

INTERNET Watchによると、 Firebird日本ユーザー会が発足したそうな。おめでとうございます。

「日本Rubyの会」が発足しても取り上げてくれるかなあ。

_ デジカメ(2)

先日欲しいと言っていたデジカメだが、

• B0001FTPDC
• Nikon Coolpix 3700
• B00008WJHB

あたりが条件を満たしそうだ。条件というのは

• 大きさは気にしない
• 光学ズーム付き
• 機敏な反応
• 300万画素以上
• できればSDカード
• ほどほどの価格

あと、銀塩カメラを作ってるところを優先している。 Coolpix 3200はストロボをチャージしている間、完全にフリーズしてしまうようなのがちょっと痛い。

他にもいくつも候補はあるのだが、まだ実機に触っていないので判断は保留。 でも、こうしてあれこれ考えているうちが楽しいって気もする。

_ [Ruby]CurlとAlph

Curlのウリの一つはクライアントサイドプログラミング。 プラグインを組み込めば、GUIもサウンドもブラウザの中から自由自在、ということらしい。

Flashでもできることだが、Curlの方がプログラミングに向いている(ような気がする)。 でもなあ、Curlは(Java+Lisp(or Tcl)+Templateエンジン)のような変な文法だしなあ。

そこで考えるのは、ブラウザ側でFlashプログラムを動かしておいて、 サーバ側と通信するというモデルだ。昔、Ruby/Tkでやっていたのと同じ方法だ。 InfoEther(というよりRubyForgeのと行った方がわかりやすいか)のRich Kilmerが、 そのようなもの(Alph)を作っている。 まだ公開されていないけど。

去年、Ruby Conferenceの時にRichからデモを見せてもらったが、 なかなかいい動きをしていた。 もっともネットワーク遅延が大きくなるとこのやり方では破綻するかもしれないけど。

_ [家族]料理はプログラミングだ

とかいうようなフレーズを以前聞いたことがあるように思う。

今日は私が夕食を作るはずだったのだが、夜に急遽用事が出来てしまった。 帰宅してから出発するまでに30分しかない。そこで、スパゲティをゆでつつ、 ソースを用意しつつ、サラダを用意するなど、慌ただしい夕食準備になった。

これは単にプログラミングというよりも、 スケジューリングをどうするかとか、同期のタイミングとか、 パイプラインをいかに詰まらせないかとか、パラレルプログラミングではないだろうか。

で、結局5人分のスパゲティを準備して、食事して、出発するまで30分で終えてしまった。

結論: プログラミング(特に並行プログラミング)の知識は料理にも役立つ(かも)。

_ [家族]入学式

今日は長男の入学式だ。1年1組だそうだ。 保育園以来の親友と同じクラスだったようで、めでたしめでたし。 桜吹雪の中での入学式であった。

思えば私も1年1組であった。もっともあっちは1学年5クラスもあったので、 下手するとそれだけで息子の小学校の全校生徒に近い人数がいたのだが。

いやあ、やっと保育園の送り迎えから解放される。 月曜日からはお姉ちゃんと一緒に自分の足で学校に行ってくれる。 当たり前のようだが、ありがたいことだ。 成長したものだなあ。

_ [本]Code Reading

0201799405 遅くとも4月の最初の週には、と念を押されていたのに ながらく延び延びになっていた 『0201799405』の監訳作業にやっと取り掛かれた。 途中で一度大量に直しを出したのだが、そこで力尽きてしまって、 初校が出るまで放置してしまったのだ。

前回ほどたくさんの直しはなかったが、意味が全然分からないような訳はもうないと思う。 最初は難しい訳の連続でどうなることかと思ったが、まあまあのレベルで収まったのではないかと。

これで他の人もチェックして、最終編集作業に回るのではないだろうか。 日本語版出版もそう遠くないな。

しかし、今回も疲れ切った。もうだめ。

_ [聖書]復活祭

11日は今年のイースター(復活祭)である。 以前、13日の金曜日の話の時にもちょっと書いたが、 毎年、

• 春分の日の後の
• 最初の満月の後に来る
• 最初の日曜日

が復活祭である。これは、

• 春分の日を含む月(ニサン)
• その中日(つまり15日前後の満月の日)に行われる過ぎ越しの祭りの前日に、十字架に掛けられたキリストが
• その次(実際は3日目)の日曜日に復活された

ことを記念するためにこの日が選ばれている。 少々わかりにくいが2000年前と今とでは暦法が異なる*1ため、 わりと現実的な計算方法だと思う。

もっとも、クリスマスが冬至のあとの適当な日に祝っているように、 春分の日以降の適当な日を決めて祝うのではいけないのか、 と問われると、実際いけない理由はどこにもないように思うので、 結局は歴史的事情ってやつなんだろう。要は気分だ。

イースター(Easter)という単語には直接的には「復活」という意味はないようだ。 少なくとも聖書由来の単語ではない。

手元の聖書辞典によると

The word Easter is from Eastre, a Norse goddess whose pagan festival was observed at the spring equinox. The association of this pagan goddess with the celebration of the resurrection of Jesus Christ was only be adaptation and synthesis. There is no real connection. Jesus, being the Lamb of God, was crucified at passover time and is the true Passover (1Cor. 5:7). He was raised from the grave on the third day thereafter. It thus became a springtime anniversary, and has come to be called Easter in the Christian world.

だそうなので、たまたま同じ春分の日つながりのヨーロッパの土着の祭りと 同一化が行われたのだろう。女神Eastreは「春に蘇る」という神話があったらしいので、 それが復活と結びついたのではという説も聞いたことがある。

今後しばらくのイースターの日付は以下の通り:

• 2004-04-11
• 2005-03-27
• 2006-04-16
• 2007-04-08
• 2008-03-23
• 2009-04-12
• 2010-04-04

計算プログラムもついでに載せておく。

def easter(y)
  g = (y % 19) + 1
  c = (y / 100) + 1
  x = (3 * c / 4) - 12
  z = ((8 * c + 5) / 25) - 5
  d = (5 * y / 4) - x - 10
  e = (11 * g + 20 + z - x) % 30
  e += 1 if e == 25 and g > 11 or e == 24
  n = 44 - e
  n += 30 if n < 21
  n = n + 7 - ((d + n) % 7)
  if n <= 31 then [y, 3, n] else [y, 4, n - 31] end
end

for y in 2004..2010
  printf "%d-%02d-%02d\n", *easter(y)
end

このプログラムはもちろん舟迫さんによるものだ。

_ [OSS]日本オープンソース推進機構が活動を開始

日経ITProの記事。『「自治体へのオープンソース導入やLinuxでのCOBOL資産活用を支援したい」−−NPO法人が活動開始』

以前、OSSAJについて書いたが、この日本オープンソース推進機構はまったくの別団体。 少なくとも設立趣旨はこちらの方がわかりやすい。

とはいえ、おんなじオープンソースで複数の団体があってどうするつもりなんだろうか。

窓口が多くて混乱するようになるのか、 あるいは窓口が多くてそれだけ多く注目を集められるようになるのか、 私には予測できない。こちらも5月からという「本格的活動開始」に注目したい。

_ [生活]思わぬ検査

早朝、息子がトイレに行くというので起こされた。 トイレの前で立っていると急に胸の真ん中が痛くなった。 かなり痛い。

つらいので寝てしまうことにした。 しかし、ふたたび起きてもまだ痛い。

子供たちが学校に出発した8時頃には痛みはだいぶ治まってきていたが、 心配なので、近くの総合病院に。胸部レントゲンやら心電図やらを取られる。

すると、梗塞の疑いがあるということで、赤十字病院へ紹介される。 で、ここでもまた血液検査やらレントゲンやら心電図やら心エコーをとられて、 どきどきしたのだが、医者のみたては「異常は見つかりません」だそうだ。 心電図のパターンは正常の範囲内で、梗塞の疑いは心電図のコンピュータが安全側に倒した結果らしい。 見逃すよりは良いだろうということだそうだ。

診断を受けた時点ではもう痛みはなかったのだが、 実際に痛かったのは事実なので、「異常なし」と言われても気持ち複雑だったが、 とりあえず看護士のおばさんの「おめでとうございます」という言葉を背に会社に向かうのだった。

なんだったんだ。失恋の痛みか。そんな覚えはここ何年もず〜っとないが。

〆切前だというのに半日つぶれてしまった。

_ [生活]誕生日

今日は私の誕生日。実際に私が生まれた日も水曜日であった。

マザーグースにはこんな詩がある。

Monday's child is fair of face,
Tuesday's child is full of grace,
Wednesday's child is full of woe,
Thursday's child has far to go,
Friday's child is loving and giving,
Saturday's child works hard for a living,
And the child that is born on the Sabbath day
Is bonny and blithe, and good and gay.

水曜日に生まれた子供は「full of woe」らしい。 辞書によると「woe」とは「苦しみ」のことなので、 なんかつらい人生が待っているような気がする。

全世界の水曜日生まれの皆さん、一緒に耐えましょう。

実際には「go」との韻を踏むためだけに選ばれた言葉だろうから、 全然意味はないわけだが、この詩の作者も無責任に残酷な単語を選ぶものだ。

うちの家族だと

• 妻: 火曜日(full of grace)
• 長女: 月曜日(fair of face)
• 次女: 金曜日(loving and giving)
• 長男: 水曜日(full of woe)

である。なんとなく当たっているような気がしないでもない(長男は除くことにしよう)。

あ、実際には私の人生はおおむね幸せです。好きなことして食べていけてるわけだし。

_ [会社]新人研修

今年入った新人三名の研修。今日のテーマは「オープンソース」。

でもって、オープンソースについて半日ぐだぐだと話すのであった。 例によってキーワードのみ。

• オープンソースの定義
• ライセンスの選択の動機、理由
• オープンソースの嬉しさ
• マーケティング用語としてのオープンソース
• ビジネスの道具としてのオープンソース
• 開発者の喜びのためのオープンソース

_ [原稿]Linux Magazine

ゴールデンウィーク進行で〆切が早まっていたのだが、 先日の病院騒ぎで2日ほど遅れてしまった。

今月のテーマはcomp.lang.rubyでも話題になっていたInstiki。Instikiが内部で使っている

• webrick
• erb
• redcloth
• madeleine

について。特にMadeleine(あるいはObject Prevalence)について解説してみた。

_ [OSS]「オープンソースエバンジェリストの盲点」？

A.Tさんからのツッコミより。 オリジナルの英文はこちら。

これらの主張をまとめると、こんな感じか。

1. 「正しい」ユーザインタフェースを作るのはEricが考えているよりもずっと大変だ。
2. この分野ではプロプライエタリな開発体制の方が進歩が速い(例: Mac OSX)。
3. これは、Ericの「オープンソースは素晴らしい」という主張に対する反証ではないか(これは本文よりもA.Tさんのツッコミのニュアンスか)。

ごもっとも。(1)と(2)については「確かにその通り」と私も思う。

でも、Ericはインタフェースの専門家ではないし、 ユーザインタフェースに対する深い見識を彼に期待するのはどうかと思う。 彼が優れているのは、ハッカーという「人種」への見識であり、 彼の功績はハッカーの気持ちとそのやり方の価値をハッカーでない人に伝えたことである。 ユーザインタフェースに詳しいからでも、 優れたソフトウェア開発者であるからでも、 優れたプロジェクトリーダーであるからでもない。

さて、(3)だ。同じ「オープンソースは素晴らしい」という言葉を聞いても、 受け止め方は人によってさまざまだ。 が、オープンソースについて実際に関っている人は、一部の人が持っているような 「オープンソース開発体制はいかなる点でもプロプライエタリな開発体制よりすぐれている」と 思っている人はいないと思う。

現実には「多くの人にはオープンソースというやり方は信じられないかもしれないけど、 思ったよりも良いものができるんだ」というのが、 その意味するところではないだろうか。

もし、「コストはいくらかかってもかまわないから良いものが欲しい」のであれば、 良いものを得るために直接金を払う方が優れたものが得られるに決まっている。 プロプライエタリな開発体制の方が進歩が速いのは、考えなくても当然のことではないだろうか。

重要なのは以下の点だ。

• 「オープンソース」というやり方とキーワードを使うことで、 資本、市場シェア、リソースなどで劣るプレイヤーが競争力を得ることが可能であること。
• ソフトウェアのソースコードが制限のない形で入手できることで、 プロプライエタリなソフトウェアでは決して得られない自由を手にすることができること。

この「素晴らしさ」の前には、進歩の遅さなど気にならない、という人もいるだろう。 かくいう私もその一人だ。 オープンソースはカメである。ウサギの論理で測れば劣っているところもたくさんあろう。 だが、キーワードは「good enough」である。

追記:

「バカが征く」で述べられていたような、 『クローズドソースであり、フルタイムのエンジニア達で なければ優れたUIを持つソフトウェアは作れない』という主張を原文から読み取ってはいけないのではないかと思う。 彼の主張は

オープンソース革命は結局、最も直感的でベストなデザインのソフトはフルタイムで働くエンジニア達によるクローズドな商用ソフトにあるという事実を覆すに至っていない。

つまり、「商用ソフトの方が(進歩が速いので)ベストの追求に向いている」であり、 「オープンソースには良いUIのソフトウェアが作れない」ではない。 そのように読み取るのは「ベストの追求こそ全て」のウサギの論理に巻き込まれることになってしまう。

_ [家族]長男誕生日

先日の私の誕生日に続き、息子の誕生日が来る。

彼はプレゼントをもらったり、おいしいものを食べさせてしまってご満悦のようだ。 しかし、疲れてしまったのか、レストランへの移動中に寝てしまい、 帰宅後も、そのまま布団に直行であった。

_ [メール]噂のGoogleの1GBメールサービス「Gmail」を最速レビュー！

Gmail。なかなか面白そうだが、

• 日本語が使えるかどうか分からない
• ソースが入手できないからカスタマイズ性に不安
• ネットワークにつながってない時は使えない

などの制約から、自分で使うのは難しそうだ。

しかし、ふと考えたら、私のノートでもディスクは1G以上残っているという事実に気がついた。 最近のディスク容量から言えば珍しいことでもなんでもない。

にもかかわらず私が過去10年のメールの全てをもっているわけではないのは、 ただ単に、私が使うソフトウェアが1Gメールに対応し切れないからだ。

であれば、新しく作るのはどうだろう。

1Gものメールであれば、フォルダに分けるというのはあまり現実的ではない。 基本は検索になるだろう。

• 高速インデックス化
• キーワード検索
• 似たもの検索
• 仮想フォルダ

などがベースになるに違いない。とか考えると、 この記事で紹介している Gmailのインタフェースというのは、よく考えられているような気がする。

誰か開発(に参加)したい人はいますか？

_ [教会]訓練集会

監督・長老定員会訓練集会。 講師を仰せつかったのだが、1時間に3人の講師から詰め込まれるのも大変な話だろうなあ。

_ 観測問題

抽象的な話だが。

地理的に拡散している、ゆるく連携された組織に対して、さまざまな戦略を考案する。 あるものは効果があり、あるものは効果がない、かもしれない。 あるものは末端では実行に移されず、有効性を発揮できないかもしれない。

効果があるかどうかは測定しなければ正確には判定できない。 その効果を測るために、たとえばアンケートを取る、 インタビューをするなどを方法をとることができるが、 それにはコストがかかる。場合によっては戦略をだいなしにするかもしれない。

さて、その有効性を損なわずに測定する良い方法はあるかないか。

うーん、ケースによって違うとしかいいようがないな。brain fartか。

_ [OSS]SCO問題

kouさんのツッコミから。

あと、バザールの基本は好きな者に好きなようにつついてもらう点だと思うのですがSC○みたいなのに粘着されてモチベーション下げるような事も避けたい所ですし。

SCO問題は、Linuxが主題になっているのでオープンソース問題であるかのようにとらえられがちだが、 実際にはオープンソースとはまるで関係ない。彼らの主張は法廷と法廷外で全く違う点に注目する必要がある。

法廷での彼らの主張はこのようなものだ。

IBMはSCOとの契約に反して、SCOが権利を持つUNIXに含まれる技術をLinuxに持ち込んだ

つまり、その本質は「契約違反」である*1。 それは真実かもしれないし、そうでないかもしれない。 が、少なくともこの論理ではSCOと契約を結んでいないものは関係ない。 そもそも契約を結んでいないのだから、契約違反は発生しえない。

つまり、たまたま訴訟の一部に(オープンソースソフトウェアである)Linuxが関連しているという以上には、 この訴訟とオープンソースソフトウェアは関係がない。 これはオープンソースでない他のソフトウェアでも発生しうる問題だ。

ところが、法廷外ではSCOは

LinuxにはSCOが権利を持つコードを含んでいる。 だから、その権利によってLinuxを利用するためにはSCOとライセンスを結ぶ必要がある。

でなければ、(IBMのように)訴えるぞ。

とほのめかしたのである。みごとなFUDだ。

こちらの主張が真実である可能性はかなり低い。 迷惑な話だが、上のような「ほのめかし」程度では罪になるとまでは言えないような気がする。 粘着されるのはたいへん迷惑な話であるが、オープンソースが世間的に注目されるようになると、 なんらかの攻撃の対象になるのは避けられないことのような気がする。

静かにほそぼそとフリーソフトウェアを開発していた頃は平和だった。 が、それで飯を喰える状態ではなかった。

オープンソースが注目される今は、飯は喰えるが、粘着される危険性は高くなった。

なかなか、万事うまくいくとは行かないものだなあ。

_ [OSS]沢山の目

続いてkouさんのツッコミの前半から。

つい最近こういう記事もありました。
>「UNIX開発者のバックドアを思い出せ」−Linuxの軍事利用に警鐘
><URL:http://www.itmedia.co.jp/enterprise/0404/14/epi04.html>

この記事を読んで思ったことは、Eric Raymondが語った「沢山の目があれば、どんなエラーも恐くない」*1という言葉は誤解されているということだ。

もちろん、ソースコードが公開されていて、チェックすることができる人がたくさんいれば、 バグは早く見つかるし、対応も速い。

が、だからと言って、どんなにレビューアーがいようと、何人開発者がいようと、 ただそれだけでは、問題が発生する前にバグが発見されるなんてことは決してないということだ。 Ken Thompsonがバックドアを仕込んだ経緯は知らないが、 そのバックドアは14年間決して利用されず、問題は発生しなかったのだろう。 よって積極的にはチェックは行われず、発見もされなかった。

オープンソースの良さは、問題が起きちゃったらすぐに対応できる点だ。 一度でも問題が起きたら困るケースで、 問題が発生する前にバグを発見するためには、地道なテストスイート作成と 繰り返しテストすること、積極的なコードレビューが必要だ。 それはオープンソースだろうとそうでないソフトだろうと同じこと。

さて、ITmediaで紹介されていた。「ダン・オダウド氏」なる人物の主張は

• Linuxは「誰でも」コードをcontributeすることができるので、 信頼できないコードが組み込まれるかもしれない。
• Ken Thompsonの例からも言えるように、ソースコードがあるからといって信頼できるわけではない。
• よって、Linuxを軍事関係に利用すべきでない。

前二者には限定付きで同意できないことはない。 確かに、アメリカと利害関係が対立する人物がLinuxにコードをcontributeして、 そのコードに発見しにくい巧妙なバックドアを仕掛ける「陰謀」が存在する余地が まったくないと断言するのは難しい。

もっとも、そのためにはバックドアは

• 発見されないくらい目立たない(できれば小さい)コード
• かつ、意図が分からない程度に複雑

という相反する要求を満たし、 かつバージョン管理でそのコードがいつ誰によってコミットされたかが明らかになる危険性をかいくぐる必要がある。 もちろん、天才的コーディングでバックドアを用意し、 バージョン管理サーバーもクラックするのだろう。映画みたいだ。

そのような危険性があるので軍事関係にはLinuxを使わないとする。 だとしても私はいっこうに構わないのだが、仮にLinuxを使わないのだとすると、 代わりになにを使うべきか。「安全だと立証されたソリューション」とはなにか。

Windows? Solaris? AIX?

上記の困難を乗り越えてLinuxにバックドアを仕込むという 陰謀説を信じることができる人が、WindowsやSolarisなら大丈夫と言える感性が私には不思議だ。 アメリカ企業たるMicrosoftによって作られているソフトウェアなら安心ということだろうか。 私には、ロシア人開発者よりもマイクロソフトの方がよっぽど野望を持ちそうに思えるのだが。 第三者が検証することは事実上不可能だし。

たいへん(アメリカ的)愛国心のある話ではあるが、論理的ではない。

あるいは「安全だと立証されたソリューション」とは、 身元がはっきりした人間だけを用いてコンピュータは使わないことか。 論理的だが、現実的ではない。

いや、身元がはっきりしているはずの人間が内通者になるのはスパイ映画では常道だ。 誰も信じてはいけない。安全などないのだ。Trust no one.

追記:

KLさんのツッコミによれば、

「安全だと立証されたソリューション」...というのは、Green Hills SoftwareのOS(フットプリントがLinuxに比べ極めて小さく、ソースコードは米航空連邦局の監査をパスしている)ということになります。

だそうだ。うーん、それならそれで論理的ではあるが...。

ということは、軍事目的のOSはすべてそのような小さなOSしか使うなって主張なのかな。 論理的ではあっても、非現実的ではないかなあ。

_ [会社]オープンソースソフトウェア活用基盤整備事業ヒアリング

1次審査を突破して、ヒアリングへ。 東京出張。なんだか久しぶり。

前夜徹夜までして資料を用意してくれた面々のおかげで、 プレゼンテーションはそれなりにできたのではないだろうか。 前回よりも準備しただけあって、やはりあわてることなく質疑に対応できた気がする。

びっくりしたこと: g新部さんが向かいに座っていたこと。世間は狭すぎ。

IPAの担当者によると、応募は５０件ほどだったそうだ。 あまり多いと競争が激しくなるので、気持ちは微妙だが、 正直なところもっとたくさん応募があってよいと思う。 せっかくのチャンスなんだし。

今年は秋にも公募があるので、 チャレンジしてみてはどうだろうか。

その後、秋葉原によって、前田くんとおなじく HDD外付けケースを購入。でも、うまくいかないところまでおんなじだったりする。

今までジャンクでもたいていうまく動いていたのだが、初の惨敗か。

_ ２６歳のハローワーク

AERA 4月5日号の記事から。

この記事を読んだ当初の感想は、普通のオジサンが持つであろうものと同じ、 「勘弁してくれ」というものだ。 今ここにある自分を無視して、どこにもない「本当の自分」を探す姿は滑稽でさえある。 『青い鳥』でも読んでくれ、と言いたい。 ただ、そういう感想はこの記事を書いた記者の期待通り、あるいは思うつぼであろうとも思う。

しかし、この記事中のある一節

一方で、そのままでいいと言われても、いまの自分はまだ何者でもない。焦燥感もある。真のオンリー・ワンになる道は、ナンバー・ワンになるよりはるかに険しいこともわかっている。

を読んで、

「真のオンリーワン」なんてものは結局ナンバーワンのことだ。
そんなこと言ってる人は「オンリーワン」のことが分かってない

と語った妻の言葉を聞いて、このことについて改めて考えてみた。

確かに。「真の」とわざわざ強調する以上、「他に同じものがないくらい飛び抜けた存在」になることを 想定しているわけで、そのような存在になるためには他との競争を勝ち抜いて 「ナンバーワン」になる必要ありそうだ。

けれども「オンリーワン」という言葉は、

• 世の中の人は一人一人異なっている
• だからそのままでいい
• 競争しようという発想そのものが不要

ということを伝えようとしているのではないだろうか。 「速いことを至上とするウサギとは違う生き方がある」と言い換えてもよい。 要するに、この記事を書いた人物は世の中に蔓延する「ウサギの論理」から自由ではなかった、 ということなのだろう。

勝つものがいれば負けるものもいる
負けたものはどうなる
負けたものには生きる権利はないというのか

考えてみれば、一握りの勝者以外はみなある意味敗者である。 勝者だけを目指す世の中は圧倒的多数が不幸な世の中ではないか。

とはいえ、競争社会を完全否定するつもりはない。 我々が目指すべきは、全力疾走で消耗することなく 地道に進み、最終的には勝利してしまう「カメの生き方」ではないだろうか。

というようなことを、Mozilla.Partyでの末松教授の言葉を読みながら考えたのだった。やっぱカメでいいわ、私は。

_ [生活]地域差を利用した生き方

元ネタはCNET Japanの梅田さんのコラム。

生活コストの高いことが前提の「大都市圏標準サラリー」を稼ぎ、生活コストの安い田舎の小さい町に住むことで、2つの世界のいいとこ取りをしよう、というのがGeographic Arbitrageである。

しかし、別にこの生き方は新しいものでもアメリカ特有でもない。 日本でできない理由はないし、実践している人も多いだろう。 事実、私はずっとそうしている。

鍵は「ふたつの世界のいいとこ取り」である。

まず、第一に仕事である。地域性に限定された仕事では難しい。

日本だけじゃないと思うが、田舎は住環境、生活コストその他で恵まれている (たとえば、今のうちは3LDKで共益費、駐車場2台分込みで8万だ)。 一方、産業に乏しいことが多いので、地元ではなかなか仕事はない(ので高給に恵まれない)。 環境が豊かでも収入が厳しければ「いいとこ取り」ではない。

しかし、「IT革命」ばんざい。すべての職種とは言えないが、 ソフトウェア開発に限って言えば、いまや地理的な問題はかなり少なくなっている。 電子メール、FAX、IRCなどを活用すれば、開発作業のほとんどは地理的な制約を受けない。 以前は情報が遅いのが難点だったが(松江は今でも雑誌の発売日が二日遅い)、 インターネットのおかげで最新の情報が自宅で入手できるようになっている。

理屈から言えば、会社としては開発者がどこにいようが、きちんと仕事を果たしてくれれば、 貢献に対する報酬として同じだけの額を払うのは当然である。都会地手当てのようなものを除けば。

であれば、あと必要なものはなにか。

実はそういう働き方を理解してくれる文化や会社だけのような気がする。 いずれにしてもソフトウェア開発職は他の職種に比べてチャンスが多い。 サポートや営業ではなかなか難しいだろう。

あきらめずチャレンジするのはどうだろうか。

_ [OSS]yaccの弱点

スラッシュドット・ジャパンで私の日記が参照されたらしく、 プチ・slashdottedである。で、とんびさんから受けたコメント。

>bisonのpure-parserはlexer用にデータを渡せないので、役に立たない。
とありますが、YYPARSE_PARAMとYYLEX_PARAMを定義したのではだめですか。ていうか、これつかって、すっかりreentranthなparser作ったつもりでいたのですが。テストしないとやばいかな。

ダメじゃないです。白状すると1月14日の時点ではYYPARSE_PARAMなどについて知りませんでした。 気がついたのはProthonのソースを読んでた時ですから、 3月の後半くらいでしょうか。

唯一の難点はbisonのinfoを見ると

Macro YYPARSE_PARAM

An obsolete macro for specifying the name of a parameter that `yyparse' should accept. The use of this macro is deprecated, and is supported only for Yacc like parsers.

とあることですかね。「obsolete」と言われても、代替手段がないんですが...。

_ [家族]また送別会

両親の任地も決まり、これで本当に最後だとみなが集まった。

留守の間うちをどうするかとか、お墓の当番だとか雑多な話をした後、 色紙にメッセージを書いて、贈呈する。

しかし、浜松だとはなあ。

最後に全員で墓参りをして解散。

_ [教会]倉吉支部大会

恒例の支部大会。 載っていた車が縁石にこすってしまい傷がつくというアクシデントがあった他は順調。

今年も神権会のレッスンは私が担当。 「精神面、物質面での自立」という難しいテーマであったので、 「職業」という側面を強調して話してみた。

使った聖句

• 創世記 3:17-19
• ヨハネ 5:17
• マタイ 6:24
• ヒラマン 13:22
• マタイ6:33
• 出エジプト 20:3
• アルマ 34:24
• 箴言 6:6-8
• 箴言 6:8-9

しかし、今思うともっと「自立」に焦点を当てて、 みなの意見を引き出すようなレッスンのほうがよかったなあ。 50点。

_ [生活]掃除

新居の掃除、および諸事の片付け。ガスの点検、ウッドカーペットの搬入、BSアンテナの取りつけなど。 午前中いっぱいかかってしまった。しかし、それだけで疲れ切ってしまったぞ。

夜には契約関係の処理もすませる。いよいよ引っ越しの準備が整ってきた。

_ [OSS]yaccの弱点(その2)

yaccの宣言的な文法は条件が書けない。 「この条件のときはこのルールを適用しない」というような文法はありえない。

まあ、LALR(1)の性質を考えればある意味当然なので、これを弱点というのは適切ではない。 より正確には「弱点」ではなくて、せいぜい「要望」とか「欲求」とかだな。

とはいえ、 Rubyの文法には「ifなどの条件式には任意の式が書けるけどdoが来てはいけない」とか、 「メソッド引数には任意の式が書けるけどコンマを含んではいけない」のようなルールが存在する。 これに対応するためには、

• すべてのルールを展開して、doが出現しうるものとdoが出現しないものの両方を用意する(コンマについても同様)。
• lexerに手を回して予約語doに対して違うトークンを返すようにする。

前者はルールの数が増える(単純計算で4倍)ので、メンテナンスの手間がかかる。 一つのルールを修正するために、 常に4箇所(あるいはそれ以上)を更新する必要がある。あんまりだ。

現在のRubyの実装は後者を使っているのだが、 これもlexerとparserが無闇に強結合するため、メンテナンス性に問題がある。 また、yaccルールだけで文法が理解しにくいのも欠点だ。

私の知る限りでこんな無茶な要求に対応しているcompiler compilerは存在しない。

再帰下降の手書きparserなら、こんな挙動も簡単に実現できる。 「条件式フラグ」や「メソッド引数フラグ」を再帰関数の引き数のひとつに渡せば良い。 しかし、再帰下降parserもメンテしにくいことで知られているんだよなあ。

結局どれでもメンテしにくいんだったら、どれを選んでも同じってことかなあ。

_ [会社][OSS]転職物語

かずひこさんがディスクロージャされたようだ。

まつもと(とNaCl)はオープンソースにかかわるというかずひこさんの人生の選択を応援します。 また、その他の多くの人が自分の希望に沿った人生を歩むことができるようお祈りします。

転職物語なんてページも出来つつあるようです。 そういえば、私も過去の転職の時には右往左往したもんだなあ(遠い目)。

今は引っ越しひとつで大騒ぎ。

_ [OSS]yaccの弱点(その3)

shiroさんとakrさんから「ANTLRならできる」との指摘が。

しまった、例によって調査不足であったかANTLRはJavaが必要なので避けてたんだよなあ。 btyaccについても十分理解してなかったし。

まあ、ツールが使えるなら手書きの再帰下降パーザよりはマシか。もうちょっと腰を据えて調べてみるか。

_ [TV]“北風より太陽”によって米国でデジタルコンテンツとPCが栄える?

インプレスPCウォッチの「後藤貴子の米国ハイテク事情」より。

要するに厳しいDRM(Digital Rights Management)を採用した日本より、 緩いDRMを採用したアメリカの方がコンテンツ産業が反映するのではないかとの予想。

心から賛同します。

地上波デジタル放送がこのまま計画通りに進んで、 2011年に地上波アナログ放送が予定通り終了したら、 その時私はテレビを卒業します、きっと。

ただでさえテレビだけからしか入手できない情報はどんどん少なくなり、 少ししかないそのような情報の魅力もどんどん下がって、 テレビを見る時間は減る一方なのに、 この上、コピーワンスを強要されて面倒なことになれば、 もうテレビの価値はないです。 DRMの必要性を否定するまではしないけど、コピーワンスがデフォルトはやりすぎ。 そのためにテレビを買い替えるとか、チューナーを買い足すなんて馬鹿馬鹿しい。 あと、7年あったらインターネットが十分代替になると確信します。

その時うちのテレビはビデオとDVD(と将来登場する何か)のプレイヤーになることでしょう。 それでも十分だと思う。

「角を矯めて牛を殺す」ってのはこういう時に使うんだっけ。 「金のガチョウ」の方が適切か。

_ [言語]Babel

おお、前田くんのBabelが単なるSatherコンパイラから進化しようとしている。すばらしい。

私は前者(ネストしない方)が好きです。namespaceの粒度にもよるけど、 きっとかなり大きくなるんじゃないかと思うので、 実質的に無用なネストは増やさないほうが良いのでは、と思います。

_ [生活]引っ越し

引っ越し当日。朝から運送屋がきてどんどん箱詰めしていく。

私は子供たちと新居に移動して、掃除と片付け。 子供たちは自分のものになる部屋の掃除、雑巾がけ、板床へのワックスかけ。 その後も、新居と旧居を移動しつつ、どたばたと。

予定では5時には終了するつもりであったが、 実際には旧居の荷作りだけで5時までかかり、 新居にすべての荷物が移動したのは夜も8時を過ぎていた。 見積もりが甘いのはどこの業界も同じらしい。

今回の引っ越しの反省点。

• すぐに必要になるものは自分で運ぼう。
• すぐに必要になるもの: 工具、包丁
• リモコンもどこに行ったか分からなくなりがち

しばらくは箱の中で生活することになりそう。

_ [生活]テレビ

子供たちは学校に。私は休みをとって片付けを。 しかし、一向に片づかない。全然箱が減らないよ。

テレビが映らない。屋根に登ってアンテナ線をつなぎかえたりしたが、 あまり効果がない。いろいろ調べた結果。

• 一戸建の場合BSアンテナに電源を供給する必要がある。 テレビのメニューから電源供給を選択。
• 新居は山の陰なので、松江からの電波は届かない。 チャンネルを中継局のものに合わせる必要がある。

ものを知らないことを露呈してしまった。半端な知識が一番役に立たない。 電器屋さんには迷惑をかけた。