Matzにっき

_ [Ruby] The Ruby Virtual Machine

一年の計は元旦にあり、という言葉もあるが、 今年はYARVのSubversionリポジトリtrunkへのチェックインから始まった。 ささだくんは本気である。 年末はこれの作業で終わってしまったのではないだろうか。

で、これで名実ともにYARVがRubyの正式インタプリタエンジンとなることが 確定したので、もはやYet Anotherではなく"The Virtual Machine"と呼ぶべきではないか、 という話をどっかで読んだ(参照元を記録しておくべきだったなあ)。

賛成である。今後はTRVということで、ひとつ、よろしく。

_ [Ruby] matzrubyブランチ on Subversion

YARVチェックインと同時にmatzrubyというブランチを作ってもらうように依頼した。

これは、今までCVS上で1.9が果たしてきた役割である 私の「実験場」の役割を果たす。

というのも、現在は(元)YARVがまだ安定しないので、 私の変更を突っ込むとますます不安定になる危惧があることと、 私自身が(元)YARVの構造を理解していないので、 インタプリタコア(eval.c)に関連する修正を(元)YARV上で実現できないからである。

というわけで、matzrubyブランチは上記の二点(YARV安定と私のYARV理解)が 解決されるにつれてだんだんとフェードアウトする運命にあると認識していただきたい。

とりあえず、

• シンボルの再分離
• ローカルインスタンス変数
• クラス変数
• privateメソッドの探索方法

くらいまではmatzrubyブランチで行われるのではないか、と。 各項目の詳細については後日。

一方、m17nはtrunkで行われるべきだと思う。 コアと関係ない(はず)だから。

_ 大当たり

夕食の準備が面倒になったので、 近場のファミリーレストラン(特に名を秘す)に食事に。

そしたら、私の注文した鍋物の底から付箋紙が出てきた。 全部食べてから気がついたよ。 新年早々から大当たりだよ。 今年を暗示しているのか。 当たるのが良いことばかりだといいのだが。

で、奥から登場したチーフなる人がどのように対応するのか 興味津々で観察していたのだが、 「すみません」、「申し訳ありません」と繰り返すばかりだった。 口だけなら簡単に言えるんだがなあ、と思いつつ、 一応謝罪は受けておいた。

レジの前でまた「チーフ」が再登場したので、 お金を受け取らないところまでやるのかなと思ったのだが、 やはり謝罪を繰り返すだけだった。 どうも彼にはそれだけの権限はないようだ。

まあ、興味深い経験だった。 もう当分行かない*1。

_ 一族集合

千葉に嫁いでいる妹以外の一族が集合。

結構な人数になる。新年の挨拶と食事。 年末には風邪を引いたものもいたようだが、 今はだいたい大丈夫のようだ。

昼食はおいしかったなあ。

昼食後、(別の)妹の新築の家を見に行く。 たいそう立派なものが建っていた。 最近の家らしく間取りなども使いやすそうになっていた。

_ [Ruby] リクルート　エンジニア適職フェア

「スペシャルトークイベント開催」だそうだ。

(Googleの)鵜飼さんとのパネル。 実はどんな話になるのだか、 あるいは「エンジニアの適職」に役に立てる話が出来るのか ちょっと疑問もないわけでもないのだが、 まあ、そういう生き方をしている人もいるということを 冷やかしてもらえればそれでいいのかな。

末の弟にも「兄ちゃん、リクルートのイベントに出るんだってね」と言われた。

_ フニクリフニクラ

義弟から「フニクリフニクラの「火の山」ってどこだか知ってますか」と聞かれて、 「ベスビオス火山」と即答したらクスクス笑いだした。 「これは世界最初のCMソングと言われててねぇ」と続けたら爆笑しはじめた。

最初、わけが分からなかったが、妹の説明によると、この疑問が出た時に 義弟は「きっとお義兄さんなら知ってるよ」と言ったそうなのだが、 その通りになったのがおかしかったとのこと。 さらにそれを越えて蘊蓄を語りだしたので、予想以上のことに笑いが止まらなかったのだか。

うーん、喜ぶべきなんだろうか。

_ [言語] Groovy 1.0 is there

Groovy 1.0がリリースされました、という話。

なんか最初のころとちょっと印象が違うんだけど(特にdefの使い方とか)、 これが多くのユーザの意見を集約した結果、なのだろうか。

その点Rubyは設計者が頑固なので、他の人の意見によって左右されることは少ない、かな。 でも、設計者本人がかなり考え方が流動的なような...。

_ [Ruby] nkf-utf8

手元のcalkiがUTF-8の「》」相当の文字(U+8BB)を含むエントリが文字化けするので、 nkf-utf8のソースを見てみた。 どうも自動判定の優先順位がEUC-JP,SJIS,JIS,UTF-8で固定されていて、 EUCの範囲内に収まる文字列はすべてEUC-JPとみなすことになっている。 で、UTF-8の「》」はEUC-JPの「損」と同じバイト列なのだ。

どうしたものかなあ。入力の文字コードははっきり分からないので ある種の判別と変換は避けられないしなあ。

今後、M17Nを取り込むにあたって もっと賢い自動判別がは必要だろうなあ。自動判別は正しくない判断をする 可能性があるから、なるたけ避けたいと言っても、実用のためには 避けて通れないだろう。

優秀なコード判別アルゴリズムはあるのかな。 Emacsのコード判別は結構賢いな。 上記の「》」と「損」も区別できてるし。

_ [Ruby] Headius: New JRuby Compiler: Progress Updates

ホリデーシーズンにJRubyはちゃくちゃくと進化中、という話。

実際にServer VMを使った場合には、 場合によってはC Rubyに比肩しうる性能が出る(こともある)ということだ。

今までは「Bignum計算なら速い」とか、JRuby自身の性能によるものではない 点でしか性能勝負はできてなかったんだけど、 今回はわりとアグレッシブな最適化(再定義されてない整数メソッドの直接呼び出しとか)を 行ったようだ。

JRubyってのは非常に面白いポジションにいると思うんで、 かれらの頑張りには今後も期待したい。

_ [Ruby] ユメのチカラ: マルチプロセッサ向けソフトウェアパラダイムとは？

この間のメニーコアのエントリを連想させる内容。さらに吉岡さんのはてな日記の方では

Rubyあたりでマルチコアに対応した実装をハックしちゃうというのも面白いかなあなどと妄想しているがあくまで妄想である。そこの人、本気にしないように。

とある。いやあ、私もそういうの欲しいなあ。 私自身は並列は得意じゃないので、できそうにないけど。

そういえばささだくんの専門はそっちだったっけか。

_ [Ruby] Class Variables

「落とし穴」のエントリ以来、 ずっと考えていたのだが、ようやっと結論が出たような気がする。

今までクラス変数は、登場した場所を囲むもっとも内側のクラス(ただし、特異クラス定義は除く)に所属する、というのがルールであった。 変数がどのクラスに所属するかは静的に決定した方が分かりやすいだろう という判断からである。

しかし、「落とし穴」と呼ばれるからには、この判断は間違っていて ユーザの暗黙の期待を裏切っている(悪い驚き)である可能性は否定できない。

新しいルールはこういう風にしようと思う。

1. メソッド内部のクラス変数はそのメソッドを定義するクラスに所属する。 特異メソッドの場合には特異クラスに(1.8とは非互換)。
2. クラス定義内部のクラス変数は定義中のクラスに所属する
3. クラス変数の参照(とdefined?チェック)において、 そのクラスに当該の名前のクラス変数が定義されていなければ、 a) そのクラスがクラスの特異クラス(メタクラス)ならば、 そのクラスとさらにそのスーパークラスを検索する。 b) そうでなければ最初のクラスのスーパークラスを検索する(現状の1.9ではエラー)。
4. 代入では、スーパークラスにさかのぼらない。 スーパークラスで同名のクラス変数が定義されていても自クラスに代入する。 サブクラスからはクラス変数は更新されない

こうやって文章にすると結構複雑なのだが、どうやらこれが多くの人が暗黙に期待するルールに一番近いようだ。

_ asahi.com：米共和党、ロムニー氏が大統領選に始動

来年のアメリカ大統領選挙候補の話。 いや、単なる身内びいき。

