最新 追記

Matzにっき


2007年07月01日 [長年日記]

_ [教会] 第一安息日

もう7月だよ。時間がたつのが速すぎる気がする。

司会はビショップが引き受けてくださった。 私は日曜学校で教師、 「神権組織について」。

なんとなく蘊蓄っぽくなってしまった。 教会ではそういう知識偏重なやり方はやめようと思っているのに。


2007年07月02日 [長年日記]

_ 2ちゃんねる実況中継 あるベルギー人から見た日本

確かに納得した。

334 :可愛い奥様:2007/06/26(火) 09:46:19 ID:raxdPvfD0
OLだった頃、会社で働いていた日本に超詳しいベルギー人が言ったことに納得してた。
日本文化は身内受けの凝り性文化だそう。
外国文化に負けまいとしているのではなく、
世に意図的にインパクトを与えようとしているのでもなく、
今ここにいる同じ価値観を共有する仲間からの喝采を浴びたいと考える。
その結果、同じものを志す者同士の「これすごいだろ、おもしろいだろ」合戦が始まり、
そこで生み出される物が自然と研ぎ澄まされていく。
でもその競争は、敵対的なものではなく、お互いを尊敬しあいながら、静かに深く進行していく。

そしてある日、偶然目撃した異文化出身の人間(外国人)から、
それがすごいものであることを知らされる。
ほとんどの日本人はその日が来るまで、自分たちが作り上げた物がすごいものとは知らない。
もろもろの伝統文化、芸能、電化製品、アニメ、他、みんな同じパターンで世界に広まっていった。
だから、日本がここまで発展してきたのも必然的なものだし、
この精神が衰えない限り、これからも日本は誰に頼まれることもなく、
知らないうちに勝手に世界にインパクトを与え続けていくだろうと。

「孤立する日本」とか「ガラパゴス」とか、 日本の現状を懸念する人は多いが、それはそれで悪いものではないのかもしれない。 効率はめちゃくちゃ悪そうだけど、良いものの誕生は効率ばかりでは はかれない。

そう考えると、日本がまるで巨大な蠱毒のようだ。 実際、そうなのかもしれない。Rubyだってそのパターンといえないことはない。

次に世界にインパクトを与えるのはなにか。

_ Programming for the masses

プログラミング人口は増えてるっていうけど、 増えたのは半分素人のようなのばっかりじゃないか、 フォーラムで「C#で配列はどうやって宣言するの」なんて 質問する連中がいくらいても役に立たない、という話。

まあねぇ、この業界、半分素人のような開発者は多いからねぇ。 アルゴリズムがなんだかわからない人とか。 Googleの使い方がわからない人とか。

_ とりあえず暇だったし何となく始めたブログ - flymake でリアルタイム文法チェック

Emacs 22に標準添付のflymakeを使うと (Rubyでも)リアルタイムに文法チェックができる、という話。

IDEでは時々見かけるこの機能が欲しいと言う人は それなりにいるようなので、そういう人は喜ぶんじゃないかな。 そういう人はそもそもEmacsを使わないという懸念はとりあえず置いといて。

_ cdiggins.com >> My Goal: Naive Programming

アルゴリズムを直接書き下したようなプログラムを書くと、 「素朴」とか「工夫がない」とかけなされるけど、 考えてみりゃ思ったまま書いてちゃんと動く「素朴なプログラム」が一番じゃね? という話。

さらに言えば、ある言語特有のイディオム(特に性能に関するもの)は、 その言語の弱さの表明以外の何者ではないのでは、という懸念。

そう。人はもっと「実行可能擬似コード」の重要さについて 考えたほうがいい。あと、性能のためにはたくさん書く勤勉さは美徳ではないことも。


2007年07月03日 [長年日記]

_ mixiが自社開発の検索エンジンに移行、ウェブ検索はYSTに:ニュース - CNET Japan

やっとHyperEstrailerがmixi経営に活かされるということか。 っていうか、今まで使ってなかったの?

それでも、 使われずに塩漬けになるプロジェクトも多い中、 ちゃんと使われるのは良いことだと思うけど。

っていうか、うちのRastが絶賛塩漬け中ってのは 大問題だと思う。

_ [Ruby] CodeZine:Java開発者のためのRubyガイド(Word, 言語比較)

私自身が「Java視点」というものをまったく持っていないので、 そういう意味では新鮮な記事であった。

_ 旭川に移動。

島大の野田先生と、出雲空港から羽田経由で旭川へ。

北海道と聞いて寒いところじゃないかと思っていたんだけど、 気温は30℃近い。暑いじゃないか。

お昼は「いちくら」で鮭節塩ラーメンを。 最初の一口は物足りないかな、と思ったのだけど、 最後まで食べたら十分おいしかった。不思議な味。

_ [Ruby] 世界に広がるオブジェクト指向スクリプト言語〜Rubyについて開発者が語る

というわけで、講演。

内容は先週の島大でのものと近いが、 先週の反省を踏まえてスライドの順序を並べ替えたり、 新しいものを書き足したりしている。

が、正直、もう少し若い人たちが多いと思っていたのだが、 予想以上にスーツ率が高くてどきどきしてしまった。 お役に立てたのかしら。

私の後は野田教授が島根での活動について 語ってくださった。さすが教育職だけあって、 なかなかプレゼンがうまい。RubyKaigiで(聞けなかったけど)好評だったのも わかるというものである。

その後、懇親会。さらに一部の人とはお酒の席に(私は飲まないけど)。

二次会は(確か)「ジャンボリー」という名前の居酒屋であったが、 独自の食べ物や(やまわさびってなに?)、内地とは味の違う食べ物(アスパラとか)が あって、食いしん坊の私は大変堪能した。

ご馳走さまでした。

ホテルに戻る途中、「ハウルの動く城」を目撃したような気がするが、 気のせいだろうか。

で、後は深夜まで原稿書き(書き下ろし)。


2007年07月04日 [長年日記]

_ 旭山動物園

旭川SOHO協議会の会長さん、副会長さんにエスコートしていただいて、 いまや日本で一番人気の動物園である旭山動物園へ。

「なぜ旭川なのに旭山か」という素朴な質問に対しては、 「動物園が旭山という山にある」という答えが。なるほど。

昔から旭川の子供たちの遠足の地であった動物園は しかし90年代には不人気から閉園の危機にあったとか。 しかし、創意工夫でここまでもってきたとか。

今は人気のために施設が新設されたりしているが、 老朽化した施設の中で工夫をして人気を集めたという話の方が (プロジェクトXに感動しがちな)私たちの心を打つかもしれない。

で、印象は「近い...」であった。 訪問中、何度もこの言葉をつぶやいた。 ほんとに動物たちとの距離が非常に近い。

ま、単に距離だけで言えば、松江フォーゲルパークでの 鳥との距離も負けてないところがあると思うが、 旭山動物園の場合、 特にペンギンやシロクマ、アザラシのように 動きのある(派手な)動物との距離が近いのが印象的である。

平日午前だというのに人が一杯であった。すばらしい。

今日のお昼も塩ラーメンであった。 が、今日のは昨日と違って白湯スープを使ったもので、 外見は博多の豚骨スープみたい。

濃厚な味わいであった。 お店の名前を忘れてしまったのが悔やまれる。

で、ちょっと羽田経由で松江に帰る。

_ インタビュー

帰りは乗り継ぎが悪くて、 羽田で2時間ほど待つことになっていた、のだが、 「楽天技術研究所について取材したい」という話で、 このタイミングで、楽天の人と、日経の人とを羽田に呼びつけて(えらそー)、 取材を受ける。

ちゃんと「楽天の中の人」として仕事ができたかな。 まだまだ新米だけど

_ [Ruby] Rhino on Rails

Rhino on Railsについての、Steve Yegge本人による「釈明」。

端で揶揄されるほどRhino on Railsは馬鹿げた技術的選択ではないということ。 ま、そうだろうとも。

_ [言語] ITmedia エンタープライズ:ゼンド、PHP開発企業のための新パートナー制度を発表

ゼンド・ジャパンは頑張っている(ように見える)。

オープンソースにどっぷりの身からは、こういうのがどこまで有効なのか 全然わからないんだけど、スーツな人にとってはこういうのが安心感を提供する、 のかもしれない。ま、それでスーツな人が大満足して オープンソースがうまく行くのであれば、それくらいのことはなんでもない気がする。

_ [Ruby] [動画]RubyがLispから継承したもの、してないもの − @IT情報マネジメント

平鍋さんとの対談シリーズ、第三回(全6回)。

今回はLispとRubyの関係。

「RubyとPythonはLispの別の側面を受け継いでいる」とかは 他人には話したことのないネタかもしれない。


2007年07月05日 [長年日記]

_ 第5回 整理を拒否して能率を上げる (葉玉匡美の脱時空勉強術):NBonline(日経ビジネス オンライン)

机は資料のキャッシュであると割り切って、 整理せずに積み上げる方式。すぐに見つからなければもう探さない。

