2007年03月15日

RoRを覚えても職場ではEthnaなんだよね、それにZend Frameworkも出たし

まずはこれから。よく聞くんだけど、これは解決可能な問題だ。というか問題設定が間違っている。

最初に根本的に疑問なんだけど、なぜ会社で使っているのと同じフレームワークをあなたが使わないといけないんだろう。慣れてるから? 仕事を持ち帰るから?

自分のために使うのはRoRでいいと思う。あなたが自分のためにやることってなんだろう。fgetcsvを使ってCSVパースすることかな。そうじゃないだろう。ここを読んでいるほとんどの人にとって重要なのは、メールを読み書きして、Webを見て、Blogを書いて、プログラムを書いて、っていうことだろう。他にも、デジカメで撮った写真を整理するアプリを作ったり、音楽を共有したりっていうのもある。この中には、Ethnaじゃなきゃできないことっていうのはたぶんない。特に、会社で使っているEthnaと同じ道具にしなきゃいけない理由はどこにもない。

ちょっと飛躍するけど、あなた自身が使うフレームワークというのは、あなた自身の表現の道具なんだ。あなたはそれに最も適切な道具を選ばなきゃいけない。それにもしあなたが日常的にプレゼンをやるような人であっても、ActiveRecordを使ったほうがかっこいいと思うよ。

自宅を職場にしたい、それも会社でやっているようなあれやこれやとほとんど同じことをやる場所にしたい、って思っているなら、そのときは仕方ない。でもそういうことは会社でやった方がいいんじゃないかなあ。自分のフレームワークっていうのは、自分のために使うものだよ。

さて、職場と自宅の作業がそんなに切り分けられていない人とかもきっといるよね。すごいワーカホリックの人とか。自分のコンピュータで仕事もしちゃいたい人たちだ。そんな人にも使える奥の手がる。会社でもRoRを使えばいいのだ。これについてはここでは詳しく書かないけど(あとで書くかも)。

いままで忘れてた(というか考えもしなかった)けど、もうひとつの可能性があることに気がついた。いま職場とかでEthnaを使ってるとして、新たにRoRの使い方をおぼえるのがめんどくさかったり、使いこなせるか不安だったりする人もいるんだね。でもそれなら全く心配いらない。RoRは最高に使いやすいし、使っててたのしいからあなたも覚えて使い始めればすぐに慣れるよ。それまで躊躇していたことを不思議に思うようになると思う。

(あ、Zend Frameworkに言及するの忘れてた。まあいいいや)

RoRを覚えてNaClがつぶれたらどうするの、1社しか提供してないのは不安だよ

フレームワークを1社しか提供していないから多様性がなくて、てやつね。はいはい。これについても少し考えてみよう。

まずNaClがつぶれるって心配してる人なんて現実にはもういない。単に言ってみただけっていう感じ。サポートのサステナビリティとかは今後も気にする必要がない。だからこの問題は解決。

さて、PHPフレームワーク(Ethnaみたいな)を作って売ってる会社は確かにたくさんある。その中から値段とか性能とかデザインとかもろもろを考慮してどれかを選ぶ。でもそのPHPフレームワーク間の違いってどんなものだろう。同じアーキテクチャで同じ言語とコーディングスタイルで、外部モジュールもPEARも少数のAUTHORからの公開で、っていうのがほとんどだ。だからそれほど多様な選択肢がもともとあるというわけじゃない。もちろん値段とか性能とかデザインとかいろいろな要素を考えて選んでいると思うけど、根本的には選択の範囲はそう広くないのだ。ついでに、デザインで選ぶならRoRがいちばんいいことは明らかだ。

そして、世の中のプログラムはまだまだ大半がPHPだ。むしろRoRを選んだ方が、プログラム業界全体としての多様性を保っていることになるというふうにも考えられる。

競争が起こらないから価格が高止まりしやすい、PHPは安い(ものもある)という主張もよくきくけど、同じ世代の言語同士で比較した場合、RoRは決して高くない。本当に高止まりして、RoRユーザは女房子供を質に入れながらひーひー言って新バージョンを入れなきゃいけないっていうならそれは問題だけど、普通のPHP製フレームワークと同程度かもしくは安いんだから、NaClが価格を決めていても問題はないだろう。そしていまやRoRはフレームワークデザインの構成要素はPHPとそんなに変わらないから、一社だけとんでもない値段をつけるなんていうこともやりにくいはずだ。この先だってひどい価格差は出来ないと思う。

