トーク

Laravel 11 待望のリリース！
公式のアップグレードガイドを見るとこのような記載が。

『アップグレード見積もり時間：１５分』

・・・本当に？

公式が言うのであればそうなのでしょう。
幸い、えんさがそっ♪は PHP 8.3 / Laravel 10 と好条件が揃っている。
では 15分 でアップグレード完遂という高みに挑戦しようではないか。

外部システムと連携を行うときに、頭を痛めるのが ”APIでの連携” です。
API で機能連携を行う場合、みなさんも一度はこんな経験があるのではないでしょうか？

「レスポンスデータが扱いづらい」
「エラーレスポンスを適切にハンドリングできない」

私たちのチームでも同様の課題に直面しましたが、
API 呼び出し時に専用の Result 型 を用意することで、解消することができました。

これであなたも、API の仕様に惑わされない実装ができるようになります。

「実装は今日からです。仕様はまだ決まっていません。」
チームに告げられた計画はあまりに無謀で、誰もが炎上を覚悟した─────。

私たちのチームではスケジュールの都合上、仕様が確定する前に実装に着手する必要がありました。
この危機的状況を切り抜けるため、サービスで採用していた ”オニオンアーキテクチャ” の利点を最大限活かし、
ドメインモデルを中心として ”仕様が決まっているところから着手する戦略” を取りました。
この戦略により、仕様の確定を待たずに手を動かせたことによって、スケジュールの遅延を防ぐことに成功しました。

実際にオニオンアーキテクチャによって、開発がブーストした事例を紹介します。

さあリファインメントを始めよう
→適切なサイズに区切るには見積もりが必要だな
→見積もりの精度を上げるには何を作るかが明確じゃないと
→リファインメントが終わらない！！

リファインメントに時間がかかりすぎる我々のチームは、「リファインメントとは何か」を考え直すことにしました。
スクラムガイドの定義を調べ、実際にやっているリファインメントと比較した結果、
辿り着いた答えは「我々のリファインメントはリファインメントじゃない」でした。

このトークでは、なぜ我々のリファインメントはリファインメントではないのか、方針を変えたことでチームにどのような変化があったのかをお話しします。

さあリファインメントを始めよう

皆さんは、Laravelでの定期実行をどう実現していますか？？

我々のチームでは、サービスをECSにてデプロイしていることもあり、Laravelのタスクスケジュール機能を使わない選択をしました。

しかし、ECSのLaravelサービスに対して定期実行する方法には、以下のようなものがあります。
・ECSのスケジュールされたタスク
・Amazon EventBridge SchedulerからのECSタスクの実行
・Amazon EventBridge SchedulerとLambdaを使用したAPI呼び出し
この中から「早くて安くて安心な」手段を選ばねばなりません。
そこで、AWSのコストを抑えつつ、必要な要件を満たし、運用が簡単な方法を見つけるべく我々はアマゾン（AWS）の奥地へと向かいました。

そして冒険の果てに見つけた、最適な定期実行の方法をお話します。

DKIM、DMARC、SPF
これらを説明できるでしょうか？

2024年4月から本格的に始まったGmailのガイドラインに基づくメールの受信拒否設定によって、メールセキュリティの考慮は他人事ではなくなりました。
これは、非エンジニアにとっても同じです。
場合によっては、サービスの利用者にGmailガイドラインに対応するよう依頼する必要があるからです。

しかしながら、これらの知識はどうしても専門的な技術知識なしでは説明しづらく、非エンジニアにとってはなおさら理解しづらい分野です。
難しい専門用語を使わないよう注意しながら、非エンジニアの方に理解してもらおうと頑張って資料を用意して説明した方も多いのではと思います。

この発表では、非エンジニアの人にも伝わるよう、今押さえておくべきメールセキュリティについて解説します。

背景
あるプロジェクトでたくさんの障害を発生させてしまった。。。
障害はユーザーに迷惑をかけてしまうし、エンジニアのメンタルが削られるし、進行中のスケジュールを圧迫する。全然いいことがない。障害はこの世から無くなって欲しい。せめて減らしたい。。。
そんな思いから開発プロセスを見直す動きが社内で生まれました。

お話しすること
・そもそも障害と何なのか？障害と向き合う
・適度な障害予防コストのバランス
・プロセス確立までの道のり
・実際のプロセスや工夫を紹介

障害を少しでも減らしたい、自分のチームに見合ったプロセスをカスタマイズしたいと同じ悩みを抱えているPHPerの皆さんにお伝えできれば幸いです！

静的解析は堅牢なPHPアプリケーションを作るための手段として広く認知、活用されるようになりました。
特にPHPStanは技術カンファレンスでも多く言及されており、PHPにおける静的解析のデファクトスタンダードとも言えるツールです。

