トーク

高速化が進み、JITコンパイラも導入されたPHPですが、残念ながら高速なスループットを求められる現場においては他のコンパイル型言語が選ばれることが多いです。
最近では、ISUCONにPHPで挑戦するものも少なくなりました。しかし、だからこそ！PHPでウェブサーバーを書いて、色んな言語に速度で挑戦しましょう！

以前挑戦したときは、OpenSwoole に頼り切りでしたが、今回はさらに色んな方式を試します。

PHPをDockerコンテナで動かし始めるとき、ローカル環境はDocker Composeで実装している人が多いのではないでしょうか。
Webサーバ (nginx) で受けてアプリケーションサーバ (php-fpm) で処理してDBサーバ (mysql) に接続する、そんな流れは知っていても、最初のうちはどう記述すればいいかよくわからず困りますよね。
結果、代々プロジェクトでコピペされてきた、あるいはインフラの人に声をかけると出てくる"秘伝のタレ"をあまり理解しないまま使ってしまっていませんか？
秘伝のタレを継ぎ足してきた立場から、その中身を紹介・解説します。理解してより旨いタレを作りましょう。

話すこと

• Docker Composeで起動する基本のサービス構成 (Web/App/DB)
• リバースプロキシ (HTTPS-PORTAL, Traefik) を利用したTLS終端, サービス間のポート競合回避

Emacsは世界最強のテキストエディタであり、PHPプログラミング単体を切り取ってもPhpStormを超える可能性を祕めています。

本LTはEmacsがPhpStormで出来ることと同様の操作が可能であることをお伝えします。
そしてもっと高度な操作やEmacsの機能を最大限に使いこなす方法を紹介していきます。

ぜひ本LTで「世界最強テキストエディタ」Emacsの可能性について感じていたきたいです。

話すこと

• Emacsへの愛について
• EmacsでPHPを書く際に便利なパッケージについて
• LSPやDAPについて
• org-modeの活用方法について

プロジェクトの振り返りは行っていますか？

振り返りにて
「これまでの問題点」
「これから伸ばしていく点」
を発見できるかもしれません。
プロジェクトの結果は技術面だけでなく、人為、経営など、多方面から影響を受けます。
これまでKPT法というフレームワークを用いて行った振り返りmtgで
記憶に残っている体験談をお話しします。

会社員時代、エンジニア同士にて行った振り返りmtg
サブリーダーを担ったプロジェクトにて行った振り返りmtg
案件に参画した際のチームにて行った振り返りmtg

素晴らしいフレームワークを使っても、
全てが有意義な振り返りmtgにはならないこと、
有意義な振り返りmtgには努力が必要であることをお伝えできれば嬉しいです。

PLATEAU(プラトー)というものをご存知でしょうか？
国交省が主導する、日本全国の3D都市モデルの整備・活用・オープンデータ化プロジェクトです。
現在、さまざまな都市の3Dモデルが公開されており、これらを活用して多様な実証実験が実施されています。

本LTでは、これらの3D都市モデルをUnityに取り込み、ちょっとしたゲームを作って遊んでみます。
なんというか、ボールっぽいものを転がして、建物を巻き込んで、カタマリ的なものを作っていくようなタマシイ風のやつです。

2021 年 11 月、PHP の処理系と言語そのものの開発に一大転機が訪れました。

• PHP の様々な側面での近代化に関わってきたコア開発者 Nikita Popov さんの活動規模縮小
• それを契機とした The PHP Foundation の発足

The PHP Foundation は寄付を募り、PHP 処理系の実装と言語仕様の改善へ取り組むコア開発者へ資金を提供して、日中の仕事として PHP の開発を行えるようにする団体です。寄付が集まるほど PHP の開発が加速し、私達 PHPer がその恩恵を受けられることになります。
https://thephp.foundation/

