ウイルス・スパイウェア検査・駆除 用ツール Dr.WEB CureIt! を無償配布中！
この画像をよーく見てほしい。 これはジグソーパズルの各ピースに各国語の「Wikipedia」に相当する表記の 先頭の文字を配置したもののはずである。
われらが日本語は上の方の割と目立つ位置になっている...あれれ？
「ウィキペディア」なのに「クィ」になっている
上記リンクによるとサンスクリット語にも間違いがあるのだそうだ。 まあ、「間違いは人間の常」だが、Wiki本文と違ってロゴ画像は訂正しにくいよなあ。
東京出張。多いぞ。
秋葉原ダイビルの東大オフィスで ささだくんと会う。 ま、懸念材料はおおかた金曜日に片づいた(本当に？)なので、 さほど難しい話はしなかったが。
途中でB4の学生さんが来て、彼の課題である
RHC (Ruby High-performance Computing)HPR (High-Performance Ruby) について
現状を聞かせてもらった。
大変興味深いうえに、楽天技術研究所の研究テーマとややかぶっていたので 面白く聞かせてもらった。まだはじまったばかりだけど。 これは産学共同を考えるしかないか。
結城さんとの対談についてのおくじさんの感想。
「変えないほうが楽」だなんて、 まともなソフトウェア開発をやっている人間なら、決して言葉は吐かないはず
いや、まあ、多くのフリーソフトウェア開発者ならそうであるという点においては 同意しますが(だからこそ、「Rubyは変わり続けている」わけで)、 しかし、「まともなソフトウェア開発」とくくってしまうのは ちょっと広すぎるかもしれない。
「フリーでないソフトウェア開発はまともでない」という主張でない限り。
結城さんは執筆者でソフトウェア開発は本業ではない、というのもあるかもしれないけど、 「変えない方が楽」と考える職業的ソフトウェア開発者もたくさんいる。 当然だがこの「変えない」の対象は「外面からわかる点」である。 外側は変えないでリファクタリングや性能向上だけ考えていた方が楽という意味だ。
もう一つ、
分散化が必須という状況では、言語なり処理系なりが透過的な機能を提供して、それで本当に嬉しいの？と思うのです。
そりゃあ、中にはいわゆるバカチョンパラレルで十分なケースもあるわけで、そういう時には嬉しいのかもしれません。
おっしゃることはよくわかる。しかし、私は今後「いわゆるバカチョンパラレルで十分なケース」が増えると考えていて、それを支援したいと考えているので、HPCをRubyで、というわけではない。 Rubyが本質的に遅いことはわかっりきっていても、それでも「もっと速く」という人は絶えないわけで。 本気で「並列で性能！計算速度命！」とかいう話なら、そりゃ明示的な指示は必須だろうし、 そもそもRubyみたいな言語を使う気にならないだろうけど。
最近だとFortressがそういうHPC分野で透過的な言語を目指して、あまりうまくいっていないようですね。
某所にある楽天データセンター(の一つ)を見学させていただく。 データセンターってどこも住所を明らかにしないのね。 テロ対策？
規模やらなんやらに感動する。 滅多に見れない大きなコンピュータや、サーバのつまったラックの数もそうだけど(60テラのディスクとかはじめて見た)、 一番感動したのは、将来にわたって拡張しやすいように、考慮され、企画され、整然と構成された データセンターの「仕組み」である。 過去、いろいろ「痛い目」にあって学んだことが活かされているのだそうだ。 過去のデータセンターでは、ネットワークケーブルが地層になったり、 電源ケーブルとネットワークケーブルが絡んだり、 マシンが重すぎて床が沈みそうになったり、 大変なこともあったのだそうだ。
一緒に見学に参加した、うち(NaCl)の社長は、 「楽天はデータセンター設計部門を子会社化して事業化すべきだ」と 強く主張していた。本当にそうかもしれない。
おお、面白そうな記事が出たのぉ、と思って読み始めたら 自分の書いた文章だった。最近、オープンソースマガジンや 日経ソフトウェアに書いた記事がWebに転載されることが多くて(それは契約の範囲内なので何の問題もないのだけど)、
面白そう→結局自分の記事だった
ということが頻発している。うれしくない。
各種言語の簡単なまとめとリンク。
HTMLとかXMLのようなプログラミング言語でないものが含まれていたり(AcronymにLanguageを含んではいるけど)、 Euphoriaのようなあまり知られていないものが含まれていたりするのが面白い。
一方、Rubyはまだ名前さえ含まれていない。
あ、そうそう。Euphoriaは最近オープンソース化されたそうだ。 いわゆる「今風の言語」ではないけれど、要チェック。
1年ほど仕事でOCamlを使って感じたOCaml言語のダメなところ、という話。
私自身はOCamlを使っていないし、まだ『入門OCaml』も完読していないので、この批判が正当なものかどうか判断はできないけれど、 今まで言語批判を読んできた経験から推測すると、 大半は設計思想との見解の相違で、 ごく一部正当なものがあるというところだろうか。
もっとも、このような批判が出ることそのものは非常に健全で、 このような批判を改めて検討することで、 自分の設計思想が本当に正しいのか再確認するチャンスを得ることになるし(時間を使ってしまうけど)、 また、今まで思いつかなかった発想の源になる可能性もある。
というわけで、Rubyに対する批判も甘んじて読もうと思っているのだ。 時々、心が痛むけれども。
Python 3000に対するBlog界の反応。
なんとなくforkを懸念する否定的な意見が目立つような気がする。 ま、実際、現行PythonとPython 3000との間で(当初の予想よりはるかに小さいものの)、 非互換性があるのは確かで、結果的に、いつまでもPython 2.xにとどまる人と、 積極的にPython 3.xに移行する人の分断が、ある程度発生することは避けられないと思う。
が、それはしょうがないんじゃないかなあ。 誰かも書いてたけど、Perl5とPerl6よりは小さいわけだし。 たぶん、Ruby1.8とRuby1.9の間よりも小さい。
その辺を気にするのがPython的コミュニティってこと？
いや、邪推が過ぎるか。
こっちにもPython 3000リンク集を発見。
かつてSmalltalkerであったRick DeNataleがRubyに対して思うところ。
いろいろ面白いことがあって、言語に興味があって英語にさほど抵抗がない人には ぜひ読んでいただきたいのだが、個人的に一番面白かったのは以下の引用部分。
I always thought that Smalltalk would beat Java, I just didn't know that it would be called "Ruby" when it did.
私はいつかSmalltalkがJavaを打ち倒す日が来ると信じてきたが、 そうなった時には、それがRubyという名前で呼ばれるとは思いもしなかった。
−Kent Beck
ま、実際問題、Rubyはいろんな意味でSmalltalkではないのだが、 それなりに(頭の柔らかいSmalltalkerに嫌われない程度には)、 Smalltalkの精神を受け継いでいる、らしい。
David Alan Blackによるエッセイ。
新たにRubyを学ぶ人は今まで慣れ親しんだ言語との違いが気になって、 「ここがおかしい」、「あそこを直したい」と感じるみたいだけど、 ちょっと待って。Rubyにはそれなりに歴史と理由があるんだから、 しばらくとどまって、「Ruby流」に慣れてからそのことを考えようよ。 決して後悔しないから。
というような話。
ま、実際「Rubyを変えたい」という話の大半は 「私の知ってる言語XXXとここが違う(から直したい)」というものであるので、 そうしていただけると、私は助かる。
が、そういうリクエストの中にも有意義なものがあったりするから油断がならない。
パフォーマンス(の多く)は処理系の性能よりもアプリケーションアーキテクチャで決まる、という話。 割と当たり前。
The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January
より「高速な」言語を使うことで性能は10-20%程度向上するだろう。 しかし、RubyとRailsで容易に実現できるアーキテクチャ変更のおかげで Twitterは１月と比較して10000%高速になっている
10000%って100倍だよね。
_ ささだ [HPRね。]
_ die [> 外側は変えないでリファクタリングや性能向上だけ考えていた方が楽 外側が変わることを気にせずにやる改善と同じ..]
_ nekosan [Fortressってヲイラ的にはとても気になってるんですが、あまりうまくいっていないんですか？]
_ reti [こんなコメントは言いたくないですが。 「〜パラレル」の「〜」の部分は、無知から来た言葉でしょう。 ちょっと恥ずか..]
_ まつもと [無知って？ 「ばか」とか「ちょん」とか呼ぶのは行儀が良くないというのはわかりますが。 広辞苑によると ..]
_ reti [語源なんて諸説ありますし、「西洋道中膝栗毛」はアジア蔑視が目立つ福沢諭吉の書でしょ？広辞苑はそもそもバイブルでしょう..]
_ じんじん [ツイこの前までは、あの有名なメディアエクスチェンジのを 使っていたんですよ。 ]
_ まつもと [retiさん、 おっしゃることは了解しました。 が、私自身は言葉狩りには賛成しません。 差別意識というのは文脈..]
_ Tietew [> 「西洋道中膝栗毛」は…福沢諭吉の書 ちげーよ。福沢諭吉は「西洋事情」。西洋道中〜はそれのパロディ。]
通常の集会。 今週は私が日曜学校で教師する順番。
集会終了後、有志で『ジョセフ・スミス２００年目のクリスマス ソルトレーク・世界最大の大合唱』を観た。 NHK作成ということで、一応第三者的な態度で構成されていた。
大変よろしかったが、出張疲れで途中うとうとしていたところがあった。 あとで改めて見直そう。実は購入しているのに見ていなかったのだ。 最近、こういうのが多いな。去年、ユタで買ってきたDVDにも見てないのがあるし。
広尾の神殿に参る。
六本木の方から向かって広尾の裏通りを抜ける。 この辺の道を通るのは２０年ぶりのような気がする。 寝坊したのでセッションはひとつしか受けなかった。
浜松の人に出会う。 その他にも知人の息子さんや、弟さんらしい人を見かけたのだが、 声をかけるチャンスがなくて確認できなかった。
２時の飛行機で松江に帰る。
先日の結城浩さんとの対談がWebで公開された。 同じものが今月発売の日経ソフトウェアにも掲載される。 同じタイミングで公開すると言うのは大胆なことではある。 ま、それだけ特集全体に自信があるということなのだと思う。
結構好きかってなことを話している。 ま、面白がって読んでいただければ幸いである。
SQLiteの開発者、Richard Hippのインタビュー。
数ある「オープンソース」ソフトウェアの中でもSQLiteはちょっと特異で、 完全にパブリックドメインを維持している。 また、SQLの解析のために独自のコンパイラ・コンパイラ(lemon)を実装してたりする。
ある意味すごく徹底してかっこいい。
また、会社を経営しているうえに、 SQLiteのためにアシスタント(Dan Kennedy)を雇っているというのも 尊敬する。
うちの取引先でもあるオープンソースジャパンがPCIホールディングスの子会社になった、という話。
なんの事情も聞いていないので、背景やらなんやらはさっぱりわからないのだが、 少なくとも当面事業方針に変更はないようだ。 このことから「オープンソースでビジネスするのは難しい」という結論が 引き出されるというわけではない、と思う。
弾さんは「失格。」と断じたRuby Cookbookではあるが、
単独の書籍としては欠点があっても、
まわり(既存書籍)の状況や、費用対効果を考慮すると、
妥当だったかもしれない、という意見。
実はまだ私自身はRuby Cookbookを読んでいない(入手していない)ので、 どちらかに味方するつもりはないのだが、 複数の書籍に名前が乗る身としては、 書籍を企画する・執筆する・翻訳する・執筆する・出版する ことはたくさんの要素がからみあう大変難しい課題であって、 だれもが満足するものができることは滅多にないことについては よーく知っている。
楽天技術研究所フェローとしての初仕事としての ミーティング出席のために上京。 なんか毎日飛行機に乗ってるな。
マイルは溜まるが、疲れる。
で、せっかくの機会なのでささだくんのところに寄って打ち合わせ。 そしたら、akrさんもいて、たくさん有益な意見をいただいた。 おかげでブロックパラメータなどいくつか放置されていたところの 細かいところが決まった(と思う)。
研究所スタッフとの挨拶から始まって かなり突っ込んだ研究テーマまで。 現時点ではまだ妄想レベルだが、 リソース(時間・人・お金)を突っ込めば実現性は高いと思う。
内容は(現時点では)公開できないが、 成果はオープンソースにするという言質は取りつけた。
PFIの人たちが「頭良さそう」なのは認めるけど、 それを示すのに「彼らは皆、東大・京大、および同大大学院の現役学生、もしくは卒業生」 という表現のを使うこの記事は「頭悪そう」。
Emacsテクニック。
さすがにEmacs歴20年近いと、知らないテクニックはほとんどなかった。 とはいえ、じゃあ、なんでも知ってるかと言うとそうはいかないのが Emacsの恐ろしいところだが。
最近だと
を「発見」した。
_ 碁盤鮫 [それを「クィ」と読んでしまったら台無しです！よくある批判は「「ワィ」なんて発音できないよ！」というものですから。。]
_ Tietew [というか中文は「維基百科」のハズなのに「袓」（示偏じゃなくて衣偏に且、U+8893）になっています。ち..]