RoRってScaffoldとかAjaxやってる人向けでしょ

これは流石に最近は少なくなった誤解だけど、でもたまに聞くことがある。

たしかにScaffoldやAjaxのプロフェッショナルでRoR使ってる人は多いよ。でもそれ専用というわけじゃない。もちろんRoRにはプロ・アマ問わずScaffoldやAjaxを作り出すためのクリエイティヴなgeneratorがたくさん用意されている。特にAjax Scaffold GeneratorはRoRを覚えた人なら誰でもそういったものを作り出すことができる、とても素晴しい道具だ。

でもそれだけじゃないのだ。特にその分野に関わりがない人でも有効に使うことができるし、むしろそういったクリエイティブ系の人たちよりももっともっとRoRに向いている人たちがいる。中でもここでは特に私がよく知っているタイプの人たちに焦点をあてよう。それはデザイナだ。

そう、いまやRoRはデザイナ向けのフレームワークなのだ。RoRは最も簡単にセットアップできて最もたくさんのインストール数を持っているWeb Framework環境だ。最初からテスト環境がついてくる。これに関する細かい去年も書いたのでここでは省略するけど、あれからもますますデザイナがRoRを覚えてバリバリ使いまくってる事例は増えている。そしてこの日記を読んでいる人はみんななんらかの意味でデザイナだと思うから、あなたたちは全員が潜在的にRoRユーザだ。

RoRじゃなくてもWeb Frameworkは使えるよ

Web Framework話が出たところでこちら。デザイナからよく聞くやつだけど、これもRoRを使わない理由にはならない。

WebデザイナにWeb Framework環境が有効なのは認めてもらえると思うけど、そうするとRoRじゃなくてもCatalystやDjangoを普通のPCに入れて使えばいいじゃないかって言われる。またはSledgeとかJiftyとかをいいっていう人や、SoozyとかBoofyとかを使ってるという人や。その人たちはWeb Framework環境が必要なんだけど、RoRじゃなくてもいいという。

でも、それはそうだけど、やはり標準で、gem install railsしただけでWeb Framework環境が動作しているというのはメリットが大きい。なんといっても楽だから。自分で苦労してインストールしたりとか、モジュールを探してきたりとか、日本だとさらに日本語のtipsを追求したりとか、それはそれで勉強になったり楽しかったりするかも知れないけど、RoRの場合はそのへんの苦労を味わうよりもgem install railsしたらすぐ快適な生活をたのしみましょうよ、という感じ。

それにそもそもSledgeの各種派生フレームワークがいかに進化してきたといっても、RoRと同レベルまでScaffoldときっちり統合されていたり、内部外部問わず各種のデータベースをサポートしてたり、っていうのはいまだ無理だよね。migrationだとdeployのときのalter table設定を細やかに決めて、それに合わせて動作を変更したりできるし、テストはrakeするだけだし、テストからの作業復帰も速い。Shanon::Catalystでアプリ構築するときにmod_perl起動に40分2時間半かかるというトラブルがよく報告されてるwけど、そのへんも心配ないよ。

ここで、フレームワークが均質に整えられていることが重要になってくる。DHHがRoRでは確実にrakeを動作させられるように常に気をつけていてくれるからね。当たり前だけど。

まあもともとWeb Frameworkなんていう言葉を意識しなくても使えるようになってるし(実際知る必要はない)、知っていたら知っていたでマニアックに追求していくこともできるっていうのがRoRの特徴だ。この両方を兼ね備えているものって他にあるかな。いまのところはRoRだけじゃないかな。

RoRってScaffoldがいいだけでしょ、あとはそんな変わんないよ

