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

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

このトークでは

• 「Interfaceを設計する」とは？
• 「良いインターフェース」とは？
• インターフェース設計とその先

といった切り口に対して

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

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

複雑な条件分岐を含むビジネスロジックは、if文の入れ子で実装されがちです。
しかし、この方法では条件の追加や変更が困難で、保守性が著しく低下します。

デシジョンテーブル（決定表）は、複数の条件と結果の組み合わせを表形式で整理できる強力なツールです。
このテーブルをコードとして実装することで、ビジネスロジックの可視性が高まり、条件変更への耐性も向上します。

本セッションでは、デシジョンテーブルの実装パターンと実践的なコード例を紹介します。
さらに、ユニットテストとの相性の良さ、仕様変更への強さなど、実装のメリットを実例とともに解説します。
明日のコーディングから活用できる具体的な実装テクニックをお持ち帰りいただけます。

コードレビューは、チームの成長やコードの品質向上に欠かせないプロセスですが、組織やチーム体制によって位置づけや進め方が変わります。
本トークでは、コードレビューを効果的に運用するための工夫や、期待できる効果・避けるべきリスクについて考えてみましょう。

本トークで話す内容

• チームや組織ごとに異なるコードレビューの役割
• コードレビューに期待できること、気をつけるべき点
• レビュアーとレビュイーそれぞれの心構えと準備

何かしらのツールを入れたいが、予算がない・・・
なら、コストを削って予算を作ってみませんか？

本講演では、AWSを活用したシステム運用において、
使用頻度が高いサービスのコストを削減するためのテクニックを紹介します。

手軽にコストをカットする方法をはじめとして、
時間の許す限り、注意点も交えながら、以下のような内容を説明します。

主要サービスの特性理解と最適化: EC2、RDS、S3、Lambdaなど、よく使われるサービスでのコスト削減方法
・インスタンスの選択: リザーブド活用によるコスト最小化など
・ストレージコストの管理: S3でライフサイクルポリシーによる不要データの自動アーカイブ
・サーバーレスアーキテクチャの活用: LambdaでPHP

2024年1月、「なぜキャッシュメモリは速いのか」が話題になりました。
この質問に答えるのはなかなか難しく、X（Twitter）ではいろいろな回答がされていました。この回答はさまざまな立場・理解からされていて、Xのタイムラインをご覧になっていた方はいまいちしっくりこなかったのではないでしょうか。

このトークでは「なぜキャッシュメモリは速いのか」に答えるのに必要な知識を、初心者の方にもわかりやすくご説明します。

• キャッシュメモリとは何か
• なぜキャッシュメモリを使用するのか
• キャッシュメモリとメインメモリは何が違うのか
• 結局なぜキャッシュメモリは速いのか

キャッシュの使いこなしは現代コンピュータにおいて避けることはできず、キャッシュを制するもののみがコンピュータを高速に動作させられると言っても過言ではない状態です。キャッシュを理解し、キャッシュを楽しみましょう！

DDDといっても、複数のアーキテクチャ(クリーンアーキテクチャ、オニオンアーキテクチャ、ヘキサゴナルアーキテクチャなど)があると思います。この中でどのアーキテクチャを選定するかって悩みませんか？
そんな方向けに各アーキテクチャの比較をした話をします！

話すこと

• プロジェクトの検討観点(開発規模、開発メンバーの体制、外部システムとの連携など)
• 各アーキテクチャの比較(クリーンアーキテクチャ、オニオンアーキテクチャ、ヘキサゴナルアーキテクチャなど)
• 各アーキテクチャごとの向いているプロジェクトは？

本格的にDDDを導入しようとすると、なかなかヘビーで実際、開発が始まると開発スピードが上がらないこともあると思います。
そんな方向けに軽量DDDという設計手法をお伝えします！

そもそも軽量DDDとは？

• DDDのValueOvject、Entity、Repositoryなどを部分的にお作法のみを取れ入れ、DDDを行うというアンチパターンとして語られているものです。
• もしくは、コアドメイン、サブドメイン、境界付けられたコンテキスト、ユビキタス言語などを意識していないもの。

話す内容

• 軽量DDDとは？
• 軽量DDDが向いているプロジェクト、向いていないプロジェクト
• 実際の導入した場合の構成などの説明

皆さんLaravelでDDDやりたいと思ったことありませんか！？
このトークではこれから、DDDを始めたい人向けに導入方法やディレクトリ構成についてお話します。

□話す内容

