トーク

クリーンアーキテクチャを知っていますか？
そう(層)ですね。

クリーンアーキテクチャは層を切り分けることで、テストをし易い構造を作る設計手法です。
Controller -> UseCase -> Repository -> DataAccessObject
　　　　　　　　　　-> QueryService -> DataAccessObject
　　　　　　　　　　-> Service -> DomainService

こういった IO や処理を切り離し、各層において逆順での接続を許さないことで
ある程度のビジネスや機能に沿った実装をメインに置きながら、テストをしやすくした機構になります。
これだけをメインに据えたものは 軽量DDD ともいわれますね。

この構造を維持をするのは、人力レビューが基本のため、とても手間がかかります。
しかし、 php には phpat というアーキテクチャの定義ライブラリが有るのです。
これを使うことで、この構造を機械的に確認してくれるようになります。

リアーキテクチャを行う際に phpat を設定し、
1 年程度 実際に運用した内容とその変遷、
簡単な設定方法について皆さんにお話させていただきたいと思います。

6年ぶりに！関西で！PHPカンファレンスを開催してきました！！

PHPカンファレンス関西では、今回のテーマを「関西PHPエンジニアコミュニティの立ち上げ」とし、以下3つの達成を目標に開催しました。

• 新たなコミュニティ参画者発掘
• 関西での技術情報共有の場となる
• 持続可能な運営体制

実際のところ上記目標は達成できたのか？どのようなイベントになったのか？など、関西の熱気を5分でお伝えできればと思います！！

ジョシュアツリーの法則って知ってますか？
「名前を知ればそれを認識できるようになる」「名前を知らないと認識できない」といった現象のことです。

我々エンジニアの身の回りには様々な現象があり、中にはみんなが経験したことがあるものも多数存在します。
そんな「現象」や「事象」の中にはあまりにも名前が付けられ、事象の解消や共有が行われているものがあります。
名前を知ることは認識すること！
この発表を聴いてそんな""あるある""の名前を知り、事象を正しく認識して、次に生かしましょう！

多くのWEBアプリケーションで導入されているであろう ECS（Fargate） 環境では DB マイグレーションってどうやってますか？

ECS Execログインを利用して migrate コマンドを実行する
ecspresso をつかう
自前でマイグレーション用のコンテナを用意する
（他にもある？）
弊プロダクトでは マイグレーション用のコンテナを用意する 方法を採用しています。
コンテナ環境での DB マイグレーションの実行方法はあまり情報がないように思われるので参考になれば嬉しいです。

メールを送る処理の実装時うっかり誰かに送ってしまうことはないでしょうか？
開発時のメールの誤送信事故を防止するために、ダミーのメールサーバに送るようにするということが多いかと思います。
Mailcatcher や Mailhog、Mailpit などの便利なツールが公開されていますが何か使われていますか？

弊プロダクトでは、ツールは利用せずにログにメールの送信内容を出力しています。

このアプローチでの Laravel を利用した開発時のメリットとデメリット、ログの可読性を上げるための工夫など私たちが行っていることを紹介します。

皆さんはPHPサーバーのセットアップをどのように行っていますか？
手動で行う方法、構築済みサーバーを利用する方法、コンテナ技術を用いる方法など、様々な方法があると思います。
しかし、これらの方法は時間がかかったり、手順が複雑であったり、構成変更の柔軟性に欠けたりすることがあります。

今回紹介するのは、Ansibleという強力な構成管理ツールを用いた、PHPサーバーの構築・デプロイメントの自動化です。
AnsibleはSSH接続によってエージェントレスで動作し、軽量で学習コストも低いため、PHPサーバーの環境構築に最適なツールです。

このセッションでは、PHPエンジニア向けに、柔軟な構成で効率的にPHPサーバーを自動構築する手法についてお伝えします。

主な対象

• PHPサーバーの環境構築に興味のある方
• インフラ・DevOpsに興味のある方

概要

相当昔にLaravel 5.5でUploadedFileのことについてまあまあ詳細に書いてきたのですが、あれから数年も経ち2桁台に差し掛かってきたLaravelの現在のUploadedFileがどうなっているか、5年ぶりに暴いていこうと思います。

留意事項

現在リリースされている最新版の10.xでお話する予定ですが、11.xがリリースされた場合は、11.x版で修正してお話します。

アジェンダ

1. UploadedFileの歴史
2. UploadedFileの内容を暴く（表面上）
3. UploadedFileの内容を暴く(実装上)

不具合や障害発生時にSlackなどでエラー通知を受け取ることはありますよね。
そのとき、即座に何をすべきか具体的な対応方法をイメージ出来ますか？
エラー発生時の対応は、迅速かつ効率的でなければ、小さな問題が大きな障害に発展することも……！！