PHPStanはそれ単体だけでも効果を発揮しますが、拡張機能を使うことでより精緻な解析ができます。
例えばLaravel向けの拡張であるLarastanを使うと、マイグレーションファイルのスキーマ情報により、EloquentモデルのDBカラムの型を解釈できるようになります。

本トークではPHPStanの拡張機能の読み方を紹介するとともに、実際の拡張機能がどのように実装・実現されているのかを見ていきます。
拡張機能のコードを読むことで静的解析の威力を知っていただき、より効果的に静的解析を活用していくきっかけとなれば幸いです。

NeoVim IDE。
本セッションでは、VsCodeやJetBrains製品が提供する「統合開発環境」としての機能を、NeoVimとTUIを利用してTerminal内で表現する事であると定義します。
LSP、DAP、補完やGitにDocker操作等々のIDEとしての環境をNeoVimで構築するまでのステップと、その効率性について解説する内容になります。
皆さんに「こんな選択肢があるのか」と自分の開発環境を見直す機会になることがGoalです。

話すこと

• なぜTerminalで完結させているのか
• NeoVim IDEとIDE製品のPros/Cons
• Lua言語について
• Terminal周りのOSS事情と、Rust製の勢い
• 自分が大規模コードをNeoVimのみで編集できるようになるまでの四苦八苦
• PHPでのライブコーディング

PHPのパフォーマンスを飛躍的に向上させる次世代のPHPサーバー「FrankenPHP」とLaravel Octaneを組み合わせることで実現する高速なPHPアプリケーション開発について紹介します。
本セッションでは、FrankenPHPの基本概念、従来のPHP FPMとの違い、Laravel Octaneとの統合方法、そしてリアルタイム機能や高トラフィック対応の具体的なユースケースについて解説します。

Laravelにおいて認証・認可はGate・Policyの仕組みに沿えばイージーに実装が可能です。
しかし、OktaやMicrosoft Entra IDといった外部IDプロパイダーを使用し、認証自体はWebアプリケーションに到達する前に行いたい場合もあります。

このトークでは、AWS ALBと外部IDプロバイダーを使用しOIDCで認証を行いつつ、LaravelではCasbinという複数言語をサポートしているアクセス制御するための認可ライブラリを使ったRBACの実装例を紹介します。
また、ALBの誤った設定によるALBeastと呼ばれる脆弱性についても触れます。

他社がどのようにスクラムを行っているか、気になったことはありませんか？
このセッションでは、私たちがどのようにスクラムを実践しているか、その具体的な取り組みをシェアします。

私たちのチームでは、サーバーサイド、フロントエンド、そしてネイティブアプリのエンジニアが同じチームで協力しながらスクラムを進めていますが、それゆえに発生する課題も少なくありません。
使用しているツールやスクラムイベントの実施方法はもちろん、発生した課題とその対策について詳しく話します。
また、モチベーションを高めながら楽しく仕事を進めるための工夫も紹介します。
これからスクラムを始めようとしている方や、スクラムの進め方に悩んでいる方にとって、少しでも役立つヒントになれば幸いです。
セッション後は、ぜひ皆さんのスクラムについても教えてください！

話さないこと
　・PHPに関すること m( )m

皆さんは、PHPStanを使って開発していますか？
PHPStanは静的解析ツールであり、PHPの開発をサポートしてくれます。
例えば、未定義の変数のチェック、PHPDocの間違いの確認、型の確認などの機能があります。
これは、動的型付け言語であるPHPで開発していく中で、必ず役に立つ機能です。

さて、私が開発しているプロダクトは、20年前から存在します。
当然、古いコードには型宣言がなく、付け足しの結果、気づかずに未到達コードが生まれてしまったことがあります。
さらには、クラスを利用しておらず、グローバル領域で書かれたコードも多くあります。
そんな古いプロダクトに、いかにしてPHPStanを導入したか、どこに苦労したのか、どう解決していったのかをお話ししたいと思います！

みなさんはDDoS攻撃代行サービスというものが存在することをご存知でしょうか？
DDoS業界は価格破壊が起きており、お手頃に攻撃できる時代となっています。
そんな簡単に攻撃可能な時代に突入しているのであれば、ある日突然あなたが管理しているサーバーが攻撃の標的になってもおかしくはありません。
私は最近までDDoS攻撃は「大量にリクエストが来るヤバイやつ」くらいの認識で正直ナニモワカラナイといった状態だったので、本セッションでは以下のような疑問について発表いたします。

