【概要】
2019/3/29~2019/3/31に開催されたPHPerKaigi2019のイベントを私的に気になったTweetを元にまとめてみました。私用（坂本真綾のライブ）により初日しか参加できないため、初日のみのレポートとなります。PHPerKaigi2020参加のきっかけになればと思います。
なお私は「PHPでJVMに入門する」を聴講しなかったため大変申し訳ありませんが省かせていただきます。
【記事の見方】
引用にツイートの文章およびURLを載せています。引用の下の記述は自分の感想です。
【会場の雰囲気】
なんとか東京にたどり着きPHPerKaigi参加してます！
トートバッグもらいました！
https://twitter.com/floran_poyo/status/1111532045283426304
はじまったー！！
https://twitter.com/1wa46/status/1111532639624798208
バドワイザー
https://twitter.com/kyoplusplus/status/1111537597472333825
非常に良い雰囲気かつ楽しい空間でした！
バドワイザーも美味しかったです。ビールスポンサーのデザインワン・ジャパン様に感謝！
【15分で分かった気になるGraphQL：市川 慎吾さん】
オーバーフェッチはマジで困っている
https://twitter.com/iganayino/status/1111538251473387521
オーバーフェッチングか。確かに汎用的に使えるように、多めにデータを返すように作るかも
https://twitter.com/juve534/status/1111538435464921089
Overfetchingとは不要な情報もフェッチしてしまうこと。汎用劇に使えるようにするためにAPIのレスポンスに多くの情報を含めてしまうと本来不必要である情報も含んでしまう。逆に必要な一つの情報を入手するために複数のAPIをコールする必要があることをUnderfechingと言います。Underfetchingはコンポーネントの原則の一つである再利用・リリース等価の原則に通づるのかと思います。GraphQLはOverfechingおよびUnderfechingの問題を解決するのに役立ちます。
なーるほど。エンドポイントが乱立するのを検索性を上げることで防ぐ…か
https://twitter.com/juve534/status/1111539172408352768
GraphQLを用いずにOverfetchingを解決しようとするとエンドポイントが乱立してしまい、メンテナンス性が低下します。GraphQLを用いることで単一のエンドポイントでOverfetchingの問題を解決することができます。
「クライアント・サーバ間で型安全なコミュニケーションができる」なるほど
https://twitter.com/okashoi/status/1111539359918903296
GraphQLは型の定義が可能であるため型安全なコミュニケーションを行うことが可能ですね。
やっぱ場合によってN+1問題は浮上するか
https://twitter.com/yKicchan/status/1111539518937722880
GraphQLにおいてN+1問題はよく見ますね。このあたりの記事が参考になりそうです。
ファイルアップロードとか、エラーハンドリング(ステータスコードが200・・・)
こういうのが苦手
他にも苦手なことあるから、
GraphQLは銀の弾丸じゃないよ。
めっちゃいい話。
https://twitter.com/nyamucoro/status/1111539685338152961
メリット・デメリットの話をしてくれるのはありがたい
https://twitter.com/juve534/status/1111539859443736576
GraphQLのメリットを推すだけでなく、GraphQLは銀の弾丸ではなくデメリットも存在すると言うことを明記した良いプレゼンでした。
GraphQLがファイルアップロード苦手っていうのは大容量のファイルを1つのポートに対してリクエストを送る必要があるからってこと？
https://twitter.com/suzuki_cecil_/status/1111539721585385472
このあたりの記事が参考になりそうです。
Laravel & lighthouse
https://twitter.com/okashoi/status/1111540582877290497
Laravel+GraphQL+lighthouse
気になるのでまた調べようφ(..)メモメモ
こういうキーワード手に入るのいいよね
https://twitter.com/nyamucoro/status/1111540832992030720
初耳なので調べて見たいと思います。
Q. GraphQL と REST は共存できるか？ A. できる
https://twitter.com/okashoi/status/1111541967312175104
Q&Aで挙がった内容ですね。先述の通りGraphQLは銀の弾丸ではないのでGraphQLに頼るべきところ、そうでないところを見極めた上で活用したいですね。
この問題は「パフォーマンスについてクライアントサイドは感知しない」でいいんじゃないかな、と思う。
計測に基づいてパフォーマンスを改善していくのはサーバサイドで行っていく
https://twitter.com/okashoi/status/1111543963385630720
なるほど！
【PHP でも Raspberry Pi がしたい！：東雲さん】
phpでラズパイがしたい…したくない？
https://twitter.com/iganayino/status/1111545209949544448
この時点ではPHPでラズパイを操作するメリットが分からなかったため、私は思いませんでしたw
Raspberry Pi, 知っているかと言われると知っているけど名前だけ。。。
https://twitter.com/y__uti/status/1111545479932723200
名前しか知らないからワクテカしている
https://twitter.com/juve534/status/1111545496101740545
私も同じくです。こういう人多いんじゃないかなと思います。でもラズパイを自由に扱えるようになれば生活環境、そして業務環境をより良いものに出来るのではないかと思います（小並感）
懐かしさを感じている
https://twitter.com/iganayino/status/1111546188082216960
工業の電気授業を思い出す
コンデンサ、トランジスタ、Lチカ...w
https://twitter.com/yKicchan/status/1111546302863532032
ブレッドボードなつかしい。。。
https://twitter.com/okashoi/status/1111546459432747008
懐かしい気持ちにさせてくれる良いプレゼンでした。
PHPerのための電子工作入門だぁ
https://twitter.com/yKicchan/status/1111546827621306369
まるで電子回路の授業だ！
https://twitter.com/okashoi/status/1111546834990714882
素子の話とか本当に電子回路の授業みたいでした。でも分かりやすい良い授業でしたw
一番カンタンな方法
file_put_contents
くっそ、やられたｗｗｗ
https://twitter.com/nyamucoro/status/1111547448525127680
file_put_contentsで草
https://twitter.com/yKicchan/status/1111547475276357632
シェルでラズパイの操作が可能ということでPHPを用いた一番簡単なラズパイ操作がfile_put_contentsという話ですね。非常に面白かったです。
確かにPHPっぽいコードになった👀
https://twitter.com/juve534/status/1111547790369259521
php-gpioつかうと確かにまあまあ見慣れたコードになってる
https://twitter.com/yKicchan/status/1111547830974320640
file_put_contentsを使うという茶番は置いといて、php-gpioというライブラリを使うことでPHPerからすると見慣れたコードになりました。
phpのラズパイメリット
webから操作しやすい
なるほど
https://twitter.com/yKicchan/status/1111547969503809536
phpで制御すると、Webに簡単に組み込める
その発送はなかった・・・
https://twitter.com/nyamucoro/status/1111548066383839232
ラズパイというとPythonあたりがメジャーかと思いますがPHPを採用することでwebから操作しやすくなるメリットがあります。なるほど、こういう観点から考えるとPHPを採用するのもアリなのかと思いました。
デモンストレーションも非常に面白かったです。
【「質」の良いユニットテストを書くためのプラクティス：東口和暉さん】
資料はこちらになります。
https://speakerdeck.com/hgsgtk/practices-to-write-better-unit-test
「初級者」から「中級者」へどうステップアップしていくか
https://twitter.com/okashoi/status/1111552640654041088
ユニットテスト初級者から中級者になるぞ！
https://twitter.com/yKicchan/status/11115526118725120
概要が初級者から中級者へのステップアップということでした。私は初級者なので非常にありがたかったです。
質→費用対効果の高い
https://twitter.com/nyamucoro/status/1111552986818314241
質が高いユニットテスト＝費用対効果の高いユニットテスト
https://twitter.com/suzuki_cecil_/status/1111553061720252416
このプレゼンでは質の良いユニットテストを費用対効果の高いユニットテストと定義していました。
我々はなぜテストを書くのか？
品質？DOC？指標？
コスト削減！
https://twitter.com/yKicchan/status/1111553124806717442
なぜテスト書くのか
品質向上、バグを防ぎたい
テストによるドキュメンテーション
テストできる設計か
根本の理由はコスト削減
https://twitter.com/nyamucoro/status/1111553187146661888
先述の定義を基に考えるとユニットテストを記述するメリットは色々ありますが、根本的なメリットはコスト削減ということになりますね。
ユニットテストによるコスト削減
vs
ユニットテスト書くコスト
https://twitter.com/nyamucoro/status/1111553261352292352
ユニットテスト自体のコストとユニットテストによる削減コストのバランス...
https://twitter.com/yKicchan/status/1111553295108075520
（ユニットテストにより削減できるコスト） > （ユニットテストを作成・維持するコスト）となること
https://twitter.com/okashoi/status/1111553597777403905
またコスト削減が根本的なメリットということは、ユニットテストによるコスト削減がユニットテストを記述するために要するコストが上回ってはいけません。ただユニットテストを書けば良いというわけではなく、質の良いユニットテストを書く技術が必要になります。
「テストの経済性」「最初はコストは嵩むが、結果的に相殺されていく」
https://twitter.com/okashoi/status/1111553972366565378
「テストの非経済性」「維持コストの高いテストを書くと、結果的にコストは増大していく」
https://twitter.com/okashoi/status/1111554144068755457
ユニットテストを書くと最初はどうしてもコストが嵩みます。ただし質の良いユニットテストは結果的にコスト削減につながりますが、質の悪いユニットテストは結果的にコストが増大します。
BASE 70万ショップ突破らしい
https://twitter.com/OwOkazy/status/1111554538207477761
BASE様、おめでとうございます！そしてスポンサーありがとうございます！
意図を伝えるテスト
https://twitter.com/rito328/status/1111554806869417984
意図を伝えるテスト。
■テストない
→動作コード読む
→実際に動かす
→作成者に聞きに行く
というコストがある
https://twitter.com/nyamucoro/status/1111555188974772224
質の高いユニットテストは費用対効果の高いユニットテストであると定義しましたが、では費用対効果の高いユニットテストとはどういうものか？
その指標の一つが意図を伝えるテストということです。Test as Documentationということですね。このあたりはレガシーコード改善ガイドにも載っていた覚えがあります。
ドキュメントそもそもない
メンテナンスされていない
わかりみが深すぎてつらい
https://twitter.com/yKicchan/status/1111555202992111616
ドキュメントは大体ないよね…
https://twitter.com/iganayino/status/1111555213477867521
悲しいことにあるあるですよね。身に覚えがありすぎます。
正直のところ自分はドキュメントを書くのが大嫌いな人間なので、意図を伝えるユニットテストを記述するようにしています。
重点は「テストを書くこと」ではなく「テストをすること」
https://twitter.com/m_norii/status/1111556037184647168
非常に良いことを言うなと思いました（小並感）
simple test. 一つのことをテストするコードを書く
https://twitter.com/OwOkazy/status/1111556070357360641
意図を伝えるためにはシンプルなテストにするべきである。このあたりは実際のサンプルコードを見るとよく分かると思います。
また身の回りにも複雑なユニットテストはあるのではないでしょうか？（私はあります）
すげー大事なことを丁寧に教えてくれている…
https://twitter.com/iganayino/status/1111556326939779072
基本的なことをすごく丁寧に教えてくれる良いプレゼンでした。初級者から中級者へのステップアップするのに必要な知識ですね。
SUTに対して疎結合
https://twitter.com/yKicchan/status/1111556473480343552
SUT = System Under Test テストする対象
https://twitter.com/m_norii/status/1111556601276596225
テスト対象のクラスとテストコードが密結合の場合、壊れやすいテストとなってしまうため疎結合であるべきということです。クラス間の密結合はメンテナンス性を低下させる。設計を行う上で疎結合は常に意識するようにしていましたが、テスト対象とテストコードの結合密度は意識していませんでした。
publicメソッドは変更頻度が少なくテスト修正頻度低い、privateは逆という考え。
一つの指標としてわかりやすくてイイな(全ては網羅できないが...
疎結合にするために、ブラックボックスとしてのテストを書く = public method に対してテストを書く
疎結合にするためにブラックボックスの外から見えるPublic Methodに対してテストを行う、逆にPrivate Methodに対してテストを行わないことがbetterとのことです。
安定性、クリーンアーキテクチャの書籍にもでてきたな
https://twitter.com/m_norii/status/1111557358503641088
Public MethodとPrivate Methodの違いとして安定度を用いて説明していました。クリーンアーキテクチャの「第IV部 コンポーネントの原則」の「安定依存の原則（SDP）」の説明にて登場しました。下記を参考にしていただけると幸いです（宣伝）
https://qiita.com/Suzuki_Cecil/items/e48166394db85817aa5c#安定依存の原則sdp
privateメソッドをテストしたくなってきたら別クラスに出せばいいんだよな
https://twitter.com/77web/status/1111557866802962433
そうそう、テストしたいprivateメソッドは、そもそも設計を見直したほうがいいサインなんだよな
https://twitter.com/m_norii/status/1111560905496510464
「private メソッドをテストしたい、と思うとき、そのメソッドは責務を持っている。そのようなメソッドがそもそも private であるべきか疑う」あーすごいいい話だー
https://twitter.com/okashoi/status/1111561116604203008
まさにその通りだと思います！！！
順序依存ダメゼッタイ（実は弊社のコードにも歴史的経緯で存在してて直したいテストNo1なんだよなー）
https://twitter.com/77web/status/1111558321612308480
普通に考えてあり得ないんだけど、テストの相互依存はやりがち…
https://twitter.com/iganayino/status/1111558360522878978
テスト間の独立を行うために順序依存・相互依存はダメという話ですね。順序依存は自分もやらかしたことがあります。
fixture独立も最近気をつけてることの一つ。わかるわかるわかるよー
https://twitter.com/77web/status/1111558438155239424
Fixtureは用法用量を守ってご利用くださいってことだな
https://twitter.com/yKicchan/status/1111558869178679299
共有されたFixtureのメリットは１回のFixtureのみで済むことですが、デメリットとしてテスト間の独立性を損なうという話ですね。用法用量を守りましょう。
テストもDRYに
https://twitter.com/OwOkazy/status/1111559112704180224
重複を避けるためにテストコードでもDRY原則を守りましょうということですね。
DRY in Test Code
そうしたいけど、意味が散らばると怖いし難しい・・・
共通化とかだと、その共通化に依存したコードになるし、
それを理解してテストコード書くのを全員でやるの難しいしくそぅ・・・
https://twitter.com/nyamucoro/status/1111559549331206144
というか、そもそも共通化などの DRY 原則、ムズすぎでは、と最近おもうようになった
https://twitter.com/okashoi/status/1111560050579918848
これはDRYの難しいところだと思います。何でもかんでも共通化というのはむしろ悪ですね。DRYは単純にコピーをするなということではなく、共通化すべきところは共通化するということですが、その判断が難しいです。
TDDでテスト容易性を強制するのイイな
https://twitter.com/yKicchan/status/1111559854915633152
テストが容易な設計にするためにTDDを採用するということですね。TDDを採用することでテストコードが前提となるので、基本的な欠陥はテスト実行により気づける。
TDDによるテスト容易性の強制については同じく東口和暉さんがPHPカンファレンス仙台にて発表しておりましたので、そちらを合わせて読みたいところです。
【まとめ】
非常に楽しいイベントで、また勉強させていただきました。お金を払う価値は全然あると思います。もし気になった方がいましたらPHPerKaigi2020に足を運んでみてください。
また運営の皆様方、サポーターの皆様方、スポンサーの企業様方ありがとうございました！