トーク

このトークでは、フロントエンドとバックエンドの整合性を保つために、スキーマ駆動開発（SDD）をPHPプロジェクトにどのように適用しているかを詳しくお話しします。スキーマを契約として定義し、その契約を守ることで、開発の信頼性と効率を向上させる方法を解説します。具体的には、スキーマ設計のプロセスから実装フェーズでの管理方法、さらにトラブルを未然に防ぐための戦略までを包括的に紹介します。

新しく加入したメンバーの皆さん、チームに馴染めていますか？
新しいメンバーを迎えた皆さん、メンバーに馴染めてもらえていますか？

一説によるとWebエンジニアの平均在籍年数はおよそ3〜4年だそうです
ということは、最初の半年〜1年である程度新しいメンバーを戦力化できないと、エージェントに支払う費用などを考えると企業としてはよくてトントン、悪いとマイナスになってしまいます

このトークでは「馴染む速さ」に定評のあるいち個人が最近の転職で経験した

• 「オンボーディングされる側」として意識していたことでうまくいったこと
• 自分が組織に馴染む速さを支えてくれた会社の文化
• 上記を２つを支えていると感じた社内の仕組み

についてお話させていただきます。

採用する側、される側双方にとってのROIの最大化のヒントになれば幸いです

TLS/SSLについて暗号化と証明書のチェックをする程度という理解でも困ることは少ないですが、もう一歩踏み込んでどのようなプロトコルになっているか、公開鍵の署名や共通鍵の暗号はどう選ばれ使われているのか、これらのレイヤーを詳しく見ていくと非常に興味深い世界が広がっています。
このセッションでは、そんなTLS/SSLの内部構造に迫り、技術の楽しさを共に味わいたいと思います。

数ヶ月前の私も、TLSについては漠然とした理解しか持っていませんでした。しかし、PHPでTLS1.2を実装する中でその複雑さが実に面白く、やがて「完全に理解した！」と言える境地にたどり着きました。

本セッションでは次の内容を発表する予定です

• TLSの基礎
• PHPでの実装ポイント
• 車輪の再発明の面白さ

15年間誰も手をつけられなかったレガシーシステムを、どのようにしてバグゼロでリプレースに成功させたのか、その実践的な戦略をお伝えします。
私の考えたオリジナルの手法をはじめ、シャドーテスト、カナリアリリース、ダークローンチ、ランダムテスト、フォールトマスキングなど、多彩な手法を駆使し、リスクを最小限に抑えながら安定したシステム移行を実現しました。
特に、これらのテクニックを組み合わせることで、予期せぬトラブルを未然に防ぎ、計画通りのリプレースを成し遂げたプロセスを詳しく解説します。
他のプロジェクトでも応用可能な、実践的な知見を共有しますので、システム刷新を検討している方にとって必見の内容です。ぜひご参加ください。

皆さん、チームを分割してみたけど、結局また一つにまとまっちゃったことありませんか！？

チームが分かれれば効率も上がる、役割も明確になる…なんて思っていたのに、なぜかチームが再び一つに引き寄せられてしまったんです。

その原因、実は「コンウェイの法則」にあったんです！

このLTでは、どうしてチームを分割したのに再統合が起きたのか、そしてその結果として何が得られたのかを赤裸々に語ります。

私たちが直面した課題や学びをシェアして、みなさんの組織設計にも活かしてもらえたら嬉しいです！

弊社M&Aクラウドでは会社や事業を売却したいユーザーと、その会社や事業を買いたいというユーザーがマッチングするプラットフォームを提供しています。
そのシステムでは、マッチングした場合のみに特定の情報が閲覧開示されます。
しかし既存の実装ではほとんどUIに近い層で情報をコントロールしていたためヒヤリとする実装となっていました。
このトークでは情報の開示レベルを制御する設計方法を紹介します。
PHPStanも活用し、コーディングの時点で開発者が迷うことなくオブジェクトを利用できる設計を紹介します。

皆さん、丸投げされてますかーーー！！！？？？

どんな現場にも「タスクとしてパスできる状態に仕立て上げる暇がないから放置されちゃってる仕事」というものがあります。
きっと上司やお客さんは「丸投げできる人がいれば・・・」と日々嘆いていることでしょう。
そう、なんと「丸投げされる技術」があれば一生食うに困らないのです！（過言）

私はよくお客さんから「こんな雑な投げ方なのにいい感じに対応してもらってマジで助かります！あざす！」みたいなことを言われます。

一体私はどのようにしてお客さんに安心して丸投げをしてもらい、どんな手順や仕草で仕事を進めているのでしょうか。

このLTでは、仕事を丸投げしてもらったときの私の頭の中身や実際にやっていることなどをまるっと皆さんにシェアします。

皆さんも丸投げされる技術を習得して青天井の信頼をGETしちゃいましょう！

