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

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

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

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

対象者

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

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

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

話すこと

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

サービス運営を行う上で切っても切り離せない管理画面ツール。
必要ではあるもののサービス自体と比較すると相対的に工数をかけにくく実際そこまで凝ったものは必要ない、というのがよくある要求で、
そういった背景から*-admin系のライブラリが数多く生まれてきている一方、言語やフレームワークに依存する部分も多く、
既存のプロジェクトで使えていたものが新規プロジェクトでうまく使えず歯痒い思いをするといったこともあるはず。
そんな中、Slackアプリによる管理画面ツール開発は一つの答えになるはず...

Block kitを利用した効率的なviewの開発、Slack APIに機能を移譲することで得られるメリットなど、実際に運用する中で得られた知見を公開します。

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

発表すること

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

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

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

トークの対象

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

トークの対象ではない方

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

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

ドメイン駆動開発でレイヤードアーキテクチャを採用するパターンが良くありますが、初学者にとっては理解し難いものです。見様見真似でなんとなく層に分けてクラスを設計してみたものの。。アレ？という感じになってたりします。

実際に遭遇したよく陥りがちな避けるべき実装パターンを例に上げて

• 何が駄目なのか？
• どういった設計にしていけばよかったのか？

をまとめてみたいと思います。

想定対象

• レイヤードアーキテクチャで悩んでいる方
• トランザクションスクリプトから脱却したい方
• ドメイン貧血症になってしまっている方

PHPで業務をこなす私の傍らには、いつもPHPUnit君がいました。
ユニットテストの多大な恩恵に与っている今、もはやPHPUnitによる自動テスト無しの生活は考えられません。

このトークでは、新人PHPerの私がPHPUnitについて学んだことを皆さんにお伝えしようと思います。
プロジェクトで「vendor/bin/phpunit」を実行してテストを動かしたことはあるけど、phpunit.xmlとかテストスイートとかよく分からんといった初学者向けの内容になります。

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

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

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

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

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

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

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

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

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

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

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

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

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

PHPを使い始めてからというもの、私にはずっと気になっている存在がいました。
それは、ディレクトリの隅っこでこちらの様子をうかがっているcomposer.json君です。

このトークでは、新人PHPerの私がcomposerについて学んだことを皆さんにお伝えしようと思います。
プロジェクトで「composer install」したことはあるけど、実際何をしてるのかはよく分かっていないといった初学者向けの内容になります。

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

発表すること

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

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

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

トークの対象

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

トークの対象ではない方

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

Garbage collection (GC) とは、確保したメモリ領域を適切なタイミングで解放する仕組みのことです。
PHP ではメモリの確保と解放が処理系によって自動的におこなわれるため、あまり意識することはないかもしれません。
しかしながら、メモリが比較的潤沢になった今でも、メモリ溢れによるサーバ障害は決して珍しくありません。
PHP における GC を理解し、メモリを意識したプログラミングをすることで、本番サーバを夜中に落とさないようにしましょう。

主な対象

• 普段メモリを意識してプログラミングしていないかた
• 言語処理系の内部実装に興味があるかた
• メモリ溢れで本番環境をダウンさせたことのあるかた

話すこと

• PHP における GC のアルゴリズム
• あなたが確保したメモリはいつ解放されるのか
• メモリ溢れを意識したプログラミング

話さないこと

• GC のパラメータをいじってカリカリにチューニングする

目標

• PHP でメモリがいつ解放されるのかを知る
• メモリを食い尽くす実装を避ける手段を知る

Git は、現代のソフトウェア開発において欠かせないツールの1つです。
しかし、一度基本操作から外れると、思いもよらないような複雑な操作を強いられることもあります。
Git の内部構造や仕組みを理解することで、こうしたトラブルを事前に避けたり、トラブルシュートしたりすることが可能になります。
この発表では、Git の核となる content-addressable filesystem と commit graph に焦点を当て、それらの仕組みや役割を解説します。

主な対象

• Git 内部で commit がどのように表現されているかを知らないかた
• マージとリベースの差を説明できないかた
• よくあるブランチフロー (e.g., Git Flow、GitHub Flow) から外れたときに操作を迷うかた

