プロポーザル

メンドウ？タイクツ？書き方がわからない？？

決めたことを文書にまとめない理由はたくさんあるかと思います。
一時的には文書を書かない方が、仕事のスピードは早いかもしれませんが、長期的に見たときにはどうでしょうか？

この発表では一時の時間短縮のためにドキュメント化を怠った結果、どのような末路が待っているかを具体例を交えて紹介します。

皆さんはパスキーと聞いて何を思い浮かべますか？
なんか新しいすごいやつ、パスワードがいらないやつ、顔認証するやつ、デバイス間で同期してくれる、公開鍵暗号、チャレンジ………

このトークでは、近年GoogleやGitHubなど主要なWebサービスでも採用されてきている新しいユーザー認証方法「パスキー」に入門します。

• パスキーとは何か
• パスキーで何ができるのか
• なぜパスキーが推されているのか
• 従来のユーザー認証と何が違うのか

などのような基本的な部分から、

• パスキーでログインをするために必要な実装
• パスキーを実装する上での注意点
• パスキーを運用する上での注意点

など発展的な部分まで、一通りパスキーでの認証ができるようになるレベルを網羅します。

このトークがお勧めな人

• パスキーに興味がある人
• ID / パスワードによる認証とさよならしたい人
• よりセキュアなユーザー認証を実現したい人

このトークで得られること

• パスキーの仕組みの理解
• パスキーの実装方法
• パスキーの運用のあれこれ

WebAPIを介して他のサービスと連携して、新しいサービスを作ることってありますよね。Googleアカウントでログインする機能の実装はまさにその一例です。
しかし、OpenAPI Specification等のフォーマットで各APIの仕様が公開されていたとしても、それらをどう組み合わせれば目的のユースケースを実現できるかは自明ではありません。ドキュメントを読み込み試行錯誤する中で、API間の依存関係やシーケンスを解き明かした経験がある方も多いのではないでしょうか。
この問題を解決するために、OpenAPI Initiativeでは「Arazzo Specification」という新しいAPIワークフロー定義が検討されています。2024年5月には、この仕様のv1.0.0が公開されました。本ポスターでは、そんな「Arazzo Specification」の詳細について解説します。

【予定している内容】

• Arazzo Specificationの概要
• 想定されるユースケース
• Arazzo Specificationの詳細内容
• Arazzoを用いたAPIワークフローの記述例

PHPStanはPHP開発者にとって頼れる相棒ですが、そのエラーは時に悩ましいもの。このセッションでは、私が独断と偏見で選んだ実例をもとに、PHPStanのエラーがどのような場面で発生するのか、具体的な修正方法をお伝えします。「PHPStan初心者」から「ちょっと苦手」な人まで、役立つ情報をギュッと詰め込みました。今日からPHPStanをあなたの最高の同僚にしましょう！

循環参照、聞いたことはあるけれど実際に遭遇したことがある方はどれくらいいるでしょうか？私もまさか遭遇するとは思っていませんでしたが、ついにその“おとぎ話”のような存在に出会ってしまいました。そして、それを解決するために地獄のような改修作業が始まりました…。
このセッションでは、循環参照が引き起こす問題やその発見方法、解決するために取った具体的なアプローチを共有します。さらに、再び循環参照に遭遇しないための防止策についてもお話しします。二度と同じ目に遭わないために、一緒に循環参照の対処法を学びましょう！

副業でPHP（Laravel）を教える中で、技術力だけでなく、自分のエンジニアとしての姿勢やスキルにも大きな変化がありました。

「このエンジニアに教わりたい」と思ってもらえる存在を目指し、GitHubの自己紹介やブログに力を入れたり、プライベートでコードを書く時間が増えたりと、活動の幅が広がりました。
また、人に教えるには深い理解が必要なため、「分からないことを徹底的に調べる」「ドキュメントやコードを読む」「一次情報にあたる」などをこれまで以上に重視するようになりました。
教える中では、短時間での原因切り分けやペアプロのナビゲーションを行う場面もあり、そこで得た経験と気づきは、自分の成長に大きく寄与していると思います。実際業務でデバッグするときにも、まず現状を把握する、どこまでできているかを探る、1次情報に当たるなどがより一層実践でき、課題を解決するまでの時間を短くできているのではと思います。

このセッションでは、副業での教える経験を通じて得た学びがどのように業務に活かされているかを具体的にお話しし、参加者の皆さんが自分自身の成長に役立てられるヒントを提供します。

覚えていますか？プログラムを読めるようになってきたある時、突然出会った彼らのことを。
先輩エンジニアの書いた三項演算子やnull合体演算子、高階関数にクロージャ。
理解不能。何を表し何の為に何をしているのか。
同時に思ったはず、「なんかカッコいい‥」と。

