私は、マークアップエンジニアという言葉は知りませんでしたし、ぶっちゃけ CSS で盛り上がる世界が存在しているということも理解できませんでしたが、以下のエントリの言わんとしていることは賛成です。

ただ、一つ違和感がありました。

IT戦記 - マークアップエンジニアはどこへ向かうべきか（を考えてたらカッとなって LL の資料公開）より

(X)HTML + CSS しか出来ない人はそれなりに危機感を感じたほうがいいと思った今日の昼ご飯でした。

JavaScript をごりごり書いている私が言うのもなんですけど、そんなこと言っちゃったら、Web 系エンジニア全体が微妙な気が・・・。CSS がバッドノウハウの塊で、極めるほどの本質的な奥行きがないなら、JavaScript もある意味同じ気がします。ぶっちゃけ「ブラウザ上なのにこんなことできて凄い凄い！」という世界ですからね。(--;　VC なら凄くねぇ！

# デモ、VC ノホウガムツカシイあるヨ。

つまり、私が感じている違和感は、本質と表層の捉え方なんだと思います。

http://twitter.com/amachang/statuses/191263472 より

「CSS 道」は道が短すぎるんだ。マーケティングの為に長く見せてるけど、実際覚えることは少ない。「デザイン」か「JavaScript」を職業に出来るくらいにしとかないとヤバいと思う。

私としてはデザインと JavaScript を同列においているのが少し気に食わないわけです。本質的な奥行きを持つデザインと、表層的な奥行きしかない JavaScript で比較するなんて。JavaScript のノウハウの少なくない部分は、言語が改善されれば（あるいはフレームワークやライブラリによって）消えゆく「べき」ものです。CSS ハックの大半がブラウザ（主に IE）の改善とともに消えゆくように。本質的な奥行き感で言えば、デザインと UI プログラミングくらいなら、結論として納得感があるんですけど。

# 絵のセンスがない私にとっては、絵描きさんやデザイナさんは尊敬の対象です。

UI に関係するプログラミング言語の変化はめまぐるしいです。つい最近まで主流だった VB も Delphi も Java + Swing も生き残っているとは言いがたいです。変化の激しいこの世の中で、JavaScript だって長く生き残るかどうかはわからないわけですよ。Ajax や Comet だって、本質的な部分には非常に奥行きがあるわけですが、表層に限って言えばあまり言うことはないわけです。近頃は Ajax.Request とか dojo.bind とか書けば Ajax してくれますから。

でも、UI に関係するプログラミングは実に奥が深いです。下手な書き方をするとすぐにメンテ不能やテスト不能（VB や Delphi のフォームみたいに）に陥ります。また、ユーザが直接触る部分ですから、工夫の余地は無数にあります。これらは、言語によらない本質的な難しさであり、価値です。

もちろん、今使っているプログラミング言語に精通することは大切です。でも、IT の世界は歴史が浅く道具の変化が激しいので、本質的なスキルは何か見極めていかないといけないんじゃないかなと思います。CSS の後に JavaScript では・・・あまりにも短期的な視点で食っていくためというのがアリアリ。そりゃ、食わにゃ死にますが、長期的かつ本質的なスキル開発を促しても良いんじゃないかな？、と思いました。

あ、でも、本エントリの言わんとしていることには賛成です。第二の何かは、Rails している人も、PHP やっている人も、JavaScript をやっている人にも、等しく必要なんだってことです。Java している人にもね！

以下、余談。

○ 余談１

とはいえ・・・C/C++ 言語の世界は変化が少ない・・・というか、変化はしているのだろうけど、プログラミングそのものが奥行きを持っている気がします。対象領域の違いから来るものでしょう。C/C++ だってアプリの世界なら同じ問題を抱えていると思います。

○ 余談２

スタンドアロン（Delphi + VCL でも Java + Swing でも VB でもいいけど）の世界を知っていると、HTML + CSS + JavaScript（＋LAMP）が、意外と理にかなっていて面白い世界なのが良くわかります。Web 系技術が凄くないと連呼する人はいるけど、また、私もそう思うけど、これまでのやり方よりは優れているんです。個別に見ると新しい技術はなくても、組み合わせて使うと新しいみたいな感じです。
実際、Kodougu（Ruby on Rails + JavaScript で実装されたブラウザ上で動作するモデリングツール）は、Java + Swing や C# + Windows.Forms で実装された同系統のソフトよりもはるかに短いコード（＝メンテしやすい）で実装できています。やはり、Web 2.0 のときに技術的にも何かが起こったんだなって感じます。「気づき」のあるなしとか些細なことなんですけど。

このブログの左側のメニューにはてブの人気エントリを表示してみました。はてなブックマークからサイトの注目記事を RSS で取得して、HTML に変換して表示しています。コードはざっと以下のような感じです。

require 'rss'
require 'net/http'
Net::HTTP.version_1_2

hotentries = ''
url = 'http://www.rmake-labo.com/akasata/'
rss_source = Net::HTTP.get('b.hatena.ne.jp', 
  "/entrylist?cname=&url=#{CGI.escape(url)}&sort=count&mode=rss")
rss = RSS::Parser.parse(rss_source)

rss.items.each do |item|
  hotentries += <<-EOS
    

      #{item.title}
      
        
      
    
  EOS
end

実運用する際は、はてなの RSS をキャッシュしたりしないと、はてなが重くなっちゃうので気をつけましょう。

「お知らせ:「コナミコマンド」を実装しました」によると、コナ○コマンドはできるらしいです。コードを見てもらうとわかりますが、if 文で普通に分岐しています。これはこれでお手軽な実装ですが、こういうものを見ると一般化してみたくなります。

上記サイトより抜粋：

var konmaiFlag = 0;
function konmaiCommand(konmaiKey){
	if (konmaiKey == 38 & konmaiFlag == 0){//上
		konmaiFlag = 1;
	}else if (konmaiKey == 38 & konmaiFlag == 1){//上
		konmaiFlag = 2;
	}else if (konmaiKey == 40 & konmaiFlag == 2){//下
		konmaiFlag = 3;

キーの配列を受け取ったら実行してくれるクラスがあると便利ですよね。特に以下のような書き方ができたら楽しいですね。

// 上、上、下、下、左、右、左、右、b、a
var keys = [38,38,40,40,37,39,37,39,66,65];
var processor = new KeyCommandProcessor(keys, onSuccess, onError);

作成してみました。以下にサンプルページ＋全ソースコードがあります。
キー入力サンプルページ（IE/Firefox）

でも、上記の実装だと、波○拳を繰り出すことはできません。なぜなら、複数のキーの同時押しができないからです。この手の実装はゲーム開発者にとっては当たり前のものだと思いますが、馴染みがないとなかなか難しいです。ス○２の波○拳の場合、下、下右、右、パンチです。私の記憶が正しければ。ここでは、↓、↓→、→、A を実現するようにします。とりあえず以下のような書き方をしたいものです。

// 下、下右、右、a
var keys = [40,[40,39],39,65];
var processor = new KeyCommandProcessor(keys, onSuccess, onError);

作成してみました。以下にサンプルページ＋全ソースコードがあります。ポイントは入力したキーを複数個持つことです。prototype.js とか使って配列を操作する機能を強化すれば、半分くらいのコードで書けると思います。でもまぁ、ここまで来るとあまり、手軽なものにはなりませんね。
キー入力サンプルページ（IE/Firefox）

実は現時点でも結構手抜き実装（格闘ものならもっとキー操作は厳密にする方が良いです。）ですが、ずいぶん進歩した気がしますね。上記のコードは全てパブリックドメインです。かなりバグがあると思いますが、適当に料理してやってください。

Ruby で URL エンコーディングを行ってくれる CGI.escape メソッドでは、スペースをプラス（+）に変換します。（仕様どおりの動作だと思います。）しかし、JavaScript でデコードを行う decodeURIComponent() 関数では、+ をスペースには変換してくれないようです。したがって、Ruby でスペースを含む文字列を URL エンコードをして JavaScript でデコードすると、プラスがデコードされずに残ってしまいます。

Kodougu でこの問題にあたってバグが発生したので、とりあえず、Ruby で URL エンコードした文字列のプラスを %20 に置き換えました。%20 はスペースに変換してくれるようです。なにやらこの手の問題は微妙にエンジニアを悩ませますね。。。

私が書いたにしては妙に反応のあった「Ruby なんて遅くて使えないよねって言ってみる」についてです。

釣りっぽいタイトルと整理されていない内容のおかげで誤読が出るとまずいので、念のため補足します。このエントリの趣旨は、Ruby は遅いけど、Web アプリにおいてはその遅さがシステムのトータルなパフォーマンスに与える影響はそれほど大きくは無いので、Ruby を使っても問題はないということです。ついでに言えば、私は「プロトタイプは Rails、本番はパフォーマンス／スケーラビリティを考慮して Java」とか「Rails を採用すると運用フェーズでコストが増大する」という意見も鵜呑みにはできないと考えています。本当に Ruby/Rails がボトルネックになっているのかと聞いてみたいところです。

ま、そんなことよりも、この記事に対応する記事を書いた方々を紹介します。いずれも、良いことが書いてあるので読んで見ると吉です。

■ 記事を書いてくださった方々
Ruby の作者であるまつもとさんに言及していただけるとは感激です。しかも的確なエントリに感謝です。

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

Rails の性能の悪化はしないようですね。VM がからむと、eval のあたりで速度低下が起こっても不思議ではない気もしますが、処理系の性能向上と相殺されているのでしょうか。それとも eval は JIT コンパイルされないのかな。とにかく、Rails は eval だらけだった気がします。Kodougu はわりと eval を使っていないので、YARV の恩恵をダイレクトに受けられそうでわくわくしています。（ユーザーメリットは無いでしょうが、1ms でも高速になるとときめくのです。）どちらにしても、Rails のパフォーマンスのネックになっているところを調べないと。

航海日誌(2007-07-07) でも取り上げられているようです。Java 使いの方かな。2007 年度の未踏の方のようです。

JavaでGenerics，拡張for文，可変長引数，static import，anonymous classを上手く使うとびっくりするぐらい楽になる．このうまさを知るともう戻れない．

同意です。Java でも「上手くやれば」生産性（ここでいう生産性はコード数）において Ruby にそうそう負けるものではありません。そして、Java のパフォーマンスは心強いです。ただ、「上手くやれば」という条件付です。私は Java、C# で、（モデリングツールですが）コードの爆発的増量を経験しているので。今のところ Ruby では起こっていないようです。（私のスキルレベルでも生産性を発揮してくれる Ruby は大好きだ。）要は、私の Java/C# スキルの問題なんですが、Ruby よりは習熟しているはずなんですけどね。。。

やむにやまれず:Rubyは遅いから使えるのですというブログでも取り上げられていました。

逆でしょう。RubyやRailsは遅いから使えるんです。

あらら。読んでもらえなかったのかしら。結局使えるって書いたつもりだったのですが。私はもうちょっと整理したエントリを書かないとだめですね。orz　それはともかく、遅いってことは、いろいろやってくれてるんだから、使えるにきまっているじゃないかってことですね。面白いエントリです。

またスケールアウト時にはマシン台数が増えて、メンテナンスのランニング費用が特に脹らむことでしょう。

ランニング費用をサーバ管理費中心にしているのが若干微妙です。ソフトウェア開発は保守の方がコストがかかるので、運用フェーズになっても Ruby/Rails のメリットはむしろ上がって行きます。一人のプログラマが一年あたりに書けるコード数が一定ならメンテナンスできるコード量も一定（※）です。そして、時代は永遠のベータ。（少なくとも Rails が対象とするアプリは運用しながら開発が続けられていきます。Kodougu みたいに。）

と、異議は唱えてみたものの、基本的には面白いエントリでオススメです。（面白いから異議を唱えるんだな、これが。）

※ こういうことを書くと、動的言語は本当にメンテナンスしやすいのかどうなのか疑問を投げかける人が出てきそうです。この辺、誰か解説して欲しいなぁ。今のところ私は保守しにくさは感じていませんが、それは規模が小さなアプリだからでしょう。でも、数千、数万人月とかになるような巨大システムの基幹に Ruby/Rails を据えるような人はいないですよね？

■ そういえばこんなツッコミはなかったなぁ・・・
例：えらそうなこと言ってる割には Kodougu 重いじゃねーか。だから Ruby はだめなんだよ。今からでも Java で書き直すか？

えーと、あの、その、Kodougu が重いのは JavaScript で書いた部分がいけていないからです。はい。サーバは結構余裕です。あぁ、JavaScript を書き直したい。時間が欲しいな。

■ 追記（2007/7/21 12:04）
こちらからさらにお返事いただきました。感激。意図が伝わらないのは、釣りっぽい書き方をした私の責任です。スンマセン。丁寧なお返事ありがとうございます。

Kodougu では、要素のエディタを dojo.widget.Dialog で作っています。ところが、要素の編集を行って Dialog を閉じてから、もう一度開いたときに、編集が反映されず古い情報が表示されてしまいました。

Dojo では、デフォルトで Dialog や ContentPane などの中身はキャッシュされるようです。Dialog を show する前に、以下のように書くとキャッシュをクリアできるようです。

dialog.refreshOnShow = true;

それにしても、Web アプリというのはキャッシュとの戦いですね。レスポンスを良くするにはキャッシュが必要ですが、キャッシュのクリアし忘れによって思わぬバグに遭遇することもある・・・ということです。難しいですね。

要は、私のように英語力が無い人間が dojo を使えるようになるにはどうしたらいいか考えてみました。

dojo といえば、豊富な機能を持った人気の JavaScript フレームワークです。しかし、マニュアルが豊富ではなく、日本語情報が少ないなどの理由から、使いこなすのはなかなか大変です。リファレンスは存在しますが、正直これを見て使えるようになるものでもありません。（あるいは、これを見て使えるスキルがあるのなら、dojo を使いこなすことに苦労するとも思われません。）

特に、dojo の widget はプログラムから生成する方法もあれば、DOM 要素に特定の属性を定義してやることで、自動的に生成する方法もあります。リファレンスだけを見て使えるような代物ではありませんが、The Dojo Book を参照するのも英語力が無いとしんどいでしょう。

そこでどうするのかというと、リリースをダウンロードしたら、テストコードを参照します。dojo.widget のテストは親切で、テストコードを見ると、5 分で使えるようになります。ドキュメントが豊富ではない、あるいは日本語ではない場合はまずはテストコードを見る、これはどんなオープンソースプロダクトにも言えることかもしれませんね。

たとえば、dojo のタブを調べる場合は以下を参照します。
/tests/widget/test_TabContainer.html

あるいは、プログラムから widget を生成する例は、以下です。
/tests/widget/test_createWidget.html

ちなみに、最近は日本語の情報としては以下が良さげです。dojo のまとめサイトっぽくなっています。
Dojo/JavaScript Toolkitのメモ

「Ruby なんて遅くて使えない」という意見が出ます。（昔、Java も似たようなことを言われましたっけ。）これに対して、Ruby 好きな人からは、「大抵の Web アプリではボトルネックは IO になるからアプリの言語は遅くても構わない」「CPU 時間よりも開発者の時間の方が重要」というような反論が展開されます。

Rails 厨にならないためにも、ここは Ruby に批判的な目を持って、この問題を考えてみたいと思います。

■ 前提
Ruby を採用するとなると Rails 絡みで Web アプリでしょうから、Web アプリについて考えてみます。（でも、DLR とか話に出てくるわけですから、クライアントで使う場合もそろそろ検証した方がいいと思いますけどね。）

■ Ruby は遅い
以下のサイトを見るとわかりますが、場合によっては、C 言語の数十倍から数百倍遅くなります。（Ruby 1.9/YARV が出てくれば、少しは事態は改善されるに違いない・・・と信じていますが。）

The Computer Language Benchmarks Game
http://shootout.alioth.debian.org/

本当に Web アプリでは言語の速度は問題にならないのでしょうか？ Kodougu（Rails で開発している Web 上で動作するモデリングツール）で図を開く処理を計測してみました。Rails のログを見ると、サーバの処理時間のうち、40% は DB 待ちでした。一回のアクセスで、少なくとも数十の SQL が乱れ飛びます。html や javascript の生成は 40% 程度を占めています。残りは、フレームワークやコントローラで消費されています。（このログは、Rails がとっているログなので Rails の中しか計測されません。）

この手のアプリは、ネットワークがボトルネックになることが多いのですが、今回は ab（Apache Bench）を使って、並列性 1 でベンチマークをとっているので、ネットワークはそれほどボトルネックになっていないと考えています。（処理は重いので、CPU はいっぱいいっぱいでした。Kodougu がそこそこ人気が出たら、今のサーバは即パンクしますね。パンクすると困るのですが、人気が出なくても困るので・・・どうしよう。）

言語の処理速度は一概には言えないのですが、上記のベンチマークによれば、Python だと Ruby の 2 ～ 3 倍、Java だと 20 ～ 30 倍になります。たとえば、Kodougu をそのまま Java で実装すれば、パフォーマンスは今の 2.5 倍くらいにはなります。（プログラミング言語の処理速度の向上がそのままトータルなパフォーマンスには現れないところがミソです。）

もっとも、サーバを 3 台余分に準備すれば（運用コストはサーバ代、人手も合わせて年間 100 万増くらい？）、Ruby のままで同等のパフォーマンスを得られるということでもあります。最近のアプリはステートレスなので、台数はわりと簡単に増やせます。DB サーバは増やすのは難しいですが。

実際のところ、Web アプリはキャッシュを使ったりして高速化をするので、言語のパフォーマンスはアプリのトータルなパフォーマンスの中ではそれほど大きな位置を占めません。まじめに最適化してしまえば、Kodougu を Java で実装してもパフォーマンスは 20 ～ 30% 位の差しか出ないのかなと考えています。Kodougu はモデリングツールということもあって、Web アプリの中では例外的に計算的な（≒ Ruby に不利な）種類のアプリです。通常の Web アプリではもっと言語間の差が小さくなるんじゃないかなと感じています。

■ Ruby の生産性
以下のような意見があります。

日本 Ruby 会議 2007 の Dave Thomas のスピーチのログより

ある研究によれば、生産性はそれぞれのプログラマでそれぞれ違う。でも、あるプログラマに着目すれば、そのプログラマが時間あたりに書けるコードの行数は、プログラミング言語によらず決まっている、たとえば一年に50,000行なのだそうだ。行数が決まっていたら、どの言語で一番多くのことを達成できる？そう、Rubyだよね。

なるほど。そういう意味では、Ruby の生産性は高いです。通常、モデリングツールのコード行数は Java や C# で 10 ～ 100 万行程度（製品コードのみ）になります。Kodougu は 5000 行程度（製品コードのみ）です。Kodougu は Web であるがゆえに、機能的に優れた面とそうでない面とがあるので単純に比較することはできません。少なくとも生産性が 10 倍になることはありませんが、50 ～ 100% 程度の向上はあると思います。

（ただ、アプリの規模が大きくなればなるほど、Java でも Ruby でも変わらなくなる気がしますが。）

■ トータルなコストパフォーマンス
Java を使った場合と比較して、サーバ運用コスト増が開発費の 20% ～ 30% 位に収まってくれるなら、Ruby はアリだと私は考えています。保守フェーズに入ったら、サーバ運用コスト増がもっと大きくても大丈夫なんじゃないかとも考えています。

■ まよめ
さて、破滅的に遅い Ruby ですが、Web アプリで Ruby が許される本当の理由は、Web アプリの負荷の質にあります。たとえば、ゲームのリアルタイム 3DCG の処理を Ruby で書くのは自殺行為です。こうしたアプリは常に CPU に負荷をかけるアプリです。（CPU でやらせること自体が自殺行為といううわさもありますが。）Web アプリは、動的コンテンツとの割合次第ですが、キャッシュなどを仕掛ければ、たまに CPU に負荷がかかるけど、いつもは比較的 CPU が暇なアプリに分類されます。今のところ、Ruby はそういう負荷の質を持った用途で使うべきものです。

クライアントでも、Ruby が使えるかどうかの判断基準は、結局負荷の質をどうとらえるかという問題に落ち着くのかもしれません。ただ、総じていうと、サーバの CPU はいつもそこそこ忙しいですが、クライアントの CPU はいつも暇です。ゲームとかやってない限り。CPU の高速化に伴い、多くの処理が負担でなくなってきていることも事実です。Web アプリのクライアントが JavaScript でも書けることから、クライアントで Ruby が活躍できる範囲はむしろ大きいのではないかなと感じています。

そうそう、Twitter もRails を使っているそう（参考）です。リクエスト数が多そうなサービスなので、Rails を使うのはチャレンジャーだと思うのですが、意外といけているようです。凄い・・・。

長いこと積読になっていた「JavaからRubyへ」をようやく読み終わりました。（※ この本を買ったのは 4 月か 5 月。）この本は、日本で Java の案件をこなしているマネージャが読んでピンを来るものなのでしょうか。マネージャ級の人に聞いてみたいところです。

大筋要約してしまえば以下の通り。
・ Java で対処するとコストが大きくなるプロジェクトもある。なんでも Java じゃリスクが高いよ
・ Ruby（というか Rails）はその中のいくつかのプロジェクトに対処できる
・ Ruby の導入にあたって、パイロットプロジェクトの実施方法
・ Ruby の導入手順（教育、リクルーティングなど）
・ そのほか Ruby や Rails の紹介（ある意味、どうでもいい）

多分、そこそこの規模のある SI 企業であれば、将来有望そうな新技術のパイロットプロジェクトを走らせて、定量的、定性的なデータの収集を行っていることでしょう。この本の位置づけとしては、その対象に Ruby（というか Rails）を含めた方が良いという啓発本なのかも。

Amazon のレビューより（tDiary のたださんがかいてらっしゃる？）：

だいたいマネージャ層には、本書に登場するDave ThomasやMartin Fowlerの名前などなんの威光も持たない。

この本がこうしたヴィジョナリーを挙げているということは、海外では威光をもつということなのでしょうか。ちょっと気になります。誰かわかる人いないかな。

日本ではこうした改善はボトムアップに上がっていくところがあるので、この本は末端の開発者が手にとったらいいのかもしれませんね。

■ 追記（2007/6/28 5:41）
はてブにコメントがついていました。どうやら、訳者の方のようです。

はてブコメントより、「この本は、日本で Java の案件をこなしているマネージャが読んでピンを来るものなのでしょうか。」：

弊社経営陣にはリーチしました

これは素晴らしい話ですね。確かに、永和システムマネジメントさんは、Ruby に対して非常に熱心（会社として熱心）という印象があります。まったく同じというわけにはいかないのでしょうが、この本で書かれているような段階を踏んで、会社として「Ruby やりますよ」って宣言しているわけなのでしょうから、やはり凄い話です。

Rails を使ったアプリに限った話ではありませんが、ファイルをアップロードする機能を Web アプリにつけたときに、ファイルを DB に入れるか、Web サーバにファイルを保存するかについてです。

私は Web サーバに保存すべきと考えていました。Web サーバとアプリケーションサーバ（Rails のサーバ）を分けている場合、静的ファイルはWeb サーバが処理して、動的コンテンツはアプリケーションサーバが処理してというようなことをする場合があります。DB に入れると、アプリケーションサーバを経由しなくてはならないので、こうした構成が取れなくなります。ただ、Web サーバを複数台にする場合、ファイルアップロード時に全ての Web サーバにファイルをコピーする手間がかかるというデメリットがあります。（バックアップの手間も一手間増えます。）

もともと私は、DB に静的コンテンツをいれると、Web アプリのレスポンスが遅くなるという問題が発生すると考えていました。ただ、この問題は Rails のキャッシュ機構を使えばある程度回避できます。この場合、静的コンテンツも全てアプリケーションサーバが処理することになります。それぞれのサーバが DB からファイルを取り出してキャッシュをするので、ファイルの管理は楽になります。

もっとも、動画アップロード＆配信サイトとか、データ量が多い場合は、ファイル置き場とアプリケーションサーバは分けざるを得ない（ストレージにも IO にも問題が発生する可能性があるので）ので、この方法はとりづらいですが。

所詮はケースバイケースですが、一つあたりのファイルがそれほど大きくなくて、ファイルの総容量が 100GB 以内に収まるのなら（最大容量は適当）、DB に入れるというのもアリかなと思うようになりました。Kodougu では、アイコン画像などがアップロード可能なのですが、今は DB に入れています。