最近、Rails 以外の Webフレームワークをいろいろ見て思ったこと。

Rails, Think Add comments

結論:Rails しか見てないのは良くない。

自分がよくやるRailsアプリの作り方は、(仕事でバリバリやってないので、作り方、結構適当です。けど、こういう流れで作ってる人も多いのでは?)

  1. だいたいのコンセプトを決める。
  2. UI設計(ホワイトボード、紙、最悪の場合:脳内)
  3. DB設計(って、言っても必要そうなエンティティ(Railsで言うとModel)とリレーションを考える。)
  4. DB設計に従って、さくっとScaffold。きゃは。
  5. 不要なアクションを削る。必要なAction と View を作る。(もちろんControllerもね)
  6. UI設計に従って、装飾。(Viewをいじりながら、CSSいじる。)
  7. 機能追加。Scaffoldだけではさすがに終われない機能は、もちろん作りこみます。
  8. 作り込むまでもなく、plugin があれば勿論ありがたく入れる。DRY!

5. ~ 7. と、デバッグはぐるぐるループしますが、だいたいこんな感じで作ります。

と、説明したところで、最近「UI」についてイロイロ考えてたのでまとめてみます。たまたまみつけた「はぶさんのRailsやChuraのいけてないところ(2006年のエントリー)」がきっかけになりました。

1.UIを設計する
2.UI設計の成果物を元に、DB設計をする
3.DB設計の成果物を元に、UI実装を自動生成する

RailsやChuraってのは、3.のところをやってくれるんだけどさ、手順全体を見たらださいじゃん。「1.の成果物(が想定しているUI実装) イコール 3.の成果物」に本当に出来るの? ちゃうでしょ。凝ったUIだったら駄目じゃん。CSSで頑張る? それで済む程度のシステムだったらいいんだけどね。
~~~
1.の成果物をストレートにUI実装に使えるほうがいいじゃん。

例えば、「1.UIを設計する」 のところで、HTMLモックを作ったとしてそれが実装として使えないんですよね。Rails Viewにコピペ(だけじゃなくてタグ化とかも)だし、ループ制御やIF制御なんか追加すると、結局みんなが昔忌み嫌ったJSPとほとんど変わらないVIEWが出来ると思う。ここ進化してない。

ちなみに、Rails界隈でみんな大好き 37signals の開発手法(物語が多いけど) Getting Real によると

紙スケッチ
-
スケッチは素早く、殴り書きで、お手軽でできるもの;それ以上は必要ありません。書きましょう。走り書きでいいんです。四角や丸や直線なんかのシンプルなものでいいんです。アイディアを頭から紙に写します。目的は、頭の中のコンセプトをラフなインターフェースのデザインに変えるところです。ここはまだ実験段階です。正しい・間違いといったことはないのです。
-
HTMLを作る
-
先ほどのスケッチの特徴(または、セクションやフロー)を元にHTMLを記述してみます。実際に形にすることで、皆がスクリーン上で見ることができるのです。
「Basecamp」では、我々はまず、「メッセージを書く」スクリーンを作り、次に「メッセージを編集する」スクリーン…徐々に開発を進めていきました。
まだプログラミング・コードに手を出してはいけません。あくまでHTMLとCSSの、現実に近い模型を作るのです。完成品にするのは後の段階です。
-
コードにする
-
実験的に作ったものがうまくいって、必要な機能を満たしたのなら、実際にプログラミング・コードを記述していきます。

と、あるんだけど「あくまでHTMLとCSSの、現実に近い模型を作るのです。」は最終的にVIEWにせっせこ書き直してるのかな。 じゃあ最初からHTMLモック(模型)をERB形式でってのは「デザイナと分業!」ってのが難しくなるという、なんともはや。個人的にデザイナと!って形式で仕事したことないので実際どうかは分かりませんが。

それで、いっきに話は飛ぶんですが見つけましたよ!プレーンなHTMLを(ほぼ)そのままVIEW層で使えるWebフレームワーク 。Java界隈の人は気付いてると思いますが。

Wicket (日本語サイト: Wicket-ja )です。もう一気に惚れました。ありがとうJava。ただいまJava。かくいう私も、就職してから4年間はJava(主にStruts)を業務でやってたのでJavaは好きなんですよ。なにが惚れたって、このくだり。

Wicketの最大の目標は、ウェブ・アプリケーション開発にオブジェクト指向を取り戻すことです。

ちなみにこのページに書いてあること全部かっこいい><

さらに脱線するんですが、UIだけさらに特化した話をすると尊敬するS氏から教えてもらったGWT-Extとかね、もうね、どうしろと>< ああ、そういえば、知る人は知っているからいまさら言いふらさなくていいって言われてたんだけど書いちゃった。

なんというか、最近、Railsから離れた目で巡回してたらJavaの底力を見たというか。

大分古いけどエンタープライズで(お仕事で) Rails使って炎上って話
Rails炎上|傲慢SE日記 ~30歳からの挑戦~
Railsについて思うこと
を読んでると、またJavaに戻ってきたりして。炎上ってのは言語やフレームワークとは全然違うレイヤー(生産性が10倍!なんて幻想に惑わされた営業や上層部や管理者etc)が問題なんだろうけどぉ。

Rails とか Java とか言ってる自分は C# な仕事してるんですけどねw

結局、1エンジニアが生涯で携わるプロジェクトの数ってそう多くないだろう(何十個や何百個ではないの意)から、業界の流れが自分にどれだけ影響するんだろうって気もするけど。流れっつってもBlog読み読みしてるだけなんだけどね :-) なんにしても言いたかったのは流行りに流されないように自分の目を持っていたいね。(って自分に言ってる)

===

気になるフレームワーク(というより連携?w)自分用まとめ

  • Wicket + Guice + ActiveObjects (Guiceはあえて使わなくても良いかも)
  • GWT-Ext on GAE (GWTで吐かれたJS/HTMLをアップすればGAEでも動くらしい元ネタ本当かな?Extについては言及されてないっぽい)

問題は何作るかだな。。。

2 Responses to “最近、Rails 以外の Webフレームワークをいろいろ見て思ったこと。”

  1. ybitboy Says:

    確かに自分もなにかと「Rails!Rails!」といきりたっていたかも。
    どんなものもRailsで作れば問題なしという勘違いがあったかなぁ
    この記事やGetting Real、Rails炎上|傲慢SE日記 ~30歳からの挑戦~、Railsについて思うことを見ても”シンプル”や”少数精鋭”っていう言葉が出てきて大事なんだなて思ったよ><
    javaになるとフレームワークがいっぱいあって、何を使っていいかわからないね。
    Wicketは魅力的だけど、導入するには学習コストもかかるからなんだかんだStrutsとかになるんだよね。
    フレームワークはプレゼンテーション層だけじゃないしね。
    Javaも肥大化してきたね(てか既にしている)

  2. Gabu Says:

    選択肢としてフレームワークを知っておくのは重要だろうね。選択に迫られた時に、だいたいの見積もり(難易度とか開発スピード)が出来ればベターだと思う。完成までをイメージできるか。

    適材適所。

    あとは自分のフィーリングに合うかですか? :-)

Leave a Reply

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS ログイン