井上

2005・10・27

PHPの時代?

一ヶ月前の記事ですが、phpspot開発日誌からFlickrシステム概要を見ました。

6万行のPHPコードをひとりで開発...

みんなの言っていること(特に利害関係のある企業の言うこと)を簡単に信用しない、という立場でいたつもりでしたが、「PHPで大規模ソフトウェアは無理だ」という"世間の常識"は無批判に受け入れていた気がします。認識を改める必要があるのかもしれません。それにしても、PHPほどの高レベル言語で6万行とは驚きます。Javaなら5倍の30万行ぐらいの規模感かもしれません。
2005 10 27 03:13 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・10・26

SELinuxの洗礼

SELinuxは、ぼくの生活にはしばらく関係無いものだと油断していました。

こんな症状でした。

ソケットへの接続でpermissionエラーらしきものがでます。ぼくの知識には無い世界でした。

結局、SELinuxの次のアクセス制御が効いていました。
/selinux/booleans/httpd_can_network_connect

/var/log/messagesファイルを見ると、ヒントはちゃんとでていましたが、長年のapacheの経験で、「apacheの問題はapacheのログを見る」と思い込んでいて気づきませんでした。

/var/log/messagesファイルから抜粋
> 伏字 : avc: denied { name_connect } for pid=9034 comm="httpd" dest=8009 scontext=root:system_r:httpd_t tcontext=system_u:object_r:port_t tclass=tcp_socket


SELinux関連の情報をWebで探して見てみました。みんな楽しそうです。sendmail.cfを書くぐらい楽しそうです。とりあえず、psコマンドとlsコマンドの-Zオプションだけは覚えました。

今日の教訓:
独自のログファイルを持っているソフトでも、/var/log/の下のファイルもチェックすべし。
2005 10 26 01:37 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・10・25

「イノベーションのジレンマ」を読みました

読むようにと命令されて、ずっと机に積んだままだった「イノベーションのジレンマ」をようやく読みました。2年ぐらい(それ以上?)積んだままだったかもしれません。
内容を聞かされていたので、犯人を知ってミステリ小説を読むようなところがあり、大きな感銘はありませんでしたが、まあ、色々と思うところはありました。

本のターゲットは大企業ですが、ぼくが知りたいことはベンチャー企業の戦略です。
確立された市場があり、そこでうまく立ち回る企業(成功した企業:大企業)があった時、大企業はその市場の顧客の意見に耳を傾けていると破壊的イノベーションを見逃す、というのが本書の主張です(破壊的イノベーションは稀な事象なので、通常時、顧客の声を聞くことは正しい戦略)。
ベンチャー企業の側から見ても、確立された市場の顧客の声を聞くことには、ろくなシナリオが無いように思えてきます。

破壊的技術を推進するには、次の戦略を取るべし、と書かれています。

アジャイルで素晴らしい、なんて無邪気に喜べると幸せですが、本とは違う現実を見てきたので、素直に受け取ることはできません。

やっかいなのは、事業計画です。別種の本によれば、きちんとした事業計画こそが、成功するベンチャー企業の条件です。それはともかく、事業計画の最大の難関は、
「大きな成功を示す事業計画でなければ、誰も金を出さない」
です。
小さな組織で小さな成功を目指す事業計画は、資金調達という観点では何の価値も持ちません。ぼくにとっては、この現実が大きなジレンマです。
2005 10 25 04:48 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・10・21

「Google File System(GFS)技術メモ」を書きました

Google File System(GFS)技術メモ
http://dev.ariel-networks.com/modules/xfsection/article.php?articleid=50

GFSは、「メンテナンスフリー」の部分が最も大きな特長だと思います。どうせ高いハードウェアでも壊れる時は壊れるので、安いPCを使って、壊れることを前提に冗長化した分散ファイルシステムです。

冗長なシステムなので、GFS単体でレスポンス性能を追求している気はしません(*)。
Googleのレスポンスの良さに効いているのは、GFSよりもMapReduceの方かもしれません。
# MapReduceの論文はまだ読んでいません。


(*) もちろん、ポイントポイントでは相当なチューニングをしているでしょうが。
2005 10 21 02:58 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・10・17