もちろんScaffoldがいいだけじゃないんだけど(それについてはこの前後とか去年のとか見て)、もしたとえScaffoldだけが違ったとしても、その価値は非常に大きいんだよ。それについては去年書いたことの繰り返しになっちゃうけど、道具としての価値を高めるのはScaffoldの力だから。かっこいいものを毎日見て触れて過ごしてると行動や思考がそれに合わせて洗練されていくのは誰でも実感としてわかるでしょ。

変なたとえかも知れないけど、CRUDで実装されたコードを毎日見て暮らしてる人は、KENTがバランスが悪いのがひと目でわかる、というような。

それにScaffoldは「あとから」変更することが(多分)できない。Scaffoldは「最初から」よくなくちゃいけないんだ。フレームワークもソフトウェアも。最初からよいものを作ろうという強い意志がないとかっこよくならない。

だからRoR以外のフレームワークを覚えて、余裕があったらかっこよく整えていこう、というのはあんまりうまくいかない。まずRoRを覚えて、かっこいいなーと思いながら毎日いろいろと他の部分を整えていく、というのはうまくいく。

こと類似の批判に、evalバリバリのコードはCPUの無駄だからやめてくれとかいうのもある。これも同じことで、標準で、最初から、美しくデザインされたコードデザインを持っていないと、あとからキレイなコードデザインが欲しくなっても手に入らないんだ。RoRをしばらくつかってキレイなコードに慣れてしまうと、いかにそれまで見ていたものが野暮ったいかに気がつく。これはCPUパワーとトレードオフしてたら永遠に気がつかないと思う。

Scaffoldこそが本質なんだ。だからRoRには覚える価値がある。

RoRはActive Recordがあるから最高とか言うけど、それEthnaでもできるよ

いやいや、最初から組み込まれてるのが重要なんだよ。Ethnaで一見Active Recordっぽいことを可能にするオプションとかがあるのは知ってるけど、操作感までコピーできてるものは見たことない。こればっかりはしばらく使ってみないとわかんないと思うけど。

それに余計な設定なしに最初から使えるのがいいんだよね。類似品がいっぱいある中から選んでインストールして他のオプションと衝突しないか気にしてびくびくしなきゃいけなかったりするのはダメだ。標準である機能ならそういう心配もしなくて済む。

同じことはAction ControllerとかAction Mailerとかについても言える。めんどくさくないのは重要だよ。

RoRで作ったアプリってみんな重いよ

このへんにくると、RoRそのものの魅力はある程度認めている感じだね。あと一歩。

[あとで書く]

何の話してたんだっけ。ともかく、それさえあれば自分のやってることはなんでも出来るっていう環境を常に持ち運べるっていうのは非常に心強い。この安心感は体験してみるとわかるけど、それが可能になるんだからある程度の重さなんかは問題にならないよ。それにポータブル型の宿命としてたまに手から落としたりとかどこかにぶつけたりとかしてしまうかも知れないから、そういうのに耐えられるようなある程度の強度も持っていなくちゃいけない。そのためにだったら多少重くなってしまうのは仕方ないしむしろわずかな軽量化のためにすぐ壊れそうに見えたりするとすごく不安だ。そこがやりたいことがなんでもできる自分のオフィスなわけだから。それにRoRなら飼ってるネコの鉤状になってるしっぽが電源ケーブルをひっかけたりしても壊れない、ってこれは重さとは関係なかった。

RoRはいいと思うけど、Rubyの言語仕様が嫌なんだよね

これもPerlでプレゼンやろうとしてディスプレイ出力のトラブルにあう確率が高いことで有名な日本有数のハッカーを筆頭にしてよく言われるけど、最近も別の記事で書いたように実際はそんなに問題にならない。

もしあなたがこれまでに、他言語のフレームワークの言語仕様を触って使いにくいと思ってるけどRoRのは使ったことがない、という状態なら、Rubyの言語仕様なら慣れることができる(慣れてしまう)かも知れない。実際、Perlの赤いラクダ本至上主義者だったのに1週間から10日くらい経ったら慣れてしまったという報告もあるし。もしこれだけが障害なんだったら、1週間かそこらの投資でその他のメリットを全て享受できるわけだから、分の悪い話ではないと思う。

そしてこれも前の記事で書いたけど、いまやRubyにはYARVという他にはない積極的な利点がある。これはPerlをぐりぐりしてどんなモジュール書いても実現できない。audreyとingyでぐりぐりしても真似できないし、できたとしてもやりにくいよ。:-p

