Interfaceの設計、していますか？

適切なInterface設計はコードの再利用性を高め、保守性を高める一方
不適切な設計をしてしまうと不要な複雑性を周辺に生み出し保守性に大きな悪影響を及ぼしてしまいます

このトークでは

• Interfaceを設計するとはそもそもどういうことか？
• 良いインターフェースの条件
• インターフェース設計の先にあるもの

といった切り口に対して

• サンプルコード
• 有名な設計原則
• 書籍の引用

などを用いながら「良いInterface設計」とその効果について解説します

プログラミングの現場で、顧客の要求する仕様をクラス設計していくと、共通する機能が出てくることがあります。
そこで聞かれる
「共通する機能ってスーパークラスに実装するのと、インターフェースにするの、どっちがいいんですか？」
という疑問。
それにお答えします。
より現場にありそうな問題を取り上げて、ドメイン駆動設計の入り口まで紹介します。。

＜対象者＞
・プログラミングを始めて2，3年以上
・オブジェクト指向でプログラミングをしている
・オブジェクト指向のプログラミングを理解はできるし、自分で書いているが、うまく書けているか自信がない

成長、できていますか？
皆さんは今年どんな成長をし、来年はどんな成長を計画しているのでしょうか？

このトークでは30代半ばでの初めてHello Worldから異業種からの転職を経て、「エンジニアとしての経験年数に対してパフォーマンスが高い」と評価を受けることが多くなった現在まで、「一貫して意識してきたたった１つのこと」についてお話します。

自身のスキルに悩んでいる方、成果を出せるように成長したい方のヒントになれば幸いです

サービスを切り出す際に、既存の再利用可能な実装を活用しつつ、ヘキサゴナルアーキテクチャを導入した背景とその効果を紹介します。このトークでは、特定のレイヤーにプロセス外依存や既存コードへの参照を局所化し、依存箇所を明確に管理することで、どのように開発効率やシステムの保守性を向上させたかを具体的な事例を通して説明します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この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向けのフレームワークです。
本格的なWeb APIの開発に必要な機能を幅広く備えており、PHPでWeb APIを開発する際の有力な選択肢の一つとなっています。

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

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

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

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

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

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

例

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

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

このセッションでは、

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

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

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

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

ソフトウェアエンジニアには抽象化の能力が重要と言われます。
では実際に抽象化とはどのような能力なのでしょうか？

実際の事例を交えながら、抽象化を理解し、実務に活かせるようにします。

話すこと

• 抽象化と具体化とは
• 抽象化のメリット
• 現実で身につける抽象化の階層
• 抽象と具象の往復とは
• ソフトウェアと抽象化

話さないこと

• 具体的なソフトウェアの実装における抽象レイヤーの話

PHP やプログラミングにまつわる内容をクイズ番組のような形態で早押しで答えていただきます。
回答者（またはチーム）はカンファレンス前に募集しておき，トーナメント形式で実施します。チームを組むのもあり，一人で答えるのもありの本格クイズ形式で進めます。

例えば以下のようなクイズに早押しで答えていただきます:

「PHP でファイルパスを指定して，ひと関数だけで読み込むには file_get_contents を用いますが，ファイルパスを指定してひと関数だけで書き込むには何の関数を使えばよいでしょうか？」
のような出題に対して「答え: file_put_contents」とどなたかが（もしくはチームが）答えられると正答数が加算されるような仕組みです。