０２年のソルトレーク冬季五輪組織委員会の会長を務めた後、知事に転身して財政改革に手腕を発揮した。ただ、全国的な知名度が低く、モルモン教徒であることが宗教右派に受け入れられるか、などが注目されている。イラク政策でブッシュ大統領の立場に近いことが懸念材料との見方もある。

_ [知財] 絶版書籍、ネット閲覧可能に・政府が著作権法改正へ

ほんとうにできればすごいことだけど、 そんなに簡単ではないよね。 本人が絶版を望んでたらどうするかとか、遺族が絶版を望んだらとか。

しかし、全体として絶版で情報にアクセスできなくなるデメリットは 非常に大きいわけで、なんとかなる手を見いだせるならそれに越したことはないと思う。

_ [Ruby] Ruby declared TIOBE's Programming Language of the Year 2006!

調査機関Gを使って独自のプログラミング言語の人気調査を行っている TIOBE Indexであるが、「2006年の言語」としてRubyを選出した、とのこと。

2006年、TIOBE Indexでもっとも順位の伸びが大きかった言語だったそうだ。

してみると、2006年はRubyの年であったなあ。 2007年はどうなるかなあ。年末には「2006年以上にRubyの年であった」と言えるかどうか*1。

_ JJ Club

なかなか家族の時間がとりにくいし、せっかくの正月休みでもあるので、 松江のJJ Clubにみんな連れて遊びに行く。

実際には一番楽しかったのは妻との卓球だったような気がする。 両方とも下手くそだったのでドロー。

あと、大人のくせにボールプールに埋まったのも楽しかったか。

_ スケート

娘二人と教会の人とでスケートに行く。 総勢17名。

本当にひさしぶりだったが、 まあ、転ばない程度に滑れた。 ただ、子供の時、ローラースケートから始めたから 姿勢が悪いんだよねえ(いや、ローラースケートのせいじゃないだろうな)。

ひとり全く滑れない小学生がいたけれど、 最初泣きそうだったけど、意外と(？)根性を見せて、 最後にはだいぶ上手になっていた。 シーズン中もう何度か来れたら結構滑れるようになると思うんだけど。

ともあれ、そんなに長い時間ではなかったが、 大変楽しかった。後で筋肉痛になりそう。

_ 年賀状問題

まだ、ぽつぽつと年賀状が届く。 その中で一通困ったものが。

• 表面は私たちの住所と夫婦の名前
• ただし住所は2年前の引っ越し以前のもの
• 裏面は完全に白紙

誰から来たのか分からないし。

たぶん、プリンターに同時に二枚フィードされちゃったんだろうなあ。 ちゃんとチェックしないとこういうことになる。

心当たりの人がいたらメールください。

_ [原稿] るびま特別編

青木さんが、るびまの添削連載をまとめて本にするという話。

コラムを依頼されていたのだが、〆切を守れないでいるうちに 真の〆切が来てしまった。大慌てで書くのだが、 風呂敷を広げすぎて、畳むのに苦労する。 なんとか月曜日には仕上げたいのだが。

_ [知財] 著作権保護期間の延長問題を考える国民会議 - thinkcopyright.org | 保護期間「延長派」「慎重派」それぞれのワケ

みごとに噛み合ってない。

_ [Ruby] eigenclass.org Happy 2007! Ruby mini-contest

挑戦者を待つ。

_ [言語] Origin of Programming Language Names

プログラミング言語名の起源。

有名なのばっかりだけど、 マイナーなものも含めて調べてみると面白いかも。

クイズ: 以下の言語の名前の起源は？

• CLU
• Eiffel
• Prolog
• Haskell
• OCaml

追記(2006-01-16)

木村さんのところで回答が。

正解を載せておきます。

• CLU - CLUsterから。クラスターはCLUにおける抽象データ型表現の名前です
• Eiffel - エッフェル塔に気がついたのは惜しい。エッフェル塔の設計者 Gustave Eiffelから。Meyerはこの方を尊敬しているそうです
• Prolog - Program in Logic。正解
• Haskell - 数学者Haskell Curryから。Curryが名字です
• OCaml - Objective Camlです。正解。ちなみにCamlは、Categorical Abstract Machine Languageの略だそうです

_ [言語] 第4回　関数型言語とオブジェクト指向，およびOCamlの「O」について

ITProの住井さんの連載。 オブジェクト指向と関数型は実はそんなに遠いわけじゃない、という話。

正直、オブジェクト指向の専門家っぽい顔をしていながら、 この辺の知識が浅いのが恥ずかしい。 もうちょっと勉強しないとな。

_ [教会] かぜひき

昨日のスケートで張り切りすぎたのか次女が体調が悪い。 自宅で休ませる。

聖餐会。いろいろな人が話してくださり、 またビショップが年頭の挨拶(兼、今年のワード目標の披露)。

ちょっと時間が押してしまったので、 あと何分で誰が話して...と気にしてしまったのは秘密だ。

次女が心配なので早めに帰る。 セミナリー補習の予定もあったのだが、延期。

_ 冬休み最終日

世間的には成人の日で祝日なのだが、 子供たちにとっては冬休み最後の日。 さすがに計画的に宿題はこなしていたようなので パニックに陥ると言うほどではなかったようだが、 それでもやり残しがあったようで(次女は昨日体調が悪くて寝ていたし)、 それなりに頑張っているようだ。

っていうか、うちの子は私の子供時代よりも まじめに宿題とか片付けるよなあ。母親の影響かしら。

私も原稿がいくつも残っているので それにかかりっきり。全然休みではなかった。

全員あまりにこもりっきりだったので、夕食は外食にした。

_ まつもとの弱点

ユーキャンという 通信教育業者がある。

で、新聞にそこの折り込み広告が入っていたわけだが、 妻が「ねえ、こういうのやってみない」という。

妻:「書道とか」
私:「勘弁してくれ」--書道は大の苦手
妻:「ポピュラーピアノとか」
私:「勘弁してくれ」--楽器は大の苦手
子:「ペン習字とか」
私:「だから、勘弁してくれ」--ペン字も苦手

要するに苦手なもののオンパレードであった。

まいった。

_ [原稿] 仕事初め

本当は仕事初めなのだが、

• 今日からの出張の準備
• 金曜日のスライド
• 日経Linux原稿

があるのに、今日になって

4日前に〆切だった原稿についてどうなってますか

というメールが来た。がーん、完全に忘れてたよ。 っていうか、そういう奴なんで、〆切当日に催促してください、お願いします。＞ 担当の人

仕方がないので、オフィスには行かないで(移動時間もったいない)、 自宅で超特急でスライドを仕上げて(今日〆切)、 夕方から東京に向かう飛行機で4日前〆切の原稿を仕上げ、 ホテルについてから日経Linuxの原稿。

これで私も立派なライターです(〆切を忘れる人は立派じゃありません)。

今回の日経Linuxのテーマは「AJAXとJavaScript」。

ちなみに4日前〆切の原稿は「Rubyレシピブック第二版」の前書き。 この調子だともうすぐ出るはず。

_ [Ruby] Ruby に今一番ほしいもの

は、IDEであるという話。

あんまり、リファクタリングツールとか使ったことないんだけど (私にとってはEmacs全体が巨大なリファクタリングツールなので)、 慣れ親しんだ人には必須なのかもしれない。

動的言語にはリファクタリングツールは難しいって思ってる人もいるみたいだけど、 リファクタリングツールの元祖は動的言語そのものであるSmalltalkなんだから、 難しいってことはないだろう。RubyだとRipperみたいな構文解析をする ライブラリの使い勝手がもっと良いとリファクタリングツールが作りやすい かもしれない。ParseTreeとか？

_ [言語] Ruminations of a Programmer: Why I should learn Lisp

「なぜLispを学ぶべきか」という話。

このエントリだけを見るとRubyでいいじゃんって思っちゃうんだけど、 S式を使った自己書換とかマクロの駆使とかはRubyでは逆立ちしてもできないね。 あと、MOPという概念がRubyにはないので、それを使いたい人も Lispが良いと思う。

_ プログラミング2.0

今風のプログラマ。

この分類で見る限り、私は限りなく1.0的だなあ。 以前の「ニュータイプ/オールドタイプ」の時もオールドタイプだったし。

まあ、結構古いプログラマなんで仕方がないと言えばそうだし、 昨今の2.0ブームも下積みになる1.0の層があってこそ存在できるわけだし。

