カンファレンスは一日にして成らず...。参加者からすれば数日間の"お祭り"も、開催に至るまでは会場選定、企画、予算策定、スポンサーとの交渉...のように、とにかくたくさんの準備が必要です。

このトークでは、日頃あまり表に出てこない｢カンファレンスがどのようにつくられるのか｣についての話題を、（PHPカンファレンス福岡なのに、何故か）YAPC::Kyoto 2023というPerlコミュニティにおけるカンファレンスを例にしてご紹介します。

特にYAPC::Kyoto 2023は、｢コロナ禍の前に企画され、コロナ禍でも一度も中止を決定することなく、延期を重ねて改めて開催された｣という特徴（？）のあるカンファレンスです。コロナ禍におけるカンファレンスの準備やその対策、いわゆる｢ウィズコロナ｣時代のカンファレンスについての工夫や考察などについてもお話します。

カンファレンスにスタッフとして関わることに興味を持っているが、一方で具体的なイメージが持てなくてあと一歩を踏み出せない、という方もいらっしゃると思います。そういった方々が、このトークを通して｢スタッフになると、こんなことをやるのか！｣というイメージを持ち、PHPカンファレンスなどを含む身近な/興味のあるカンファレンスのスタッフに名乗り出る一助になればいいな、と思っています。

対象者

• カンファレンスの運営に興味がある人
• カンファレンスの裏側、裏話を聞いてみたい人
• 他コミュニティのカンファレンスの様子が気になる人

海外展開を視野に入れたWebサービスを開発する場合、多言語対応は避けて通ることはできません。
要件次第ではありますが複数の言語を扱いたい場合、対象localeの判定やDBでの異なる言語データの持ち方等考慮すべき事項は多々あると思います。

このトークでは実際にLaravelを用いたWebサービス開発時の多言語対応について、
対応したことや後から振り返ってこうすればよかった等実際の開発で得た知見等をお話ししたいと思います。

話すこと

• HTTPリクエストヘッダのAccept-Languageを用いたlocale判定について
• DBで複数の言語データの持ち方、およびEloquentでの対象データの取得について
• laravel-langを用いた複数言語のファイル生成

Interfaceって...

• 具体的な実装が書けないし、何のためにあるのかよく分からない
• 先輩に言われてDIする時に使ってるけどなんでそうするのかはよく分かってない
• ライブラリとか作る人じゃないと使わないんじゃないの？
• Repositoryパターンの概念は分かったけど、実装を差し替えるなんてそうそうなくない？

そんな風に思っていたりしませんか？
私は思っていました！

このトークでは自称中級PHPerが上記のような状態を脱するきっかけとなった経験を元に、Interfaceの使い所や有用となりそうな場面などについてロガーライブラリのデファクトスタンダードであるMonologを題材に考察してみます。

このトークのゴール

「Interfaceよく分からない...」から「機会があれば使ってみようかな？」と思えるようになること

対象者

• Interface書いたことない方
• 書いたことあるけど、よく分からんという方
• 抽象とか部分型とか言われても分からん！もっと簡単に説明してくれ！って方

非対象者

• Intefaceバリバリ書いてるし理解してるぜって方
• 抽象とか型理論を肴にお酒が飲めるレベルの皆様方

皆さんAPIシナリオテストを書いていますか？

単体テストでコントローラーまでは書くけれど、APIをE2Eテストは実際のクライアントから叩いたり、curlで実行する方が大勢かと思います。
E2Eテストを書くのは色々ハードル高そうというイメージで諦めていませんか？
確かにフロントエンドを含めたE2Eテストは実装と維持が凄く大変です。
そこでAPIにフォーカスしたテストに絞ってみて書き始めてみることをオススメします。
個人的に非常にコストパフォーマンスが高いテストだと感じています。
このセッションではAPIシナリオテストを導入検討して導入してから感じたことを紹介したいと思います。

OpenAPI仕様書を書いて、そのまま使わないというのは勿体ないです。
swagger-phpでOpenAPIの仕様書を書いてそれをそのままアプリケーションに組み込んでしまおう！という内容です。
実際にswagger-phpで仕様書を書いて、それをどの様にValidationやルーティングとして利用するのか？について具体的なコードと実装例を上げて解説したいと思います。

私は、現在の会社で約1年間、料金チームに所属していました。このチームでは、締め日や売上日など、ビジネスにとって重要な日付の扱いが欠かせません。しかし、日付計算には様々な落とし穴があり、月末処理が適切に行われなければ企業に請求できないなど、クリティカルなバグを引き起こす可能性もあります。

