天使やカイザーと呼ばれて

サイン（案）

妻と一緒に考えるも、どれもいいし、「これだっ！」という決め手がない。でも考えるのは面白かった。

Posted:

10.26.2008

Category:

Etc

タケコプター

Personal Helicopterの試験飛行の動画である。音がすごいけど、ちゃんと制御されていて、操縦はそう難しくなさそう。途中で片手になる場面もあるし、もしかしたら自動車の運転よりもシンプル（セグウェイ並み）じゃないだろうか。

Posted:

10.20.2008

Category:

Etc

ニッチスペース

無事に完成を迎えて今週から実際に住み始めている我が家において、設計の時点で僕がどうしても付けたかったものがあった。それが「ニッチ」スペース。壁を一部くり抜いて、ちょっとしたものを飾れるようにするスペースだ。我が家のニッチスペースは、玄関を外から入ったときの正面に見える壁と、階段を2Fに登り切ったときの正面の壁の2カ所に作ってある。
まず、玄関正面のニッチは、透明なリンゴを3つおいてシンプルな雰囲気を出してみた。

From 自宅建設080903

下からライトアップすると、以下のような感じになる。

From 自宅建設080903

次に階段正面のニッチスペースだが、ここは最近の思い出の品をいくつか飾ってみた。

From 自宅建設080903

左から、

• Mash up Award 3rdの副賞でもらったDukeシューズ。
• Googleのロゴの背景の手前に、クリスタルDuke。
• Mash up Award 3rdの賞状。
• Sunからもらったあぶら取り紙と、Google Developer Dayやデベロッパー交流会の時の参加証。

と並べてある。このニッチスペースも、ライトアップが可能だ。

From 自宅建設080903

これからもっともっといろいろなことをやって、このスペースに並べていきたい。僕のちょっとしたモチベーションだ。

Posted:

09.04.2008

Category:

Etc

XMLは未だに1.0？

OpenSocial JavaScript APIを実際に使って動作確認を最近数多くこなしているが、その際に気がついたことがある。
「XMLって、未だにversion=”1.0″としか書いたことがない」
皆さんは、version=”1.1″ と書いたことがありますか？「version=”2.0″にいつなるんだろう？」とか考えたことはありませんか？
これ、実はすごいことで、最初のXML 1.0の勧告がW3Cからされたのは、今をさかのぼること何と10年前の1998年2月10日。途中でXML 1.1の勧告やXML 2.0に関する議論が行われたこともあったけど、10年という長い間、Version 1.0がこのネット時代を支えてきたことになる。
ではXML 1.0の歴史は10年間なのか？というと、実際には半分嘘。XML登場以前の約12年間、その前身となったSGMLが徐々に成熟してきた成果がそのままXMLに反映されているために、SGMLも含めたXMLの歴史は、すでに20年以上も経過していることになる。つまり、「XMLって10年も同じバージョンなのか、すごいなー」という印象ではなく、実際には「XMLって20年以上も同じバージョンなのか、すごいなー」という印象を持つべきかもしれない。ちょっと乱暴だけど。ちなみに、SGMLの前身にGMLという仕様もあり、GMLは1960年代から1970年代にかけてIBMの社内文書で使われていた。文字情報のマークアップという発想は、僕が生まれた1975年以前からあったということになる。
昔話はさておき、XML 1.0が10年もの間使われ続けてきた歴史は、個人的には「最小限の仕様策定という方向性が正しかった証明」と言えるのではないかと思う。つまり、SGMLやDSSSLなどの歴史を踏まえて、重量級な仕様ではなく最小セットの仕様とすることで、XML 1.0の仕様を崩すことなく新しく外部の仕様で補完してあげることで未知の仕様追加に対応する、といった今日では当たり前な考え方を最初に実証した例ではないかと考えられる。
YAMLなどのアンチXML仕様が一般的な大多数になっているかというと、そうはなっていない。やっぱりXMLはVersion 1.0のまま、今日もその利用は拡大し続けている。version=”1.0″と書くたびに「XMLの仕様って、やっぱりすごいんだなぁ」と思う今日この頃である。