今月のユニマガは凄いかも

大谷さんがアリエルフレームワーク(afw)の心髄を書いています。書いてはいけないことまで書いています。
UNIXデバイスドライバ、グリッド、Linda(ruby版はRinda)の話など、ユニマガ復活を印象づける一冊です。
もっと読む...
2005 10 17 14:36 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・10・13

スキーマ不定のXMLをRDBに放り込む

最近オフィスで席替えがありました。隣に凄い人が来たので、追い付くために必死に勉強しています。厳しい世界ですが、学びの場が常にあるのは、アリエルの良いところです。

先月、第2世代XML-DBについて言及しました。少し古くて(2001年)、有名かもしれませんが(昔、ぼくも見た記憶があります)、XML-DBをこけにした記事があります。
DB2を売っているIBMの記事である点は差し引いても、確かに「集約」機能に関してRDBに一日の長があることは事実でしょう(*)。


スキーマ不定なXMLをRDBに放り込む方法を調べてみました(概論だけ)。
分かりやすいのは次のふたつです。
http://www.ipa.go.jp/about/news/event/pdf/29A4_yui.pdf
http://www.astf.or.jp/astfinfo/mediaA/pdf/12-yoshikawa.pdf

前者の分類のCLOB(Character Large Object)は、単にXMLをそのまま1カラムに放り込むパターンで、事実上、RDBを単にインデクサとして使うイメージです。
後者で、「構造写像アプローチ」と呼んでいるのは、XMLのスキーマごとにRDBのテーブルを作るイメージです。実用アプリでO/Rマッピングとか言っているのはだいたいこのアプローチかもしれません。アカデミック的には関心が低そうです。
「モデル写像アプローチ」はXMLのスキーマに依存せずにRDBに放り込めるのと、XPathなど(XMLの世界の言葉)からSQLを自動生成するあたりがマニアックで、アカデミックの関心を引くようです。
モデル写像アプローチは更に細分化されます。前者のXMLPGSQLはモデル写像アプローチの枝アプローチ派で、後者のXRelは経路アプローチ派のようです。


前者の文書を書いた油井さん(実は一度会ったことがありますが)の日記から面白い抜粋:
http://db-www.aist-nara.ac.jp/~makoto-y/tdiary/?date=20050727
「なぜMLを学ぶ必要があるか?」
時代はMLのようです。言うまでも無いですが、Markup Languageではありません。

http://db-www.aist-nara.ac.jp/~makoto-y/tdiary/?date=20050830
「Functional Programmingの流行(?)」
やはり、そうですか。

http://db-www.aist-nara.ac.jp/~makoto-y/tdiary/?date=20050920
「How to lead a project success?」
耳の痛い部分が...言っていることは正しいことばかりです。


(*)個人的な理想論を語ると、スキーマ固定の世界(RDB)とそうでない世界は「違う」と思っています。XMLをRDBに放り込む無理矢理感は否めません。
2005 10 13 02:41 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・10・11

パフォーマンスと言えばgoogle

Javaとperlのパフォーマンスがどうだ、なんて話は、人間が小さい気がしてきました。やはりパフォーマンスを語るならgoogleを避けて通るわけには行きません。

Google Research Publications
http://labs.google.com/papers/

Rob Pikeの名前があります。slashdot経由でGoogleに入社したと聞いた記憶がありますが、こうやって名前を見ると感慨深いものがあります。

# ちなみに、まだどれも読んでいません。
2005 10 11 04:28 - inoue - トラックバック(DISALLOWED (TrackBack))

パフォーマンス、信じられるのは自分だけ

「サーバーサイドの大規模な開発にはJava」、と言われ始めてからだいぶ経っています。一方、インターネットで本当にトラフィックをさばくサイトのサーバがServlet化している様子は見られません(netcraftを信用すればですが)。いくつかのオンラインバンク系のサイトで、.jspのついたURLを見ることがあるので、コボラーには人気なのかもしれませんが(凄い偏見)。

本当のところ、Servletとmod_perlでどのぐらいのパフォーマンス差があるのでしょう。

