盛り上げます！

小田原っこ: 小田原に住んでます。ラブ。

アブストラクトマシマシ・シンタックス少し・ツリーマシマシ。このような呪文を見かけたことはありませんか。そう，二郎系ラーメンです。この呪文を「コール」と呼び，ラーメンの着丼前のトッピングとしてヒアリングされます。一見，二郎系ラーメンのコールは複雑そうに見えますが，ある一定の法則性があります。そしてスタッフは法則性に基づいて解釈し，ラーメンにトッピングをします。似たようなのを見たことがありますね。そう，お察しの通りプログラミング言語の構文解析器です。例えばramen(1, 2)という構文はramenという関数をコールし，1と2という引数を与えます。つまりトッピングです。このようにramenという関数の引数は 2つで…といった意味を与えるのが構文解析器です。
本トークでは，PHPで構文解析器で専らよく使われるAST解析を実装するにはどうしたらよいか，二郎系ラーメンのコールを題材として解説します。

令和になっても相変わらず紙の書類の需要は大きく、Webアプリ開発においても帳票印刷機能は多くの案件で要求されます。
しかし、これがとにかく面倒くさい。

• 複雑なレイアウトの帳票をHTML/CSSでデザインするのが地獄
• かといって超微細Excel方眼紙でデザインするのはもっと地獄
• しかもPDFに変換するときに微妙に見た目が崩れてどうにもできない

帳票印刷機能を実装したことのある方には強く共感していただけると思います。

そんな面倒で難しい帳票印刷ですが、実は私は既に数年前に最強無敵のソリューションを編み出し済みです。

• ピクセル単位で細かく帳票をデザインできる（しかも簡単に）
• 帳票デザインの保守性が高い（修正が容易）
• 印刷時に見た目が一切崩れない

という条件を満たせる唯一（当社調べ）の方法です。

このトークでは、この至高のソリューションを具体的に解説します！

PSR-15はPHP-FIGが勧告するHTTPハンドラとミドルウェアの標準仕様です。仕様の基盤となるPSR-7とともに非常に簡潔なインターフェイスの素晴らしい仕様です。

このトークではPSR-15がどのようにミドルウェアの仕組みを提供するのか、シンプルすぎるPSR-15とPSR-7の実用アプリケーションでの利用しにくさを改善できるかの試み、そして拙作のPSR-15ディスパッチライブラリHakoneの設計思想についてコンパクトにお話しいたします。

GitHubが提供するCI/CDサービス 「GitHub Actions」。
ドキュメントが充実していて簡単に使い始められる反面、ジョブが終わらなくてキャパを食い尽くしてしまったり、GitHub Actionsが障害中でCI/CDが出来ない、などのトラブルも耳にします。

本トークでは数多のプロジェクトでGitHub Actionsと戯れときに事故に向き合ってきた体験をもとに、GitHub Actionsを使うときにやっておくと良い設定をご紹介します。

お話しすること

• GitHub Actionsのおさらい
• タイムアウトの設定は必ず
• バージョンは明確に
• CIで出来ることはローカルでも出来る状態が理想
• 3rd-party Actionsは定期的にバージョンアップしましょう
• Environment VariablesとSecretsは正しく使い分けよう

PHPは現在のところ、毎年何らかの新バージョンをリリースしています。
大体毎年11月末〜12月にリリースされることが多いです。

さて、PHPカンファレンス小田原の時点では4月です。
このときにはPHP Internalsはどうなっているのか、新機能はどうやって決まっているのか、
alphaとかbetaとかって何？などをお話します。

ぜひ最新のPHPのキャッチアップに繋げていきましょう。

みなさんはローカル環境で開発を行って本番環境へデプロイするまでどのように実施していますか？
実はここでお話する取り組みは今も絶賛進行中だったりするものもあります。

出来らあっ！！という気持ちからコンテナ化を進めることになり、ローカル環境整備やデプロイフローの改善といったものへ繋がっていきました。

このトークでは、

• レガシーな開発環境やデプロイフローを改善していった軌跡
• ローカル環境の整備
• コンテナ化
• デプロイフローの改善
• 全体を巻き込んで行動する時に心がけているマインドと振る舞い

といったことを話していこうと思います。

PHP8.3が2023年11月リリース予定です。

PHPカンファレンス小田原2024が実施される頃には、皆さんの理解も進んでいることでしょう。