Posted:

09.02.2008

Category:

Etc

新居が完成しました！

今年の5月の状況が以下の写真。

そして先月末の状況が以下の写真。

というわけで、2月より計画してきた「新居建築計画」第1弾がこのほど完了し、今週から住み始めた。それはそれは困難な問題が次から次へと出てきたけど、一つずつクリアしていって、なんとか引っ越すところまで来た。
建築風景の写真を公開しているので、興味のある方は以下よりご覧ください。
http://picasaweb.google.co.jp/yoichiro6642/
これで終わりではなく、続く第2弾として「外構工事」が控えている。落ち着くまでは、まだまだかかりそうだ。

Posted:

09.02.2008

Category:

Etc

Firefox3.1はJITコンパイラを搭載予定

IE以外のWebブラウザとしてすっかり定着した感を個人的に勝手に持っているFirefoxだが、次の3.1ではJavaScriptコードの実行を高速化するために、JITコンパイラが搭載される予定らしい。
「JITコンパイラ搭載でJSを大幅高速化へ、Firefox」 – @IT
http://www.atmarkit.co.jp/news/200808/25/firefox.html
ベンチマーク結果では、約1.83倍の速度向上を実現したとのこと。
Javaの歴史が「JavaVMの速度向上」の歴史であることは有名だけど、JavaScriptも同じ道を地道に歩んでいるということなのだろう。でも、Javaの高速化技術とJavaScriptの高速化技術を比較するのは、ちょっと違うのか。むしろ、JRubyの高速化技術とJavaScriptの高速化技術が、似ているのかな。詳しくないのでよくわからないけど。
とにかくFirefoxが速くなるのは非常に喜ばしいことだが、これで手放しに喜べないのがWebの現状。いくらFirefoxが速くなったとしても、IE7、Safari、Opera、その他のいくつかのWebブラウザを無視して開発をすることはできない。
なにせ、IE6がまだ現役な今日を、誰が予想できただろうか？ちょっと調べてみても、IE6の英語版の登場は、2001年8月。すでに7年も経過している。というか、7年も最新のWeb技術を動作し続けているIE6のすごさに、改めてびっくり。それにしても、そろそろIE6は御退官願いたいのは、JavaScriptに関わる全ての人々の願いではないかと。
結局、全てのOSがWebブラウザの標準搭載をやめない限り、Webブラウザ乱立状態は続く。競争原理が働くことは喜ばしいことなんだけど、OS提供側が特定のWebブラウザに囲い込みを行うような行為（標準搭載をすること自体これに該当すると思う）は、そろそろやめて欲しいと考えるのは、僕だけだろうか？

Posted:

08.26.2008

Category:

Etc

フレームワークと言語とコミュニティ

