デザイナに eRuby を書かせるべきか否か
masayang氏に、わざわざ回答をいただいた。ありがとうございます。
技術が変われば分業体制も変わる - サンフランシスコ出羽守手記(masayangの日記
- eRubyでXHTMLの大枠を記述するのはRubyエンジニア
- そのeRubyの編集をデザイナにも解放せよ
- デザイナがeRuby構造を壊したとしても、テストで検知できるし、最悪リポジトリから戻せるではないか
これは同意できる。
技術が変われば分業体制も変わる - サンフランシスコ出羽守手記(masayangの日記
これはよくわからない。リポジトリと、CSSの階層構造は、似ているとは思えない。
技術が変われば分業体制も変わる - サンフランシスコ出羽守手記(masayangの日記
- デザイナが先にHTMLテンプレートを作成し、プログラマがそれを参照にeRubyを書くという古典的手法では、「先に画面デザインを確定させる必要がある」ということになり、Agileの持ち味をぶち壊すことになる。
eRuby や Smarty のようにテンプレート中にロジックを埋め込むタイプだと、主に 2 つのアプローチがある。
masayang氏は、(a)のやり方は古典的であり、Agile の持ち味をぶち壊すといっており、37signals がとっているような (b) のやり方を勧めている。
（ここまではあってるよね?）
自分としては、(a) も (b) も間違いだと確信している。こういう問題が発生するのは、そもそも HTML の中にロジックを埋め込んでしまう eRuby や Smarty の仕様が原因である。HTML と Presentationg logic をちゃんと分離するようなツールを選べば、このような問題は発生しないし、デザイナが eRuby を書く必要もない。
eRuby や Smarty のようなタイプのものは、プログラマが HTML も書く場合は手軽な方法でありお勧めできるが、デザイナを入れて協業するようなプロジェクトには向かない。
で、id:kwatch さんの指摘
技術が変われば分業体制も変わる - サンフランシスコ出羽守手記(masayangの日記
> いやー、超ありそう。つーか、SmartyとかJSPとかでもありそう。デザイナ涙目。
が成立するかどうかってのは、デザイナ作業によるデグレードをテストで検知できるか否かにかかっているのではないかと。つまり、テストフレームワークの選択と、それをチームが正しく使っているかどうか。
違うと思うなあ。デザイナと協業しようという工夫と熱意がプログラマにあれば、協業するためのライブラリを持ってくる（あるいは作ってしまう）なんて難しいことではない。でも現実にはそんなプログラマがいないから、デザイナが苦労しているだけ。
正直、デザイナに eRuby を書かせるなんてのは、プログラマの都合をデザイナに押し付けているだけだと思う。
Ruby on Rails でいえば、DHH が eRuby で満足しちゃっているのが元凶。
進化した技術を習得した技術者が集まる現場では、当然分業体制も変わってくるよね、という当たり前といえば当たり前の結論。だけど、わかってない人達は、わかってないこともわかってくれない。COBOL屋の話と同じだ。
技術が変われば分業体制も変わる - サンフランシスコ出羽守手記(masayangの日記
まあ、これはその通りだと思う。デザイナが (JavaScript も含めて) プログラムを書くようになるんだから、プログラマもデザインに限らず要件定義や営業もできるようになるべき。
参考：米国における「Web Designer」求人一例
技術が変われば分業体制も変わる - サンフランシスコ出羽守手記(masayangの日記
...(snip)...
もちろん、プログラマとデザイナの分業を維持している会社もまだまだ残っているよ。でも、ちょっと検索しただけでも、そういう分業体制が破壊された会社が見つかる、という意味をこめて上記3事例を載せてみた。
これはすごい。デザイナの募集のはずなのに、まるでプログラマを求めているかのような条件ではないか。参考になるなあ。
この条件をクリアできるデザイナだと、給料はどのくらいになるのかな。これが平均レベルとかだったらやばいね。
