CakePHPとHTMLコーディングの話

NEKOGET@要件定義屋さん @NEKOGET

@tanakahisateru CakePHP1.3.8でview周りを試しながら画面構成図→ワイヤーフレーム→グラフィックデザイン→HTML→viewってな流れとルールを悩んでる訳だけれども、ひょっとして2で考えた方が良いのか？とか一瞬悩んだわけですよw

NEKOGET@要件定義屋さん @NEKOGET

@tanakahisateru まぁこのまま1.3.8で、にゃおんにゃおん.うにゃー！するわけですがw

田中ひさてる @tanakahisateru

@NEKOGET 僕はぶっちゃけ、CakeやらRailsはCRUD機能が主役になるアプリ部分用なので、ワイヤーフレームベースでデザイン提案ってのには向かないと思ってるんですよ。エンドユーザに提供するリッチビューは、逆にほとんどフルCRUD要らないから、ORM犠牲にしてもいいかなと

田中ひさてる @tanakahisateru

@NEKOGET そんなわけで、CakeみたいなやつでCRUDができたあと、別フレームワークでエンドユーザ用のビューを作るために、適当なのがなかったからPinocoを開発したという。

NEKOGET@要件定義屋さん @NEKOGET

@tanakahisateru なるほど。CakePHPを見ていて思ったのは、情報設計はCakePHPでプログラムを書く人が握っていて、そこにHTML脳でつっこんでいくのは難しいなあと思っていたところでした。どうしてこんなに難しくなってんのか？と…..

田中ひさてる @tanakahisateru

@NEKOGET だってあれ、CSSめちゃやりにくくないです? とくに、HTMLの人に手伝ってもらって分業しようとしたときとか。ソースからDOMがイメージできない。

NEKOGET@要件定義屋さん @NEKOGET

@tanakahisateru CakePHP1.3.8でHTML+CSSエンジニアさんな立ち位置でできることはviewを触る事ではなくて、CSSと画像を触る程度の事しかできないんじゃないかなと…

NEKOGET@要件定義屋さん @NEKOGET

@tanakahisateru CakePHPでviewを含めてコードを書く人が、きちんとHTMLがわかっていればなんとかなると思います。ただわからないままに書けばカオスです。

田中ひさてる @tanakahisateru

@NEKOGET たぶん、「つくる」フェーズで欲しい表現力より、保守/拡張フェーズで欲しいDRYを優先してるからだと思います。ただまあ、その方法をプログラマーだけで考えちゃった。というか、だけで考えざるをえなかった。

NEKOGET@要件定義屋さん @NEKOGET

逆に言えば、PHPエンジニアな立ち位置で考えれば、HTMLの知識さえあればこれほど楽なフレームワークはないと思う。

田中ひさてる @tanakahisateru

@NEKOGET 逆に、デザイナーはDRYによる不具合回避で後の工数減らす発想がなくて、自分の作業そのもののIT化に疎かった、で、意見しなかった。マクロ書くとか難しいこと考えるより、コピペしたほうが早いし、HTMLの仕様がそもそも再利用性をまったく育てない。そんなイメージです。

NEKOGET@要件定義屋さん @NEKOGET

@tanakahisateru なるほど。HTMLエンジニア側の思想はあまりCakePHPのフレームワークからは感じませんでした。ただまぁ保守ってデザイン(見た目）の調整等も多いですよね。

NEKOGET@要件定義屋さん @NEKOGET

@tanakahisateru なるほどです。そこはやはり橋渡しというか、歩み寄りつつ意識と情報のすりあわせ、交換が必要ですねぇ。

田中ひさてる @tanakahisateru

@NEKOGET ほんと、HTMLの作業そのもののIT化はデザイナーがやらなきゃ、で、そのためには、デザイナーがプログラマーの再利用性やミス防止に関する秘術からもっと学ばなきゃと思うんですよね。DB叩くためじゃなくて、ビューの調整で後工数爆発しないように。不満たれる前に予防したか

NEKOGET@要件定義屋さん @NEKOGET

@tanakahisateru あ、DRYって'Don't repeat yourself'でOK?

NEKOGET@要件定義屋さん @NEKOGET

@tanakahisateru 何ができて何ができないのか？の共有ですね。 スライスされてviewに埋め込まれた時点でviewに対する責務はプログラマのものだと思いますがそこに至る前のHTML設計は HTMLエンジニアの責務だと思います。協力大事。

NEKOGET@要件定義屋さん @NEKOGET

HTMLエンジニアさんがPHP等のHTMLを利用するプログラムがHTMLに何を要求しているのかは学ぶべきだし知っておいた方が手戻り減るし幸せになれる。HTMLエンジニアさんもプログラマさんもhappy♪

田中ひさてる @tanakahisateru

@NEKOGET ですです。headタグのkeywordに単語追加するとき、コピペしまくって修正もれするか、layout/head.ctpに書いておいて、一ヶ所変えたら全部おなじパターンで変更できるか、的な。

NEKOGET@要件定義屋さん @NEKOGET

HTMLを利用して表現するプログラムを書いてるプログラマさんもHTMLのことをきちんと学ぶべき。HTMLにできること、できないこと、苦手な事。

NEKOGET@要件定義屋さん @NEKOGET

@tanakahisateru 世界観を共有したいですね。

NEKOGET@要件定義屋さん @NEKOGET

デザイナと言うと範囲が広すぎるし、役割が曖昧になるのでHTMLエンジニアさんという表現にしてみました（テレ

田中ひさてる @tanakahisateru

@NEKOGET 一般的にはそうだと思います。が、話戻すみたいでアレなんですが、僕はデザインとロジックの責務が直交するようにしたいんですよ。ビューの大部分はHTMLでできているので、HTMLコーダーが直接修正をコミットして実際に結果が変わる、みたいなワークフローが理想だと思います

NEKOGET@要件定義屋さん @NEKOGET

グラフィックデザインをつくるには、ワイヤーフレームは必要で、フレームワーク側が画面設計を握ってるならフレームワーク側でワイヤーフレームを提供してほしいなと思うw

NEKOGET@要件定義屋さん @NEKOGET

@tanakahisateru そこはもう、フロントエンドエンジニアさんの登場なんだと思います。HTML得意なプログラマさんの登場。 view職人。 HTMLコーダさんからview職人さんへのジョブチェンジ！

田中ひさてる @tanakahisateru

@NEKOGET うん、本来「プロ」クオリティとはそうあるべきだと思います。自分のレイアウトをもっとスムーズに最終結果に結びつけたいという気持ちで、技術を磨いていかないと、ホント、ただセンスと体力を資本にしてたら、歳を重ねたあとバイトでOKな若手と競うはめになる。