そして、いつかは自分もこんなプログラムを書いてみたいと言う憧れに近い感情を感じたはず。
エンジニアなら誰しもが通った、なんか小難しいけどカッコいいシンタックスへの憧れを
「PHPシンタックスコレクション〜ペチコレ〜」厨二病が好きそうな小難しいシンタックス編
と称して紹介していきます。
独断と偏見で選んだ「なんかカッコいいシンタックス」達が華やかにランウェイを彩ります。

皆さんはゲーム大好きですか？
わたしもネットがあまり普及されてない頃、攻略本を片手にずっとゲームをやってました。

実はPHPにも攻略本があります。ナ、ナンダッテー！？
全て印刷したら六法全書になるであろうボリューム。その名はPHPマニュアル！
本当にコントリビューターの方々には頭が上がりません。いつもありがとうございます。

もちろん、、、PHPerと名乗るからにはPHPマニュアルマラソンをやったことありますよね？
え？やってない？
それなら、一緒に習慣化するしかない！

この発表を経て、PHPの素晴らしさを再認識しましょう！

Laravelでの開発経験者ならおなじみのBladeテンプレート。
あなたは本当に使いこなせていますか？

このセッションは、まず日常的に使う基本的なディレクティブ @if や @foreach といったディレクティブをおさらいし、意外と知られていない隠れたディレクティブのご紹介や、 @csrf などのディレクティブの裏側で行われている処理内容、さらには独自のニーズに応えるカスタムディレクティブの作成方法まで幅広くご紹介します。

「実はこんな使い方ができたのか！」と思わず驚くトピックを盛り込みつつ、テンプレートコードをシンプルかつ可読性を高めるコツをお伝えします。

このセッションを通じてBladeディレクティブを使いこなし、テンプレートを効率的に管理するスキルを身につけ、日々のLaravel開発を一層効率化しましょう！

本セッションでは、CSVファイルのダウンロード速度が遅すぎて切り戻しになった知見をもとに、Laravelアプリケーションのパフォーマンス改善のデモンストレーションを行います。
「頑張って作ったのに遅すぎて使ってもらえない」では悲しすぎるので、ご参考にしていただけますと幸いです。

以下のテーマに沿ってデモをしていく予定です。
・ しくじり談
・ DBからのデータ取得時に気をつけること
・ 取得したデータを加工するときに気をつけること
・ 加工したデータを出力するときに気をつけること

キーワード
・ Eloquentとクエリビルダ
・ N+1問題
・ メモリ
・ ジェネレータ

想定視聴者
パフォーマンスを意識したコードを書ける・レビューができるようになりたい方

テストコード実装によるアプリケーションの実装設計や中長期の運用メンテナンス性に変化が出た話をします。
当初、ファットコントローラーや行数の多いメソッド、ライブラリへの依存性高い設計などが原因で、メンテナンスしにくいPHPアプリケーションを運用していたチームがテストコードの実装から技術負債を徐々に解消していけるようになりました。
理由は「テストコードを入れやすい実装と設計」をするようになったこと。
挙げた課題へどのような実装・設計の変化が起きたかリファクタリングの具体例や、テストコード導入による設計の変化を紹介します。
またテストコードによるリプレイスを叶えたアプリケーションを立ち上げた事でPHPやフレームワークバージョンアップへの適用性、テストコード実装スピード向上の変化についても語ります。

私が携わっている長年稼働しているサービスには、巨大連想配列$resultsが存在します。これは、元々は小さな配列だったものが、改修を重ねる中で次第に肥大化していきました。
巨大連想配列は可読性やメンテナンス性を低下させるため、私は以下のアプローチで改善を進めています。

1. Xdebugの活用
   配列の構造を可視化し、一目で理解できるようにする。
2. 新規部分の改善
   新しく作る部分は値オブジェクトを導入して書き換える。
3. 分離と整理
   大きなキーを別の変数に切り出したり、I/O形式が異なる場合はメソッドを分ける。

お話しする内容

• 配列の構造を一目で把握するためのXdebug活用術
• 巨大連想配列を生み出さないコツ
• 巨大連想配列を分解して整理する方法

巨大配列で頭を悩ませている方の改善のヒントになれば嬉しいです。

新卒から6年間所属した部署から大異動で全く別のチームに配属された先には鳴り響くアラートの日々が待っていました。
みなさんも、プロダクトの監視の状況で以下のようなケースに出会ったことはないでしょうか？

• 何をしたらいいのか、何が問題なのかわからないアラート
• 既存チームメンバーから無視され続けているアラート
• アラートが来ても反応するメンバーが限られている、対応できるメンバーが限定的
• アラートが頻繁に来ていてチームがアラート対応に疲弊している

上記のアラートについて見ていくと異動先のチームには、以下のような問題を抱えていました。

