Matzにっき

_ [会社] 就職活動

そろそろ来年卒業の学生さんたちが活発に活動しているようで、 うち(netlab.jp)にも、 「会社説明会はありませんか」とか、「資料をください」、 「面接を受けたいです」などという問い合わせがくるようになった。

それはそれで良いのだが、地元新聞社が運営している就職サイトなどからの問い合わせを受けたもので、 記入してあるメールアドレスに返信したところ「User Unknown」でエラーになるケースが頻発している。 どうも携帯メールのアドレスの記入間違いや、変更したことを忘れているなどが原因のようだ。

せっかく説明会の案内が受け取れないのは学生さんたち自身にとって不利だと思うのだが。 くれぐれもアドレスはお間違いのないように。

_ [OSS] NPO法人や神戸情報大学院大学がオープンソースのイベント，MySQL創業者やZope CEOが来日講演

OSCARアライアンスと神戸情報大学院大学が神戸と東京でイベントを開くという話。

イベントのプログラムなどはこちら。 それから、申し込みページ。

オープンソースジャパンの動向には注目している。 地味な我々とは違ったやり方だが、それで成功するものならそれはそれで良いと思う。

参加しようかなあ。でも、技術屋にはそれほど面白い話ではないかなあ。

ITmediaには、 角田社長のインタビューあり。

_ 「日本企業はCOBOL資産を利用し続けるべき」と英マイクロフォーカス社長

一から再構築するよりも、COBOLアプリケーションを利用すべき理由を、ヒル社長は三つ挙げる。具体的には、（1）既存のCOBOLアプリケーションをオープン環境に移植したほうが、開発コストを安くできること、（2）めまぐるしく変わる経営環境下で、アプリケーションを素早く構築できること、（3）これまで稼動してきたアプリケーションゆえに、不具合を起こすリスクを低くできること、である。同氏は、「実際、既存のCOBOLアプリケーションを流用することで、一から構築した場合と比べて、30％ほど生産性が向上した実績もある」と語る。

私の知らない世界ではあるが、そういうものなのかもしれない。

その場合には、ぜひOpenCobolを使うと良いと思う(笑)。 少なくともうちの会社では本格的事務処理アプリケーションをLinux＋OpenCobolで開発できている。

_ [OSS] FLOSS-JP オープンソース / フリーソフトウェア開発者 オンライン調査日本版

結果がまとまった。関係者の皆さんはお疲れさま。

結果から傾向を読み取るのは各自の宿題ということで。

_ [特許] 「ソフトウェア特許は弊害をもたらす」、MySQLのマーティン・ミコスCEO

全面的に賛成というほどではないが、

ソフトウェア特許を保有し、ほかの企業から特許使用料を徴収することだけをビジネスとするような企業は、特許海賊、特許漁り、あるいは暴利をむさぼる特許企業などと呼ばれています。こういった業者に狙われると、こちら側が武器を持っていても役に立ちません。報復手段もなければ、取引や交渉の手段もないのです。なぜなら彼らは自分たちの製品を持っていないからです。何も製品を販売していないのです。

ですからこの問題は、ソフトウェア業界全体、それも中小規模の企業よりも大手企業に打撃を与えるのです。暴利をむさぼる特許企業の唯一の存在意義は、彼らの行動がソフトウェア特許の弊害がいかに大きいかを人々に認識させる役割を果たすということです。

という点には共感する。ただし、

少し考えれば、ジャーナリズムや芸術、文学、音楽など、特許が認められていない分野が数多く存在するのに気付くでしょう。そして、ソフトウェアを数学、ジャーナリズム、文学などと同じ分類に含める必要があり、その方が合理的であることが分かるはずです。

というのは心情的には理解できるが適切な表現かどうかはわからない。 ちゅーか、数学も特許になる時代になってから久しいし、 そのうち芸術・文学などの特許も出かねない。少なくともアメリカでは。

最近、http://www.freshpatents.com/をウォッチしているのだが、

• 窓のない部屋に窓をつける技術(フラットディスプレーを壁に飾るだけ？)
• 非揮発性メモリを利用してブート時間を短縮(Linuxのinitrd？)

というような素敵な特許申請が目白押しだ。願わくばこれらの特許が成立しないでくれたらいいなあ。 面倒だから。

_ FAQ based Web site

後輩たちが開発している「Rast - N-gram based full-text search system」のページが完成した。といっても現時点ではまだソースも公開していないので、ただ存在するだけだけど。

で、このページを作っている時に、Webサイトのデザインが話題になった。

最近では一般のWebサイトもBlogツールやWikiなどを使って作ることが増えてきた。 しかし、ユーザー、特に初心者ユーザーにとってフレンドリーなのはやはり質疑形式ではないだろうか、と。

そこで思いつくのはFAQベースのサイト構築法。

トップページの内容は

• Rastとはなんですか
• 最新の話題はなんですか
• 主な特長はなんですか
• 現在実装されている機能はどこまでですか
• Rastのライセンスはどうなっていますか
• このソフトウェアをどこからダウンロードできますか
• 開発スケジュールを教えてください
• 連絡先を教えてください
• Rastってどう読みますか、どんな意味ですか

という感じ。とにかく終始一貫FAQスタイル。

どんなもんだろうか。なんだか0262560992を思いだすなあ。

_ [知財] iPodショックから日本企業は何を学ぶのか

「笠原一輝のユビキタス情報局」より。

前回筆者は、今の日本のコピーワンス方式は容認できないと書いた。なぜなら利便性や自由度を損なうという、ユーザー側の論理だけでなく、日本の産業界にとっても、そして結果的にはそれを強いている放送業界の側にとっても有害なモノであると思うからだ。

(中略)

日本の機器ベンダが日本独自の事情に振り回されているうちに、海外のベンダがどんどん魅力的な製品を作り、それを海外でどんどん投入されたら、どうなるか。今後、デルなどのIT系企業がデジタルAVに参入してきた時に、高コストの日本企業は太刀打ちできなくなる可能性がある。日本向け製品と海外向け製品で別の製品を作らされることになれば、それだけ日本の機器ベンダの競争力が低下していくからだ。

(中略)

その結果、日本企業は広告に回せる費用が無くなり、広告を出すことが難しくなる。そうなれば、広告収入に頼っている放送業界にとってもかなり痛い状況になるのではないだろうか。これは言ってみれば“最悪のケース”だが、このまま突き進めば、こうなるのは目に見えているのではないだろうか。

それなのになぜ、良い点だけしか視聴者に示さず(放送業界からコピーワンスの件について聞いたことはない、隠しているとは言わないまでも、触れたくないとは思っていそうだ)、「破滅への道」を突き進むのか。

音楽業界でも同じようなことが起きた(起きつつある)。

なぜ、ネットワークウォークマンが受け入れられなかったのか、それはソニーの幹部が認めているとおり、サポートするコーデックの著作権保護(DRM)を厳しくしすぎたため、ユーザーにそっぽを向かれたからだ。

しかし、そんなことになる前に、もっと緩やかな著作権保護を採用するなどの選択肢はなかったのだろうか? おそらく、ソニーの関係者も心の中では「こんなモノだめだ」と思っていたのだと、筆者は思う。実際、筆者もある機器ベンダの社員に「こんなのじゃ受け入れられないと思いますよ」と何度も言ってきた。そうした時に、機器ベンダの関係者から帰ってきた答えは「それはよくわかっている、でも駄目なんです」というものだった。

駄目だとわかっているのに、できなかったのだ。なぜかと言えば、レーベル側が強行に駄目だと言い続けてきたからだ。

目先の利益しか見えない経営者たちによってコンテンツホルダー、ベンダー、ユーザーすべてが不幸になる。 それがコピーワンスや強ＤＲＭのたどる道だ。手遅れにならないうちに手が打てないものか。

_ [言語] カールとターボリナックスがリッチ・クライアントソリューションで提携

本国で不調な言語ビジネスを引き取った(株)カールが生き残るために模索を続けている。

最近のAjaxやJSON*1のようなテクノロジートレンドの前にはますますCurlは不利のような気がするけど、それでもなお、Matzにっきは言語ビジネスに果敢にチャレンジする(株)カールを応援します。

_ [Ruby] The Internet Company − Special Offer for Ruby Users

年＄５０でホスティングを、というのはあまり珍しくないし、単にRubyが使えるというのだと普通の話だが、

• Ruby CGI
• FastCGI
• proxy-integrated WEBrick
• mod_ruby
• PostgreSQL

までサポートするのはちょっと珍しい。それだけではない。ここは更に

• Ruby on Rails (either with PostgreSQL or MySQL)
• IOWA

までサポートしているそうだ。なんと勇気があることだ。

_ ピアノの移動

出社前に妻と二人で電子ピアノを二階の子供部屋からリビングへ移動。 子供たちが最近一階にばかりいてちっとも練習しないから、というのが理由だが、 練習嫌いの子供たちには別の動機づけが必要なのかもしれない。

それはそれとして、電子ピアノとはいえ結構重い。 腰を壊すかと思った。

_ Computer History Museumに見る小型化の歴史(その1)

「本田雅一の週刊Mobile通信」より。

カリフォルニア州マウンテンビューにあるComputer History Museumに見るコンピュータの歴史。 ハードウェアが着実に、安く、速く、小さくなっていく歴史を目で見ることができる。 この博物館には一回行ってみたいな。