単なる言い訳という気もしないでもないが、 とてつもなく散らかった机の持ち主としては非常に共感する。

ちなみに積み上がった机は限界が来た時点(大体年末の大掃除の時)で フラッシュし、きれいになる。が、机の面が見えるのはその後数週間だけだ。

_ [Ruby] 0.7 developer preview released! - Rubinius

Rubinius 0.7がリリースされた、という話。

実用レベルにはまだまだだがあきらめず着実に進歩しているところは評価したい。 Evanは業務時間の半分はRubiniusに使ってもよいということで、 職場の理解があると言うことはプロジェクトが中断しにくいということでもあるし、 そういう意味では将来が期待できると思う。

もちろん、フルタイムで働いているJRubyも。

_ [言語] Dr. Dobb's | Python NetWorkSpaces and Parallel Programs | 7 2, 2007

NetWorkSpacesという仕組みを使ってプロセス間通信をすることで、

  • 異言語間通信
  • 分散処理

を実現しようという話。PythonとRの間で通信ができると言うことは、 当然、Rubyでも利用可能だと思う。

通信コストが十分に低ければマルチコアを活用する目的にも使えるかも。


2007年07月06日 [長年日記]

_ [言語] 23 Programming Languages compared through their Amazon book sales

Amazonの売り上げに見る人気言語ランキング。

これは総計ではなく、その言語についてもっともAmazon売り上げが多い書籍各1冊の 順位によるランキング。ちなみに上位三位は

  1. JavaScript - JavaScript: The Definitive Guide
  2. Java - Head First Java, 2nd Edition
  3. Ruby - Programming Ruby: The Pragmatic Programmers' Guide, Second Edition

だそうだ。もちろん、この計算方法では、Javaのような書籍がたくさん出ている言語は 売り上げが分散する傾向があるので不利になるだろう。 それでも2位になるJavaはたいしたものか。

_ [Ruby] Part2 Rubyに学ぶ「Ruby on Railsの正体」:ITpro

「Rubyの秘密」。

日経ソフトウェアに掲載された時も思ったのだが、 制約と自由の関係について的確な指摘がなされていると思う。 ある種の制約は自由を増やす傾向がある。 ある種の自由は人間の負担を増す傾向がある。

_ [言語] lucille 開発日記 >> LLVM 2.0 & gcc 4.2

LLVM 2.0のJIT性能は(少なくともあるベンチマークでは)gcc 4.2よりも 高速であったという話。

LLVMの性能が高いって話は以前から聞いてはいたけど、 ネーティブコンパイラに勝つってのは予想外であった。 もうちょっといろんな局面での性能比もみたいものだ。

_ [Ruby] Rail Spikes: Rails developers: experts or script kiddies?

Railsには質の悪い開発者が流れこんでいるんじゃないか、という話。 先日のコードモンキーの話と似てる。

Rails(やRuby)がニッチな間は、コミュニティを構成するのは マイナーな言語やフレームワークに気がつくだけの「アンテナが高い人」が中心で、 一般的に技術レベルが高いことが期待されていたが、 こうあちこちで取り上げられるようになると、いつまでもそれを期待するわけにはいかない。

Rails largely draws its market share from PHP and Java. Rails apps can be written as quickly as PHP, and can be as robust and maintainable as Java. And developer satisfaction exceeds both.

Railsは、PHPとJavaからマーケットシェアを引き出している。 RailsアプリはPHPと同じくらい素早く、 Javaと同じくらい頑丈で保守性が高い。 そして開発者満足度はいずれの言語よりも高い。

PHP isn’t all bad, but it is unfortunately a magnet for bad code. This could be because many bad coders choose PHP, or because PHP has really low barriers for entry, or because PHP itself encourages bad development practices. I suggest that it is a combination of these. The end result: PHP does not have a culture of high programming standards.

PHPは悪くない。が、不幸にして悪いコードを引きつけてきた。 悪いプログラマがPHPを選ぶからかもしれない。 PHPが初心者にとっつきやすすぎるからかも。 あるいはPHPそのものが悪い開発習慣を推奨するからかも。 おそらくはその3つの組み合わせである。

じゃあ、PHP出身者が流れ込んでくるとRailsもPHPのように「悪いコードの巣窟」になるのか。 このエントリの筆者は否定的である。 なぜなら、Railsはその根幹に「良い開発習慣」を含んでいるから。 たとえばユニットテストとか、デザインパターンとか。

RubyやRailsが開発者の「底上げ」に利するのであれば、それよりうれしいことはない。


2007年07月07日 [長年日記]

_ [Ruby] Ruby なんて遅くて使えないよねって言ってみる - Akasata's Page(あかさたのページ)

タイトルは「遅くて使えない」となっているが、 実際に呼んでみると「使えないわけではない」というような論調。

いや、別に「Rubyが遅い(特に1.8が遅い)」って言われても、 「はぁ、そうですか」としか思わないんだけど(性能を目指して実装してないし)、 パフォーマンスと言うのは非常にFUDに満ちあふれた分野であるので、 誰かが「遅い」とか「遅くて使えない」と言った場合には、 その真意を見極める必要がある。

で、「遅くて使えない」って言った人が、 その根拠にGreat Language Shootoutを 持ち出してくるようなら、その人の言うことは聞かなくてもいい。

Shootoutは娯楽としては面白いけど、 実際の仕事の参考になるようなベンチマークではない。 これが測っているのは主にインタプリタの性能(メソッド呼び出しや単純な計算)だが、 実際のアプリケーションの性能は、そのような部分よりも アプリケーションフレームワークの性能や、ライブラリ実装の品質などの 影響の方がはるかに大きい。

YARV (Ruby 1.9)がリリースされたあかつきにはShootoutの順位はずいぶん変化すると思う。 YARVは現在のPHPやPerlやPythonよりも速い。 テストによっては現在のRuby (1.8)の数倍から数十倍高速になる。

じゃあ、速度の問題はこれで解決かというとそんなことはない。 YARVになってもRailsの性能は改善されないからだ。 要するにRailsが遅いのだとしてもそのボトルネックはインタプリタ性能にはないってこと。

このことを見るだけでも、実際の局面でShootoutがいかに意味がないかはわかると思う。

さて、とはいえ、新しいVMを導入したのにRailsの性能が改善しないというのは あまりにもナンなので、12月のリリース前にはRailsをベンチマークにして、 ボトルネックを探して改善する計画がある。本番ではRailsも高速になるから。多分。

_ BabelStone: What's new in Unicode 5.1 ?

2008年以降の「いつか」にリリースされるUnicode 5.1で増えるもの。 これによって総文字数は100,823文字とはじめて10万文字を越える(5.0は99,024文字)。

誰だよ、65536文字表現できれば十分だなんて言ったのは。

とはいえ、もうこのレベルになると追加されるのはもうほとんど使われないような文字ばかり。 特に台湾から来たものとかは「ある特定の個人の名前に使われているだけ」とか ちょっとどうなのよ、というものもある。その人が死んだらもう歴史的文字になっちゃうね。

自分が死んだ後に歴史に名を残すのはなかなか難しいことで、 大半の人たちは200年もしないうちに存在すら定かではなくなってしまう。 それを思うと、Unicodeという国際規格に自分の名前を残すというのは 良い考えかも……迷惑だから、やめてください。ダメ、ぜったい。


2007年07月08日 [長年日記]

_ [教会] 日曜日

次女が聖餐会でお話をしてくれる。 かなり照れながらも一生懸命に話す姿が好ましい。

日曜学校では教師。 ビショップリックが毎週日曜学校教師をしなければならない 人手不足が嘆かわしいと思う半面、 結構教えるの好きだから楽しいと思うところもある。

でも、くたびれた。


2007年07月09日 [長年日記]

_ 富士通、島根でもノートパソコン組み立て教室を実施 | パソコン | マイコミジャーナル

おおっ、近所だ。行くか。

と思ったが、この日は「LL魂」の日である。ちょっと無理だな。

_ [言語] Java and K

スクリーンキャスト。JavaとK(APLの末裔)の比較(英語)。

まあ、このタスクが圧倒的にK向けということを置いておいても、 ベクタを扱うプログラムにおけるAPL系言語の生産性は間違いない。 ある程度はRubyにも取り込みたいんだけど、 どういうAPIにするのが良いかなあ。

まずは複数のベクタ(配列)の各要素に対して処理する(APLでいう

v1 + v2

でv1とv2の各要素を加算した配列を得るような)メソッドをEnumerableに加えればよいのかな。 良い名前が思いつかないけど。

_ [Ruby] [Rails] Webアプリケーションセキュリティフォーラム - Journal InTime (2007-07-05(木))

セキュアなRailsプログラムの作り方。 こうやってまとめておくとありがたい。


2007年07月10日 [長年日記]

_ [言語] Large Binary Data is a Weakness of Erlang << Metalinguistic Abstraction

Erlangは巨大なバイナリデータの扱いが苦手、という話。

基本的にパターンマッチで処理を行うのだが、 毎回文字列のコピーを作っちゃうから、長い文字列だと効率が悪いということらしい。 copy-on-writeとか、部分文字列のようなのが必要なのかもしれない。