話すこと

• Content-addressable filesystem とは
• Commit の内部表現
• Branch の内部表現
• マージとリベースはどのような操作か
• 応用例

話さないこと

• GitHub、GitLab 等のホスティングサービスについて
• PHP 関連

目標

• Git の内部表現を理解する
• 複雑な操作を迷うことなくできるようになる
• 操作が複雑にならないようなブランチ運用を選べるようになる

みなさんはクリーンアーキテクチャを理解している/知っていますでしょうか？
ドメインモデル, ユースケース, アダプタ, インフラストラクチャ...etc, はい、私は全くわかりませんでした。

ただちょっと視点を変えて、それぞれのレイヤーを擬人化してみると、最近なんとなくわかった様な気になることができました。
(例えば、ユースケースをプロダクトオーナー、インフラストラクチャをステークホルダーとした時に、実装について直接会話させると何が起きるのか → なんかアカンそう → じゃあどうするか など)

そこで本トークでは、みなさんにも自分と同じようにクリーンアーキテクチャを少しでも理解してもらえることを目標としてお話しできればと思います。

■ 話すこと

• レイヤーを擬人化してみるとどうなるか
• レイヤーを意識しないとどうなるか
• 依存関係(DI, DIP)について
• クリーンアーキテクチャを理解すると何がうれしいのか

■ 話さないこと

• クリーンアーキテクチャの深い話

■ ターゲット

• クリーンアーキテクチャ？なにそれ、おいしいの？という人
• クリーンアーキテクチャを理解するにあたって、とっかかりが欲しい人
• クリーンアーキテクチャでやっているが、なぜやっているのか分からない、ただの雛形にそって作業している人

■ 補足

※ 決してクリーンアーキテクチャ原理主義者ではありません、あくまでも一つの考え方、知識として持っておくと幅が広がると思い話します
※ クリーンアーキテクチャと書いていますが、なるべくXXXアーキテクチャ全般に通じる話にしようと思っています

私はこれまでビジネスロジックとドメインロジックをほぼ同じものとして捉え、ドメインモデルにビジネスロジックを実装することで業務知識を表現するような実装を意識していましたが、最近の開発の中でドメインロジックとビジネスロジックはレイヤーの異なる概念なのではないかと考えるようになりました。

この2つのロジックを区別し、ドメインモデルからビジネスロジックを追い出すことで仕様変更に強いドメインモデルを構築することが出来るのではないか、という考えを今回のトークでお話ししたいと考えています。

このトークでは、以下のトピックに関する僕の考えを共有することを目標とします

• ドメインとはそもそも何なのか
• ドメインロジックとはどのようなものなのか
• 何をドメインロジックとして扱うべきで、何を扱わないべきなのか

私はこれまでビジネスロジックとドメインロジックをほぼ同じものとして捉え、ドメインモデルにビジネスロジックを実装することで業務知識を表現するような実装を意識していましたが、最近の開発の中でドメインロジックとビジネスロジックはレイヤーの異なる概念なのではないかと考えるようになりました。

この2つのロジックを区別し、ドメインモデルからビジネスロジックを追い出すことで仕様変更に強いドメインモデルを構築することが出来るのではないか、という考えを今回のトークでお話ししたいと考えています。

このトークでは、以下のトピックに関する僕の考えを共有することを目標とします

• ドメインとはそもそも何なのか
• ドメインロジックとはどのようなものなのか
• 何をドメインロジックとして扱うべきで、何を扱わないべきなのか

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

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

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

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

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

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

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

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

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

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

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

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

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

仕事と家事と育児との分業をこなして15年目を迎え、感じたことをお伝えします。
分業のバランスを取るため、phperフリーランスという働き方を選択しました。これまで満足に分業の両立ができていたことはありません。今でも葛藤の毎日です。安心してください、分業のバランスが取れてなくて当たり前です。
今では子供達はある程度手が離れてきたので、仕事の比率を上げるべく、また決意を改めるため、昨年法人化しました。逃げれない状況を作って馬車馬のように働いています。
分業のモデルケースとしてお聞きいただけると嬉しいです。

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

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