日付計算は、時にうるう年や月末日の考慮が必要であり、さらにタイムゾーンの扱いも慎重に行わなければなりません。そのため、日付計算で様々なバグが発生することがあります。

このセッションでは、実際に発生した日付計算のバグについて取り上げ、実際のコードを交えながらその原因や修正方法について話します。

具体的には、以下のバグを取り上げます。

• 13月が生まれてしまったバグ
• プラン終了の1ヶ月前に送るべきメールが送信されていなかったバグ

これらのバグは、特定の日付でのみ発生するため、十分な手動テストが困難です。そのため、Unitテストによる日付計算のテストについても取り上げます。

また、PHPの日付計算でよく使われる、date(), DateTime(), DateTimeImmutable()の違いについても軽く取り上げます。

ユーザーのパスワード保存などでLaravelのHashingを使われたことがあると思いますが、もしHashingの安全性について尋ねられた時、皆さんはどう答えますか？もしかしたら公式ドキュメントで安全だと言われているから、みんな使っているから安全であると答えられるかもしれません。（以前までの自分はそうでした。）一般的な業務を行う際にこんなことを考える必要はありませんが、このLTではHashingでハッシュ化を行うことが果たして安全であると言えるのか、またなぜ安全であると言えるのかについて発表します。

発表すること

• ハッシュ化に対する脅威
  ハッシュ化に対してどのような脅威が待ち構えているのかを紹介

• ハッシュ化の脅威に対する対策方法
  前項で紹介した脅威に対する対策方法を脅威ごとに紹介

• LaravelのHashingの実装について
  前項で紹介した対策方法をHashingでどのように実装しているのかについて実際のコードを見ながら紹介

トークの対象

• 最初の質問に自分と同じような答えを出された方
• ハッシュ化の安全性について興味がある方
• LaravelのHashingの実装について興味のある方

トークの対象ではない方

• 最初の質問にきちんと根拠をもって答えられる方
• 「安全なWebアプリケーションの作り方」の代表的なセキュリティ機能の項目を一読されている方

ここ数年でQAエンジニアという名前を聞く機会が増えてきたかもしれません。
QAエンジニアは、会社によって持つ役割が大きく異なります。

また、テストエンジニアとQAエンジニアは何が違うのでしょうか？
テストエンジニアは、主にテストの実施に特化しています。
一方、QAエンジニアはプロジェクトやプロダクトなどの品質向上に貢献します。

私は10年間テスター（テストエンジニア）をして、その後、転職によりQAエンジニアとなりました。

私のテストエンジニア・QAエンジニアとしての経験から、このセッションでは、QAエンジニアの仕事内容について詳しく説明します。

■概要
2018年のPHPカンファレンス福岡でしたテストライブをします！

今回のテスト対象は別のものを用意するよていです！

2018年の様子はこちらからご覧ください
https://underscore42rina.hatenablog.com/entry/2018/06/17/004141

2018年のPHPカンファレンス福岡でテストライブを行います。今回のテスト対象は、別のものを用意する予定です。

■詳細:
私は、PHPカンファレンス福岡でテストライブを行う予定です。今回のテスト対象は、現在検討中ですが、最新の技術を使用したプロダクトを用意する予定です。

このテストライブでは、参加者は探索的テストを目にすることができ、その方法や手順について学ぶことができます。

探索的テストとは、テスト計画やテストケースを事前に作成せず、テスターが自由に操作しながら、問題点や改善点を発見するテストのスタイルのことです。このテストは、想定外の問題点や改善点を発見することができるため、プロダクトの品質向上に貢献します。

さらに、探索的テストは経験ベースのテストと言われ、その手法は本などで技術を得られづらいため、参加者はこの機会に知識やスキルを見ることができます。

みなさまのご参加をお待ちしております。

ファーストリリースが3ヶ月後という状況の新たなWebアプリケーション開発プロジェクトに参加する中で、目の前のスケジュールに間に合うような高速開発と、ファーストリリースの先も破綻せずに改善しつづけられるよう中長期的な持続可能性を意識した開発を両立させることが求められました。
このトークでは、全力で走りながらレールを敷くようなWebフロントエンド開発を支えるために工夫した点、導入したテクニック、うまくいったことやいかなかったことなどをお話しします。

※本トークの内容は PHP に関連しません。

