カナダ経由だったので、入国審査のときに
10日以内にトロントに滞在した人はこちら
などと言われたりしてた人もいたが、なんとか無事帰国。
岡山経由松江行きの指定席も手配し、うちに電話してから、新幹線に乗り込んだ。 まもなく新幹線が発車し、アナウンスが聞こえた
東京行きのぞみに乗車いただきありがとうございます。
がーん。なんと反対方向ののぞみに乗ってしまったのだった。ばか。
慌てて次の停車駅、京都で降りて、下りのひかりに乗り換える。 しかし、すぐそばの京都で止まってよかった。これで名古屋までノンストップとかだったら、 リカバリのしようがないよ。
で、結局岡山発の次の特急で帰れたのだが、伯備線の特急は1時間に一本しかないのにもかかわらず、 時間の関係で30分遅れだけで済んだのは不幸中の幸いであったろう。
いや、連絡がつかず30分待たせてしまった妻と子供には悪いことをした。
やはり国が違うといろいろ細かいところが違うのだが、今回の旅行で気づいた小さなこと。
ご存じの通り、日本の歩行者信号は、
青→青点滅→赤
と変化するのだが、アメリカの歩行者信号は
青→赤点滅→赤
と変化する。日本の信号が「急いで渡れ」という暗黙のメッセージを送っているのに対し、 アメリカの信号は「そろそろ危険だ」というメッセージを送っていると感じた。 いや、アメリカの信号の方がうっとうしいのだが、目的はよく果たしていると思った。
アメリカは左ハンドル右側通行なので、右折の方が曲がりやすい。 で、交差点はデフォルトで常時右折可なのだそうだ。
つまり、正面の信号が赤でも人や車が来てなければ曲がってもよいということ。 交通量が多く、危険なところでは「右折禁止」と書いてある(もちろん英語で)。
これも合理的....なのかもしれない。
公衆電話の受話器を取るとコインを入れなくても「ツー」と音がする。 ダイアルしてつながると課金されコインが落ちる。
これは変わってる、と思ったのだが、帰国してから使ったグレーのISDN公衆電話は同じ動作をした。 ただ単に私が遅れていただけらしい。
あと、公衆電話といえば
というのも印象的。特に後者は「ああ、映画で公衆電話が鳴るのはそういうことか」と納得だ。 古くは『ダーティハリー』、最近だと『スピード』で鳴ってたよね。
『スピード』は全然最近じゃないか。
Mr.orzによるツッコミが理解できていない。
>「メンテナが望まないフォークが発生して、互換性を維持できなくなったケース」
正確には、メンテナ→オリジネータですね。
で「かつてあったか」→少なくとも著名なケースはない（と思います）
「今後あるか？」→可能性としてある以上、企業としては何らかの対策が必要かと（でないと経営責任になる）
いや、オリジネータから引き継がれている可能性もあるので、メンテナで良いでしょう。
さて、互換性が維持できない可能性があるということであるが、 いったいどういう事態を想定しているのか想像ができない。おそらくは私の想像力が貧困なのであろうが。
「可能性を否定する」のはなかなか難しいので、 日本が沈没する可能性も、私が明日バスに轢かれる可能性も否定できない。 明らかに予測可能な事態に対策を行わなかった場合には経営責任になるだろうとは思う。 きちんとした企業では飛行機が落ちても大丈夫なように経営陣を複数の便に分散させるということだし。
しかし、ここでMr.orzやその他の方々が「予想している可能性」とは、具体的にはどういう事態なのか。
時々発生する「互換性の低い互換品」問題はオープンソースとは直接関係がない。
既に述べたが、注目を集めるプロダクトには互換品が登場することが多い。 IBM汎用機、インテルx86プロセッサ、NEC PC98、Microsoft Office。 場合によっては特許、商標、ライセンス、不当競争防止法などで疎外できることもあるが、 いつも互換品を留めることができるとは限らない。
互換品が登場した場合、差別化のためなんらかの差異が加えられることが多い。 性能や価格など互換性に問題のない差別化であれば問題はないが、 しばしば新機能(たとえばAMDの3DNow!)だったりして、 プロセッサによって動いたり動かなかったりすると悲しいことが起きる(こともある)。
あるいは互換性が不十分で問題が発生することもある。 これは単なる努力不足であろうけど。
さて、オープンソースであった場合、この互換性問題はどうなるか。 変化するのか、しないのか。
まず、オープンソースであるので、その定義からソースコードが自由に利用可能で、 かつ、修正したものの再配布が可能である。 これだけを見ると、ちょっと修正した非互換なソフトウェアが蔓延し、 互換性の保証を行うことが困難になる可能性を感じるのかもしれない。
しかし、そんなことは起きない。
あるソフトウェアAが存在し、なんらかの事情により、そのソースコードを改変した 「似ているが非互換」なソフトウェアBとCが登場したとする。 オープンソースライセンスでは(たとえLaTeXライセンス1.3を利用したとしても)、 これを禁止することはできない。
しかし、BやCをオープンソースにすること、BやCがAを起源にすることと、 またBやCがAに対してどのような修正を行ったか明示することを求めることは可能だ。 実際、GPLをはじめ多くのライセンスはそれを要求している。
であれば、もしBやCがAに対する差別化を目標としていても、 Aと、BやCの区別を明確にすることが可能であれば、 ユーザにとっては通常の互換品との差はまったくない。
開発者にとってみれば、 BやCがどのような変更を加えたかの開示要求が可能なので、 差別化を目指したBやCの良いものはAに取り込んでもよし、 そうでなければ放置してもよい。 取り込むかどうかの選択権がAにあるぶん、 通常の互換品よりも望ましい事態とさえいえるかもしれない。
というのが私の感じるところなのだが、Mr.orzが
GPLがフォークについての懸念を法的処置してないのに対して、たとえば、LaTexライセンスあたりはうまく処理していると思います。また昨年１２月リリースのモノはデキもいいし。
とおっしゃる真意はいかに。
私はGPLがフォークについて扱っていないのは、 そもそも懸念でないからだと思っている。 LaTeXライセンス(1.3)については、私にはOSD準拠にみえるが確証はないし、 GPLコンパチかどうかも(まだ)明確でないわけだから、 かえって(別の)リスクが高いのではないかと思っている。
ソースは公開するが改変についてはライセンスで一定の歯止めをかける（原則改変自由だが、不合理な非互換フォーク※を避ける）というのは可能です。
※わたくしは、非互換でも合理的なversion-up なら「やむなし」という考えです。
これも具体的なイメージが湧かない。 禁止したい「不合理な非互換フォーク」や、「やむなし」である「合理的な非互換version up」とは、 誰による、どのようなものなのだろうか。
Estraierで関連検索をしようと思えば、あらかじめestindex relateを実行しておく必要がある。
しかし、ソースを見る限りではこれは別にバッチで行う必要はなさそうだ。 ある文書に対して関連検索を要求された時にはじめてoddocscores()を呼び出し、 重要キーワードを得てから、 それらキーワードを(OR検索で)含む文書に対してふたたびoddocscores()でキーワードを取得して、 それらのベクトルの比較を行えば、eagerにスコアを求めておく必要はない。
ということで、estindex.cを切った張ったして、30分ほどでオンデマンドにスコア計算をする(_scoreに結果を保存する)コードが完成した。estindex relateを実行しなくてもキーワード抽出や、関連検索が動いているみたいだ。
ということで、平林さん、いかがでしょう。次期Estraierにはオンデマンドスコアリングを導入してみては。 ただ、_dateデータベースを更新してないんでなんかまずいことが起きるかも。
「二兎を追うものは一兎も得ず」ということわざがあるが、 まさにその通り。原稿と講義の準備の二兎を追おうとすると 逃避行動の時間が突然増加するのはなぜだろう。
逃げているからです。
このままではどちらもマズいことになりそう。
逃避行動のハックは進む。 今日はMorqのRast対応が完了した。今まではEstraierとの二本立てだったが、 もうRast一本に集約することにした。 統合が終われば、最初からmorqで使うことを考慮して開発してもらったRastの方が ずっと使いやすい。高速だし、属性検索はできるし。
ありがたいのは、
というような検索条件ができるようになったことだ。 今までは単語単位の検索しかできなかったからね。
便利になったのはうれしいけど、「今日までにどうしても必要」という話はなくなったみたい。 じゃあ、予定通り来週作業にすればよかったのか。原稿やらスライドやらをうっちゃって作業したのに。
いや、短に逃避してただけか。
36時間くらいかかって900MBのメールを取り込み終わった。
が、その直後、データベースに間違いがあったことが判明。 インデックスの日付の形式が間違っていた。
やりなおし。がーん。
しかし、今度は雄也くんに聞いて、データベースをフラッシュする頻度を下げる。 これでメモリを消費して、時間を節約できる、はず。
なんとか講義のスライドは書いたけど、 2日フルの講義なんかしたことないから分量の感覚が掴めない。 全然足りないかも。
東京へ移動。筑波で講義が終わってから羽田に向かうのでは、 出雲便の最終には間に合わないことが明らかなので米子から出発。 うちからだと米子は遠いのだがしかたがない。
しかたがないついでに実家に寄ることにする。 妻と末娘もいっしょ。彼女らは電車で帰宅する予定。
思わず昼食までご馳走になってから東京へ。
東京では会議。
現在進んでいるプロジェクトの反省とか、 今後の案件処理についてどうするか、とか重い話。
正直もっともめるかと思っていて、最悪のことも予想していたのだが、 予想外にスムーズに議論が進み、かなり前向きな結果が出た。 まあ、それは良いことだと思う。
会議終了後、やや遅い(東京オフィスの人たちには遅くないらしい)夕食を食べてから筑波へ。
つくばエクスプレスに全区間乗るのは初めてだが、快速で45分は快適だ。 すっかり「住み心地の良い町」になってしまったな。 私のころは都心からの適度な距離感がかえって快適だったのに。
ホテルでスライドの直しと日経Linuxの原稿書き。
IBMの学生向けイベント。
中原氏は今回のイベントについて「作られたものを使うという意識から“創る”ほうに意識を向けてほしい」と話している。
...
突き詰めて考えると、ソフトウェア技術の空洞化は、人材の空洞化にも通ずるところがある。そこで、次代を支える人材を育成する手段として、ソースコードから触れることができるOSSが注目されるのだ。近年ではFirefoxやTunderbirdなどの登場もあり、確かに一昔前と比べると、一般ユーザーでもOSSに触れる機会は増えた。しかし、日本におけるオープンソースコミュニティーを見ると、若い人が活発に活動しているという様子があまり見られない。もちろん、若い開発者がいないというわけではないが、名前の挙がるような人物は数年前から何も変化していないという気がする。VA Linuxの佐渡秀治氏も以前、日本特有の傾向について語っていたことがあるが（関連記事参照）、比較的オープンなはずのオープンソースコミュニティーであっても、なぜかクローズドなものになりがちな傾向がある。
一方、学生の現状について、「今の学生はスマート」と中原氏は語る、リポートを書かせると、Googleをはじめとする検索エンジンをたくみに活用するなど、「道具」としてITを使う術は冴えているという。単純なコーディング能力も高いと推測される学生たちに欠けているのは、独創性や将来へのビジョンではないかと指摘する。
「モノ作り」重要。
先日、Rubyをインデントブロックにするプリプロセッサを紹介したが、 今度はPythonでブレースで使うもの。
秀逸なのは、プリプロセッサをcodingプラグマで起動するアイディア。 普通のPythonプログラムの先頭に
# -*- encoding: braces -*-
を加えるだけでブレースによるブロックが使えるようになる。なんと。 今度はエンコーディングが指定できなくなるけど。
えーと、新人(中途でも)うまく適合できなくて、 お互いに不幸な事態はしばしば発生するが、 メンタリングでそれが解決できるならば、それに越したことはない。
まだ初回だけど、今後も読まなくちゃ。