しかし、ソフトウェア、特にプログラミング言語の方はさほど進化していないなあ。 少なくともFortran、COBOL、Lispが生まれた５０年代のコンピュータと現代のコンピュータほどの違いはない。 それどころか時代がやっとLispに近づいてきた程度ではないかと。

まあ、言語ってば基本的には「思考のための記法」なので、 人間がすぐには進歩しない以上、そんなに急激には変われないんだけど。

_ [OSS] 効果的なリリースの仕方

アップルは年に2〜3回新製品を発表するが、その度にマック・ファンが熱狂して、マスコミの目を引く。アップルは、その狂騒に乗じて広報活動を行っている。オープンソース・プロジェクトは、こうしたアップルのやり方に学ぶべきである。広報こそ新しいユーザーを獲得する鍵であり、新しいユーザーはオープンソース開発モデルの活力なのだから。

なるほど。考えてもみなかった(だからダメなんだ)。

となると、1.8.4のリリースはOSCONの会場からというのはどうだろう。

問題は宣伝文句だな。完全安定期に入った1.8系では目新しい機能は入りそうにない。 人目を引くためには、もっとたくさんの機能が追加されたリリース、つまり1.9系を打ち上げるしかない、か。

それは開発者サイドにはあんまりうれしくないかも。

_ [言語] JSON: The Fat-Free Alternative to XML

上のエントリでも触れたJSONはJavaScript Object Notationで、 JavaScript(やPython)で読み込める記法でオブジェクトを表現しようという試み。

過去に私が「私はなぜXMLを愛していないか 〜 言語屋の視点から」で書いた XMLへの不満に対する答えにもなっている。

JSONは以下のような「XMLは優れている」という主張ひとつひとつについて、 「少なくとも同程度には優れている」ことを丁寧に示している。

• http://www.simonstl.com/articles/whyxml.htm
• http://www.karto.ethz.ch/neumann/caving/cavexml/why_xml.html
• http://www.softwareag.com/xml/about/xml_why.htm
• http://www.xmlspy.com/manual/whyxml.htm

詳細は上記JSONページを見ていただきたいが、 要約すると「JSONはXMLと違って拡張(新規タグの定義)とかはできないし、 ドキュメントマークアップ言語ではないが、 データ表現フォーマットとしては単純性、相互運用性、可読性において同等か、より優れている」ということだ。

Rubyに変換するのも簡単だ。 YAMLとどっちが優れているか、決めるのはちょっと難しいかも。

単純さではJSONの勝ちだが。

_ 初節句

末娘の初節句。でも、なんにもしていない。 雛人形を出すのもこの子が分かるようになってからでいいかな、と。

_ [特許] ブラウザ特許訴訟、控訴審でMicrosoftが逆転勝利

Eolasの「ブラウザ特許訴訟」に関して、米連邦控訴裁が一審の判断を破棄して、 審理のやり直しを命じた、という話。

ただし、この記事は相当ミスリーディングで、この記事だけ読むと

「Eolasの特許訴訟で地裁評決を覆し、審理を差し戻すという本日の控訴裁の決定は、Microsoftのみならず、インターネットユーザーにとっての明白な勝利だ。当社はこれまで一貫してEolasの特許は無効だと訴えており、本日の決定は当社の立場がはっきりと肯定されたものだ」。 Microsoftは声明でこう述べている。

Eolasとカリフォルニア大学関係者からのコメントは今のところ得られていない。

とあたかもマイクロソフト完全勝利のように読める。

実際はもうちょっと複雑で、同じITmediaの記事である 「プラグイン特許訴訟、差し戻しに−米控訴裁が下級審判決を無効と判断」を読めば、単に差し戻しになっただけで、 一方的にマイクロソフトが勝利したわけではないことがわかる。

今回の判決は、下級裁判所の判決を一部破棄して残りは支持し、判断全体を無効として差し戻した上で裁判のやり直しを命令する、という複雑なものだった。このことから、両当事者はともに勝訴を主張している。

「重大な問題の大半が明確になったため、この判決は大学にとって勝訴だと考えている」とカリフォルニア大学の広報担当Trey Davisは述べ、「Microsoftにとって重要な問題については、同社の敗けだ」と語った。

と、カリフォルニア大学(特許所有者でEolasに独占的ライセンスを提供している)は、 自分たちの勝利を主張している。Eolas不利の流れは事実だろうが(そしてそれは望ましいことだ)、 あまりにもミスリーディングな記事は弊害の方が大きい。

_ [OSS] オープンソース・イニシアティブ、ライセンス急増への対策を提案

増え続けるオープンソースライセンスへの対策として、 OSIがOSDに３項目追加を検討という話。

• 既存ライセンスと重複しないこと。

  新しいライセンスは、認定済み既存ライセンスがカバーしていない問題を解決するために設ける

• 簡潔で理解しやすいこと

  法律の専門家向けではなく、一般の人々にも理解できるように記述する

• 再利用可能なこと

  特定の個人、組織、プロジェクトの名称を差し替えるだけで、ライセンスの条件を変えることなくほかのオープンソースにも適用できるようにする

訳文の引用は日経IT Proから。

私が感じたことは、すでに該当記事内でBruce Perensによって述べられていた。

「OSIが採用する項目としては良いと思う。しかし、これらはオープンソースライセンスの定義というよりも、OSIの認定ガイドラインといった部類に属するものだと思う」（Perens）

OSDの既存の10項目は「オープンソースとはなにか」を記述したものであった。 追加が提案されている3項目は「OSI認証ライセンスの満たすべき条件」を記述したものであり、 性質が違うので明確に区別されるべきだと思う。

_ [OSS] IBM、オープンソース支援策を発表--学生の求職やスキル習得をサポート

IBMがオープンソース開発を支援するため、求職者データベースの構築やEラーニングに取り組む、 という話。

これらがどのくらい役立つのかは未知数だが、次々とアクションを起こすIBMは本当に上手だ。 本気度をアピールすることができていると思う。

ところで、日本でオープンソース開発者の求職者データベースとか作ったとしたら、 登録したい人はどのくらいいるだろう。アメリカと比較して人材の流動度が圧倒的に低いお国柄では、 なかなか勇気がなくて登録できない人が多数のような気もする。

_ 論文書きにおける悲劇のサイクル

1. ACM SIGPLANや情報処理学会から面白そうな論文を見つける
2. 読む
3. それを、動的言語、スクリプト言語、Rubyなどのコンテキストに応用することを考える
4. そのコンテキストで不足する部分を補う論文を構想する
5. 一人悦に入る
6. しばらく経つと少し冷静になる
7. 新規性はそんなにないじゃないか、と思うようになる
8. orz
9. そして1.に戻る

_ [言語] Category in Objective-C

どうやらObjective-Cの「カテゴリ」と呼ばれる機能が、 以前から悩んでいたselector namespaceに近いもののようだ。 基本的な概念は理解できるものの、実際の挙動(と実装)がイメージできず苦しんでいたので、 参考にできるものがあるのはありがたい。

しかし、ちょっとGoogleしてみた範囲内では、その仕様はよくわからなかった。 具体的な挙動や実装について参考になる資料はないものだろうか。

あれ？ まてよ。

今、改めてGoogleしたページを読み返すと、別に有効範囲が静的スコープであるとは書いてないな。 そうするともしかしてカテゴリってのは、ただ単に「インスタンス変数が追加できないMix-in」なのか。 それだったらすっごい残念なのだが。

