Matzにっき
2005年02月01日 [長年日記]
_ [家族] 学級閉鎖
寒いと思ったら雪が積もっている。インフルエンザもはやっているらしく、 次女と長男のクラスは学級閉鎖。長女はちょっと不満げな顔で登校。 もっとも自宅に残った子らも外出禁止なのでうれしいわけではない。 まあ、流行拡大を避けるためには当然の処置であろう。
しかし、考えてみれば社会人は風邪引いても仕事休めなかったりするわけで、 企業でのインフルエンザ拡大とかは現実的な脅威だったりしないんだろうか (うちの会社の連中は(よっぽど仕事が煮詰まってない限り)ちゃんと休みます)。
_ 『スモールコンパイラの制作で学ぶプログラムのしくみ』
4774121770 昨日、本屋に立ち寄ったら目に止まった。 恩師(中田育男先生)が監修していらっしゃるし、 価格も手ごろだったのでレジへ。 と思ったら、財布にお札が一枚も入ってなくて、あわててカードで購入。
教え子としては朝倉書店の『4254121393』も購入すべきなんだろうけど、ちょっとお財布にやさしくなくて(実は脳にもやさしくない)。
で、今日になって雪降る午前中に読んでみたら、なかなかよろしい。
文系出身で法政大学の大学院、IT Professional Courseに入学した著者は、
中田先生の「コンパイラはコンピュータサイエンスの基礎である」という言葉に
だまされて惹かれてコンパイラをテーマに選び、
とうとう1年で携帯電話で動く小さなコンパイラを作り上げるところまで到達したという。
本書はその彼女が文系の視点でコンパイラの本を書き上げたのだそうだ。
1章は「たとえ」をつかってソフトウェアの働きについて解説しているのだが、 これはまさに私が書きたかったアプローチだ。某出版社から企画を通すところまで行ったのだが、 時間が取れずとても書けなかったので私の方からキャンセル。残念だ。
2章以降はJVM上で動作するCell言語のコンパイラとインタプリタ(VM)を作っている。 これも(別の本で)書きたかったテーマだ。 Rubyは元々書籍の解説用言語としてプロジェクトが始まったことを知っている人はもはや少ないが、 『(言語を)作りながら学ぶオブジェクト指向プログラミング』というような本になるはずだったのだ。 あまりにも売れそうにないので早々にキャンセルされたんだけど。
というわけで、「まつもとに(才能が足りなくて)書けなかった本」の片鱗がここにある、ということで。 言語に興味のある人は眺めてみて損はない本だと思う。他の中田先生の本よりもずっとやさしいし。
_ [特許]ジャスト「一太郎」の販売中止を命じる 松下アイコン訴訟で判決
また、えーっというような判決が出た。この特許の内容は
「アイコンの機能説明をさせる第1のアイコン」をクリックしてから第2のアイコンをクリックすると、第2のアイコンの機能説明をしてくれる処理
である。
こんなの誰でも思いつくんじゃない？ こんなアイディアを本当に保護する必要があるわけ？
更に、こんなのに対して「製造・販売の中止と製品の廃棄を命じる判決」というのは、ちょっと。
ジャストシステムには、ぜひとも高裁まで争って逆転していただきたい。 また、私は当面、松下(Panasonic)の製品を買いません。 長らくLet's Noteユーザでしたが、今はIBMだし。
しかし、私の懸念はこれだけではない。松下がこのような「特許闘争」を行う企業体質だとすると、 いつの日か彼らの持つ特許2945753号、2982752号、2982753号を「行使」して、 日本を大混乱に陥れないとは限らないということだ。
いや、待てよ。
それで特許の「問題」がクローズアップされればむしろ望むところなのか？
だとすれば「Matzにっき」は松下電器産業を(普通とは違う意味で)応援します。
追記
いくらなんでも「応援する」は不謹慎だと思うようになった。 訂正したい。
2005年02月02日 [長年日記]
_ 気温
昨日からえらい寒くて、大変。雪は積もるし道は凍るし。
私のうちは坂になった路地の奥にあるのだが、道が凍っていて上れない。 スタッドレスがすり減ってるのかな。とりあえず坂の下に駐車させてもらう。 こんなことで明日のデブサミに行けるのか。
_ デブサミ2005
ちゅーわけで、出席が危ぶまれていないこともないデブサミですが、 今朝の飛行機は飛んだらしいので、明日も大丈夫だと期待するものです。
食事に参加表明を出してくださる方が複数いらっしゃったので感謝しています。 デブサミに参加される方々は、 私たちのセッションが終わった直後に声をかけてくだされば、そのまま移動できると思います。
参加されない方は...、どうしよう。参加する人にコンタクトを取る？
どなたか会場を決めていただけませんか。 新宿(かずひこくんの宿)または新橋・銀座(私の宿)の近くが希望です。
_ [OSS] オープンソフト開発支援の法律センター開設
OSDLがオープンソフト開発を法的に支援する法律センターを設立するという話。
現在OSSにとって必要とされている支援は(経済的な援助を除いては)このようなものではないだろうか。 日本でこのようなものを作ることは可能なのか。
_ [OSS] エリック・レイモンド氏がOSI代表を降板
ま、ひとつの時代が終わり、次のステージに移ったということで。
_ [言語] Nokia、アプリケーション開発に『Python』言語を追加
Nokiaの携帯でPythonアプリが動くという話。
こういう点はRuby(やPerl)と比較して明らかにPythonが優れたところだよな。
_ [言語] Tao Language for Scripting and Computing
新言語。オブジェクト指向スクリプト言語なのだそうだが、どこが目新しいかはよくわからない。 ライセンスはGPL。
_ デブサミ2005・追記
やっぱり関係者の立食パーティがあるそうです。
実際は私はそれはどうでも良いのですが(かずひこくんは「関係者」ではないし)、 その後、風穴さんから「一緒に食事しないか」と誘われています。 「立食よりマシなものが食べたい」んだそうです。
せっかくだから風穴さんも誘いたいんですが、 デブサミ参加者のみなさん、しばらくなら待てますかね。
ううっ、なにもかもこんなにぎりぎりに話が来なくてもいいのに...。
多数が読んでいる日記でこんなにプライベートな話はどうか、とも思いましたが、 考えてみたら、普段から「私が車をぶつけた」というような思いっきりプライベートな話が満載でした、この「Matzにっき」は。
_ [特許] ITmediaニュース：「一太郎」判決の衝撃
まとめ記事。でも、「たとえ新規性があっても特許は無効」という意見はないようだ。 私の暴走なのかな。
ところで、2ページ目、
判決を受け、著名なプログラマーが松下製品の不買を表明するなど、開発者サイドにも波紋が広がっている。
の「著名なプログラマー」って、もしかしてもしかすると私のこと？
いや、自意識過剰かな。他にも不買表明した人いそうだものな。
2005年02月03日 [長年日記]
_ おわび
先日来のアクセス増加のため(スラッシュドットの影響が大きいらしい)、 昼休みや深夜などには負荷が高くこの「にっき」をはじめ boron.rubyist.net 上のたくさんのページが閲覧できないことがあったようだ。
調べたら日に何度もロードアベレージが30とかになっている。まあ、boronはもともとかずひこくんのマシンだったものをrubyist.netやmodruby.netなどが間借りしているのだが、 どうもマシンパワーが不足しているようだ。先日、全面的にmod_ruby化を行ったりしているのだが、焼け石に水らしい。
マシンリプレースが必要か。しかし、原資はどこから？
_ [特許] 一太郎の敗訴 自由な開発環境の整備も必要
ソフトウェア特許の危険性について触れた社説。こういう「一般向け文書」はありがたい。
_ デブサミ2005 (1日目)
朝、道が凍結していたが、心配したほどではなく、無事に飛行機で東京に。 そのまま表参道の青山ダイアモンドホールへ。
参加したセッションは以下の通り。
XP事例カタログ
「dRubyの方から来ました」の咳さんをはじめとしたXP実践の事例紹介。 「忍者式テスト」とか「スタンダップミーティング」とか、実際にうまくやっている例は参考になる。 もっとも、私はうちのチームで一番XPを実践していないので、 他のチームメンバーには常識なのかもしれない。
Web-DBシステムチューニングの方法
割とフツーのDBチューニング。私はDBに関しては素人以下なのだが、 みなさん、日々こんな苦労をしているのね。
軽量Javaへの潮流
「Struts + Spring + JSP」でJ2EE5.0を先取りって話。 「新しい技術で楽ができる」ことが強調されるが、 それはつまり「今のJava技術者」がめちゃめちゃ苦労していることを意味するような気がする。 これらがオープンソースソフトウェアであるのは確かだが、 この内容は「オープンソース」トラックではないような。
なぜ「オープンソース」でうまくいくのか(前編)
副題が『オープンソース的開発手法の秘密をさぐる』。 Linuxの開発体制をベースに「オープンソース的開発手法」 あるいは「バザール手法」について解説。 私(とその周辺)には物足りなかったけど、 今日の聴衆の大半にはちょうどいいレベルだったのかも。 ビジネス的な話はあえて避けたみたい。
聴衆における「スーツ族」の割合がめっぽう高いのも印象的だった。
なぜ「オープンソース」でうまくいくのか(後編)
後半。副題は『まつもとゆきひろが語る「オープンソース的開発手法の現実」』。 後半になるとスーツ族とギーク族の割合が変化しているような気が。
風穴さんが質問して、私がそれに答えるというスタイル。 私のバックグラウンドやらRubyの開発動機やら開発体制やら。 風穴さんの意向でオープンソースの思想やらビジネスやらの話は避けて、 開発スタイルや開発者の気持ちなどにフォーカス。 当たり前だが私にとってはなにも新しい話ではないので(みんなどこかで話したような気がするし)、 これを聞いた人たちがどう思ったのかはよくわからない。 私の周辺にいる人たちにとっては新規性は無かったみたいだし。
最後の質疑応答でややビジネス的な話が。うち(netlab.jp)が差別化にオープンソースを使っている話を紹介した。あと、時節柄、特許の話が。それに対する答えは
- オープンソース開発者は個人だったり零細だったりすることが多いので事前に特許検索とかしていることは期待できない。よって、特許侵害の可能性が高いように思えるかもしれない。
- しかし、月間2万件(情報分野のみ)も申請される特許から自分の開発しているものに重複する特許を発見することは専門家でもほぼ不可能だ。
- 現実にIBMやマイクロソフトのようなしっかりした法務を持つ会社でも特許訴訟の対象になっている。いや、むしろそういう会社の方が標的になっている(お金を持っているから)
- よって、オープンソースが特に危険ということはない。
- もっともソースを公開しているからばれやすいということはあるかもしれない。 逆にお金を持っていないから訴訟の対象になりにくいということもあるかも。
結局、ソフトウェア特許はオープンソースに対する脅威というよりは、 ソフトウェア産業全体に対する脅威だと思う。良い機会なのでもっと議論を深めるべきだ。
その後、有志と表参道(から渋谷方面にちょっと移動した)インド料理店で食事。
参加者は、(私の席から時計まわりに)Shelacyさん、 naruseさん、かずひこくん、tellmeさん、 えとーさん、風穴さん、くろももさん(名前、間違ってないよね)。
今回はRuby関連の集まりとしてはありえない男女比であったような気がする。
えー、個人的にはおなかが空いていたのでがつがつ食べることばかりで(カレーおいしかった)、 あまりお話できなかった人もいましたが、私は楽しかったです。
参加表明してたのに、来れなかった人は残念でした。またの機会に。
2005年02月04日 [長年日記]
_ デブサミ2005 (2日目)
朝から出席(でも遅刻した)。レポートは以下の通り
オブジェクト脳をなぜ作るのか
NECの牛尾さんとウルシステムの平澤さんとの対決。 しかし、21世紀になるのに「オブジェクト指向の三要素(カプセル化、継承、ポリモルフィズム)」はないだろう、とか思った。カプセル化も継承も本質ではない(それらを含まないオブジェクト指向プログラミング言語やツールはいくらでもある)。この中で一番本質に近いのはポリモルフィズムだけで、それは牛尾さん自身もお認めになっているようだ。
じゃあ、残りの二つはもういいじゃん、とか思ったのだが、じゃあ実際の例題を、 となったとき、Javaだとポリモルフィズムを使うのに、 継承(inheritsかimplementsのいずれか)が必須であった。 そういうことか。Rubyなら特異メソッド使ったりして直接ポリモルフィズムを体験できるのに。
あと、牛尾さんがオブジェクト指向を理解したのはファウラーの『リファクタリング』を読んで、 ということを聞いてちょっとショックだった。めちゃめちゃ最近じゃん。 Blue Bookを読んで(あれ、Green Bookだったかな)って私はもう「じじい」だな。
私自身は21世紀になってから、 (プログラマに対する)オブジェクト指向の教育には「コンピュータに置き換えないたとえ話は役に立たない」と思うようになったので、牛尾さんの話には同意できなかった。「オブジェクト指向という考え方は分かった気がしたけど、実際どう使ったらよいのかわからない」というのは、この「たとえ」が原因ではないかと疑っている。
はてなの作り方
ちょっと遅刻しての参加。私が聞いた範囲では「作り方」というよりも、 ユーザとの付き合い方、仕様の引き出し方のような話が中心だったみたい。 もっともこれらも広い意味での「作り方」の重要な要素なのだけれども。 きびきびした開発が心地よさそう。 話を聞いていて『4274065979』の5章「もうひとつの未来への道」を思い出した。洋の東西を問わず似たようなアプローチで成功しているなあ。
はてなの近藤さんとはんばあぐさんが同級生だったとは知らなかった。同級生でスピーカーしてたのね、今回。
スマートデータベースCachéの実力
「きゃっしゅ」ではなく「きゃしぇえ」と発音していた(最後のeの上にアクサンが付く)。 なんだか面白いもの。B-treeやXMLデータベースを連想する。 RDBを念頭に置いていると「データベース」と呼ぶのに抵抗がある。 もっともRDB以前は「データベース」という単語は違う物を指していたし、 私が前職で使っていたObjectStoreはもっと「データベース」らしくない。
Caché ObjectScriptとCaché Basicという言語を持ち、 データベースそのものがその言語のVMを持つというアプローチと 名前と値のペアを持つノードのツリー構成でデータベースを表現するのは面白いと思った。
でも、もうちょっと突っ込んだ内容が知りたかった。 言語おたくとしては上記2言語の仕様とかに特に関心がある。 展示会にもブースを出していないみたいで、カタログとか入手できなかった。
あと、性能についても「ほとんどメモリ上の処理なんで高速」とかで具体的な数字の言及は無かった。 データベースソフトウェアのマーケティングとしては不利ではないか。
My Framework作成の勧め: アプリケーションを３０個作る時には何を用意するか
前半は「お手製」フレームワークについて。 結局はTemplate MethodパターンとStrategyパターンの応用をフレームワークと呼んでいるような気もしないでもない。
「硬い」Javaで、「柔らかい」アプリケーション(たとえばWebサービス)を提供するために、 あまり変化しない部分から変化しやすい部分を切り出す苦労があるのだと感じた。 より「柔らかい」Rubyではそこまで必要性は高くないが、 修正は分散しない方が生産性が高いので、同じアプローチは有効だ。
後半はDIについて。C#でDIコンテナを作って解説していたが、 私の周囲の人の頭上に「？」マークが浮かんでいるのが見えるようだった。 もっとも、別の方法で解説するのは発表者の負担が大きいのだが。
全体を通じて久しぶりに「私の知らない世界」を見たなって感じ。 知らないところからいろいろと刺激を受ける。
あとはいろんな人と話ができたのも楽しかった。 「Ask the speaker」というコーナーがあったのだが、 聴衆はあまり聞きに来なくて、主にスピーカー同士の交流が行われていたように思う。 JAOOでも同じようなことが起きていたので(「このカンファレンスに来るといろんな人と話せるからいいんだよな」って言ってたスピーカー多数)、洋の東西を問わないのかもしれない。
それから、本イベント中、マイミク二人ゲット。
今回は扱いが良かったので、気分よく過ごすことができた。 関係者に感謝したい。
_ 『ハッカーと画家』
4274065979
以前のエントリでふてくされていたら、 今日の昼食で「謝辞に名前が載ってますよ」との指摘。 あわてて確かめたら確かに「Matz」と載っている。
ありたがいことだが、実質的に役に立ってはいないので、今度は過分だと思う。
2005年02月05日 [長年日記]
_ [言語] リッチ・クライアント開発言語「Curl」の採用企業が増加，Webサービスにも対応予定 : IT Pro
Curlの採用事例が増えている、とのこと。
難しい言語ビジネスの中、成功事例になってくれるのを期待している。 まあ、マーケティングから出てくる言葉をうのみにはできないんだけど。
_ [特許] フォローアップ
些細な一言が結構な影響を与えたような気がしないでもない今回の特許騒動だが、 後片づけとしていくつかのリンクを紹介しておく。
<URL:http://d.hatena.ne.jp/shiranui/20050204#p1>
shiranuiさんによる解説。知財部にお勤めなのかな。
<URL:http://d.hatena.ne.jp/atsushieno/20050204#p1>
atsushienoさんによる知財法の改正案。私もこれくらいが妥当だと思う。 ベルヌ条約は廃棄だ(とかいうわけにはいかないんだろうな)。
<URL:http://benli.cocolog-nifty.com/benli/2005/02/post_1.html>
権利者商品と侵害商品との間に代替性がない場合、侵害商品の製造・販売を差し止めても、 権利者の利益を増大させることに直接繋がらない、との指摘。 侵害品の製造・販売等を差し止めることが権利者に経済的なメリットをあまりもたらさない場合に、 差止め請求を棄却する権限を裁判官に与える方向で法改正を行うことこそが望まれるのではないか、とのこと。 まったくだ。
<URL:http://d.hatena.ne.jp/shiomaneki/20050203/p1>
Macにはすでにこの種のヘルプがあったので、 1989年当時でも公知であった可能性の提示。
議論が深まることそのものは良いことだ。
_ [家族] 百日の祝(ももかのいわい)
今日で末の娘が産まれて100日だ。 で、食べ物に困らないようにとの願いを込めて、 鯛を用意した。
鯛の身とご飯を口に当ててやる。 あと、桃果汁を飲ましてやる。
別にこれで違いが出ると思ってるわけではないんだが、ノリだよね。
2005年02月07日 [長年日記]
_ [映画] ペイチェック 消された記憶
B0001851BE
具合が悪くて出かける気にもなれなかったので、数日前にレンタルしておいた映画を見る。
...これは面白い。伏線がぴたりと決まるのも満足感があるし、 アクションも十分だ。そうか、ジョン・ウー監督か。 原作はP. K. Dickか。短編が原作なのも成功の理由かもしれない。 長編が原作だとどうしても尺に収まらない(ので説明不足になる)ことが多いから。
あえて気に入らなかった点をあげると、
- 「マシン」の動作原理の解説が陳腐。 たぶん、原作のままなんだろうけど、もう21世紀なんだから通用しないだろう。 ここはばっさり削っても良かったのでは。
- 「鳩」の登場の仕方がわざとらしすぎ。監督の「サイン」なのはわかったから、 もうちょっと自然にするわけにはいかんのだろうか。いかんのだろうな。
ハンサムでアクションもこなせるエンジニアにリアリティがない、なんてことは この際問題にしないことにしよう。
４点(５点満点)。
昼間休みすぎて、夜寝られなかったので、２０のアイテムを使った順序で思い出してみる。 なかなか頭の体操になる。
2005年02月08日 [長年日記]
_ 妻の誕生日
なのだが、あいかわらず具合が良くないのであまり活動できない。 夕方、ようやっと外出してケーキ(Baskin Robinsのアイスクリームケーキ)を購入。
あんまりおめでたい感じにはしてあげられなかったなあ。
_ [言語]The Falcon Programming Language
新言語。C++で記述されたVMを持つスクリプト言語、らしい。 以前はHasteという名前の言語だったらしい。
The Falcon Programming Language is a generic purpose untyped 4th generation language, based on a Virtual Machine executing portable pseudo codes (a class of languages nowdays known as Scripting Languages, and counting Python, PERL, PHP, Ruby and LUA among them), completely written in C++.
Falcon differentiates from all other scripting languages because it has been developed with a series of goals in its design since the first program line had been placed:
- Simple but elegant grammar
- Extremely fast Virtual Machine
- Easily embeddable in any kind of application
- Easily extensible and maintainable
- Fully multiplatform
文法に「end」を使うので外見はちょっとRubyに似ている。が、思想的に似ているかというと、 ちょっと違うような気もする。 単一オブジェクトを定義するobject文や、状態を明示的に記述する(らしい)state文などは興味深い。 が、state文の挙動はよくわからなかった。
downloadリンクが壊れているので、ソースはチェックできなかった(2月10日現在リンクは復旧している)。
2005年02月09日 [長年日記]
_ [特許] 特許2945753号
shiranuiさんが松下の特許2945753号について考察してくださっている。
もっとも、結論は
「私が現在調べられる資料の範囲内では、何とも言えない。」です。
全く含まれていないと断言することはできませんが、完全に含まれているとも言えません。前述したソフトウェア特許研究会で、弁理士の谷川英和氏がどのような意味合いで述べられたのかが分かりませんので、谷川英和氏がおっしゃったことを鵜呑みにするのもできません。
だそうだが、特許の専門家らしい慎重かつ冷静な分析は参考になる。
_ [特許] OASIS、「隠れ特許」を避ける新ポリシーを策定
OASISの特許に対する新方針。
新ポリシーの下では、同団体の技術委員会に標準案を提出する者は、その技術から特許使用料を徴収する予定があるかどうかを言明しなくてはならない。
だそうだ。まあ、不意打ちのような特許紛争を避けるためには妥当な行動だと思う。
OASISは、RambusがSDRAMメモリ標準をベースにした製品に対して特許使用料を要求し始めたときに半導体業界が陥ったような事態を避けようとしている。Rambusは結局、SDRAM関連の特許を持っていることを明かさずに標準化の会合に参加したとして、詐欺で有罪判決を受けた。だがその後、控訴審でこの判決は覆された。控訴裁判所は、Rambusが参加した標準化委員会Joint Electron Device Engineering Councilには、Rambusを詐欺罪に問えるような明確かつ十分な知財開示ポリシーがなかったと判断した。
ということなので、「事前に明確にしてもらう」という運用体制が必要なのだろう。
オープンソースでも「コードを貢献するものはその技術から特許使用料を徴収する予定があるか言明しなくてはならない」というルールを確立すべきか。たとえば、GPL3にこのルールを導入するのはどうだろう。不浄条項とは違い自由の制限にはならないような気がする。
2005年02月10日 [長年日記]
_ 出社
今週最初の出社。自宅で仕事をしていたとは言え、 まる1週間以上会社に出なかったのは、本当に久しぶり。 前回はたぶんRuby Conferenceその他でアメリカに行ってた時か。
かずひこくんも同じ時期に具合が悪くて、 デブサミで悪い病気をもらってきたんじゃないかという気になる。 症状は違うんだけどね。
2005年02月11日 建国記念の日 [長年日記]
_ [Ruby]アマゾンが、ブログサイト「43 Things」に投資
43 Thingsってのは、 面白いサイトで、それぞれのユーザが最大４３個の「やりたいこと」を登録し、 そのやりたいことをベースに相互にリンクするというもの。
で、なぜこれがRubyエントリかというと、 これはRuby on Railsで作られているらしいのだ。
We started building the prototype using instiki - not even writing code - and then enlisted the help of DHH to start thinking about developing the site using Ruby on Rails. We roped in our friends at 37 Signals to help.
<URL:http://robotcoop.com/weblog/52/on-background>
メンバーの写真をよく見ると、継続ベースのWebアプリケーションフレームワークBorgesのメンテナであるEric Hodelの顔も見える(左側奥から2番目)。他にもRuby Conferenceで見かけた顔があるような。
ZDNetで取り上げられたすぐ後なのに、別にレスポンスが悪くもない。 なかなか優秀だ。
2005年02月12日 [長年日記]
_ [OSS] O'Reilly Open Source Convention
今年も８月１日から５日まで、オレゴン州ポートランドのOregon Convention Centerで開かれる。
で、今年はRubyのトラックがあるということで(一昨年はあったが昨年はなかった)、 RubyCentralの友人たちから依頼されていた 発表のプロポーザルの〆切が 「Midnight (PST) February 13, 2005」ということなので、少々あわててサブミットする。
テーマは「Yield to the Block: the Power of Blocks in Ruby」。 ブロックの使い方をいろいろと語るというネタなのだが、４５分持たせられるだろうか。 日本語なら楽勝だけど、「えーご」だからなあ。
この後、March 7, 2005までに採否の通知が来ることになっている。
採用されちゃったら、行ってくるしかないのだが、今度は交通費その他の算段をしなくちゃだな。 秋のRuby Conferenceにも行きたいんで、お金のアテを用意しとかないとなあ。 昨年は海外渡航ゼロだったのだが。
発表すると、結構な値段のOSCON参加費がタダになるので、 どうせ行くなら発表した方が良い。時間がない(日本時間だと月曜夕方５時)が、 少しでも行くつもりがあれば、だめもとで応募してみるのも手だ。
噂によればRubyトラックは競争率が低いらしいし。
2005年02月14日 バレンタインデー [長年日記]
_ [原稿]UNIX USER
朝は息子を病院につれていき、インフルエンザが治ったことを確認してもらってから病院へ。
あとは原稿書き。Linux Magazineが休刊になってしまったら、 さっそく原稿依頼があった。UNIX USERは「Ruby開発日記」の延長のようなネタ、 ということで「ハッカー」の心理や生態を取り扱うような読み物を2ページくらい。
そうなると必然「ハッカーと画家」とかと比べられてしまいそうだが、 あんな文章は書けませんから。「開発者日記」の勢いだけで書いたようなテイストは残したいのだが、 うまくいくだろうか。
_ チョコレート
最近はあまり甘いものを食べない。嫌いになったというほどではないのだが、 たくさん食べる気にならない感じ。「もう一生分の甘いものは食べたから」というのが口癖。
だが、妻と三人の娘がいるとありがたいことにもらえるわけだ、チョコレートが、この季節には。
本当にありがたいことだとは思うのだが、 ウルトラマンの形をした結構な大きさのあるチョコレートの塊をどう片付けたらよいのかと思うと 思案に暮れるところがないわけではない。
_ [Ruby] FutureMail
Ruby on Railsのアプリケーションがまた一つ。 「未来の自分にメールを書く」というのがテーマみたい。
当然スケジューラやリマインダとしても使えるが、 応用次第ではまた別の使い方もできるかも。
2005年02月15日 [長年日記]
_ [原稿]日経Linux
今月は日経Linuxからも依頼されているのだった。「日経LinuxはRubyを取り上げたことはありませんから、とりあえず紹介記事を」という依頼だった。考えてみれば、最近はRubyの紹介なんて雑誌に載ることはあまりないし、紹介記事なんて2002年のUNIX USERの特集以来ではないだろうか。さらに言えば、私は自分自身で紹介記事を書いた記憶はないなあ。最初の雑誌記事(TRY!PC)は原さんが書いてるし、Software Design誌はgreenteaさんが(変名で)書いてるし、UUはやまだあきらくんだし。
というわけで、勢い込んで書いたのだが、今日の〆切には間に合いそうにない。 メールして一日だけ〆切を延ばしてもらう。よい子は真似しないように。
2005年02月16日 [長年日記]
_ [原稿]日経Linux
昨日、書き終わらなかった原稿を引き続き。８ページという約束であったが、 書き終わった後ざっと見積もってもらったら９ページ半はあるとのことであった。 また書きすぎた。実際にはあちこち削ることになるだろうな。
_ [特許]HP幹部：「ソフトウェア特許を無視するのはいささか世間知らず」
なんだそうだ。
HPのLinux担当バイスプレジデントMartin Finkは当地で開催中のイベントLinuxWorld Conference & Expoで、「最終的にソフトウェア特許は生活の一部となる。それを無視するのはいささか世間知らずといえる」と語った。同氏はさらに、ソフトウェア特許に反対するのは結構だが、それらを取得しようとしないのは無謀だとも指摘した。
いや、特許に実際に関る人はみな同じようなことを言うし、 ソフトウェア特許をすぐに無効にする現実的な方法もなさそうだから、 おっしゃることはわからないでもないのだが、 「取得しようとしないで」公知にするというもアリだと思うのだが。
それに、今まで積み上げた慣性を考慮に入れず、 「産業振興」だけを考えると、今の特許のあり方は(ソフトウェアだけに限らず) いろいろと改善の余地がありそうなんだが、そういうことには触れないんだよなあ。
ま、「特許は無視できないし、重要な戦略物資」だと思ってることは同じでも、 オープンソースに(ごく一部だけど)自社特許を解放して、 オープンソース開発者の歓心を買うIBMに比べて、 「Linux担当バイスプレジデント」が自らソフトウェア開発者の反発を買うような発言をしちゃうHPは、 かな〜り、お粗末な印象を受ける。まったく下手くそなんだから。
これでは「HPが味方である」とは思ってもらえないと思うよ。
2005年02月17日 [長年日記]
_ 中部国際空港が開港・３大空港時代がスタート
中部でもどこでもいいから、ちゃんとしたハブ空港がほしいものだ。 地方から海外に出ようと思うと、羽田から成田が遠すぎ。 関空も国内便が少なすぎてハブになってないし。
私の住んでるところが田舎すぎるというのはあるにしても。
_ [OSS]「世界に通用するオープンソース人材を」リナックスアカデミーがミラクルと提携し高度教育コース
ミラクルのよしおかさんが加わってるなら、 そんなに変なことにはならないかな。
とはいえ、「世界に通用するオープンソース人材」としてどのような人材を想定しているのかは、 興味深い。私には「コードが書けるだけでなく、コードが読める」ことと、 「メールなどネット経由でのコミュニケーションができる」ことくらいしか思いつかないのだが。
あ、あと「ほっといてもプログラムをばりばり書くほどのプログラミング好き」というのも必須かな。 育成するものではないような気もするけど。
そういう人材がいればうちの会社で欲しい。 Rubyでばりばりプログラムが書けるし、オープンソースの開発も優遇される。
_ [Ruby] A Little Ruby, A Lot of Objects
XP界(というかテストファーストプログラミング界か)の「Mr.マリック」こと、 Brian Marickによる書籍のドラフト。まだ、中身読んでない。
彼にもらったCow Magでホテルのカードキーをダメにした人は私だけではないに違いない*1。
追記: よく見れば日付が2001年だ。もうすぐ出る、とかいう話ではなさそうだ。
*1 Brian Marickの奥さんは獣医なんだそうで、それが理由かどうかはわからないけど、毎回新しく知り合いになった人にCow Magを配っている。で、うっかりこの磁石をカードキーやキャッシュカードに近づけてしまった人は悲惨な目に遭っている。彼曰く「だから気をつけろって言ったじゃない」だって。
_ ruby.meetup.com
登録してみる。 が、Japan/Matsueなんてところに登録する連中は、 (いたとしても)ほとんど私の席から半径10メートル以内のような気がする。
_ セミコロンをリターンに
増井さんがキーバインドを変えてセミコロンをリターンにしちゃった、という話。
それから、最近気がついたことは、セミコロン打たなくていいですよね、あんまり。キーボード入力してる時、セミコロンって小指にあるじゃないですか。これは非常にいいポジションなんだけど、C とか Perl では打つけど、Ruby では打たなくていいですよね。で、使わないキーがこんないいところにあるのはもったいないから、これリターンにしちゃったんですよ。
だから、私の機械は今全部、右手の小指がリターンなんです。すると手を全然動かさなくていけるんですよ。普通の人は、バックスペースで右手を動かすし、リターンでも動かすから、かなり無駄なんですよ。日本語を入力しててもかなり手が動いてるはずです。でも、ここをリターンにしてから、ほとんど手を動かさずに舐めるように入力できるようになりましたよ。
ところで、セミコロンはどこへ行ったかというと、キーボード右下部のキーを全部セミコロンにしちゃった。
まあ、私の場合、「；」は「え」の入力に使うから外せないのだが。
そういえば、もう10年以上前、飲み会の帰りにすっころんで、 左手首を傷めた時、左手をひねって小指でコントロールキーを押すのが辛かったので、 スペースバーをコントロールにしたことがあった(で、スペースを代わりにどこに割り当てたのかは覚えていない。たぶん「無変換」か「変換」だと思う)。なかなか快適であったが、 コントロールよりもスペースを押す回数の方が明らかに多かったので、 手首が治ったら元に戻したけど。
この時の経験が自分専用のキー配列の追求のきっかけになり、 最終的に「きゅうり改」を作る原動力になったような気もしないでもない。
_ [OSS] オープンソースライセンスを3種類に--OSI、削減策を検討
次々と独自のライセンスが出てくるのは事態を複雑化させるだけだし、 整理できるものならした方が良いとは思うので、 この動きそのものは大歓迎。
ただ、ライセンスの移行は相当に面倒が予想されるので、そんなに簡単には進まないかも。
もうひとつ気になるのは、見出しの「OSIの動き」は歓迎されるものだとしても、 なんか本文の中身に違和感がある。
OSIが自らの役割の重要性を自覚していないのは明らかだ。彼らには、オープンソースが依拠するライセンスについての基盤が、信頼に足るものであるよう確実を期す責任がある
現状のライセンス認定プロセスでは、単に特定の仕様を順守しているかどうかが審査されるだけで、オープンソース業界のビジネスモデルをさらに革新する力がそのライセンスにあるかどうかは見過ごされている。これは、オープンソースを機能させている核心の部分に対して、はっきりと直接的に危険を及ぼすものと私には思える。OSIがいまのやり方を続けるなら、彼らは的外れな方向へ進んでしまうだろう
いや、OSIのやり方が良いといってるわけではないが、 上記の発言はなんだか「俺オープンソース」の匂いがする。 OSIが保証したかったのは「ソフトウェアの自由」だったはず(たとえその「自由」がfree software陣営が考えるものと少しずれていたとしても)、「業界のビジネスモデルを革新する力」があるかどうかなんて元々は関係ないはず。
OSI Certifiedライセンスの種類が増えてトラブルが多くなっているのだとして、 OSI Certifiedの認証プロセス中で、既存のライセンスを使えないかどうか説得する手順を増やす というならともかく、OSDを満たすライセンスを
われわれが、Sunに対して『（CDDLという）独自のライセンスがオープンソースとして認定されるわけがない』と言っていれば、SunではおそらくMozilla Public License（MPL）を選んでいただろう
と「門前払い」するのが正当のような物言いはいかがなものだろうか。
ちなみに上記の「的外れな方に進んでしまうだろう」という、 私からみれば「そっちの方が的外れでは」という発言は、 先日も批判したHewlett-PackardのLinux担当バイスプレジデントでOSDL理事のMartin Finkのものである。なんだかなあ。
追記
原文を読んでみた。 Finkの主張のニュアンスが翻訳で変化していてはいけないと思ったからだ。
該当部分は以下の通り。
"Clearly, the OSI has not internalized its critical role to ensure that the licensing underpinnings upon which open source is built remain a force to be reckoned with," Fink said.
"This current path of approving licenses--based simply on the compliance to a specification rather than on the basis of a new license's ability to further innovate the business model of the open source industry--represents to me a clear and present danger to the very core of what makes open source work," Fink said. "If this is the path the OSI continues to choose, then it is choosing a path towards irrelevance."
この部分に関してはニュアンスの変化はないようだ。Finkが徹底的にビジネスサイドからしかオープンソースを見ていないことがうかがえる。「混乱」して困るのは主にビジネスに利用したい連中で、個別の開発者のさほどでもない(でも混乱を増加させる必要はないと思うけど)。そこを「OSIがそうする責任がある」とか「的外れな方法」と強く強く主張するのは、FinkがOSIやひいてはオープンソースというものを、「利用」して(自分の)ビジネスのネタにしたいという「欲望」の現れではないだろうか。いや、そのような「欲望」が悪いとは言わないし、オープンソースをビジネスに利用してくれて結構なのだが、こうあからさまに押しつけられると迷惑な感じだし、ちょっと食傷気味。
それはそれとして、興味深いのは以下の部分が翻訳されていないこと。
Greenblatt, and other industry executives, believe the number of licenses can be dramatically distilled down.
"Eventually there should be three licenses: The GPL, a commercial version of the GPL and, of course, there will be the BSD because you can't rid of it," he said, referring to the Berkeley Software Distribution, or BSD, a popular variant of Unix developed by the University of California, Berkeley in the 1970s.
Greenblatt added that elements of other licenses, such as Sun's CDDL, could be used to form the short list of open-source licenses.
生き残る3種類のライセンスとは「GPL、商用版GPL、BSDライセンス」らしい。
日本語タイトルの「オープンソースライセンスを3種類に」というのはここから出ているのに、 この重要な部分が翻訳されなかったのはなぜだろう。そういえばITmediaでも翻訳されてないなあ。 ちなみに原題は「Open-source board eyes fewer licenses」である。 ここでの「Open-source board」はかならずしもOSIだけのことではなく、OSIとOSDLなどのメンバーからなる 「委員会」のことではないだろうか。
2005年02月18日 [長年日記]
_ [Ruby] 関数呼出し
しばらく原稿に追われてRubyをいじる暇がなかったので、 反動としてRubyについて考えてみる。こういう時間が一番充実しているような気がする。
関数とレコードをベースにオブジェクト指向プログラミングをエミュレートするPythonと違い、 オブジェクト指向プログラミングによって関数をエミュレートするRubyでは、 lambdaはあっても、呼び出しが格好悪い
f = lambda{|x| p x}
f.call(12)
と「.call」が必要だからだ。気持ちとしては
f = lambda{|x| p x}
f(12)
と書きたいものだ。そこで
- 関数的呼出しの関数名部分がローカル変数のときには、そのローカル変数の値に「call」メソッドを適用する
というルールを導入するのはどうだろうか。以前にも同じようなことを考えたのだが、
- 「call」ではなく「()」という特殊メソッドを適用していた
- 「foo.bar(12)」なども「foo.bar().call(12)」に適用できることを考えた
こともあり、あまりうまくいかなかった。 今回の条件であるローカル変数があるかないかならコンパイル時に判断できるので、 実害は少ないような気がする。
欠点はローカル変数名と同じ名前の手続きが呼べなくなることだ。 通常あまり問題になることはなさそうだが「p」のような重複しやすいものもあるしなあ。
なにか回避策を用意すべきだろうか。
_ [Ruby] Look at me, I’m a Signal!
Ruby流DIコンテナNeedleの開発者であるJamis Buckが５年間プログラマーとして働いたBYUを辞めて、 Ruby on Railsを開発したDHHの 37signalsに転職するという話。
在宅で仕事をするらしいのだが、 アメリカのプログラマの流動性を感じさせる一件。 また、Rubyが人の人生を変えるのを見るとなんとも言えない気持ちになる。
彼の成功を祈る。
2005年02月19日 [長年日記]
_ 買い物
娘の誕生日のプレゼントを買いに買い物に出かける。 途中で寄った電器店で妻がマッサージチェアにはまる。
「これ昔のと全然違う。気持ちいい。ほしいなあ」
確かに同意する。が、「26まんえん」はちょっと高い。 それよりなにより、これって松下製品なんだよなあ。
やっぱ買うわけにはいかないなあ、と言ったら不満そう。
「じゃあ、私が買うから。それでいいでしょ」
いや、うち、財布は一つなんですけど。 松下電器は主婦の気持ちをがっちりつかんでいるらしい。
別の商品を検討してみるか、オムロンとか。
_ ルートビア
松江ではルートビアがなかなか入手できない。 しばらく前に某スーパーマーケットで見つけて買い占めたら、 それきり入荷しなくなってしまったし。
と思ってたら松江サティ３階のホビーショップでＡ＆Ｗが売られていた。 あいにく一本しかなかったが、今後は(少量なら)ここで入手できるということか。
2005年02月20日 [長年日記]
_ [教会] 米子訪問
米子の教会を訪問。出雲の次に近いからありがたいが、家族や古くからの知人ががいるので恥ずかしい気もする。まあ、今は両親がいないからまだマシか。
お話しのテーマは聖約。「約束を守る」という基本的な話から、 「人と人の約束」さらには「人と神との約束」について。 あと、自らの経験から「その時かぎり果たすのではなく、継続して守る」ことと、 「あらかじめ備えることにより、楽に約束を守れる」ということについて。
自らの経験ってのは、〆切前の苦労だったりするんだけど。 〆切は何ヶ月も前に分かってるんだから早めに取り掛かれば楽なのにねえ。
2005年02月21日 [長年日記]
_ [言語] Minimizing Row Displacement Dispatch Tables
ちょっと古い論文。だけど知らなかった。
静的言語ではダイナミックディスパッチの実現にC++のVirtual Table(VTABLE)のような ディスパッチテーブルを用いる手法が使われることが多い。 これは「高速である」、「コンパイル時の情報が豊富」などの性質が有利に働くからだ。
上記の論文はこのようなディスパッチテーブル手法をSmalltalkのような動的言語に適用する、 というもの。動的言語特有のクラスやメソッドが動的に追加された時にどう対処するかという点についても 考察されている。
目新しい点は
- 二次元(クラス×セレクタ)のテーブルを一次元に圧縮する。まず、疎なテーブルをソートし、 大きいものからfirst hitで一次元の配列に格納する。取り出しはオフセットを使う。
- テーブルを圧縮する時、 通常は表をクラスごとに分割するが、セレクタごとに分割することを推奨している これによりセレクタの追加が行の追加ですむので更新時の効率が上がる。
- クラスが追加された場合には複数のディスパッチテーブルを持つ(method_missingで第二のテーブルにフォールバックする)ことで対応。新しいクラスは少々遅いが全体としては速い実装が可能。 暇な時にディスパッチテーブルの再構成を行う。
なかなか効率は良さそう。しかし、この手法はRubyのようなオープンなクラス(既存のクラスにメソッドを追加できる)ではテーブル再構成が増えて効率が悪くなるかも。ここをどう解決するか。
_ [特許] CAもオープンソースへの特許公開を確約
Computer Associates（CA）は自社の特許ポートフォリオの一部をオープンソースの開発者に公開し、すでにこうした動きに出ている他社を追従する計画を進めている。
同社関係者によると、CAは自社の特許を利用して、オープンソース製品に対する法的攻撃からユーザーや開発者を守る考えもあるという。特許の公開時期やライセンス条件の詳細については今後決定されると、この関係者は述べた。
とりあえず素直に歓迎したい。望むのは、どうせ公開するなら(Sunのようにではなく)IBMのような上手な方法で行われることだ。
「自社の特許を利用して、オープンソース製品に対する法的攻撃からユーザーや開発者を守る考え」というのは、IBMのアナウンスよりも一歩踏み込んでいるように思える。
もっとも、そもそもソフトウェア特許に運用に問題があるからこんなことが必要なんだ、 ということは忘れないようにしたい。なにか良い解決策はないものか。
既得権者には受け入れられそうもないが、「特許の有効期限は2年」というのが 一番「産業振興に利する」ように思えるなあ。
_ [OSS] フリー/オープン・ソース・プロジェクト管理の要諦
Perl, Apache, Linuxの各プロジェクトリーダー(「元」も含む)の言葉。
まあ、一言にフリーソフトウェア/オープンソースソフトウェアと言ってもあり方はさまざまだ。
たとえば私が関わるものだけでも、 Rubyはよくも悪くも私が始めた「私のもの」で、いろんな人の意見を反映するとは言え、 最終決定するのも、責任を取るのも私だ。 逆にcmailは私はオリジナルの作者ではなく、引き継いだ保護者であり、 そして集団管理体制に移行した(が、最近は衰退しているんだろうなあ)。
どれがいいとは断言できないが、 参加しやすいコミュニティを持つものは長続きしそうな気がする。
ところで、この記事のタイトル「要諦(ようてい)」って知らない言葉。 辞書によると「肝要なさとり」あるいは「肝心の点」ってことらしいけど。 原文タイトルの「The paradox of free/open source project management」とはずいぶん印象が違う。
ここで言う「paradox」とは
フリー/オープン・ソースプロジェクトを立ち上げ大成功に導きたいのなら、時機をあやまたずに手放す計画を立てよ。
ということらしい。上記のインタビューのどこからそういう結論を引きだしたのかよくわからないけど、 まあ全く嘘というわけではない。
でも、同じインタビュー(と自分の経験)から、私が教訓を引き出すとしたら、
- OSSの成功にはリーダーシップが必要
- リーダーの必要条件は「コミュニティから尊重されること」。 そしてそれは「正しい判断を行うこと(行い続けること)」、 「失敗しても適切に対応すること」、 「権利を保持しつつもそれを乱用しないこと」で得られる。
- プロジェクトが大規模化すると組織化が必要になる。 全部自分ではカバーできない。
くらいかな。上記の「結論」は最後のものだけを強調し過ぎているように思う。
_ How NERDY are You?
Overall, you scored as follows: 6% scored higher (more nerdy), and 94% scored lower (less nerdy). What does this mean? Your nerdiness is: Supreme Nerd. Apply for a professorship at MIT now!!!.
だそうだ。そんなに？
2005年02月22日 [長年日記]
_ [Ruby] International Obfuscated Ruby Code Contest
とうとう登場した。いつかはやる人が出てくると思ってたんだ。大歓迎。
大会ルール。 〆切は3月末日(2005-03-31 23:59:59 UTC)。
可読性が高いといわれるRubyだが、読めないことに関しても他の言語に決して負けないことを示していただきたい。
_ [Ruby] Chizzle
Ruby用IDE。
Chizzle is a ruby ide. Frustrated by the lack of a good ide for ruby, CharlesLowell and I decided to try our hand at one.
Our vision is to eventually build an IntelliJ style IDE with tons of refactoring support on top of Parrot AST's. This means that it in theory, with a few tweaks, it should support any language which can run on top of the Parrot VM. This includes ruby, python, perl6 and a ton of others. Pretty cool concept, yeah?
っていうか、これParrot用IDEなのね。あれ、「目指してる」だけなのか？ いずれにしても面白い。
ところでこのIDEは日本では「千鶴」と呼ばれちゃうんだろうか。
_ [OSS] VAリナックス、オープンソースに関する信条とコミュニティーへの約束を条文化
「約束」を引用しておく。
- VA Linuxはオープンソースを支持します
- VA Linuxは従業員がオープンソース・プロジェクトに関わることを認めます
- VA Linuxは積極的にオープンソース・コミュニティにお返しをします
- VA Linuxはオープンソースコードの権利を適切に処理します
- VA Linuxはコミュニティを信頼し、高いレベルで協調します
非常によろしい。 佐渡さんのインタビューも参考になる。
うちの会社もこれくらいしないと、 OSS界におけるプレゼンスの今以上の向上は望めないんじゃないだろうか。 今、同じ「約束」を出しても二番煎じで目立たないのが欠点だが。
社内では、うちで開発しているオープンソースソフトウェア(あまり知られていないが結構ある)を、 一箇所にまとめてファームして、sourceforge.jpのような形で知らしめてはどうか、 というアイディアが出ている。実現すればVAとは違う形でアピールできるかも。
追記:
佐渡さんのインタビューには、
しかし、われわれとしては勤務時間内は100％与えられたタスクをこなしてほしいと思っています。企業に属する以上、勤務時間中にはやはり業務に専念しなければいけません。ただ、業務に関連してプロジェクトに関わることもあるでしょうから、それは認めなければいけません。
とある。ああ、VA Linuxはまだ「普通の会社」なんだなあ。
うちは小さいせいか、
- 業務でOSSを開発することがある
- そうでなくても勤務時間内に(自分の)OSSを開発しても全然ＯＫ
- ていうか、完全裁量労働制なので、勤務時間が結構あいまい(でも、みんな割と「普通」に働いてる)
- しかし、〆切までに100％タスクを達成してほしい(じゃなくて「達成しなさい」)
なんて感じだ。
_ [OSS] 普通の会社
佐渡さんの日記で、上のエントリに反応があった。直接コメントがつけられないので、こちらで書いてトラックバック。
で、Matzさんからは「VA Linuxはまだ「普通の会社」なんだなあ。」と突っこまれているが、これについては(世間の普通ではないかもしれないが)普通の会社でいいと思ってるのでいいとして、それ以降に書かれていることはちょっと首をひねるかな。
あぁ、「普通の会社」と書いたことから私の意図以上にネガティブなものを読み取られたようですね。 言いたかったのは「うちは(まだ)普通じゃないなぁ」であって、実はVAに含むところはないです。 まだまだ小さいからこうなってる部分もあるわけで一概に比較はできないでしょう。
そもそも業務でOSSを開発するのは、VAリナックスではごく普通のことであるので、OSSの開発も業務に入ることになる。ただ、業務と全く関係のないOSSプロジェクトに勤務時間中ずっとかかりきりになるのは当然ダメなわけで、ある程度の線をひくことになる。
やってることは同じですよね。ただ、うちには勤務時間という明確な縛りがないから、 「タスクを期限までに完了する」というのが「線」になっているということで。
2005年02月23日 父の誕生日 [長年日記]
_ [言語] Teaching my kids to program
子供にプログラミングを教える時にどんな言語を選ぶかって話題。
DanDon Boxってのはすごく有名な人らしい(ごめん、知らないの)。
私だったらどうするかなあ。私の４人の子供たちは、 あいにく(さいわい？)プログラミングに関心がないので そういうことを考えたことがない。 プログラミングってのは自分で学びたいと思って身につけるものだと思ってるし。
でも、いざ彼らが「学びたいんだけど」と言ってきたら、なにを与えるかなあ。
- Ruby
- やっぱり父親が一番詳しい言語だから(当たり前)。 でも、Rubyってばどっちかっていうと「ハッカーの道具」で素人向けではないような気もする。 ま、そういう点は触れないで教えればよいのだが。
- Squeak
- やっぱ、一番見栄えがいい処理系といえばSqueak周辺ではないかと。 ただねえ、次につながるかといえばなんか違う気がする。
- LOGO
- 元祖タートルグラフィックス。 子供にプログラムの結果がはっきり見えるのは良い。 でも、ちょっと古めかしい。今でも処理系は入手できるんだろうか。 「次につながるか」という不安はここにもある。
- Dolittle
- ドリトル先生にお願いしようか。 が、父親もよく知らない言語は教えられないなあ。
ひまわりなでしこ- これも同様。日本語プログラミングにはずっと前から懐疑的なのだ。 ただ、「シンボルを日本語の単語にして構造は通常言語」というのはアリかもしれない。
なんかコレというものがないねえ。
....作るか(ぉぃ)。
_ [Ruby] Probe Object
sshiさんの日記から。
まあ、Rubyを含め動的型言語には、
Rubyでは動的型付けの悪影響で、ライブラリなんかの関数に何のオブジェクトを渡せばいいのかさっぱりわからないことがある。ソース読んでも関数定義だけでは仮引数の個数と名前くらいしかわかんない。
- 変数宣言に型を書かなくていいなんて、なんて書くのが楽なんだ、ビバRuby!
- 変数宣言に型を書かなくていいなんて、なんて読むのがつらいんだ、ガッデムRuby!
てなかんじ。
という傾向があるのだが、それに対する対応策として、 「じゃあ実行してみちゃえ」というアイディア。 動的言語万歳。
使い方のわからないメソッドにProbeというオブジェクトを引数にして渡すと、method_missingを活用して
- そのオブジェクトに対して呼び出されたメソッド
- その引数
- メソッドの戻り値の使い方
などを記録してくれるという仕組み。詳しくは元のエントリを参照のこと。
結構いいかも。逆転の発想だ。
2005年02月24日 Ruby誕生日 [長年日記]
_ [Ruby] 古いRuby
前回の転職の時のごたごたでそれより古いRubyのソースを保有していなかった。 具体的には ruby-1.0-970819.tar.gz が最も古いものだった。
いや、3MのMT(磁気テープ)に入ったものが読めれば、 学生時代のものも含めていろいろと面白いソースがあるとは思うのだが、 ドライブが入手できそうにない。
私の古いマシン(旧式Dynabook)にはなにか残っていたかもしれないが、 今は段ボールの箱の奥底に眠っている。
が、今回友人たちに相談したところ結構古いものが入手できた。 持つべきものは良い友というものだ。ありがたい。
新たに入手できたものは以下の通り。
ruby-0.49 ruby-0.50 ruby-0.51 ruby-0.52 ruby-0.53 ruby-0.54 ruby-0.55 ruby-0.56 ruby-0.65 ruby-0.66 ruby-0.67 ruby-0.68 ruby-0.69 ruby-0.70 ruby-0.71 ruby-0.72 ruby-0.73 ruby-0.99.4-961224 ruby-1.0-961225 ruby-1.0-970324
歴史的資料として面白いと思う。 近いうちにどこかで公開したい。
これら以外のソースを保有している人はご一報いただきたい。
_ [Ruby] 言語の誕生日
デブサミでも話したことだが。
1993年2月24日は「Rubyの誕生日」ということになっている。 これは『4756132545』の共著者でもある 石塚さんと、新しいオブジェクト指向言語を作ることについて最初に話しあった日であり、 「Ruby」という名前が決まった日でもある。
この時点では1行もコードは書かれておらず、 Rubyはまだ頭の中のイメージだけで存在していたとは呼べないから、 人によっては「誕生日と呼ぶことはできない」と感じるかもしれない。
しかし、結局は形のない存在であるソフトウェアにとって「名前」と「イメージ」はとても重要なものであると私は考えるので、その重要なものがそろったこの日こそ言語の誕生日としてふさわしいと思うのだ。
というわけで、もう12年。長い付き合いになったものだ。
2005年02月25日 次女誕生日 [長年日記]
_ [家族] 次女誕生日
今日は次女の誕生日。しかし、夕べから熱を出して今日は学校休み。 彼女が８歳のときにも同じようなことがあったような気がする。
_ [OSS] 株式会社ユヒーロ
Googleの広告によれば「若き日本人によるオープンソース企業」なのだそうだ。
が、しかし、
オープンソースアーキテクチャ
システムの開発や運用において必要となるアプリケーションには、オープンソースアーキテクチャを選択しています。 当社ではオープンソースアーキテクチャを用いたソフトウェア、システム開発実績を有します。
という点以外は、 オープンソースについてなにも述べられていない。
トップページにもあるHiTo!なる データベース管理者(DBA)務支援システム(主力商品？)もどうやらオープンソースではないようだ。
だとすると、どの辺が「オープンソース企業」なのだろう。 堂々と「オープンソース企業」を名乗るためには、 単に「オープンソースを利用したソフトウェア開発をしたことがある」だけでは十分ではないようにも思う。 最近ではそんな企業は全然珍しくないしね。
それはどうでもよいのだが、このページのどこを見ても、 「人」が出てこないのが不満だ。企業情報のページを見ても、社長の名前さえ登場していない。 オープンソース界隈ではやはり人が資産になるのではないだろうか。 今時「慶應義塾大学湘南藤沢キャンパスとの連携」だけでは十分とは言えないような。
正直、このページの情報だけからではここに仕事を依頼したい気持ちにはならないなあ。 Google AdWordsの効果は上がらないかも。
もっとも、うちの会社のページも悲惨だが、 正直ここから仕事を得ているわけではない。 実は「ホームページ改善プロジェクト」は何年もペンディングになっているが、 来年度こそは動きだせそうな材料がある。
ま、それはそれとして、Matzにっきは株式会社ユヒーロを応援します。 堂々たるオープンソース企業に成長してほしいものだ。
私の名前に似てるし、さ。
_ FCCのデジタルTVコピー規制は「度を超している」と裁判所
日本のデジタルTVコピー規制(コピーワンスのみ)も「度を越している」と誰か判定してくれないものか。
デビッド・B・センテル判事もこれに同意した。センテル判事は、高画質の映画やTV番組を著作権侵害から保護できない状態で放送することをエンターテインメント企業が嫌がっていることは認めたが、これはFCCが関与する問題ではないと述べた。
「コピープロテクトが施されなければ、提供されるコンテンツは少なくなるだろう。しかし、議会はFCCがコンテンツを最大限に増やさなくてはならないという指示は出していない。FCCは洗濯機を規制できないし、世界を規制することはできない」（同判事）
日本の放送関係者に聞かせてやってくれよ。 テレビでデジタルTVについてCMが入る度に暗い気持ちになる。
2005年02月26日 [長年日記]
_ [知財] 「創作とは、人の心に宿ったものの表現」松本零士氏が著作権保護を語る
いや、それについてはまったく同意するし、 他人の権利を侵害してはいけないことについてもその通りだと思う。
しかし、「じゃあ具体的に何をしたいのか」という点で不安になるのは、 過去の言動があるからだ。
その他のツッコミどころとしては
「文学であれ、絵画であれ、音楽であれ、すべて、人の心に宿ったものを表現したもの。これが創作だ。それぞれ、世界にひとつだけしかない。何かものを書く (描く)ものにとっては、体験や自分の目でみたことに基づいたことをかたちにするのが仕事だ。いまや、簡単に(著作物の)コピーができるようになっているが、複製には、経験や真実に裏打ちされたものがない」。漫画家の松本零士氏は、創作の意味について語る。
というが、
- そもそも読者が読む漫画は(生原稿の)コピー/複製ではないのか
- 上記複製が「模倣」のことであったとしても、 松本零士の作品も相当の割合で模倣から始まっていることをどう考えているのか
の辺りだろう。ポスターが宮沢賢治の「模倣」である『銀河鉄道999』であるところが泣かせる。
_ 外食
昨日が次女の誕生日であった(が、彼女は具合が悪かった)ので、 今日の夕食は外で食べることにする。おいしいものを食べて幸せそうであった。
さて、このレストランにはインテリアのディスプレーとして、 英語の本が並べてあったのだが、ふとタイトルを眺めると
Encyclopedia of Explosive and Related Items (爆発物および関連物百科事典)
などという物騒なものであった。ページをあけると、 グラフやら化学式やらがびっしり書いてあった。 専門的過ぎて理解できなかったけど、見る人が見たらまずいものなんじゃないの？
_ 先生
GCCのバックエンドをプログラムできるILogScript。チュートリアルに微妙な表現が。
と、まあ、その件についてなんだけど、この問題は非常に難しい問題であって、例えば、コンパイラのことを、コン・パイラ君とか呼んじゃったりしてても、一緒に名前を連ねるのを許しちゃう、みたいな、そういうセンスを理解できるだけの大きな器を持っていないと立派なコンパイラの先生にはなれないんだぞ。というそういう問題も同時に含んでるのである。コンパイラ書きというのは、そういう部分も要求されるのだ。多分。
爆笑。
ささださんの日記にも、同じ先生について言及されている。
いろいろと楽しかったのだけれど、「もっと真面目にコンパイラと付き合っていれば」という言葉を聞いて、じゃぁどこまでやれば真面目に取り組めたことになるんだろう、とか思ってしまった。
私の知る限り、この方ほど真面目にコンパイラと付き合った方はいらっしゃらないと思うんだけど、 それでも本人は「もっと高いところに行けたのに」と感じちゃうのかなあ。
2005年02月27日 [長年日記]
_ [教会] 松江
松江に出席。地元はラクでいい。
もうすぐ八歳の息子は監督と面接。 誕生日に向けて、いくつかのチャレンジを受けた息子は目に見えてへこんていた。 プレッシャーに弱いタイプなのね。
うちに帰ってからも荒れていて、 八つ当たりをしては姉に逆襲されて涙を流していた。 こういう時、弟は不憫だ。
寝る前にぼそっと「いいところも見てほしいなあ」とつぶやいていた。 わかるよ、それ。いいところもいっぱいあるんだよね。なかなか分かってもらえないけど。
2005年02月28日 [長年日記]
_ [特許] 最近の特許交渉相手の問題点
企業知財部員の日記から。
実際の業務担当者の立場からの文章は新鮮だ。
最近話題になった松下vsジャストの訴訟でもそうだが、（松下の人曰く）ジャストは再三に渡る契約交渉の申入れを行っても無視しつづけたとのことだが、そのような会社が出て来ている。（ついでに松下の人に聞いたところによれば、差し止め請求でもすれば、ビックリして交渉のテーブルにでもつくだろうと思っていたとのこと。だから、損害賠償請求もしなかったとのこと。しかし、テーブルにつくどころか、徹底抗戦の構えだったので、判決が出るまで行ってしまったとのこと。世間が騒いで２度ビックリとのこと。まあ、本件は直接関係ない。）
なんだそうだ。この日記の特許セクションのエントリはどれも勉強になる。
_ [OSS] IBM、PHPの支持を表明--「Zend Core」バンドルを共同開発へ
言語としての筋なんか関係ない、要するにマーケットシェアが重要なのだ、 という言語屋としては口にしたくない現実を見せつけられる出来事。
いや、やっかんでいるだけです。
_ [OSS] オープンソースプロジェクトと企業間の確執
「フリーソフトウェアプロジェクトPreludeと、プロジェクトのプログラマの一人を起用した企業ExaProtect Technology社の関係が破綻した」という話。
どちらに味方するつもりもないけれど、不幸な出来事だ。 「お金が絡むと難しい」という事例のひとつとして歴史に残るのだろうか。
とはいえ、GPLソフトウェアについて、
Preludeチームは現在、ExaProtect社が今後Preludeを使わないようにするため、拘束力のある合意をExaProtect社と締結しようとしている。
というのは明らかに賛同できないなあ。 これは「ExaProtectがGPL違反行ったから」という理由ではないようだし。