開催概要
- 日時・場所
- 2015/05/30(土) 10:00〜17:00 @ブリーゼプラザ
- 公式サイト
- ハッシュタグ
- #phpkansai
- 資料まとめ
- 全セッションのビデオ
tl;dr
特に良かったセッションベスト3
- Symfony – フレームワークの先へ
- DMMプラットフォームの失敗から学ぶスクラム開発体制
- Codeception テストの活用
聴講したセッション
[基調講演] PHP7で変わること〜言語仕様とエンジンの改善ポイント〜
- hnwさんのブログ
- PHP 5.6 -> 7.0 で速度2倍
- PHP7はHHVMに迫る速度
- 各エクステンションのPHP7への対応状況
Codeception テストの活用
- 「顔で分かるかもしれないけど日本人ではない」
-
Codeception = E2Eテストフレームワーク
- UnitTestも一応できる
- Codeceptionのテストは読みやすい
- ビジネスの意図を読める
- 否定形のAPIもあるので、通常系のユーザシナリオだけでなく、エラーシナリオ、セキュリティシナリオもテストしやすい
-
run --steps
でステップごとの実行ログ - エラー発生時にその瞬間のスクリーンショットだけでなく、DOMも保存できる
- レポート周りが充実している
- Selenium(WebDriver)とも一緒に使える
ビッグウェーブ到来!? – 関数プログラミング導入の要点
- 副作用のないプログラム
- 参照透過性
- 関数が参照透過であれば、コードが安全になるだけでなく、テスタビリティが良くなる
Symfonyコンポーネントで生まれ変わるEC-CUBE
- 目的
- プラグインの競合の解消
- ロジックの密結合の解消
- レガシーな独自フレームワークを捨て、silexで全面書き換え
DMMプラットフォームの失敗から学ぶスクラム開発体制
- DMMでもPHPを10年以上使っている
- POP = Product Owner Proxy
- 管理は本人のために行うもの
- 管理者は何でも管理したがるが、それが生産性に貢献しているかを意識しなければならない
- YWTM
- Y(やったこと)、W(分かったこと)、T(試すこと)、M(メリット)
- KPTで言うところのKeepが見えにくい?
- →Keepはチームのルールになっていくから敢えて可視化しなくてもいい
- 今、1週間スプリント
- →W(分かったこと)のフィードバックを早く得るため
- (質問) スクラムに対する抵抗勢力はなかったか?
- (回答) 抵抗勢力(笑)はなかった。ただ、既存の仕組みを白紙にして始めるというのは難しい。歩み寄りは必要
Symfony – フレームワークの先へ
@fivestr さんの話、今日聞いてる中で一番エモいセッションっぽい #phpkansai
— Hiraku (@Hiraku) May 30, 2015
フレームワークは洗練されていってるが、我々エンジニアは成長していっているのか? #phpkansai
— Taro (@panther_king) May 30, 2015
『エンジニアの仕事はユーザーに価値を提供する/世の中をよりよくすることが目的。フレームワークを使いこなすことではない。』 #phpkansai
— Hiraku (@Hiraku) May 30, 2015
フレームワークがビジネスロジックの実装の妨げになっては本末転倒。様々な設計を許容するフレームワークを選ぶ #phpkansai
— Taro (@panther_king) May 30, 2015
フレームワークは道具にすぎない より本質的な問題に注力していく #phpkansai
— bowa (@junkpot1212) May 30, 2015
フレームワークが面倒を見てくれないビジネスロジック部分こそが本来エンジニアが解決すべき(注力すべき)課題 #phpkansai
— ゆう (@kawanamiyuu) May 30, 2015
その課題に立ち向かうために、オブジェクト指向、パターン、原則、DDD に対する理解、つまり、ビジネスの要求に応えるための設計能力が必要 #phpkansai
— ゆう (@kawanamiyuu) May 30, 2015
失敗する覚悟で何度も設計にチャレンジする。失敗しないと成長しない。 #phpkansai
— Taro (@panther_king) May 30, 2015
- fivestarさんのブログ
- エンジニアの仕事はユーザーに価値を提供する。世の中をよりよくすることが目的。フレームワークを使いこなすことではない
- フレームワークが面倒を見てくれないビジネスロジック部分こそが本来エンジニアが解決すべき(注力すべき)課題
- その課題に立ち向かうために、
オブジェクト指向
、パターン
、原則
、DDD
に対する理解、つまり、 ビジネスの要求に応えるための設計能力 が必要- それってすごく経験が必要だし難しい
- 失敗する覚悟で何度もチャレンジし、エンジニアとして成長していかなければならない。プロフェッショナルとして
- それってすごく経験が必要だし難しい
- フレームワークがビジネスロジックの実装の妨げになっては本末転倒
- 様々な設計を許容するフレームワークを選ぶ
- これからのフレームワークはアーキテクチャなど本質的な部分で違いを生み出すことが重要
Lightning Talks
継続的Webセキュリティテスト
- VAddy
NetBeansを使ってライブコーディング
ドメイン駆動設計の仕様パターン(Specification Pattern)
- Domain Kata (PHPライブラリ)
PHPerにもCoderDojoのメンターとしてお手伝いしてほしい
RubyのアレをPHPで倒す
- Ruby Warrior
- PHP Warrior
- Python Warrior