近年、さまざまな動的言語に型をつけ、静的解析する試みが盛んに行われています。

このセッションではその考えの言及となった漸進的型付けのアイディアの紹介から、各言語の型付けに対する動向まで紹介します。

選手入場

• PHP
• TypeScript
• Python
• Ruby

WebAssemblyはWebブラウザでの利用にとどまらず、エッジコンピューティングでの実行やプラグインとしての記述手段、マイコン用のランタイムまで存在します。

本トークではWebで動くWebAssemblyとは一味違う、WebAssemblyのWebブラウザの外の話をご紹介します。

また、 PHPをWebAssemblyバイナリにする方法を模索し、マイコン上でPHPを動かす試みを行います。(登壇までに実演できることを期待しつつ……現在はPHPバイトコード→Javaバイトコード→WebAssemblyが最有力)

はなすこと

• WebAssemblyの概要と思想
• WebAssemblyのWebブラウザ外での利用(WASI、言語埋め込み、プラグイン、マイコン)
• 昨今のマイコン事情
• (PHPをWebAssemblyに頑張って変換してマイコンで動かす)

はなさないこと

• WebAssembly VMの仕組み
• Webブラウザで動作するWebAssemblyの活用方法
• PHPからWebAssemblyを呼び出す方法

対象

• WebAssemblyの思想を知りたい方
• ブラウザ以外のWebAssemblyでの使われ方を知りたい方
• (できないとよく言われるけど……)PHPをWebAssemblyにしたい気持ちがある方

なんらかの機能の開発者は、機能を作る際になんども同じ動作を繰り返して正しく動くことを検証すると思います。
一方で開発者だけだと見逃してしまう考慮漏れなどに気づくのに有効なのが別な人がその機能を触っての検証です。

開発者も検証者も検証シナリオを考えたり、実行したりする際に、同じような動作を繰り返します。
その機能のユーザーは開発者や検証者よりは長い時間をかけてその機能を利用するはずですが、
同じような操作を何度もするという点ではあまり相違はないと思います。

つまり、開発者や検証者が面倒だな、複雑だなって感じる部分は、その機能を何度も使うユーザーにとっても面倒で複雑なものになる可能性があるのではないかと思っています。
このことを具体的な機能の例で示します。

BEAR.Sundayの最初のアルファリリースから2024年で10年になります。これを記念して、他のフレームワークにはないBEAR.Sundayのユニークな特徴をポスターで紹介します。