selector namespaceのある言語といえば、他にSmallscript (S#)やJavaScript (EcmaScript 4.0)などもあるが、 いずれも現時点で私には理解できていない。

情報提供歓迎。

_ お葬式

知人のお母さんが亡くなった、ということで、教会でのお葬式(偲ぶ会)に参加する。

私は故人とは面識はないが、人々に愛されていたことがよく分かる会であった。 簡素ながらも思いやりが感じられる良い会であったと思う。

父と同じ68歳。早すぎる死という印象もないではない。 彼女の霊が安からんことを。

_ [OSS] オープンソースカンパニーユヒーロ再び

先日、オープンソースカンパニーであるという、 株式会社ユヒーロについてとりあげたら、 ユヒーロ代表であられる伊藤寛之氏が、わざわざブログを始めてまで反応してくださった。

自ら「ユヒーロがオープンソースカンパニーを名乗る資格を有しているかと考えると、私自身も個人的には“NO”である」と認めつつも、「思いつきであるにせよオープンソースカンパニーを名乗ることの本当の気持ちを考えてみると、今まで、そしてこれからもお世話になるであろうオープンソースソフトウェアに少なからず貢献したいという思いがあったことも事実」であり、また、

ユヒーロが真のオープンソースカンパニーを目指すにあたって以下のことを目指していく必要がある。

1. オープンソースソフトウェアを利用する人たちが少しでも増えるように努力すること。
2. オープンソースを利用する人たちがより快適に利用できるようにサポートしていくこと。
3. 自社のソフトウェア「HiTo!」を将来的には、オープンソースとすること。

後日、オープンソースと人について改めて考えてみたい。

と非常に前向きに考えておられる。念のため書き添えておくが、 私はオープンソースをただ利用するだけの企業を軽蔑したりはしない。 が、オープンソースに積極的に貢献しようという気持ちのある人や企業には賞賛を惜しまない。

Welcome to the Open Source World.

Matzにっきは、オープンソースカンパニーとしてさらなるステップを踏みだそうとしている株式会社ユヒーロを引き続き応援します。

_ [OSS] IT業界に根付く神戸情報大学院大のオープンソースカリキュラムとは

オープンソースは(隠されているところがないので)教材としてふさわしいものが多いし、 オープンソースに理解のある優秀な人材を輩出してくれれば、 業界全体がよくなるかもしれない。

こちらも暖かく見守りたい。

_ [特許] EUのソフト特許法案、7日の閣僚会議で承認へ

今日はニュースが多い。

この文面を読む限りでは最悪の展開になったということかしら。

ヨーロッパはソフトウェア特許に関して一進一退を繰り返しつつも、 悪くない動きを見せていたのに、ここで一転、大企業に有利な決定がされたということは、 世界がより住みにくい世界になったということを意味しているような気がする。

将来、引退したらヨーロッパにでも住もうと漠然と思ってたんだけど、 あんまり良くないかなあ。どこかの国が(tax heavenならぬ)patent heavenとか宣言して、 自国内では外国の特許は無効(もちろんWTOにも加盟しない)とかいう動きを見せたら、 ...一発で外交圧力でつぶされそうだな。

_ 「サマータイム」がやってくる!?

日本にも夏時間(DST)を、という話。反対。

Rubyが海外にも使われるようになった2000年頃からしばらく、 毎年春と秋になるとアメリカやヨーロッパから時刻に関するバグレポートがやってきた。 夏/冬時間の切り替わりで一定期間だけずれが生じるというものだ。 で、これがまた面倒なバグでねえ。 あるケース(たとえばアメリカ)で直ったかと思うと、ヨーロッパではうまくいかなかったり。 夏時間のない日本に住んでて今まで本当にしあわせだったと痛感したものだ。

省エネや活動時間の調整は各自で行いましょう。 もう大人なんだから。

_ 情報処理学会第67回全国大会 - 情報の検索・抽出最先端

検索エンジンを開発している後輩(部下)たちには参考になるかも。 ....ならないかも。

_ SAJAX - Simple AJAX Toolkit

AJAXフレームワークを使ったWebサイト開発を支援するツールキット。 現在はPHPのみをサポートしているが、ASP, Perl, Python, Rubyにも移植したいとのこと。

ちょっと見た感じでは、AJAXプログラミングがちょっとラクになるかな、という気はした。 150行弱のPHPコードでここまでできたら上出来か。

もうちょっと洗練する余地はありそうな気もする。

_ [言語] Dynamic Languages Symposium

というものを、OOPSLA 2005と併催するからProgram Committeeとして参加してくれないか、 というメールが来る。名誉なことだから受けたいのだが、 参加できるかもわからないしなあ。ちょっと迷いが。

_ 寒さとお祭り

子供たちが通っているスイミングスクールがある海洋センターが、 小さなお祭りをするということで、遊びに行く。 が、この日は妙に寒くて、雪は降るし、出店とかも中止になったものが多かった。 息子はスーパーボールすくいを本当に楽しみにしていたので、かなりがっかり。 唯一やっていた射的も6発もらってひとつも当たらなかった(最後の一発は私が撃ったのに当たらなかった)ので、 ますますがっかり。相当落ち込んでいた。

とはいうものの、隣のいろり茶屋で食べたお蕎麦はおいしかった。

その他、買い物をいくつか。

_ [教会] 松江

第一日曜なので松江。聖餐会では何人かの方が先日の告別式についてお話をした。 「心のこもった会であった」という印象は共通のもののようだ。 キリスト教式の分かりやすい会であった(素人には意味がわからないお経とかはないし)、 というのもあるだろうが、それよりなにより故人が生涯かけて築いた人徳があるのだろう。 葬儀社の人も「私もこういう式がいいなあ」と言っていたとか。

その他はごく普通。

夕方、先月できなかった長女との面接。思春期の割に素直な娘に育ったものだ。 ありがたいことだ。

_ [Ruby] Matsue Ruby Meetup Group

告知

知る人ぞ知る(登録会員１名)のMatsue Ruby Meetup Groupは、 3月8日(火)午後6時30分からミーティングを行います。

場所は

松江市学園南 2-12-15 HOYOパークサイドビル2F
(株)ネットワーク応用通信研究所

0852-28-9280

です。テーマは「最初なので自己紹介」 あるいは「RubyとWebアプリケーション」 または「Ruby 2.0の仕様について考える」です。 当日の参加者の希望によって決めようと思います。

なんとなく会社のメンバーしか集まらないような気がしますが、 一般の参加者も歓迎します。

_ [言語] Span

SmalltalkのセマンティクスにJava的構文を与えたような言語。 お約束のHello Worldはこんな感じ。

class Hello {
  static public main: args {
    Console << "Hello World!\n";
  }
}

こういう言語では(Rubyのように)ifやwhileなどは文法で持つことが多いし、 またメソッド呼び出しの形式も「obj.method」にするような気がするが、 SpanはこれらはSmalltalk形式のまま。

2 + 2;
5 + 2 - 7;

Array new: 10;
Rect x: 5 y: 5 width: 10 height: 10;

(5 >= 4) ifTrue: {
    this doWhenTrue;
} 
ifFalse: {
  this doWhenFalse;
};  

1 to: 5 do: #(cnt) { 
  cnt doSomething; 
};

要するに「Smalltalkにより普通の構文を」という出発点は同じでも、 アプローチにおいてRubyとは違う道をとっている(Rubyが捨てた点を残し、Rubyが残した点を捨てている)。 これが成功するのかどうかは私にはわからないが

あと、興味深いのはSpanは実行エンジンにParrotを採用している点だ。 Parrotかんばれ(Pugsに負けるな)。

_ [言語] Pugs

PugsとはHaskellで書かれているPerl6コンパイラである。 一瞬「本気か？」と思ったが、大いに本気らしい。

作者のインタビュー。

_ 韓国で有名な日本人

IRCで韓国人が話していた。「韓国で有名な日本人といえばYuminとAyumiだ」。

松任谷由実と浜崎あゆみのことかと思えば、全然違う人らしい。

• Yumin http://search.empas.com/search/imgdir.html?f=V&m=B&e=7&w=82&q=%C0%AF%B9%CE&qn=
• Ayumi http://search.empas.com/search/imgdir.html?f=V&m=B&e=1&w=89&q=%BE%C6%C0%AF%B9%CC&qn=

日韓の文化の溝はまだ深い。

_ [言語] The Nice programming language

kazamachiさんからの情報。JVM上で動くyet another language。 IBM Developer Worksのalt.lang.jreでもとりあげられている。

Java言語の冗長なところを取り除いて、 Parametric Typeなどを強化した、という感じか。

DBC(Design By Contract)やmulti-methodをサポートしているのは良いところだ。 というか、Javaが最初からこれくらいできていれば苦労しないですんだ人は多いだろう。 十分に保守的なので「Javaのあるべき姿」と言っても良いかもしれない。

でも、レシーバがある場合のmulti-methodの定義構文は好きじゃない。 定義と呼び出しで見かけが全く違うから。

void laugh(String str){
  println("haha, I'm holding an instance of " str);
}

let myString = new String("Andy");
myString.laugh();

_ [言語] Eleven

この「Matzにっき」で紹介した言語もかなりの数になると思うのだが、 よくもまあ次々と現れるものだ。言語好きとしては嬉しい限りだ。

Elevenは、 信頼性の高い、スケーラブルなWebアプリケーションを開発するためのプログラミング言語で、 Cに似た文法でデータベースをバックエンドとしたアプリケーションを開発できる。 Elevenで開発されたWebアプリケーションは PHPまたはmod_perlで動作する(ということは、コンパイラはPHPまたはPerlを吐くということか)。

面白いのはセッション状態変数をすべてMySQLデータベースに記録するので、 セッション管理などは暗黙的に行われる(これをstatesafe variableと呼ぶ)。

statesafe var first, last;

display
{
  print ("Please enter your name.");
  edit ("First name: ", first);
  edit ("Last name: ", last);
}

display
{
  print ("Thank you, ", first, " ", last, ".");
}

これだけで２画面を持つWebアプリケーションを実装したことになる(右図は実行例)。 実行例には「Updated state for user 1005.」とか「Continue」「Logout」とかのように 「どこから来たのか？」と疑問に思う部分もあるが、 とりあえず気にしないことにする(いざとなればソースを読めばよいから)。

それぞれのdisplayがWebアプリケーションの各画面に相当しており、 ロジックが非常にわかりやすい。画面遷移の記述として非常に直感的だ。 すばらしい。

次の例も衝撃的だ。

statesafe table
{
  var deadline    "Task deadline";
  var description "Task description";
} todolist;

display
{
  edit ("Enter your tasks: ", todolist);
}

これでToDoリストアプリケーションが実装できた、ということらしい(右図)。 非常に興味深い。tableというのがpredefinedな構造で、 "edit"に対して「Modify...」、「Remove...」、「Add entry...」などまで含めて提供しているようだ。

なかなかよくできている。 プレゼンテーションとロジックの分離のような 最近のWebアプリケーションサーバーでのはやりの仕組みはどうなっているのかという点も気にならないではないが、基本的な方向性は非常に共感できる。

で、考えてみると、これって別に新しい言語を導入しなくても、 Rubyのブロックとインスタンス変数を使ってライブラリで実現できそうだ。こんな感じで。

statesafe :first, :last;

display {
  print "Please enter your name."
  edit "First name: ", @first
  edit "Last name: ", @last
}

display {
  print "Thank you, ", @first, " ", @last, "."
}