そこで、私がエラー通知を受け取ったときの初動〜対応完了までに「何を考えて」「どのように対応しているのか」をお伝えします！
このLTを聞けば、「エラー通知来ないでほしい」と願っている皆さんも、通知が来ても慌てることなく、冷静に対応できるようになっているはずです！

このLTを特に聞いて欲しい人

• 「エラー通知が来たら何をしますか？」に即回答出来ない人
• エラー通知は先輩がなんとかしてくれると思っている人
• 新卒PHPer、新卒PHPerがチームに加わった先輩エンジニア

リモートワークが日常となった現代、テキストコミュニケーションの重要性に気づいている人はどれほどいるでしょうか？
リモートネイティブとして、新卒から3年間の社会人経験を通じて、私が学んだテキストコミュニケーションの重要性をLTでお伝えします！

「先輩にどう質問する？」「ビジネス側のやり取りはどう進める？」などシーンに応じて、伝わりにくい文章の例をどう改善するか解説します！
そして、絵文字「👍」や感嘆符「！」など細かな表現まで、日々のテキストコミュニケーションで意識しているポイントを余すことなくお話しします！

このLTが参考になる人

• 社会人経験が浅い新卒エンジニア
• 長文を送って「何言いたいか分からない」「もう少し短くして」と言われたことがある人
• 日々のコミュニケーションで周りの人にもっと意識して欲しいんだよな〜と思っている人

多くのPHPerは日常的にGitを使用していると思いますが、理解して使いこなせているでしょうか？
このトークは、新卒PHPerやGit初心者を対象に、チーム開発におけるGitの“使いこなし方“に焦点を当て、実践的なノウハウをお届けします！

単にcommit&pushしているだけの「ただ使う」レベルから、わかりやすいPRを作るために適切なコマンドやオプションを選択できる「理解して使う」レベルへとステップアップしましょう！

具体的なトーク内容

• 具体的な実装を用いて、この修正に対してどうコミットすると良いかを解説！
• レビュアーにとってわかりやすいプルリクエストの書き方のポイント！
• チーム開発でブランチはどう切ると良いか？
• 便利なGitコマンド/オプションとその使い所！
• コミットやプルリクエストは今開発するためだけに必要なものじゃない。未来の開発者のために残していくものなんだ。

Gitを使いこなすことは、楽しいプロダクト開発に繋がるということを、皆さんに伝えたいです！

このトークでは、LaravelのORMシステムであるEloquentのアクセサ・ミューテタが何か、またクエリビルダとの違いは何かについて、PHP初心者に向けてわかりやすく解説します！！
その後、Eloquentとクエリビルダを組み合わせて使用する際の注意点について、実際に起こった失敗談を紹介します。
そして、この失敗から得た教訓をもとに、同様の問題を避けるためにはどうしたら良いのかについても掘り下げます。

このトークを聞くことで、Laravelを利用しているけれどもEloquentとクエリビルダの違いが分かっていない方も、明日からこの2つの違いを理解し、安全にデータベース操作ができるようになるでしょう！乞うご期待！

あれ気付いちゃいましたか？
PHPerの皆さんがとっても仲良しのIDE、PhpStormくんのかわいさ（便利さ）に。

あ、まだ気づいてない（知らない）んですね！
じゃあこのLTを聞いてPhpStormくんを布教されてください！！
わたしの推しのPhpStormくんの超かわいいところ（超便利な機能）を時間が許す限り詰め込んで紹介します！！

例えば、私の推しポイントはこんな感じだよ！！

• コード書いててヤバそうなところあったら教えてくれるとこ超優しい🫶
• 一発でメソッド抽出したり、簡単にリファクタリングが出来るところ超かわいい🫶
• ファイルの外部で定義されている PHP クラスを参照すると自動で保管してくれて超カッコいい🫶

他にももーっといっぱい推しポイントあるから当日楽しみにしててくださいね！！！
PHP初心者の方にとっては新しい発見に、PHP玄人の方には新たなPhpStormくんの推しポイントに気がつくきっかけになれば嬉しいです！
かわいいのはアイコンのカラーだけじゃないんですよっ！

「デプロイ頻度」は開発生産性を測る重要な指標の一つです。
2、3ヶ月程度かかる大きめの機能開発で、機能をまるっと作ってからリリースしようとすると、このデプロイ頻度が落ちてしまう経験をした方は多いのではないでしょうか？
このようなとき、プルリクエストが肥大化しレビューが複雑になり、見落とされた不具合や障害が発生しやすくなってしまいます。