一方ですべての方がその機能を理解しているとは限りません。

今回はそのPHP8.3の機能を、小田原の地で一緒に振り返りましょう。
あと話者の趣味でパフォーマンス比較も行います。

• お話すること
  • PHP8.3の機能に関して
  • PHP8.3のパフォーマンスと、今までのPHPのパフォーマンス比較に関して

SRE、この言葉からあなたは何を想像しましたか？
会社のAWSアカウントを管理してくれている人！困ったときに助けてくれる人！SLI/SLOを推進する人！
さまざまあると思います。
SREの起源であるGoogleではSRE(サイト信頼性エンジニア)の名の通り、運用するサービスの信頼性を保つことが責務とされていました。
現代では Enabling,Embedded,Platformなどなど多様なSREが存在しています。
サービスの信頼性を保つという観点は同じでもそのアプローチ方法は多様です。
このトークではこれらの違いについて弊社での実体験も交えて説明します。
ぜひ、皆さんの会社におけるSREについて考えるきっかけを作れればと思っています！

小田原っこ: 小田原の会社で働いていました!

（初心者向けトークです）
PHP Data Objects（PDO）は、DBへのデータアクセスを抽象化する、軽量で高性能な拡張モジュールです。PHPでWebアプリケーションを作成するときは、多くの機会でPDOを利用する事があります。

このトークではPDOの基礎的な使い方から、実務レベルでRepository層でのPDOの扱い方についてお話しします。

対象者

• Webアプリケーション開発の経験が浅い方
• ORMなどは使った事があるけどPDOは無い方

話さないこと

• PDOの内部実装について

Architecture Decision Record (ADR)はご存知でしょうか？
設計に関する議論や決定をまとめておく文書として、近年注目を集めています。

本トークでは、実際に会社でADRを導入して一年以上運用した結果、開発現場で継続的に使われているのかどうかなど、 実情を赤裸々にお話します。

本トークで話す内容

• ADRとはなにか？
• なぜ、導入する必要があるのか？
• 実際に導入してみて苦労したこと
• 良かったこと、悪かったこと

概要

JIT コンパイルとは、実行時にネイティブコードへのコンパイルをおこなうことです。
PHP では、バージョン 8.0 から導入されました。
PHP 8.4 (プロポーザル記述時点での予定) では、8.0 で導入された JIT エンジンが作り直され、新しい JIT エンジンが導入される予定です。
このセッションでは、新しく入る JIT エンジンについて、現在の実装と比較しつつ紹介する予定です。

話すこと

• JIT コンパイルとは
• 現在の JIT エンジン
• 新しい JIT エンジン
  • 何が異なるのか
  • どのようなモチベーションで導入されるのか

目標

• JIT コンパイルとは何か理解する
• 新旧の JIT エンジンについて知った気になる

ある日、「手動オペレーションに定評がありますね！」（意訳）と言われたことがあります。（全然ネガティブな文脈ではないので安心してください！！！！！！！！！）

特にプロダクトの初期フェーズにおいては、プロダクト自体の機能や価値提供のために、管理画面の開発などの優先順位が下がることがあると考えています。

運用フロー、提供フローが定まっていないうちに画面を作り込んでしまうなどが、「早すぎる最適化」になってしまうこともあるでしょう。

そのような事態を避けるためにも、作り込めるポイントがくるまで、安定した手動オペレーションを行うことはチームにとってもプロダクトにとっても大切なことなのかもしれません。

本トークでは、手動オペレーションを行う際に私がどのようなことを心がけているのか？という話を中心に、作り込めるポイントをどう判断しているのかをお話ししてみたいと思います。

P.S. 浜松っこです。

近年、PHPプロジェクトの品質を高めるためのツールとしてPHPStanのような静的解析ツールが導入されるケースが増えています。

PHPStanを導入することによって、PHPでもJavaやTypeScriptのように静的解析の恩恵を受けることができます。

• コードを解析しやすくなるのでIDEが賢くなって補完やコードジャンプがしやすくなる
• 網羅的に検査しているのでコード修正によるエンバグを減らすことができる
• etc

既存のコードベースに初期導入するのは、コードベースが大きい程ハードルが高くなりがちです。
本トークでは40万行のLaravel PHPにPHPStanを導入した実例を踏まえて、どのように導入したのかをお話しします。