だれかElevenのアイディアをRubyのライブラリとして実装しようという人はいないだろうか。

_ [Ruby] Meetup for The Matsue Ruby Meetup Group

ということで、開催された。

事前の予想通り、社外からの参加者はなかったが、告知時間が短かったのでしょうがないだろう。 参加者は、私から時計まわりに、 まつもと、しゅうご、ゆうや、ごう、どん、こうじ、けんご、かずひこの計8名(敬称略)。 どこかに食べに行くか、という話もあったが、それでは食べるばかりでミーティングになりそうもなかったので、 オフィスの大机でピザを取ることにした。

結局、なんだか雑談で終わってしまったような気もするが、とりあえず話したこと。

• 自己紹介(のようなもの)
• Rubyと求人(ちゅーか、どんな新人に来てほしいか)
• RubyとWebアプリケーション(ちゅーか、社内で開発中のWebアプリについて)
• Ruby 2.0(「いつでるんですか？」「できたとき」「はぁ」)

あとなんだっけ。Lispにおけるレキシカルスコープとダイナミックスコープの話とか、 いろいろしてたような気がするけど。きっとかずひこくん辺りが議事録を出してくれるんではないかと。 出ても雑談ばかりで価値があるかどうかはわからないけど。

反省点など。

• けっこう楽しかった(私は)。他の人は退屈だったかも。
• 時間が長すぎ(6時半から11時近くまで)
• 雑談に終始して生産性(？)は低かった

次回も開きたいが、今度はテーマを決めた発表か、CodeFestにした方が良いかもしれない。 時間も1時間半くらい限定で。

_ 出会え系

ところで、今回利用したMeetup.comだが、 ミーティング中にさっそく「今回のMeetupはどうだったか」とか「次回はいつにするか」とかメールを送ってきた。なんと積極的な。これは「出会え系(命令形)」とでも呼ぶべきか。

_ [言語] Eleven続き

昨日、「ElevenのアイディアをRubyのライブラリとして実装する人はいないだろうか」などと書いたら、 moriqさんがRailsで実装してくださった。

こんな感じ。

require 'eleven'

class FooController < ApplicationController
  include Eleven
  statesafe :first, :last

  display {
    print "Please enter your name."
    edit "First name: ", @first
    edit "Last name: ", @last
  }

  display {
    print "Thank you, ", @first, " ", @last, "."
  }
end

第一歩としては上出来ではないだろうか。

_ [Ruby] Meetup Group Meeting レポート

昨日プレッシャーをかけておいたので、 Meetup Groupミーティングのレポートのようなもの が、かずひこくんのところにアップされた。注目。

_ [Ruby] Ruby 2.0 ブロックローカル変数

昨日のミーティングで話そうと思ってて、 あまり盛り上がらなかったので触れなかった話題。

Rubyのブロックスコープをなんとかしたいとずっと考えてきた。 で、今までにもいろいろなアイディアを練ってきたのだが、なかなか決められなかった。 最近になってやっと「これなら」というものが出来上がったように思う。

仕様は以下の通り。

• ブロックパラメータはローカル変数のみ
• ブロックパラメータのスコープはブロックローカル
• ブロックパラメータ名が外側のローカル変数と重複したらエラー(前田くんの勝ち)※
• ブロックパラメータの後ろに「; 変数」という形でそのブロック内でだけ有効な変数名を指定できる※
• これらの変数も重複はエラーになる
• ブロック内で初出の変数のスコープはブロックローカル(今まで通り)※
• メソッド内で使われたスコープが終わってしまった変数への参照は警告になる※

今まで「2.0ではこうする」と宣言してきたものとは違うが(特に※の部分)、 互換性はより高いし、使い勝手も悪くなってないと思う。 特に「ブロック内初出のローカル変数のスコープ」については、 メソッドスコープにすることを強く反対していた dblack はよろこぶことだろう。

さて、これにより

3.times {|i; a|
  a = 5
  p [i, a]
}

のような文が許されることになる。本当は

3.times {|i; a=5|
  p [i, a]
}

のように初期化もいっしょにしたいが、「|」が式の中に登場することのある演算子なので、

• あきらめる
• 初期化にはprimary(リテラルとか変数とか括弧でくくった式とか)しか許さない

のいずれかになりそうだ。

3.times {|i; a=2+3|
  p [i, a]
}

がエラーになるのを受け入れられるかどうか、だな。

_ [OSS] Rast ファーストリリース

N-gram 方式の全文検索システムRastのソースコードがとうとう公開された。 ここ数ヶ月の後輩たちの成果を見てやってほしい。 ただ、まだ最終版からはほど遠いのでお手柔らかに。

_ [OSS] The Power of Blocks in Ruby is accepted

OSCON 2005へのプロポーザルが採択された。 テーマは「Yield to the Block: The Power of Blocks in Ruby」とするつもり。 Rubyの特徴であるブロックの活用方法をいろいろと語る４５分のセッション。

さて、これで行く方法を算段しないといけなくなったな。 夏休み期間にアメリカ行くのにどのくらいかかるかな。

_ [OSS] FOSS企業を成功に導く7つのヒント

• FOSSコミュニティを馬鹿にしてはいけない
• ビジネス・プランに集中せよ
• FOSSの再パッケージングでは力不足
• 人材の必要性は変化する。それを見越した雇用計画を作れ
• プログラマと非プログラマの分裂を避けよ
• 全員が製品とコミュニティを理解せよ
• ビジネス・コミュニティとFOSSコミュニティの両方に企業を売り込め

ごく当たり前のことが書いてある。 ただ、翻訳はあんまり良くないような。「？」と思ったら原文を参照。

_ [Ruby] 思いつき

Rubyではレシーバが省略された関数的形式で呼ばれたメソッドはselfのメソッドと見なされる。 ただし、privateと設定されたメソッドがエラーにならないという違いがある。

これはこれで便利なものだが、ちょっとだけ欠点があって、 単にユーティリティとして使いたい関数的メソッドで名前空間が消費されてしまう。 ただ単に手続きをまとめるためにだけ作ったメソッドでも、 重複するといけないのでサブクラスで同名の関数を使うことはできない(正確には可能だが、トラブルになる)。

そこで、関数形式で呼ばれたメソッド呼び出しでは、メソッド探索を当該クラスからはじめる、 というのはどうだろう。仕様はより複雑になるが、再定義されたメソッドを利用しないので、 サブクラスの都合によりメソッドの動作が変化してしまう事態や、 メソッド名が偶然衝突してしまう危険性を避けることができる。

当該クラスからのメソッド検索に必要な枠組みはすでにsuperの実現のために用意されているので、 実装もそんなに難しくないはずだ。

仕様が複雑になることと、関数的メソッドをオーバライドできないこと、がデメリットだが、 そんなに悪い取り引きではないと思う。

1.9で実装してみようかなあ。

_ [Ruby][言語] 「Regarding Ruby (and Ruby on Rails)」または初心者向け言語の落とし穴

RubyをPHPやJavaと比較するという話。

「Ruby is too easy to be used as a first language」という観点は面白い。 つまり、最初Rubyでプログラミングを学んでしまった人は、 それがあまりに楽で簡潔なので、 他の言語に移行する時の学習曲線が急勾配になりすぎるということ。

そういわれれば、そういうこともあるかもしれない。 私だってRubyでプログラミングを学んだわけじゃないものなあ。

しかし、同じ論理はより強力に「なでしこ」や「ドリトル」にもあてはまりそうな気がする(HSPにも？)。 これらの言語で学んでしまった人は他の言語に移行するのが大変になるかもしれない。 ずっとその言語で閉じていればいいけど、いざ他の言語が必要になったら...。

いや、人間の柔軟性はそれくらいなんなく克服するのだろう....と、信じたい。

_ ハネムーンナンバー

トラックナンバーに代わる新しい指標。トラックナンバーの定義は

The TruckNumber is the size of the smallest set of people in a project such that, if all of them got hit by a truck, the project would be in trouble.

トラックナンバーとはトラックに轢かれるとプロジェクトの遂行が困難になる最少の人数

であるが、一方のハネムーンナンバーは

チームのメンバーが順にハネムーンに旅立って行くパターンを全て考え、 何人目でプロジェクトが停止してしまうかの平均値

である。トラックナンバーがブラックユーモアであるのに対して、 ハネムーンナンバーは「おめでたい」ことであるという違いが大きい。

いや、冗談はともかく、トラックナンバーが最悪のケースしか示すことができないのに対し、 ハネムーンナンバーは不均質なプロジェクトメンバーを表現できるというのが大きい。 上記のページでは、

• ゴレンジャー(5人そろっていないとプロジェクト遂行不能)
• サイボーグ009(9人中ひとり(009)はクリティカル)
• デンジマン(5人中だれか残っていれば良さそう)

のような例で楽しく解説している。

ハネムーンナンバーの最大の欠点は、 トラックにはねられる事態が(ブラックであるにもかかわらず)誰にも起こりえることなのに対して、 プロジェクトメンバーがハネムーンに出かけるのはそんなにありそうに思えない点だ。

もう行っちゃった人は二度は行かないだろうし、 まだ行っていない人はなかなか行くことがイメージできない。

_ [特許] こんなにあったUI特許--ジャスト-松下裁判で浮かび上がる課題

国内では現在、3000件超のUI特許が成立済み。だが、出願時に新規性などを正しく判断できたか疑問が残る特許もある。

