Rails勉強会＠東京第25回のポジションペーパ。今月こそは参加するぞ！

ポジションペーパ（PNG）

■ 追記（2007/12/17 2:14）
今回も行けませんでした。orz

Rails勉強会＠東京第24回用のポジションペーパです。

PNG 形式のポジションペーパ
PDF 形式のポジションペーパ

■ 2007/11/18 追記
今回の勉強会は所用ができて、結局いけませんでした。orz

日曜は Rails 勉強会に行ってきました。今回で三回目です。この勉強会は、5 ～ 6 個のセッションを前後半（それぞれ一時間半）に分けて行います。オープンスペース方式で、どのセッションに参加してもいいし、途中でセッションを移動しても構いません。

続きを読む

明日起きられたら、懇親会（昼飯）から参加する予定の Rails 勉強会用のポジションペーパです。

ポジションペーパ（PNG）
縮小版ポジションペーパ（PNG）

disられそうな PDF 版も置いておきます。

ポジションペーパ（PDF）

Rails 開発者こそモデリングすべきだよなぁって唐突に思いました。Rails は DB スキーマさえ作成すれば、そのあとはレールに乗って高速に開発ができるのですが、当たり前の話 Rails は DB スキーマの設計方法は教えてくれません。ましてや、どんなソフトウェアを作ればいいのか教えてくれるわけでもありません。

Rails は「何を作るか決めてからがすごいフレームワーク」なのです。分析工程は開発者自身が自分のやり方で実施しないといけないのです。

何を作るのかを導き出すのはモデリングが得意です。とはいえ、一般的な UML 本に載っているような開発プロセスはどうにも Rails アプリを記述するには重すぎる気がします。（少なくとも私はそう考えています。）往々にして、図解言語というものは、概要をとらえるには適していますが、詳細に書くと途端に見難くなります。実装レベルのシーケンス図などは、見るだけでも吐き気がします。

そこで、Rails 向けにシンプルな分析工程を考えてみます。

続きを読む

弱い技術者は実はおやじ予備軍というエントリを見て感じた事を書きます。と言っても、このエントリの書いてある本筋には大賛成です。枝葉末節についてです。

弱い技術者は実はおやじ予備軍より

実は、チャンジャーに見えるRailsユーザもおやじ予備軍の危険性があります。「JavaからRubyへ」でこのような意見があります。Javaの世界はフレームワークが乱立していて適切な組み合わせを選ぶのが大変だからRailsで統一されているRubyがいいんだと。 これには、全然賛成できません。悩みたくないからスーパーなデファクトを望むのは、危険だと思うんですよね。ライバルがいないとどうしても進歩の速度が鈍ります。Rails一党独裁よりも、いくつかのフレームワークが競い合うほうが健全なのではないかと思います。

前の Rails 勉強会では Merb というフレームワークが紹介されていました。こちらの記事が詳しいです。このフレームワーク自体はまだ実用には時間かかりそうですが、Rails ユーザも一党独裁問題に対しては、バランスを取り始めています。言い換えると、Rails ユーザはいい意味で Rails に対して批判的です。この流れは、今はかなり進んでいるエンジニア限定ですが、いずれ一般的な Rails ユーザにも波及してくことでしょう。

Rails vs Seasar にでもなっているのか、ひがさんは Rails 系には手厳しいですね。。。

弱い技術者は実はおやじ予備軍より

典型的なおやじ予備軍は、自分で考えるよりも権威のある人にこれだって言ってもらうのを好みます。身に覚えはありませんか。これって頭の固いおやじがスーツなやつらに付け込まれているのと同じです。

今はひがさんも「おやじ」をたらしこむ力が付いてきたでしょうから、「だから Rails 厨は・・・」なんて書き方をされると絶大な効果があります。願わくば、批判するなら Rails ユーザの実態をよく調べてほしいところです。

昨日は、Rails 勉強会＠東京第 22 回に行ってきました。半年ぶりくらいの参加でした。

この勉強会は昼ごろに集まって、やりたいセッション（合計 5 ～ 6 個）を出し合って、前後半それぞれ 3 ～ 4 個のセッションを行うという形式になっています。参加者は、興味のあるセッションに参加します。私は前半は「よろず悩み相談室（？）」、後半は「Finder の実装（render_component が使えないからもっと良い仕様を考えよう）」に参加しました。正直、Ruby にも Rails にも詳しくない私にとっては何を聴いても勉強になります。

前半でおもしろかったのは、with_scope に関する不満でした。要約すれば、with_scope をネストして掛けたいということでした。「blog.user.blogs」というような記述をする時に、blog を検索するのに使った条件を、blogs にもつけたいということでした。（これはこれで関連の意図と違ってしまうので、with_scope の現在の仕様は納得感がありますが、こういう検索を楽に行う機能があったらいいというのは私も賛成です。）ストアドプロシージャで解決するという話は、もっと簡単な方がいいなぁと思いました。なんか誰かが作りそうですけど。

後半は、render_component の改善案についてでした。render :partial の不満点かもしれません。問題点は、二つ。一つは、render_component が遅いこと。もう一つは、render :partial を実行する際の find 関係の処理を記述する場所が欲しいというものでした。後者の不満点を解決するのが render_component ですが、前者の問題で使えません。render_component は Kodougu でも、一部使っています。（メタメタに言われている機能なので、積極的には使ってないですけど。）この話を聞きながら、こっそり Rails のコード（ActionPack）を読んでいました。話についていくのがやっとですが、そこそこ追えるようになってきたかも・・・。

終了後は懇親会へ。一次会はもんじゃ、二次会はさくら水産でした。いろいろな話をした気がしますが、よく覚えていません。(^^; こういう勉強会に顔を出すとみなさんよく勉強されているので刺激を受けます。私も頑張らないとナー。

Rails 勉強会用ポジションペーパです。念のため以下に貼っておきます。

PowerPoint2007 形式
PNG 形式

Kodougu は、こちらの手順で国際化しています。Rails で国際化するのによく使われる Ruby-GetText-Package ですが、PC を新しくしたら、ちょっとはまってしまいました。Windows Vista 上で rake updatepo したら、msgmerge が見つからないというエラーが出ました。前のマシンでは GTK+ をインストールしていたのでこの辺の設定をしていたのですが、今回はまだやっていないことに気がつきました。なんという間抜け。(--;

以下を参照しつつ、対応しました。
http://www.yotabanana.com/lab/20060910.html

新しい PC をセットアップすると、何かしらミスをしますね。。。orz

私が書いたにしては妙に反応のあった「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）
こちらからさらにお返事いただきました。感激。意図が伝わらないのは、釣りっぽい書き方をした私の責任です。スンマセン。丁寧なお返事ありがとうございます。