Macユーザーの皆さんにはお馴染みのHomebrew。
Macの初期設定時のみならず、日々新たに便利なコマンドを見つけてはbrew installしていることと思います。
そんなお馴染みのHomebrewですが、裏側はどんな仕組みになっていて、コマンド自体はどこからダウンロードされているのかはご存知でしょうか？

実はこれ、とても簡単な仕組みになっていて、誰でも自分のGitHubリポジトリを通して自作のコマンドをHomebrewで配布することができます。

このLTでは、実際にPHPでCLIツールを作ってHomebrewで公開するまでの流れをお話しします。
自作のコマンドをHomebrewで公開して、世界に羽ばたきましょう！

Macで複数バージョンのPHPを使い分けるのって意外と難しくないですか？
Docker経由でしかPHPを使わない猛者スタイルなら困らないかもしれませんが、
パフォーマンスや開発体験の問題からローカルのPHPを使いたい事情もあると思います。
phpenvやsymfony-cliと.php-versionファイルを併用すればディレクトリごとに使用するPHPバージョンを指定することもできますが、
この辺はいざ導入しようとするとYak Shavingの嵐が待っていて（実体験）非常に面倒だったりします。

というわけで、このLTでは私がMacのローカル環境で複数バージョンのPHPを楽に使い分けるために実際にやっていることを5分でサクッとお伝えします。
実際に運用していてまったくストレスを感じていない方法なので、ちょっとでも困っている人には明日からすぐにお役立ていただける内容だと思います！

Doctrineは、Symfonyフレームワークの標準の構成でも採用されているPHP製のORMです。

Laravel全盛の現代、Doctrineには全く馴染みがないという方も多いと思いますが、
いつSymfony案件にアサインされるかもしれません。備えあれば憂いなしです。
それに、普段と異なるパラダイムに触れることは学びの面でもとても有意義だと思います。

この機会にDoctrineを完全にマスターしておきましょう！

このトークでは、

• 「Active Record」と「Data Mapper」の違い
• Doctrineがデータを扱う仕組み（「Doctrineの世界」という感覚）
• エンティティマネージャー、Unit Of Work、リポジトリなどの要素概念

などについて25分で可能な限り詳しく、そして分かりやすく解説します。

SOLID原則の中でも最重要と評されることも多い「依存性逆転の原則」。

• 上位モジュールは下位モジュールに依存してはならない
• 抽象は具象に依存してはならない

という説明は100万回ぐらい聞いたけど、正直いまだにピンと来てない・・・という人も多いのではないでしょうか。

このトークでは、そんな掴みどころがなく理解しにくい「依存性逆転の原則」について、

• 適用する前後の具体的なコードを示しながら
• 適用しないと具体的にどんな問題があるのか
• 適用すると具体的に何がどう嬉しいのか

をとことん分かりやすく解説します！

このトークを聞けば、今まで何となく知識として知っているだけだった「依存性逆転の原則」が、
実際に日々のプログラミングの中で使いこなせる道具に変わるはずです。

乞うご期待！

API Platform は、Web APIの開発に特化したPHP向けのフレームワークです。
エンティティクラスにアトリビュートを1行追加するだけで一瞬でREST APIとOpenAPIドキュメントを生成できてしまう手軽さを持ちながらも、
本格的なWeb APIの開発に必要な機能を幅広く備えており、PHPでWeb APIを開発する際の有力な選択肢の一つとなっています。

このトークでは、API Platformの導入方法から、State Provider・State Processor・OpenAPIドキュメントのカスタマイズといった重要な基本機能の概要までを、
実際に動作するデモをお見せしながら丁寧にご紹介します。

皆さんにAPI Platformの概要を知っていただき、少しでも興味を持っていただければ幸いです！

API Platformは、Web APIの開発に特化したPHP向けのフレームワークです。
本格的なWeb APIの開発に必要な機能を幅広く備えており、PHPでWeb APIを開発する際の有力な選択肢の一つとなっています。

エンティティクラスにアトリビュートを1行追加するだけで一瞬でREST APIとOpenAPIドキュメントを生成できてしまう優れものなのですが、
ある程度複雑なことをしようとすると途端にフレームワークについての深い理解が求められ、入門と実戦の間には大きな隔たりがあります。

このトークでは、API Platformの導入方法から基本機能の概要、さらには実践投入に向けた各種ワークアラウンドや実装テクニックを、
実際に動作するデモをお見せしながら丁寧にご紹介します。

API Platformの実戦投入、あるいはその検討の一助になれば幸いです！

ユニットテストにおいて、テストダブルをうまく使うことは必要不可欠です。
しかし、それらの違いや使い分けを誤解していることも多々あります。
PHPUnitでも、モックやスタブを適切に使わないことで、意図が伝わりにくい不明瞭なテストコードが生まれてしまいます。