mod_perl側で面白い情報が、ドリームアーツ竹迫さんの「mod_perl における C10K Problem」です。
c10kは、同時クライアント数1万の課題にどうするかという話です。
実際には同時接続数100のオーダーでもかなり厳しい話です(極論ですが、1セッションがCPUを0.1秒占有するだけで、最大10秒の遅延を生みます)。竹迫さんのプレゼンは、mod_perl以外のところで、いかにがんばるかに焦点が当たっています。

直接的に、Servletとmod_perlのベンチマーク比較をしたのが、次のふたつです。
http://module.jp/blog/cgi_php_servlet_modeprl_benchmark.html
http://www.caucho.com/articles/benchmark.xtp

前者は小山さんが行ったベンチマークです。Tomcatに比べてmod_perlの方が少し良い数値ですが、まあ、誤差の範囲でしょう。

後者はResin(servletサーバ)が、自分たちはmod_perlより速いと主張しているページです。そうは言っても、圧倒的な差をつけているわけではありません。せいぜい数10%速いといったところです。ここではResinがTomcatより3倍速いと言っています。Resinのサイトにそんな記述は見つからないので、信用できるかは不明です。もし本当なら、Tomcatはmod_perlよりだいぶ遅いことになってしまいます。
3倍の数値はともかく、Resinが速度を売りにしているのは事実です。XSLTも速いと主張しています。もっとも、あの信じられないほど遅いXalanと比較している時点で終わっている気がします。自信があるなら、libxsltと比較してもらいたいものです。
Performance FAQによると、Resinのネットワーク周りはネイティブコードでチューニングしているようです。この辺は、SunやIBMには(政治的に)できない部分です。

さて我らが(?)Tomcatはどうなのでしょう。Tomcat FAQのパフォーマンスの項から、Servlet Performance Reportを見ました。細かい数値はともかくWebSphereのひとり負けが目立ちます。IBMなので、安いマシンで速く動くようなバカなソフトは作りません。TomcatとResinは、あまり差を感じません。これを見てTomcat意外にやるじゃんと思うか、Resinは口だけソフトと見るか、速いソフトなんて信用できないのでやっぱりWebSphereが一番ですよ、と思うか、それぞれの自由です。
2005 10 11 02:36 - inoue - トラックバック(DISALLOWED (TrackBack))

アンチStruts(のトランジションドリブン)

Javaファンの井上です。

1年以上前にStrutsネタを書いて、「次回に続く」と終わらせています。
http://dev.ariel-networks.com/blog/inoue.php?blogid=2&archive=2004-8-17

Strutsに違和感をずっと感じていましたが、共感できる文書を見つけました。

Strutsの志向を「トランジションドリブン」と呼んで批判しています。対案として「ページドリブン」なアーキテクチャを提唱しています。直感的に、悪くないと感じます。
ただ「ページドリブン」という用語はあまり好きではありません。「ページ」と呼ぶと、ユーザ側(ブラウザ)の一画面を想起させます。ユーザ側での画面にとらわれる必要は感じていません。ブラウザにHTMLを返すのも、JavaScriptのXMLHttpRequestに応えるのも(いわゆる、須崎さんJesse James Garrettが提唱したAJAX)、RSSリーダーにRSSを返すのも、Webアプリ側が区別する必要は無いはずです。

Strutsの「トランジションドリブン」がいつも悪いわけではありません。「次へ」「次へ」と進むようなページ遷移、普通のWindowsアプリで言うところのWizard的なUIには向いています。過去のWebアプリには、こういうWizard的UIが多かったのですが、今後、相対的に減っていく気がしています。と言うわけで、Strutsの意思を継いでいるJSFにも違和感を感じています(気が変わる可能性もあります)。
2005 10 11 02:28 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・10・09

cygwinのmc(Midnight Commander)

cygwin上でmvと打つつもりが間違えて、mcと打ってしまいました。すると、mc(Midnight Commander)が起動しました。mcがcygwinに入っているとは知りませんでした。日本語名のファイルやディレクトリを扱う時、役に立つかもしれません。


昔、Meadowもcygwinも無かった頃(*1)、Windows3.1で作業する時は、VZエディタのファイラでファイル操作をしていました(*2)。Meadow(Emacs)には負けますが、良いツールでした。


