トップ «前の日記(2008-08-07 (木)) 最新 次の日記(2008-08-12 (火))» 編集
2002|02|03|04|05|06|07|08|09|10|11|12|
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|03|06|07|08|09|11|12|
2011|01|03|04|05|07|
2012|01|02|03|06|07|
2013|03|04|05|07|09|
2015|10|
2016|08|10|

ぷっちん日記


2008-08-10 (日) 夢の中でActiveScaffoldについて語っていた [長年日記]

夢の中でActiveScaffoldについて語っていた

夢を見た。そこでは、私は熱心に、チームメンバーらしきエンジニアに、いかに「そのプロジェクト」にActiveScaffoldを採用すべきでないかを語っていた。

特に次の2点について。

  • ActiveScaffoldは楽しくない(私にとって)
  • 典型的な形ーモデルの属性や子モデルがほぼ編集対象であるーでないとうまみが出ない。夢の中の「そのプロジェクト」は典型的ではなかった

夢の中での主張はそんなところだが、ついでなのでActiveScaffoldについて考えていることを少し書いてみよう。ただし、使ったのは昨年秋~今年春くらいのことなので、最新版では事情は違うかもしれない。

  • ActiveScaffoldは、画面構成(デザインを含む)を自分で考えたくない開発者には、それを手軽に自動的にやってくれるということでとても喜ばれる。もちろん自動で機能ができるという点もそうだが、私には、デザインについてが感情的には一番大きなポイントのように見える。
  • モデルの属性、従属モデルの属性を一気に登録/変更/削除する用途には確かにActiveScaffoldは向いている。
  • 日本語化、表示・入力フォームのカスタマイズはできる。しかしすべてについて施した場合、ActiveScaffoldを使わなかったときにくらべてどのくらい楽なのかは疑問が残る。カスタマイズなしなら手間として圧倒的に楽なのは間違いない。
  • モデルや画面にオリジナルの工夫を入れていくと、ActiveScaffoldが足かせになる。特に、モデルの構造には比較的柔軟だが、画面や遷移の根本的な変更は結構つらい。自分が苦労するだけでなく、チームメンバーに苦労をするよう説得する苦しみ、あるいは、苦労しなくていいと妥協する苦しみがある。このストレスが、私のいう「楽しくない」のメイン部分である。
  • ActiveScaffoldのプロジェクトでは、開発者は、ActiveScaffoldの範囲でやるようになる。ユーザーの使い勝手よりもActiveScaffold的な考え方が優先されていく。これは若手技術者の成長という観点では大変心配な点だ。一方、Railsもフレームワークなわけだが、ユーザーの使い勝手とRails的な考え方は、そういう厳しい二者択一ではなく、両立させられるのが嬉しい。

結局、「ユーザーインターフェースが悪くても、ぱっと見はキレイなWeb画面から、マスターメンテナンスがしたい。手間をかけないで作ってくれ。もういっそ英語のままでいいよ」という案件なら私はActiveScaffoldを使う。そうでなければ使わないかな。


 以前の日記