このセッションでは、具体的な例を交えつつ、PHPUnitにおけるテストダブルの適切な使い分けについて話します。
プロダクトコードだけでなく、テストコードにおいても可読性は大事です。
良いテストコードを書くために、良いテストダブルの使い方を知っていきましょう！！

話すこと
・モックとスタブの違い（基本の部分）
・PHPUnitにおけるテストダブルの使い分け
・使い方が間違っているケース（具体例）

Tests as Documentationという考えがあります
自動化テストは、コードの動かし方と、どう動作するかを示す文書のようにある(べき)です
つまり、他者を意識して何かを伝えるのを助ける存在とも言えるでしょう

もっと言えば、受け取る側と伝える側がいる”Test as Communication"とも呼べそうです
例えば、プルリクエストを送る場面。レビュアーに「伝えるため」のテストになっていますか？
何を理解して欲しいか、どこを気にして欲しいか、そのために何を強調するか──

テストコードを「伝わりやすくする」ため気をつけている事を、 主観や好みや癖を盛り盛りで話します

例

• 一時変数・メモ変数で「名前」を与える
• データプロバイダーをどう使うか
• カスタムアサーションの導入
• 読まなくて良いモノを奥に押し込む

Laravelでbladeを書く際に、 @csrf という「おまじない」を書いた経験が誰しもあるかと思います。
この @csrf は CSRF攻撃を防止するためのものですが、CSRF攻撃とは具体的に何で、@csrfを書くことでLaravelが裏でどのようにCSRF攻撃を防いでいるかを説明できるでしょうか？

このセッションでは、

• CSRF攻撃について改めて復習
• @csrf はなにをしているのか？
• LaravelはどのようにCSRF攻撃を防いでいるのか？

についてお話しできればと思います。

現在時刻に関するテストの話題、よくありますよね。
ユニットテストでは現在時刻に関するテストも可能な設計にしているかと思いますが、
QA環境で、たとえばプロダクトマネージャーやその他企画職の様なエンジニア以外の方が、
未来の日時に始まるキャンペーンをテストしたい場合、どのようにされていますでしょうか？

DBのキャンペーン開始日時のデータをいじる？
　→DBじゃなくてソースコードにハードコーディングされていたら？
ソースコードに書かれている開始日時を修正しちゃう？
　→それもいいけど、間違えてデプロイしない？それに何度もやるのはめんどくさい。

など簡単な手段はありますが、デメリットもあります。

これらのデメリットを解消し、誰でも簡単に現在日時を変更して検証できるようにした（前半は現在時刻に関する一般的な設計テーマ、後半はSymfonyを使った実装アプローチについて）話をしたいと思います。

WordPress運用、苦労してませんか？

• 本体やプラグインのアップグレードに追従できない
• アップデートしたら重大なエラーで突然サイトが止まってしまった
• ファイルアップロードでのサイト更新にミスがあって想定通りの表示にならない

こういった、WordPress運用をサーバーで行うことの辛いところを解消する運用を編み出したチームがあります。ぼくたちです。

このLTでは、以下について実現できて運用している事例を紹介します。

• composer でプラグインを管理する手法
• docker compose を利用してローカルで本番同等の表示を再現する機構
• 既存のWordPressサイトを、EFSとS3だけの、RDSなしでECS移行
• AWS DataSync を利用した本番環境とは別の場所での環境再現

Webサービスは、検索エンジンのクローラーから脆弱性を狙った攻撃Bot、さらには転売目的の在庫探索Botまで、様々なBotによるアクセスにさらされています。検索エンジンのクローラーはサイトへのアクセス増加というメリットをもたらしますが、その他のBotアクセスはサービスの安定性やセキュリティに深刻なデメリットを引き起こします。
このセッションでは、Pythonを利用した機械学習を用いて、これらのBotアクセスを効率的に判別し、効果的なアクセス制御を実現した事例についてご紹介します。特に、PHPで構築されたWebサービスやWordPressを運用している方にとっては、脆弱性を狙った攻撃からの防御が他人事ではないと感じていることでしょう。
実際のデータを元に、どのようにしてBotアクセスの特徴を捉え、機械学習モデルを用いてこれらのアクセスを分類・制御するかについて、具体的な方法論を紹介します。

ある程度複雑なWebアプリケーション機能を作るとき、ユニットテストを書くべきか、結合テスト（aka 機能テスト, FeatureTest, FunctionalTest）を書くべきか？
カンファレンスに参加する意識の高いPHPerの皆さんは「テストコードがあるだけでありがたい」は平成で卒業して、プロダクションコードだけでなくテストコードも保守しながら持続可能なアプリケーション開発を目指していることと思います。「このクラス、どうテスト書けばいいですかね？モックを使ったユニットテストでも書けるし、DBデータを使ってユニットテストすることもできるし、呼び出し元のコントローラに対するテストでも書けるんですが…」
最近、チームに新しくjoinしたメンバーと議論したのをきっかけに、私が自分なりに定義し直したテストコードの「要はバランス」についてお話しします。