Webフロントエンドのテストは書けていますか？テストを書いたほうがいいのはわかっているけど面倒でサボりがち、UIを変更するたびにテストも壊れてしまうし、いずれメンテナンスされなくなるくらいなら最初から書かないほうがいいんじゃないか...そんな気持ちになったことがある人も多いと思います。
このトークではDOMのテストに特化したオープンソースのJavaScriptテストユーティリティライブラリ Testing Library を紹介します。
Testing Libraryのおかげで、これまで億劫だったDOMのテストは、むしろ真っ先に書きたいテストに変わるかもしれません。テスト駆動開発との相性も抜群です。さらに、Testing Library を使ってテストを書いていくとWebアクセシビリティの改善にも役立ちます。
普段あまりDOMのテストを書いてない人もDOMのテストに苦手意識がある経験者もぜひ知ってほしい、Testing Libraryの世界を案内します。

※本トークの内容は PHP に関連しません。

皆さん。
皆さんは型を書いていますか？
私は書いています。

なのに、いつの間にか型情報は消えているんです。
mixedになっているんです。
不思議ですね？

最近のPHPはバージョンアップのたびに型付けに対するサポートがどんどん厚くなっています。
それに合わせて開発環境が型情報をもとに補完候補を適切に表示したり、
静的解析によるチェックが高精度になり、
開発体験・開発速度が良くなっているはずです。

なのに、大切な型情報は消えてしまいます。
悲しいですね？

そこで、
どんな時に型情報が消えるのか、
どうやって回避するのか、はたまた回避は無理なのか。

主にLaravel・PHPStanとVSCode環境を例に最近の型にまつわる開発支援環境について発表します。

SPA全盛の時代ですが、まだまだ古き良きMPA（Multi Page Application）のシステムを触る機会は多いですし、
凝ったUIを必要としない社内システムなどでは、新規開発でもMPA構成を採用することは普通にあります。

MPAだとビューのテストは基本的にPHPフレームワークが提供してくれる結合テスト基盤を使って行うことになると思いますが、
結合テストで検証できるのはあくまでHTTPレスポンスの内容までで、その後ブラウザ上でJavaScriptを使ってある程度複雑な処理が行われる場合に、その部分をテストすることができません。

MPAであっても、一部の画面にだけちょっとしたDOM操作や非同期処理が必要になるケースは多く（例えばいいねボタンとか）、
このようなJSの処理は上記の理由から自動テストがサボられがちです。

このトークでは、こういったMPA上のJavaScriptの処理を楽にテストする方法を、Laravelにおける実装例をもとに解説します。
（例としてLaravelを取り上げますが、他のフレームワークにも容易に応用可能な内容です）
既存のMPAに後付けで簡単に導入することが可能なので、すぐにでも実務に活かせる内容になると思います。乞うご期待。

突然ですが、皆さんの現場のPHPはバージョンはいくつでしょうか？

既にPHP7系もEOLとなって久しく、先日行われたPHPerKaigiで行われたアンケートでは8系がマジョリティーとなっていました。
CIで静的解析やユニットテストが回り、デプロイは自動化され、RectorやDependabotでライブラリは最新、エディタはPhpStorm一択！
といったモダンな現場がある一方で、無視できないのは少なくない「5系」に入った票です。

現実には様々なしがらみからレガシィ化してしまったコードベースは存在します。
無限に広がるarrayの可能性、なくならないバグやデグレ、属人化したデプロイ作業...
そんなPHPの闇の中でもDeveloper eXperienceを諦めたくない！

このトークではレガシィな環境で戦ってきた中で培った自分なりの工夫、実際の現場で使っているツールや行っている取り組みをお話します。
過去の自分と同じような境遇の方の参考になれば幸いです。

お話すること

• PHP5系でも使える品質向上のための開発支援ツールの紹介
• 既存コードベースに引きずられないように開発している箇所とそのアーキテクチャ
• レガシィと向き合うための自分なりの工夫とマインドセット

お話しないこと

• PHP4系で動いているシステムへの言及
• PHP8系で動いているシステムへの言及
• リプレースの話

アプリケーションを実装する時にEventDispatcherを使ったことのある人は多いと思います。
そんな便利に使っているEventDispatcherの仕組みはご存知でしょうか？
まずSymfonyのEventDispatcherの仕組みを参加者の皆さんと一緒にソースコードリーディングで解明するとともに、SymfonyのEventDispatcherがどのようにPSR-14を実装しているかも見ていきます。

