Open8
PHP Conference Kansai 2024の感想
wadakatuはじめてのOSSコントリビュート
登壇者：てきめんさん
ざっくり感想
- php-srcにコントリビュートしてみたい
- まずはC言語勉強せねば。
- コントリビュートが就職に活かせる
- 完全同意
- OSSコントリビュートしてますっていうだけで、採用担当者の見る目が全然違う気がする
- 1回しか転職したことないけど。。
- 開発者に責任はない
- 自分もあるOSSで、Tokenizerを使わなければいけないところをPreg::replaceCallbackで実装して、バグを全世界に公開してしまった。。（遠い目）
- かなり著名なOSS作者からバグ報告来た時は戦慄した
- ただ、バグ報告してくれた人も、そのリポジトリのオーナー？もみんな私を責めるようなことは一切言わなかったので、「みんな、あったけぇ。。」という気持ちになった記憶
- 自分もあるOSSで、Tokenizerを使わなければいけないところをPreg::replaceCallbackで実装して、バグを全世界に公開してしまった。。（遠い目）
- コントリビュートとは
- とりあえず使うこと
- 使ってくれる人がいないとそもそも何も始まらない
- 寄付もいいぜ
- 毎月お布施するのあり
- ドキュメント修正が第一歩
- typo, 日本語訳などなど
- 自分も、laravel-langの日本語訳がはじめてのOSSコントリビュートだったような気がする
- phptファイル修正、issue, バグ報告, 警告を取り除く, Feature request
- PHP使いこなしてないと難しいイメージ
- とりあえず、やらないと何も始まらないので、OSS Gateなり、自分の使ってるパッケージなりに何かしらアクションしてみる
- Discussion投げるだけでも、OSSコントリビュートなので。
- TokenizerとかASTを理解して、全世界に公開したバグのリベンジしたい
- とりあえず使うこと
wadakatuレガシーシステムへのPHPStan導入から半年での課題と効果
登壇者: donさん
ざっくり感想
- donさんアイコンが太鼓の達人の和田ドンじゃないですか、やだ〜
- ぜひ和田カツとコラボを何卒。。
- 静的解析ツールといえば
- phpstan
- phan
- PhpStorm Inspection くらいしか知らない...
- SonarQubeは初耳
- 最近のPHPは本当に型定義が強くなった
- 個人的には型大好きなので、本当に嬉しい
- phpstanの解析レベルの選定は本当に悩ましい
- 脳死でmaxにすべきだと考えてた時代が私にもありました。。
- 解析レベル8は高い
- 今自分のプロジェクトでは0から進めて、既存コードに対するエラーを修正してから段階的にレベルを上げている。
- 結構時間かかる
- 指摘事項多い
- 確かに既存は一旦無視して一気にレベル上げるのもありかも
- 今自分のプロジェクトでは0から進めて、既存コードに対するエラーを修正してから段階的にレベルを上げている。
- PR単位での静的解析チェックは必須
- 型への意識上がるの良いな
- いまだに型付けずにプルリク出す人いるから、早く解析レベル上げよう
- 確かにローカルでphpstan実行しないな
- とりあえずPR作って、CIに頑張ってもらう感じ
- 確かにその辺が手軽にできれば、もっと効率化できそう
wadakatuRDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド
登壇者：曽根 壮大 さん
ざっくり感想
- true, falseで削除フラグ使うことは個人的にあんまりない
- その代わり、deleted_atに日付入れてみたいなことをよくする
- テーブルを細かく分けたい気持ちはあるが、中々データベース触れない
- 自分の知識不足
- 既存コードの変更箇所多い
- サービスの稼働止めてしまいそう
- 今のプロジェクトでも、usersテーブルに60個くらいカラムあるから早くなんとせなばという気持ちはある
- 日常的にリファクタリングしたいので、もっと開発者くださいという気持ち。。
- 現在、ほぼ1人プロジェクトなので新規開発 or バグ開発で忙殺されている。
- でも、ごちゃごちゃ言わずリファクタリングもやります。。
- 失敗できる環境作り大事
wadakatu令和最新版 PHP メモリ管理術
登壇者：めもりーさん
ざっくり感想
- スライドの背景絵が可愛い
- 「レガシーコードとどう付き合うか」本読みました！
- php開発してて、メモリ気にしたことあんまりない
- ライブラリの機能使って、メモリ足りなくなったら
--memory_limit=-1するくらい- phpstanとか
- ライブラリの機能使って、メモリ足りなくなったら
- Allowed memory size of hogehoge bytes exhaustedはたまに見る
- CSVファイルの読み込みとかは確かにメモリに気を使う
- ただ、Generator使って遅延評価すれば大丈夫と脳死で考えている節がある
- PHP起動にも2M以上のメモリを使用しているのは、言われてみればそりゃそうだなんだけど実際に挙動見ないとピンとこない
- memory_get_usageに引数渡せるのは知らなかった
- trueを入れるとZend MMがどれほど実際にメモリを確保しているか知りたい場合に有用らしいが、いつ使うんだろう。。
- 関数呼び出しでメモリ消費されるのは良い学び
- 使っていない変数ちゃんと消しましょうとレビューするときに理由も添えることができるのでありがたい。。
- ガベージコレクションは本当にありがたい
- 自分でメモリ解放とかやると思うと、ゾッとする
- cloneもたまに使うけど、よく理解せず使ってる
wadakatu「"品質"が高いコード」って何？
登壇者：若葉 章さん
ざっくり感想
- バグがないとかはコードの品質が高いと思っちゃう
- 要求を満たしていることが品質
- ただ、その要求が毎回綺麗に出てくれば幸せなんですけどね。。
- 基本、後出し後出しで要求が山積みになっていくイメージ
- なんでもできれば高品質と思いがちだが、実はそうではないのは良い学び
- 未満もダメ
- 超過もダメ
- YAGNIの精神ですね。。
- 将来使うかもとかで、変な共通化したりするのあるあるなのでやめよう
- 経営層から達成すべき要求が提示されないことはよくある
- 経営層がどれだけ技術に関して知識があるかも重要な気がする
- なんかいい感じに〜みたいなのだと困る
- 最初の入りはそれでも良いが、そのまま丸投げされるとこっちもやる気なくなる
- 品質がちゃんとお給料とかに直結するようになるといいなぁ。。
- テストコードは要求を満たすかどうかを確認するように書く
wadakatuCodeRevieweeが求められること
登壇者：おのぽんさん
ざっくり感想
- 「CodeReviewerが求められること」という発表もされている
- 最近、ReviewerもRevieweeも当てはまるので、そちらの発表も読む
- おのぽんさん卓球上手なのすごい、教えてもらいたい
- 変更行、変更ファイル多いのは、あるある
- 今のプロジェクトは超小規模開発なので、尚更やりがち
- この癖直さないと
- レビューは夏休みの宿題と一緒なので、抱えれば抱えるほどやりたくなくなる
- 故に、早くレビューを捌きたいのはわかる
- ただ、大量の変更点が１PRにあったらやる気削がれる
- バージョンアップとかのPRは変更点大きくなりがちなんだけど、なんかいい方法あるかな？
- 1 PR = 10ファイル程度で抑える
- 意外といけるんだなという印象
- 軽量なPRであることを伝えるのはやってなかった
- ロジックのコメントは書きたくない派
- Githubのコメントに書くくらい複雑なら、phpDocとかに書いた方が良い気がする
- そのphpDocをレビューの一環で読んでもらう方が良いのでは
- 後からコード見た人もわかりやすいし
- 質問内容が理解できない場合に、理解できるまで聞くのは大事
- 自分の成長につながる
- 日本人結構これが苦手な人が多いイメージ
- Reviewerがコメントしやすい環境づくりは大事
- Revieweeにすごい喧嘩腰で来られたことがあって、困惑した
- もうレビューせんぞ？という気持ちになった
- KA法でインタビューとかしてるの、すごい労力
- 自分も登壇する時はこれくらい熱量持って、構成考えていきたい
wadakatuアプリケーションエンジニアこそ「監視」だよね！と私が考える訳
登壇者：きんじょうひでき
ざっくり感想
- [配布版]とタイトルスライドに記載があるけど、もしかして登壇用とSpeakerDeckアップロード用と２つスライド作ってるのかな・・・？
- 赤背景に「とっても優しい監視の話」は、良いつかみ
- 監視 = ベテランめちゃわかる
- 何見たらいいかわからないから、後回しになりがち
- 基本見る時は、先輩に一緒に診てもらう
- 何か問題が起こってから、コンソールを見ててんやわんやするイメージ
- 監視を物語として捉える想像力は、実装や設計でも役に立ちそう
- グラフありすぎて、何にもわからんはありがち
- AWSのコンソールとかページネーションが100以上あったりして、何見たらいいんだってなりがち
- DataDogも同じく
- 初心者向けの要素（かぼちゃの監視）がわかりやすくて良い
- こういう発表が増えたら、PHPって何？な人でも参加しやすくなりそう
- ユーザーが不満なく使えているかを監視する
- この視点で監視全く出来てないな。。
- 最近自社サービス内で夜9時ごろにRDSのレイテンシー跳ね上がったりしてるのでちゃんと確認しなきゃ。。
- 一概にページが重いと言っても、その原因は様々
- だから、分解が必要
- DataDogとか導入してるんだし、ちゃんと活用しないとな
- 大抵はスロークエリとかなんだろうけど、勘だけで対処するのはやめるように癖づけたい
- 実装者が監視も並行してできると最高なんだろうな
- 大抵はそんな暇ないが
- でも、今の自分の場合だとそれができるポジション
- これから積極的に監視していくか。
- ただ、退職者が書いたコードも監視するのはしんどいというのもある
- まずは、あまり難しく考えず、必要最低限の情報を眺めるところからスタートしてみる
- オライリーの入門 監視 社内で読書会してたな
- 資料漁ってみよう
wadakatuレガシーとモダンなシステムが混在する開発環境を改善しよう
登壇者：井上良太
ざっくり感想
- メインシステムがあって、サブシステムが複数あるような複雑な環境で働いたことないな。
- 世の中にはいっぱいあるんやろな
- 古いほうに合わせるのか、新しい方に合わせるのかでも色々違った難しさがありそう
- PhpStormちゃんと配布されてるんだな、羨ましい
- うちは、黒字出すためという名目で削られたな。。
- 今は自費で使ってます😢
- Windowsでの開発ってどうなんだろう
- ずっとMacだから気になる
- リポジトリクローンするだけで、とてつもない時間かかりそう
- WindowsにPHPインストールに関しては、Laravel HerdがそろそろWindows対応するらしいのでそれ使えば良さそう
- ただ、環境をみんなで合わせたい場合は別の案になるだろうな
- Pre環境が各エンジニア毎にあるみたいなイメージなのかな
- 便利そう
- 他の人の動作確認を待たなくて良いので、かなり開発効率上がりそう
- 現職では、限られた環境を取り合ってる
- makeコマンド使ってことない
- 大規模開発とかだと、使うコマンドが多くなりがちなのでまとめるのは良さそう
- PhpStormからユニットテスト実行良さそう
- ただ現在の仕事環境だとモニター2枚あるので、別に無理にやらなくても良さそう
- ノートPC１台だけで実装する時は、捗りそう
- 「レガシーなシステムの改善についても長期スパンで検討中」
- 大事だ。。
- 弊社もやらねばね。。