レイヤードアーキテクチャをはじめ、オニオンアーキテクチャ、ヘキサゴナルアーキテクチャ、いわゆるクリーンアーキテクチャ、他には独立したコアレイヤーパターンやADOPなど様々なレイヤ化アーキテクチャが存在していることからわかるように、レイヤを元にアプリケーションを構造化することはとても良いアイデアです。

しかし一方でレイヤを増やしたもののあまりメリットを享受できない場面も存在します。

このセッションでは、なんのためにレイヤ化をするのか、どういった観点でレイヤが作られるのか、レイヤ化することによってアプリケーションの複雑性がどのように管理しやすくなるのかといったことを考えてみたいと思います

Laravelの魅力でもあるEloquent Model。
良くも悪くも雰囲気で書けてしまう反面、特定条件下では正しく動かなかったり、パフォーマンスの悪いコードを書いてしまう恐れがあります。

本トークではEloquent Modelを使うときにハマりがちなトラップを取り上げて、それらが「良くない理由」と「どうすれば良くなるか」をご紹介します。

想定観客

• 雰囲気でLaravelを書いている方
• 不具合が起きにくいコードを書きたい方
• パフォーマンスの良いコードを書きたい方

お話しすること

• そのコード、nullが返ってきたとき死にます
• そのコード、クエリ1,000回発行されるけど大丈夫？
• そのコード、メモリ1GB使うけど大丈夫？
• 良くある間違いを仕組みで防ぐ (Laravel IDE Helper x PHPStan)

Renovate や Dependabot などが広く使われるようになったことでライブラリバージョンアップの対応頻度が高まっている現場は多いのではないかと思います。
ライブラリは導入することによって開発コストを大きく削減できる一方、使い方によってはバージョンアップの対応コストが必要以上に高くなりますので、バージョンアップ対応にそこそこの工数が取られている人も多いのではないのでしょうか。

このセッションではバージョンアップが楽になる使い方をいくつか提示し、それぞれのメリットデメリットを整理することでライブラリとの使い方・付き合い方について考えていきたいと思います。

世の中のプロダクトは、二つに大別出来ます。 「ライブラリ・フレームワーク」と「アプリケーション・サービス」 です。

この二つには何の違いがあるのでしょうか？それは、 「インターフェースであるか、ドメインであるか」 です。

一方は多くの開発者に向けて汎用的に作られたもの、もう一方は特定のエンドユーザーに向けて専門的に作られたもの。

この二つの目線を見分けることで、様々な諸問題と正しく向き合うことが出来ます。

このトークでは、インターフェースの目線とドメインの目線、二つの目線で技術に対することで得られるメリットをご紹介します。 「技術的負債」 とは何なのか。 「技術選定」 はどうすればいいのか。 正しい目線で物事を見極めたい あなたに、是非ご覧いただきたいと考えています。

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

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

このトークでは

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

といった切り口に対して

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

このトークでは、

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

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

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

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

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

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

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

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

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

乞うご期待！

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 を書く上で、静的解析ツールは必需品となりました。コードを実行する前に型を解決し、問題を明らかにすることで、開発イテレーションを大きく向上することが可能です。

静的解析ツールはいくつかありますが、その中でも PHPStan は非常に強力なツールとして利用されています。その PHPStan で最も細かく解析してくれる level: max を使うと、 mixed 型や array-shapes を含め 全ての変数に型を明示する必要があります 。

このトークでは、自作 PSR-7 実装を通して、どのようにして level: max な PHPStan で 型安全 に実装するか、そして その費用対効果がどれほどなのか を紹介します。

レベルマックスな PHP ユーザーは一体どうなるのか？解き明かします

PHPerの世界でもwhatやwhyが大事だ、howはなんでもいい、と言われるようになりました。
たしかにwhyやwhatはとても大事で、howは所詮howです。
しかし、howを軽視しすぎるのはおすすめできません。
「思考に気をつけなさい。それはいつか言葉になるから。言葉に気をつけなさい。それはいつか行動になるから。（後略）」というマザーテレサの名言にもある通り、howは知らず知らずのうちにあなたの設計方針に影響を与えてしまうのです。
howがどのように設計方針に影響を与えるかの実例をいくつか紹介した後、その対策についてお話しします。

クリーンアーキテクチャの同心円で、一番外側にあるデータベース。ドメインのコードはデータベースに依存させないように書きましょうと言われがちです。しかし、果たしてデータベースは本当に常にドメインの外側に置くべきなのでしょうか？
リンケージではLaravelとDoctrineORMを組み合わせてドメインのコードとフレームワークの距離を保ちつつ開発していますが、ドメインとデータベースとの距離については議論がありました。
Doctrineという技術選定、ドメインのコードからORMへの依存を許す決断をした根拠についてお話します。

トークの対象者

①
「このコード何となく良くない気がする、リファクタしよ〜」「書き換えてみたけど、しっくりこないな‥」
そんな経験はないですか？
②
「コピペコードになってるなぁ。もっと良いやり方がありそう…」「でも既存コードに手を入れる踏ん切りが付かない！」
そんな人はいませんか？

トークの趣旨

• リファクタリングには時折「概念の整理」が欠かせません
• 概念の抽出や切り分けには「抽象/具体化」を用います
• そうして「物の見方を変えていく」体験を提供します

トークのアプローチ

コードの代わりに、日本語で記述された要求・手続きの文章に「変更」を加えていきます

• 「開放閉鎖原則を満たす」を目的に変更していきます
• 具体的なコードを用いない事で、一歩引いて考える脳みそを鍛えます
• コーディングテクニックに依存しない、リファクタリング力の向上を目指します

良い設計技法やイケてるコーディング──
新しい事を学ぶ際には「なぜ生まれたのか」を知ると武器になります
そのために、「それが生まれる前の様子」を知ると助けになります

現代的な「良い」コードの探求のため、昔っぽい世界を覗いてみませんか？
「クラスもねぇ制御フローもねぇglobalやgoto頼りの世界」を覗いていきませんか？？？

手続き型？いいえ！もっと遡りましょう
「構造化プログラミング的な要素を排除しつつ、今日のPHP(8.4)で開発」に挑みます

話すこと

• 構造化プログラミングの簡単なおさらい(定義・歴史)
• コードサンプルと解説: 簡易CMS

「非構造化」のルール(一部)

• クラスや例外やwhile(true)以外のループや名前空間は使わない
• ユーザー定義関数: 引数は使わない・値を返さない/グローバル変数でやり取りする
• gotoや標準関数は使う