例えばJavaで言えば、SpringFrameworkだったりSeasarだったりStrutsだったりWicketだったりClickだったり、Java言語が持つ言語仕様とそれがもたらす特性をフルに生かしたフレームワークの上で、多くの開発者がアプリケーションを作成する。
例えばRubyで言えば、Ruby on RailsだったりMerbだったりCampingだったりramazeだったりVintageだったり、Rubyが持つ言語仕様とそれがもたらす特性をフルに生かしたフレームワークの上で、多くの開発者がアプリケーションを作成する。
例えばPythonで言えば・・・例えばHaskellであれば・・・例えばPerlであれば・・・なんだろう？
最近では、言語が先行して流行ることは少なくて、何らかのフレームワークが流行った結果、その基本となる言語が注目される、ということがほとんどだと思う。で、流行したフレームワークについて、コミュニティが形成されて普及がさらに進む、という傾向が強い。つまり、言語のみに関して大きなコミュニティが形成される、というよりは、フレームワークに人が集まるという傾向だと思う。
さて、そうやって形成されたコミュニティは、もちろんフレームワークを担いでいるわけで、フレームワークの良さを広く一般に伝えていくことはとても良いことだと思う。しかし、いつの間にか、フレームワークの話ではなく、その基本となる言語に話がシフトしてしまっているコミュニティが見受けられる。つまり、「フレームワークの良さ」が、あたかも「言語の良さ」として語られてしまっている、ということ。
これは、必ずしも真ではない。例えば、フレームワークのシンプルさは、あくまでフレームワークがそうシンプルにしてくれているだけで、言語がシンプルかというとそうではないこともある。フレームワークを使うからこそ開発者フレンドリーになるはずなのに、言語そのものをコミュニティメンバーや一般開発者に「簡単だから」的な言い方で勧めている、とかもそう。
こういったことを信じて参加した人にとって、非常に良くないことだと思ってしまう。詐欺に近いんじゃないかと。
フレームワークを通じて、より低い場所、つまりそれを構成する言語の特性を知ることは、開発者の技量を深めるための非常に良い手順である。こういった話を通じて、フレームワークから見える言語の良さを伝えていくのであれば納得できる。例えば、フレームワークのコードリーディングとかをコミュニティ内でやっていたりする、とか。でも、フレームワークを使うだけ、それだけで「この言語はいいよ」と言うのは、ちょっと違うんじゃないの？と思ってしまう、個人的にどうしても。
で、そういった意見がコミュニティの外野で聞こえてきても、コミュニティがそういう意見を聞かず、自己都合の理由を付けて軌道修正をしない、というのも、残念ながら僕は見たことがある。
例えば、僕はRuby on Railsというフレームワークを使ってアプリケーションを開発し、その結果Ruby on Railsの良さを少なくとも体感している。でも、それで「Rubyできます。」とはどうしても言えない。「Rubyでプログラミングできます。でも、Ruby on Railsを使った開発です。」と必ず言うようにしている。だって、Rubyの言語特性をちゃんと伝えるだけの背景を知らないわけだし、Ruby on Railsによる恩恵を受けた上での開発経験なんだから。
僕は、コミュニティの存在は非常に大事だと思うし、OSS全盛の今日だからこそ、コミュニティ主導という流れは主流になっていると思う。でも、間違ったメッセージを発信してしまうことは、人間がする活動の集合であるコミュニティにとっては、避けて通れないことだ。そして、それに警告を打ってくれる外部の人は必ず登場するわけで、コミュニティはちゃんとそういう声に耳を傾け、自身の活動の軌道修正をして欲しい。そうじゃない「オレオレ」コミュニティかどうかをちゃんと見極めた上で、コミュニティに参加するように多くの人がなって欲しい。そして、外部がそういう声を出しやすい環境を、コミュニティの主要メンバーはちゃんと作っていくことを心がけて欲しい。
特定のコミュニティに対して、ということではなくて、上記のような状況って少なからずどのコミュニティにもあると思う。今後ますます影響力を持つであろうコミュニティという形成物に関わる人々は、常に自問自答や外部意見の取り入れと反省を繰り返して、方向性がぶれず、間違った方向に広がらないような運営を期待したいな、と思った2008年の夏である。

Posted:

08.20.2008

Category:

Etc

続： コミッタは自分で名乗り出てなるものではない

「コミッタは自分で名乗り出てなるものではない」の内容に関して、ひがさんを始め、多くの方々のご意見をいただくことができて、とても嬉しい。ありがとうございます。
さて、

それが何故「コードに対する貢献をしたんだから、コミッタにしてくれ」なんて発想になるのか、僕には理解できない。

これは、
「コミッタには気楽になっていいんだよ」 – ひがやすをblog

よういちろうのblogをみると「コードに対する貢献をしたんだから、コミッタにしてくれ」っということなので、行動してるジャン最初に。好きだからこそ、コミッタになりたいと思うんでしょ。

