Rubyをスルーしてた理由 - サンフランシスコへの道　〜the long and winding load〜

ちょっと遅くなりましたが先日、豆蔵主宰の豆ナイトに行ってきました。

私が面白いなと思ったのは、こんなこと。

「Rubyに転んだ理由とスルーしてた理由」
- 牛尾さんのセッション、さすがコンサルタント、(良い意味で)話が上手い。
- Rubyをスルーしていた理由に、超共感。「仕事に使えないから」「所詮一過性の流行ものだろうから」「Railsったって、自動生成の塊でしょ」
- 技術の空洞化の問題点は、おっしゃるとおり大きな問題として今まさに直面中。
- 教育に関する問題を解決できるなら、取り組みたいなぁ・・・なんて考えちゃいました。

「僕と牛尾と校庭で」
- 角谷さんのセッション、熱いお方でした・・・。
- 「楽しい」ということがどこまで「ビジネス的な価値」があるかが、もう少し定量的な事例がほしい。（そりゃちょっと難しいな・・・）
- とにかく「Rubyが楽しくて仕方ない」という想いがびしびし伝わってくる感じでした。

「JavaラーのためのRuby再入門」
- 豆蔵エンジニアの方からのRubyの簡単な紹介。
- dRubyにはたまげた。
- Railsに対しては印象変わらず。O-Rを前提にしたアーキテクチャは、やっぱりEnterprise系(業務システムと読替え可)には難しいなぁ。

とにかく楽しい勉強会でした。特に牛尾さんのセッションは共感することが多く、もやもやが整理された感じ。今後牛尾さんが、ある程度の規模のEnterprise系システムに対してRubyをどう当て込んでいくのかが、非常に興味があります。

それと、驚いたのがdRuby。あんなに簡単に分散オブジェクトしちゃっていいの？って感じ。「昔必死こいてCORBAを勉強したのは何だったの？」「EJBが出てきてあんなに喜んだのは何だったの？」といった感じ。
いいわ〜、あの手軽さ。衝撃的だった。あれだけのためにRuby使いたくなっちゃう。

その後の懇親会も、なかなか楽しいものでした。参加していた現場のPMクラスの方が豆蔵のコンサルタントさんとやりあっているのも、ちょっと笑えた。お酒が入ると、お互いどうしてもね。

今回で２度目の豆ナイト参加(１回目はもう数年前)でしたが、やはりいい刺激になりますよね、社外の勉強会って。これからも探して参加するようにしようっと。

・・・ところで皆さん、Railsって、どう思います？とくにあのDB周りの規則。命名規約は受け入れられます、所詮決め事だし。ただ、主キーがID列になってしまうというのだけは、どうしても嫌。自動生成する側からすれば、当然の選択かもしれないのですがね。でも嫌。

ある程度以上の規模のシステムにおいて、主キーにID列を使うのはほんっとに避けたほうが良いと思う。制的モデルから設計思想や業務が見えてこないから。

実は過去にあるパッケージのカスタマイズ案件で、ひどく苦労しまして。ええ、そりゃひどい苦労を。

よくできたモデリングって、E-R図を見るとシステム全体が見えてくるんですよね、業務の特性とかデータの流れが。ところが主キーとしてID列を使われてしまうと、E-R図を見てもさっぱりわからない、データのまとまりやら作成単位やら流れが。

データの関連性を補うために必然的にFKや制約を利用せざるを得ないのですが、これがまた扱いづらくて。概念モデルや論理モデルでFKや主キー以外の一意制約を表現することは有効だと思いますが、物理に適用してしまうと、一気に取り扱いが難しくなってしまう。単純な話、テストの生産性がガクンと落ちるのですよ。

・・・あ〜、この辺の議論をRailsに詳しい人としてみたい。「嫌なら使わなければいいじゃん」「RailsをEnterprise系で使うのは無理だよ」とかいう思考停止状態の議論ではなく、「どうしたらこんなお悩みを解決できるかねぇ」という議論を。

やはり、勉強会や懇親会でぶつけてみるか！