すでに日本を含めた世界中から多くの寄付が集まり、The PHP Foundation によって雇われた数人の開発者によって、実際に多くの言語改善が成し遂げられました。このような PHP の開発事情をすでによく知っていて、所属会社からも寄付を行っている、という方もいれば、「PHP という言語自体の開発を生身の人間がやっていて、彼等がどう日々のご飯を食べているかが我々のビジネスに強く関係している、なるほどその発想はなかった」という方もいらっしゃるかと思います。

このトークでは The PHP Foundation の成り立ちと意義、これまでの活動内容をあらためて紹介し、「そういうわけで皆も会社のお金で The PHP Foundation に寄付をしよう！」というお話を、The PHP Foundation の関係者でもないのに外野から勝手に力強くやっていきます。

LT 枠でめっちゃ早口になって舌も回りきらずよく聞き取れない部分が多くなる可能性がありますが、その場のライブ感とともにパッションをぶつけるのがきっと大事なことなので、細かいことはあまり気にしない感じでやっていきます。

PHPを使用している方にとっては、PHPの中身に興味がある方も多いと思います。そんな時は、PHPのソースコードを読んだり、改造したりすることで理解が深まることがあります。
PHPを改造した場合、その動作を確認するためには、コンパイルする必要があります。また、PHPをWeb上で表示するためには、Apacheなどのサーバーソフトウェアのインストールも必要になります。
そこで、このトークでは、PHPを実際にコンパイルしてWeb上で表示させる手順について、Dockerfileをお見せしながら解説します。

対象者
・PHPをコンパイルしてみたい方

話すこと
・PHPをコンパイルする手順
・PHPとApacheをコンパイル・インストールする上ではまったポイント

話さないこと
・Cコンパイラの選択
・PHPの内部実装

人工知能ってやばいですね！！私はあまり中身については分からないのですが、「きっとヤバいね」という噂をたくさん聞くので、すっごいヤバそうだなという事を知っています。

TestGen AIは、RectorやEasy Coding StandardsといったOSS活動でも有名なTomas Votruba氏のプロジェクトです。
https://testgenai.com/

テスト対象のコードを入力すると、自動的にPHPUnitのテストコードを生成してくれます。
(動作イメージは、↓のツイートなどを見ると分かりやすいかと思います)
https://twitter.com/testgenai/status/1639331232151371804

何をしてくれて、どんな感じに動くのでしょうか？
このLTでは、実際に触ってみて&これからどんな発展の可能性がありそうかを共有します。

MVP, Minimum Viable Product 顧客に価値を提供できる最小限のプロダクト。
よくアジャイル開発の文脈で「プロダクトはMVPから作りましょう」という話を聞くと思います。
たとえば初日にシステム全体のサイトマップを書き始めたり、ユーザーModelやログイン機能から作っちゃダメということです。
「価値を提供できる最低限」を見極めて、顧客の課題を解決するコアとなる機能から作る考え方とコツをお伝えします。

今や、CIを回して静的解析を活用して、コーディング規約の運用は機械で自動化するのが当たり前です！！
カンファレンスや勉強会に参加している皆さんにとっては、きっと「そうだそうだ！」と強く頷いていただける主張なのではないでしょうか。

・・・本当にやれていますか？
現実には、きっとそんな甘くないぜ！と唇を震わせている人もいるのではないでしょうか。
今まで使っていない方法や仕組みを取り入れるのは、心理的な抵抗感や不安も生じますよね。

まずは「ノーコストで入れてみる」という方法をとれないものでしょうか？それが出来れば、導入に向けた障壁が1つ解消しそうです。

このLTでは、実際にそうしたアプローチを実施して、PHP_CodeSnifferを既存プロダクトに導入した際の話＋今後の展望をお話しします。
私の戦略は、「既存コードに影響のないSniffを入れる」「それによって、まずは”CIでスタイルチェックが動いている”状態を作る」「そのために、既存コードの適合状況を機械的に分析する」「自転車置き場の屋根の色の議論を避けるために、トップダウン的にPER Conding Styleをベースにする」「今後の進展のための仕組みを作り、運用・展開を移譲する」などを組み合わせたものでした。