障害、嫌ですよねぇ。
嫌だから、起こしません・・・！素晴らしいのですが、「リリース怖い」「改修怖い」では、前に進めなくなります。

1番良いのは「適切に怖がる」「転んだら盛大に学び尽くす」という態度です。
スクラムを筆頭に、「ふりかえり」の力は「組織を強くする」ためのアジャイルな組織に必須な力と考えられています。もっと広げれば、体験学習の世界でも重要なことです。

そうした、本来の「これから先に活かすふりかえり」の姿を取り返しませんか？

お伝えしたいこと

• ただの「事実確認」で終わらせない、障害のふりかえりをやろう
• 「同じことはもう起きない」ではなく、「組織としての課題」につなげよう

私のキャリアの直近3~4年は、東京のエンジニア採用に加え、地方のエンジニア採用をしてきました。
採用活動を通じて、地方のエンジニアが現地に根を張り、活躍することに非常に大切な意味があると思っています。
特にリモート普及後、「フルリモート」「現地の企業」「地方拠点」など、企業の選択肢も格段に増えてきました。

■話をしたいと思っていること
・関東と地方のキャリアの違い
・リモート普及後の地方のエンジニアの変化
　・どのような活躍の仕方があるか
　・逆にどのような問題がおきているか
　・技術コミュニティの在り方の変化
・リモート時代の地方のエンジニアの存在意義
　・地方でエンジニアが活躍することにどのような存在意義や価値があるのか

日本社会は、労働力減少や少子高齢化など直面している問題が山積みで、関東一極型の働き方は難しくなっています。
福岡であったり、それ以外の地域でのエンジ二アが活躍・活動する場所が増えていったり、居住地を含めた柔軟な働き方は今後ますます必要になっていくため、地方でキャリアの挑戦をしたいと考えている人の後押しになる発表を目指していきたいと思います。

私自身の経験を通じて、地方のエンジニアの活躍・地域ITコミュティの重要性についてお話したいと思います。

PHPのフレームワークやライブラリを作成する人に向けて、「みんながこういうノリで実装してくれたら嬉しいな」を形にした「PSR」と呼ばれる取り決めがあります。

https://www.php-fig.org/psr/psr-14/

「PSR-4(オートローディングに関する規約)」「PSR-7(HTTPメッセージの取り扱い表現方法に関する規約)」「PSR-12/PER Coding Style(コードのスタイルに関する規約)」などは、耳にしたことがある人も多いのではないでしょうか。

そんなPSRの中に、「PSR-14: Event Dispatcher」があります。イベントやその発行・購読についての規約です。
この14番は、どちらかというと知られていない部類のような気もしています！

このセッションで、改めてスポットライトを当ててみましょう。
「PSR-14とはどういうもので、リアルワールドにおいてはどのような実装があるのか」について知ってみませんか？

話すこと

• PSR-14は何を狙ったものなのか
  • この取り決めが議論され形になった背景には、どのようなプログラミング上の課題があったのか。何を解決するものなのか
  • = 「Observerパターンとどう付き合うか」みたいな話
• PSR-14を用いた実装例(ライブラリ)を覗いてみる

みんな大好きWordPress！世界のWebサイトの4割以上と圧倒的シェアを誇る皆様御存知のPHP製超有名CMS！
そんなCMSで作られたWebサイトのインフラをリプレースする機会に恵まれたので、イキって「時代はコンテナ！冪等性こそ至高！」とEC2からFargateに載せ替えようとしたら大失敗？！

今回のトークでは上記のEC2からFargateへのリプレースプロジェクトにおいて得られた知見を共有させて頂きます。

お話すること

• 実際に行った移行手順
• ハマったポイントとその解決策
• リプレースしてみた感想

PHPのビルトインウェブサーバーを使ったことはありますか？
Laravelユーザーの方ならお馴染みの「php artisan serve」というコマンドで使用しているかもしれません。

実際HerokuやAWS ECSのLaravelデプロイ時に「php artisan serve」を使用する例もちらほら見受けられますし、公式サイトでもこのようなサンプルが紹介されています。

しかしながら、php公式がビルトインウェブサーバーを本番環境で使用することを禁止しています。
https://www.php.net/manual/ja/features.commandline.webserver.php

実際にビルトインウェブサーバーを使用した経験に基づいて、その弊害についてお話ししながら、ビルトインウェブサーバーの注意点をまとめてみました。