Matzにっき

2003年12月05日

_ [OSS]オープンソースウェイ2003

朝から東京に移動。パシフィコ横浜に着いた時点で最初のプログラムは終了していた。参加した各プログラムはほぼ満席。150名程度の出席があったようだ。

"オープンソース"という考え方：八田真行氏(GNUプロジェクト、東京大学)

聞き逃した。配布資料を見る限り、オープンソースとはなにか、ということを歴史・経緯なども含めて説明していたのかな。

GPLに関する法律問題〜日本法とGPLの整合性〜：小倉秀夫氏(弁護士、中央大学法学部兼任講師)

日本法という観点からGPLを研究したもの。法律って難しい。が、ふだん法律や契約的なものは素人談義に終わってしまうのだが、こういう形できちんと聞けることはありがたい。なんだが意外に楽観的に聞こえたんだけど空耳かなあ。

産業政策から見たオープンソース：久米孝氏(経済産業省商務情報政策局情報処理振興課課長補佐)

官僚という立場から経済産業省のオープンソース政策について語る。久米さんは例の「42件」の人なのだが、ここのところの成長めざましく(おっと失礼か)、オープンソースの事情というのをよく理解してきている。こういう人が恒常的にオープンソース政策に関ってくれるとありがたいんだが、きっと数年でローテーションしちゃうんだろうなあ。

世界各国政府のオープンソース政策と採用動向：比屋根一雄氏(三菱総合研究所情報技術研究部主任研究員)

各国のオープンソース事情と先日のFLOSS-JPの結果の発表。タイをはじめとする各国の取り組みを紹介。日本のオープンソース開発者はまだ数千人程度らしい。また、生計を維持できている人はほとんどいない、とのこと。

オープンソースハッカーズ：まつもとゆきひろ(ネットワーク応用通信研究所特別研究員)

弁護士や官僚に囲まれて、実際の開発者の立場から。まあ、好き勝手なことをしゃべりまくったのだが、まとめると

ハッカーになろう(ハッカー予備軍へのメッセージ)
ハッカーを使いこなそう(スーツ族へのメッセージ)

というようなことかな。スライド。

地方自治体とオープンソース(パネルディスカッション)

長崎、岐阜、沖縄でそれぞれオープンソースを利用した取り組みについて。 3県ともそれぞれの取り組み方が違っていて興味深い(長崎は県庁が直接、岐阜は財団法人経由、沖縄はNPO)。まだ、オープンソースを利用するだけのレベルだが、まあ、最初はそれでよいとは思う。

ところで、「地場のITニーズを地元で満たす」というのがいずれの県も基本方針のように思えたのだが、実は「よそ(特に東京)から仕事をもってくる」という視点の方が有効じゃないのかなあ。すくなくとも、うち(ネットワーク応用通信研究所)ではそうしてるけど。

追記: メディアによるレポート。

_ [OSS]オープンソースウェイ懇親会

中華街「均昌閣」にて懇親会。都合で８時までしかいられなかったけど、大変おいしゅうございました。どうもごちそうさま。

_ [家族]でえと

妻を迎えに羽田空港まで。今晩と明日1日は東京でデートの予定。

_ [特許]非現実的。

おくじさんのenbug diaryから、

個人的印象につっこんでも仕方ない気もしますが、

ソフトウェアを特許の適用外にするというのも(世界の流れから見て)非現実的。

というのは違和感ありまくり。「世界の流れ」じゃなくて、「アメリカとイギリスの流れ」の間違いでは？

というフォローをいただく。

まあ、日本(だけじゃないけど)はアメリカの影響を強く受けていて、無視できないってことがあるんで、「アメリカとイギリス(もそうなの？)の流れ」というのは確かなんだけど、むしろ問題にしてたのは「ソフトウェア特許」という言葉が指しているものが本当はなにかということ。

私が聞いたことが正しければ、 (少なくとも日本では)特許のクレームに「ソフトウェア」と書くケースはほとんどなく、実際には「方式」とか「システム」という言葉で表現されているはず。ソフトウェアというのはその実現手段のひとつに過ぎない。

とすると、「ソフトウェア特許」の定義とは本当はなんなのか。

で、前提として「特許制度そのものを無くすことは現実的でない」とすると (ここまで特許制度を否定する人はあまり多くないようなので)、特許の保護となる対象である「アイディア」のうち、どのようなものを「ソフトウェア特許」とするのか特許の法制度に沿った「言語」で表現するのは非常に困難ではないだろうか。

我々の視点からは「(ハードウェアを含まない)ソフトウェア開発の障害になる特許」と言いたいところだが、私の目から見ても、いくらなんでもそれは適切な基準でないだろう。

だからこそ、今回のEUの決定は「ソフトウェア特許」という言葉でなく、インタフェースやプロトコルは特許の対象にしないという判断だったと理解しているのだが。

日本にいると海外の特許事情はなかなかわからないので(というか、国内の事情もあんまりわかってないのだが)、おくじさんなどからEUの「実情」を聞かせてもらえることはありがたい。

_ [家族]宿泊(と映画)

宿泊はもともと泊まるつもりだった東横インをツインに変更して。意外と快適。テレビで『オーロラの彼方へ』(だっけ、タイトル忘れちゃった)と『ザ・コア』を見る。が、どちらも半端にしか見れなかったので、また今度見よう。

[ツッコミを入れる]

2004年12月05日

_ [教会]命名

末の子の命名の儀式を行う。何度も行うことではないので、すっごい緊張した。とちるし。