このトークでは、私のこれまでの反省を活かし、大きめの機能開発でもデプロイ頻度が高い状態を維持した事例を紹介します！皆さんの日々のチーム開発に取り入れられるよう、具体的なテクニックについて順を追って説明します。

話すこと

• 細かくデプロイするために必要な設計の工夫
• タスクを分割するには、インタフェースだけ先に実装してデプロイしよう
• テストコードが先に書いてあると安心して実装できる
• チームでデプロイ頻度を上げるために取り組んだ施策

新卒入社して2、3年後ぐらいで出来ることが増え、大きな機能開発も任されるようになったとき、設計をどのようにすればいいか分からない、大きい変更のタスク分割が難しいと悩むことがあると思います。
このトークではその悩みを解決するヒントを見つけられる(かもしれない)のでぜひ聞きに来てください！

「◯◯の機能について、ここをこうして欲しいんですよね…」
（◯◯なんてあったっけ、あれかな…）
「はいっ！できました！」
「それ、◯◯じゃなくて××だと思うんですが…」

みたいな経験を一度は皆さんはしたことはありませんか？

本トークではプロダクトに機能を追加するという開発業務の中に、「情報設計」というステップを追加した時に具体的に何をやったのかについてのお話をします。

みなさん情報設計という言葉を聞いたことはありますか？
PHPerのみなさんは普段からどういった情報を扱っていますか？

情報設計は、扱う複雑な情報を整理することでチーム開発をより円滑にすることが期待されます。

本トークでは情報設計という考えを実プロダクトの開発フローに組み込み、具体的に何をやってどんな知見を得られたかをお話しします。

また導入はしていないが、他の情報設計を開発フローに組み込むかの方法についても考察します。

PHP8.3ではOpcacheにも改善が入りました。php.iniを僕は雰囲気で使っていますが、これを機会にしっかり最高の設定を考えたい。本業でECSで利用しているphp.iniについて最高のパフォーマンスを出すためのPHP
にするための設定を考えます。

PHPerKaigiが行われる3月という時期では、php-srcの新機能どころか、バージョン番号すら話せるタイミングにないことが多いです。
それは一体なぜなのか、というと、リリースマネージャーすら決まっていないことが多いためです。

本セッションでは、3月ごろでは何が行われているのか、年末になるリリースに向けて何が行われているのかというスケジュールを俯瞰して見られるようにしてみます。

LTで届けたいもの

「ユニットテスト、あまり好きじゃねぇぜ〜」という人に、「少しお世話になってみようかな！」と思えるキッカケを！

前口上

「テストが苦手、抵抗感がある…」という人が、「テストって良いかも！」と言うようになった瞬間を目撃した事があるのですが、
そのキッカケは「テストがあると便利なんだなと思えた」ことだったそうです。

テーマ

「便利で助けになる」と感じられる場面の1つが、「実装を低カロリーに読み解く、知る」です。
例えば、フレームワークやライブラリの挙動を知りたい時。
「このクラスどう使うの？」「このメソッドの引数はどんな？」
──英語や日本語で書かれたドキュメント以上に、PHPで書かれたテストコードは、「こういう事ね！」を感じ取りやすいです。

特に、エッジケースや微妙な値(境界値や「引数が逆だったら」etc.)については
わざわざドキュメントに書かれないものでも、テストとして明確になっていたりします。
更に！ちょっと書き換えて動かして試す〜なんて事も可能に・・そう、テストならね。

実例を交えて説明しますので、「積極的にテストに絡みに行ってみよ☆」となっていただきたい。
そんなLTです。

話すこと

• Test as Documentationの威力を知る
• 「コードに関する疑問を解いてみる」の実例
• テストを「使う」際のコツ

WordPressが好きなエンジニアがいるでしょうか？いいやいない。と反語を使いそうな勢いで、エンジニアは嫌いだという方を多く見ます。
もしかしたら、そんな中で良いところや悪いところを整理できていないかもしれないと考えました。
(ああぁ！！！！と叫びたくなる衝動を抑えて)冷静にWordPressの良いところ、悪いところを整理して発表します。

ジュニアエンジニアが多く、テックリードがあまりいないかも・・・？そんな環境でお仕事した方々はいないでしょうか？
ジュニアエンジニアの方々はすごく頑張ってくれているので、しっかりレビューしたいけど、する時間がない！
やるならできれば自分が本当に必要なレビューだけ頑張れるようにしたい！そう思っている方々も多いことでしょう！特にLaravelなら！！！
そんな時に僕がやっていたCI/CDを公開しつつ、何を考えてそのようなことをやっていたのか？についてお話しさせていただきます！