• DDoSとはどんな攻撃で防ぐことは可能なのか？
• F5アタックや金ロー見ながら日本中で唱える滅びの言葉はDDoSなのか？
• Nginx、Lambda、LaravelのRate Limiting設定は意味があるのか？
• CDN、WAFの効果は？
• iptables、セキュリティグループなどのパケットフィルタの効果は？

メンタルは崩れると業務のパフォーマンスに大きな影響を及ぼします。
比較的メンタルが弱い私が継続して業務に携わるため実践してきたセルフケアやレジリエンスと言われる回復力の鍛え方をお話します。

聞いてほしい方

基本的にどなたでもではありますが。

• 若い方（早めに身に着けておいて損はない）
• メンタル弱い自覚のある方

お話すること

• メンタルが不調になる要因
• 実践してきたセルフケア
• レジリエンスの鍛え方
• 実践したことにより得られた業務での成果

得られること

• メンタルが不調になりがちなときの対処法を学べる
• 業務でのパフォーマンスを安定させるためのセルフケアのコツ
• 落ち込んだときからの回復力（レジリエンス）の向上方法
• 長期にわたりモチベーションを保つための具体的な戦略

計算量とは、アルゴリズムが問題を解くために必要とするリソース、特に時間やメモリの量を指します。プログラムはただ動けばいいだけではありません。膨大なデータを扱う現代において、計算量はアルゴリズムのパフォーマンスを左右する重要な要素です。皆さんのコードはどれだけ効率的ですか？計算量の基本から、時間計算量や空間計算量の理解を深めることで、あなたのプログラミングスキルを次のレベルに引き上げましょう！

本トークで話す内容

• 計算量とはなにか？
• 時間計算量、空間計算量
• 実装時に意識すること

正規表現はテキストの抽象表現です。ソフトウェアでは入力値のチェックやテキストの整形などに用いられるので、私たちプログラマにとって馴染みが深いものの一つです。

ところで、正規表現の「正規」という名前が「良い性質」という意味を持っていることをご存知でしょうか？ 実際、統計の分野では良い性質を持ち、理論の根幹となる分布に正規分布という名前が付けられています。同様に、シンプルで汎用性の高い正規表現もまた、正規という名前に相応しいといえるでしょう。

しかし、開発者に正規表現の話題を振ると 「複雑で可読性・編集容易性が低くく、辛い」 という話題になりがちです。本セッションでは、正規表現が何故複雑になり、読めなくなってしまうのかという疑問に答え、その解決方法を示します。

なお、本セッションはPHPerKaigi 2024で発表し、改良したものです．

本番運用においても、ローカルで開発を行う場合においても、Dockerなどのコンテナ技術およびAWS ECSなどの周辺サービスを利用するのはすでに一般的かと思います。
ただ、確かに便利な技術ではあるのですが、運用を続けていくうちに以下のような課題に出くわすことがあります。

・CIの実行に時間がかかる
・本番・CI・ローカル環境ごとにライブラリ・パッケージをインストールする記述が分散しておりメンテが面倒
・aptなどでバージョン固定してインストールしているパッケージが、リリース用イメージのビルドタイミングでインストール失敗しリリース時に困る

このトークでは、実際にPHPのDockerイメージを毎日自動ビルド・プッシュすることで上記のような課題を解消した事例についてお話しします。

昨年のカンファレンスで「CodeReviewerが求められること」について発表させていただきました。
その中で、Revieweeが
・気づきや学びが欲しい
・自信を持ちたい
と感じていることが明らかになりました。
またその時の発表では触れませんでしたが、Revieweeは「楽しく働きたい」とも考えていることがわかりました。

しかし、コードレビューにおいて、Reviewerが気づきや学びにつながるようなコメントをしたとしても、伝え方次第でRevieweeから楽しさや自信を奪うことがあります。
本セッションでは、Revieweeが不快にならない伝え方を探究し、PHPerエンジニアへのインタビューも交えながら、心地よいコメントの条件を考察します。
コードレビューの場が楽しくなり、組織が活発になる一助となれば幸いです。

対象者：コードレビューを行う全エンジニア（役職問わず）

テストコードはプロダクトの持続可能な成長には不可欠で、私の所属する開発チームでは書くことが必須となっています。
しかし、書き方が人によって異なり、テストケースに過不足があったり、実装の仕方やレビューで悩んだりすることがありました。
そこで、テストコードの書き方をガイドラインを策定しました。現在では開発チーム全体で運用され、一定の効果を発揮しています。

本トークでは、このガイドラインの内容をもとに、テストコードを書くうえで最低限気をつけたいことについてお話します。
また、チーム全体で運用するための、策定のポイントについてもお話しする予定です。

テストコードの書き方を知りたい人はもちろん、テストコードレビューで悩んでいる人、チームで統一したコーディングルールを運用したい人にとって有益なものとなれば嬉しいです！