• DDDでどのアーキテクチャを選定するべきか？選定基準は？
• LaravelでのDDDの導入ステップは？
• Laravelに導入する場合はどのようなディレクトリ構成が良いか？

みなさんPHPStanを使っていますか？ PHPStanはオープンソースで開発されているので誰でもソースコードを読んで仕組みを学ぶことができ、理に適った提案であれば取り入れてもらうこともできます。

ところが静的解析ツールはPHPや標準関数の仕様通りに実装すれば完成すればるというわけでなく、さまざまな考慮事項や現実との折り合い付けかたなどがあります。

本トークでは私がこれまでPHPStanに送信したPull Request(※トークプロポーザル時点で未マージ含め49件)について分類して紹介します。

• 取り入れられた提案
• マージされたPR
• マージされなかった
• マージされたが後にrevertされた提案
• 投げ出してしまって完成していないPR

良い設計は「コードの書き換えやすさ」をもたらします
そのためには、関心の分離や抽象度の調整といった仕事が必要です。難しそうですね¯\(ツ)/¯

見方を変えれば 今、一緒に考える?後回しにしたい?を意識すれば、良い感じになりそう と言えるでしょう
コードを書きながら「ここ面倒臭いな」と思う場面、ありますよね？そこにヒントが眠っています

原則やパターン等の形式知だけでなく、感覚に頼って「良い設計」を手に入れられるはず！！というのが本トークの主張です

話すこと

• プログラミング中の「(誰しも)あるある話」を取っ掛かりに
• 実はそれがチャンスであることと、対処法を示し
• 「何故それで良いと言えるのか」の論理的な補強を行う

ねらい

• こんな人に: 「設計って難しそう・自分にはまだ早い」と感じている人
• こんなお土産を: 「良い設計を目指す最初の一歩」になる

PHPアプリケーションをサーバレス環境で動かしたいと思ったことはありませんか？軽く調査していくといくつかやり方はあるようです。

このセッションでは私が実際に様々な方法で簡単なPHPアプリケーションをデプロイしてみてわかったことを共有します。
ホスティング先の参考になれば嬉しいです。

時間の許す限り、以下のようなプラットフォームやツールをセッション中扱う予定です:

• AWS Lambda
• Google Cloud Functions
• Google Cloud Run
• Vercel Functions
• fly[.]io
• Serverless Framework
• Bref

PHPUnitには多くの便利なアサーションが用意されていますが、
わたしたちが普段使っているフレームワークにも独自のアサーションが実装されていることをご存知でしょうか？

普段便利に使わせてもらっているアサーションの中身がどうなっているか、みたことはありますか？
「まだ、みたことない・・・！」という方、このセッションでテストの裏側にある仕組みにDeep Diveし、テストライフをさらに快適にしていきましょう！

話すコト

• PHPUnitがどのようにアサーションの結果をOK/NGと判断しているのかを知る
• 各フレームワークにあるいろいろなアサーションを知る
• 自分でカスタムアサーションを作成するという選択肢を知る

私はスクラムを使って日々プロダクトを作っています。
その中で、スプリントレビューに「手応え」を感じたことがありました。
一方で、手応えがないレビューの時、自分では「うまくいっていない」と気づいていなかったことに後から気づきました。

効果的なスプリントレビューを体験したことで、
過去に「うまくいっていなかった」ことが明らかになり、改善の余地を見つけられました。

このセッションでは、経験主義に基づいて学んだ「うまくいくスプリントレビューのコツ」を具体例と共にシェアします。
また、どのロールの人でも実践できる、スプリントレビューを成功に導く方法についてお話しします。

話すコト

• なぜスプリントレビューを「うまくいかせたい」のか？
• 「うまくいかない」レビューとは？原因は？
• 「うまくいく」レビューの具体例と成功のコツ
• 各ロールごとの素敵なスプリントレビューを創るためのHOWTO

「タスクが大きすぎて進めにくい」「タスク同士が依存して足を引っ張り合う」「ああ、またコンフリクト…」
といった状況に心当たりはありませんか？
少なくとも私は、この悩みを何度も繰り返し経験してきました。

良いプロダクトを迅速に届けるため、開発タスクを効率よくmainブランチに統合していきたい。
その思いを胸に、試行錯誤しながらタスクを「疎」にするための方法を自分なりに編み出してきました。

しかし、「疎にできるけど、疎にしないほうが良いタスク」も存在することに気づいたのです。
この発表では、爆速で効率よくチーム開発をするための「タスクのちぎり方」について話します。

話すコト