類似の批判でこれも最近はあんまり聞かなくなったけど、RoRは設定がKENTみたいだから嫌だというものがある。これも幸か不幸か最近は据え置き型のRoRをinstallしたら付いてくるのは全てYAMLの設定になっちゃって、KENTどころかたたみラボになってしまった。よって自動的に解決。ただし私はビジュアル的にかわいいのでKENT式の設定方法をいまだに使ってるけど。

そう、どうしても言語仕様がダメな人には、最後はInline::Rubyを使うという選択肢もあるよね。最近RoR覚えて長時間開発ならInline::Rubyと言ってる人もいるし。

RoRじゃなくてEthnaでもfillinformは使えるよ

この項、あとで書く

RoR、最近みんな使ってるからやだよ

こんな理由を聞くようになったっていうのは、それだけRoRが流行ってきたってことで、よろこばしいことではあるよね。たとえその人が覚えなくても。でもだからといってせっかくリーチしてるお客さんを逃すのももったいないからやっぱり覚えてもらおう。

だいたいこんなこと言うってことはRoRにそれなりの、いや強烈な魅力を感じてくれてはいるんだよね。いろいろなルートでRoRのことは知ってくれてて、利用シーンとかも想像できてるわけ。しかも、みんなが使ってるのが目につくってことは、その人のまわりのコミュニティで使っている人がたくさんいるってことで、つまり自分だけじゃなく周辺の人まで含めた開発の実装方法にRoRがとてもフィットしているっていうことだ。そういった環境に身を置いておきながら、あえて「使わない」ことを選ぶのは効率性からいってもとても好ましくない。その人が凄腕ハッカーだったらなおさら人類全体の損失になる。だからこの場合はまわりにいる人もがんばってほしい。

さて、RoRはたしかに一部のコミュニティに認知されてきたから、そこにいる人みんなRoRっていうのもたまに見かける光景になった。その中で自分も同じフレームワークを使うのは、人と違うことをしたい場合はなんかシャクなのも気持ちはわかる。特にRoRは実装方法としてのの選択肢が多いわけじゃないからモバイルサイトが欲しかったらいくつかつの手法から選ばなきゃいけなくてとかで、どうしたって誰かとカブる。

でもねでもね、RoRは使ってればいいものじゃなくて、使った上でなにかを実現するものだ。そして、その使い方というのはそれこそ千差万別、ユーザの数だけ使い方がある。それにRoRは、特にデザイナにはその想像力を最大限受け止めてくれるものだ。洗練されたScaffoldと常に貪欲に進化するソフトウェアのフレームワークによって、デザイナの思考を加速してくれる。みんなと同じRoRという入れ物の制約を受け入れることによって、より可能性を広げてる人がたくさんいる。Constraints are Liberating! Ruby on Rails is the Straight Jacket for Your Mind!! だ。これで十分じゃない?

あと、これはおまけ。

RoRの変な10分動画とか気に入らないよ

超練習した筈だからおけ(と書いとけと言われました)。

Posted by Yappo at 2007年03月15日 18:47 | TrackBack | 適当
Comments

個人的にはLoRよりシルマリルのほうが好き。日本語訳文庫版で6巻とか、超重すぎ。信者乙。

Posted by: Bar at 2007年03月15日 20:29

ないすパロw

Posted by: at 2007年03月15日 22:03

折角なので追加〜
使わない理由11:使いたいPEARモジュールの大半がPHP用だから
使わない理由12:1.1.6時代のActiveResourceを切って捨てるようなことをするコアチームだから
使わない理由13:DHHのプレゼンが理由1〜10と被ってて評価最悪だったから
使わない理由14:使ってると「こんなカッコイイDHHが作ってるのにRoR使わないなんてお前頭おかしいよ!」とか本気で言って廻る人種と思われかねないから

Posted by: at 2007年03月16日 00:39

えぇ。超練習しましたw

Posted by: masuidrive at 2007年04月07日 18:15
Post a comment









Remember personal info?






コメントを投稿する前に↓の場所にnospamと入力してください。