ウェブアプリになってから、あまり画面そのものをモデリングする機会がありませんでした。スタンドアロンの GUI アプリでは画面のモデリングが必要となるケースが結構あった（複雑な画面を持つアプリケーションは画面上に配置されるコンポーネントを戦略的に管理しないと開発が成り立たなくなる）のですが、Kodougu を含めウェブアプリを作るようになってからあまり意識していませんでした。所詮画面のあるシステム、そうそう違いがあるとは思えないので、ためしに画面設計に関するモデリングを検討してみました。

続きを読む

私は、マークアップエンジニアという言葉は知りませんでしたし、ぶっちゃけ 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 のときに技術的にも何かが起こったんだなって感じます。「気づき」のあるなしとか些細なことなんですけど。

このサイトは、Ruby, Rails, JavaScript などプログラミング系の話題を取り扱っているせいか、アクセスされるブラウザの傾向が一般とは違うのだろうと考えていました。

7/1 ～ 7/9 までのアクセス結果（Google Analytics）を見ると、セッション数 2160 に対して Firefox は 1210（56.02%）、IE は 671 （31.06%）でした。技術系サイトなので Firefox の割合が多いことは当然ですが、もう一つ傾向がありました。Firefox ユーザは 90% 以上が最新版（現時点で 2.0.0.4）を使っているということです。IE ユーザは、75% 以上がいまだに IE6 を使っていました。
（ちなみに、Windows ユーザーは 80% 程度です。OS によらず、Firefox が浸透していることがわかりますね。）

バージョンアップにかかる手間が Firefox の方が少ないという事情もあるでしょうし、こんな辺境（？）のブログを見に来るような技術屋は、総じて新しい物好きが多いということもあるのかもしれません。あるいは、Firefox は最新版に対する信頼性をユーザから勝ち取っているといいうことかもしれませんね。

Firefox ユーザのこうした傾向は Web アプリの開発者としてはなかなかありがたいものです。テスト対象のブラウザのバージョンを絞ることができますから。

私は Sleipnir + Trident ユーザなので、大きく見ると IE ユーザですが、Web アプリは最初は Firefox でテストをしています。