• そもそも、なぜタスクを疎にしたいのか？
• 疎にすべき場面とそのパターン
• 疎にしないほうが良い場面とその理由
• リソース効率 vs フロー効率のバランス
• タスクを疎にするテクニックN選（時間の許す限り）

弊社の主要な検索機能では、Laravel Eloquentを用いたRDS上の検索クエリにおいて、複数テーブルのJOINや複雑なクエリ構造が検索パフォーマンスに影響を及ぼしていました。特に、利用頻度の高いクエリがレイテンシー増加の主因となっていたため、その改善策としてOpenSearchを導入しました。

導入後、検索速度が飛躍的に向上し、レイテンシーも大幅に改善されました。
また、OpenSearchのPHP DSLライブラリを導入することで、クエリの構築をシンプルにし、保守性を高める工夫も行いました。

Laravel eloquentとの共存を図りながら、検索機能のパフォーマンス最適化を実現しました。
これらの経験を基に、検索機能改善の実例を紹介します。

このトークは、パフォーマンスに課題を抱える開発者や、検索機能の改善に興味のある方に向けた内容です。

Form・Html ファサードは laravelcollective/html パッケージに含まれています。
このパッケージは放棄されており、spatie/laravel-html への移行が推奨されています。
私の関わるサービスでの使用箇所は約1,700箇所…！
移行ツール「Shift」で移行しましたが一筋縄ではいかず…

今回は laravelcollective/html の Shift による移行で、苦労して得た知見をご紹介します。

■ 内容

laravelcollective/html から spatie/laravel-html への Shift による移行方法
Shift でうまくできなかったところ
移行前後の違い
■ 対象

laravelcollective/html の移行を検討している人
移行ツール Shift がどういうものか知りたい人

カンファレンス等では話を聞くことも多いテストコード。テストコードをかけると、それが命綱のような役割となり、安心してコードの変更を行えるようになります。

ですが、歴史の長いソフトウェアでは、様々な経緯からテスト環境が導入されていないこともあります。

本トークでは、Laravelなどのフレームワークを入れるのではなく、ゼロからテスト環境を導入する方法を解説します。

• composerでphpunitをインストール
• autoloadの設定
• phpunitの設定ファイルの記述

このトークを通じて、みなさんも関わっているプロダクトで、テストコードのゼロイチに挑戦してみませんか？

話さないこと

• 良い単体テストコードの書き方

可読性のためにコードのネストを浅くすることはとても良いプラクティスです。
ガード節はネストを簡単に解消できる手法として広く勧められていますが、途中リターンを多用することに問題はないのでしょうか？

このトークでは、ガード節を使うメリット・デメリットを詳しく分析し、さらに可読性を高めるために考案した新しいテクニックを、具体的な例を交えながらご紹介します。

ネストが浅くて読みやすいPHPコードの作成にきっと役立つ情報をお届けします。

抽象構文木:ASTの名前は、PHPStanやRectorの普及もあり、少し身近な存在になってきました。

しかし「コンパイラでもない人間の我々が、なぜ喜ぶのか？」と思う人もいるはず。
名前や、チラッとだけ概念は知っている。けど、何をもたらしているのか──

そこで、ASTの概念の応用例に触れてみたら、その世界に入門しやすいのではないか！！というトークです。
「こういう事もできる(応用)」「そのために(基礎概念)」を話します。

例えばajthinking/archetypeはプログラマブルな「コード書いてくれる君」です。
ソースコード生成が「スタブの文字列置換やTwigのレンダリング」に頼らず出来るようになる！
じゃあ、その内側のどこにASTがいるんだ！

応用例から「逆に入っていく」アプローチで、ASTと少し仲良くなることを目指します。

概要

Language Server Protocol (LSP)は、2016年にMicrosoftが発表したJSON-RPCベースのプロトコルです。
LSPはモダンなテキストエディタなら必ずある機能(e.g. 定義ジャンプ)を提供していますが、一番の魅力は特定のテキストエディタに依存しない形での実装になっていることです。
これにより各テキストエディタでの実装の必要がなくなり、エディタ選択の自由度が飛躍的に高まりました。

PHPの言語サーバ実装はintelephenceとPhpactorがメジャーです。
本登壇ではPhpactorの実装に触れつつ活用テクニックを紹介していきます。

このトークでお話すること

• LSPの台頭とLSP前後のテキストエディタの変化
• プロトコル解説とLSPがサポートしている機能の紹介
• PhpactorとPHPStan拡張などの便利機能紹介