1.0万歳。

でも、真似しなさいとは言えないな。

_ セキュリティキャンプ・キャラバン島根

なんと島根県でもセキュリティキャンプが開催される。1月27日。

本家キャンプとは違い、参加対象も限定されていないので セキュリティに関心のある人やWebサービスを公開している人は なるべく*1みんな参加した方がよい。

_ [Ruby] Ruby on Rails トレーニングプログラム

今回も初日午前中の講師。RubyとRailsの概要について。 会場がどの駅からも遠い。都会の人は歩くなあ。 私みたいな田舎者はドアツードアで車を使っちゃうから足が鈍ってて。

今回は出席者が多くて(25名)ちょっと緊張した。 Railsもろくに使えない私でいいのか、という気もしないでもないが、 言語設計者自身から講義を受ける機会はなかなかないということで、 土産話にはなるようだ。 優れた言語設計者が優れた講義を行うとは限らないのだが。

まあ、納得してもらえるならいいか。

_ [Ruby] 打ち合わせ

東京支社に移動。Rubyとコミュニティ支援などについて社外の人と打ち合わせ。 もしかしたら、本格的な支援が受けられるかもしれない。 ただ、我々「コミュニティ」側が組織体制が脆弱なので 経済的支援を受けても活用できないかもしれない点を改善する必要がある、かも。

その他にもいろいろと面白そうな話が出た。 今後はスケーラビリティ(いつも強調している生産性のではなく、性能の)も 重要になるかもしれないなあ。今のうちにいろいろ調査・研究しておく必要があるかも。 その辺は私(たち)では絶対的に経験値が足りないので、 いろんな人に聞いたり、教えてもらったりする必要があるだろう。

_ [Ruby] 懇親会

再びトレーニング会場へ。 立食形式で懇親会。

毎回トレーニング初日の夜に懇親会をするのだが、 きまってその後に質問が活発になったりして、 トレーニングが円滑になる。信頼関係は大事だ。

今回は会議室ひとつ借りて立食形式にしたのだが、 非常によかった。今までの居酒屋などでの懇親会も 食べ物はすごく良いのだけれど、席が固定されてしまうと 移動が面倒で話が進まない。立食形式だと いろいろな人と話はできるし、面白い話もたくさん飛び出すし、 今まで懇親会の中でも最良と言ってもよかったと思う。

担当の人に「次回からも立食にしましょう」とお願いしたのだが、 「会場の手配が難しくて、なかなか」とのことであった。 都内で立食形式で安くしあげられるところを調べる必要があるかな。

_ [言語] あるJava使いの場合 - Javaを学ぶ価値

「なぜJavaを学ぶ価値があるのか」という話。

プログラマ、システムエンジニアを職業とするならJavaは学んでおいて損はないでしょう。

「需要があり供給が不足しているから」

というのは理解できる。まったくもって正当な話だ。

しかし、その結果、

自分もそうしてジャバラーになったのです。

最初の現場には、経験２年以上のジャバラーはいませんでした。 それはそれは悲惨な開発になりました。

今考えるとバグだらけ、つくりもいい加減、 訳の分からないところでリフレクション。 もちろんまともにソースレビューできる人はいません。 それでも企業の基幹システムになってしまいました。

ということであれば、不幸なことだ。なにかが間違っていると思う。 おそらく間違っているのは個別のプログラマではなく、 もっと上の方で。

そのような不幸をこの世からなくせるか。 もし可能ならば、どうやって？

_ [Ruby] mapとreduce、あるいはマクロ不存在の理由

最上さんのところから。

最後のページより引用

今注目しているのはマルチコアへの対応です。これからプロセッサがコモディティになってきます。それほど遠くない将来に，机の上のパソコンでも64コアや 128コアのプロセッサが珍しくなくなる。そうすると，プロセッサコアへのタスクの割り当てはスレッドなんかでは不可能になる。自動化するしかなくなります。プログラミング言語で並列性をどこまで活用できるか。CやRubyのような手続き型言語ではなく，関数型言語が生きてくるかもしれません。

単にmapとreduceを加えれば良いのでは？と思ってしまった。

うーん、そうなのかなあ。Rubyのような言語においてmap/reduceが持つ可能性を あまり深く考察していないので、はっきりしたことは言えないんだけど。 それでできるっていうんなら、上記の発言は単なる私の不見識ですね。

もうちょっとmap/reduceについて勉強する必要があるかな。

もうひとつ、

マクロが無い言語ではプログラムしたくないと考える私のような人間からすると、Rubyにマクロを入れることを拒絶し続けることは前から不思議だった。マクロは言語作者の意図を超えてプログラミングのスタイルを変更してしまう可能性がある。これも同じくスタイルを破壊される事への忌避感が原因なのかも知れない。

こっちは当たりかも。マクロというのは要するに言語ジェネレータなわけで、 これを入れてしまうと言語はメタ言語になってしまい、 「その言語で書かれた」というプログラムを読解するヒントが少なくなってしまう。 それを嫌っているのは確かにある。

メタ言語が必要だったり便利だったりするケースは確かにあるけど、 日常的に使うものまでメタ言語だと、私の脳に優しくないので、 日常言語としてデザインされたRubyにはマクロは不要である、ということではないかと。

まあ、発言の背後の意図を憶測されることはまつもとさんにとっては迷惑かも知れないけど。だけど私も言語を作っている身としては、私のmap/reduce当然、マクロ当然という考え方のどこかに欠陥があるのかも知れないと、考えて理由が知りたいのだ。

理由は上の通り。繰り返すとmap/reduceについては不見識。 マクロについては日常的にメタ言語を扱うのは私が疲れるから。

背後の意図の憶測が迷惑なってことはない。どんどん憶測していただきたい。 違ってればそういうし。

_ [原稿] 日経Linux 2007年3月号

テーマは「AJAXとJavaScript」。

ただし、AJAXの技術要素と言語としてのJavaScriptの紹介をしたところで 紙面が尽きそうだ。まあ、次の月に持ち越し、ということで。

しかし、週末までに書けるかなあ。ちょっと、〆切に対する見積もりが甘かった。 いや、いつものことだけど。

とはいえ、講習会に顔出したりしないといけないし、 フルタイム原稿書きというわけにもいかない。

_ 日経ソフトウエア2007年1月号打ち上げ

新宿で日経ソフトウエア2007年1月号の「フリー言語で真のプログラミングを学ぶ」という特集の打ち上げ。

わざわざ私が東京にいる時に開いていただけるとは感激である。

出席したのは、私、酒匂さん、天野さん、Yuguiさん、大森さん。 30代はおらず、40代と20代の集まりであった。

で、ほとんどの時間は私と酒匂さんの昔話モード。 1980年にどんな無茶をしたとか、古い言語や環境ではどんなだったとか。 若い人(特に天野さん)にとっては信じられないほど モノがない頃の話で、想像を絶していたようであった。

年寄りの話をちゃんと聞く人は伸びるよ。

いやあ、楽しかった。今日は鏡開きということで、 最後にぜんざいをいただいた。ありがたい。 鏡開きには子供のころのイヤな思い出があるのだが、 たまには良いこともある。

