コードを書いていて自分で命名をする機会って多いですよね。
良い命名をすることで、コードの可読性が向上し、保守性も高まります。一方、悪い命名はコードの理解を困難にし、ソフトウェア品質を低下させる原因となります。
実体験、書籍、ウェブ記事や他のカンファレンスで学んだことを総合的にみて、どんな命名をすべきかを具体的なコードを示しながら発表します。

本発表の目的は、良い命名の条件と具体的な命名方法を理解し、実践につなげることです。

内容

• 命名の重要性
• 悪い命名の例とその影響
• 良い命名の条件と具体例
• 実践で使える命名方法
  • 変数の命名
  • メソッドの命名
  • 命名の場所

PHPで文字コードを扱うには、mbstringを使うのが主流であると思います。
そんなmbstringですが、PHP 8.1からMajor Overhaul of mbstringという大規模改修が入ったため、その内容を把握するための記事を書きました。
運良く、執筆者であるAlexさんに読まれたことで、ぼくはPHP 8.3となるバージョンの面倒を見るという立ち回りをしています。

文字コードはそれぞれ生まれも管理の方法も違うため、色々と混乱することもあるでしょう。
特にShift_JISのたくさんの亜種などはたくさんありすぎて何がなんだかわかりませんよね。
そういったものを紹介していければいいなと思っています。

また、PHP 8.3では、どうやらUTF-8を使うのがよさそうというのがわかってきました。
一方で、Shift_JISやISO-2022-JPなどを使うというのも選択肢としてあるようです。
それにはUTF-8特有の弱点も存在していて、Shift_JISが好まれる理由でもあるようです。

文字コード、それぞれ先人の歴史の積み重ねによるものが多いです。
一度、棚卸しを兼ねて文字コードを見てみませんか。

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

このトークでは、日頃あまり表に出てこない｢カンファレンスがどのようにつくられるのか｣についての話題を、（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バリバリ書いてるし理解してるぜって方
• 抽象とか型理論を肴にお酒が飲めるレベルの皆様方

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

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

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

発表すること

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

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

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

トークの対象

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

トークの対象ではない方

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

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

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

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

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

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