Apacheのログ解析

手垢のついたテーマではあるが、ここ2年ほど色々痛い目にあってきたので、ここいらでその経験を活かしたソリューションに仕上げたい。

まず、注意しなければならないのはメモリとCPUを節約しなければならないということだ。アクセスが増えてきたにも関わらず、予算の関係でサーバを増強できないということは、ままある。だいいち、お金があるなら、RTmetricsのようなアプライアンスを導入できるし、その方が良い。予算がない場合が問題なのだ。

WebサーバとDBサーバを1台のサーバ機が兼任しているような環境で、しかもアクセスの増加にあえいでいるような局面でメモリとCPUを贅沢に使うわけにはいかない。だからRubyは選択肢から外さないといけない。なにしろRubyは遅いから。

C/C++という選択も駄目だ。サーバ機がどんなOSで動いているかわからない。多数のサーバOSをサポートするのはできないことではないが、検証環境を揃えるだけの予算がないし、そこまで性能が必要なわけでもない。

Javaは悪くない選択だ。まずは順当というところだろう。たいていのOSでJavaは稼動しているし、パフォーマンスも悪くない。

Objective CamlとCommon Lispも有力な候補だ。どちらもたいていのサーバOSで稼動するし、ネイティブコードにコンパイルできる。DBとの連携にも支障がない。

ほかにも候補はあるが、この3つの言語でそれぞれに実装してみよう。

いろいろひどい目にあった

腐らず再開しよう。

NetBeansのRubyサポート

うわさには聞いていたが、かなり賢い。
Rubyのコードを解釈して補完してくれたりするのだが、Rubyの構文は人間には優しいがコンピュータには厄介な代物なので、よくやったなあと感心する。
これでIDEがないとプログラミングできないタイプの人もRailsに来るんじゃないかな。

# 本当はそういう奴はプログラミングの世界に来るべきじゃないんだが。

Blogged with the Flock Browser

NetBeans+JRuby+Rails

何気にNetBeansのRubyサポートはいい。
Glassfishの上でJRuby on Railsがさくっと動く。今はWEBrickベースなようだが、Glashfishを前提にした本番環境が出てくるだろうね。期待しよう。

Common Lispの美点

t2ruさんのCommon Lispの美点を読んで。

あえて付け加えるなら、最適化のための汚いコードをマクロの背後に隠すことができる点も強みとして加えてもいいかなあ。
現実のアプリケーションでは、いったん出来上がったコードに最適化のためのコードやアドホックな修正のためのコードが追加されることが多い。そうすると、普通の言語ではどんどん本来の処理が見えにくくなってしまう。その点、Common Lispなら大丈夫だ。

Objective Camlの使いどころ

カリー化がわかってみると、Objective Camlは良さげに思えてきた。
しかし、実際に何に使おうと思案してみると、意外に使いどころがない。

いや、どんな応用に使っても良いんだろうとは思う。
だが、僕にとっては速度を気にしないならRubyがfirst choiceで、速度が重要なのであればCommon Lispがfirst choiceになっている。そこに割って入るには、相応に理由付けが必要だ。

Ocamlのストロングポイントは、静的型付けの安全で効率的な実行可能ファイルを（Javaあたりなどと比べて）より短いコードで書けるところにあるだろう。
静的型付けという点を除くと、だいたいCommon Lispの方が勝る。特にコードが短くなる点と表現の自由度という点では勝負にならない。
だから、あえてOcamlを使うからには、プログラムの正しさをコンパイラで確認したいというニーズが必要だ。つまり、性能と正確さが要求されるケースだ。

その要求が成立するには、仕様をフォーマルに記述しうる状況が必要だ。RubyやCommon Lispには柔軟性があるから、仕様がフィックスしていない案件で力を発揮する。僕の仕事では、仕様がフィックスしないことの方が多いのだ。

ここ数日、Apacheのアクセスログを解析する高速なプログラムを書きたいと思っていて、Common Lispでやろうかと思っていたのだが、これこそOcamlの出番のように思われる。すでに運用中のプログラムがあるので、仕様はもう固まっているからだ。