10年前のピーク時より減ったとはいえ、現在でも年間500件ほどのUI特許が出願されている。

そもそもUI特許に関しては、「産業発達という特許制度の趣旨にそぐわず、特許として保護するべきではない」との意見もある。だが、日本政府の方針もあり、プロパテント化の流れは止まりそうもない。

勘弁してくれ。

_ Colorization Using Optimization

モノクロ映像(静止画・動画)を簡単にフルカラー化する恐るべきテクノロジ。

この技術があれば、『カサブランカ、フルカラー・ハッピーエンド版』*1も夢じゃない。

_ [特許] ITmediaニュース：先願主義を導入すべき-MS弁護士、特許法改正を訴える

米Microsoftの顧問弁護士ブラッド・スミス氏は、...変革が必要とされる4つの領域を挙げた。1つ目は特許の品質と量、2つ目は悪質な訴訟を最小限に抑えること、3つ目は特許法の国際的調和、4つ目は個人発明家および小規模企業による特許出願を行い易くすることだ。

(中略)

スミス氏は、「故意の侵害」の基準を改正し、真に悪質な侵害行為に限定すべきだと主張した。

その主張はわからないでもない。マイクロソフトぐらいパワーがあれば、 法律への変更の働きかけも現実味を帯びるよな。

_ [特許] アマゾン、「女の子にはピンクの包装紙」を提案するシステムで特許取得 - CNET Japan

えーと、

• 購入された玩具が人形用の服である場合、それを受け取るのは女の子であると推察できる
• 受取人が女の子であると推測される場合、ピンクまたはパステルカラーのプレゼント用包装紙を最初に提案できる
• ある年に2歳児用の玩具を購入した顧客が、翌年の同時期に3歳児用の玩具を購入した場合、その次の年からはこの情報を活用して、顧客にリマインダーメールを自動送信できる
• 注文されたのが香水で、注文日がバレンタインデーの1週間前ならば、その香水はプレゼント用であると推測できる

いや、確かにそうなんだろうけど、なにも特許にしなくても。 通しちゃうUSPTOも大問題だけど。

_ [教会] 新見

ステーク大会土曜の部で新見に。 前々からおそれていた通り、朝から雪。

今回は国道181号経由で新見に向かったが、 明地峠が積雪と凍結で大変。スノータイヤが減っているのもあってかなり恐かった。 峠を抜ける30分でぐったり疲れた。

集会は第一部、第二部ともにわかりやすくてよかった。 もっとも、「わかる」だけじゃだめで、実践が伴う必要があるんだけど。

ある人が「事故をみかけたが助けてあげるべきだったかもしれない」と話していた。 私たちも来る途中スリップしてガードレールにぶつかった車を見かけたが、 特になにもしなかったのを思い出す。運転手にもけががなさそうだったし、 とりあえずなんとかなりそうだったのだが、声かけくらいはしてもよかったかも。

帰りの峠は完全に凍結していて、チェーンが必要だった。 車に乗り換えてから14年になるがチェーンを使ったのは初めて。

滑らないから恐くはないが、うるさい。

_ 言い訳

おくじさんの日記から。

私が応募者に必ず尋ねる質問の一つに、「フリーソフトウェア・プロジェクトに参加したことがありますか」というのがあります。「ない」というのが大多数で、決まって「時間がないので」と言います。

応募者はほぼ学生なんですが、これは絶対に言い訳でしかありません。学生より暇な人種がこの地上に一体どれぐらい存在するでしょう。

(中略)

じゃあ、本当のところ何なのかと言うと、単なる意志の欠如だ、と話していたのです。かなり高い確率でそうだと私は信じていますが、一方で新たな疑問というか、納得しきれないところもあります。

うむ。そろそろ面接希望の人も出ているし、来週には会社説明会もあるし、 この質問を聞いてみようかなあ。

ただ、うちの場合、松江での面接希望者の大半は「松江にある(面白そうな)ソフトハウス」という認識で就職を希望するＵターン希望者のような気がするから*1、フリーソフトウェアの関りは期待できないかなあ。

つまるところ、エネルギーの問題なんですかね。電気とかじゃなくて、人間の持つ精神的活力というやつ。実際、長期的に活動している人って、みんなエネルギッシュだもんなあ（私自身は疲れ気味にしか見えないかもしれませんが）。

うーん、エネルギーの問題というのはありそうな気がします。 それより大きいのは敷居かなあ。なんだか敷居が高いみたいなんですよねえ。

_ [教会] 新見(2日目)

朝5時に起きると松江でもけっこう積もっている。

昨日の反省を踏まえて、まず早朝からタイヤチェック。 見ると前輪が著しく減っているので、ローテーションを試みる。 慣れないタイヤ交換で45分は費やす。 今日一日分の体力をすでに使い切った感じ。

道も変えた。今度は国道180号から生山、新見へと向かう。 道中それなりに積もってはいたが、危険なことはなかった。

鳥取県から岡山県に抜けた瞬間に積雪量がぐんと減り、 やはり山陰は陰なのだという俗説に対する傍証を得た。 同時に岡山県側の道路が貧弱なのを見て、 鳥取県の道路は立派という別の俗説に対する傍証も得た。

娘二人はコーラスに参加。2時間の集会中、 壇上で子供たちがじっとしていられるかという点が心配だったのだが(小学校低学年の子供もいたし)、 きちんと訓練されていたのか、子供たち自身の意識が高かったのか、 「おりこう」にしていた。感動した。

「世の光になる」というテーマで何人かからお話を聞いた。 まず引きこもってないで世の中に出て行かないとなあ、と感じた。

帰り道、四十曲峠で脱輪している車を見かける。 見ると知人であった。展望台の駐車場手前の溝の蓋が外れていて、 しかも雪でまったく見えないので前輪を落としてしまったのだという。

なんとか牽引ケーブルを用意して、さあ引き出すかと思った時、 通りかかった見知らぬ人がさっと自分の車を動かして、ケーブルを繋ぎ、 脱輪した車を引き上げた。見事な手際。

それが終わると名乗ることもなく、さわやかに去っていった。かっこいい。 まるで「よきサマリヤ人」のようであった。

アアイウヒトニワタシハナリタイ。

さて、やっとのことで玉造に帰り着くと、 最後の坂道が登れない。雪でタイヤがスリップしてしまうのだ*1。昨日初体験したチェーンを試してみよう。

がりがりがり、途中までは登れたが、最後の最後でタイヤが空転してしまう。 だいぶ苦労した。最後にはなんとか車庫にいれたのだが、もう、これ以上ないってくらい疲れた。

そういえばこの悪天候で、かずひこくんもWikiばなの帰りに飛行機が飛ばず苦労したらしい。

_ 体調不良

昨日疲れすぎた。家族そろってなんとか朝食を食べたのだが、 子供たちが登校した後、再びふとんに倒れ込み、目が覚めたのは昼の2時だった。 うーん、まだ疲れが残っている。 今日は会社説明会があり、就職希望の学生たちが来るというので行きたかったんだがなあ。

しかし、かずひこくんが私の代わりに「フリーソフトウェア・プロジェクトに参加したことがありますか」と質問してくれていたらしい。予想通りの反応だったみたいだけど。

_ MM!

あることがきっかけで、ふとTypeKeyのアカウントをとったので、 この機会にMMを使ってみることにした。

「Matzめも」という名前でこの「Matzにっき」のネタ候補メモが見つかるかもしれない。

_ [Ruby] RubyURL.com in a hour...

Ruby on Railsを使って、TinyURL相当をわずか1時間で開発できた、という話。 すばらしい生産性。

Railsはこのような生産性ネタが豊富で、マーケティング的にも優れている。

_ 確定申告

〆切日にならないと動けないのは、悪い癖だ。去年もそうだった。

原稿の締め切りが押しているので気分的に書類整理をする気にならなかったのもあるのだが、 しょせんは言い訳である。確定申告の期限が原稿の〆切よりも前である以上、 いつかはやらなくてはいけないことは、はるか前から分かっていたはずなのだから。

わかっちゃいるけどやめられない♪

昨年必要経費として使ったお金を合計し、 源泉徴収票、昨年分の支払い調書、医療費の領収書とともに公民館へ。 印鑑忘れて一度取りに帰ったりしたけど、なんとか無事書類処理完了。

例年、玉湯町中央公民館では玉湯町税務課の職員が丁寧に対応してくれる。 上記のセット(印鑑、源泉徴収票、支払い調書など)だけあればちゃんと処理してくれる。 おまけに待ち時間も(最終日であるにもかかわらず)ほとんどゼロ。すばらしい。

しかし、来年からは市町村合併で松江市になるので、このすばらしいサービスが継続されるかどうか心配だ。 で、対応してくださった職員の方に来年もここで受け付けますか、と聞いてみた。 答えは「分かりません」だった。合併後のことは決まってないことが多いらしく、 職員の人も不安そうだった。このすばらしい住民サービスが低下しないことを切に望むものだ。

_ [特許] キムチの作り方

freshpatents.comより。

キムチの作り方は複雑だし、時間はかかるし、匂いはあるし。 だから、簡単で、若い人や外国人にも受け入れられるキムチの作り方の特許。

要するにあらかじめ調合した「ドレッシング」を用意し、 白菜などをそれに漬けることでキムチを作る、というアイディア。

えーと、それってキムチの素？ 誰か教えてやったほうが良いのでは？

_ [特許] 抗菌コンピュータ

これもfreshpatents.comより。