おまけに娘は途中で泣き出して、ほとんどパニックだった。泣いたのは4番目にして初めてだなあ。

[ツッコミを入れる]

2005年12月05日

_ 低レベル

[ruby-dev:27399]で、『4434046683』が紹介されていたので、いつか読もうと思っていたが、松江では入手できない。一度だけ見かけたときに捕獲しておくべきだったな。

先週東京に行ったときにも見つからなかった。が、東京オフィスに実物があったので眺めてみた。

なかなか良い本のようなので購入を決意して、Amazonで購入した。

しかし、実物を見たときからわかっていたことだがこの本はなかなか「低レベル」で、読むのがつらい。「低レベル」といっても、デキが悪いわけでも、初心者むけというわけでもなくて、要するに「マシンに近い」ということ。

どうも普段やってることが言語処理系なんてマシンから遠いところにいるせいか、このような「低レベル系」が苦手だ。

実は先日来『1593270038』という本の監訳しているのだが、これも低レベルで大変だった。良い本なのは確かなのだが、私がお手伝いできたのは文字コードに関する部分がほんのわずかだけだった。監訳料はお断りしないといけないかしら？

_ [Ruby] Why Ruby is an acceptable LISP

RubyがLispの良い点を継承しているので、「受け入れられる」Lispになるかもしれないという話。来月発行の「ハッカーズライフ」を先取りされたようなネタ。

具体的には

簡潔な関数型言語である点
実用的なマクロがある

点を取りあげている。前者についてはブロックによる簡潔な高階関数が紹介されている

Lisp:
;; Call 'fn' once for each natural number.
(defun each-natural-number (fn)
  (loop for n from 1 do (funcall fn n)))

  ;; Print 1, 2, 3...
  (each-natural-number
    (lambda (n) (format t "~D~%" n)))

Ruby:
def each_natural_number(fn)
  n = 0
  loop { fn.call(n += 1) }
end

each_natural_number(lambda {|n| puts n })

または
def each_natural_number
  n = 0
  loop { yield n += 1 }
end

each_natural_number {|n| puts n }

実用的なマクロについては、ブロックやリフレクション(たとえばRailsが使っているような)DSL的表現によって提供できると述べている。

しかし、案の定Lispファンから反論が来ていて

Ruby is not Lisp. A Lisp is a Lisp because it’s code is represented as its basic data structure.

RubyはLispじゃない。Lispはコードが基本的データ構造で表現されているからこそLispなんだ

だそうだ。ごもっとも。

しかし、あらかじめ予想したようなエントリがあった。

「Power vs Popularity」では、「確かにLispの方が強力だ(マクロあるし)。では、なぜRubyがはやって、Lispはマイナーなままなのか？また、人気とパワーのトレードはどのくらいが適切か？」について、自答している(作者はLispファン)。

で、結論は要するに「Rails」ということらしい。つまり、Lispにはなんでもできるパワーはもっているが、結局自分でLisp on Railsを作らなくちゃいけない。そんなことしたくないから、Rails(とそれを使うためにRuby)を選んでいるわけだ。

「どこまでできるか」という可能性よりも、「今できる」という現実の方が人気に直結するということらしい。言語屋としてはちょっとさみしい結論だな。

[ツッコミを入れる]

2006年12月05日

_ [原稿] 日経Linux 2006年2月号

えーと、物書きにあるまじきこと、と言われそうですが、私、「年末進行」なるもののこと、すっかり失念しておりました。

正直、普段の月よりもずいぶん早く原稿の催促を受けて、少々パニクっております。しかも、先月のうちに考えていたテーマについて、いざ書こうと思ったら、全然筆が進まない、という。

悩んだ揚げ句、当初考えていたのとはまったく違ったテーマになった。今月は「バージョン管理」。RCSとかCVSとかSubversionとかgitとかの話。ここ数ヶ月Rails周辺について話してきたけど、正直、ちょっと飽きてきたので。まだ、Rails本体の話になってないのに。

_ チープ教育

我々が子供のころには、コンピュータ(「マイコン」と呼ばれていた)は、まだなにもできない存在で、私と同世代は、その上でBASICでASCIIキャラクタを動かして「ゲームのようなもの」を作ることでプログラミングを学んできたと思う。

しかし、今はそんなことはできない。コンピュータはチープなものではなくなり、プログラミングの対象ではなく、道具に成り下がってしまった。私の子供はコンピュータのユーザではあるがプログラマではない。プリインストールされているソフトウェアが提供してくれている処理を使うことはできても、コンピュータをコントロールすることはできないし、新しい可能性を切り開くこともできない。

が、リンク先のエントリの

ということはつまり、今チープな作品に出会える場を探すとすると、技術的な制約があるなど何らかの理由で「へぼくても許される感」が残っているところにこそ、チープ教育の素地があるのかな、と思います。

今の学生は、作品を作ることにおいて、「無意味なポジティブさ」を何から学ぶのでしょうか。携帯電話の制限された環境の中でちっちゃいゲームを作るのもいい。ブログも文章作品のチープ教育に一役買っているような気がします。 YouTube や iMovie や携帯についたビデオカメラは、映像作品のチープ教育を手助けする可能性を秘めています。チープ教育の芽は、探せばまだいたるところにありそうです。

というのは、希望が持てた。チープ教育の「場」の提供。これはプログラミング教育における新しい視点かも。知ってる人にとっては「とっくにわかってるよ」ってことかもしれないけど。