タイトルの通り、PHPカンファレンス小田原に参加してきました。
参加のきっかけや感想を記載します。
参加のきっかけ
今回参加した理由は大きく分けて以下の2点です。 - 同じ会社の人が登壇予定で関東に来るので会いたかったから - Xのタイムラインで見て、過去の開催が盛り上がっていたから
2トラック構成で片方はPHPにかかわらない話メインの構成になっており、間口が広いカンファレンスだなと感じ、話を聞いてみたいと思ったことも背景にあります。
少しだけ自己紹介
- PHP経験ほぼなし
- JavaやRuby on Railsのコミュニティでは登壇経験あり
- お仕事はテックリードやマネージャーという立ち位置
聞いたセッション等
リンク先はforteeです。
- 前夜祭
- FigmaとPHPで作る、1ミリたりとも表示崩れしない最強の帳票印刷ソリューション
- VAddy PHPカンファレンス全部スポンサーする！の裏側
- PhpStorm超絶技巧20分集中講義
- オダワラよいとこ
- GitHub Actionsで泣かないためにやっておきたい設定
- SREとその組織類型 ~多様化するSREについて改めて考えてみた~
- テスト品質を向上させよう！ 〜 アンチパターン回避メソッド 〜
- 単体テストを書かない技術
全体通しての感想
まず「小田原」が良かったです。
ランチは美味しいし、町並みはきれいだし、時期的に桜も満開。 気温もちょうど良く、天気も晴れ、絶好のカンファレンス日和でした。
小田原城を見たり、街を散策して食べ歩きしたり、見どころがたくさんある街だなと思いました。
今回目的の一つとして、「会社の同僚に会って直接話を聞く」ということがあったのですが、そちらもバッチリ果たせました。
リモートワークになって、遠方の同僚と仕事以外の話をする機会はなかなかないので、カンファレンスへの考え方を聞けて新鮮でした。
各セッションの感想
ここからは各セッションの感想を列挙していきます。
前夜祭
前夜祭の日は前夜祭参加者に限りコワーキングスペースが無料で利用できました。 コワーキングスペースではお茶もお菓子も出るし、モニターや電源、WiFiは当然のように使えるしで、至れり尽くせりでした。
前夜祭自体はIRTと懇親会の2部構成でした。
IRT
IRT (Interactive Round Table)は同席したメンバーと特定のテーマについてディスカッションをする企画です。 blog.phperkaigi.jp
PHPカンファレンスの前夜祭なんですが、PHPの話題が入っておらず運営さんの配慮を感じました（自分が言語のカンファレンスの主催になったら絶対言語について入れてしまうので）。
アイスブレイクとして話すにはちょうど良い話題ばかりで、あっという間に時間が過ぎていき、いくつかのテーマは「もっと話したかった」です。
懇親会
カレー美味しかったです！！！
正直コミュ障発揮して、いろんな人と話すことができたわけではないですが、言語の垣根を超えて、幅広いお話が聞けて、とても有意義な時間でした。
カンファレンス登壇のためにはどうしたらよいのか、モチベーションは？など、会社の人に持ち帰りたい話がたくさん聞けたので、すごく収穫になりました。
FigmaとPHPで作る、1ミリたりとも表示崩れしない最強の帳票印刷ソリューション
| スピーカー | たつきち |
|---|---|
| Xアカウント | @ttskch |
| fortee | fortee |
実装方法や詳細は「Zennの記事見てね」とのこと。
感想
直近業務でインボイス対応等で帳票を作成することがあり、つらみを感じていました。 そんな中だったのでタイムリーな話題だったことと、みんな大変さを感じていることがわかり、ホッとしました。
SVGで生成する発想はなかったですし、自分でもこういうソリューションを見つけて共有していきたいです。
VAddy PHPカンファレンス全部スポンサーする！の裏側
| スピーカー | 市川@cakephper |
|---|---|
| Xアカウント | @cakephper |
| fortee | fortee |
スポンサーセッションです。
感想
VAddyという脆弱性診断ツールの紹介でした。 これも直近業務で脆弱性診断どうしようって考えていたところだったので、タイムリーな話題でした。
「機能追加するとどうしても画面が複雑になるが設定を減らし、誰でも（非エンジニアでも）使いやすいツールを目指している」と話していたことが印象的でした。
また、なぜカンファレンスのスポンサーになるかというお話もあり、KPIは気にせずに単に「面白いから」やってみる、とお話されていて、良い考え方だよなぁと感心しました。
市川さんは前夜祭でも話かけてくださり、非常に助かりました。ありがとうございます。 （PHP界隈で知り合いがほとんどいなかったのでぼっちちゃんでした。）
PhpStorm超絶技巧20分集中講義
| スピーカー | 杉本さん |
|---|---|
| Xアカウント | @yusuke（スピーカーとは別ですが） |
| fortee | fortee |
スポンサーセッションです。
感想
PhpStormの紹介でした。
Javaのコミュニティ（JJUG CCCなど）に参加しているので、「IntelliJ IDEA」とほとんど同じだなぁと「これは知ってるマウント」していました。
が、「最近使用した箇所」のナビゲーションは覚えておらず、「めっちゃ便利じゃん！！」となりました。
またスポンサーブースでは好きなプラグインの話をさせていただき、「プレゼンテーションアシスタント」を愛用していることをお伝えしました。
ちなみにTamaCatとApache Tomcatは全くの無関係でもじったわけでもなく、単に猫といえばTamaだろうと決まったとのこと。
オダワラよいとこ
| スピーカー | スナック無駄 |
|---|---|
| Xアカウント | - |
| fortee | fortee |
スポンサーセッションです。
感想
とにかく語り口が面白い！
小田原のお店紹介がメインだったのですが、ジョークを言う部分と伝えたいことを伝える部分の比率が絶妙で、どのお店も行きたくなりました。
時間の関係で今回はご紹介いただいたお店にお邪魔することはできなかったので、観光に行った際にはぜひ立ち寄りたいと思います。
ちなみにエンジニアはお酒とコーヒーが好きらしいですが、私はどっちもNGです；；
GitHub Actionsで泣かないためにやっておきたい設定
| スピーカー | pinkumohikan |
|---|---|
| Xアカウント | @pinkumohikan |
| fortee | fortee |
感想
なんとなくテンプレートをそのまま使っていたので明日使えるテクニックが満載でした。
タイムアウト設定はなんでフェイルセーフやフールプルーフな初期値になっていないんでしょうね？ 無制限よりはもちろん良いのですが、10分くらいにしてもらって、それ以上かかりそうなら手動で延ばすような運用のほうが安全に思えます。
また、コマンドをShell ScriptやMakefileに書いて、CIでもそれを呼び出して実行するというのは目からウロコでした。
最近うまく動いていないCIがあり、手直しする際に毎回3つくらいのコマンドを打ち続けていたので「Makefile作っておけば......！」と、このセッションを先に聞けていなかったことを悔やむばかりです。
SREとその組織類型 ~多様化するSREについて改めて考えてみた~
| スピーカー | よこやまたつお |
|---|---|
| Xアカウント | @tatsuo4848 |
| fortee | fortee |
| リンク | ブログ |
感想
すみません、SREのことを誤解していました。
言われてみれば当たり前のことなんですが、チームみんなでよくしていく必要がありますよね。
「SREはロールではなくスキルである」という言葉が印象に残ってます。
SREはSREチームの人たち（SREs）がやるものではなく、ソフトウェアエンジニアリングの観点からサイト信頼性を高める活動をしていけたらと心に誓いました。
それはそれとして、弊社にもSREを推進するチームほしいかも。
テスト品質を向上させよう！ 〜 アンチパターン回避メソッド 〜
| スピーカー | Kanon |
|---|---|
| Xアカウント | @samurai_se |
| fortee | fortee |
感想
テストクラス名、AAAパターン、パラメタライズドテストといった基本的なテクニックの話からカバレッジへの向き合い方のお話をされていました。
パラメタライズドテストはリーダブルテストコードという考え方とちょっと相反するところがあるなぁとは思いました。 speakerdeck.com
カバレッジ50～80%を目指すということで、個人的な感覚とも一致し納得できるものでした。
100%を目指すと「デッドコードではあるけど明示的に処理している箇所」や「ほとんど発生しない例外パターン」までテストコードを書く必要があり、メンテナンスコストだけが発生することも多いと感じていました。
Mutation Testについては名前しか知らなかったので、今度詳しく調べてみます。 JavaだとPITがデファクト・スタンダードっぽい......？
単体テストを書かない技術
| スピーカー | きんじょうひでき |
|---|---|
| Xアカウント | @o0h_ |
| fortee | fortee |
感想
言語の違いを一番感じたセッションでした。
Javaをメインで書いていた関係でin/outの型があることが当たり前で、inやoutで期待する構造が来ているかを関数のテストとして書く文化がありませんでした。
一方Javaでも、例えば電話番号を期待する引数ではドメインクラスに切り出しているか否かで変わってくるよなーと当たり前のことを考えていました。 このへんは「概念に名前を与え、システムの制約にする」につながる話かなと思います。
前夜祭のときに少しお話させていただき、契約プログラミング的ですねーと会話したのですが、「戦術」の「考え方」でモロにでてきてますね（笑）
おわりに
PHP知らないのにPHPカンファレンスに参加しましたが、言語に寄らない話も多く、コミュニティも温かく、ためになる時間となりました。
これもスポンサー様、登壇者様、コアスタッフ/当日スタッフのみなさん、そして一般参加者の方々のおかげかと思います。
すばらしいイベントをありがとうございました。