光触媒を使った抗菌コンピュータ。これを発明として新規性を認めろ、と。 この特許の23のクレームの中には今までだれも思いつかなかった発想がある、のかもしれない。 ざっと読んだ限りでは見当たらないけど。

_ [特許] 特許庁にビジネスモデル申請 - 内部告発システム開発で泰希堂

京都新聞(虚構新聞にあらず)。

企業の内部告発をインターネットで受け付け、経営改善に役立てる社内通報システムを経営支援サービス会社、泰希堂（京都市上京区）が開発し、特許庁にビジネスモデル申請した。

システムは、事前に認証番号とパスワードを与えた社員や主な取引先などから専用サイトで内部告発を受け、匿名で内容を経営者に報告する仕組み。経営者から依頼があれば、提携先の弁護士や税理士らのアドバイスを文書で提供する。

基本使用料は１万円。通報１件につき１０００円で、１年に１回通報を義務付ける方針。専門家への相談は別料金。

「内部告発を義務付ける」というのはどういうことか、とか、 「通報1件につき」という価格体系はいかがなものか、とか、 思うところはいろいろあるが、 最大の懸念は、これでビジネスモデル特許を申請するってのは、ほめられたことなんだろうか、という点だ。 いくら申請するのは自由だとは言え。

千数百年の歴史を持つ京都周辺では特許とか知財とかに関する認識が違うのだろうか。

_ [OSS] 続・言い訳

先日のエントリが予想外の反響があって驚いている。 反応リンク集までできてるし。

しかし、全般に私の(たぶん、おくじさんも)意図した部分とは違う話になってしまっている。 オープンソースプロジェクトにどうやって参加するとかは、私の主眼ではなかったのだ。 ま、興味深い話だから、それは別に話そう。

わたしの会社(netlab.jp)は、 オープンソースを中心とした地方の小さなソフトウェアハウスだ。従業員数は40名強。 東京にもオフィスはあるが、主力は島根県松江市にある。 正式名称は「(株)ネットワーク応用通信研究所(略称: NaCl)」というが、 あまりに長いので業界では「ネットワークさん」とか「ネットワーク通信研究所」とか、 いろいろな「あだな」で呼ばれている。 中には「Rubyのまつもとがいる会社」としか呼ばれないケースもあるようだ。

ま、それはどうでも良いのだが(ホントはよくない)、 そういう会社にも「就職したい」という希望者はいて、 会社説明会とか開けば、それなりに聞きにくる人はいるのだ。

しかし、現在までのところ、就職希望者から「オープンソースを仕事にしたい」とか、 「最先端のソフトウェアを開発したい」とか、 「プログラマとしての自分を伸ばしたい」とかいうような前向きな動機が聞かれることはめったにない。

むしろ、「(将来食いっぱぐれがなさそうなので)コンピュータ関係に」、 「地元島根で就職したいので、松江のソフトハウスならどこでもよかった」というような動機の人ばかり 見かけるのだった(さすがに直接はそう言わないけどね)。

んでもって、「時間がない」とか言い訳する人は、決まってそういう人たちだったりするんだな。 まあ、正直に「今まで関心なかったから」とは言えないのかもしれないけどなあ。

そういう人たちの中でも、将来「化ける」人がいないとか限らないけど、 現時点でハッカー素養が発現していない人を採用するのは(結局発現しない可能性を考えると) かなりリスキーだ。日本の雇用制度では、駄目ならすぐクビとはいかないし。 だからどうしても現時点で外から見て素養が分かる人を採用せざるをえない。

オープンソース(フリーソフトウェアでもいいけど)はハッカー素養のある人をひきつける傾向があるので、 オープンソースへの気持ちを聞くのはハッカー素養の判別に役立つ。ただそれだけのことだ。

ということで、netlab.jpは、前向きな態度のハッカー(あるいはハッカー予備軍)を歓迎します。

具体的には、

• プログラミングが好きな人
• 自分で学ぶことができる人
• 創造性がある(と自分で思いこめる)人
• ブレーキが壊れた人
• 自分の可能性をプレゼンできる人

などの条件を満たし、私たちと一緒に働きたいという人は、 jobs@netlab.jpまでメールをどうぞ。

_ 米Yahoo!、架空の「テクノロジー予測株式市場」を開設

米Yahoo!の研究機関であるYahoo! Research Labsは15日、テクノロジー出版大手の米O'Reilly Mediaと共同で研究プロジェクト「Tech Buzz Game」を開設したと発表した。

まあ、要するにキーワードを会社とみなした株式市場みたいなものだ。

Programming Lanugageというマーケットもあり、Rubyがエントリされている。で、さっそくエントリして、株を購入してみたのだが、

• Lispが妙に高いし
• RubyがPythonより高いし
• 株価の変動が予想しにくいし

なかなか利益が出せない。Groovyへの投資は元が取れそうだ。

こんなのを見てると本当の株に手を出すのがためらわれるなあ。

追記:

2週目に至って株価の変動は全体に安定してきたようだ。 Rubyは安めに推移していて損確定(泣)。

_ [家族] 卒業式

長女の小学校の卒業式に参加する。 もうそんなになるのか。

なかなか気持ちのいい式であった。 ビデオに撮ったのだが、あとで見返すことがあるのだろうか。

しかし、今日は寒く、会場も凍えるようであった。 おかげで妻は風邪を引いてしまったようだ。 たいしたことにならずにすめばよいのだが。

_ Undergraduation

Paul Grahamの新作。コンピュータサイエンス専攻の学生が卒業までに学んでおいた方が良いことはなにか、Graham流の助言。

• ハッカーになる(のを学ぶ)こと
• 数学(のメタファ)
• その他なんでも
• 仕事に役立つ知識
• 大学院について

ここで(私にとって)重要なのは「仕事に役立つ知識」についての彼の言葉。

What you should learn to get a job depends on the kind you want. If you want to work in a big company, learn how to hack Blub on Windows. If you want to work at a cool little company or research lab, you'll do better to learn Ruby on Linux. And if you want to start your own company, which I think will be more and more common, master the most powerful tools you can find, because you're going to be in a race against your competitors, and they'll be your horse.

(超訳)大企業に勤めたいならWindowsを、クールな小企業や研究所に勤めたいならLinux上のRubyを学ぶべき。自分で起業したいなら最強のツールを自分で探すこと。

ご存じのようにPaulは(元)Common Lispハッカーで、そのつながりでLight-weight Languageを推奨している。 その文脈でPerl, Python, Rubyを紹介することもたびたびあった。

しかし、私の記憶する限り、今まで彼がRubyについて言及する時にはいつも「PythonやRuby」というような、 無視はしないものの、おまけのような扱いであった。まあ、RubyはPythonよりもマイナーだし、 当然の扱いだと私自身も考えていた。

しかし、上記の引用では「Ruby on Linux」とはっきり書いている。 もちろん、ここでの正確な意味は「Rubyのような動的言語」であることは間違いないのだが、 Paulの中で「RubyはPythonよりマイナー」という意識が減ったことを示しているような気がしないでもない。

いや、考えすぎかも。

_ [言語] Sun、動的言語を支援する「Coyote」プロジェクト

同社は...、「Coyote」と呼ばれる新たな開発プロジェクトをSun Public License（SPL）の下で立ち上げた。その目的は、開発者がNetBeans IDE（統合開発環境）を使って動的言語でコードを書く上で役に立つモジュールを作ることにある。

JVMベースの動的言語を支援するIDEということか。まあ、動的言語のプレゼンスが向上することは望ましいことだと思う。

_ [言語] ParenScript

Lisp (というか、S式的文法を持つ言語)をJavaScriptに変換するコンパイラ。 これでJavaScriptを書かなくてすむ、しかし、そこまで嫌わんでも。

変換例:

(defun apply-effect () 
   (when (and document.all photoslider.filters) 
      (let ((trans photoslider.filters.reveal-trans)) 
          (setf (slot-value trans ’*Transition) 
                (floor (* (random) 23))) 
          (trans.stop) 
          (trans.apply))))

これがこうなる(↓)

function applyEffect() { 
   if (document.all && photoslider.filters) { 
      var trans = photoslider.filters.revealTrans; 
      trans.Transition = Math.floor(Math.random() * 23); 
      trans.stop(); 
      trans.apply(); 
   } 
} 

_ [教会] 岡山

会議。乗せてもらったのでラクチン。道中ほとんど寝ている。先週の疲れが残っているのだろうか。

会議では運営方法について提案を行ってみたが、通じたかどうかは分からない。 いや、変更した方が良いと思っているのは私だけかもしれず、 変更した方がまずい側面もあるのかもしれないが。

それとは別にちょっとショックなこともあった。 嬉しいことも一緒にあったのだが(詳しく書けないのが残念)。

_ [Ruby] Java vs Ruby (or RIFE vs Rails)

ことの発端は、theserverside.comで Geert Bevinが「Ruby on RailsはJavaの10倍の生産性とは本当か」と提起したことだ。

彼はRailsの典型的アプリケーションであるTa-da Listを JavaとRIFE frameworkを使い、

• 行数はTa-da Listより300行多い(50%増)
• 開発期間は2日(サーバ側)
• いくつかの機能追加とバグフィックスを行った

というBla-bla Listを作ったのだった。 ついでに、GeertはTa-da Listのセキュリティ問題も発見している(すでにfixされている)。

