読者です 読者をやめる 読者になる 読者になる

設計勉強会に参加してきた(かなり前に)

id:shimookaさん企画された設計勉強会に参加してきました。
設計勉強会 - events.php.gr.jp
ぎりぎりまで会社を出れず、時間をちょっとすぎたぐらいに着きました。

WEBアプリケーションにおける設計とは?

PHPユーザ会
id:yandoさん
猫好き ゴルフ好き CakePHP好き
10/25にCakePHPカンファレンスがある(すいません!もう終わってる。。)

PHPerにとっての設計
いろいろな設計がある
基本 外部 内部 詳細

ぐぐっても定義が出てこない
なにをもって定義するか 基本と外部がいっしょとか

phpが通信ならばwebアプリケーション
ほぼLAMPなアーキテクチャ
超厳密なトランザクション管理もない

PHPの視点からみるときまている
11万月とかもない

詳細設計が話す内容ではないか
チーム体制とかは聞きたくないだろう

詳細設計のフェーズをコーディング前にとる
いきなりコーディングすると問題がいろいろある

使用の理解ずれ
適切な処理単位
想定される処理量、処理方式
 バッチ処理にするなどの対策
コーディング後に修正が大変
 FWをどこまで使うか プロペル<->SQL
 トランザクションの管理ポリシー
 命名規則
  あとからモジュール名変更とか記憶にない


個人的に気にする点
認証の有無 SSL セッションの単位
 ちゃんとしないときもいモジュールができる
 1つのモジュールでまたいで変なことをすると気持ち悪くなる
 画面単位ではなくて 目に見えないところ
複雑すぎる処理はシンプルに ifのネスト3段階になるとつらい しないように
 人間が読めるように
表示に特化した処理はviewに
 タグがactionに出ないように
再利用できそうな処理をライブラリ化する


未来のために
リスクを避けるために固執過ぎると膠着状態になる
ユニットテストとかは絶対にやったほうが
 ユニットテストやったほうぎい? 全員
 ユニットテストやってる? いない

ORまっぱはつかったほうが良い

Smartyはやめたほうがいい
APCは絶対使ったほうがいい
バージョン管理はひつよう
本番環境でのソース編集が必要なのはへん

ZENDのカンファレンスでも話があった

当たり前なことだけど、当たり前のことをしっかりやったほうがいい



コードキャッシュの話
月曜のPHP勉強会で話しますので 続きは月曜日に


Smartyを入れただけで遅くなる事実
いまから使うのはしなくていい
Smartyのタグがあってうれしい人はいる?


質疑応答では、SmartyによりもPHPの方がみづらいのではないか?という意見もあったが。
あんまりSmartyを用意したからデザイナーでということはないのでは。
Smartyにしたからデザイナーができるというのはできていないのでは。
エンジニアがテンプレートも書く。

Ethna的なActionとViewな何か

id:sotarokさん
設計勉強会で発表してきました+メモ+資料 - 肉とご飯と甘いもの @ sotarok

haltさんに喧嘩を売られた気がするので話すとか。
設計に長けていないが ポリシーを話したい
元events.php.gr.jpよりはポリシーがある


ライトウェイトなMVC


図がよかったです。
AppManagerとかAppObjectとか使ってない
Ethnaのpreforwrdの使い方とか。

Ethnaの使い方講座になってるw


Open PEAR Serverをやっている
openpearコマンドとか。
すでにリリースしています!>http://openpear.org/


MVCとは何か。おまえらMVCわからずにフレームワーク使うな

haltさん
MVCとは何か。
おまえらMVCがわからずにフレームワークを使うな


Mojaviの場合とかから始まって過去のフレームワークの話。
私は知らない頃の話なので面白かった。


Ethna
テンプレートにSmartyのforeachがあって、viewクラスにもDBから取得のロジックがある

viewクラスって必要なくない?
という話


ここまで

話を聞きながらメモをしていたのだが、 PCの入れ替えなどで埋もれてしまっていました。