この手立てを使って、「何年もスタイルチェッカーを入れたい声はあったが実現されていなかった、10年以上の歴史を持つプロダクトコード」に対して、今ではCIによるチェックが稼働しています！

PHPにはプリロード(Preload)があります！！パフォーマンスが上がります！
・・・噂は聞いたことがある・存在は知っていても、実際に使ったことはありますか？
何となく難しそうだなぁ。。複雑な事をしなければいけないそう。。そんな風に、遠い存在に感じている人も多いのではないでしょうか

ayesh/composer-preload というパッケージがあります。
see: Packagist

これはComposer Pluginです。
READMEを見ると Composer Preload is a composer plugin aiming to provide and complement PHP opcache warming. と記述されています。
正に「プリロードを気軽に使ってみよう」を支援するツールであり、私達にとってプリロードを「遠い存在」から「身近な存在」に近づけてくれる可能性があります。

どんなアイディアでそれを実現し、どんな仕組みになっているのでしょうか？
簡単に内部に触れてみましょう。
それによって、「プリロード完全に理解した！」という人を増やすLTになります。

私は、学生時代に地方の大学で技術コミュニティー（サークル）の運営に取り組んできたので、地方大学のコミュニティーについてお話ししたいと思います。

私は新卒のエンジニアですが、昨年まで地方の大学で技術コミュニティの運営に取り組んできました。私が大学生の頃、2019年12月からコロナが流行し、大学はリモート授業になり、サークル活動も対面で行うことが難しくなりました。また、「地方のITコミュニティー」と「大学のサークル」では特性が異なりオンライン化に伴い、それぞれのコミュニティーで苦戦したことがあると思います。

このような環境の中で行ったことや、苦戦したことや上手くいかなかったことについて発表します。また、「大学生のコミュニティー特有の課題」や「地方大学のコミュニティーの課題」についてもお話ししたいと思います。

「学生で参加される方」や「学生コミュニティーに携わっている方」に少しでも多くのことが共有できればと思っています。

AWS上で構築したWebアプリケーションを開発したとき、PHPをメインに使っていてもフロントエンドから amplify を使って直接サーバーリソースにアクセスすることもあるでしょう。

これまで長らく使われてきた aws-sdk-js（以降 aws-sdk）は v2 から v3 となり、モジュール別のパッケージとして展開されるようになりました。

私も担当しているプロジェクトではサーバーサイド、クライアントサイド共に TypeScript を使っていますが、 aws-sdk v2 が本年中にメンテナンスモードに入ることから v3 への移行作業を行なっています。

そこで蓄積された v3 移行のナレッジや、ハマりポイントなど、v3 移行の現場から生の声を稲妻トークでお届けします。

先輩「この実装はどうしてこうなっているの？」
自分「ここは〇〇という理由でこうしています！」
先輩「了解です、その説明はコードコメントに書いておくとよいので追記お願いします～」
コードレビューを受けているとき、こんな経験はありませんか？

コードで表現できないことを説明したいとき、それを書く場所の候補はコードコメント、コミットメッセージ、プルリクエスト（説明欄やコメント）と多岐に渡ります。
「どこに書けばいいのかわからない！」そんなときの指針となるお話をします。

Github Actionsでworkflowを作成してCI/CDされている方も多いのではないでしょうか？
本セッションでは2022年にリリースされたカスタムアクションで開発者体験が良かったものを紹介したいと思います。
実際にプロジェクトに導入して習慣が変わっていった体験談にも触れたいと思います。
関連してworkflowの作成時のtipsもいくつか紹介したいと思います。

「推測するな、計測せよ」という言葉を耳にしたことがあるかもしれません。

例えばアプリケーションのパフォーマンス改善を行う場合に行き当たりばったりでアクションしてもうまくいかないことが多いと思います。