Rubyはその辺、ちょっと工夫はしてるけど、 文字列の構造がもっと複雑になってもいいなら(あと、Cレベルの互換性が下がってもいいなら)、 まだまだできることはあるんだけど。どうしよう。

本当に困ってる人が出てからでいいかな。

_ [Ruby] The easiest rubinius core library patch tutorial ever. << The Plan A

やさしいRubiniusの拡張法。

確かに簡単なんだけど、これだと便利すぎて厳密な互換性は実現できそうにないな。 to_intのような変換システムはどこで動くんだろう。

しかし、こうやって簡単に機能が拡張できるというのは それはそれで素晴らしいことのような気はする。 効率もよくするんだって言ってるんだし。

_ こんなTシャツはエンジニアしか思いつかないぜ!夏/Tech総研

個人的には以下のものがウケた。

Honey, you are my jewel.
Ruby and perl are not.

あと、

grep me

も悪くない。でも、最近だと実用性の観点からは「Google me」なんだろうなあ。


2007年07月11日 [長年日記]

_ Google デスクトップ

ようやっとインデックス作成が一段落したようだ。 えーっと何日かかったんだ? 2週間?

結局30万アイテム強であった。多い。

_ [Ruby] Agile Artisans::C on Rails

CでRails互換フレームワークを、という話ではなく、 本当にパフォーマンスが必要ならRubyInlineを使って、 Cコードを埋め込むことでパフォーマンス改善できるよ、という話。

このエントリの場合には2 reqs/secが21 reqs/secと10倍の改善が可能であったそうな。 もちろん、彼のアプリケーションがどのようなものであったのか分からないし、 おそらくはほとんどの場合にはRubyInlineまでは必要になることはないと思うのだけど、 もし本当に必要ならそういう手もあると知ってることは悪いことではないだろう。

なお、彼(Jared)は、この経験をもとにOSCONでUse C to Tune Your Rails Applicationというプレゼンを行うそうだ。

_ [Ruby] Using :select in Rails for Better Performance - Geek Skillz

もうひとつ、Railsパフォーマンス改善テクニック。

Rails(というかActiveRecord)は、SQLを隠蔽しちゃうんで、 SQLのSELECT DISTINCTを実現するのに、たとえば

@distinctlist = Item.find(:all).map{ |i| i.fieldname }.uniq

なんてことをやっちゃうことがあるんだけど(あるの? ありそう)、 実は、

Item.find(:all, :select => 'DISTINCT fieldname')

とやる方がずっと効率がいい。当たり前といえば当たり前だけど。 データベースのことはデータベースにやらせた方が(効率が)よい。

もっとも、それで生SQLばかり使うようになるのでは本末転倒だけど。

_ [Ruby] Ruby Project Spotlight, June '07 : Sequel - O'Reilly Ruby

ならいっそActiveRecordなんて使わないでSQLをそのまま(でもRuby風に)使いたい、 というのがSequelである。

私はDBプログラミングの経験がないんで使い勝手とか想像してもよくわからないんだけど、 SQLの雰囲気がそのまま感じられるような気がする。 でも、せっかくだからfilterとかでなんでも文字列で渡すんじゃなくて もうちょっとメソッドに隠蔽(で、内部的にSQLを生成)するアプローチをとってくれた方が Ruby風味が高くて「おいしかった」かも。

PythonのSQLArchemyとかそんな感じなの?

_ [言語] Transcendental Technical Travails: Tagged unboxed floating point numbers

Rubyでは31bitまでの整数は即値といってタグをつけてポインタ値に埋め込んでいる。 これはインタプリタ実装の基本的な最適化テクニックで、これによって 普段よく使う整数値の効率が非常に高くなっている。

一方、浮動小数点数はこのテクニックの対象外になるので、 小数ひとつひとつのためにオブジェクトが割り当てられ、 効率が非常に悪くなっている(大きな数Bignumも同様)。

で、リンク先はタグをつけて埋め込む技術を浮動小数点数に適用する方法について。

「値」が最低64ビットになってしまうというのは、ある意味デメリットであるが、 最近ではポインタ64ビットなアーキテクチャも増えてるし、 そろそろ現実的な選択肢になってきてるのかも。


2007年07月12日 [長年日記]

_ モーションポートレート株式会社

静止画から動画を生成する技術。

それはともかく、

カーソルを顔の周りでぐるぐるしてたら「目が回るぅ〜」と言われたのには 驚愕した。芸が細かすぎる。

_ [言語] Projects: pybraces (Tim Hatch)

先日、Rubyをインデントブロックにするプリプロセッサを紹介したが、 今度はPythonでブレースで使うもの。

秀逸なのは、プリプロセッサをcodingプラグマで起動するアイディア。 普通のPythonプログラムの先頭に

# -*- encoding: braces -*-

を加えるだけでブレースによるブロックが使えるようになる。なんと。 今度はエンコーディングが指定できなくなるけど。

_ 【コラム】コーチングで変わる人材管理 (1) デキない社員がやってきた! - 新米メンターの悪戦苦闘 その1 | 経営 | マイコミジャーナル

えーと、新人(中途でも)うまく適合できなくて、 お互いに不幸な事態はしばしば発生するが、 メンタリングでそれが解決できるならば、それに越したことはない。

まだ初回だけど、今後も読まなくちゃ。


2007年07月13日 [長年日記]

_ [言語] 組み込みから生まれた言語Erlangの時代が来る - 日経エレクトロニクス - Tech-On!

いつの間にか日経ソフトウェアから日経エレクトロニクスへ異動した 大森さんによるErlangの紹介。しかし、いまだに心の中で「えるらんぐ」と発音しちゃうな。 正解は「あーらん」です。

さて、この記事には事実とやや異なる点がいくつかある。その辺を指摘しておこう。

まず、一番気になる点はタイトルから。「組み込みから生まれた」とあるが これは私の知る限りでは事実に反する。

Erlangは,1987年ごろにスウェーデンのEricssonで開発されました。元々は,信頼性が要求される通信機器のために設計された組み込み用のプログラミング言語です。

確かにErlangは「1987年ごろにスウェーデンのEricssonで開発」されており、 「信頼性が要求される通信機器のために設計された」が、 その通信機器とは電話交換機である。 電話交換機はそれはそれで面白い領域ではあるのだが(CHILLのような専用言語もある)、 しかし、一般的には「組み込み」とは言わない分野だと思う。

もうひとつは、私がこの言語に感じている思いについて。

まつもと氏は今でもErlangがお気に入りらしく,今年4月には自身のWeb日記で,「次」に来る言語の候補としてErlangの名前を挙げています

もちろん、私がErlangに注目しているのは事実で、 私を経由してはじめてErlangを知った人も多いだろうとは思う。 また、「次の言語」の候補として名前を挙げたこともある。

しかし、Erlangは最初から私の「お気に入り」の言語ではない。 たとえばLispがそうであるようには。 Erlangと比較するならばPythonでさえ、私のお気に入り言語と呼んでもよいと思う。

では、私はErlangの何に注目して、何が気に入らないのか。

注目しているのは、もちろん、アクターモデル(プロセスモデルと呼んでもπ計算モデルと呼んでもよいのかもしれない)による、高生産性並列プログラミングである。

たいたいにおいて並列プログラミングは難しいのだが、 Erlangにおいては、他言語のオブジェクトと同程度に軽量な「プロセス」と、 それらの間のメッセージ通信モデルにより、比較的簡単かつ高生産性で 並列プログラミング可能である。

しかも、関数型言語として値がimmutableであるが故に 同期や排他制御のコストがない(または低い)ので、 コアの数が増えれば増えるほど性能が向上する点も見逃せない (ただし、Erlang言語処理系そのものが驚くほど速いわけではない、らしい)。

気に入らない点は3つ。

ひとつは文法。Erlangには文法に気を使わない人によって設計された言語の臭いがする。 慣れの問題かもしれないけど、正直、Erlangの文法はお世辞にもわかりやすいとはいえない。

もうひとつは計算モデル。個人的に関数型言語はどうにも相性が悪いのだが、 Erlangはさらに相性の悪い論理型言語(具体的にはProlog)の感触もある。 これもかなり慣れの問題で、気にならない人は気にならないだろう。

最後も非常に個人的なことなのだが、ソースコードが読みにくい。 「Erlangの秘密」を探ろうと思ってソースコードを眺めたのだが、 どこになにがあるのかさっぱりわからなかった。残念。 もっとも、他の人にとってはRubyのソースコードだって読みやすくないかもしれないわけで、 「お前に言われたくない」と思った人もいるかもしれない。

というわけで、正直な感想は「Erlangは注目すべき言語だが、おそらくは将来の他言語に影響を与える礎になるのではないか」である。

_ [Ruby] InfoQ: Evan Phoenix on Rubinius - VM Internals Interview

RubiniusのEvan Phoenixのインタビュー。