ま、Rails効果ってのは、Rubyを使っているという点以外には、 徹底してDRY (Don't Repeat Yourself)を実践することで実現されているので、 同じような設計思想のWebアプリケーションフレームワークがあれば Javaだろうが似たような生産性を実現できてもなんの不思議もない。 DHH(Railsの作者)がRailsに対してやったのと同じマーケティングを、 GeertはRIFEに対して試みたと見なすのが自然だと私は思った。

ところが、これに対して

• Railsの10倍の生産性とは信じられない、というRails懐疑派
• Rails効果は本物だ、というRails擁護派
• Rubyの求人なんかないじゃんか、というJavaビジネス派
• (Bla-bla Listの使っている)Laszloは駄目だ、というアンチLaszlo派
• いずれにしてもFUDはヤメロ、というアンチFUD派
• 「本物の」アプリケーション開発にRubyのような「スクリプト言語」は不十分、 Javaのような「本物の言語」が必要だ、というJavaラブ派(or アンチスクリプト言語派)

が絡み合って、コメントが伸びる伸びる。おまけにDHHも参戦した。こちらは(ソースは公開されていない)Ta-da ListとBla-bla Listでソースを並べて、Railsによるアプリケーションの簡潔性を示していた。

それに対するGeertの返事。要約すると「一番極端なところを比較してもしょうがない」ということ。説得力があるようなないような。

その後も議論は止まらない。最後には「〜じゃないか」「そんなことは主張してない」と泥仕合風味。

見かねたLucas Carlson(Rails派)が、 「Ruby vs. Java: A matter of taste」という記事を自分のブログに書いた。これは視点の違い、趣味の違いだとする公正なもの(だと私は思った)。

それでもまだ議論は収まりきっていないようだが、 いやあ、みんな自分のフレームワークを愛しているからこんなにもめるのか、 それとも「マーケティング」手段になにか根本的な間違いがあるのか。

個人的には、「スクリプト言語では不十分」という主張が気になった。 この主張に関する話はなんとなく尻切れトンボで終わってしまったのだが、 結局「遅いから」ってことなんだろうか。 そればかりでもないように感じられたのだが、具体的な指摘は出なかったなあ。

もちろん速度的な問題はあるけど、それ以外でRubyでは無理で、 Javaならできることなんてないような気がするけど。

_ CC-Wikiライセンス

なんてものができたらしい。

Wikiのような集合的著作物をどうするかというのは結構悩ましかったりしたのだが、 これで少し解決に向かうか。もっともCC-Wikiで解決するのはいくつもある問題の内の一部だけど。

Rubyリファレンスマニュアルもこれにしとくかなあ。 あ、でもncつけといた方が良いのか。

_ [言語] The State of the Scripting Universe

スクリプト言語の代表として

• Damian Conway (Perl)
• Rohan Pall (PHP)
• Guido van Rossum (Python)
• Dave Thomas (Ruby)
• Jeff Hobbs (Tcl)

にインタビューしたもの。このインタビューはメールを通じて行われたので、 解答者はお互いの答えを知らなかった。

内容は、うーん、わりと普通。簡単に要約すると

• スクリプト言語はもはや小さなプログラム向けではない
• でも誤解はなかなか解けないんだよねえ
• むしろDynamic Languageと呼んでほしい
• 近い将来、ほとんどのプログラミングはDynamic Languageで行われるようになる

とかいうようなもの。言語は違えど意見がほとんど同じであるところが興味深い。 お互いの意見を参考にしているわけでもないのに。 あと、Damianが徹底的にRubyを無視してるところとか(泣)。

必読、とまでは言わないが、 近い将来のプログラミング言語のトレンドの参考になるかも。

_ 地球の壊し方

「環境を破壊する」とか、「人類を絶滅させる」とか、 「地球を死の星にする」とか、「世界征服する」とかは、 文字通り地球を破壊することに比べたらいかに簡単なことかということを述べたページ。 文字通り地球を破壊するさまざまな方法が提案されている。

しかし、そこまで地球を破壊しようという熱意はどこから来るのか。

それはそうと、このページに出てくる「von Neumann machine」とは、 私の知っている「フォン・ノイマン機械」とはまったく違うもののようだ。

_ [Ruby] Ruby Conference 2005

事前登録が開始された、とのこと。

今年は、10月14日(金)から16日(日)まで、場所はカリフォルニア州サンディエゴ。

では、渦中の人、Rails作者、David Heinemeier Hanssonのお言葉をどうぞ。

You have to come. I went last year and had the most wonderful three days in the company of most of the best Ruby hackers. I'm so most definitely going again this year. You have to come.

(超訳) 絶対行くべきだ。去年、ぼくも行ったけど、 すごいRubyハッカーたちに囲まれてサイコーの３日間だったよ。 ぼくは絶対今年も行くね。君も行くべきだ。

(DHHに会ったことないので口調は想像です)

今年こそは私も行けたらいいなと思っている。

さて、Ruby Conference直後にはOOPSLA 2005が開催される。 また、同じ会場で2005 International Symposium on Wikisも開催される。

日本のWiki魂を見せつける猛者はあらわれないものか(Ruby関係者に限らず)。 Wiki Symposiumの投稿〆切は、それぞれ

• Research paper and practitioner report submissions are due April 29, 2005
• Workshop, and panel submissions are due April 8, 2005
• Demonstration submissions are due July 1, 2005

だそうだ。

_ [Ruby] Five Things You Didn't Know You Could Do with Ruby

Hal Fulton (『Ruby Way』の著者)による記事。 どちらかというとマネージャでも分かるような「実例集」になっている。

彼によると「5つのこと」とは、

• Process Satellite Images and Meteorological Data

  NOAAは気象衛星から送られたイメージ処理にRubyを活用している。

• Easily Code and Run Multi-Server Web Applications

  数多くの「エンタープライズサイト」がRubyで構築されている。

• Run Sophisticated Distributed Applications

  dRuby, XML-RPC, !okey/rpc, Ruby/MPI

• Troubleshoot the Space Shuttle Disaster, and Perform Other Advanced Simulations

  シミュレーション分野にもRubyは使われている。たとえばNASAはRubyを使ってスペースシャトル事故の解析を行っている。

• Interface with Other Applications, Technologies, and Services

  他のシステムと簡単にインタフェースできる。SWIG, RubyInline, SOAP, Win32APIなどなど。

実は、これは「Five Things You Didn't Know You Could Do」シリーズの一環で、他にも

• With Python
• With PHP
• With Tcl
• With Perl

がある。ただ、他の言語の「You Could Do」はもっと技術よりだ。

_ コードがドキュメントだ

Martine FowlerのBlikiより。原文。

私が常々主張していること*1。こんなふうに書けたら、誤解されずにすむのになあ。

_ The Pragmatic Studio

Pragmatic Programmersによるセミナー。 コロラド州デンバー、ワシントン州シアトル、バージニア州レストンで開催される。

この講師に３日間フルタイムで教わって650ドルは安い。 が、日本から参加するのは現実的ではないか。

_ [言語] UnderC

組み込みを意識したC++インタプリタ。同種のものとしてはCintやChが有名だが、 よりコンパクトであることを意識しているようだ。LGPL。

_ [Ruby] Selenium

Webアプリケーションのテストツール。テストを一般のブラウザでドライブするのが特徴。 実装の詳細は見ていないのだが、 ブラウザを使うということで、WWW::Mechanizeのようなやり方よりは互換性が高いかもしれない。

_ [漫画] 『巌窟王』と思い出

本屋で漫画雑誌を眺めると、 小学校、中学校、高校まで同じ学校の先輩が連載を始めていた。

２０年ぶりに見る先輩の漫画は、あんまり変わってなかった。 でも、ちょっと抑えてあったかな。 今後は漫画の道に進むんだろうか。

考えてみれば、当時は自分も高校生だったから気がつかなかったけど、 ２０年前に十代であれだけ描けたってことはすごいことだったんではないだろうか。 卒業直後からもう伝説になってたしな。

思い返せば私の高校時代は「鳥取県西部漫研黄金時代」の直後で、 二級上まではすごい人がたくさんいた。前田さんしかり、赤井さんしかり。 プロになった人もいた(いまは小説を書いている人もいるな)。

しかし、黄金時代が過ぎ去った後の私たちの世代はもう出がらしで、 たいしたことはできなかった。まあ、私は「描く人」ではなかったし、 そもそも漫研じゃなかったし。

やったのはせいぜいCOMECON(米子だからコメなわけだ)という同人誌イベントを企画したくらいか。

_ [OSS] オープンソースソフトは時限爆弾 -- MS出資のシンクタンクが批判

このレポートを書いたKenneth Brownは「LinusはLinuxを書いてない、Minixの盗用だ」と書いて、 Tannenbaumにけちょんけちょんにけなされていた人。まだ懲りていないらしい。

「こんな馬鹿がいる」という以上には意味のない記事だが、 マイクロソフトもこんなのに出資しているという事実自体が彼らにとっての不利益ではないかと。

_ [Ruby] 「RPGツクール XP」東京工科大学の授業用教材として採用

学生の作品は公開していただきたい、ぜひ。

_ [言語] 企業で真価を発揮するP言語 -- Burton Group報告

「R言語」のRubyは「P言語」の中間にいれてもらえないのは悲しむべきか喜ぶべきか。 もっとも「R」と同じ仲間に分類されても困るが。

ところで「G言語」って「GMW」の「G言語」、…じゃないよね、きっと。 「C」と「G」は4つ離れているから「#」を「+」4つと解釈したのかなあ。

でも、

(C++)++

だから、「+」4つじゃ、「E」にしかならないんだけど。残念。

_ [Ruby] Writing a simple Ruby evaluator

あらすじ。「ブロック中のretryの動作の説明に疑問を感じたTom Moertelは、 その意味を理解すべくHaskellでRubyのmini evalulatorを実装し、 その動作を完全に理解したのであった。Cool」

そこまでやるか。継続を使ったretryの挙動の記述は(継続が理解できていれば)わかりやすい。

_ The Guerrilla Guide to Interviewing

Joel on Softwareより。2000年3月だからずいぶん古い話だ。

良い人材を採用するための面接について。Joelは必要な資質について、 「今なにができるか、ではない」という。それはこれからいくらでも学ぶことができるから。

必要なのは

• Smart (賢いこと)
• Gets Things Done (仕事を達成すること)

の両方を備えていることである、という。

両方備えていないのは論外として、どちらかしか持っていないとするとどうなるか。

Smartだけの人は(しばしばPhDを持ってたりするが)、実用にならない方向に能力を使ってしまう。 すばらしいが(ビジネスとしては)役には立たない。

Gets Things Doneだけの人はもっと悪い。彼らは考えずにプログラミングする。 コードを関数化せずにコピペしまくったり、 とりあえず動くが拡張性も何もないコードを書いたり。 結果として将来大きなトラブルを引き起こし、 他のSmartな人々の手を煩わせることになる。

でもね、Smartだけの人でもいいと思うんだ。他の人の意見を聞く耳があれば。 Gets Things Doneの部分は他の人が補うことができると思う、ある程度は。

あ、でも、ビジネスには「夢想家」は要らないかな。

もっとも私自身も若い頃は単なる夢想家で、 実力も知識も行動力もないため、壮大な構想を夢想するだけだった。 でも、人はいつかそこから卒業して、地に足をつけてなにかを作り出す必要があるのだろう。

_ [Ruby][OSS] OSC 2005 セッション「Ruby Hot Topics」

Skypeで聞いてました。なかなかおもしろい。

でも、最後の私の質疑のところは面白くなかった。 いや、質問が少ないのもそうだけど、私もあまり気の利いた答えができなかったので。

それと、ああいうイベントって終わった後の雑談とかから有益なヒントが得られたりするんだよねえ。 Skypeじゃそういうの、ないものねえ。

_ 出雲

出雲へ。朝は半期に一度の監査。聖餐会では、転出する人がいるので最後の話だとか。 いい話だ。 私は今年で生誕200年のジョセフ・スミスについて。

集会終了後、あわてて松江に移動。 送別会と17年度のセミナリーの説明会に参加。忙しい。 今年は朝型の生活に(強制的に)変えられそうだ。

一日が終わってから今日が復活祭であることに気づく。 クリスチャンとしていかがなものか。この際、来週あたりに心の中で祝うことにしよう。残念。

_ [会社] 就活デー

今日は午前と午後のそれぞれに来年の新卒のための会社説明会。 また、その後、2件の採用面接があった。

私はその内の片方に参加したのだが、 いやあ、面接は難しい。1時間やそこら話してもその人の内面とか本質は分からないし。 一応意見は述べたが私には最終決定権はない。

_ [OSS] FSF：「GPL第3版でフリーソフトプロジェクトが分割することはない」

「いろいろ言う人はいるけど、そんな変なものにはならない(なりえない)」という話。 正直なところ、FSFとしてはこれ以外の反応は不可能だろう。

_ IT資本論 観光と文化資本クラスター

松江圏の観光についてを例にした真摯な考察。 そうねえ、観光立国を考えるならもうちょっとなんとかした方が良いかもしれないねえ。

ところで、そういう島根県民自身があんまり近場で観光してないような。 「異邦人」であるところの、かずひこくんとかの方が近県出身でもう8年も住んでいる 私の家族よりもよっぽど観光しているぞ。その辺も検討の余地ありかも。

_ 山口へ

末娘を見せびらかせに妻の実家である山口へ。 例によって国道9号を西へ。出雲市内で渋滞したが、 後は普段よりは遅いもののまあまあのペースで移動。

今回は先日(だいぶ遅れた妻への誕生日プレゼントとして購入した)ポータブルDVDプレイヤーで 映画を見せることができたので子供たちがおとなしくしていた。 酔うのではないか心配したが、一番酔いやすい体質の長女は平気な顔をしていた。 逆に酔ったことはほとんどない次女が「ちょっと気分が悪い」と言っていた。

津和野の手前でどうしても眠くなったので12分間の仮眠。 今回は移動に5時間かかった。

_ [Ruby] 一時間で覚える Ruby

例示による学習法を用いたRuby入門。 本当に一時間で覚えられるのか、Rubyを知らない人をつかまえて試してみたいものだ。 私の身近な(Rubyを知らない)人は、 Rubyどころかコンピュータを使うまでに100時間くらい必要そうな人ばかりで、 参考にならない。

_ 遊ぶ子供たち

子供たちは遊びに来たイトコ(妹)と一日遊んでいる。 姉の方はピアノやら講習やらなのだそうだ。

次女はここ数週間このイトコとFAX文通をしていたので、 親友のようだ。もとから仲は良かったけど。

_ 日本通信 B-MOBILE

山口でネットから隔離されてしまうのは痛すぎる。 4月1日までに参加申し込みが必要な発表会があるし、 連載もゴールデンウィーク進行で〆切が早くなっている。

というわけで、契約が切れていたB-MOBILEカードの更新を行う。 32kリンクしかないが、圧縮してそれなりの体感速度で通信できる。 sshの-Dオプションとtsocksを組み合わせると ほとんどの通信をSOCKS接続経由で圧縮して行うことができる。 結構便利だ。

_ [言語] Five-minute Multimethods in Python

Pythonに最近加えられたfunction annotationを使ってmultimethodを実現する、と言う話。

面白い。

function annotationは「＠」という記号を使うし、 「あまりPythonらしくない」という印象だったが、 結構使いでがあるようだ。

Rubyがmultimethodを実現することはないだろうなあ。 上手に実現しないとduck typingを妨げかねないしなあ。

_ [OSS] 住商情報システム、VAリナックス子会社化でオープンソース分野を強化

VAリナックスがビジネスとして魅力的なことを意味しているのだと思う。 住商情報システムといえば「とんがった技術」に注目する会社だ。 Curlとか。未踏ユースのバックアップもしているはず。

ただ、

住商情報システムでは、オープンソースを活用して構築、運用する案件の目標受注金額を、2005年度20億円、2007年度100億円とする。

という大きな期待にVAリナックスの運営方針が曲げられたりしないことを切に祈る。

_ [OSS] ヒューメント、Firebirdの有料サポートサービスを開始

ヒューメントは4月1日からFirebirdの有料サポートサービスを提供することを発表した。3種類のメニューが用意され、価格は3インシデントで21万円から。

オープンソースビジネスは積極的に応援したい。 でも、「いちインシデントななまんえん」ですか。

データベースだとあり得るのかな。Rubyじゃ絶対に無理だな。

Royの社会的実験

ふたたびThoughtWorksについて。 ThoughtWorksは以下のような「通説」に反対する「社会的実験」なのだそうだ。

• 有能な人材しかいない会社なんて無理。有能な人材が利用する平凡な人材(less able people)もミックスしなきゃだめ。
• 頭の良い奴らは金儲けに興味がない。だから頭の良い奴ばかりの会社は生き残れない。
• 人のいい奴が損をするような厳しい世界だ。何か理由でもなけりゃ、従業員や顧客にいい顔する余裕なんてない。
• 有能な人材はみんなとうまくやっていけない。理屈ばかりこねて、ジコチューだから。
• 大企業には強力なマネジメントの仕組みが必要。
• 頭の良い奴らはB級学生に管理させなきゃいけない。なぜなら、頭の良い奴らは理想主義に走り過ぎて、実際の判断をくだせるほど、現実的になれないからだ。それができるのは、貪欲なB級の学生だ。
• 長期的にやることはうまくいかない。
• 会社の財務と業務の内容を内部に明らかにすることは悪いことだ。外部になんて、とんでもない。それにどうせ会社が大きくなったら、そんなことは続けられない。
• 弱点を公開してはいけない。外部の人間には特に。
• 国際企業になるということは、弱い国の人々を利用するということだ。
• 現場の人間に会社を脅かすような権限を与えてはいけない。
• 文化は二の次（長持ちしない）。優れたビジネス モデルこそが必要。

うーん、とんがっている。うち(netlab.jp)はここまで前衛的ではないなあ。 特に最初のもの(平凡な人材)について。もっともうちの場合は、

• 有能な人材を利用する平凡な人材(less able people)もミックスしなきゃだめ。

だけど。これは、おごちゃんの意向でもある。彼の主張は

• 会社は定食
• ハッカーはおかず
• とんかつだけではとんかつ定食にならない、ごはんも味噌汁もあって初めて定食だ

というものだ。だからいろんな人を取ろうとするわけ。

ThoughtWorksの人は(主にJAOOで)何人にも会ったことがあるけど、 みんな優秀そうで、またハッカー魂を理解している人のように見えた。 今後もThoughtWorksには注目していきたい。

_ 松江市玉湯町

山口に来ている間に、八束郡玉湯町は合併して松江市玉湯町になった。 これで今日から松江市民となる。税金が上がりそうなのは嫌だなあ。