そのためにはまず実際の状況を知るための、「計測」するというアクションが大事です。

例えばツールを使ってコードのメトリクスを取るのもよいでしょう。
コードのサイズ、重複コードの有無、コーディング規約の遵守状況、循環的複雑度、エラーの有無などコードに対する「現状把握」をすることができます。

さまざまな値を取得すると有用な値やそうでない値なども出てきます。
その上で取得した値を分析・考察したり組み合わせて、「判断」をします。どこがアプリケーションの改善点なのか…？何がアプリケーションにとって最適なのか…？？プロダクトにもっとも寄与するためには…？？？

このように、推測で考えずに「計測」して「現状把握」を行い「判断」するというステップをもってカイゼンへのアクションを取ることが大切だと考えています。

このトークでは実際にどのように考えてアクションに移しているのか？どのように計測から現状を把握し、判断を持ってカイゼンのためのアクションをとっているのか？というエッセンスをお話しできればと思っています！

PHPアプリケーションのコード品質を上げて、メンテナンス性をあげて、寿命を伸ばすためによく使われるようになったphpstan。
皆さんのプロジェクトのphpstanのlevelはいくつですか？baselineは解消できていますか？
SymfonyやLaravelで作ったアプリケーションに対してlevel:maxを設定してbaselineなし・エラーなしにした経験から、コードを書くときに気をつけること＆phpstanを納得させるテクニックをLTの5分にギュッとまとめてお伝えします。

日々大量の PHP コードをタイピングする PHPer にとって快適なタイピング環境は非常に重要です。
しかし、市販のキーボードでは手に馴染まない、キーピッチが狭すぎるなど、自分のニーズに合わない場合があります。
そこで、基板から設計する自作キーボードの世界に足を踏み入れてみませんか？

このセッションでは、PHPer 向けに、自作キーボードの製作方法を紹介します。
ハードウェアの知識がなくてもおおまかな手順が理解できるように、
必要なツールや素材、発注から組み立てまで、キーボード製作のための手順を解説します。

自分だけのキーボードを作るための知識を獲得し、自分だけの理想のキーボード 「Endgame」 を作り上げ、快適なタイピングライフを手に入れましょう！

Macで複数バージョンのPHPを使い分けるのって意外と難しくないですか？
Docker経由でしかPHPを使わないみたいな猛者スタイルで行ければいいのかもしれませんが、
パフォーマンスや開発体験の問題からローカルのPHPを使いたい事情もあると思います。
phpenvやsymfony-cliと.php-versionファイルを併用すればディレクトリごとに使用するPHPバージョンを指定することもできますが、
この辺はいざ導入しようとするとYak Shavingの嵐が待っていて（実体験）非常に面倒だったりします。

というわけで、このLTでは私がMacのローカル環境で複数バージョンのPHPを楽に使い分けるために実際にやっていることを5分でサクッとお伝えします。
実際に運用していてまったくストレスを感じていない方法なので、ちょっとでも困っている人には明日からすぐにお役立ていただける内容だと思います！

現代のフロントエンド開発は、過去と比較して複雑化が進んでおり、HTMLの仕様に対する意識が低下しがちです。アクセシビリティの向上がますます重要視される中、HTMLはその基礎であり、正しい仕様の理解と実装が不可欠です。しかし、HTMLの仕様は想像以上に複雑で、WAI-ARIAなどの関連技術も含まれています。

このライトニングトークでは、Markuplintというツールを開発者が自ら紹介します。
Markuplintを導入することで、開発者は複雑な仕様を覚えることなく、リンターが問題点を指摘し、開発に集中できるようになります。

内容:

1. アクセシビリティの重要性とHTML + WAI-ARIA
2. クイズ: このHTML正しい？
3. Markuplintの紹介と導入方法

このトークを通じて、参加者にMarkuplintの有用性を理解していただき、より品質の高いWeb開発が行われることを期待しています。