短い期間ではありましたが、 ESPer2007 にお呼ばれして、しばらく日本に滞在してきました。 まずは、事務局のみなさん、どうもお疲れさまでした。 また、ヨタ話に付き合ってくださった参加者の方々、ありがとうございました。 そんな内容でいいのかと脱力したに違いない、他の発表者の方々、ごめんなさい。
内輪では少し話しましたが、実を言えば、 かずひこさん に下ネタ禁止令が施行されていたため、せっかく考えた数々のネタが討ち死にしてしまい、かなりネタに苦しんでいました。 仕方がないので、Googleさんをネタにしてしまいました。 悪意はありませんので、笑って許してやってください。 ちなみに、自分で載せた国旗を判別できなくなったのは天然ボケであって、 ネタではございません。
うーん、しかし、井上さんは凄かったですね。 みなさん、プレゼンがうまいなあと本気で感心していたのですが、 絶対追い付けるわけがない天才を見たと思いました。 格が違いすぎて、参考にもならない... おそらく発表者中、最年少だったと思うのですが、 確実に一番すごい発表でした。 優秀な若い人を見ることができるのは、いつでも良い気分がするものです。
若いと言えば、 太田さん がすげーきれいな肌をしているなあと感動したり。 いや、そういうことを言うと、気味の悪い親父だと思われ兼ねないので、 決して口にはしませんでしたが。 言葉に出していることと、頭の中で考えていることが全然違うんですよね。 でも、同性愛者ではありませんので、念のため。
プライバシーに関わりそうな事が多いので、後で話していた内容について触れるのはやめますが、 いろんな人とお話できて、参考になることも多かったです。 もっと怖がって近づいてきてくれないのではないかと想像していたのですが、 案外温かく迎えてくださる方がたくさんいて、随分と助かりました。 おそらく30人以上と話をして、懇親会では飯を一皿しか食べられないという有様で、 二次会では食ってばかりいました。
ところで、プレゼンの資料作りで参考になるかもしれないことを書いておきます。 著作物には権利関係の問題がありまして、 特に絵や写真は自由に扱えないライセンスのものが多いように感じます。
白抜き地図を探すのに大変苦労しまして、 結局 Freemap.jp のものを使わせていただきました。 ここのものは非常に自由に配布されていて、大助りです。
国旗は 外務省：世界の国旗 のものを流用しました。 ここは本当に使っていいのか、よく分かりませんでしたが、 税金を投入しているのだから、まあいいだろうと勝手に判断しました。 ただし、EUの国旗は外務省にはなかったので、 Europa のものを使い、サイズを外務省と同じに調整しました。
キーウィは Wikipedia から流用しました。
それ以外は、自分で作成・撮影したものです。 あ、後、 うちの会社 の素材も流用してましたね。
基本的に、私のプレゼンはべらべらダベり続けるので、 大抵の聴衆は眠くなってしまいます。 それをちょっとでもマシにする工夫は、かならず絵を入れること、 スライドの内容を大胆に遷移させること、です。 聞いている人が、一体これは何なんだ？と不思議に思ってくれるような、 そういう印象を与えられたら、と考えています。 棒を使って、体を動かしていくというスタイルは、 井上さんの真似を即興でやろうとしたのですが、 マイクと指示棒とスライドの操作の、三つを同時にやるのは大変難しいことなのだとよく分かりました。 私にはやっぱりできそうにもありません。
そんなこんなで、また次にお目にかかれる機会を楽しみにしてます。 ごきげんよう。
ひまがねえー。
あー、思い出した。 実はフランス滞在五年目を迎えました。 が、書くのを忘れていました。
えー、今年度の抱負を。
どんなに忙しくとも、どんなに辛いことがあっても、 ハックの喜びを忘れない生き方を見出す
もうフランスと全然関係ない目標です。 技術的に多少は解決できそうな気もしますが、 それ以上に精神的余裕をいかに確保するかがポイントとなりそうです。 今年度こそは、今まで作りたいと思っていて放置していたアイデアや、 新しく思いついたアイデアを形にしていきたいと思います。
ESPer2007で、ukaiさんがおっしゃっていたように、 どんどんやったことを出していく、ということを重視しないといけませんねえ。
GPLv3化について、 ようやく話に決着をつけた。 GRUB Legacyはv2のまま放置、 GRUB 2はv3に移行、ということで。 RMSも同意してくれたので、後はちまちました作業を繰り返して、新しいバージョンをリリースすればいいだけ。 移行スクリプトももらったので、目で確認するのが一番時間がかかるってことになりそう。
ちなみに、GNUでは、特別な事情がない限り、今月中にGPLv3へ完全移行することになっている。 その結果、どの程度問題が発生するかは未知数ではあるが、 GPLv2-onlyのコードを除けば、非互換性の問題が新たに発生することはないはずなので、大勢には影響しないのではないだろうか。 少し話題の出ていた LZO については、なぜか2.02においてGPLv2-onlyになってしまっていたが、 次のバージョンではGPLv3が適用されるとのことである。
GPLv3化しました。 来週にリリースします。
Shaun of the Dead に続く、Simon Pegg と Edgar Wright のコンビによる作品、 Hot Fuzz を昨日観てきました。 幸い、この作品は VO （音声そのまま）で上映されることがわかったので、 喜んで行ってきました。 前作がすばらしかっただけに、相当期待していきましたが、 期待を裏切らない出来栄えです。 特に、前半のパブで18未満を徹底的に追い出すシーンとか、 後半の肉屋相手に戦うシーンとか、 めちゃくちゃ笑えました。
久々にとってもリラックスした気分になれました。 すかっとした気分になりたい人は是非観てください！ と言いたいところですが、この作品は果して日本では上映されるのでしょうか？
ペア・プログラミングって、教育目的以外で、 優れた技術者にとって、何か役に立つんですか？ とかいう話をしていたけど、 書くのが面倒くさくなってきたので、まあいいや。
この前会社で少し話していたことではあるが、 自分でもあまりしっくりこない部分でもあるので、 ここにまとめておく。
プログラミングにおいては、 適宜処理や定義を分離し、複雑度を局所的に低下させる必要性が生じる。 それによって、人間が理解しやすくなり、管理しやすくなるだけではなく、 コンピュータ的にも部分的な更新をしやすくなったり、 コードをコンパクトに収めることによって、キャッシュ効率が上がるというような効用も存在するかもしれない。 代表的なコンセプトは、ライブラリやモジュールだろう。 ある特定の機能に専念し、直接アプリケーションを構成するのではなく、 あくまでより上位の階層を支援するわけだ。
階層的な考え方としては、水平方向と垂直方向の両方が存在するわけであるが、 ここでは垂直方向について考えてみたい。 まず、根本的に下位層は上位層よりも情報量が少ない、ということを前提としてよいだろう。 例えば、 libcurl のようなネットワークプロトコル用のライブラリは、 その上位において、botが開発されるのか、 インタラクティブなブラウザが作成されるのか、 そういったことは分からないし、分かるべきではない。 十分に汎用的な設計を行う必要があるし、 それゆえに、どう使われるかを決め打ちすることはできないのである。
こうした性質はアプリケーションレベルまで到達しなくても、多々出現する。 ここで、一つ具体的な例を考えてみる。 言語は何でも同じ事なのだが、 仮にPythonを使うことにしてみる。
class Picture(object):
def __init__(self, data=None):
# Do something here.
画像を操作するようなモジュールを設計している。 画像の初期化のため、データを与えることができる。 さて、問題は、このdataがどこまでサポートするべきなのか、ということなのだ。
一つの考え方としては、バイナリデータさえ受け取ればいいので、 strしか受け付けないとすることだろう。 これは非常にシンプルで、それなりに使える考え方である。 あらゆるデータが最終的にstrに変換されるのであれば、 これでは機能的に足りない、という事態もありえない。
その一方で、もっとよしなに扱ってほしいという考え方もありうる。 例えば、fileオブジェクトも受け付けてほしい。 そうすれば、openして、そのまま渡すことができる。 あるいは、StringIOでも構わないではないか。
この考え方を押し進めていくと、 実は大変なことになりはじめる。 なぜかというと、他にも似たようなデータの表現手法はたくさん存在するからなのだ。 例えば、Pythonのarrayモジュールには、より効率的なバイナリデータを扱う手段として、array型が提供されている。 これもサポートした方がよいのではないか？ あるいは、ユーザ定義のクラスだったら、どうなのか？
この問題に対する解決手段としては、いわゆるpolymorphismを利用して、 同じ名前のメソッドで、最終的にstrオブジェクトが取り出せるようにしておけば、 上のPictureクラスは具体的なことを何も知らなくて済む、ということが考えられるであろう。 しかし、それぞれのオブジェクトの振舞は必ずしも一致しているわけではなく、 それにはそれ相応の理由があったり、なかったりする。 実際、Pythonのfileオブジェクトに対して、strを実行しても、ファイルの中身が返ってくるわけではなく、 RubyのIOオブジェクトでもto_strは存在しなくて、readと同じになったりはしない。 結局、いくつかのパターンをPictureクラスに組み込まないことには、 さまざまなオブジェクトに対応することはできない。
私が、個人的にそうすることに抵抗があるのは、どう使われるべきかを下位に埋め込む結果となるからだ。 そういうことをやりすぎると、逆に上位が下位がどう実装されているのかを知らないと、 うまく実装できなくなってゆく。 例えば、どのようなメソッドを持っているかを調べて、 それによって処理を切り替えるとしよう。 すると、もしユーザが独自のクラスを作り、そのインスタンスを渡したくなったら、 そして、そのクラスが検査対象となるメソッドを複数持っていたら、 一体何が起こるのだろう。 検査の順番に依存したりしないだろうか。 仮に依存していたとしたら、どうやって解決するのか。 結局自前で渡す前にstrに変換せざるをえないのではないか。
私は、上位が下位を強く、内部実装を意識させられる状況がたまらなく嫌いである。 それでは隠蔽化が破綻しているわけであって、 まさにお節介というべき状況なのだ。 このような状況は業務アプリケーションでは頻繁に見られるのだが、 実際に何がなされるかがプログラム内だけを見ていては収まりがつかなくて、 結局その上位の人間の意思決定こそが重要な局面が増えてくる。 もしもプログラムが多くを前提として作成されていると、 究極的には人間がコンピュータにお伺いを立てて、 プログラムの都合によって、人間の方がやりかたを合わせてあげない等という、 本末転倒な事態に発展するのである。
その一方で、もっと適当にやってくれる方がいいじゃないか、という考え方も否定することが難しい。 例えば、ユーザ定義型は知ったことではないが、 せめて組込みのクラスぐらいは処理してほしいと思ったりするわけだ。 しかし、ここのところの線引きはひどく困難だ。 バージョンが上がるにしたがって、 組込みのクラスが増加したら、それも加えていくのか。 あるいは、組み込みではないが、頻繁に利用されているライブラリはどうなのか。 はっきりした、常に有効な方針を決定することは一筋縄ではいかない。
現時点での私の方針は、とにかく一つのことに専念させる、ということ。 確かに、もっと適当にやってくれたらいいと思うこともあるが、 そこはぐっと我慢する。 どうしてもそうしたければ、同じメソッドにつっこむより、 新しいメソッドを作る方がいい。
これでいいのかどうか、まだよく分からないのだが、 もっとうまい考えが浮かぶまでは当分この方針を採るしかないと思っている。
脱線すると、 同じ理由で私は自動プログラミングというものを全然信じていない。 プログラムに普通書かない部分までつっこむ必要が生じるわけで、 そんなことが本当に可能だとは思えないというか、 仮にできたとしても、ちっとも使いやすくならないという直観があるのだ。 人間が打ち込む情報を減らす工夫はまだまだできそうだとは思っているけれど。
_ zunda [発表、拝見したかった〜 しかしどうして無線のピンマイクは使われないのか、発表のたびに思います。マイクが服に着けば手..]
_ ゆきち [どうも、発表ありがとうございました & お疲れさまでした。短い時間でしたが、楽しい一時を過ごせて感激です。「あの」奥..]
_ okuji [そうですねえ。ピンマイクはほとんど誰も使ってなかったですよね。音の入りが悪いことがあるからなのか、単にいかにもマイク..]
_ kzk [えーっと、日記で公表される方が困ります(笑) それはそうと、色々面白い話や参考になるお話を有難うございました。また日..]
_ amatsus [ごちそうさまぁ。毎回おいしいもん食わせてもうて恐縮です。お昼入ったお店、明治創業で芸能人もお忍びで来るとか。どうりで..]