と指摘されている通りで、「貢献してるんだからコミッタになりたい！」ということはもちろん主張していいことだと思います。「貢献」という言葉の意味が「不具合パッチ程度のもの」だとすると、僕の尺度からするとそれはコミッタになるための条件としては足りないと思っているので、rejectされるかな、と。もちろんこの尺度はOSSによって違うので答えはないだろうけど、自分の意見としては、contributionのレベルに応じてコミッタになれるかどうかが決定されるプロセスがちゃんとあったほうがいいのではないかな、ということを言いたかっただけです。
あと、説明不足を棚に上げて言うと、「自分で名乗り出るかどうか」はどうでも良くて、貢献した実績があるかどうか、という点が僕が言いたいことです。いきなりコミッタになる前に、できることってあるんだよね。それをすっ飛ばして「コミッタになりたい」と言うのは、その後の展開が「そんなこと言われても、あなた誰ですか？何ができるんですか？その前に何かできることがありませんか？」と言われてしまうと思うので、違うよね、と。
何はともあれ、文章が悪すぎた。。。反省。
「まずは貢献をしましょうね」ということが言いたくて、「名乗り出るかどうか」を言いたかったんじゃなくて、「ある程度の貢献がないとコミッタにはなれないと思います」と思うわけで、「何の貢献もせずにコミッタにしてと言うのは違いますよ」ということです。名乗り出るかどうか、が多くの人に主題と捉えられてしまったのは、僕の文才のなさの極みです。

Posted:

08.05.2008

Category:

Etc

コミッタは自分で名乗り出てなるものではない

と思う。もちろん、自分自身で新しい何かを作った時は、自動的にそのプロダクトのコミッタに就任しても良い。しかし、他人のプロダクトに対して、
「コミッタにならせてください」
っていきなり名乗り出るのは、OSSの世界を知らないにも程がある。
OSSは、もちろんソースコードが公開されているために、そのメリットとして「誰でも修正コードを作って適用できる」ということがあげられる。しかし、それが即コミッタ就任につながると思っている人がいるようだが、それは大きな勘違い。つまり、公開されたコードの不具合や改善策を提供することは、「OSSの利用者に課せられた当然の行為」であり、本来であれば、そのOSSプロダクトを利用する人全員が行うべき（少なくともそれを認識しておくべき）ことである。
それが何故「コードに対する貢献をしたんだから、コミッタにしてくれ」なんて発想になるのか、僕には理解できない。
あとからコミッタになるということは、利用者から開発者に昇格する、という非常に珍しい話。そのためには、対象プロダクトに対して、大きな貢献がその人によってもたらされるべきだし、そういった活動が「既存のコミッタから認められて」初めて昇格に値する話である。つまり、自分から「コミッタにならせてください」というのではなく、「コミッタになってください」とお願いされなければ、きっとコミッタになったとしても何も貢献できないし、必ず幽霊になる。だって、認められていないということは、貢献してくれる、という裏付けがないってことなんだから。
逆の言い方をすれば、既存のコミッタは、安易に誰かをコミッタとして任命してはいけない、ということだと思う。そのプロダクトを育ててくれる貴重な人を見つけるためには、その人のやる気だけで決定するのではなく、ちゃんとした裏付けがあって初めてコミッタとして任命すべき。その判断を誤ると、プロダクトに負の貢献をされたり、幽霊になって名前だけ使われる、という結果を招くことになる。
大好きなプロダクトがあって、そのコミッタとして真剣に参加したいという気持ちがあるのであれば、自分から名乗り出なくても、それ相応の行動が既存コミッタの目につくはずだ。そうやって本当のコミッタが生み出されなければならない。そのためにも、すでにコミッタな人、これからコミッタになりたい人、その両方がOSSの文化を正しく理解した上で行動するべきではないか、と思っている。
今日ではOSSの企業への浸透および開発への参加も普通になってきた。今一度、OSSとはどういう世界で成り立っているのかを、IT業界全ての人間が理解しておく必要があるのではないだろうか。

Posted:

08.04.2008

Category:

Etc

母校にて3年生向けに講演をしてきました

7月17日、昨年に引き続き、今年も母校であるいわき明星大学の電子情報学科3年生向けに、講演を行ってきた。

昨年から今年にかけての出来事を中心に、IT業界の現状と面白さを学生に伝えるべく、いろいろな話を試みてきた。幸い、あまり寝ている学生も出ずに、興味を持って聞いてくれた模様。
「英語はやっとけよ」というメッセージ、どれだけの学生の心に届いただろうか。。。

Posted:

07.19.2008

Category:

Etc