• コンポーネントの集合ではなく、制約の集合。フレームワークのフレームワーク
• Google Guice クローンのDIシステム
• AOPアライアンス準拠のAOP
• RESTネイティブ
• Semverリスペクト。リリース以来の後方互換継続
• SQLとPHPインターフェイスの束縛
• イベンドリブンで無効化可能な分散キャッシュフレームワーク
• 合成可能なクリーンアプリケーション
• アプリケーションからAPI ドキュメントの生成
• IA(インフォメーションアーキテクチャ）との親和性
• マトリクスコンテキストによるアプリケーションの振る舞いの変更
• 超絶パフォーマンス

人類が増えすぎたPHPを品質保障(Quality Assurance)するようになって既に20年が過ぎていた…
開発環境の周りの巨大なContinuous IntegrationはPHPerの第二の故郷となり、人々はそこでプロダクトを生み、育て、そして死んでいった。

西暦2023、静的解析が開発環境に取り入れられるようになり、いくつかの現場ではめざましい成果を挙げたが、別の現場では疎まれ、また別の現場では開発プロセスに投入できないまま散っていった。

このトークでは、私の考える静的解析導入時のバッドプラクティスをお伝えします。

• 何のために型をつけるの？
• コードの型付け、どこから手をつける？
• 「えっ、せっかくならlevel:maxにしないと意味なくない？」
• 汝、 @var を憎め
• あなたのユニオン型の使いかたは間違っている

過去、私は社内の勉強会を主催してきましたが、2023年には他社の方と何度か勉強会を開催する機会を作り実行してきました。
これらはまるで「ミニカンファレンス」のような形をとり、非常に有意義なものでした。
その経験から得た知見を共有し、これまでの成功と失敗から学んだことを皆さんとシェアしたいと思います。
PHPer同士の合同勉強会がもっとカジュアルに行われることを願って！

書くこと

• 合同勉強会をなぜやるのか・開催するモチベーション・社内にもたらされる効果
• 「やりましょう」のHOWTO
• 当日までにやること
• 当日のHOWTO
• 合同勉強会に入れた方が良い要素

友達の目に余る行動、恋人に直して欲しいところ・・・
伝えたいことはたくさんあれど、嫌われたくないと思う気持ち。
しかしオブラートに包むとうまく伝わりません。

このようなご経験のある方はCodeReviewer改め、行動Reviewerと呼ぶべきでしょう。
そんな行動Reviewerなみなさまが一体どのように伝えていくと相手に聞き入れてもらえるか、phpを交えながら面白おかしく発表していきます！

私たちが開発しているPHPサーバーは色々な人から受け継がれ秘伝のタレが継ぎ足され続け、よく分からないバグが稀によく起きます。
これまでその解消の武器をいくつもそろえましたが、最近はオブザーバビリティエンジニアリングという武器を使っています。

オブザーバビリティがあるシステムは新しいコードをデプロイせずともデバッグができるシステムです。
OpenTelemetry はそれを実現できる技術の一つですが、PHPで始めるのはいくつかの障壁と意思決定ポイントがあります。
例えば、collectorやbackendといった登場人物の理解、小さく始めるにはどのotel backendを採用すべきか、計装ライブラリは何を使うべきか、どこに仕込むべきかがあります。

私たちはオブザーバビリティエンジニアリングを実践すべく、OpenTelemetryを導入しました。
しかし満足のいくようなアプリケーションのトレーシングとメトリクスを出すまでに色々な失敗を繰り返しました。
このトークではOpenTelemetryを既存サービスに導入するにあたってどのような選択肢があるかを紹介し、どの選択をした結果どのような失敗をしたかをお話しし、PHPでの計装の事例紹介をしたいです。

public subnet のロードバランサーで受けて、private subnet のアプリケーションで処理して、storage subnet のデータベースに保存する。
これが、自分がこれまで「信仰」していた、クラウドの構成概要でした。

が、最近とある方に、自分にとって Breaking Change な発想を提案されました。"public subnet に全部置いちゃう" というスタイル。
セキュリティグループで通信制御すれば、いいんじゃない？トノコト。

あるコミュニティで話を聞いてみるとわりと既にこのスタイルだったり、実際に NAT Gateway 要らずでコスト効率最高だったり、意外にアリなんだなと思いました。

本トークでは、この角度を実現した２つの事例をご紹介します。

• 3層構成FargateをIaCでコスト最適化構成に"1週末"で作り直した
• 1台のEC2で稼働していた小規模なサービスのネットワークをダウンタイムなしで再編した

Macユーザーの皆様、Docker環境は何を使われておりますか？Docker Desktop, Rancher Desktop, Colimaなどあるかと思います。
今、MacのDocker環境で一番注目されいるツールは、OrbStack(https://orbstack.dev/)といっても過言ではありません。「OrbStack is the fast, light, and easy way to run Docker containers and Linux. Develop at lightspeed with our Docker Desktop alternative.」と公式サイトにあるように、早くて、軽くて、簡単に扱えるツールです。

このLTではOrbStackは何ができるのかを説明します。そしてOrbStackならではの便利機能を使いながらLaravelアプリケーションのローカル開発環境の方法もご紹介します。

対象者としては以下の方を想定しています。

• Macユーザーでローカル環境でDockerを使われている人

対象としていない人は以下となります。

• Macユーザーでない方

このセッションでは、 require と use 宣言は似てそうだけど違うということが分かったということについて話します。

私は、素のPHPからPHPを勉強し始めました。その時は、「他のPHPファイルを読み込むときは require を書く！」でとにかくファイルの先頭に require を書いて読み込んでいました。

そして、フレームワークも勉強したいと思いLaravelを始めました。すると、ファイルの中には require を先頭には書いておらず、 namespace と use がたくさん書いてありました。

自分でフレームワークもどきを作ってみて、 namespace と use を使い、PHPでブログサイトを作ってみました。namespace と use 宣言、 require は書く必要があった！ということがわかりました。

話すこと

• require と use の違い
• use を理解しようとしたら出てきた namespace について

対象

• PHP初心者
• 名前空間を知らない方
• 素のPHPを書きたい方

php-src。それはPHP言語のソースコードのことです。
そのため全て読むのは大変です。
php-srcを読む際、適当なtest.phpを作り、ast\parse_codeを利用しながら気になる挙動の構造を確認したり、気になるfunctionにブレークポイントを仕込んでdebugしていくこととなるでしょう。

しかし、debug環境を整えようとすると、一筋縄ではいかないことが多々あります。少なくとも経験の浅い僕にとっては簡単ではありませんでした。
MacやWindowsなど、デバッグを試す環境の違いにより色々な知見を得ながら環境整備しなければなりません。
それだけの労力を割きながら、いざphp-srcのmake testをしてFailだらけになると気が滅入ってしまうものです。

そこで、Dockerを利用してphp-srcのためのsandbox環境を整えました（発表当日にはgithub上でpublicリポジトリとして公開します）。
本セッションでは、そんなsandbox環境とVSCodeを連携方法や、それらを用いたfunctionへのアプローチ（debug）方法をお伝えいたします。

もうphp-srcの環境構築に迷うことはありません。
素敵なphp-srcリーディングライフを送りましょう！

対象者： php-srcを読んでみたい方/読もうとしたけど環境構築で挫折した方

皆さん、コア吐いてますか？

コアダンプファイルは実行中のプログラムのある時点でのメモリ内容を、丸っとファイルへ吐き出したものです。Linux や Unix 系 OS では、プログラムがクラッシュした際など、設定によってその原因究明のためのコアダンプファイルを吐き出させることができます。

我々 PHPer にはコアダンプファイルは馴染みの薄いものです。PHP スクリプトの実行でコアが吐かれるのは、ふつう処理系や C 言語拡張部分の不具合を踏んだ場合です。PHP は仕事で使われることの多いビジネスマンの言語で、仕事でそのような不具合を踏みやすい環境を常用することは珍しいでしょう。

しかしこのコアダンプ、プログラムのクラッシュ時以外でも取れば取れるもので、気合で読めばけっこう楽しいものでもあります。みなさんもこのトークを聞いて、毎日じゃんじゃんコアを吐いていきましょう！

PHP スクリプトは Web で多く使われ、Web システムの多くは I/O バウンドなため、CPU が遊びがちです。マシンの有効活用には PHP ワーカを増やして並列度を上げたくなります。

しかしたとえ CPU が余っていても、各ワーカプロセスがメモリを食いすぎると並列度を上げづらくなります。実質的に可処分メモリ容量を各ワーカの消費メモリで割った数が並列度の上限となってしまうこともしばしばです。

昨今は Roadrunner、Swoole、FrankenPHP といったリクエストごとに状態をリセットしない AltFPM が成熟してきており、また昔ながらのキューワーカのようなものや Web 以外での PHP 利用も含めて、long running な PHP 実行環境を利用するシーンは増えてきています。これは、メモリがどこでどう使われているかを把握しその改善を行う技術の求められる局面が日に日に増えてきていることをも意味します。

このトークではメモリ使用量の計測のとり方からビットフラグ化、interning、SHM 追い出しといったみみっちいテクニックに PHP のアロケータ実装にまつわる事情の把握まで、12 のメモリ改善技を雑然とご紹介します。

2023年9月、初めてPHPで Hello World しました。

私はいわゆるサーバーアーキテクチャを勉強するのが好きです。これまでにプリフォークサーバー、マルチスレッドサーバー、イベントループサーバー、グリーンスレッドの最小構成を自作したことがあり、ブログにまとめたこともあります。（ https://blog.ojisan.io/server-architecture-2023/ ）

そんな私が PHP の勉強として docker-compose + MySQL + PHP で簡単な掲示板サーバーを作り、それをクラウド上にコンテナでデプロイしようとしました。しかしこれはとても難しかったです。Laravelアプリケーションをコンテナデプロイするためにはアプリケーションサーバー(PHP)とウェブサーバー(Nginx, Apache)に分離して開発、場合によってはそれらを FastCGI で繋ぐことに驚きました。当初私はアプリケーションサーバーだけを配置、もしくは前段にCDNを置くだけといった構成を想定していたためです。正直なところ PHP サーバーのコンテナデプロイを納得するためには低レイヤーでの理解が求められると感じました。そこでこのトークではPHPサーバーとコンテナデプロイでお世話になる低レイヤー技術（主に並行プログラミング）や新鋭のライブラリや環境についておさらいします。

EmacsやPhpStormのようなテキストエディタは常に最新のPHPをストレスなく書けるように機能を提供し続けています。
直近追加されたmatch式やenum構文なども問題なくハイライトしてくれるのは誰かが対応してくれているからです。
この記事では、そもそもテキストエディタはどのように構文を解釈してハイライトしてくれているのか、tree-sitterなどの最近のテキストエディタ事情も踏まえて解説していきます。

私は今までマネジメントに携わらず、メンバーレベルのエンジニアとして開発業務に携わっていました。
しかし最近小規模(4人)チームのリーダーを任され、どちらかというとマネジメントよりの業務の役割が増えています。

その際に気づいたこと、失敗したこと、意識したこと、戸惑ったことを赤裸々にお話します。

業界歴３~４年目のマネジメント系業務に挑戦するエンジニアにおすすめのトークです。

皆さんが所属してるエンジニア組織の課題はなんでしょうか？
どの組織も何かしらの課題があるのではないかと思います。

当社ではPHPで開発された複数メディアを運営し、エンジニアの人数も増加しながら継続的にリリースすることで順調に事業を成長させてきました。

一方で、事業が成長するにつれて「スキル獲得に漠然とした不安がある」や「他エンジニアと交流・切磋琢磨が生まれにくい」と言った声も聞こえるようになりました。

こういった課題に対して、エンジニアリングマネージャーとテックリードを中心に「技術推進委員会」という名の横断組織を作り、メンバーで熱い議論を交わしながら課題解決の施策を考え、実施してきました。(チーフエンジニア制度設計、ハッカソン運営、AWS勉強会開催etc)

このセッションでは、横断組織の立ち上げからこれまでに実施してきた多くの施策や、施策を実施したことでの組織の変化について話します。

私はおよそ10年ほどエンジニアとしてお仕事をしてきたなかで、いろんなインシデント対応をしてきました。
その中で得てきた経験をもとに、「どんなことに意識して対応を行っているのか？」をまとめてお話します。

この話を聞いた方がインシデント対応することになった時、１つでもいいので実務で活かしてもらいたいという想いでお話します。

お話すること

私がインシデント対応において大切にしている点
インシデント対応時に活躍するツールや使い方
原因分析と再発防止の考え方

想定する聴講者

インシデント対応をちょっとやったことある、けどもどんなことに意識していけば良いかまだ掴めてない方

『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック』（Boswell & Foucher）
エンジニアのみなさんなら、一度は読んだことがあるのではないでしょうか。

私はブライダル専門メディアを自社開発・運営している会社で保守開発を担当しており、
現在はサイトの一部機能を削除する案件にジョインし、開発を行っています。

Laravelで構築された弊社のサービスは、約20年続く結婚式場のクチコミサイトです。
改修に改修を重ね長年運用されてきたサイトの機能を削除することは、簡単ではありません。
例えば、以下のような問題に苦戦しました。

・表記揺れをしている、または意味を汲み取れない関数名・変数名である
・あちこちでクラスが継承され、メソッドやViewファイルの依存関係が複雑である
・おそらくもう二度と使われないプログラムをきれいさっぱり削除できているか、不安になる

この経験から、普段からシンプルで美しいコードで運用・保守していくことの大切さを痛感しました。

本トークでは、歴史ある大規模サービスの機能を削除する上で直面した問題と、そこから得た学びを共有します。
“機能削除”という観点から、『リーダブルコード』をどのように意識して実践していくべきか、一緒に考えませんか？