まあ、結論としては、「世の中全部 Firefox になっちゃえばいいのにな！」ってところで。(^^;

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

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

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

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

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

ニフニフ動画を見てみました。ニコニコ動画の劣化コピーです。ニフティがやるんだからもうちょっとましなものが出て来るんだと思っていましたが。

切込隊長BLOG（ブログ）: ニフニフ動画がネット諸氏に送る絶望より

何この脱力感。営業数字が上がらない営業マンを大声でドヤしつける管理職のそれではなく、数ヵ月後の資金繰りに思い悩む経営者が頭を抱えるタイプのダウナー系のインパクトを見る者に与えることにかけては、やはりニフティには一日の長がある。

あまりに秀逸なコメントに脱帽。そう、ニフニフ動画を語るにはこの脱力感が一番適当だと思います。画面を見た瞬間、「うわ、やる気ねぇ」って感じさせるのは、なかなか凄いことですよね。多分、急ごしらえのシステムで作りこみをしている時間が無かったんでしょうけど。

2007/6/14 2:36 時点でランキング一位が「すごいぜカスラック」（JASRAC をこき下ろした動画）というのもニフニフ動画を象徴している気がします。サイトコンセプトから何から何までパクリで構成されているという意味では、ニコニコの無法っぽさのさらに斜め上を行っています。この点において、むしろ褒めるべきなのかもしれません。

わずかにニフティのやる気（＝押す気満々の自爆スイッチ）を感じさせるのはこちらのページか。

いやいや、しばらくニフニフから目が離せませんねぇ。

追記（2007/6/14 3:18）。

でも、成功する可能性がゼロなわけではありませんよ。ニコニコは有料化で失速するかもしれません（※）し、ニフティなら最初からある程度集客できるかもしれません。Rimo と違ってニコニコとガチンコになるのは、かえって良いのかも。

※ 負荷を抑えるため、ニコニコでは、初期に登録したユーザー以外はアクセス制限がかかっていて、かなり不便らしいです。有料ユーザーになればいいのですが、お金を払いますかねぇ？

日々世相に疎くなっているような気がしますが・・・Google Gears というものが発表されて、世間の注目を集めているようです。Google Gears をインストールするとブラウザ（IE/Firefox）を拡張して、新しい JavaScript の API を提供してくれます。API には、ローカルにデータとアプリ（html と js）を保存する機能が含まれていることから、オフラインでも Web を使えるようになる技術として注目を集めています。

世の中全てがブラウザで済んでしまう時代が近づいていますね。Kodougu でも使えそうなので、少しわくわくしています。より簡単に対応できるように、Google Gears のプログラミング作法を調査しておきますかね。

とりあえず以下のような記事を見つけました。

【ハウツー】早速プログラミング! Google Gearsを使ったアプリを作ってみよう
(1) Google Gearsで使われている技術 | エンタープライズ | マイコミジャーナル
http://journal.mycom.co.jp/articles/2007/06/01/gears2/index.html

Google Gears・・・何かに似ていると思ったら、CodeGear に語呂が似ているんだ。こんな激動の時代に Delphi なんて生き残っていけるのかなぁ・・・。

Apache のログを眺めていたら、AB（ApacheBench）のアクセスは HTTP 1.0 クライアントとして認識されているようです。このため、AB では、コンテンツ圧縮など HTTP 1.1 を前提にした処理は実行されない可能性があるため、正確には速度を計測できないかも・・・。（少なくとも、AB からのアクセスでは、mod_deflate は走っていませんでした。）

これ・・・私の勘違いですかね？？？

Kodougu のサーバは回線がしょぼい（10Mbps を数台で共有している）ので、結構重要な気がしているのですが・・・。

私は Kodougu について語るとき、いつも「重い、遅い」と言っているのですが、ベンチマークをとったことはなかったので、手始めに AB（Apache に付属するベンチマークソフト）を使って速度を計測してみることにしました。

実行したコマンド

ab -n 100 -c 10 http://www.kodougu.net/rendering/diagram/1

計測したのは一番重くなると思われるモデリングツールを表示するページで、10 のコネクションで、合計 100 リクエストを送ることを試してみました。（もっとも、このベンチマークは、あくまでリクエストを送ってレスポンスを返すまでの時間を計測するものなので、たとえば、script タグで関連付けた外部 JavaScript ファイルの DL 時間などは計測できない・・・と思います。今は敢えてその辺を無視しています。）

ベンチマーク結果

Benchmarking www.kodougu.net (be patient).....done

Server Software:        Mongrel
Server Hostname:        www.kodougu.net
Server Port:            80

Document Path:          /rendering/diagram/1
Document Length:        24522 bytes

Concurrency Level:      10
Time taken for tests:   22.140625 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      2479000 bytes
HTML transferred:       2452200 bytes
Requests per second:    4.52 [#/sec] (mean)
Time per request:       2214.063 [ms] (mean)
Time per request:       221.406 [ms] (mean, across all concurrent requests)
Transfer rate:          109.30 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       15   21   8.1     15      46
Processing:   516 2145 2189.3   1390   11765
Waiting:      421 2025 2163.7   1281   11640
Total:        531 2166 2188.7   1421   11796

Percentage of the requests served within a certain time (ms)
  50%   1421
  66%   2046
  75%   2453
  80%   2671
  90%   5453
  95%   7062
  98%  10031
  99%  11796
 100%  11796 (longest request)

サーバは Mongrel となっていますが、間に Apache Proxy が挟まっています。秒間 4.52 リクエストを処理することができるようです。これは、あくまで Web にあげているバージョンで、ローカルで動作させている最新版はさらに重くなっていて、この半分くらいの性能しか出ません。まだ分析していないので、回線、Web アプリ（Rails）、DB（MySQL）のどれがボトルネックになっているのかはわかりません。

まあ、ユーザが少ないうちは、この程度の処理能力でも問題ありません。でも、100 ユーザくらいが同時に使ったら、図を表示するだけで何十秒も待たされることになり、現実的に使えるものではなくなってしまいます。現在は、サーバは一台（CPU:Core2Duo/Mem:1GB）なので、サーバ台数を増やしていくという選択肢もありますが、アプリケーションだけでも 10 倍くらいは改善しないと使い物になりませんね。

機能拡張が落ち着いたら、パフォーマンス改善をしないとなー・・・。

左側のメニューの下のほうに日本地図があると思います。これは、なかのひとというブログパーツです。アクセス解析ツールの一つなのです。特徴としては、「どんな組織の人がアクセスしてきたのか」に特化していることです。

仕組みとしては、whois 情報を元に、経度緯度に変換、地図上に表示とのことです。

よく、この業界では「××のなかのひと」という表現をしますが、まさにこのツールはどこのなかのひとがアクセスしてきたか調べるためのものというわけです。一日で開発出来てしまいそうなツールですが、アイディアが面白いのでしばらく使ってみます。

ウェブに接続していると常に感じることは、タイムラグが結構あるということです。何かの本では、ウェブで世界と瞬時につながるという話もありましたが、そういう意味で言うとウェブはまだまだ発展途上ってことですかね。

最近、生産性に関する議論があって面白かったので、そのやり取りを時系列に並べてみました。

2007/2/11
山形浩生 の「経済のトリセツ」　　Supported by WindowsLiveJournal - 生産性の話の基礎
http://d.hatena.ne.jp/wlj-Friday/20070211/p1

2007/2/12
池田信夫 blog 生産性をめぐる誤解と真の問題
http://blog.goo.ne.jp/ikedanobuo/e/cd4e52fd7cca96ac71d0841c5da0cb75

404 Blog Not Found:生産性より消費性
http://blog.livedoor.jp/dankogai/archives/50762325.html

2007/2/13
分裂勘違い君劇場 - アルファブロガーたちの地位争いが優良コンテンツを量産する
http://d.hatena.ne.jp/fromdusktildawn/20070213/1171359965

山形浩生 の「経済のトリセツ」　　Supported by WindowsLiveJournal - それでも賃金水準は平均的な生産性で決まるんだよ。
http://d.hatena.ne.jp/wlj-Friday/20070213/p1

飲み屋でやったら 2 時間（もかかるのか？）で済んじゃいそうなやり取りですが、ウェブでのやり取りでは数日間は最低かかりそうです。ただ、生み出す価値は計り知れないです。（知見のある方々が公の場で、ある意味万人に向けたわかりやすい議論を展開するわけですから。）

ウェブでタイムラグを感じる理由は、例えば情報収集のアンテナの反応速度によるのかもしれません。例えば、はてな RSS は、記事を書いてから 12 時間くらいたたないと新着記事を拾ってくれない場合があります。

さて、タイムラグがあるといいつつも、上記のような議論の場合、人間の反応速度としては、これが限界（つまりウェブのタイムラグがボトルネックにはならない）かもしれません。リアルで忙しいのにウェブに費やせる時間なんてたかが知れていますから。

今のウェブは「瞬時ではないけどそこそこすばやく、そこそこ整理された情報に触れたり議論したりすることができる」ところに価値があるのかな・・・？