PHPerKaigi2018雑メモ
最初に
これは自分が書いたメモをただ挙げただけの内容になる。
感想とかは次の記事で。
前夜祭
オープニングトーク
- PHPerKaigiは双方向コミュニケーション
- 長谷川さんがビール煽って楽しそう
PHPでテスティングフレームワークを実装する前に知っておきたい勘所 #phperkaigi
- PHP標準のテスト機能がある
- phptってやつ
- ライブラリとフレームワークの違い
- 呼び出しが逆
- アプリケーション側でcookieとかheaderを呼ぶとテストで死ぬ
- それぞれラッパーして上げないとテストできない
Q:Power-assertって実運用で使える? A:結構大変。eval使って悪いことしている。
うずらさんの飛び入り LTPHP7.1 is fast(?)
- PHP7.1は早い
- ベンチマークツールによって結果が大きく違う
- keepaliveの扱いが違ったり、HTTP1.1に対応しているかどうかで差がある
Q:` php -S ` は試していないの? A:PHP公式でNGが出ているので試していない。
PHP と SAPI と ZendEngine3 と
QA
Q:USE_ZEND_ASSOCは0に出来るけどなんの用途で使う? A:なんとも言えない。デバッグなので使うのではないか
Q:OPCODECHACEは全てのコードでキャッシュされる? A:どこでもキャッシュされる。
大統一PHP
ビールが加速していく。
我々はhttpdになりたい
はパワーワード
(要約するとGoやRubyと違って、PHP自身はhttpdになってない)
- ReactPHPで早くしようと思ったら設計がいるぞ
- ぶっちゃけ簡単に使ったら遅いー
- 実行したスクリプトが死んだらサーバも死ぬぞー
Q:なんで1バイナリにまとめた(モチベ)? A:他の言語に合わせる。Docker使っている人に合わせるため。
Q:ReactPHPを本番で使っている? A:APIで使っている。HTMLとか投げるとしんどい。 早いとかそういうモチベを持っていると思うが、そのモチベだとシングルトンにしないと行けなくて大変よ。 最近はPsr7に対応して良くなっている。
本編
PHPerのためのWebサービスのモニタリングの話
PHPアプリケーションの監視の話。
- サーバサイドは自分たちの管轄なので、モニタリングしやすいし手が打ちやすい
- クライアント(JS)は不可解な事が起きるのでモニタリング大事
- DNSとかアンコントローラブルだけど、モニタリングはいるよ
- サーバサイドはNew Relicがおすすめ
- 監視は可視化するのが大事 →時系列でデータを持たないと今の状態が分からない
- ダウンロード数や課金数もモニタリングすると良い →サイトはダウンしてないけど、ダウンロード数が急激に減ったら問題が起きたとわかる
- アプリケーションエンジニアは2015年Webサーバアーキテクチャ序論 - ゆううきブログを良い
- パフォーマンスモニタリング会とかを2週間に1回くらいやっておく良い →何か問題が起きたか気付ける
- 計測→観測することで「感が働かせるようになる」 →未来を予測できるようになる
Q:DB監視について、自分の会社でAWSのAuroraを使っていて、DBが落ちる障害が起きたが、インスタンスサイズを最大にあげて終わりにした。 よくなっているが、価格が高すぎて困っている。 どうしたら適切なインスタンスサイズを選べるか?何を見ればよいの?
A:アプローチは間違ってない。 CPU・メモリ・ディスクIOが問題の9割を占める。 チューニングしてどれかを下げられるか。 CPU50%を下回れば良い。ディスクIOはディスクサイズに依存する。 メモリはバッファプールに乗っているか、インデクスが効いているか。 発行されたSQLがきちんと実行されているかを見る。 SlowQueryLogなどを見る。
SOLIDの原則ってどんなふうに使うの?
- TODOが2週類あるという状態なので3つ目が増えることも想定する必要がある
- オープン=機能が拡張できる、クローズド=修正を行わない
- 原則を適応する範囲はバリエーションを追加する場合
Q:TODOの表示をTODOのクラスがもてばいいのではないか 表示部分を別クラスに切り出したのはなぜ
A:TODOEntityの中に持たせれば確かに他のコードを書き直す必要はない。しかし軸が一つならうまくいく可能性が高いが、表示処理がPDF出力とか、があった場合に、Entityの中に、showPDFみたいなのが必要にってしまう。 考えすぎても先に進めないが、よく追加される要件は考慮に入れておいた方が良い。
CakePHP相談会
Join CakePHP on Slack!で色々話がある。
→最近は3.6ベータの話とか。
1→3へアップデートの話
- 7.0でCakephp1.3を動かした会社がある
- coreに手を入れたと思われる
- 4系で動くことを想定しているので、普通には上がらない
- パスワードの共有化とかセッションの共有化は作り込みが必要
- coreに手を入れたと思われる
- 1と3を同じリポジトリに入れ、3でリクエスト受けて、3になかったら1に流す実装をしていた
2→3のアップデートシェルはある
→あんまり期待できないかもだけど…
CakePHP1.3はどこまでのPHPバージョンで行けるか
- CakePHP1.3はPHP5.6までは行ける!!
- coreに手を入れてなくてもいける
- もっともアプリケーションが動いているだけなので、全部の機能が使えるというわけではない
- デバッグオプション入れるとCakeのコードでいっぱいWarming吐く
- coreに手を入れてなくてもいける
- mysql関数が怪しいかもしれぬ…、mysqliなら問題なし
アップデートの話
- CakePHP2.10は4が出てから1年はバグフィックスされる
- CakePHP4.0の構造はどうなる?
- 3.6で非推奨なものを使わなければ行けるぞ
- 4からは最新の機能をガシガシ使っていく流れになっている
- 3.6と4で差がないならなぜバージョニングが違う?
- おそらくPHP5の互換を切るかどうかでバージョニングしている
- ランサーズでCakeのcookbookを読む会をやっている
- ランサーズの人が読んで、参加メンバーで議論する
- 1, 2, 3と上げるためにやっている
- 2から3に上げるとき
- 2のCustomFinderを作っておけば、3のCustomFinderに上げやすい
- Cookbookにバージョンごとのアップグレードの話が載っている
- バージョンアップで挙動が変わっていないことをどう担保する?
- PHPやフレームワークのバージョンを上げないでなんとかならないか?
Hackで作るマイクロフレームワーク
自分的には大本命。
「皆さんHack使っていると思うんですよね」 はパワーワード
- .hhconfigでPHPのコードを動作させないように出来る
- かなり男になれる
- hhiを使うことでATOMとVScodeならHackをかけるぞ
- PsrはHackを想定していない
- Hackで作ったろ by facebook
- HHVM-Autoload
- Composerのhack版。絶対使おうな
- HackでPsr11のmixedの扱い
- mixed変数をそのまま使うと型がわからないため、タイプチェッカーがエラー扱いをする
* 配列であれば、配列だよってコードで明示する - mixedは使わない方が良いよ
- mixed変数をそのまま使うと型がわからないため、タイプチェッカーがエラー扱いをする
- Hack≠PHP
- hackはPHPの配列にフィールドを設定できる
- 返ってきたJSONに対して型をチェックできる
- 出力できるJSONもチェックできる
- 要点はPHPと同じで小さなライブラリの集合体になっていく
- symfonyもサポートが切れ、残るはZendのみ
Q:Hack > PHP7の部分はどこ? A:IOの消費が良い、それくらい。
Q:初めて型の厳格な言語に触る場合、おすすめできる言語か? A:型に厳格な言語を初めて触る方にはおすすめしない。 →今ならGo言語かPHP7の方がよい。
Q:HackでベターなWebフレームワークはある? A:ない。今なら先駆者になれるチャンス!
アンカンファレンス - MySQL相談会
Q:MySQLの技術的負債をどう解決する?
A:データベース・リファクリングに書いてある。
テーブル構造変更だけじゃなく、アプリケーションと相互に修正を加えていく必要がある
PHPStanで始める継続的静的解析
- dynamic=動かしてみる
- モックを工夫しないと誤作動が起きる
- static=動かさずに読む
- プログラミング言語やコードスタイルによって出来る範囲がわかる
- PHPStanはautoloadを設定する]
- Composerの関係で、厳密にはコードを実行している
- composerが標準化したことで、autoloadを実行しても問題なし、という見解が出来るようになった
- Composerの関係で、厳密にはコードを実行している
@return $this
←メソッドチェインしてますの合図(PHPdoc)
極論
LT
HackのAsyncCurlで死んだ話
- curl_multi_execが原因でこけていた。
- 世に転がっている「HHVMが謎の死を遂げた」も上記が原因かもね。
レビューをもらいやすい細かい プルリクの切り分け方 at PHPerKaigi 2018
既存の振る舞いを変えないものはどんどん先出しでリリースしちゃえ。
Lumenで堅牢なAPIを設計する。
Lumenで出来るセキュリテー対策に関するTips - Fendo181 - Scrapbox
* Lumen使ってみたいなと思っていたので気になっていたLT。
* まとめの内容は良いオチがついていたw