PHPカンファレンス関西2015 に行ってきたメモ


# 開催概要

* 日時・場所
  * 2015/05/30(土) 10:00〜17:00 ＠ブリーゼプラザ
* 公式サイト
  * http://conference.kphpug.jp/2015/
* ハッシュタグ
  * \#phpkansai
* 資料まとめ
  * http://sprawl.hatenablog.jp/entry/2015/05/31/215206
* 全セッションのビデオ
  * https://www.youtube.com/playlist?list=PLr4blcQ4RR8P_oKIvC0V42duZKpSZYdtq

# tl;dr

## 特に良かったセッションベスト3

1. Symfony – フレームワークの先へ
1. DMMプラットフォームの失敗から学ぶスクラム開発体制
1. Codeception テストの活用

# 聴講したセッション

## [基調講演] PHP7で変わること〜言語仕様とエンジンの改善ポイント〜

![DSC_0121.JPG](https://qiita-image-store.s3.amazonaws.com/0/3899/c7511731-54af-8078-786b-fab62609bb86.jpeg "DSC_0121.JPG")

![DSC_0123.JPG](https://qiita-image-store.s3.amazonaws.com/0/3899/7b25dfc4-08b6-a1ba-1c48-860f9c6847bf.jpeg "DSC_0123.JPG")

http://www.slideshare.net/hnw/phpcon-kansai20150530

* hnwさんの[ブログ](http://d.hatena.ne.jp/hnw/20150602)
* PHP 5.6 -> 7.0 で速度2倍
 * PHP7はHHVMに迫る速度
* 各エクステンションのPHP7への対応状況
 * https://github.com/gophp7/gophp7-ext/wiki/extensions-catalog

## Codeception テストの活用

![DSC_0124.JPG](https://qiita-image-store.s3.amazonaws.com/0/3899/ca407d47-3600-c5e3-3b3c-d1fb789f05f3.jpeg "DSC_0124.JPG")

![DSC_0125.JPG](https://qiita-image-store.s3.amazonaws.com/0/3899/e44379d4-e149-38c7-b1f3-f0eba4f01dca.jpeg "DSC_0125.JPG")

![DSC_0126.JPG](https://qiita-image-store.s3.amazonaws.com/0/3899/ff3c0b71-ac0b-af37-8451-53722bb0d585.jpeg "DSC_0126.JPG")

http://www.slideshare.net/FlorentBatard/php-kansai-phpkansai

* 「顔で分かるかもしれないけど日本人ではない」
* [Codeception](http://codeception.com/) = E2Eテストフレームワーク
  * UnitTestも一応できる
* Codeceptionのテストは読みやすい
  * ビジネスの意図を読める
* 否定形のAPIもあるので、通常系のユーザシナリオだけでなく、エラーシナリオ、セキュリティシナリオもテストしやすい
* `run --steps`でステップごとの実行ログ
* エラー発生時にその瞬間のスクリーンショットだけでなく、DOMも保存できる
* レポート周りが充実している
* Selenium(WebDriver)とも一緒に使える

## ビッグウェーブ到来！？ – 関数プログラミング導入の要点

![DSC_0127.JPG](https://qiita-image-store.s3.amazonaws.com/0/3899/7bab6f28-1caa-c7c1-784e-1e7d188a2711.jpeg "DSC_0127.JPG")

![DSC_0128.JPG](https://qiita-image-store.s3.amazonaws.com/0/3899/412a4d95-e7a1-ebb9-1338-1cebae5041be.jpeg "DSC_0128.JPG")

https://www.slideshare.net/daiksy/php2015

* 副作用のないプログラム
* 参照透過性
  * 関数が参照透過であれば、コードが安全になるだけでなく、テスタビリティが良くなる

## Symfonyコンポーネントで生まれ変わるEC-CUBE

![DSC_0129.JPG](https://qiita-image-store.s3.amazonaws.com/0/3899/abe4727d-d157-fff7-c8e3-e83a58a0c6ae.jpeg "DSC_0129.JPG")

http://www.slideshare.net/shinichitakahashi790/symfonyeccube

* 目的
  * プラグインの競合の解消
  * ロジックの密結合の解消
* レガシーな独自フレームワークを捨て、[silex](https://github.com/silexphp/Silex)で全面書き換え
  * https://github.com/EC-CUBE/ec-cube

## DMMプラットフォームの失敗から学ぶスクラム開発体制

![DSC_0130.JPG](https://qiita-image-store.s3.amazonaws.com/0/3899/9b129c6d-7007-2ea6-761c-a7f964843d96.jpeg "DSC_0130.JPG")

![DSC_0132.JPG](https://qiita-image-store.s3.amazonaws.com/0/3899/61cc9ec1-5434-38a3-6da0-cac6f3adce47.jpeg "DSC_0132.JPG")

![DSC_0133.JPG](https://qiita-image-store.s3.amazonaws.com/0/3899/0e02354d-6dd7-d755-2c31-82968dcf21a6.jpeg "DSC_0133.JPG")

https://prezi.com/ygzhzwdnofcd/dmmcom-dmm/

* DMMでもPHPを10年以上使っている
* POP = Product Owner Proxy
* 管理は本人のために行うもの
  * 管理者は何でも管理したがるが、それが生産性に貢献しているかを意識しなければならない
* YWTM
  * Y(やったこと)、W(分かったこと)、T(試すこと)、M(メリット)
  * KPTで言うところのKeepが見えにくい？
      * →Keepはチームのルールになっていくから敢えて可視化しなくてもいい
* 今、１週間スプリント
  * →W(分かったこと)のフィードバックを早く得るため
* (質問) スクラムに対する抵抗勢力はなかったか？
  * (回答) 抵抗勢力(笑)はなかった。ただ、既存の仕組みを白紙にして始めるというのは難しい。歩み寄りは必要


## Symfony – フレームワークの先へ

![DSC_0135.JPG](https://qiita-image-store.s3.amazonaws.com/0/3899/ac9234f1-20ee-3bda-e903-6519dd71ca81.jpeg "DSC_0135.JPG")

https://speakerdeck.com/fivestar/symfony-huremuwakufalsexian-he

<blockquote class="twitter-tweet" lang="en"><p lang="ja" dir="ltr"><a href="https://twitter.com/fivestr">@fivestr</a> さんの話、今日聞いてる中で一番エモいセッションっぽい <a href="https://twitter.com/hashtag/phpkansai?src=hash">#phpkansai</a></p>&mdash; Hiraku (@Hiraku) <a href="https://twitter.com/Hiraku/status/604536053483978752">May 30, 2015</a></blockquote>

<blockquote class="twitter-tweet" lang="en"><p lang="ja" dir="ltr">フレームワークは洗練されていってるが、我々エンジニアは成長していっているのか？ <a href="https://twitter.com/hashtag/phpkansai?src=hash">#phpkansai</a></p>&mdash; Taro (@panther_king) <a href="https://twitter.com/panther_king/status/604535999662718976">May 30, 2015</a></blockquote>

<blockquote class="twitter-tweet" lang="en"><p lang="ja" dir="ltr">『エンジニアの仕事はユーザーに価値を提供する/世の中をよりよくすることが目的。フレームワークを使いこなすことではない。』 <a href="https://twitter.com/hashtag/phpkansai?src=hash">#phpkansai</a></p>&mdash; Hiraku (@Hiraku) <a href="https://twitter.com/Hiraku/status/604536279900954626">May 30, 2015</a></blockquote>

<blockquote class="twitter-tweet" lang="en"><p lang="ja" dir="ltr">フレームワークがビジネスロジックの実装の妨げになっては本末転倒。様々な設計を許容するフレームワークを選ぶ <a href="https://twitter.com/hashtag/phpkansai?src=hash">#phpkansai</a></p>&mdash; Taro (@panther_king) <a href="https://twitter.com/panther_king/status/604537065707954176">May 30, 2015</a></blockquote>

<blockquote class="twitter-tweet" lang="en"><p lang="ja" dir="ltr">フレームワークは道具にすぎない&#10;より本質的な問題に注力していく <a href="https://twitter.com/hashtag/phpkansai?src=hash">#phpkansai</a></p>&mdash; bowa (@junkpot1212) <a href="https://twitter.com/junkpot1212/status/604538708633620480">May 30, 2015</a></blockquote>

<blockquote class="twitter-tweet" lang="en"><p lang="ja" dir="ltr">フレームワークが面倒を見てくれないビジネスロジック部分こそが本来エンジニアが解決すべき（注力すべき）課題 <a href="https://twitter.com/hashtag/phpkansai?src=hash">#phpkansai</a></p>&mdash; ゆう (@kawanamiyuu) <a href="https://twitter.com/kawanamiyuu/status/604540662386561024">May 30, 2015</a></blockquote>

<blockquote class="twitter-tweet" lang="en"><p lang="ja" dir="ltr">その課題に立ち向かうために、オブジェクト指向、パターン、原則、DDD に対する理解、つまり、ビジネスの要求に応えるための設計能力が必要 <a href="https://twitter.com/hashtag/phpkansai?src=hash">#phpkansai</a></p>&mdash; ゆう (@kawanamiyuu) <a href="https://twitter.com/kawanamiyuu/status/604540801025085440">May 30, 2015</a></blockquote>

<blockquote class="twitter-tweet" lang="en"><p lang="ja" dir="ltr">失敗する覚悟で何度も設計にチャレンジする。失敗しないと成長しない。 <a href="https://twitter.com/hashtag/phpkansai?src=hash">#phpkansai</a></p>&mdash; Taro (@panther_king) <a href="https://twitter.com/panther_king/status/604542302124523520">May 30, 2015</a></blockquote>

* fivestarさんの[ブログ](http://fivestar.hatenablog.com/entry/2015/06/01/002827)
* エンジニアの仕事はユーザーに価値を提供する。世の中をよりよくすることが目的。フレームワークを使いこなすことではない
* フレームワークが面倒を見てくれないビジネスロジック部分こそが本来エンジニアが解決すべき（注力すべき）課題
* その課題に立ち向かうために、`オブジェクト指向`、`パターン`、`原則`、`DDD`に対する理解、つまり、 __ビジネスの要求に応えるための設計能力__ が必要
    * それってすごく経験が必要だし難しい
        * 失敗する覚悟で何度もチャレンジし、エンジニアとして成長していかなければならない。プロフェッショナルとして
* フレームワークがビジネスロジックの実装の妨げになっては本末転倒
  * 様々な設計を許容するフレームワークを選ぶ
* これからのフレームワークはアーキテクチャなど本質的な部分で違いを生み出すことが重要

## Lightning Talks

### 継続的Webセキュリティテスト

http://www.slideshare.net/ichikaway/web-php2015-lt

* VAddy
  * http://vaddy.net

### NetBeansを使ってライブコーディング

### ドメイン駆動設計の仕様パターン（Specification Pattern）

https://www.slideshare.net/kumamidori/20150531-phpcon-kansai

* Domain Kata　（PHPライブラリ）

### PHPerにもCoderDojoのメンターとしてお手伝いしてほしい

http://www.slideshare.net/ssuser6d17aa/phpercoderdojo

### RubyのアレをPHPで倒す

* Ruby Warrior
* PHP Warrior
* Python Warrior

### CakePHP事始め

http://www.slideshare.net/4for8pow/php-48787255

### Wocker 〜 秒速でWordPress開発環境を構築する

http://www.slideshare.net/kaitokoga9/wocker-48780708