PHPerKaigi 2018に参加してきました。
せっかくなのでメモ書きを残そうと思います。
PHPerKaigi 2018
https://phperkaigi.jp/2018/
開催: 2018年3月9日（金）〜3月10日（土）
場所: 練馬区立区民・産業プラザ Coconeriホール
スライドのまとめ
PHPerKaigi2018 スライド リンクまとめ
ここに書くこと
3/10のTrack Aのセッションについてのみ（3/9は不参加）
セッションを聴いた感想と質疑などのスライドに書いてないことを中心にまとめます
Track Bはアンカンファレンス、Interactive Round Tableなどでわいわいがやがや面白そうでしたがちゃんと参加していません・・
オープニング
- Track A, B, 会場の紹介
- スポンサー紹介がしっかりしている・・事前に収録されていました
アナウンスしていたのはこの方だそうです
https://twitter.com/toudourenge/status/971877262030065665 -
Kaigiなので講義ではなく双方向コミュニケーション
質問やAsk the speakerコーナーもあるよ
今からでもできるWebサービスモニタリング
https://phperkaigi.jp/2018/proposal/b4aba719-f98e-4f92-9cc2-3b682540fbfd
https://speakerdeck.com/soudai/phper-monitoring
https://twitter.com/NEKOGET/status/972291789825560576
↑個人的に@NEKOGETさんのメモ書きイラストが参考になると思うのでそれがある場合はそのリンクも追加してあります
感想
なぜモニタリングが必要か、なぜWebサービスを見るか、知りたいことは何か、モニタリングの勘所は、というふうに系統立てて話されていてとてもわかりやすい内容でした。
その他ではWebサービスのモニタリングについて、クライアントサイド/インターネット/サーバサイドがあり、クライアントサイドのモニタリングは
- ブラウザ、JS、プロトコル、ネットワークが対象
- 監視ツールの定番のようなものはない。群雄割拠（ビジネスチャンス？）
と言及されていました。
クライアントサイドのモニタリングは確かに重要だと思いますが後回しにされる感（もしくは何もしない）があるので、ここをうまいことやる仕組みがあるとよいですよね。
質疑
DBについて
Q: 障害があったのでインスタンスを増やしたがちょうどいいところにもっていくにはどうすればよいか（インスタンスが多くてお金がかかっている現状）
A: インスタンスを増やせば9割解決する（CPU、メモリ、ディスクが増えるので）、残りはバグ
対応としては間違っていない
サーバレスのモニタリング
A: in/outをみる
コンテナなら生存期間を監視して、長すぎるなら落とすとか
ログの監視
Q: アプリログを監視するときによい指針があれば
A: critかwarningが重要、critはなぜあがったか調べる必要がある
落ちているもの、あとでみるもの、（あと1個失念・・）と分けて監視するといい
SOLIDの原則ってどんなふうに使うの？
https://phperkaigi.jp/2018/proposal/8c508f9e-c8a2-4603-be72-8f701f3c1103
https://speakerdeck.com/hidenorigoto/solidfalseyuan-ze-tutedonnahuunishi-ufalse
https://twitter.com/NEKOGET/status/972303918364413952
感想
実際のコードを例にしてリファクタリングされていく過程が示されていてイメージしやすかったです。
新人と先輩のストーリー仕立ての進行も面白かった。
雑感としてはリファクタリング後の構成（クラス図）はクラス数が増えてぱっと見かなり複雑に見えるので、うっ、となる人はいそうだなという気がしました（クラス数が増えること自体は別に悪いことではないのですが）
質疑
Q: リファクタリングする際に登場するもの(サンプルでいうResolverとか)を決める方法はあるか
A: デザインパターンやよく使われているパターンがある。またフレームワークのコードなどを参考にするとよい
（サンプルに出てきたResolverクラスやsupportsメソッドなどはSymfonyでよく登場しますね）
Q: リファクタリングに失敗したら・・？
A: かきなおすしかない。はじめに選ぶ「軸」が重要
Q: 既存の（新規でない）クラスにオープンクローズドの原則を適用するためによい方法はないか
A: レガシーコード改善の本が参考になる。どこかに区切りをつけて、インターフェースを入れて、その内側のみ手を入れる。
ランチセッション
15分でわかる!WBMPビューアー実装から始めるPHPバイナリ超初心者入門 / php_wbmp
https://speakerdeck.com/rela1470/php-wbmp
感想
jpeg2wbmp(), png2wbmp()という関数ははじめて知りました。
PHPでビューア実装素晴らしいです。地味ですが面白かった。
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
https://phperkaigi.jp/2018/proposal/c116e984-1824-47b7-afd7-4d763422de4a
https://www.slideshare.net/yoku0825/mysql-90218198
感想
mysqlのバックアップの話。
バックアップの手法がいろいろあるのだな・・と勉強になりました。
Hackで作るマイクロフレームワーク
https://phperkaigi.jp/2018/proposal/53897414-a463-4b6d-8f4f-b6f9aa8f2a5e
https://speakerdeck.com/ytake/hackdezuo-rumaikurohuremuwaku
感想
HHVM/Hackを気軽に触ってみよう、という趣旨だったと思うのですがこれを聴いた後にHackをやってみよう、となるかというと・・・？？
Goなど他に選択肢はあるがあえてHackを採用して普及させたいという意気込みは感じました。
質疑
Q: Hackは難しいとかなんとか
A: （ごにょごにょあって）
proxygenというHack自身がサーバになる機能があるらしい？？
しかし発表者さんはそれは使ってないらしい
Q: Hackにフレームワークはあるか
A: ない。のでいま作れば第一人者になれる
Q: Hackを使うにあたって抵抗勢力はないか
A: パワープレーで通した（！）
Q: Hackを使うのに適しているシステムはあるか
A: I/O(http, DB)が非同期なのでPHPでそこがボトルネックならHackを使うとよい。その他は趣味のようなもの
Q: はじめてwebアプリ（型付き）を作るのにHackは適しているか？
A: 適していない・・。PHPやGoのほうがおすすめ。Hackは覚えることが多いとのこと
BEAR.Sunday
https://phperkaigi.jp/2018/proposal/e2848389-75d3-45e2-9106-85be29f17a87
https://speakerdeck.com/koriym/bear-dot-sunday-2018
https://twitter.com/NEKOGET/status/972355365328142344
感想
フレームワークとは、からはじまりBEAR.Sundayの3つのオブジェクトフレームワークの説明を歴史的経緯も含めて順々に説明されていました。
私はBEAR.Sundayを使ったことがないのですが使うと設計力があがりそうな気がしました。
あと気になったのはBEAR.Sundayの名前の由来・・
Ray.Diは由来の説明がありましたが（光が差し込むイメージ）BEAR.Sundayはなんでクマなんだろう・・
PHPStanで始める継続的型検査
https://phperkaigi.jp/2018/proposal/293b2a2d-e769-496d-8622-4c844c97e3ba
https://speakerdeck.com/hirak/php-static-analysis
感想
phanと比較してphpstanを採用した理由がわかりやすかったです。
phanはPHPDocを基本とする、一方phpstanはautoload.phpによる実際のコード＋PHPDocによる設定。
実際に動かしてみる、というのはPHPらしさがある。
またエラーの除外の柔軟性があること、雑にチェックすることもできる。
すでにあるコードに対して導入するか、新規のプロジェクトに導入するかで採用するツールも変わってくるということ。
そしてphanをdisっているわけではないと言及はされていました。（念のため）
質疑
Q: CIでの連携は実現できている？
A: 途中から静的解析を入れたので、エラーが大量にでてしまう、ので部分的に適用しつつ前に進めている
Q: CIのビルド時間はどうか、時間はかかるか
A: デプロイはブロックするが、CIを無視するルートもあるので困ったらそれで回避する
全部のテストで数分はかかっている、必ずしも全部は待っていない、何かやらかしてrevertするなどといったときはCIの結果は無視してしまう