• アラートの詳細を詳しく見なければ問題がないことを判断できない
• アラートの判断は属人化している
• ほとんどのケースにおいて問題ないアラートが飛び続けている
• 最初に監視を設定した人はすでに社内におらず、意図がわからない
• メンバー間のアラートに対する認識齟齬

これらに対して、一つ一つ向き合って出してきた答えについてお話します。
聞いて欲しい方

• 新たに配属されたが、アラート対応ができなくて悔しいと思ってる人
• アラート対応に課題感を持っている人
• 一緒に見直していく仲間を増やしていきたい人

LaravelのEloquetにはupsert関数があって便利だなぁ♪
あれ？updateOrCreate？
あれあれ？updateOrInsert？

一体どれを使えばいいんだーーー！！！

本セッションではこんな悩みを解決するために、それぞれの関数の説明とどう使い分けるかについてお話します。

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

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

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

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

「いつまでも できると思うな 夜メンテ」

深夜メンテナンス作業を経験したことはありますか？
作業には様々なメリット・デメリットがありますが、何よりも体力的に辛いですよね。

あるカラムの暗号化作業を進める中で、深夜メンテナンスが必要だという結論になりました。しかし、シニアエンジニアに相談したところ、「今回は深夜メンテができるが、できないサービスも世の中にはある。深夜メンテ不要でリリースする方法を一度考えてみては？」というアドバイスを受け、リリース方法をチームで再考しました。
その結果、リリースを3段階に分けた小さなリリースを採用することで、深夜メンテを回避することができました。さらに、小さくリリースしたことで、各リリース段階で不具合が発生した際も原因を特定しやすく、迅速に戻せる状態の確保ができました。

お話しする内容

• 小さくリリースすることのメリット・デメリット
• 「小さくリリースできるかも？」と考えるためのヒント

開発者にとっても、ユーザーにとっても、メンテナンス時間は短いほど嬉しいものです。
このLTでは、深夜メンテに頼らずにリリースを進めるための工夫や実例を共有し、参加者にとって実践的なアイデアとなるような内容をお届けします！

技術的負債はどこの開発現場でも多かれ少なかれ存在します。技術的負債ゼロな現場はありません。
技術的負債を継続的・定期的に返済できていれば問題はありません。しかし長年放置され「負債度」が高まった技術的負債を返済するのは非常に厄介で骨が折れる作業です。

私たちは約10年放置されてきたPHPアプリケーション（PHP5）をPHP8にアップグレードしました。
負債解消チーム立ち上げから苦節３年、メンバーの離脱もありつつもレガシーなPHPアプリケーションの移植およびアップグレードを完遂することができました。
しかしそれを終えて今、こう思うのです。なぜここまで大変になるほど放置してしまったのか―。

本発表では技術的負債はなぜ生まれてしまうのか、その組織的・構造的な問題に触れつつ、それにどう立ち向かい、そしてその後どうすべきなのか、私自身が経験したPHPの移植事例・アップグレード事例を踏まえて発表します。

話すこと

• 技術的負債の生まれ方
• 「技術的負債の倒し方」のはじめ方
• 技術的負債の倒し方
• 技術的負債の倒したあと

想定聴講者

• 技術的負債の解消をしたいと思っている方
• 現在進行系で技術的負債と闘っている開発者

※本発表は PHPerKaigi 2024 で発表した「10年モノのレガシーPHPアプリケーションを移植しきるまでの泥臭くも長い軌跡」の完結編となります。

最近の学生エンジニア界隈ではTypeScript, Go言語, Rustを学ぶ人がかなり多くなっており、PHPを現在進行系で学んでいる人は自分の周りではあまり見ません。
(書いたことある！という人は見ます)

私も、もちろんそれらの言語を書き、開発体験が良いと感じることが多くありました。
そんな中、自称関西学生PHPer最後の砦という責任感を持って今でもPHPを書いています。
そんな自分がPHPを書いていて良いなと思った点を言語機能やコミュニティの観点、ソフトウェア開発を学ぶといった様々な観点から色々話します。

学生目線というところが肝です。似たような話にはしません！
自己満LTになりそうですが、面白いトークを目指します。

Rectorというリファクタリングツールがあります。
このRectorではカスタムルールを作成することで、任意の条件でリファクタリングを行うことが可能になります。

このカスタムルール上でPHPStanの機能を利用したり、php-parserを用いることでRectorの能力を最大限に活用してリファクタリングすることができます。
そしてPHPStanのbaselineをゴシゴシ削減することにも繋がります。

エディタ上やCLI、CI等でしか普段使わないPHPStanをコード上で利用するという不思議な体験をお届けします。

「PHPStanをCIとエディタでしか使わないなんて勿体ない！」と発言する人間を量産できるように頑張ってトークします。

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

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

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

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