そうか、こんな風にしてるんだね。 まだRubiniusのソースコード読んでなかったよ。

しかし、これはこれで茨の道だと思うけど、 それをある程度動くところまで持っていったEvanの努力(と根気)は 大したものだと思う。

_ [Ruby] Headius: To Keyword Or Not To Keyword

こんどはJRuby方面。

ある種のメソッドは予約語にしたい、という話。 以前、ささだくんも似たようなことを言ってたから気持ちはわかる。

ある種のメソッドとは

  • スタックフレームとか
  • ローカル変数とか
  • コンテキストとか

要するにコールフレームに属する情報を参照したり書き換えたりするメソッド。 たとえば、evalとかlocal_variablesとかがあがっている。

うーん、どうしよう。確かにそうするとコンパイル時にできることが増えて、 うれしい(特に実装者が)というのは理解できるけど、 予約語が増えるとろくなことはないし。悩ましい。

それにString#gsubとかIO#getsのような「普通の顔をしてるけど、 実は特殊なメソッド」をどうするのかとか考えると夜も眠れない。

で、最近は結構午前中に寝てたりする。

とりあえず、String#gsubについては、 ブロックにMatchDataを渡す新しいメソッドを用意するのはどうだろうか。 より使用を促すためString#sとか短い名前を付けるのが良さそう。

_ [Ruby] Ruby Refactoring - Trac

Rubyのためのリファクタリングツール。

実際に使ってはいないが、ドキュメントを読んだり スクリーンキャストを見たりする限りでは結構いろいろと リファクタリングを自動化できそう。

私自身はEmacsでバリバリと書いちゃって、 リファクタリングツールなんて使わないオールドタイプだけど、 それはそれとしてリファクタリングツールがあるのは良いことだ。

_ masuidrive on rails >> Blog Archive >> masuidrive的プロジェクトの方針

あー、こういう風なソフトウェア開発っていいなあ。

って、今でも好き勝手に開発してるんだから、 こういう風に開発できるようにすればいいのに。

そうか、私はチーム開発が圧倒的に苦手だから、 こういうスタイルの開発をまともにしたことがないのか。 それはそれで反省したり、いろいろ考えたりすべきことだろう。

でも、こういうのをTracよりももっと積極的に支援するツールって あったらうれしいんじゃないかな。それともTracで十分?


2007年07月14日 [長年日記]

_ [Ruby] Ola Bini on Java, Lisp, Ruby and AI: A JRuby Rubinius machine