_ [言語」XML and J2EE: Commodity Skills

いくつかの技術タームがどこで注目されているかを Googleトレンドで見ると面白い傾向が分かる。

• Ruby on Rails
• J2EE

これが、アメリカ人の新しモノ好きを意味するのか、 トップトレンドでないテクノロジーはインドや中国に移転されて行ってしまうということなのか、私には判断は難しい。なんとなく後者のような。

_ [Ruby] jijixi's diary - Ruby の文法的欠陥

Rubyが既存のクラスを意図せず書き換えちゃう可能性についての指摘。 私はこれを「文法的」とは呼ばないけど(文法じゃないから)、 まあ、問題を起こす可能性については認める。

もっとも

• ちゃんと名前空間を分離する
• クラスを定義する時にはスーパークラスを明示する

というルールを守っている限り、あまり落っこちる落とし穴ではないかもしれない。

ファイル単位の名前空間の分離についても触れられているけど、 確かに、JavaやPythonはちゃんと分離するから、そっちに馴れた人には 分離しない点についても気になるかもね。

この点でRubyは明示主義なんだよね。 おそらく単にプログラミングモデルで一番参考にしているLispなどでも ファイル単位で名前空間が分離していないからだろう。

でも、CommonLispのpackage宣言のようなものは 将来必要になる...のかなぁ。

_ [Ruby] 丸山先生レクチャーシリーズ in 東京 2006-2007

半蔵門から大森へ移動。

レクチャーシリーズ、今回のテーマは「web2.0　--　新しい技術と新しいビジネスモデル」 なんだそうだが、Rubyの話はアウェイな気がしないでもない。

丸山先生の話は盛り沢山であった。時間内に終わるかな、と心配したが、 案の定、スライドを消化しきれてなかった。 ま、しょうがない。Web2.0のアウトラインを理解するには良かったのではないかと。

次が私の話。「動的言語の世界」と題して、 Rubyのような言語がなぜ注目されているか、というような話。 最近の講演(日経BP次世代フォーラム、福岡)とややかぶる。

次がマイクロソフトの安藤さんによる「マイクロソフト技術で体現するWeb 2.0「Windows Live」〜ソフトウェア+サービスの目指すところ〜」。 要するにVistaのガジェットでなにができるか、どう作るかと言う話。 それほど目新しい話ではなかった。 注目すべき発言は「画期的なのはそのインストールベース(数)」というもの。 非常にマイクロソフト的であった(苦笑)。

次は首藤さんの「peer-to-peer の世界」。 ウタゴエCTOになってからははじめて会うのかな。 Wiiリモコンを使ってプレゼンしようとしていたようだが、 センサとの距離や蛍光燈の光などに負けて断念したようだ。

この話興味があったのだが、飛行機の時間の関係で途中で抜けないといけなかった。 最初の導入しか聞けなかったのが心残り。

コンポーネントスクエアのページから発表資料がダウンロードできる。

当日の感想リンク

• [イベント参加レポート]新しいネットワーク・メディアとweb2.0
• 丸山先生レクチャーシリーズ in 東京 2006-2007 ■第3回テーマ「web2.0　--　新しい技術と新しいビジネスモデル」

_ [言語] 静的/動的言語

休憩時間に挨拶していただいた方と雑談していたのだが、 「動的言語の利点を持ちつつ、静的言語のように情報を与えてコンパイルすることで実行効率を実現できる言語(の組み合わせ)はありえないものか」というような質問を受ける。

プロトタイプは動的言語で作っておいて、 ライブラリやフレームワークとして切り出す時には、 コンパイルして効率の良いものにしたいという開発スタイルを考えておられるようだ。

RubyとかだとJavaに代表されるような静的言語とは プログラミングモデルからして違うから 単にちょいちょいと型情報を追加して、というわけには行きそうにもない。 最初から動的・静的のミックスを念頭に置いた言語が必要そうだ。

と、ここまで考えて気がついた。

それなんてLisp？

Lispなら基本は動的言語だし、柔軟さについては他の追随を許さない。 さらに型情報を負荷付加することもできるし、 多くの処理系ではコンパイラも用意されていて、 場合によっては通常のコンパイル型言語(Cとか)よりも速いことがある、そうだ。

ということで、 「Lispとかどうでしょうね」と答えたら、 その方は苦笑しておられた。

Lispの不人気は相当なものである

誤解(？)の根は深い。

_ [Ruby] 2006年「Ruby on Rails」が愛された理由

愛されてますねえ。NaClもちょっとだけ言及されてる。

_ [Ruby] local variables new scoping rule

Evan Phoenixがruby-talkでRubyConf 2003のスライドについて言及する。 すっかり忘れてたよ。

で、改めて考えてみると、これは悪くないアイディアかもしれない。 まあ、もともと自分のアイディアなんだけど。

まずは問題点から。

問題

現状のRubyでは、ブロックの中で初出のローカル変数の有効範囲は そのブロックの中に限定される。 これは無名関数のようにブロックが使われる時に その関数の中だけで有効なローカル変数が使えないと 非常に不自由だからだ。

しかし、一方、通常のループ的にブロックを使う場合、 値を持ち出すためにローカル変数に代入しても その変数が(そのままでは)ブロック外部には見えないため わざわざブロックの前まで戻ってあらかじめ代入しておく必要がある。

しかし、ブロック限定のローカル変数を使いたい局面は限定されており、 ハフマン圧縮的見地からは、より頻繁に使われる通常のローカル変数的使い方のために、 いちいちブロックの前に戻って宣言的代入が必須と言うのはめんどくさい。

解決法の提案

元々はローカル変数のスコープの昇格で解決することを考えていたのだけれど、 これは構文的に後ろに登場する情報が前の意味を変更するというのが 非常にRuby的でない(or 私の好みではない)気がしていて踏み切れなかった。 実装もそれなりに面倒なものしか思いつかなかったし。

しかし、Evanの指摘により、昇格法よりもさらに前に考えていた*1、 デフォルトはスコープローカル、明示的に指定した場合だけブロックローカル、 というものを採用する気になった。

具体的には

• 通常の代入によって作られるローカル変数は(class,module,defが作る)スコープローカル変数
• ブロックパラメータはブロックローカル
• 以下のいずれか、または両方
  • ブロックパラメータの後ろに「;」を置き、そこに続けた変数はブロックローカル変数
  • 「:=」で代入した変数はブロックローカル変数

結局は3年前のエントリで 考察していた通りで、その時、あきらめた明示的なブロックローカル宣言を取り込んだものとなった。

英語圏の人のためには、このエントリをRCRにまとめた方がよいよなあ。 ちょっと面倒だなあ。

実装

一度心を決めたら話は難しくない。 丸山先生のお話を聞きながらハックしてたら30分でできてしまった。 変更はparse.yだけに限定されるので、きっとYARVでもそのまま動く、はず。

_ [原稿] 日経Linux 2007年3月号

「週末にお願いします」と言われたのだが、 朝の時点でまだ半分も書けていない。 「週末っていつまでだ」とかなり焦りながら 原稿書き。

本当は休日は家族と過ごしたいのだが。 まあ、上二人が部活でいないので、家族全員がそろうわけではないのだが。

ところで、今さらながらJavaScriptって面白い言語だね。 同じ動的言語でもRubyとは姿勢が対極。 簡単な仕組みで中身までさらしていろいろできるようにしたいJavaScriptと、 必要そうな機能は一通り組み込みで持ってしまって、中身は見せずにスマートに書かせたいRuby。

中身が見えてる方が遊ぶ余地は広いけど、どうしても記述は繁雑になる。 中身が見えない方は、言語が許していないことはとたんに難しくなるけど、 その範囲内であれば生産性が高い。

そういう意味ではJavaScriptやPythonの方がLispに近いのかもしれない。 RubyでMOPとかあり得ないものな。

あと、プロトタイプ言語と言いながら、 Ioほど徹底していない(ので、私には使いにくい)オブジェクトシステムにはなんだかなあ。 関数オブジェクトに対するnewとか要らないから直接cloneさせて。

_ [Ruby] On Ruby: Will rubinius Be An Acceptable Lisp

Rubiniusは将来S式を入力に許すかもしれず、 そうなればますます「Acceptable Lisp」の地位を括弧確固としたものにできるかも、という話。

しかし、上述の「中身までいじらせるかどうか」という点が 「ホンモノのLisp」との間の越えられない壁になりそうな。

_ [Ruby] ホワイの(感動的)Rubyガイド

Poingnant Guide和訳キターーーーッ。青木靖 さん、GJ。*1

_ [教会] セミナリー補習

通常通りの集会。

先週までで手をつけてなかったことをいくつか片付けられた。

集会後、セミナリーの補習。 ビデオ教材を見ながらいくつかの原則について学ぶ。

• 一見安全にみえる誘惑または危険
• 高慢

いや、どれも重要なことだ。特に後者。

で、帰るのが遅くなってすっかりくたびれた。

_ [言語] サン、Fortranに代わる新プログラミング言語をオープンソースに - ZDNet Japan

Fortressもオープンソースに。すげえ。

とはいえ、まだ仕様が固まってきて、 インタプリタがなんとか動く程度なので、 なんとも評価しがたい。

とりあえず言語仕様[PDF]は読むことにする。

• Fortress ホーム
• Fortress FAQ

_ [Ruby] ITmedia エンタープライズ：まつもとゆきひろ−第3回：僕の存在価値はそこにある

風穴さんによるITmediaインタビュー第三回(最終回)。

自分で発言した内容が、少しだけ編集されただけでそのまま掲載されるというのも 貴重な体験だと思う。かなり長い時間話したことが、そのまま。 最終原稿チェックがあったので、さすがに間違ってたことは修正したけど。

キバヤシ: しかし、おかしいとはおもわないか？
キバヤシ: このインタビューでまつもとは謙遜ぶっているが、彼は学生時代に実の母親から「あんたから高慢を取ったらなにが残るの？」と言われた奴なんだぞ
MMR団員: ええっ！？
キバヤシ: それを踏まえて彼の発言「そういう人たちにはRubyは作れなかったわけで。その辺に僕の存在価値がある」を読み解くと...
キバヤシ: 「お前らにRubyみたいのが作れるか。悔しかったら作ってみろ」となる
キバヤシ: つまり、これは言語を作ろうと考える人々への挑戦状だったんだ！！ MMR団員: な、なんだってーーーーっっ！！

真実はいかに。

_ [Ruby] InfoQ: Ruby Version of Refactoring In the Works

『4894712288』のRuby版が執筆中との話。 マジですか？

_ [OSS] Groklaw - BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law

BSDライセンスにも感染性があるという話...なの？

よくわからないなあ。識者のコメントを求めたいところだ。

_ [言語] クレイジーjavac? - 'Kitchen Sink Language'で仕様の試食を楽しもう

Javaに新しい仕様を追加する実験的ブランチを使うことについて。 楽しそうだなあ

Rubyにも、と思ったが、 改めて考えてみると、私のやってることはkitchen sink languageそのものだ。 ただ、参加者が少ないだけで。

ITmediaには「ITmedia エンタープライズ：Javaの生みの親、再び言語論争の渦中に？」という記事もある。こちらはややネガティブな印象がある。

_ Steve Jobs はなぜ説得力があるのか

Steve Jobsになぜ説得力があるのか、 そのプレゼンテーションテクニック。

プレゼンテーションすることが多い身としては是非参考にしたい。

• 練習
• 等身大の自分
• 効果的な視覚効果
• 的確な焦点
• 三度繰り返す
• 当意即妙の話
• 沈黙の間合い
• 特徴を比較

_ [Ruby] IBM 境界を越える: Ajax on Rails - Japan

Bruce TateによるAjax on Rails。 うーん、ちょうど日経Linuxの来月分で書こうと思ってた内容とかぶるなあ。

まあ、いいか。

_ [言語] IA32(x86)JITアセンブラ Xbyak

これがあるとJITができるな。 x86限定だけど。

ポータビリティのためにはGNU Lightningのようなものが必要か。 Gecko 3.0にはJIT付きJavaScriptエンジンが添付されるということだが、 この辺も将来のRubyに参考になるかもしれない。

あと、LuaJITも見てみないとな。

_ スライド

明日の出張のためのスライドが完成してない。 大あわて。

_ [言語] 第6回　OCamlの「モジュール・システム」

住井さんの連載６回目。

モジュールシステムはRubyの弱い点でもある。 この辺はもうちょっと考えないとな(でも、たぶん、取り掛かるのはずっとずっと先のこと)。

_ 出張

朝から東京へ移動。横浜へ。

某企業の社内勉強会の講師。 「開発者本人でなければ話せないことを」というリクエストに従い、 最近の講演の内容を大幅に変更した。 とはいえ、いじりすぎて時間の感覚がうまくつかめなかったので ８分ほど時間が余ってしまった。反省。

その後、質疑応答やら懇親会やら。 大変楽しかった。

懇親会では「Rails技術者ならいくらでも欲しい」という話が出た。 そういう時代なんだ。 うち(NaCl)でも足りない*1んで 人が欲しいんだけど、資金的に余裕がある大手との競争になると なかなか勝てないなあ。

_ 人材募集

というわけで、人材募集。

• Ruby/Railsで思い切り仕事ができる
• 裁量労働制。コアタイムなし。完全週休二日
• 勤務地: 東京 (または松江)
• 業務分析、設計ができる人優遇
• チームマネジメント、教育ができる人も歓迎

詳しくはNaClのページまで。

_ [OSS] グーグルのクリス・ディボナ氏：「われわれはプロプライエタリソフトも重視している」 - CNET Japan

GoogleのオープンソースプログラムマネージャのChris DiBona氏へのインタビュー。

しかし、わざわざそのようなことが強調されるほど Googleはオープンソースばかりにコミットしているわけではない。 もちろん、Googleはたくさんのオープンソースソフトウェアを支援しているし*1、 必要であれば資金も出している。

が、Googleほどの規模と技術者を抱えていれば、 私には、それはむしろ「少ない」と映る。

誤解してほしくないのは、私にはそれに対して非難するような意図は一切ない。 「やや残念」と思うことはあるかもしれないけど、 オープンソース化は強制によって行われるものではないし。

それにね、私にはGoogle(の中の人)の気持ちも分かる気がする。

私がオープンソースに注力する最大の理由は自分の自由を最大化することであり、 私がGoogleの中の人であれば、Googleの中(向こう側)のあらゆる情報やソースコードにアクセスできるのだから、外側(こちら側)への公開への熱意はそれほど高くならないだろう。 そんな中でオープンソースにコミットしてる「Googleの中の人」というのは むしろ尊敬に値するだろう。

とはいえ、それは私が「向こう側」に行くことを躊躇する4番目くらいの理由でもある。

_ [Ruby] スターティア、独自CMSを「Ruby on Rails」に対応　開発を効率化

私が直接は知らない人が真剣にRubyをビジネスに使うことも 増えてきて、 最近、プレスでRubyやRuby on Railsの名前を見ることも珍しくなくなった。 そろそろ、いちいちフォローする必要もないのかなあ。

でも、うれしいけど。

_ [Ruby] receiver, name, owner of Method object

[ruby-talk:234949]の提案に従い、 Methodオブジェクトに

• receiver - そのメソッドのself
• name - そのメソッドの名前
• owner - そのメソッドを定義していたクラス

の各メソッドを追加した。しかし、続いてこれらのメソッドの名前は 適切かどうかの議論が巻き起こる。

一番、もめた(もめている)のはreceiver。 つまり、obj.method(:foo)で取り出してきたものは メッセージを受け取ったものではないので、 receiverは適切ではないだろう、という話。

確かに普通、メッセージセンドというとメソッドの実行までを含めるから メソッドの選択と取り出しだけをメッセージセンドと呼ぶのもおかしいと言えば おかしい。

一方、Methodオブジェクトを経由しようと、通常のメソッド呼び出しだろうと selfの役割が変わるわけではないことを考えると、 receiverという名前が不適切であると言うことは selfのことをreceiverと呼ぶことそのものが不適切ということになる。

では、selfはreceiverではないのか。私はずっとそう呼んできたんだけど。

あるいはメッセージセンドというモデルを持たないC++やJavaでは thisのことをなんと呼ぶのか。まさかreceiverじゃないよね。

_ リクルート　エンジニア適職フェア 「理想のソフトウェア開発の現場とは？」

朝一番の便で東京に移動。有楽町の適職フェア会場へ。

若干の打ち合わせの後、パネル会場に。 立ち見が出るほど人が集まっていた。恥ずかしい。

鵜飼さんはちゃんとスライドを用意してきていた。 私も(実は飛行機の中で仕上げした)スライドを持っていたのだが、 いちいちマシンを切り替えるのは難しいので 私の分を表示することは断念。

鵜飼さんのメインテーマは「深追い」。 私のは「自由」。まあ、立ち位置が近いのでわりと共通したメッセージだったように思う。

あまり「激論」とか「対決」とか「熱く語る」とかいう感じでは無かったのだが、 聴衆のお役に立てたのだろうか。

皆さんにも見せなかったスライドを公開しておく。

そういえば、前日の夜実家から電話がかかってきて、 「リクルートのイベントに出るんだって」とのことだった。 なんでも父親がネットでたまたま見つけたらしい。 リクルートのリーチ力は侮りがたし。

_ 『4062820366』

「対談」終了後、そのままTech総研の『我らクレイジーエンジニア主義！』の取材に。

えーと、正直、クレイジーエンジニアってのとはだいぶ違うと思って、 「私なんか取材しても面白くないですよ」とだいぶ伝えたのだが、 ライターの人を説得しきれなかったので、そのまま取材ということになってしまった。

だいたい並んでいる人がMITの石井教授とか筑波の山海先生とか、 ヒトカドの人ばかりで、私みたいな人の出番じゃないと思うんだけどなあ。 まあ、かえって読者に身近に感じてもらいやすいというのはあるかもしれない。

そのうち、載るんじゃないかと。

せっかく東京に来たので笹田くんと打ち合わせようと思ったのだが、 時間が合わずすれちがい。私たち、そういう運命なのね...。

_ [教会] バプテスマ会

お金の支払い書類のことでちょっとどたばたした以外は ごく普通の日曜日。

集会終了後バプテスマ会。今年最初である。 よくぞ決心してくれた、という気持ちである。 最初教会に来るようになった頃とはだいぶ気持ちが変化したらしい。 当初はお姉さんも一緒に受けるという話であったが、 もうちょっと自分の気持ちに自信が持てるまで待ちたいということだった

その方がいい。

しかし、さすがに土曜日出張はしんどくて、 なんだか一日中疲れていた。

_ [OSS] steve dekorte - projects - open source - skipdb

内部データ構造にSkip Listを使ったdbmっぽいライブラリ。小さくて速いらしい。bdbやqdbmよりもソース規模は小さく速度は速いとうたっていた。テストケースは配布ソースに含まれているので不正はないだろうが、 データ規模とかでどう影響されるのかは興味深い。

って、今、気づいたけど、 これ作ってるのってSteve Dekorteじゃん。 Io作ってる人。

才能あふれる人っているもんだなあ。

_ [知財] なぜ実現しないネット放送--「品質論」唱える既得権益者の本音

本音とタテマエ。 っていうか、こうやって本音を引きずり出されると コンテンツホルダやら放送局関係者やらは立場ないよね。

もっと正直な世の中になってもいいと思う。

_ [Ruby] Ruby Programming - 向Ruby之父学程設計

※注意。リンク先のエンコーディングはBig5です。

台湾版「たのしいRuby」だそうだ。550台湾元。 この本は私も監修してるけど「向Ruby之父学程設計」ってのは 漢字だけから推測すると「Rubyの父に学ぶプログラミング設計」って感じじゃない？

だとすると言い過ぎじゃないかと。 いや、わかんないけど。

_ [OSS] 「賞味期限切れ」のソフトよさらば。ようこそSugarCRMへ - 日本のITは世界を制す！？

まあ、前からのことなんだけど、この人の書くブログエントリには まるっきりの嘘が書いてあるわけじゃないのに 強烈な違和感を感じるのはなぜだろう*1。

オープンソースをビジネスとして取り扱うことについての抵抗は 私自身にはないはずなのに。

たぶん、コミュニティベースの「普通のオープンソース開発」のことを むやみに低く評価した発言をするからだろうね。 たとえば、以下の発言。

草の根活動のオープンソース・ソフトウェアもビジネスモデルがあやふやで、手を出すのもためらわれるというところでしょう。

自分のところをよく見せたい気持ちは理解できるけど、 そんな言い方をして、他のオープンソースプロジェクトに喧嘩を売らなくてもいいのに。

これではオープンソースのことをまるで知らない(知らなかった)人には 多少アピールするものがあっても、もともとオープンソースに近い人は かえって遠ざかっちゃうんじゃないかな。

あ？ 待てよ。

ビジネスモデルとしては、それでいいのか。 もともと詳しい人はどうせ客にはならないから、かえって邪魔かもしれないしな。

たとえ、この人の文章にオープンソースに対する愛が感じられないとしても、 そんなことビジネスには関係ないしね。

_ [OSS] Fork JavaScript

JavaScriptの亜流の新しい言語か、と期待したのだが、 そういう話ではなくてPrototype.jsを置き換えるようなAJAX向けJavaScriptライブラリ。 Railsといっしょに使うことを想定しているようだが、 Railsに依存しているわけではなく、Rails以外とでも使える。

_ [OSS] OSDLとFSGが合併、Linux Foundationを設立

いろいろ思うところがある人もいるかもしれないが、 私は素直に良いことだと思う。

もっとも良い点は両組織とも名前と実態が乖離していたのが、 ちゃんとLinuxにフォーカスした団体であることが明示できる名称になったこと。 Linusも抱えているんだし、名前倒れと呼ばれることもないだろう。

あと、風穴さんによる解説もある。 「OSDL＋FSG＝The Linux Foundation＋α？」

_ [OSS]Dynamic Draw

しばらく前に、オープンソース化にあたってライセンスの選択について相談を受けたものがとうとう公開されたらしい。

とはいえ、sourceforgeの使い方に引っかかったりと 本質でない点でいろいろと困難があったようだ。 オープンソースのすそ野を広げるためには この辺の障壁も下げる必要があるのかもしれない。

_ ALSA、音出ない

今日まで気がつかなかったのだが、 いつの間にかLinux PCから音が出なくなっている。

別にリブートもしてないから、なにかの設定がおかしいのだろうか。

まず、問題を切り分けなくてはいけない。

最近updateされたのはesoundだが、esoundなしに直接ALSAを叩いても音が出ないので、 問題はALSAモジュールのほうにあるのだろう。

典型的なトラブルはミュートがかかっていることに気がつかなかったり、 /dev/dspなどのパーミッションが間違ってたりすることだが(過去に何度も引っかかっている)、alsamixerでちゃんと設定しても音は出ない。パーミッションにも問題はなさそうだ。

問題が発生したのはDebian sidのlinux-image-2.6.18-3-686だったので、 古いカーネル2.6.17-2-686でも起動してみたが、 やっぱり鳴らない。ということは、カーネルモジュールのせいではなく、 どこかの設定のせいなのか。

しかし、ALSAの設定できるところってほとんどないんだよなあ。 で、いまだに原因が分からず音が鳴らないままなのであった。 ビープは鳴るんだけど。

どうしたもんだか。

追記

という日記エントリを書いた1月27日早朝、改めて試してみたら鳴るようになっていた。 特に設定を変更していないのに...気持ち悪い。

追記(2)

だいぶ状況が分かってきた

• esdが起動していない状態でfirefoxが動くと(たぶんflashが)/dev/dspを掴む
• でもlsofやfuserでは表示されない
• その状態でesd経由では音が出ない
• かつ、alsa直叩きでも音が出なくなる(これが謎のまま)

ということらしい。さらに

• 最近updateしたflashplugin-nonfree 9.0.31.0.1はesddsp経由では音が出ない

ということのようだ。すべての現象の説明がつかないのが気持ち悪いが、 とりあえず基本的な状況は理解できた。 まあ、sidを使ってる宿命みたいなものか。

とりあえずflashをdowngradeする。

追記(3)

FirefoxからIceweaselにアップグレードしたらまた音が出なくなった(2007-02-01)。

きっかけはプラグインの検索順序が変わって、 またflashplugin-nonfree 9.0.31.0.1が使われるようになったこと。 しかし、これで一度音が出なくなると

• esd経由だろうが
• esddsp経由だろうが
• alsa経由だろうが
• プロセスを全部終了させようが
• リブートさせようが

なにをしても音が出ない(ビープは鳴る)。

だいぶ困ったあげく

• /var/lib/alsa/asound.stateを削除
• alsaconfの再実行

で音が出るようになった。いや、他にもいろいろやったから もしかしたら別の理由があるのかもしれないけど。

_ [言語] Lisp:S式の理由

LispとLispユーザがなぜS式を選択するか。 ハッカーのはしくれとして理解できないこともないが、 なんというか、見事に「普通の人」と立ち位置がずれている。 すがすがしいくらいだ。

ま、そういう態度もアリだろう。

でも、やっぱり一般受けはしないだろうなあ。 見かけはRuby(というか「普通の言語」)で、 セマンティックスはS式という「妥協」はできないものか。

できないんだろうなあ。

追記

えんどうやすゆきさんからトラックバックをいただいた

なぜ文法がRubyでなければいけないのか理解できないのですが。

というかそもそも「普通の人」って何さ。「Rubyは普通の人に優しい」と主張したいのだろうか?

いやもしかしてあの「普通のやつら」の「普通」なのか?

コメントをつけようと思ったが、反映されないみたいなので(スパムと見なされた？)、 ここにも書いておこう。

「普通の人」とは「プログラミングをする人のうち、かなりの割合」という程度の意味です。かなり多くの人々が「S式を受け入れがたい」と感じるのは観測された事実です。また、これらの人々はLisp(の外見？)よりもRuby(の外見？)の方が受け入れやすいと感じるようです。理由はまだ分かっていません。

私はS式を読み書きするのに抵抗はほとんどないので(それでもLisp Wayばりばりなプログラムは(おそらく別の理由で)読みにくいのですが)、この「普通の人」に私は含んでいません。

あのエントリの主張は、その前提を踏まえて「S式が『普通の人』にとって受け入れがたいなら、Rubyのような大衆ウケする文法を外部表現として使うのが良さそうだが、(その試みは成功したことがないので、なんらかの理由で)できないんだろうなあ」というようなものです。

けっして「文法がRubyでなければいけない」とは主張していないので、その理由を読み取ろうとしてもできないのは当然だと思います。

で、あの文章が「Rubyでなければいけない」と読まれてしまうようでは、私はまだまだ精進が足りませんね。

Lisp使いの人は、自分たちが愛する言語が

• 人気がない
• 知られていない
• 誤解されている

ことを認識することからはじめた方が良いと思う。余計なお世話だけど。 「普通の人」は本当にLispを知らない。

_ [Ruby] Asoby: Aspect-Oriented Programming in Ruby - New Playground for Rubyists 2.0

Ruby本体をハックしてアスペクト指向を実現した、という話。

こういう話は大好きだ。 実際問題として本体に取り込むかどうかは別として。

私自身はアスペクト指向についてなんともいえないモヤモヤしたものを感じている。 どうも、言語そのものが扱うべき領域を逸脱しているような。 実は(アスペクト指向の大家である)千葉滋先生には個人的に「それってどういう意味よ」とツッコまれているのだが、 しばらく考えてみるに、いまだに言語化できない。現時点ではただの直感である。

_ ソフトウェア ジャパン２００７−社会を変えるイノベーション−

東京に移動してから 東京オフィスで内職してたりしたら、 会場についたのは指定された時間(15:15)ぎりぎりであった。 受け付けではすぐ前に坂村先生がいてビビる。

そのまま会場へ。

ただ講演をするもんだと思っていたら、 「ソフトウェアジャパンアワード」なるものをいただいてしまう。 実は案内のメールにはちゃんと書いてあったのだが、 夕べまできちんと読んでなかったよ。 坂村先生と並んで話すというだけで十分緊張していたのだが、 アワードをもらうということで緊張は頂点へ。

で、そのまま坂村先生の話を聞いていたんだけど、 お話がかっこいいなあ。なんか、「これだけのことをしてきましたっ」というような なんというか、「実績バリバリです、先進的過ぎて時々理解してもらえないけど」、というか。

その後、私が話すんだけど、 坂村先生の話と対比して私の話のユルいこと。 Rubyには別になんのイノベーションもないしなあ。 「楽しさだけ追求してたら、いつの間にかこんなところにいました」というか。

その後の懇親会も楽しかった。坂村先生はすぐ帰られたようで あいさつすることもできなかったけど。

一番印象的だったのはIBM基礎研の小野寺さんとお話できたこと。 私、小野寺さんのデザインされたCOBのリファレンスマニュアル、今でも持ってます。

最近はJavaばかりだそうだけど、そろそろ他の言語もやってみたいとのこと。 Rubyなんかも考えてくださっているようだ。正直、うれしい。

その他、いろいろな方とご挨拶して、 いろいろな話ができた。大変楽しかった。

会場で何人かとリクルーティングモードでのお話もできた。 なんか、好感触。どうかな。

懇親会後、さそわれるままに六本木のお好み焼き屋で二次会。 こちらも大変おもしろかった。 大挙して「オープンソースラボ」に遊びに来てくださるとの口約束であったが、 酒の上でのことでしたでしょうか。Ｋさん。 私、待ってますから。

_ [Ruby] mixiのようなSNS開発も夢じゃない？---ニーズウェルがRubyのトレーニング：ITpro

ニーズウェルが Ruby on Rails講習会を開催するという話。 特徴はテーマとしてSNSを選択したという点。 ３日で18万円。 (株)メタWeb 研究所が協力している、とのこと。

いや、頑張ってください。

値付けとかでだいぶうちのとかぶっているような気がするけど、 切磋琢磨することも重要だと思う。

っていうか、よそが参入する気になるほどRubyとRailsが魅力ある市場とみなされれたことに正直に喜びたい。

_ 帰宅

朝起きて、羽田空港へ。

ホテルが南千住だった*1ので、 ほんとうに久しぶりに常磐線に乗った。死ぬほど混んでた。

東京にはひんぱんに行くけど、たいていは混雑する時間を外して活動していたので こんなに人がたくさん乗ってる電車には長らく乗ってなかった。 ちゅーか、９時過ぎてもこれだけ乗ってるってどういうことよ。

東京に住まなくて本当に良かったと思う私。 ２便で出雲空港へ。

_ スタイラス紛失

で、うちに帰ったら愛用のVisor Edgeのスタイラスがなくなっていた。 電車の中かどこかで落としたんだろうなあ。 ぐすん。もう、手に入らないだろうなあ。

仕方がないので、以前にいただいていた予備機(あるのかよっ)のスタイラスを使うことにする。

_ 新年会

夜は会社の新年会。昨日はソフトウェアジャパンの懇親会、今日は新年会と 宴会続きすぎ。楽しかったけどね。

_ [言語] SRFI 89: Optional and named parameters

すごい面白い。やっぱLisp(系言語)はアイディアの宝庫だわ。 頭のいい人がいろいろ考えてるからな。

今やってるvisibitilyに結論が出たら次はこれだ(named parameter)と思っているので ぜひ参考にさせてもらおう。

Lispの方には足を向けて寝れない...って、どっちの方角なんだろう？

_ [OSS] O'Reilly Open Source Convention 2007 July 23-27, 2007 Portland, Oregon

今年のOSCONは6月23日から27日。 場所はいつものオレゴンコンベンションセンター。

今年は行かないつもり。呼ばれてないし。

そういえば、RailsConfも 今年はこのオレゴンコンベンションセンターで開催するらしい。 今年はO'Reillyとの共催だからかな。

こちらの日程は５月１７日から２０日。

_ 画像ビューア絵箱@nekobooks

先週のリクナビはあちこちで話題になったらしい。 私(や鵜飼さん)の名前と言うよりもリクルートのブランドの威力だろう。

が、どうも「まつもとひろゆき」という表記をあちこちで見かける。 やっぱ、間違えられちゃうよなあ。残念だ。

で、今回「まつもとひろゆき」でエゴサーチをして見つけたのがこれ。

なんと、正真正銘の「まつもとひろゆき」さん。 イラストレーター・デザイナ・開発者で、 Macのフリーウェアを開発しておられる。

が、せっかくの作品を私のものだと勘違いしている人もいるようで、 申し訳ないような気もする。

っていうか、まぎらわしいなあ。 せっかく差別化のためにひらがなにしたのに、 全然有効じゃない。もっと珍しい名前だったらよかったのに。

_ ウェブキャリアでWebエンジニアとしてのキャリアを磨こう

歌代さんさんのインタビュー。

しかし、こんなにもズレてていいのか。 伝統的なSE観と、「本物のエンジニア」。

_ セキュリティキャンプ・キャラバン島根

島大の中で道に迷ってだいぶ遅刻して参加。 会場くらい確認してから来ればいいのに。

園田(sonodam)さんと濱本さんの話が生で聞けると言うのは僥倖だが、 見渡した限り、そのことを理解している参加者は少数派な気がした。

で、のんびり話を聞いてたら、 担当の人(U-20プロコンでお世話になった人)が、 「で、Rubyのまつもとさんがいらっしゃっていますから、お言葉をどうぞ」 とのたまう。えーと。

しょうがないので、「最近の若者は...」というネタで ５分くらい。「成功者はブレーキが壊れている」という話は 濱本さんにもウケたらしい。

もっとも、後で考えたら「ブレーキが壊れている」と「ポテンシャルがある」は 直交しているから

• ポテンシャルがあり、ブレーキが壊れている(成功者)
• ポテンシャルがあり、ブレーキがかかっている(もったいない)
• ポテンシャルは無いのに、ブレーキが壊れている(大迷惑)
• ポテンシャルは無いけど、ブレーキもかかってる(無害)

という組み合わせがあるなあ。 むやみに「ブレーキを外せ」とだけ言うのは無責任だったかも。

_ [教会] リアホナ2007年２月号

先日インタビューされた記事が 教会の月刊誌リアホナ２月号ローカルニュースに掲載された[PDF]。 なんだか照れ臭いぞ。

教会でも読んだ人から「読みましたよ」と言われて、恐縮する。 恥ずかしい。まあ、覚悟の上で引き受けたんだけど。

集会では、先週のバプテスマに引き続いて、按手と確認。

集会後、セミナリーの補習。教材ビデオを見たのだが、 (すでに見たことあるプログラムだったのに)感動してうるうるしてしまった。 年取って涙腺がゆるんだか。

_ [言語] 中身の見える言語

なんか、すごいゆっくりしたペースでブログエントリで対話しているような...。

最上の日々より。

Matzにっき

中身が見えない方は、言語が許していないことはとたんに難しくなるけど、

これが、まさに私が嫌いな事です。とすると、やはりどちらが良いかでは無くて、ユーザの種類によりけり、ということなんでしょう。

Lisp:S式の理由 なんかも私には関連したテーマに見えます。

それが嫌いな人がいるのはわかります。 別にそれが悪いってわけではなくて、 そういう人にはLispって言語がありますから。

で、Lispでない言語の中身が見える必要があるかどうか、ですが、 (私にとって)重要な点は、日常的なユースケースで不便が出るかどうかです。 つまり、ほとんどの場合では「中身が見える/操作できる」ことは プログラムを書くことと直結しないので、 そのような領域に悪影響を及ぼさないかどうかが非常に重要です。

で、私の知る範囲内で、そのような「中身が見える」系の言語 (たとえばJavaScript, Perl5, Python, Ioが思いつきます)では、 日常的なユースケースの記述が繁雑になる傾向があるように思います。 JavaScriptでオブジェクトの継承や委譲を操作すると とたんにプログラムが難しくなるとか、 Pythonでいつもselfを書かないといけないとか。

私自身は中身を見せないことと、簡潔な記法にどのくらい密接な関係があるのか 断言できるほど考察が進んでいるわけではないのですが、 少なくとも実際の言語を見る限りではかなり正の相関がありそうです。

また、「中身を見せない」方がパフォーマンスチューニングの余地が大きい というのもあります。 もっとも、やることがシンプルな方が高速だったりするのはよくあることですし、 パフォーマンスチューニングの余地が大きいはずのRubyが 他の言語より遅かったりして、 「お前が言うか」というようなレベルなのは恥ずかしいですが (YARVが改善してくれるに違いない)。

この点においてLispってのはやや特殊で、 中身が相当見えるのに、繁雑さはマクロで隠蔽できるという特徴があります。 それはそれですばらしいことですが、 マクロはマクロで、(私にとって)イヤな点があるので、ねぇ。

_ [言語] XML.com: What's New in Prototype 1.5?

つい先日リリースされたPrototype.js 1.5の新機能について。

なんかますますRubyに似てきてる。succとか$wとか。

っていうか、この間書きおわった日経Linux 2007年3月号(2/8売り)の 原稿でPrototype.js 1.4について解説したばっかりだったんだけどなあ。 脱稿直後にリリースがあってげんなり。

_ [Ruby] forums.ps2dev.org :: View topic - Ruby on PSP

PSP (Playstation Portable)の上でRubyが動いたという話。

私はPSPには詳しくないんで、Ruby on PSPの詳細についてはわからないが、 「Nokiaケータイで動いた」ことよりも驚きが大きかった。

弟のPSPを借りてきて動かしてみたいものだ。

が、いざ動いたとして「Hello World」以上に何をやるのかというのは、 正直、思いつかなかったりするのだけれども。

_ [Ruby] Practical Ruby for System Administration: Books: AndrBen Hamou

という本が出るらしい。

「前書きにfunnyなことが書いてあるので、それでいいか」というメールをもらった。 クリスマスの生誕劇をもじったシーンで、飼葉桶にMatzがいるというお話。

えーと、うーん、クリスチャンとしてはちょっと複雑。 まあ、ジョークに目くじら立てるのもねえ。 内容は面白かったし。

_ [OSS] Open Tech Press | FOSSの理想郷ブラジルにイメージ失墜の危機

FOSS(Free/Open Source Software)全盛の地と言われているブラジルの陰の部分。 まあ、なんでもいいことばかりでもないよね。

ブラジルでフリーソフトウェアの人気が高いのは本当らしくて、 この間Larry Wallと話をした時も、 「ブラジルではロックスターみたいに扱ってもらえた」と言ってた。 カンファレンスなどの出席者数も半端じゃないみたいだし。

で、昨年はブラジルとアルゼンチンのイベントからお誘いを受けたのだが、 両方とも日程があわなくて断らざるをえなかった。 とても遠いので気軽に引き受けられないのだった。

でも、一度行ってみたい気はする。

_ [OSS] OSS普及には新しい価値観をもった人々がリーダーシップを--日本OSS推進フォーラム

日本OSS推進フォーラム代表幹事の桑原洋氏。

中小規模のSIerなどは、かつては大手のレガシー戦略のもと、いわゆる下請けという立場で厳しい状況のなかビジネスをおこなってきた経緯がある。何か自分たちの力だけでブレークスルーを起こし、ビジネスとして大きな成功を果たせないか。そのひとつの選択肢として、OSSのビジネスで大手よりも先手をとろうとする企業がでてきている。

一方、大手にとっては、OSSのビジネスはまだまだ規模も小さく、当然のことながら大きな売り上げも期待できない。さらに、政府調達などでのOSSに対する官の動きも当初より緩慢で、現段階で大きな先行投資をこの分野に対しおこなうべきか迷いがあるというのだ。

うち(NaCl)なんかは この戦略を取った典型的な例であろう。 うちのサイズ(50名程度)のSIerだと、 オープンソースという武器が無ければ、下請けの下請けくらいにしかポジションを占めることはできなかったであろう。

ただ、オープンソースの認知度が上がってきたことと、 景気が上向いてきたことで若干危機感はある。

認知度が高まり、市場が大きくなれば、今まで手をこまねいてきた大手が 参入して競争が厳しくなるだろう。 また、「オープンソースを使ってお安く」という比較的景気低迷期に最適化された 戦略がだんだん通じなくなる(というか、差別化要因でなくなる)のも痛い。

次の一手を練らねばならない。いや、もう始めてはいるけど。

_ Effective Debugging using Dave Thomas' ”Programming Ruby” - evolutionNext WebLog

書籍『Programming Ruby』を使った効果的なデバッグ(虫退治)。 本を大切にする人にはあんまりお勧めではない。

_ [知財] 「松本零士氏　クリエーターの思い」著作権攻防

もうそういう浪花節は勘弁してください。

「自分の財産権に期限がついているのはうれしくない」という感情はわからないでもない。 けど、それであらゆる著作物の権利を巻き添えに延長するのはコモンズの見地からも ありがたくはない。

いっそ、「登録制で無期限延長」を推したい。 ５年ごとに更新するとかで。

おまけにデフォルト(無登録)では、発表後10年とかだと申し分なし。 ベルヌ条約には反しそうだけど。

で、こういう後ろ向きの話よりは、 こちらの『「Ｊホラー、リメークによりハリウッドで勝利」著作権攻防』のような お金を払ってでも活用したいという前向きの話を読みたいものだ。

_ [言語] プログラマーの常識を学ぶ前に

＠ITの記事。

で、「プログラマーの常識を身に付けるのにJavaはうってつけ」なんだそうだが、 その理由が明示されてない。 「Java言語の着実な普及に加え、最近オープンソース化されたことも相まって、Java言語の情報処理技術分野における重要性はますます高まって」いるからってことなのかなあ。

よくわかんないや。

_ [Ruby] xruby - Google Code

Javaバイトコードへのコンパイラxruby。

今回のリリースの特筆すべき点はsample/test.rbがちゃんと動くということ。 test.rbの中身を知っている人にとっては驚愕すべき点だ。