ぷっちん日記

■ 花火を見に行った

綺麗だったが計画性がなかったため、人混みにやられた。もう陸の孤島から帰れないかと思った。。。

■ 某ゲームの影響で

会社のレポートに「更新」が「行進」となっている変換ミスを発見した。orz

■ ブルーベリー収穫

サンシャインブルーのほうは今年は結構とれた。（もう一鉢は枯れてるけど）

ジャムを作るほどではないが、タルトなら焼けるな。

でも、面倒なので一生懸命、生で食べました☆

そろそろサンシャインブルーの鉢も手狭そう（現在、８号）なので植え替えたほうがいいのだが、これも面倒。でも、狭いばかりでなくバランスが悪くて、強風が吹くとひっくり返るので、やらねばだめだろう。まあ冬にでも。

ひっくり返るといえば紅梅もまずいのだが、これはすでに10号。こんな大きいものを植え替えるのは辛い・・・；；　が、これもやらねばだめだろう・・・。

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

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

特に次の２点について。

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

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

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

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