JRubyでRubiniusのバイトコードを実行する、という話。 フィボナッチ数の計算でMRI(Matz's Ruby Interpreter)より30%高速だとか。

フィボナッチ数の計算がどれだけ意味があるかは未知数だが、 まあ、限定された局面でも私のインタプリタよりも高速だと言うのは それなりにすごいことだと思う。

ところで、JRubyはこないだYARVのバイトコードも実行可能だったような 気がするんだけど、なんなんだろうね、このパワーは。

_ [言語] Running C programs on a Lisp OS

Cはしばしば「高級アセンブラ」とか「移植性のある低級言語」と呼ばれて CPUをそのまま操作できるような気がするけど、 一昔前に一世を風靡した高級言語マシン(たとえばLispマシン)では、 Cの実行モデルをエミュレートするのはそれはそれは大変なことである、という話。

つい、日常的によく接する環境が普遍的だと考えてしまうけど、 そのような「狭い世界の常識」が通用しない世界はいくらでもあるということ。

もっとも、最近ではアーキテクチャの寡占化が進んで、 そういう意味での多様性は減ってきているけどね。 なんか、どのCPUもx86っぽいし。

でも、制約が厳しい時代こそそれを乗り越えようと多様化が進む傾向があるから、 ハードウェア技術の進歩によって多様性が減った現状から、 物理法則の限界に苦しむようになる未来では、 また多様性が増加するかもしれない。

それはそれで面白い時代だと思う。

_ [Ruby] The Ruby VM: Episode IV

Ruby VMインタビュー第4弾。今度はM17N。

ささだくんはこの件について解答を拒否したので(彼は賢い)、 今回は私だけ。

_ [Ruby] InfoQ: Wiki-style GUI Layout with Profligacy and LEL

WikiっぽいインタフェースによるGUIレイアウト定義。

Wikiっていうよりも Perlのformatを連想させる。 Rubyでボタンオブジェクトなどを生成していくよりは、 GUIの定義が簡単かもしれない。

_ [言語] Ask Reddit: If you created your own programming language what would you put in it? (reddit.com)

「あなたがもし新しい言語をデザインするならなにを入れる?」という質問。

「新しい言語なんて作っちゃいけない」というものもあれば、 「高速GC」とかのような実装よりのものとか、 「型推論付きのオプショナルな静的型」という気持ちはわかるが無茶な希望とか、 さまざまである。

_ [Ruby] InfoQ: The Beauty of Ruby

昨年のJAOOにおけるGlenn Vanderburgの発表。 英語だし時間も長い(55分)もあるので見るのも大変だが、 「Rubyの良さ」について真摯に語ってくれている。

リンク先はページを開くといきなりビデオが始まるので注意。

スライドとビデオがシンクロしているのが素晴らしい。 どうやってこういうの作るんだろう?

_ お見舞い

昨日、実家の母が床に落ちてた新聞広告を踏んで転倒。 脊椎を傷めて入院したと父から電話。

さっそく息子を連れて病院へ。 他の子供たちはいろいろと都合が悪かったのだ。

口は達者だが腰が痛くて起き上がることもできないのだそうだ。 そういえば、つい先日、妻も同じ状況で転んでいた。 転び方が良かったのか彼女はほとんど被害がなかったけど。 足元には注意したい。


2007年07月15日 [長年日記]

_ [教会] 初期のキリスト教会

聖餐会は司会。

日曜学校は教師。今日のテーマは「初期のキリスト教会」。 イエス・キリストの時代の教会がどのような組織と運用であったかを 新約聖書の記述から学ぶというような話。

断片的な情報しかないので確定的なことはなかなか言えないのだが、 それでも結構なことがわかる。どんな役職があったのかとか、 どんな運用をされていたかとか。

はっ、また講義調になってしまった。


2007年07月16日 海の日 [長年日記]

_ ピアノ発表会

息子のピアノ発表会。 次女は今年は辞退した。吹奏楽部とピアノ練習の両立はできなかったらしい。

で、息子だが、まあ失敗もあったが頑張りました、という感じ。 彼の努力を知っているので素直にほめてやりたい。 私が楽器のたぐいが一切ダメで、息子はもうちょっとマシになってほしいと 願ってピアノを習わせているわけだが、難しいこともあるのに 頑張ってくれているのがありがたい。

えらいね。

若い時にリアルタイム処理を体に覚えさせておくことは良いことだと思うよ。

_ 筑波移動

明日からの講義に備えて、米子空港から東京へ。 途中、病院によって母のお見舞い。

その後、羽田→秋葉原→つくばの順に移動。 ホテルオークラへ。今年は本館。


2007年07月17日 [長年日記]

_ 筑波大学 集中講義 「プログラミング言語の設計と実装」 (1日目)

今年で三年目になる母校での集中講義。 なんでも同じ内容の集中講義は3年までなのだそうで、 今年が最後になる。

一日目の内容は「プログラミング言語の設計」。 自己紹介から始まって、プログラミング言語の歴史や 発展の経緯など。また、「良いプログラミング言語」を判定する基準など。

一日目のレポートは「20年後のプログラミング言語像を予想せよ」というもの。 例年通り面白い内容のものが多かったが、 講義の中で「プログラミング言語の進化は遅い」とか繰り返し述べたものだから、 「20年経っても変化しない」と予想した人が思ったよりも多かった。

しかし、いくら言語の進化が遅いからと言っても、 20年と言うのはそれなりに長い期間で、まったく変化しないってことはないと思うよ。

いずれにしても、大変楽しい経験であった。 が、休憩時間を除いてほぼ5時間、立ちっぱなしで話し続けるのはしんどいよ。 とてもとてもくたびれた。

_ [言語] (The Scheme Way): The recruiting secret weapon

リクルートの条件に「Scheme」と書いたら、 他だったらとても自分のところに来てくれなそうな優秀な人材が応募してきた。 マイナーな(でもとんがった)技術をもって募集するのは採用の秘密兵器になるかも、 という話。

そうなのか。

しかし、最近の応募状況を考えると、 「Rubyで仕事ができる」とか「Ruby開発者と仕事できる」くらいでは もはやあまり強力な秘密兵器にならないように思う。

これはNaClもSchemeに移行するしか(嘘

_ 第2回 「小成功病」が経営者を蝕む:ITpro

企業が「とりあえず」のところまで成長してしまうと 安住してしまって、成長が止まってしまう(おそらくは無意識のうちに)、という話。

NaClとかもそういう地点に到達しているのかなあ。 RubyやRailsを起爆剤に次のレベルに大きく伸ばすのか、 無茶せずに少しずつ着実に成長することを考えるのか。


2007年07月18日 [長年日記]

_ 筑波大学 集中講義 「プログラミング言語の設計と実装」 (2日目)

集中講義、2日目。今日は「プログラミング言語の実装」。

今日は言語処理系の典型的な構造や実行環境などについて。 字句解析、構文解析、最適化などの基本的な部分や、 仮想機械やガーベージコレクションについても説明する。

昨日はプログラミング言語概論という感じで 「お話」としても聞ける内容だったと思うのだが、 今日はいきなり実装の詳細部分まで踏み込んだのでかなり難易度が高かったように思う。 難しいと思った人はごめんね。

今年も昨年同様、実際に学生さんに前に出てもらって、 ガーベージコレクションを実地で体験してもらった。 リファレンスカウント、マークアンドスイープ、ストップアンドコピー、 それとジェネレーショナルの各アルゴリズムについて 実際に体を動かして学んでみた。

学生さんからは「オブジェクトの参照関係が見えにくかった」という指摘があったのだが、 これはある程度わざとである。 というのも、コンピュータにとってオブジェクト間の参照関係は鳥瞰的には見えない ので、いちいちオブジェクトを覗きに行かないとわからないからだ。

まあ、自分でGCアルゴリズムをデザインする機会はまずないだろうけど、 各種処理系のGCがどういうアルゴリズムで動いているか把握しておくことは 役に立つこともある、かもしれない。

集中講義はこれでおしまい。三年間やってみたけど、 三年目が一番うまく行ったような気がする。

来年もやりたいか、と聞かれると、ビミョー。

_ [言語] Whoever does not understand LISP, is doomed to reinvent it. | Lambda the Ultimate

Lispのことをわかってない人は、結局Lispを「再発明」する破目に陥る、という話。 グリーンスパンの第10法則ふたたび。

まあ、RubyだってLispの再発明であると言えないことはないわけで、 それは認めちゃうんだけど、とはいえ、じゃあ、Lispが再発明も要らないほど 素晴らしい言語かっていうと、ちょっと疑問がある。

「Lispファン」にはまったく見えないが、 そうでない人には障害になる「なにか」が確実に存在して、 再発明されたRubyとかが(Lispよりも)人気があるのは その「なにか」成分が少ないんじゃないかと。

ということは、再発明したのも無駄じゃなかったんじゃないかと思う。


2007年07月19日 [長年日記]

_ [言語] :gnuvince.net >> Blog Archive >> My 5 things I hate about Python

私がPythonで嫌いな5つのこと。

  1. listにdictのget相当(範囲外でNoneを得る)がない
  2. (x)rangeが終端を含まない 「for month in xrange(1,13)」とか
  3. (Cの)static変数相当がない
  4. メソッドだったり関数だったり。len()とかsort()とか
  5. lambdaが1行式しか書けない

まあ、大したことないって言えば大したことない。 逆にいうとそれ以外は嫌いじゃないってことだものな。 インデントの件は含んでないし*1。 この人は実はかなりPythonファンだと思う。

しかし、コメント欄ではそれらに対してかなり厳しい反論が付いている。 「真の」Pythonファンは、そのような批判に対しても反論せずにはおれないようだ。 いや、Rubyファンにもそういう人は多そう。

他山の石。

*1  コメント欄でインデントが消えてるサンプルコードがあるのが、(私から見ると)皮肉っぽい

_ Slash7 with Amy Hoy - Help Vampires: A Spotter's Guide

海外版「教えてクン」、その傾向と対策。

洋の東西を問わず、そういう人たちは居るのね。 でも、このエントリではそういう「Help Vampire」を 救済しようとする試みも含んでいる。

_ [言語] Buran Composition on-board computer

ソビエト版スペースシャトルであるBuranに搭載されている コンピュータは完全にオリジナルなものであったが、 彼らはそのためにBuran用の新言語、Prol-2とDipolと、 データ記述用言語Floksを開発した、という話。

ロシアの技術は侮りがたし。 コストを度外視した開発は時として驚くべきものを産み出す。 これも一種の蠱毒か。

_ [Ruby] IronRuby and Ruby.NET: The Differences and Benefits of Both

最近話題のIronRubyと、最初の実用的な.NET上のRuby処理系であるRuby.NETの違いについて。

  • IronRubyはDLR上で動く
  • Ruby.NETはCLR上で動く
  • IronRubyはRuby.NETのパーザーで動く
  • Ruby.NETは1.8.2添付のライブラリが動く。
  • IronRubyは現時点では機能的にまだまだ

_ [Ruby] まめめも - 高速 Bignum#to_s

桁数の多いBignumのto_sをkaratsuba系アルゴリズムを利用して Rubyで実装し直したらより高速になったという話。

Rubyの実行コストを考えると驚異的な話だと思う。 いや、ただ今使ってるアルゴリズムが効率悪すぎ、という話なのだが。

が、正直、アルゴリズムの説明を読んでもよくわかんなかった。数学苦手。

だれかCで実装し直してくれないだろうか。 喜んで取り込むから。イヤじゃなかったらChangeLogに名前を刻みこむから。

他力本願。

_ [Ruby] よしみ視点 - Ruby開発者:まつもとゆきひろ氏の集中授業

本題は私の集中を受けそこねた、という話なのだが、

野村総研、検索語に関連の深いキーワードを連想する「連想検索エンジン」を開発 インターネット-発表資料:IT-PLUS

この検索エンジンは、Ruby(正確には、Ruby on Rails)で開発されています。

というリーク(?)が。NRIがRubyに興味を持ってる話は知ってたけど(社内講演会もしたし)、 こういう風に使うとは知らなかった。


2007年07月20日 [長年日記]

_ 上京

朝の飛行機で東京へ。

まずは品川のソニーで打ち合わせ。 近いうちにソニーの中で講演会をしようという話。

ソニーくらい大きいと社内だけで立派なイベントが開催できるんだねえ。 私の前に呼ばれた講師が世界的なビッグネームたちで(確証が持てないので名前は非公開)、 思わず遠慮しようかと思ったのだけど、そこは説得されてしまった。

_ 楽天技術研究所

で、次に六本木に移動して、午後は楽天技術研究所でのミーティング。

今までのサーベイをもとに今後の方向性について考える。 あまり非現実的で実現できないのも困るが、 かといって「(誰でも)やればできる」というような、 簡単(に見える)ものでも困るということで、悩ましい。

が、方向性は見えてきたかな。

途中はともかく、最終成果はオープンソースにできるように念を押す。 好感触である。

あと、楽天名刺ができたので、名実ともに「楽天の中の人」というイメージが強くなった気がする。

最後に「楽天、システム開発拠点を国内主要5都市に分散化へ」というニュースを受けて、 このあたりの泥臭いことでもお手伝いできそう、という話になる。

_ なぜ楽天か

で、この辺で「なぜ私が楽天フェローを引き受けたか」についてちゃんと書いとこうと思う。

とはいえ、最大の理由は「縁」なのだが、 より具体的には以下のようなことが理由である。

  • 最初のオファーであった。

    楽天は私に対するこの種のオファーの中で最初のものであった。 楽天との契約にはある種の排他条項があるので、 今後、無制限にフェローを引き受けることはできない(しない)。

  • 私の活動を制限する意図がない

    もちろん、東京でのミーティングが発生するので まったく制限がないわけではないが、 基本的に私の最優先事項である「Rubyの開発」を疎外する意図が全くない ということを終始明示してくださった。

  • 補完関係が成立した

    私が楽天にないもの(プログラミング言語とオープンソースに関する技術と経験、 そっち方面での知名度とコネクション)を提供でき、 逆に楽天も私にないもの(エンタープライズソフトウェア開発の経験と実績、 大規模トラフィックとデータ、ビジネス領域での知名度とコネクション、人材、 あと、お金ww)を持っている。協力により相互に利益が得られることが期待できた。

  • 日本から世界へ

    私の方はあんまり気にしてないんだけど、楽天としては「国産言語」という点に 注目してくださったみたい。 私としては尊重してもらえるのはありがたい。

_ [Ruby] Heap fragmentation in a long running Ruby process ,A+ Open Source Teddy Bears

長期間起動したままのRubyプロセスがメモリフラグメンテーションを起こして 大量のメモリを消費してしまうことがある、という話。

RubyのメモリアロケータはOSのmallocに頼りっぱなしでフラグメンテーションを 回避するような工夫はなにもしていないから、そういうこともありえるかもしれない。 ただし、この話には続きがあって、問題はRubyのアロケータのせいというよりも glibcが採用しているptmalloc2に原因があったらしい。

より新しいバージョンであるptmalloc3をリンクしたら、問題は解決したとか。

_ [言語] coding, by Derek Young: The Curse of The Elegant Languages

the amount of good software written in a language is inversely proportional to the elegance of that language.

ある言語で記述される優れたソフトウェアの数は、その言語のエレガントさに反比例する

という仮説。

その根拠はRubyにはDrupalのような良いCMSが見当たらない、というもの。 言語デザイナーの努力はなんなの、と思わせるような仮説である。 世の中はBASICに戻った方がよいんじゃないの、とか毒をはきそうになるけど、 我慢、我慢。

そういえば、Ruby(とRails)で記述されたCMSとかはあんまりたくさんは見かけないよね。 少なくともまだ「定番」といえるようなものは登場していない。 でも、それはRubyのエレガンスさとは無関係で、 みんな、RailsのCRUDで実現できるような「エンタープライズシステム」作成に 夢中でCMSに手が回らないからじゃないかぁ。


2007年07月21日 [長年日記]

_ お見舞い

今度は妻と息子と末娘を連れてお見舞いへ。 姉たちはやはり部活。

コルセットが効果を発揮して、すいすいと歩けるようになっていた。 外すとまだグダグダだそうだが。見かけ上かなり健康そうに見える。

_ 人気のAPI/フレームワークを作るための39カ条 - @IT

39は多いので全部は紹介しないけど、 これはAPIとかフレームワークに限らず、ソフトウェアデザイン全般に有効であろうと 思うものがほとんどであった。

少なくとも言語設計には応用可能である。 まあ、考えてみれば、言語を構成するものは 文法とライブラリであるが、割合としてはライブラリ(つまり、API)なのであるから 当然と言えば当然か。

_ [Ruby] やむにやまれず:Rubyは遅いから使えるのです

Rubyを使うのはその柔軟性や生産性のためで、 他の言語でそれを達成するためには、結局自分でそれらを実現しなければならない。 野良フレームワークでそれを実現しようとすると

  • 一人(or 少数)で作っているから、品質が高くならない
  • パフォーマンスが目的で野良を選んだはずなのに、結局、だんだんパフォーマンスが低下する

破目になってしまいがち。つまり、Rubyが遅いのはそれなりに理由があるということ、という話。

実際にはRubyが遅いのには別の理由(まつもとの能力の限界)もあったりするんだけど、 それはそれとして、グリーンスパンの第10法則というのはそうやって あちこちで繰り返されるんだねえ。

_ スターロジック,人月商売の悪弊がはびこるSI業界に成果物価格で挑戦 - ものづくりとIT - Tech-On!

顧客にマジカで分析してもらって、タスクカード1枚8万円と言う値付けで開発する というビジネスモデルを採用、もう人月モデルには戻らない、という話。

諸悪の根源は見積もりの不確定さだと思うので、 顧客によるある程度の分析が行われることで、見積もりの確度が上がれば、 人月モデルとサヨナラできるのかもしれない。

予想される問題は、このビジネスモデルは「顧客の怠惰さ」を過小評価している点ではないか。

SI屋: まず、業務を分析してください。その結果のタスクカード1枚ごとに8万円で開発します。

顧客: えー、分析ぃ? めんどくさい。そんなにコストがかけられないから開発をお願いするわけで。分析も設計もそっちでやってよ。

これもまた、見積もりの問題である。


2007年07月22日 [長年日記]

_ [教会] 遅刻・赦し

いろいろと思うように行かなくて、 教会の駐車場に入った時点で10時であった。 集会スタートが10時なので、厳密には遅刻である。

今日は司会のはずだったのに。

ビショップにお願いすることになってしまった。 ごめんなさい。

日曜学校は現代の教会について。 現代の教会の組織と運営の概要について。

神権会は「赦し」について。

昨年の秋に起きたアメリカのアーミッシュコミュニティで発生した殺人事件(少女10名が人質になり、結果的に5名死亡、5名重傷、犯人は自殺)において、 アーミッシュの人たちが、犯人も犯人の家族も許し、 葬儀に犯人の家族を招待し、 被害者のために集まった寄付金の一部を分け与えた、という話。

最近、悲惨な事件の犯人を「決して許さない」とする遺族の人が多い。 気持ちは理解できる(私も家族が殺されたら、そう感じないとは限らないし)。 日本の社会は、この「不寛容」を許容している(むしろマスコミとか後押ししてる) ように思える。

しかし、いくら怒っても、犯人が死刑になっても、被害者は帰ってこない。 クリスチャンは、このような事態にあって、「赦すこと」を勧めている。 一見、不自然なようだが、これこそが平安を招く態度だと思う。

私は赦す勇気を持つ人たちを尊敬する。

もちろん事件の再発は防ぐ努力が行われるべきであるが。


2007年07月23日 [長年日記]

_ ITmedia +D LifeStyle:「1世代コピー9th」では誰も幸せになれない

なんだか新しいアクションを取れば取るほど、墓穴を掘っているような気がする。 もう日本の(TV系)メディアの未来に関して希望は持てないな。

前から宣言しているように、4年後に地デジ完全移行になれば、 私はもう(放送受信装置としての)テレビを捨てるし、 HD画像も要らない。

正直、HD画像はきめ細かくて情報量は多いんだけど、 カメラがパンする時とかに、車に酔ったような気分になるので、 全然うれしくない。

ネットから情報を得るか、アナログにダウングレードしてから見るから、 こういう新しい(消費者不在の)テクノロジーたちは、 私の知らないところで勝手にやっててほしい。

_ [言語] CodeZine:L2Lisp in Ruby(インタープリタ)

オリジナルはPascalで記述されたLispインタプリタを Rubyで再実装したもの。 手軽っぽくてLispの孝三構造を理解するのに良さそうだ。

でも、出自を考えると、どうしてPythonでないのかというのは疑問である。

_ [Ruby] 日記的な - multipart時のCGIライブラリの挙動

Rubyのcgi.rbはリクエストボディのサイズが10Kを越えると パラメータとして文字列でなくStringIOかTempfileを渡す。 それが使いにくい(ので直してしまおう)という話。

正直、Rubyのcgi.rbは古めかしいし、この件をはじめとして あちこち使いにくいことが残っているので、 捨ててしまいたい。

問題は適切な移行パスが思いつかない点だ。

世の中はほとんどRailsだからcgi.rbはさほど使われていない(から、どう変えても問題なし) だとありがたいんだが、世の中そうは甘くないだろうな。

_ [Ruby] Dr Nic >> Magic Wiggly Lines => GuessMethod, by Chris Shea

特にirbの中で用いることを想定したスペルチェック付きメソッド呼び出し。

$ irb
> require 'rubygems'
> require 'guessmethod'
> class Object; include GuessMethod; end
> class Product; def name; "Some product"; end; end
> Prodct.nw.nae
attention: replacing non-existant constant Prodct with Product for Object
attention: sending new instead of nw to Product:Class
attention: sending name instead of nae to #<Product:0x144ff10>:Product
=> “Some product”

以前からNameErrorでスペルチェックを行う「もしかして」機能付エラーメッセージ というのを夢想していたのだが、こちらは警告付きで実行してしまう というより大胆なもの。しかし、インタラクティブなirbセッションの中であれば、 冷酷にエラーにしてしまうよりは「こういう風に解釈しましたよ」とのメッセージ付きで 良きに計らってくれた方がありがたいかもしれない。

_ [言語] IT Conservative: 10 Years of XML: Global Warming

XMLは誕生以来ほぼ10年になるが、その結果は地球温暖化ではないか、という話。

つまり、XMLはシンプルではあるが非効率である。 CPUサイクルやネットワーク帯域を少しずつ無駄遣いしている。 そして、その消費されたエネルギーは地球温暖化(Global Warming)の原因の一つかもしれない。 アル・ゴアはこの件についてドキュメンタリーを書くべきではないか。

いや、CPUサイクルの無駄遣いに関しては、我らスクリプト言語も同罪だな。

_ [Ruby] New Ruby Profiler Released: Supports Rails, threads, IRB, and more

新しいruby-profでは

  • 再帰的メソッド
  • Rails
  • スレッドアプリケーション
  • IRBからの呼び出し
  • 64ビットCPU

をサポートしているという話。Railsアプリのプロファイルとかは嬉しい気がする。


2007年07月24日 [長年日記]

_ [Ruby] Rubyをビジネスに活用へ、40超の企業が集まり新団体:ITpro

Rubyビジネスコモンズの設立。

Rubyアソシエーションの設立と時期が前後するため、 ややわかりにくいが、対象が結構異なるため、 「中の人」の眼からは競合しないと思ってる。

  • ビジネス分野における「Rubyの安心感」の達成を目指し、 (開発)コミュニティとビジネス界(とそこからのお金)の関係構築を目指す Rubyアソシエーション
  • ビジネス分野におけるRubyコミュニティ構築を目指すRubyビジネスコモンズ

という感じか。 共通するのは「Rubyビジネスはじまったな」という点くらいだと。

ま、競合するくらいならRA理事長たる私がRubyビジネスコモンズ設立総会に呼ばれたりしないよね。

_ [OSS] Open Tech Press | Nintendo DS(Lite)でオープンソース系ソフトウェアを使用する

Nintendo DSをコンピュータとして考えると、 めちゃめちゃ低価格でそれなりのパフォーマンスがある。 バッテリーも長持ちだし。

とりあえず息子のDSを借りて試してみるかな。 このサイズと価格ならPDAの代わりになる、かも。いや、やっぱ難しいか。 最初にメモリカードリーダを買わないといけないのかな。

_ [OSS] オープンソースで「永く使える安心」を守るために:ITpro

製品ベンダーによって狙いは様々だろうが,OSSの開発企業やコミュニティを取り込もうとする動きが活発化するのは必至だ。その中で,いかに開発コミュニティを維持していくか。OSSも属人的な人のつながりに依存したままでなく,組織運用力が問われる時代になったと言えそうだ。

古くからオープンソース/フリーソフトウェア開発に関ってきたものとしては ビジネス論理はちょっと「イヤな感じ」がするのが正直なところだが、 企業の論理も理解できる。

Rubyアソシエーションの設立は まさにそこを埋めるためのものだ。

_ [言語] The Broken Metric of Intuitive to the Uneducated Language Syntax - O'Reilly ONLamp Blog

初心者に理解しやすいため、プログラミング言語の文法は プログラミング経験のない人にも分かりやすいものでなければならない、 という指標は間違っている。なぜなら文法(シンタックス)は意味(セマンティクス)ほど 重要ではないからだ、という話。

が、セマンティクスの違いというのは、 「普通の言語」とProlog、HaskellやErlangのような場合であって、 「普通の言語」の間では、文法の違いはそれなりに重要だと思う。

もっとも、「初心者向けである必要はない」という点では同意するのだが。

_ [Ruby] InfoQ: Rubinius Internals: Threading, ObjectSpace, Debugging

Rubiniusについてのインタビュー、続き。

最近、JRuby界隈でも話題になっているThreadingやObjectSpaceについて。 Rubiniusにはそれらについての問題はあまりない、とのこと。 完全に独立したmachine(MultiVMのこと)を作るのは簡単だし、 それらを独立したnative threadに割り当てたり、channelを通じて相互通信したりできる。 また、メモリ管理は自前でやっているのでObjectSpaceの問題もない。

あと、バイトコード置き換えのテクニックを使ってパフォーマンスの劣化なしに、 ブレークポイントが使えるというのも魅力的である。 もちろん、RubiniusはMRIやJRubyと比較して完成度という点ではまだまだだが、 なかなか希望のあるビジョンを提示している。

っていうか、YARVも高速ブレークポイントやプロファイリングについて考えないとな。 確か、ささだくんが取り掛かるとか言ってたような。

_ 情報科学類案内

私の母校、筑波大学の情報科学類のパンフレット。 いつの間にか学類の名前が変わっている(情報学類→情報科学類)。

先輩からのメッセージ」というところに、観たような顔の人が...。


2007年07月25日 [長年日記]

_ 採用面接

普段なら採用面接を担当してる前田くんが 外せない用事があったということで、私ともう一人で採用の技術者面接を受け持つ。

で、FizzBuzzにヒントを得て紙の上に簡単なプログラムを書くという問題を 2問ほどやってもらう。緊張したのかちょっと的外れな解答もあったけど、 さすがに全然プログラムができないってことはなさそう。

っていうか、日本での面接で全然プログラムできないプログラマ候補に出会ったことないんだけど、 それはやっぱりエンジニアの地位が高いアメリカ固有の事情なのだろうか。

日本でのエンジニアの地位なら、できるフリをして潜り込む動機がないものね(自虐的)。

いずれにしても、わずかな時間で人を判断できるだけの情報を集めるのは 難しいものだ。書類での情報と実際会って得られる情報はまた違うし、 そのいずれもが「本当の人となり」を表しているとは限らない。

難しいものだ。いずれにしても、もっと人が欲しいなあ。

_ ITpro Challenge!

というイベントが開催されるそうだ。

プログラマーの挑戦が世界を変える
ハッカーの流儀がメインストリームになる

のだそうだ。本当かな。

まあ、いずれにしても著名人たちの話が聞けるのは貴重な機会であろう。 定員が限られてるみたいだけど。70名は少なすぎるなあ。

  • 江島健太郎
  • 鵜飼文敏
  • 伊藤直也
  • 戀塚昭彦
  • 小飼弾

私はちょうど同じ日にX-Devに呼ばれてるから 顔を出すくらいはできるかもしれない。

_ UTN #27: Known anomalies in Unicode Character Names

Unicodeに間違いがあるって知ってた?

まあ、9万以上も文字があれば間違いがあるのも無理はないかもしれない。 しかし、どのような経緯でこんな間違いがまぎれ込んだのか、 むしろ、その辺が知りたい気もする。


2007年07月26日 [長年日記]

_ [教会] YWキャンプ

若い女性のキャンプに娘たちを送っていく。 今年は船上山で、例年よりも近い。

船上山というのは後醍醐天皇関連の史跡なんだねえ。 知らなかった。

_ 打ち合わせ

明日のイベントに備えて打ち合わせ。 正直、打ち合わせは面倒だが、まあ、重要なイベントなので。

_ Geek to Live:「できる」ToDoリストの作り方 - ITmedia Biz.ID

ToDoリストのエントリの抽象度があまり高いと 実行できない。細かく分割し、部下への指示であるかのように書き下すと 達成率が上がるという話。

まあ、実際には私はそういうレベルにさえ届いていないのだが。 とりあえず今日の仕事は手元のA6ノートに書き出すことで達成できているのだが、 何日にも渡るような長めのissueは忘れてしまうこともしばしば。

なんかツールの支援が必要だと思うのだが、 Remember the Milkもどうも定着しないんだよなあ。 なにがいけないのかなあ(たぶん、意識の低さ)。

_ [言語] SLiP - a Sorta Like Python shorthand for XML

XMLのPythonっぽい表現。 ドキュメント表現としてのインデントはそんなに嫌いじゃない(YAMLとか)ので、 SLiPもなかなか良いんじゃないか、と思う。

ただねえ、こういうXMLの別表現はなかなか定着しないんだよねえ。 結局、

  • XMLは結局誰も読まないから、フォーマットを読みやすくする改善に対するインセンティブが弱い
  • 新しいフォーマットには新しいライブラリが必要で、その導入はそれなりに面倒

ということなんだろう。

こうして地球温暖化が進んでいく(いや、もちろん冗談だけど)。


2007年07月27日 [長年日記]

_ [Ruby] Rubyの普及促進を図る「Rubyアソシエーション」発足,まつもとゆきひろ氏が理事長に:ITpro

島根県庁で記者会見。 選挙時期の地方での地味なプレスリリースであるにもかかわらず、 テレビ局が2局、新聞が3社も来てくださった。

プレスリリース本文はNaClに置いてある

夕方のテレビニュースで放映されたらしい。私自身は見てないけど。

_ [OSS] OSSサロン

夕方からは月に一度のしまねOSS協議会によるOSSサロン。 今月は楽天技術研究所代表の森さんによるサードリアリティの話。 あと、楽天の技術開発の方向性とか。

楽天の名は島根でも知れ渡っており、知名度のおかげか聴衆も非常に熱心に聞き入っていた。 森さんのプレゼンがうまいのもあるけど(今日は二日酔いではないそうだ)。 ここ1年、毎月OSSサロンを開催してきたけど、ベストに近い盛り上がりではないだろうか。

_ ITmedia エンタープライズ:まつもとゆきひろのハッカーズライフ:第5回 ハッカー環境問題 (1/2)

以前、私が『オープンソースマガジン』に書いた原稿の再配布。

ところで、元原稿で「パソコン」と書いたものがすべて「PC」に置換されているんだけど、 これはなにか理由があるんだろうか。内規とか。一部、意味が通らなくなってるんだけど。

_ retrospectiva

増井さんから紹介されたissue tracking system。

Ruby 開発チーム用のissue tracking systemがほしいんだけど、 やっぱ定番のtracがよいのか、それともredmineがよいのか、 retrospectivaがよいのか。あるいは自作するか。

要求からして考えてみよう。 まあ、ちゃんとしたチケットシステムがあればなんでも良いのかもしれないけど。 後、重要なのは結局ツールに対する習熟度なのかもしれないし。

_ [Ruby] Why Ruby on Rails Succeeded - CIO.com - Business Technology Leadership

「the Ruby Way」のHal Fultonによる「なぜRubyは成功したか」についての分析。

  • Born from Real-World Needs (リアルワールド)
  • An Overarching Philosophy (フルスタック)
  • Technical Excellence Isn't Enough (マーケティング)

だそうだ。やっぱ、マーケティング重要だよな。 自分が地味でマーケとは正反対なんで、特にそう思う。

私の性格を反映してかRuby Associationも地味だし。 それに比べると...(後述)。

_ ITエンジニアの「性格改造」!? 人が集まる技術講習会の秘密

講習会っていうか、これだと「なんとかセミナー」のようだな。

って書くと悪い印象を与えてしまうようだが、 実際問題、技術を中心に問題解決の実践できるようしむける、という意味では 価値があるのではないかと思う。

とはいえ、かなり体育会系ノリなので、 私(や、私の同類)が付いていけるか、自信がないんだけど。


2007年07月28日 [長年日記]

_ [Ruby] RubyConf 2007 Presentation Proposal

募集開始されましたよ。もうそんな季節なんだねえ。

今年は東海岸で精神的距離が遠いけど、 今年も出席しようという強者はいるかな。 規模とかの話はまだ聞いてないけど、 昨年(350強)よりは多いんじゃないかな。

あんまり大きくなってもらっても、しんどいけど。

今年のキーノートはLL魂のLanguage Updateフルスケール版、 というのはどうだろうか。> ささだくん

_ [言語] Most Popular Web Languages / Frameworks

調査機関Gの結果によると

  • ASP.NET: 86 million (8600万件)
  • Ruby: 101 million (1億100万件)
  • PHP: 2.95 billion (29億5千万件)

で、PHPダントツである、という話。 もっともPHPプログラムはindex.phpというファイルを使う傾向があり、 それがカウントされている可能性があるので公平ではないのではないか、との指摘あり。

フレームワークでは

  • Symfony: 4.6 million (460万件)
  • CakePHP: 4.8 million (480万件)
  • Ruby on Rails: 5.4 million (540万件)

で、極端な差はないものの、Ruby on Railsの勝利。

_ [言語] Python 3000 FAQ

もうPython 3000が近いということで登場したGuidoからのFAQ。 Python 3000の冒険度合が下がってしまった今となっては、 (野次馬的視点からは)あんまり面白くはない。

lambdaやmapやfilterは残るのにreduceはなくなるのね。

_ [Ruby] Tiresome, Tedious Bullshit (on Rails)

システムの規模が大きくなるにつれて、 Rubyによって向上する生産性よりも、低下する保守性の方が問題になるのではないか、 という話。

私自身はそのような規模のソフトウェアを開発したことがないのでなんとも言えない。

が、周りから聞くことから推測するに、ある程度以上の規模のソフトウェアを開発することは それがどんなツールであっても大変である。ので、

  • 分割してしまって小さなシステムの集合にしてしまう
  • 開発プロセスを厳密に定義し、開発要員に徹底する

のいずれか、または両方が必要なのではないだろうか。 また、そのような対策が十分たてられない状態では、 静的型はある程度有効だろうが、真に信頼性の高い、複雑なシステムを作るための (カバレージの高いテストを含む)プロセスがあるのであれば、 動的型の問題は顕在しないのではないだろうか。

しかし、「それは理想だ」ということなんだろうか。


2007年07月29日 [長年日記]

_ [教会] イエス・キリストを信じる信仰

司会。

日曜学校は福音の第一原則のひとつ、 イエス・キリストを信じる信仰について。 あるいは、信仰という言葉が局面ごとに持つさまざまな側面について。 っていうか、聖書は技術書じゃないんで、 同じ単語が文脈ごとに違う意味を持ったり、 あるいは一つの概念の違う側面が強調されてたりして、 それも理解を妨げる要因のひとつだったりする。

まあ、公称数千年かけて書かれた書物だから。

_ 選挙

参院選挙。 私と妻は、期日前投票をすませておいたのだが、 どうも予想外の動きになりそうだ。

しかし、郵政民営化以外の点で自民党と政策的違いはほとんどなさそうな 国民新党の候補を応援してしまう民主党のポリシーはよくわからない。

将来、所属政党が自民党と合流するようなことになれば(郵政問題で妥協が行われれば可能性は十分にある)、 結果的に民主党と対立することになると思うんだけど。

敵の敵は味方、ということか。


2007年07月30日 [長年日記]

_ 選挙結果

結果として自民大敗ということらしい。

まあ、その辺は流動的なものだから、どうでもいいんだけど。 人気商売は大変だなあ。

で、政治方面には疎くて理解できないことが沢山あるんだけど、 今回、一番理解できないのは、選挙に大敗したから 総理は責任をとって辞任、総選挙で国民に信を問うべきだ、 という意見が自民党から出る、という点。

現在、与党は自民・公明合わせて衆院の2/3を占める圧倒的有利な状態である。 まあ、以前の小泉人気のおかげだけど。

で、参院選挙に大敗して過半数を割り込むような状態で 選挙に望めば、またもや大敗して衆院でも現在の勢力を失い、 かなり高い確率で政権政党から脱落することが予想される。

解散することで国民に真を問うたことに対して、 潔いと感じてくれる人もいるだろうが、選挙結果を逆転するほどのものではない(と思う)。 それならば、なんと言われても任期中は政権を維持して、 なすべき事をなし、その結果で評価してもらうことが、 与党としてなすべきことではないのだろうか。

結果が出なかったらそれまでだが、その場合はどうしようもないということで。

この件に関して(だけ)は、首相の判断に共感できる。

首相に反発する自民党の人は、選挙に負けようが、政権を失おうが、 「責任は取った」と言えればそれでいいのかな。 サムライの潔さがなによりも優先するのかな。

_ [言語] 37 Reasons to Love Haskell (playing off the Ruby article)

Rubyについて古典的な記事『Thirty-seven Reasons I Love Ruby』(2000年)の「37の理由」はHaskellでも成立する、という話。

となると、Rubyが好きな人は(少なくともこの基準に従う限り)Haskellも愛さねばならない ということになるが、実際はそうとも限らない。少なくとも私は(現時点では) Haskellを愛せない。

では、38番目の理由があるはずだが、それはなにかと考えると、 Haskellみたいな言語だと宣言的なスタイルが思いつかないと とたんにどうしたらいいのかわからなくなる。

ということは、つまり....手続き型脳の恐怖?

_ 福岡へ移動

出雲から夕方の飛行機で福岡へ。

一度自宅に帰るつもりだったのに、会社での作業が長引いて 時間がなくなったので、空港へ直行。 おかげで着替えを取ってこれなかった。

仕方がないので、福岡で着替えを購入しようと思ったが、 土地勘がないので、買い物する場所を探すのに不自由する。 ネットできるケータイを持ってると、こういう時には便利かもしれない。

かなりさまよったあげく、天神でいくつか買い物と食事。

スタッフに予約してもらったホテル(ハイアットレジデンシャルスイート)が めっちゃ豪華であせる。台所があるってどういうことよ。


2007年07月31日 [長年日記]

_ [Ruby] Rubyビジネス・コモンズ: 設立総会

設立総会。超地味なRuby Associationとは違って、 この設立総会は立派なものだ。 福岡県知事も来たりするし。 出席者も300人以上いたんじゃないかな。

で、「Rubyの未来」と題した講演を行う。 まあ、これまでの技術的動向の変化の方向と 現在のRubyの立ち位置から、Rubyの未来を(無責任に)予想する というような内容。

しかし、こんなに多くの人がRubyに注目してもらえるというのは、 ありがたいことでもあり、はずかしいことでもあり。

本物の「Rubyバブル」が来ていることを実感する。 今はイメージ先行で中身の薄い風船に、 これからは中身を詰めていかねばならない。

その後、懇親会ではいろいろな人と挨拶する。 昨年12月のイベントでは名刺が尽きて申し訳ない思いをしたので、 今回はかなり多めに名刺を持参したのだが、 やはり途中でなくなってしまった。

NaClのだけでなく、楽天フェロー名刺までなくなるとは予想外だ。 福岡の人は名刺交換が好きだとか。

いずれにしても、次回があれば今回以上に名刺を持参しようと思う。

二次会では胴上げされた。長いこと生きてたけど胴上げされたのは初めてだ。 普段接することのない体育会的ノリに新鮮な驚き。

_ [Ruby] Three years with Ruby on Rails

Railsが世に出てちょうど3年、という話。 たった3年なのか。

Railsは世界を変えてしまった。 特に私の周りの世界を。

もうちょっと地味に行くつもりだったんだけど、 冷静に思い返してみれば、私以外の人にとっては、今の方が幸せな世界ではないかと思う。 Railsが呼び水になって、動的言語(やLispっぽい言語)の認知度が高まっているし、 技術者の幸せをともなう生産性の高さが「普通の人たち」の間で 語られるというのはソフトウェア業界はじまって以来のことではないだろうか。

これからも世界は変わりつづける。 その中心に近いところに居られたら、と願う。

_ 世界に“コンピュータ”は5つあれば足りる − @IT

「世界に“コンピュータ”は5つあれば足りる」というのは、 IBMのワトソンが語ったとされる有名な言葉だが、 実は本当にワトソンがそのように行ったと言う証拠はないそうだ。

で、その時とは違う文脈で「5つあれば足りる」という話。

つまり、少数の「コンピューティングファーム」が計算能力を提供し、 普通の人は「端末」からそのパワーを利用するという中央集権モデルが 現実になりつつある。

これまでの「分散」の流れはなんだったの、という気にもさせるモデルだが、 コンピューティングの歴史では集中と分散は振り子のように繰り返しているので、 これからしばらく(Webのおかげで)集中に振れそうだ、という予測なのだろう。

おそらく、その次はデータセンターのサイズや電力などの物理的限界と P2Pのような技術によって分散に振れるんじゃないかなあ。


最新 追記