(*1)存在したかもしれませんが、ぼくが知らなかった頃。
(*2)ファイルマネージャを使うには若すぎました。
2005 10 09 02:34 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・10・06

Deskzilla, Kontiki, Ning

# 何の進歩も無いslashdotネタです。

Bugzilla Delivered to the Desktop
http://developers.slashdot.org/developers/05/10/05/168247.shtml?tid=185&tid=8
から
Deskzilla
http://deskzilla.com/index.html
bugzillaのリッチビューワー専用ソフトをPCにインストールする形です。slashdotの賛否両論には色々と感慨深いものがあります。


BBC Releases P2P TV Client Test
http://slashdot.org/articles/05/10/05/0139223.shtml?tid=129&tid=95
から
http://www.bbc.co.uk/imp/help/index.shtml#seventeen
Kontikiを使っているようです。
ひっそりと実験してひっそりと消えそうな予感がするのは悲観的すぎるでしょうか。


Marc Andreessen's Social Platform: Ning
http://developers.slashdot.org/developers/05/10/05/121253.shtml?tid=95&tid=8
から
http://www.ning.com/
ソーシャルアプリ(定義はあってないようなものですが、まあコミュニティウェアみたいなものです)を自由に作ってください、というサイトです。ブックマーク共有なり写真共有なり、既にある程度できているものをコピーしていじって、ソーシャルアプリのアイディアをすぐに試せる場を目指しているのでしょう。サーバの保守や、違法コンテンツのリスクまで考えると、金持ちゆえにできる富豪的アプローチかもしれません。もっとも、このリスクは、ユーザにWeb公開用のディスクスペースを提供しているISPと同じと言えば同じかもしれません。感覚的には、シェルの利用を公開していた初期のISPなのかもしれません。perlで書かれたcgiスクリプトをみんなが競って書いていた時代です。コマンドラインシェルがWebブラウザになり、言語がperlからPHPに変わったのは、たぶん偉大な進歩なのでしょう。

言語や環境が変わっても、結局、重要なのはアイディアです。
http://appideas.ning.com/
ブレインストーミングのネタに使えそうです。
2005 10 06 06:30 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・10・04

Linusの暴走

slashdotから 「Linus Says No to 'Specs'」

取り上げられたMLのスレッドです。

要は、LinusがMLで、(文書化された)スペックをこきおろしたという記事です。こんな感じです。



MLで相手してる側の、ややあきれた感もいい感じです。


Linusの攻撃の雰囲気が10数年前にマイクロカーネルを攻撃した時と変わっていないのが笑えます。粘着質と言うか、パラノイア的と言うか、たぶん凄いハッカーになるには、こういう部分が無いといけないのでしょう。
2005 10 04 02:47 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・10・03

謎のSQLite

あのlirisさんに触発されて、SQLiteを見てみました。

Cのlow-levelのAPIは良いです。まさに5分で理解できるAPIです。

古いので注意、と書いてありますが、このパフォーマンスは驚異的です。特に次のふたつです。


こんなに速ければ、もっと全面的に採用したくなります。まあ、ベンチマークの結果をそんなに簡単に信用はしませんが。


リリースの歴史を見ると、微妙に謎のソフトです。オープンソースの多くは、このぐらい(5年)の歴史があると、最初ひとりもしくは数人で始めたプロジェクトが、徐々に協力者を得て行く様子が見て取れるものです。SQLiteにそんな気配は全く感じられません。実は、Copyrightも普通ではありません。パッチを送った相手に、(事実上の)著作権の放棄を求めています。

「著作権を放棄しているのでライセンスなんてありません。ソースコードにはライセンスの代わりに祈りを書きます」(意訳)とあって、次の言葉がソースコードの頭に書かれています。

May you do good and not evil.
May you find forgiveness for yourself and forgive others.
May you share freely, never taking more than you give.

なんと言うか、rms並の変人ぶりを醸し出している気がします。
作者はこの人です。Webサイトから判断すると、rmsとキリスト教が好きな人のようです。

rmsはまだSQLiteの存在を知らないのでしょうか。知ったら、GPLにせよ、と言うはずです。
2005 10 03 04:10 - inoue - トラックバック(DISALLOWED (TrackBack))