B0000DJLOA
さんざん悩んだ揚げ句、結局買ったのはB0000DJLOAであった。 候補はCanon MP710とHP psc 2450 photosmartだったはずなのだが、 MP710は筐体があまりに大きいので(しかも重量が10Kg超)断念、 psc 2450はインクの値段の高さと(ヘッダ込みなのでしょうがないのだが)、 きっとコピー機としてしか使わないうちの利用パターンには向いてなさそうという理由で断念。 インクコストが安く、コピー機としての使い勝手の良さそうなMP370を選択した。 とはいえ、psc 2450の液晶は惜しかったかなあ。割引率が高くて価格はMP370と同程度だったし。 いやいや、私の判断は正しいんだ。
買って帰って、いくつかカラーコピーとデジカメからの出力を行ったが、家族には好評であった。
しかし、気に入らなければ自分で手を入れられるオープンソースソフトウェアと違って、 他人がデザインを決定し、変更できないプロダクトっていうのは、後で後悔しそうでなかなか決断できない。
いや、ただ単に決断力がないだけなんだが。
私の通っている教会は、アメリカに本部があるせいか、 立派なホームページがあるのだが、 日本語ではインターネット上の公式な情報はほとんどなかった。
が、この度、やっと日本語サイトがオープンした。 まだまだ情報は少ないし、翻訳の途中のものとか残ってるけど、ないよりはずっとマシだ。
個人的には、近日登場予定という「全国の教会検索」を期待している。 Ruby Conferenceとかでアメリカに行く時には英語版の「meetinghouse locator」で、 教会堂の場所、集会時間、地図、任意の地点からの道順などの情報が入手できるので重宝していたのだ。 私自身は国内なら日曜日は帰っちゃうと思うけど、出張が多い人とか、これが便利な人は多いと思う。
今月は「Metaprogramming Ruby」。Glenn VanderburgのOSCON 2005での発表をベースに。 でも、もうちょっと突っ込んだ内容になっていると思う。
ただ、リフレクションやevalについては(実装した本人であるので)詳しいが、 メタプログラミング機能が「言語内DSL」の実現に役立つというのは、 彼のオリジナルのアイディアだ。参考にさせていただいたGlennに感謝。
本当はお盆進行で10日が〆切だったんだけど、ちょっと間に合わないみたい。 編集の人にメールを出して1日〆切延ばしてもらう。
長いぞ。無駄な時間だったとは思わないけど。
やっちゃった。文書登録はRastの10倍以上速そうだ。
本当はRastを速くするハックというのをやりたいんだがなあ。 どうも能力と気力がついて行かない感じ。
GNU EmacsとXEmacsは、しばしば懸念されるものの めったに起きることはないフリーソフトウェアプロジェクトのfork例。 ライセンス上、フリーソフトウェアプロジェクトのforkを強制的に止めることはできないが 協力した方が得、という話。
とはいうものの、この話の流れを読んでみるに、 forkの原因は技術的な要素よりも、 結局は人間関係とコミュニケーションが鍵であることと、 (本人は意図していないだろうけど)RMSのコミュニケーション能力は あまりほめられたものでなかろうことが読み取れる。
どこでも人間関係と言うのは難しいものだ。
はてなの伊藤さんのインタビュー。
オープンソースのコミュニティにコミットする人の中には、会社で充実した仕事ができなくてその反発からやってるという人も少なくありません。会社の中でくすぶっている人が外に出て道が開けるケースもあり、それは肯定されるべきだと思います。しかし、経営者の自分としてはそういうふうにエンジニアに思わせてしまうことが経営として失敗なので、肯定はしちゃいけないんですね。
「くすぶらせちゃいけない」というのはその通りだろう。 個人的には「積極的に外に出させる」というのをやりたい。 できてないんだけど。
NetBeansは進化中、という話。
ここで紹介されているスクリーンショットでは、
ができるようになっている。もう、「IDEがないから」という言い訳は 聞かなくてもすむのかもしれない。
Railsのおかげ(？)で、Rubyの代名詞という感じになったOpen Classだが、 ちょっと工夫すれば(annotationを使って)実現できる、という話。
Pythonのannotationってばなんでもできるよね。 おもしろいメタプログラミング機能だと思う。
それはそれとして、コメント欄では「たとえ可能でもしてはならない」というコメントが目立つ。 やはりOpen ClassはPython主義者(の多く)には耐えられないのかしら。
個人的には、この辺は言語で制限するのではなく、 「自分が何をしてるか分かってないと危険」ということだけ示して 許可したいのだけど。
PHP on Railsは不可能という話。
ActiveRecordをActiveRecordたらしめているものは、 リフレクション機能であり、それはPHPには欠けているから。 Javaにはリフレクション機能はあるんだけど、 言語的に硬いからなあ。結局はXMLなりGroovyなりを経由して 柔らかくするしかないのではないだろうか。
それはPHPでも同じか。複数言語を取り混ぜればよいという話になる。
というところで、タイムリーなMartin Fowlerの記事。
現在フレームワークを選んでいるのと同じように、何ができるかによって言語を選ぶような人たちのプロジェクトでは、複数の言語を見ることになるだろう。
そうなるかもしれない。しかし、その時、選択基準になる「何ができるか」とは「何」か。
LispでもRubyでもいい、十分に高度な抽象化能力を扱える言語であれば、 どの分野であっても、その言語の上にそれなりに有効なDSLを構築することができるはずだ。 となると、選択基準は実は「what」ではないだろう。
私の思いつくものは、以下の二つだ。
となると、JRubyやIronRuby(or Ruby.NET)のような相互運用性のある環境が より魅力的になるのかもしれない。 C言語とC Rubyはずっと以前からそういう関係を築いてきてるわけだけど。
デジカメでピンホールという発想はなかった。脱帽だ。