国内初の民間刑務所となる美祢刑務所(えーと、正式名称は「美祢社会復帰促進センター」)で 刑務作業としてWebアプリケーション作成を行い、 その言語としてRubyが採用されたという話。
「社会復帰促進センター」は初犯限定の刑務所で収容規模は男女合せて1,000人程度。 今回対象となるのは女性のみ60名だとか。まず4ヶ月の教育を受けた後、 実際の作業に入るのだそうだ。
えーと、こういうプレスに名前が出るのは名誉なことだと思うし、 Ruby (on Rails)の生産性とか学習容易性(本当に容易なのかどうかはともかく、そう思われてる)が その理由となったのだと思うとうれしいことでもある。
が、発想は斬新だけど、なんか不安はないでもない。
直前に人力検索はてなで言語選択についての質問してたりするし、受託会社であるプリズニーズでは、 今現在も講師を募集してたりするし。
現在女子受刑者にプログラミング言語教育を行っていただける 方を急募しております 応募資格: なんらかのプログラミング言語で2年以上の業務経験のあるかたで 受刑者に対し偏見のない方。山口県美祢の刑務所に常駐できる方 契約形態: 契約社員、正社員、アルバイト 給与 ： アルバイト 時給3000円以上(月80時間以上働けること) 正社員・契約社員： 月給30万円以上（正社員の場合は社会保険つき） 期間: 4ヶ月〜(契約社員・アルバイト希望の方は4ヶ月でもＯＫ） 宿泊施設あり(弊社負担）
「なんらかのプログラミング言語」って、Rubyじゃなくてもいいのかなあ。
一瞬、応募しようと思ったのは秘密だ。
MicrosoftからのFlash対抗であるSilverlightがMIX'07で発表された。 Macでも動く.NETランタイムというのも画期的だが、 より注目すべきはこのSilverlightにはDLR (Dynamic Language Runtime)が含まれ、 対象言語がJavaScript, Python, Rubyであること。 同時にIronRubyも正式発表になった。ライセンスはBSDライクになるとのこと。
すげー、とうとうマイクロソフトからRuby処理系が登場したよ。 開発者John Lamのインタビューも公開された。
記念に今日は(秘蔵の)マイクロソフトTシャツを着ることにする。
以前のイベントで知り合った人たちがオープンソースラボに訪問してくださるという。 わざわざの松江まで来てくださっての訪問に感謝。
Exerbのゆうやくんや神戸大の坂本先生も一緒に来てくださる。 今はゆうやくんは神戸なんだね。
で、坂本先生は元九州大ということで、 しばらくして「あのSmalltalkシステムの〜」とか「あの(舞波さんのいた)坂本研の〜」とかが つながった。鈍スギです。
その後、お昼までご馳走になった。皆美の鯛飯おいしゅうございました。
「Erlangが優れているというならRubyから呼べばいいじゃない」ということで、 Ruby/Erlangブリッジ(のさわりだけ)。
結構期待できるかも。
そういえば、Erlangの優れているという並列実行処理系(のソースコード)をまだ読んでない。 恐らく単一代入による参照透明性を利用して、シェアード・ナッシングを実現しているのと マルチコアを最大限に活かすため適当にfork(またはスレッド生成)しているんだと思うけど。
SBCLでの新しいメソッドキャッシュ技法について。
フラットな配列をキャッシュに使って、invalidateをメモリアクセス一回ですませることで ロックを回避するというアイディア。無駄な領域が残るが、それは キャッシュサイズの拡大などの機会に一気に整理するということらしい。
スレッドが一般化するにつれ、このような技術の重要性が高まる、かも。
日本人は「給料や年収」「役職や地位」以外にも、目に見えない「4つの報酬」を重視している、という話。
その4つとは、
わかる気もする。金銭的な報酬ばかりを重視するとバランスが崩れることも多いし。 要するに満足する基準は人によって違うということ。
追記
書き忘れたこと。
そのいち。
金銭的な報酬以外を重視するのは日本人ばかりとは限らない。 たとえば、AppleのSteve Jobsが年収$1であるのが良い例だろう。 もちろん彼の場合はすでにお金に困っていないとか、 ストックオプションによっていくらでも稼げるとかは無視してはいけないだろうが。
そのに。
経営者の観点からは金銭的でない報酬というのは都合が良い。 いわくお金をかけないで人材を確保できるからだ。 これを経営者の陰謀と見るか、限られた源泉で最大限の満足を提供するための手段と見るかは人によって変わるだろう。
従業員の立場からも同様である。「金銭以外の報酬」という建前で丸め込まれると感じるか、 本当に満足感を得て充実して働けるか。それは個別の状況(人格とか、現状の経済的余裕とか)で 捉え方が変わるだろう。
プログラミング言語誕生の地。
一番驚いたのは、「Ruby誕生の地」をズームすると 0.95リリース当時の勤務先の住所になっていること。
一体、誰が調べたんだ。他の言語はどうなってるんだろう。
追記
このエントリへのリンク元で「Ruby生誕の地は名古屋」であるとの記述を数件見たが、 実際は、Ruby誕生の地は物理的には浜松市(舘山寺町)、厳密にはネット上(名前が決まったのは 東京・浜松間のチャット上だったから)である。
Borlandからスピンアウトした(というか、個人的な印象としてはこっちの方が「ボーランド」らしい) CodeGearのイベント。
今回は「CodeGearの新しいRuby IDE」が発表されるそうだ。 最初はRailsConfで発表されるらしい。 コードネームとかも聞いたけど、公表しない方がよいだろうな。
Ext3をベースにしたバージョニングファイルシステム。 任意の時間の状態に戻ることができるらしい。 OSXに搭載されるというタイムマシン機能のようなものだな(未来には行けません)。
カーネルパッチが必要と言うことなのでまだ試していない。
なんかファイルシステムまわりのいろいろな面倒から解放されそうなので 期待している。あと、ファイルシステムそのものに全文検索機能があれば 私の生活がずいぶん楽になりそう。
後者はfamとHyperEstraierを組み合わせれば現在の技術でも十分に実現可能だと思うけど、 面倒なので放置している。
言語設計における複雑さの尺度の話。Javaの場合。
|S|
------- × degree(S)
Min{S}
リファレンス(JLS)で変更な章の集合をSとし、 degree(S)はcross-referenceの量とする。
これによるとJDK 1.5での変更について
となるそうだ。複雑度に謎の定数aとかbとか残る時点で この尺度が不完全なことがわかるが、まあ、参考くらいにはなるかもしれない。
とはいえ、Rubyではこの方法では測れないな、仕様書がないから(苦笑)。
ある意味、目的に対して最適化した集団であると思う。 合理主義のアメリカらしい。
日本ではなかなかそういう風土・文化がなくて、 たとえば私のいる会社でも、そういう点では甘々である。
そちらの方が住みやすいと考えるのか、 効率が悪くて目的が達成できないと考えるのか。
どちらも真実ではある。
Erlangを学ぶためのリンク。英語ばかりだけど。 スエーデン語でないだけマシか。
せっかくのゴールデンウィークだし、ということで 米子(日吉津か？)にあるお菓子の壽城に出かける。
初めてなので、どんなところかと思ったが、
ほとんどただで楽しめたので悪いところではない。 が、頻繁に訪れるところでもなさそうだ。
そういえば名古屋にもお菓子の城という場所があったな。
分散バグトラッキング。 分散バージョン管理というのはあるが、バグトラッキングも分散してはどうか、という話。
中央リポジトリのない完全な分散バージョン管理システムが いまいち使いにくいような気がするのと同様、 完全な分散バグトラッキングシステムも使いにくいかもしれないな、という印象を持った。
とはいえ、たとえばLinuxでは分散バージョン管理が行われているわけだし、 運用の徹底と慣れでなんとかなるものなのかもしれない。
Tim O'ReillyがScalaに言及している。
Scalaは以前にも紹介したことが あるが、個人的にはマイナーなJVM言語だと思っていた。 しかし、いつの間にか私の気づかないところで着実に進歩していたようだ。
今回はActor的並列プログラミングが注目されているようだ。 Erlangとは違う形で(分かりやすい/扱いやすい)並列プログラミングを提供する言語になる、かも。
10進小数についてのFAQ。 浮動小数点数でなくても小数は難しい。
よく見ると、まとめているのはREXXの作者、 Mike Cowlishawであった。この人も多才な人だ。
なんとも見習いたいものだ。
月の第一日曜日なので証会。
ビショップの記録によれば、3月は8人、4月は9人の人が壇上に立った。
では、5月は10人かと思ったら、今日は15人であった。 たくさんの方が前に出てきてくださったことには単純に喜びたい。
昨日まで(正確には自宅に付いたのは日付が変わって本日だった)、 ユースカンファレンスに出席していた長女も自分の感じたことを 語ってくれた。なんか、感動した。親馬鹿？
Python 3000 PEP。型情報を変数名の末尾につけることで、 オプショナルな型を実現しようというアイディア。
こういうのもSigilって言うんだろうか。 3秒くらい「？」マークが浮かんだ*1。
ちょっと鈍すぎる。
*1 PEP3117の日付に注目
Mathematicaの通常形式とFullFormとを比較することで、 functional formが適切でないケースがあることがわかる、という話。
確かに、
cat a b c | grep xyz | sort | uniq
と
(uniq (sort (grep xyz (cat a b c))))
でどっちが読みやすいかと言われたら、ま、適切でないケースもあるよな、と思う。
RubyにおけるLazyListの実現。
こういうのを将来のArrayクラスに突っ込みたいんだけど、無謀かなあ。 違う言語になっちゃいそうだけど。
しかも、その為にはcontinuationかcoroutineかfiberを YARVに組み込まないといけないような。先は遠そう。
FOO CampのFOOというのはFriends of O'Reillyの略で、 Tim O'Reillyから招待状をもらった人だけが参加できるギークイベント。 「選民主義」と揶揄する人もいるみたい(そういう人が始めたのがBar Camp)。
で、今年はこの招待状をもらったんだけど、アメリカまで行って参加する気にはならないなあ。 欲しがっている人から見たら「なんてもったいない」と感じるのかもしれないけれど。
格闘ゲーム。 えーと、キリスト教国ではこんなものも登場するのでしょうか。
ま、確かに、以前、アメリカのおもちゃ屋で モーセやらイエス・キリストやらのアクションフィギュアを 見た時にはちょっと感動した。
その時、隣にあったのはフロイトのフィギュアだった。誰が買うのよ...。
SIerの老舗CECがOSSの「新たなビジネスモデル」を模索中、という話。
あくまでも「模索中」であるせいか、 全然目新しさがない。商用ソフトとOSSを適材適所で組み合わせる という発想も、新しいどころかむしろ古臭い印象を与える。
日本で、大手SIerさえもOSSを無視できない、という点は やや話題性があると考えられないこともないが、 2007年の話題でもないよなあ。
もう一歩、新規性のある話題を期待したい。
Ruby on SolarisでDTraceが使えるようになったという話。
噂によるとTwitterのパフォーマンス危機の際には、 (サーバがSolarisだったので)DTrace for Rubyが活躍した、ということだ。
プロファイリングはパフォーマンス改善の基本なので、 優れたプロファイルが提供されることはとてもありがたいことだ。 問題は手元にSolarisがないことだな。
会社にはSolarisサーバが一台あるけど。
AACS LAがBlu-ray Diskのキー(09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0)*1を 載せているサイトに削除するように要請した、という事件から あちこちで祭りが起きているのだが、 AACS LAが128bitキーの「所有権」を主張できるのあれば、 私も同様に主張できるはず というのが、リンク先のエントリ。
このページを見に行くと、あなたのための128bitを用意してくれる。 ちなみに私の128bitは
A8 91 34 24 E1 7D 66 DD 5D 70 94 A5 D4 45 EA CF
であった。
*1 これを載せたので私のところにも通告が来るのかな
パートナーであるJavaへの別れの言葉。「さよならJava」
もう10年、一緒にやってきたけど、もうダメだと思う。 君が悪いってわけじゃない、いや、やっぱり君が原因かな。 僕はもっと若くてかわいい人に出会ってしまった。 そう、君の妹、C#さ。
言いにくいんだけど、君は整形手術が必要だと思う。
そもそもAWTの始め頃になにかが間違ってしまっていた。 Swingでそれはさらに悪くなった。
君はわかってない。ユーザインタフェースフレームワークの目的は 開発者が優れたユーザエクスペリエンスを構築するためのものなんだ。 それなのに君は美しいAPIやプラットフォーム中立性、 それにマイクロソフトを排除することばかり考えてた。
(後略)
JavaOneでのTim Brayへのインタビュー。
注目すべき点
サン・マイクロシステムズでWebテクノロジー関連のディレクターを務めるティム・ブレイ（Tim Bray）氏は、近い将来にプログラマが直面する問題は、CPUのコア数が増えてハードウェアの並列化が進むのに対して、現在使われている言語の多くで並列プログラミングのサポートが十分でないことだという。
ブレイ氏は、こうした問題に対して2つの方向性で解決を模索しているという。1つはグーグルが作った分散処理のフレームワークで「MapReduce」と呼ばれているもので、数万個のCPUで膨大なデータ処理をするといったときに有効だ。すでに、MapReduceをJavaで実装した「Hadoop」（ハドゥープ）というものがあるという。
「Hadoopは外部ライブラリですが、Java言語自体で並列処理をサポートすることも必要」（ブレイ氏）といい、そのモデルとして2年ほど前から“Erlang”（アーラン）に注目しているという。「Erlangはエリクソンが開発した古い言語ですが、とても興味深い特徴を持っています。きわめて効率的にプログラムの並列化ができ、ふつうのAMDやインテルのCPUを使って25万スレッドを動かすこともできます。ただErlangはオブジェクト指向言語ではなく、関数型言語です。つまり、一般的な言語になじんだ、ほとんどのプログラマには奇異に感じられるので、われわれとしてはErlangが持っているいいところを、もっと身近なRubyやJava に入れていこうと考えています」。Java上で動くRubyの実装であるJRubyが、本家Rubyより先にこうした並列処理サポートを取り込む可能性もあるという。
関数型言語は、一般的な言語とコードの書き方が大きく異なるものの、いずれJavaに関数型プログラミングの要素を入れていくことも必要だとブレイ氏は語る。「関数型プログラミングは、並列プログラミングに適しているばかりでなく、テストもやりやすいのです」。関数型プログラミングに対して感じる違和感について、「かつて、オブジェクト指向プログラミングは難しすぎて一般プログラマには習得できないといわれていましたが、今では当たり前のように使われていますよね。関数型プログラミングについても同様かもしれません」と楽観的な見方もあると指摘する。
マルチコア上でのスケーラビリティが将来のキーとなる点、 関数型プログラミングの要素(って、どこまで考えてるんだろう)が 有効である点においては同じところを見ているような気がする。
しかし、
Java上で動くRubyの実装であるJRubyが、本家Rubyより先にこうした並列処理サポートを取り込む可能性もあるという。
ってのはどういうことよ。負けてはいられないなあ。
Sunがオープンソース開発者に報酬を与えるというような話。 「お金だけが動機ではない」というごく普通の「オープンソース開発者」のコメントが続いている。
詳細がわからないので、これ以上コメントするのは難しいが、 Sunがちゃんとしたプログラムを用意して、 オープンソース開発者がなんらかの報酬を得られる新しいチャネルができるというのであれば それはそれで歓迎すべきことである。
たとえ、それによって恩恵を受ける開発者が いわゆる「オープンソース開発者」全体からいえばごくわずかであるとしても。 当然ながら。
本当は日曜日が〆切だった。あせあせ。
今回のテーマは「APLとJ」。 APLはプログラムが、「読めない」、「書けない」、「表示できない」の三拍子なので、 簡単に触れるだけで、実際のサンプルは簡単なJで。
とはいえ、考えてみるとAPLってのは40年前にMapReduceを実現してるんだよなあ。 もちろん分散じゃないけど。
Python 3000のGiant Interpreter Lockについて尋ねられた時のGuidoの反応。
threadでパフォーマンスが伸びるなんて幻想だ。 スケーラビリティが欲しければプロセスを作るべきだ、とのこと。 彼がthread否定派だとは知らなかった。
しかしねえ、実際問題として考えるにRubyやCPythonのようなインタプリタ系実装では 変数やメソッド呼び出しひとつひとつのレベルで排他制御が必要になるので、 細粒度ロックはコストが高くなりすぎて、パフォーマンスは得られないような気がするし、 この件についてはGuidoの意見に賛成だな。
YARVはnative threadを使ってるけど、 (少なくとも現時点では)最大のメリットは、 パフォーマンスではなくて、native threadを使ってるライブラリと共存できることだと思う。
でも、それだと使い勝手が悪そうなのでfiberみたいのが欲しいんだけど...。 継続でもよい(これがあれば自前でfiber作れるから)。
JavaOneで発表された「Java系」リッチクライアント向け言語。 なんていうか、JavaScript＋Java＋αみたいな。
また新しい言語をつく欄でもいいだろうという気もするんだけど。 まだ仕様を詳しく見てないんだけど、JavaScriptの変態なオブジェクトモデルとは 一線を画してるんだろうか。
なんていうか、PythonっぽいLisp。a.fooとかa[5]とか。
っていうか、そこまでするならPythonでいいやん。 もうS式じゃないし。 構文木が取り出せればそれでいいんじゃないの？
ThoughtWorksがMingleという JRubyで動く「Agile IT project management application」を発表したという話。
Ora Biniが入社したと思ったら、すぐにこれだ。 動きが速い。
ちょっと危機感(最近、こればっかり)。
HoboってのはRailsの拡張にあたるもの。
ちょっと面白そう。Railsの大量にあるHelperとどう違うのかは、まだ確かめてない。
会社から早く帰って、Skypeをセットアップ。 ちょっととまどったが、無事ログイン。接続。 テスト完了。
家族と夕食を食べた後、19:30から本番。
で、議論でマクロの話になって、弾さんにふられて 「文法の意味が揺らぐのが嫌」とか話してたら、 しばらくしたら、突然、映像と音声が止まってしまった。 Skype Chatは通じるけど。
言いかけてたこと
で、無線LANがいけないかと、有線を引いたり、 ルータをバイパスしたりと、いろいろやってみたが、 結局、復旧しなかった。残念。
どうもSkypeはうまくいったためしがないので、 今後、なんかのイベントでSkypeを使うという話が出たら、 素直に断ることにしよう。
まだ、ネットはプレゼンテーションには使えないわ。 私の機材の関係かもしれないけど。
で、レポートたち。
長野県松本市でプレゼンする。 「国産技術」などと言われると恥ずかしい気もするが、 まあ、あまり気にしないことにする。
家族にこの話をした時に、家族全員が「松本のキーホルダーを買ってきて」とのことであった。
わかりました。
Charles Nutterのインタビュー。 YARVより速いとか言ってるよ。
処理速度のチューニングも進んでいる。JRubyは高速実行を目指したYARVと、「ほぼ同等か、テスト項目によってはやや遅い程度の速度」（エネボー氏）といい、本家のRubyよりは確実に速いとしている。
ふむ。でも、たしか、JRubyって1.8.6よりちょっと速いくらいじゃなかったっけ。 プリコンパイルしたのかな。
昨日、Skypeビデオで苦労したので、Ekigaも試してみようかなあ。 とりあえず、ビデオテストで自分の顔が見えるところまではできた。
ノーブランドのカメラはあっさり動いたが、 ElecomのカメラはLinuxでは使えないみたい。
弊社でも採用基準には悩んでいるのであった。 参考にしたい。
「PHPは言語としてはダメだが、どこにでもあるし、知見も蓄積されていることがキラーだ」 という話。納得できる。
前にも書いたが、システム構築における言語の比重ってのは高くないんだよね。 言語デザイナーとしては残念な話だけど。
「素晴らしいデザイン」はあまりにも簡単に見えるので、 あたかも労なくして作られたように見なされてしまう、という皮肉。
The Elegance Paradox is this: to create elegance requires entirely inelegant preparation, but nobody should be able to see that.
確かに「自然なデザイン」というのは難しいものだ。 ほとんどの場合、「自然」は未定義語だから、 「感性」、「本能」、「勘」などを頼りに試行錯誤を繰り返す必要がある。 その苦労は他の人には見えないんだよね。
職人魂。ちょっと方向性を間違っちゃった、かな。
Apache LicenseとGPLの非互換性なんてのは、別に思想の違いや対立があるわけでなく、 たんなる(法律)技術上の問題だったわけだから、これが解決するというのは非常に 望ましいことだと思う。
コミュニティの原動力は「好き」とか「楽しい」であることの再確認。
それはそうと、コミュニティごとになんとなく性格が違うのが面白い。 まあ、(日本での)Rubyのようなコミュニティのように「言語好きが集まりやすい」というのは 理解しやすいが、DebianとGentooとUbuntuの性格の違いはなにによって決定されるのだろうか。
JSR 292に関して、JVM上の各種動的言語の実装に関して。
単に一言で「動的言語」と呼んでもそれぞれ事情が違うのが興味深い。 しかし、考えるにJVMの都合なんかまったく考えてないRubyの仕様が一番凶悪だな。
「XMLは人間が読むものではない」、「DSLの台頭によって(Java界における)XMLの地位は下がりつづけている」という話。
ビルドツールとしてMavenの変わりにBuilderやSCons、 コンフィギュアファイルとしてJava Configuration, JRuby, Groovyなどが使われ始めている。
最後にSICPからの引用。
Programs must be written for people to read, and only incidentally for machines to execute.
ふたつのRuby - Erlangブリッジ。
前者(Rebar)の方がシンプルだが、実際に使う時には後者(Erlectricity)の方が可能性が高そうだ。 いずれにしてもまだproof-of-conceptレベルだけど。
こうやって、各種ツールを組み合わせて、性能や生産性を実現する試みが 次々と現れる様は、未来への可能性を感じさせる。
長女、次女の中学校の授業参観。
中三は進路についてのオリエンテーションの参観であった。 推薦とか内申とか入試との比率とか。 島根県はまた制度が違うように思える。
っていうか、私の中学時代には こんなに情報が開示されていなかったような気がする。 内申なんてまったく気にしてなかったものなあ。
AJAXによるズームインタフェースのUnicode文字の一覧。
あまり調べものには向かないが、 「Unicodeってこんなに文字があるんだ」ということを 肌で感じることはできる。
ThoughtWorksに行ったJRuby開発者、Ola BiniによるJavaOneレポート。 結構、手厳しい。
リンク先は最終日のものだが、他の日もなかなか面白い。
高階関数を持つ言語(OCaml)のライブラリを精査したところ、
So among 2239 functions defined in OCaml standard library (and whatever libraries I have installed), 87.2% take no blocks, 12.1% take one block, and 0.7% take two or more blocks.
2239関数のうち、関数引数を取らないものが87.2%、 ひとつだけ取るものが12.1%で、ふたつ以上とるものは0.7%であった。
ここからわかることは、プログラミング言語は 99.3%を占める高階関数(ブロック)を0または1個とるものに最適化するべきであり、 めったにない二つ以上ブロックのために、それ以外のものを「ゆがめて」はいけない、 ということ。
Rubyの文法はまさにこの最適化が行われており、 設計時の私の「勘」が、実証された形になっているのがうれしい。
longjmpのコストはそんなに高くない、という話。
改めて考えて見るとsetjmp/longjmpがやってることは、 いくつかのレジスタをコピーするだけなのでそんなに重いわけではない。 (matzrubyを含めて)setjmp/longjmpを多用する処理系が重いのは、 安易に再帰に頼っているからであってsetjmp/longjmpのせいではない。
via retrospections: Andre's Weblog - Blog
「Threadはダメ」という論文。 面白いのは「(ある程度以上複雑な)Threadプログラムは人間に理解できない」という一方で、 「Erlangのような並列性を組み込んだ言語が今後主流にならないだろう」という主張。
Alternatives that replace these languages with entirely new syntax, such as Erlang or Ada, have not taken root, and probably will not. Even languages with minor syntactic modications to established languages, like Split-C or Cilk, remain esoteric.
The message is clear. We should not replace established languages. ...
I believe that the right answer is coordination languages. Coordination languages do introduce new syntax, but that syntax serves purposes that are orthogonal to those of established programming languages.
つまり、「主流の言語(established languages)」には手を入れず、 それらで記述されたタスクを組み合わせる「協調言語(coordination languages)」が 主流になるのではないかという予測。
が、その協調言語が(たとえばRubyで書かれた)DSLだったらどういうことになるだろうか。
今日の聖餐会は母の日特集であった。
いろいろな人が母に関する思い出や経験を語ってくれた。 母の愛は偉大だ(そうだ)。
うちも両方の母に小さな贈り物をした。
次女はお菓子を作って妻に感謝の気持ちをあらわしていた。
ふーん、飲み込まれちゃうんだってさ。
しかし、バックにサンというブランドを得て、性能や普遍性で勝るJRubyが、Rubyワールドのヘゲモニーをいつの間にか奪ってしまう可能性も否定できない。現在、JRubyはRuby1.8と互換性を持っているが、Ruby1.8から大きな変更が加わるRuby1.9が登場するころに、もし万が一、 JRubyユーザーの多くが、そうした変更を嫌ったら、どうなるだろうか？ Rubyが、いくつかの“Rubies”にフォークしてしまわないだろうか。ちょうど、BSDがFreeBSD、NetBSD、OpenBSDと分かれたように。
まつもと氏を中心としたRubyコミュニティは、今後どういう体制を整えていくのか。あるいは緩やかで暗黙的な連帯だけで開発を続けていくのか。それは、今後Rubyの受容がどこまで進むのかにも関わってくる問題で、今は誰にも予想ができないことなのだろう。
っていうか、「Javaのやり方」から見てるからそう感じるのかもしれないけど、 フリーソフトウェアの歴史を見てると、「Javaのやり方」の方が特殊だし。
Java界におけるRubyの存在意義のひとつは「Alternativeの提示」だと思う。 Javaの世界の当たり前が、外の世界では必ずしも当たり前でないことを示してきた。 Rubyだけがそうしてきたわけじゃないけど。
つまり、
で、フォークだけど、「したければしたらいい」というのが私のスタンス。 少なくとも現時点では「フォークしたくない(ので調整したい)」と思ってるのはJRuby側だから。 言っとくけど。
これこれ。ながらく「育てて」きた.bashrcがあると、 zshに移行するのも面倒だと思ってきたが、ヒストリの共有だけはうらやましいと思っていたので これはありがたい。
後、ワイルドカード展開もうらやましいかなあ。
「なら、さっさとzshに移行すればいいのに」と言われそう。
「静的型情報がないとヒントが少なくてコードを読み解くのが難しいんじゃない」という疑問に対する反応。結論は、「人間にとっては(多くの場合)そんなことはないんじゃない？」というもの。
Structs+Springの以下のコードと
public ActionForward edit(ActionMapping mapping, ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
PersonForm personForm = (PersonForm) form;
if (personForm.getId() != null) {
PersonManager mgr = (PersonManager) getBean("personManager");
Person person = mgr.getPerson(personForm.getId());
personForm = (PersonForm) convert(person);
updateFormBean(mapping, request, personForm);
}
return mapping.findForward("edit");
}
Rails (ActiveRecord)の以下のコードを比べてみる。
def edit @person = Person.find(params[:id]) end
で、読みやすさは言語(の文法)によるものではなく、 プログラマによるものである、という結論。
もちろん、Java文法でも上の例題よりも読みやすいコードが書けるAPIは可能だろう。 要はモチベーションの問題か。
来週のRailsConfで正式発表だとか。
日本での発表は6月5日のCodeGearイベントにて。 私もゲスト出演することになった。事前打ち合わせ、何にもしてないんだけど。
Ruby on Railsのコマーシャルアニメ。
キーワードは「Don't Repeat Yourself」という部分をわざわざ「リピート」したり、 「Web development that doesn't hurt」のところで「痛い」目にあったりする皮肉が笑える。
Appleのコマーシャル(日本だとラーメンズがやってるやつ)のパロディ。 明日のプレゼンではこれを使わせてもらおう。
続編もある。
なぜBugzillaがバージョン2.0から3.0まで9年もかかったか。
まったく新規開発を行おうとした(元祖)3.0は頓挫し、 段階的に進歩を続けてきた2.x系が3.0が目標としていた機能の全てを実現して 改めて3.0としてリリースされたという話。
プロジェクトが長い歴史を持つようになり、 コードが複雑になってくると、新規蒔き直しをしたくなるのは世の常だが、 そういう試みはたいていうまくいかない。 段階的な進歩こそ進むべき道だ、とJoel Spolskyも言っていた、確か。
いや、私もRubyで同じことをしたので、よーくわかる。
最近話題のSpelling Correctorを(JVMベースの関数型言語)Scalaで。
これを見る限りでは、あまり魅力的には感じられない。 ま、単純な置き換えではScalaの魅力は発揮できないのかもしれない。
話題のActorも使ってないし。
東京へ。某外資系企業が社内技術リーダーシップカンファレンスの講師として呼んでくれたからだ。
実は昨日、愛用のThinkpad X31が不調で電源が入らなかったり*1したので、どうなることかと思ったのだが、 人類が数千年前から愛用してきた情報機器(紙とペン)を活用することでなんとかなりそうだ。
羽田から会場までハイヤーが手配されていた。さすがリッチだ。
で、結果からいうと講演は成功だったと思う。 発表内容は英語だったのだが、昨日紹介したRailsビデオも含めて おおむね好評だったようだ。こういう場に呼ばれるということ自体が、 Rubyがメジャー化した証拠だよね。
講演終了後、いろいろと情報交換(雑談とも言う)をした後、 再び羽田までハイヤー。松江に帰る。
*1 Fan Errorだそうだ。検索するとわりと珍しくない症状らしい。今回はファンの掃除でなんとかしのいだ
で、メジャー化するとこういう話も来るわけだ。
XPの実践やオブジェクト倶楽部の運営で知られる永和システムと業務提携という話が 発表された。永和さんはうちよりずっと規模が大きいのにこうやって話を持ちかけてもらえるというのがありがたいことだ。
NRIがオープンソースの救急サービスを開始、という話。
自分が提供したプラットフォーム限定で問題解決を支援するサービス(SpikeSourceとか)は あるが、そのような制約の一切ない状況での救急サービスは珍しいのではないか。 一回９９万円という値段が高いか安いか判断するのは難しいが、 「気軽に助けを呼べる」というのは安心感を呼ぶし、 こういうサービスが存在しているということそのものが、 保守的な層にオープンソースを受け入れてもらうために有効なのかもしれない。
このサービスのメニューにはRuby on Railsも含まれている。 なぜか「スクリプト系」ではなく「Java系」に分類されているけど。
なんとなく、Rails系の対応を行う人の顔はよく知ってるような気がする(ほのめかし)。
Rubyでも書けるぞ、という話。 「だからどうした」と言われそうな気もするけど。
しばらく前にオープンソースマガジンに書いた記事が、また公開された。 今回はハッカーと仕事。
この中で、
この会社はハッカーの扱い方を心得ていて、居心地の良い職場環境を提供してくれています。
という部分に某所でツッコミが入った。要するに「居心地が良い」のは、 まつもとの立場が特別だからで、NaClに入れば天国というわけではないということ。 めちゃめちゃ給料が高いわけでもないし、 仕事の負荷が低いわけでもないし。
私は「フェロー」という立場だし、 私の給料は他の皆さんが稼いでくださっているからこそ払われているわけだから、 ま、ご指摘の通りである。書いた時点では、まさかそういう風に捉えられるとは 想定してなかった。私の想像力の足りなさである。
「良い環境」というのは、「青い鳥」のようなもので「どこかにある」し、 「意外に身近なところにある」というのが言いたかったんだけどなあ。 良い環境は口を空けて待ってるんじゃなくて、 自分で構築していくものだと思う。
タイムラインに続く「NiftyサービスRuby on Railsシリーズ」第二弾。 ま、ユーザにとってはRailsで構築されてようがなんだろうか関係ないんだけど、 プレスってのは、イメージだから、ほら。
今度はプロフィールを扱うサービス。Nifty色を薄めるためか、 Niftyという文字は目立たないようになっている。
プロトタイプは増井雄一郎さん(masuidrive)さん、 実装はNaClをはじめ、複数の企業からの技術者の協力で、実現された。 お疲れ様でした。
かずひこくんの転職記。 いや、たいしたものだ。
私の語学力(英語)は日本人の平均以上だと思うんだけど、 それでも
「語学力が弱い」というだけの理由で自分の可能性を狭めるのは本当にもったいない
というのは頭では理解できても、実際に海外に転職するところまで踏み切れない*1。 彼の勇気ある行動には脱帽する。
*1 誘われたこともないけど
ついこの間発表されたDLR(Dynamic Language Runtime)が、 もうMonoで動くようになったという話。
なんと16日で移植完了だとか。 正直、もっとずっと時間がかかると思っていたので、(うれしい)意外であった。
Mono、やるじゃん。
弾さんによるErlang評価。 「文法が変だが面白い」。
同意である。もうちょっと「普通」の文法にしたらどうかなあ、と私も思う。 もっともErlangの文法はPrologの影響を受けてるらしいので、 今さら変えるのは難しいのかもしれない。
あと、向井さんからのフォローアップが「dankogai の Erlang 評に一言いうことにする - val it : α → α = fun」にある。
実際に「普通の人」の手に届くのはErlangではなく、 その次の世代の言語じゃないかなあ。
ポルトガル語でRailsの本を書いているFabio AkitaがRailsのコンサルタントである Surgeworksに就職した、という話。
これだけだと、別に珍しい話でもなんでもないが、注目したいのは
国を越えた在宅勤務(特にRubyをベースにしたもの)が、 現実的になってきているということである。
もっとも、以前からDHHはデンマークにいて37signalsのために 働いていたり(今はシカゴに引っ越したけど)、アメリカベースの企業では 別に珍しいことではないのかもしれない。
出た*1。
今回はややコンパクト。 私の担当は「APLとJ」。 ま、改めて勉強するに
ということで、APLが読めないのは必ずしもギリシャ文字のせいではないことが はっきりした。って、そういう記事なのか。
*1 って、実際に書いてるのは24日だから遅すぎるけど
Ruby on RailsでできているMyITproの実装の話。
こういう話はたいてい表で語られることはないし、 たまに話されても、あまり上手なプレゼンではなかったりするのだが、 これに関しては書き手が記者の人であるだけあって 特殊な内容というわけではないが、読み応えがある。
面白かった。
Andy Tanenbaum教授はあいかわらずマイクロカーネルの信奉者だけど、 世の中はその方向に進んでないよね、あんまり(最近の状況を)学んでないんじゃない、という話。
この指摘の真偽はともかく、 確かに世の中の動きの方向はなかなか予想できないから、 過去の成果によっていると置いてきぼりにされちゃう危険性はいつもあるよね。 「過去の栄光」がある人ほど危ない。
言語分野でも
などという「予想外」が発生してるし。これからも予想は裏切られるに違いない。
しまねオープンソース協議会月例のオープンソースサロン。
今回はサン・マイクロシステムから技術者の藤槻 泰宏さんをお呼びして、 Project LookingGlassについて。
正直、「ビジュアル系」にはあまり強くないのだが、 これは面白いと思った。 「APIも簡単」ということだったので、興味深かったのだが、 Javaなんだよねえ(苦手)。
いずれにしても見かけのインパクトがあることは重要である。 10年以上鳴かず飛ばずだったRubyは、やはりデモで華がない。 あれはダメだよね。いくらなんでも「Hello World」じゃ。
それに比べて、Ruby発展の起爆剤になったRailsのデモのインパクトのあること。 「15分でWebアプリケーションをゼロから作ります」とか。 マーケティングの極意はやはり「見せて理解してもらうこと」にあると感じた。
その後、懇親会。「ひらメソッド」のひらさんと 隣の席で、いろいろ面白い話が聞けた。マルチコア時代の新しいOSについて、とか。 そういうOSができたら、ぜひそこでRubyが効率良く動くようなことを考えたい。
RailsConfの情報がブログに載り出した。 リンク先はDHHのキーノートのレポート。
楽しそうだなあ。でも、1500人超のカンファレンスなんて想像できないんだけど。 いや、OSCONはそれ以上の規模だったけど(会場も同じだし)、 単一テクノロジーのカンファレンスじゃなかったし。
今年のRubyConfも規模が大きくなっちゃうのかなあ。
Bruce TateによるRailsケーススタディ。
『JavaからRubyへ』と同様に、冷静かつ公正な態度は好もしい。 その上でRuby(やRails)を選んでくれるというのだから、これ以上はないだろう。
先日の「LazyListの機能を(Rubyの)Arrayに追加したい」というエントリへの 弾さんのコメント。
まあ、自分でも「このアイディア、サイコー」と思ってるわけではないので、 批判やら指摘やらは歓迎するのだが、 それでも、ListはArrayではない、というのは適切な「読み」ではない、と思う。
というのも、私が欲しいと思った「LazyListの機能」は「Laziness」であって 「Listであること(List-ness?)」ではないからである。 だから、LazyListの機能を追加したArrayは「ListでありArrayでもある」という キメラのようなものではなく、LazyArrayである。
「長さが決まってないArrayがありえるのか」というツッコミもあるだろう。 が、queueやらstackやらとしての機能までも備える「大クラス主義」のRubyのArrayである。 ある時点でサイズが決まっていないなど些細なことではないだろうか。 アクセスがO(1)である点も、「値が確定している範囲内ではO(1)」で十分だと考える。
ついでにいうと、Perlの「リスト」はプログラミング言語の観点からみると 相当に「変態的」なので、これと比べてもらっても困る。 Perlのリストって値のような値でないようなものだし。 少なくともPerlにおける「一級市民」ではない。
リストと配列の両方を持つ言語といえば、Lispがあって、 こっちを引き合いに出されるのであれば、ずっと良かったと思う。
でもねえ、本当に扱いたいのは「オブジェクトの列」にすぎないんだから、 コンピュータが十分に賢くて、リストだの配列だのと考えることなく、 適当に高速に動いてくれるのが一番いいんだけどねえ。 リストだのタプルだの配列だの使い分けるのは面倒だ。
集会終了後、岡山へ。
行きはとにかく眠かった。 事故せずに着いて本当によかった。
で、いろいろと興味深い話が聞けた。 次世代の育成とか、人の話を聞くとか。
自分ができてないところだけに耳が痛いこともあった。
うちに帰ったらすっかり遅くなってた。
我々の親の世代と我々とではずいぶん社会環境が違う。 たとえば私の父親はソフトウェアエンジニアになることを想像もしなかっただろう。
とすると、私の息子が就職するようになった時、 その環境はまた私とは違うだろう。 っていうか、今「我々」とまとめてしまったが、 「Matzにっき」の読者間でさえ、かなりのズレがあることだろう。
となると、年寄りの世代が若い世代にどのようなアドバイスができるだろうか。 Kathy Sierraは
を挙げている。私ならなにを伝えるかな。
くらいかな。自分でできてないことも多いけど。 あと、最後のがストレートに「数学」と書けないところが情けない。
本当に世界を変えることについて。 英語だがぜひ読んでほしい。
そして世界を変えるために自分になにができるかを数分間考えてみよう。 私になにができるかな。
Tiobe Indexでここ2ヶ月Rubyの順位が下がっている件について。
まあ、そういうこともあるだろう。 RailsConfとかの開催でまた盛り返すんじゃないかな。 ま、自然なブレの範囲内だと思う。 一喜一憂するのもどうかと。
(じゃあ、このエントリを取り上げなくてもよかったんじゃ)
LispWorksやAllegro Common Lispを買うと フリー(無償)のCommon Lisp処理系にはない、どんな付加価値があるのか、という話。
有償の言語処理系を売るビジネスは絶滅寸前だと思ってたけど、 Common Lisp界ではまだ生きていけるらしい。それでも2社だけど。 頑張ってるなあ。
ErlangメーリングリストにおけるJoe Armstrongのポスト。 Erlangの文法的改善について。
正直、彼の文法デザインのセンスは私とはだいぶ異なるものの、 少なくとも1989年誕生の言語の文法をさらに改善しようとするほどに 熱意を維持し、開発を継続している態度は尊敬に値する。
ThoughtWorksがRubyWorks(エンタープライズRuby向けThoughtWorks版パッケージの名称、らしい)と JRubyの24/7サポートサービスを提供する、という話。
24/7というのは、日本語だと「24時間365日」のこと。 すげーっ。ThoughtWorksは本気だ。いや、今まで信じてなかったわけじゃないけど。
Larry Wallがなぜ文末のセミコロンにこだわって RubyやPythonのように行末では省略可能にしないのか、その理由。
(ただし、ブロック末尾ではセミコロンを省略できる)
ま、わからないでもない。
が、最後二つはあまり良い理由ではないと思う。 これらは静的型言語が好きな人からもよく聞く「理由」だが、 実際には、人間にとってのやさしさとコンピュータにとってのやさしさは 相当異なっているのに、その点を無視して「やさしさ」という単語で ひとくくりにして同一視しちゃうのは問題だと思う。
処理が早く終了することと、生産性はまったく直結しない、という話。
30分かかっていた処理が30秒で済むようになったらすごいことだろう。 でも、本当に？ それは30分付きっきりでなければならない仕事なのか それともほったらかして30分別のことをしてればよい仕事なのかによるだろう。 もし、後者だったら処理速度を60倍にするメリットはあまりないかもしれない。
あるいは同じ60倍の高速化でも30秒かかっていた仕事を0.5秒で終わらせるようにする のはどうだろう。その高速化はコストに見合うのか。
子供に最初にプログラムさせるという話になると、 まずテーマに選ばれるのは、キャラクタを動かす、図形を描く、そして、ゲームくらいだろう。 しかし、それは適切ではないかも、という話。
Hackety Hackでは、ゲーム以外の手段でプログラムを学ぶ。 それはゲームのプログラミングは難し過ぎるから(_whyによれば)。
確かにそうかもしれない。私でもゲーム(でも難しいからBASICの頃の古典的キャラクタゲーム)を 題材に選びそうだものな。
弾さんによる 「Matzさんでさえ言及した様子がない」新言語Xtalの紹介。
うーむ、実はこっそりブログでの開発状況を観察し 密かに愛でていたのに。
個人的な経験から言えば、言語仕様がある程度安定するまでは 人の意見を聞かず、自分が「これ」と思うところを追求した方が 最終的に良い物ができる可能性が高まると思っているので(独り善がりになる危険性も高まるんだけど)、あまり人に知られない方が良いんじゃないかなあ、と思っていたのだ。
が、弾さんのところみたいな大手からリンクされたんじゃ もう隠しておく意味はなくなったな。
個人的にはXtalは
など面白いところがたくさんあると思う。
でも、メジャーになるには冒険しすぎかもしれないと思ってしまうのは 私が年を取って安定指向になってきたせいかしら？
いや、別にメジャーにならなくても全然問題ないんだろうけどね。
最悪のケースを想定することでより良い見積もりが出せる、という話。
まあ、単純に「見積もって」と言われたら、 こんな作業が必要そうだから、と思いついたものを積み上げて見積もるわけだが、 ソフトウェアの場合、「必要そうな作業」は恐らく本当に必要な作業のごく一部に過ぎない。 「最悪のケースを想定して」と言われると 最悪のケースを想定するためにいろいろな状況を考慮する必要があるわけで、 より多くの状況を考慮することでより正確な見積もりが出せるということなのだろう。
考えてみれば当然のことだが、見積もりは悲観的に。
個人的には、(〆切のある)仕事でソフトウェア開発の見積もりを行う時には、 普通に(特に悲観的でなく)見積もった時間に1.5から2.5までの係数を掛けることにしている。 最初はかなり罪悪感があったが、最終的にはいつもちょうどいいか、ほんのちょっと余るくらいで 収まるので、こんなものかな、と思っている。
この方法を実践するまでは、いつも見積もりばかり甘くていつも火の車だった。 健康を壊しかねない。
Railsに関するGeek Sessions。 今回のテーマはスケーラビリティ。
レポートを読むだけでも面白そうなネタが満載であることがわかる。 こういう交流も重要なんだろうなあ。
もうちょっと詳しいレポートは「geekSessions I: Ruby on Rails: To Scale or Not to Scale」に。
JRuby 1.0に向けて最終バグのリスト。
もう近いな。そういえばRubyKaigiには間に合わせると言ってたな。 この調子なら間に合うんじゃないだろうか。
YAHOOの面接試験問題。
正直、言語そのものがどうかと感じるので、こんな問題解かされるような羽目には 陥りたくはないが、 NaClでも技術者選別に悩んでいるという事実がある以上、 もしかすると入社希望者には似たような(Ruby対象の)問題を出す必要が 将来出て来るのかもしれない。
私が以前に語った「一部の技術者は深く「潜って」いき、最終的にはハードウェアか、OSか、言語に行き着く」という言葉から。
ハードウェアに向かう人というのは、土台になってる物質や物理法則が世界の根本だと感じてる人。
OSに向かう人は、世界を制度や仕組みが動かしてると思ってる人。
で、言語に向かう人は、世界を主に人と人とのコミュニケーションで捉えてる。
一般論として言えるかどうかはわからないけど、 これは非常に面白い捉え方だと思う。
なんかMVCのような雰囲気でコンソールアプリが作れるフレームワーク。
見かけは面白いけど、本当に実用になるのかな。 ちゃんと使ってみないことには判断できないな。
Rubyのスレッド対応の未来について。
「継続ないじゃん」ということも書いてあるのだが、 ちょうどその日にささだくんが継続をサポートしてたりするところが笑える。
っていうか、継続サポート、マジですか？
やるなあ。
募集開始。今年はどんなのが来るのかなあ。楽しみだなあ。
受け入れ側としても、昨年以上に応募者にも楽しんでもらえるような企画をしたいな、 と話している。ソフトウェア開発(特に楽しい部分)が伝わるような「なにか」ができるといいな。
小迫さんにとって不快なことをしてしまったようだ。
先日私はRuby 1.9に鬼車5.7.0をマージした。 これは別に企むところがあったわけではなくて、 5.xでしか提供されてない機能が欲しくなったのと、 今後実装するM17N機能の実装に5.xのAPIの方が都合が良かったから(UTF-16も処理できるし)。
で、この場合、Rubyは単なる鬼車の利用者なので、 鬼車のライセンスはBSDライクだし、利用する前に 相談するとか許諾を求めるとかは考えてなかった。
で、今後、Rubyの都合で鬼車本体に手を入れてもらう方が (我々にとって)都合が良いようなことがあったら、 その時点で相談しようと思っていたのだった。
だから決して「拒否のメールを受けることが僅かでも損になると思った」などということはない。小迫さんが我々の都合に合わせたくなければ(そして、そう思われるなら、それはもっともな拒否だと思う)、我々の方で勝手に追随するまでのことだから。
不快な思いをされたのであれば、その点については謝罪したい。
とはいえ、
これから私にできることは何もありませんので、今後何も起こりません。従って、この件について私にメール、コメント等を送らないでください。返事をしませんので。
ということなので、取りつく島はないのかも。
JRubyチームに引き続き、Eval PhoenixもRubiniusの開発のために雇用された(半分だけど)、という話。
Rubyがいろいろな人の生活を変えていくのは、驚きである。 ちょっと恐い気もする。
Rubyを使ったウィルス、なのかな。危険度は低いらしい。
っていうか、Windowsで/usr/local/binとかあるのってどういう状況？ Cygwin?
RubyスレッドでMapReduceを実現した話。 あまりRubyのスレッドをいじめないでください。
Ruby 1.8までのスレッドはスタックを毎回まるごとコピーしているので コンテキストスイッチのコストがめちゃめちゃ高い。 「動く」とか「使える」とかは言えるけど、間違っても「性能が良くなる」なんてことは言えない。
でも、1.9(YARV)で落ちるってのはなんでだろう？ ネーティブスレッドのスタック領域を使いきったかな？
ActorをRubyで実現するライブラリ。 ActorってのはScala風なんだろうか。まだ調べてないけど。
利用例はこんな感じになる。
require 'concurrent/actors'
include Concurrent::Actors
RequestGreeting = Struct.new :reply_to
Greeting = Struct.new :value
# spawning a new actor
oracle = Actor.spawn do
greeting = "Hello"
loop do
# guarded receive (does case-like matching via #===)
Actor.receive do |f|
f.when Greeting do |m|
greeting = m.value.dup.freeze
end
# callback part 1
f.when RequestGreeting do |m|
m.reply_to << Greeting[greeting]
end
end
end
end
# sending a message to an actor
oracle << Greeting["Howdy"]
# getting a reference to the current actor
current = Actor.current
# callback part 2
oracle << RequestGreeting[current]
Actor.receive do |f|
f.when Greeting do |m|
puts "#{ m.value }, Bill!"
end
end
結構、気持ちのいいAPIである。性能はどうだろう。 現時点ではあんまり期待できないかな。将来に期待か。
作業中。とりあえずstring.cは終わった。
Javaでは
new Date(new Date().getTime() - 20 * 60 * 1000);
とかくものが、Ruby (with ActiveSupport) では
20.minutes.ago
と書ける。簡潔でよろしい。では、C#ではどうするか。 C# 3.0なら、既存のクラスにextentionという形でメソッドが追加できるので、 オープンクラスのようなことができ、結果として
20.Minutes().Ago();
と書ける。括弧が省略できないので惜しいな。
いろいろなレベルのPythonプログラマによる階乗プログラム。
っていうか、個人的には英語で運営されている4chan.orgが まるっきり2ちゃんねるなところの方が驚いた。
ちなみにRubyなら、こんな感じ(1.9限定)。
1.upto(6).inject(:*)
JavaFX Scriptによるプログラミングの紹介。
なんど読み返してもJavaFXが魅力ある言語には思えない。 functionとoperationの奇妙な分離といい、 宣言的なんだけど、結局制限の多い記述とか、 よく動作が理解しにくいlazyとか。
もうちょっと言語そのものがわかれば、使いやすいと感じるようになるのかなぁ。
メールがたまりすぎちゃうと処理できなっちゃって、「破産」するしかなくなる、という話。
スパムはまあある程度機械的に処理できるので別としても、 確かにメールはたまる一方である。 私のinboxには処理待ちのメールが残っているのだが、 すでに500通を越えている。
古いものはもうフォローしきれないのでアーカイブ行きになるべきだろうな。
Timothy BuddのLittle Smalltalk ver.3 からの派生。
まだはじまったばかりだが、GCが単純なリファレンスカウントから マークアンドスイープによって循環参照に対応したり、 残っていたバグをつぶしたり、今後が期待できる、かも。
LazyなArrayを、と書いたら、弾さんがあっという間にPerlで実装してしまったという話。
こういう時にtieというのは強力だよね。 言語機能としてはあまり好きではないんだけど。
RubyだとArrayの機能をそのまま流用とは行かず、 元々のエントリにあったLazyListのように別のクラスとして再実装する形になるだろう。
Rubiniusとかなら配列もRubyで記述されることになるから、 Arrayをサブクラス化して、いくつかのメソッドをオーバーライドすることで 簡単に目的が達せられるかもしれない。
blogで公開されている以上、「こっそり」とは呼べないのではないでしょうか。
どなたかがコメントされていたが、 「こっそり」の主体はあくまでも観察者である私であって、 作者の石橋さんではない。
アドバイスする「おじさんやおばさん」の価値をまったく否定するものではないが(そういえば、この業界、おばさん/おねえさんは、ほとんど見かけないなあ、少なくとも日本では)、 多すぎるリクエストやコメントが集中するにはまだ早いと私は考えていた。
たまたま見かけた「おじさん」がコメントするのならともかく、 1日数千PVの「Matzにっき」や、恐らく万を越えるPVを持つ「404 Blog Not Found」から リンクされると影響力が大きすぎるんではないかと。
杞憂かもしれないけど。
まあ、でも、しょうがない。 杞憂であることを祈りつつ、正常な成長が促されるように これからも見守ることにしよう。
言語設計ってのはねぇ、ソフトウェアの多くの領域とは違って 正解というものがほとんどないので、 難しいのだ。アドバイスしたがる人は多いけど、 本当に役に立つアドバイスができる経験者がどれだけいるかと考えると、 すべてのアドバイスは眉に唾をつけて聞くべきだ。
たぶん、「日本で一番言語設計にうるさい男」だろう私だって、 Rubyじゃない言語に対するアドバイスは当てにならない。
父が松江に訪問する。 こちらに来てから、ステーク大会とかでない普通の日に 父と同じ教会に出席したことはないような 気がするので実に10年以上ぶりということになる。
そういう日に限って、聖餐会の話やら神権会のレッスンやらが当たっている。 照れ臭いことで。
集会終了後、掃除に関するファイアサイド。 今までとは若干方針が変わって、 作業量は減ることになるので楽になりそうだ。
出張で信州・松本市へ。
出雲空港から伊丹空港へ。 さらに乗り継ぎで信州まつもと空港へ。
意外なことに出雲・伊丹間と伊丹・松本間は同じ機材(Q400)だった。 CAも同じ人。初めての経験。
まつもと空港はこじんまりとした空港。 行き先が、福岡、大阪(伊丹)、札幌しかない。 タクシーの運転手の人がいうには他にはエプソンの人が ビジネスジェットで利用するんだそうだ。
タクシーで空港からホテルまで移動。 その後、荷物をホテルに預けて、市内観光。
遠くの山はきれいだし、ちょうど天気もよいし、 熱からず寒からず、非常に快適である。 しかも、どこもかしこも「私の名前」だらけである(しかも、かなりの割合でひらがな)。
車一台一台にまで名前が付いている。
松本城を訪問。意外に平地でびっくりする。 松江城も、今は亡き米子城も山城ですこし高台に立っているので、 これが当たり前のような気がしていたが、戦国時代の城ではないだろうから、 高い位置にある必要はないのかも。
美しい城であった。
おみやげ(要望通りのキーホルダーなど)を購入。 昼食は蕎麦。出雲蕎麦よりも色が白くて上品な感じ。
というわけで、長野県ソフトウェア生産性研究会主催の講演会。
70名定員という話を聞いていたが、 ふたを開けたら出席は９５名だったそうだ。 かなりいっぱい。 長野市の方から来た人も大勢いたようだ。
で、2時間。
途中、5分休憩を入れたのと、最後5分残して質疑応答に当てたのと以外はしゃべりっぱなし。 大学の集中講義(5コマ×2日)を除くと、最長の講演だったのではないだろうか。 使用したスライドは実に106枚。
その後、懇親会。
大変待遇が良くてありがたかった。 なぜか、繰り返し繰り返し「先生」と呼ばれるのだけは閉口したけど。 私、教員じゃないし、医師でも、弁護士でも、作家でも、政治家でもないんで 「センセー」は勘弁していただきたい*1。
大変楽しかった。
そして、今度買い替えるプリンタはエプソンのにしようと思った。 問題はA970かA920かどちらにするかだが。
*1 その点、「住井さん」は教員なので難しい
で、泊まったホテルはネットは自由に使えたのだが、 メールが外に出ていかない。どうやらOutbound Port 25 Blockingを実施中のようだ。
以前から「なんとかしないと」と思っていつつも、 面倒でずるずると引き伸ばしていたのだが、どうにも手をつけざるをえない。 メール出さずにすむわけじゃないからね。
会社のメールサーバはサブミッションポートをオープンしているのは確認済。 以前、途中まで試した時にアカウントもパスワードも用意しておいた。
愛用のnullmailerはstarttlsに対応していないので、 MTAを置き換える必要がある。シンプルなものが好きなので、 msmtpとかnbsmtpとかを使おうかとも思ったが、 これらはメッセージキューを持たないので、 ネットに接続していない時にはメールが出せない。
しょうがないので定番のexim4を使うことに。 以前は設定がよくわからなかった(ように思った)のだが、 なんとなく設定してたらうまくメールが送れるようになった。
めでたし、めでたし。
PHPでは、round(0.49999999999)が1になる、という話。
一瞬、浮動小数点数の誤差の話かと思ったが、 考えてみれば0.5は二進数で割り切れる。
その真の理由はどうやら
要約すると、「紙とペンで計算すると5.045になるはずの値（実際にはコンピュータ上では約5.04499999999999992894573）を小数点以下第二位までで四捨五入してるのになぜか5.04になった！バグだ！」って騒いでいるプログラマがバグ報告をしてきて、これに対処するために四捨五入の境界値付近（0.00000000001くらいの差）だったら全部0から遠い方に切り上げるようなコード修正をした、ということかと思います。
ということらしい。
えーと、通常なら絶対にあり得ない設計なんだが、 PHPユーザはこういう設計センスの言語を信頼できるのか*1。
なんだかとても悲しい気持ちになった。
それはそれとして、PHPやPythonのround関数はオプショナルな第2引数をとって何桁目まで切り捨てるのかどうかが指定できるのだそうだ。 これは面白いから、Rubyにも取り込もう。
p 5345.6432.round(2) # => 5345.64 p 53456432.round(-4) # => 53450000
となるはず。
追記
どうやら上記は正確ではなくて、補足エントリによるとconfigureが検出する状況によって、変な挙動だったりそうじゃなかったりするようだ。
って、要するにIA86の80bit浮動小数点数の問題かっ。まともな挙動をすることもある点では欠点をあげつらうのは「フェアじゃない」のかもしれないけど、 正直、自分の使ってるPHPが変な動作をするかもしれないというのは イヤすぎる。なんでこんなことに。
*1 オマエが言うか、という批判は甘んじて受けよう
懇親会で「私、こんなフレームワーク作ってます」という話が出たもの。
「そりゃ、皆さんに知ってもらわないと損ですよ」と焚き付けたら、 さっそくsourceforge.jpでアップデートされていた。素早い。
オープンソースやフリーソフトウェアへの理解はもうずいぶん進んだのだろうと 思っていたのだが、「業界」の外では、まだまだまるで理解されていないのだ ということがよくわかる文章。
この場合の「業界」は「IT業界」ではなくて(記者はIT分野の記者だ)、 「FLOSS業界」のこと。
8時ちょうど...ではなく、7時59分のあずさ6号に乗って東京へ。
松本から東京は思ったよりも近い。飛行機じゃないから気楽だしね。
東京ではニューヨークから来たRubyユーザと一緒にお昼。 Rubyのこと、ほめてもらえるのはうれしい。けど、照れ臭い。
あと、日本の食事は安いとか、日本のベーグルは本物じゃない、とか。 文化とか食べ物とかのこと。あと2週間日本にいるというのに RubyKaigiのこと知らなかったので紹介しておく。 が、今からチケット買えるんだろうか。
U20プロコン実行委員会。 今年はどのくらい集まるかなあ。
会合終了後、よしおかさんのポロシャツをほめたら できたばかりというレアモノのAsianuxポロシャツをいただいた。
ラッキー。
明日のLinux World/Expo Tokyo 2007での発表は 後半にRailsのデモをやってもらうように会社の人にお願いした。 が、あんまり発表とか経験がなかったので 緊張しまくり。とにかく準備するしかないと
の繰り返し。コストに見合うかどうかはともかく、熱意はすごい。 今後の成長の糧になるといいね。
稲荷町のホテル。古いのはともかく、 浴室がひどい臭い。もう泊まらない。
Railsでなく、Rail。Rubyとは関係ない。
RailはBefungeやPATHの流れを汲む二次元言語。 Railでの「Hello World」はこうなる。
$ 'main' (--): \ \-[Hello World!\n\]o-#
標準入力を標準出力にコピーするcatはこう。
$ 'main' (--):
\
| /---------\
| | |
| \ /-io-/
\---e-<
\-#
ループが「ループ(輪)」として目に見えるのが特徴。
CodeGearのイベント記事をGoogle Translateで翻訳したら 出席するはずの私の名前が消えてしまったという話。
なぜ、むしろ翻訳しやすいひらがなの「まつもとさん」の名前を翻訳できず、漢字の木村明治さん（Akijiになっているけど、正しくはMeijiさん）が翻訳できるのか、不思議。
となっているが、実はひらがなの名前は機械翻訳泣かせである。 つまり、漢字の羅列は名前として認識しやすいが、 ひらがなだと、通常の文の一部として解釈することが多いようだ。 たとえば、
まつもとゆきひろ
を
「まつも」と「ゆきひろ」
と解釈し、「まつもってなによ」と混乱してしまうとか。
というわけで、6/5にはCodeGearデベロッパーキャップゲスト出演します。
デジカメにおいて、機能競争が飽和してきていて、 打開するためには「時流に反した割り切り」ではないか、という話を、 リコーを題材にして。
機能競争というのはソフトウェア(や言語)の世界でも日常的で、 なんだかんだ言っても「なにができるか」で評価されることが多いんだけど、 そういう時こそ違う評価軸(たとえばRubyなら「どのくらい気分が良いか」)を 提示することが成功の鍵になるのではないか、と思う。
連日PHPを話題にしているのは、 PHPを嫌いだからじゃなくて、PHPという言語の状況が素材として面白いからである。
今回のお話は
結果として開発者はPythonやRubyに逃げていき、PHPは死んでしまうのではないか、という懸念。
あらゆるソフトウェアについて新しいバージョンへの移行は 難しいことであるが、PHPの場合、それが顕著なのかもしれない。
Rubyでも1.8と1.9の間にギャップがあるので、 似たような状況にならないとは限らない。
プレゼンテーション。11時から最終練習という話だったが 少々遅刻した。ごめんね。
練習後、昼食。ビッグサイトはどこも満席。 かろうじてカレーを食べる。
1時からのSeasarのひがさんのセッションは大混雑。 すごい人気である。
と、思ったら、2時からの私のところも馬鹿にならない人数が集まる。 30分以上前から席を陣取ってる人までいるし。 最初30分弱は私がRubyをとりまく現状について話して、 残り15分くらいを山崎さんにデモしてもらう。
いつも、スライドばかりでおもしろくもないプレゼンだが 今回は趣向を変えて、と思ったのだが、担当になった山崎さんには いい迷惑だったかもしれない。せめて成長の糧にしてね。
デモのある発表は初めてであったが聴衆はどう感じたろうか。 数人に話を聞く限りでは、 おおむね好評だったのではないかと思う。
ただし、難点もあって、
くらいは残念だった。まあ、こんなに人間が来ることを想定した会場設計ではなかったものな。
ほか、風呂グラマー、増井(masuidrive)さんに会ったり、あちこちブースをめぐったり。 増井さんはおととしのOSC札幌で私が英語で質疑応答したのに影響されて アメリカに引っ越すのだそうだ。すげーっ。
思わぬところで他人の人生に影響を与えてしまっている。 なんだか恐いような気がする。
昨日公開された、私・平鍋さん・角谷さんの鼎談。 Linux World会場でもうちのブースで上映されていた。
今回はAgile・オブジェクト系言語の歴史概観。 ホワイトボードに書いていたものをタイムライン化したものも用意した。
うだうだとした話だが、これはこの後もずっと続きます。 ぜんぶで6話くらいになるとか聞いたような気がする。
「Rubyの鍵は信頼である」という話。
信頼については昨年末の福岡での発表で強調した覚えがあるが、 この人はそれを(Google Translateかなにかで)翻訳して読んだのだろうか(スライド公開してないような)、それともRubyを見ていて独自にその見解に到達したのだろうか。
どうも後者のようだが、だとすると、その感覚は非常に鋭い。 まるで言語仕様(とわずかな私の言葉)だけから「Ruby Way」を切り出してきた Hal Fultonのように鋭い。
Enumerableを操作するのに
@stooges.select {|s| s.name == 'Mo'}
と書く代わりに
@stooges.that.have.name == 'Mo'
と書くためのライブラリ、ho_enumerable.rbについて。
非常にRailsというか、ActiveSupportと同じ臭いがするが、 それはそれでアリなんじゃないかと思う。 でも、こういうのをHigher Orderっていうのかなあ。
というわけで、昨日U-20プロコン実行委員会でポロシャツをいただいたわけだが、
なんて書かれた(しかも出かける前にこのエントリを読んでしまった)からには、 着ていかないわけには行くまい。というわけで、Linux Worldでは 関係者でもないのもAsianuxポロシャツを来ている「自称ハッカー」が目撃されました、とさ。
あと、オライリーからも何枚もTシャツをいただいてしまった。 ありがとうございます。
夏時間(Daylight Saving Time - DST)のせいで計算が狂って2004年10月には30日しかないことになってしまったプログラムの話。
もう何年も前の話になるが、RubyのTimeクラスにも面倒なバグがあって 半年に一回1時間ずれるというレポートに対処するのに大変苦労したことがある。 何年かに一回政治家たちが省エネとか訳のわからない理由を言い訳に サマータイム導入を口にするが、冗談じゃない。
夏時間がないのは日本の美徳だと断言したい。 そんなものは要らない。
「今まではハードがどんどん高速化してきたので、ソフトウェアの皆さんは(マシンのアップグレードで)自動的に性能向上を享受できていましたが、これからは諸般の事情でそういうことはできなくなります。ソフトウェアの皆さんもご協力を」という話。
っていうか、最初からそういう風に言ってほしいものだ。
LinuxWorldでゼンドジャパンのブースに行って質問してきた。 あまり嫌みにならないよう、身分は隠して。
で、関心があったのはPHPのスクリプトキャッシング。 これにより実行速度が1.3から3倍になるのだそうだ。 どうにも納得が行かないのでいろいろ食い下がったが 対応してくださったのが内部までご存じの技術者ではなかったので 「理屈はともかく体感では確かに速くなります」とのことであった。 実体験を疑う理由はない。が、技術屋としては「なぜそうなるのか」がとても気になる。
私の理解が正しければ、スクリプトキャッシングは、 プログラムのロード時に構文解析を行い、内部的に用いる中間表現に変換したものを 保存しておくことにより、構文解析のコストを削減し、 高速化を実現する技術である。PHP以外にもたとえばPythonが同様のことを実現している (でも、Pythonは1.3倍とか言ってない)。
しかし、これにより実行速度が1.3から3倍になるということは、 単純に計算してアプリケーションの実行時間の23%から67%が 構文解析で消費されている必要があるのではないか。 Rubyではよっぽど特殊なケース以外では構文解析時間が 実行時間に対して大きな比率を占めたことはない。 各種プロファイルを行っても構文解析関係が上位に来たことは 私の経験では一度もない(ので、通常の感覚ではチューニングの対象にならない)。
にもかかわらず、PHPではこの結果というのはどういうことなのだろうか。 ソースも見てないので、断言はできないのだけど、いくつか考察してみる。 間違いがあれば(きっとある)、遠慮なく指摘してほしい。
構文解析が予想以上にコスト高
普通に考えたら、構文解析はそんなに重い処理ではないのだが、 実はそれは思いこみで、なんらかの事情でPHPでは構文解析のコストが非常に高い。
構文解析が予想以上に頻繁に実行される
普通に考えたら、mod_phpやfastcgiを使えば、構文解析はほとんど行われないと 思ってしまうが、実はそれは思いこみで、なんらかの事情でPHPでは構文解析の頻度が 非常に高い。あるいは実行速度が改善されたというのはCGIモードであった。
実は単なるキャッシングではない
スクリプトキャッシングは単なるキャッシングではなく、 同時になんらかの最適化も行っている。 キャッシングされて何度も実行されることが期待されるので、 かなり頑張って最適化しても、時間消費に見合う。 とはいえ、PHPのような言語でそんなに最適化が効くような気はしないけど。
謎は深まる。
というわけで、とうとう正式発表。 楽天からのプレスリリース。
FAQ。
転職ですか
いいえ、NaClと兼務になります。
東京勤務ですか
いいえ、松江在住のままです。 定期的(月一程度)face to faceのミーティングを行います。 あとはネットで。
楽天でなにするんですか？
えっと、「フェロー」です。それなにって言わないように。 私もよくわからないから(苦笑)。
まだ詳細は決まってないけど、基本的にRubyの活用、 技術発展に関するテーマの「研究」をすることになります。 結局、今までとあんまり変わらないような気もしないでもないですが、 それは今後明らかになると思います。
昨日のLinuxWorldのレポート。
私たちのセッションについても触れられている。
「毎日1つずつWebアプリケーションを作るようなことはまずないので、1日かかるか15分でできるかというのは、生産性の面からはあまり関係ないように思われるかもしれない。だが、開発者の仕事は作ってそれで終わりではない。15分で済めば残りの時間で既存アプリケーションのメンテナンスができるし、発注元からの仕様変更にも迅速に対応できるようになる」（まつもと氏）。
うーん、なんかニュアンスが違うな。「〜まずないので15分でできるというのはインパクトはあってもクリティカルではない。Railsの本当の便利さは機能拡張や変更の容易さにある」とかいうようなつもりだったんだけど。
なんでもできるけど、全部はとても覚えられない、CommonLispのLoopマクロについて。
もうちょっとなんとかならないものかと思わないでもない。
プリプロセッサを使ってRubyにもPythonスタイルの インデントによるブロックを、という話。
あれが好きな人は結構いるよね。個人的にはあまり好きじゃないんだけど。 弊害の方が多いような気がして。
4839919798
Code Readingに続くシリーズ二冊目。「今度は品質だ」
途中GreatCodeとかが入ったので、勘違いしている人もいるかもしれないけど、 厳密にはこれが二冊目だから。
ということで、Code Reading同様カバー裏のギミックも健在である。 私の主要な役割は前書き書き。これはこれで大変なのよ。