想定対象読者

• これからLaravelにPHPStanを導入したい人
• PHPStanを継続的に運用する方法に興味がある人

テストの目的は、迅速に進めるための十分な自信を得ることであり、より多くのコードをテストすればするほどチームはより自信を持つことができます。

しかし意味のない努力をしていないでしょうか？

• カバレッジ100%を目指すことにこだわるあまり、肝心な業務要件のテストが漏れている
• カバレッジレポートを見ていないせいで、重要な処理が集まるパッケージへのテストが漏れている
• そもそもテストコードがきちんと書けていないため、カバレッジレポートの数値が正確ではない

これらのアンチパターンに陥った場合、品質を高めるどころかむしろ下げてしまう方向へ努力していくことになります。

このトークでは、上記のようなアンチパターンに触れながら、努力に見合ったテスト品質の向上を目指すためのノウハウをお話しします。

テストを書くとき、テストデータ（テストフィクスチャ）をどのように用意していますか？プロダクションコードを改修するとき、テストフィクスチャにも多数の改修作業が発生してつらくなっていませんか？
私は10年近くテストのある開発をしてきた経験から、テストフィクスチャもオープン（拡張に対して開いている）で、クローズド（修正に対して閉じている）にするのが良いのではないかと思うようになりました。
このトークではまず様々なテストフィクスチャの作り方を概観した後、オープン・クローズドなテストフィクスチャを実現するために現時点でベストだと私が思う方法をお伝えします。

テスト書いてますか？ますよね？
─果たして、本当にそれが正解でしょうか。

テストには「欠陥があることの証明」が重要です。
「証明しなくて良い事」が増えれば、テストの責任も軽減されるでしょう。
つまり、書くべきモノが減ります！！
実際に、設計技法やPHPの機能、ツールによって、そんな願いが叶えられると考えます。
例えば「引数にint型宣言」で、「文字列を受け取ったらどうバグるかの証明」はお役御免です。

良い意味でテストを減らす道・・・探りましょう！

持ち帰って欲しいもの

• 改めて「テストの訳」に立ち返る
• 「横着してテストを書く」以外の方法を模索する

話すこと

• 単体テストに何を期待していますか？
• 安心できて開発体験も良いコードに想いを馳せる
• 「テストを書く」以外に責任を分散する

話さないこと

• E2Eなど、単体テストよりも「広め」のテストについて

私はこれまでの業務で主にPerl、Go、TypeScriptなどを書いてきました。PHPは1行も書いたことがありません。

PHPカンファレンス福岡2023に何気なく参加したところとっても楽しく暖かいコミュニティだったので、「これは登壇する側にならねば！」と思いました。

このLTではPHPカンファレンス小田原2024当日までに締め切り駆動で初めて扱うPHPで何かしら成果を作り公開します。作ったものを当日発表するのでクオリティはおいておいて楽しみにしてもらえれば嬉しいです。

開発の中でPHPに対しての感想も出てくると思うので他言語経験した人からの視点も共有できればと思っております。

私はWebフロントエンドエンジニアですが、PHPカンファレンスに参加するうちに、PHPという言語の持つ魅力と、PHPコミュニティの魅力に深く引き寄せられました。

そこで、自身のWebフロントエンジニアとしての視点から、PHPの新たな展開を探ることができないかと考えました。私が注目したのは、Webブラウザのようなモダンな実行環境上で、ネイティブコードに近い速度と安全なコード実行を可能にするWeb Assemblyと、Rustで書かれたモダンなJavaScriptランタイムエンジンであるDenoを用いて、PHPを動かしてみるという取り組みです。

本プロポーザルでは、シンプルなアクセスカウンターの作成を通じて、これらの技術要素の組み合わせの持つ可能性を探求します。具体的な成果物の作成を通じ、Web AssemblyとDenoから実行されるPHPの可能性を掘り下げ、その結果についてお話します。

職場や自身の担当が変わった時など、今まで触ったことのないプロダクトをキャッチアップする機会はままあるかと思います。
そういった時、少なくともコードベースでのプロダクトを理解することは、その後の仕事効率に効果が出やすいものです。
ではプロダクトを理解するためには、何から見ていくのが良いか、それをどうやって自分の知識に落とし込んでいく方法があるのか、ということを簡単にお伝えしてみたいと思います。