トーク

アラン・ケイ博士が考案した最初のオブジェクト指向言語Smalltalkは、トリグヴェ・リーンスカウク氏が論文でMVCを提唱するきっかけとなり、あのKent BeckもTDDやXPの考案者として有名になる前はSmalltalkの開発者、SUnitの作者として名を馳せました。

Smalltalkを学んでみたいと思っても、学習環境はあまり整っていないように思います。 しかし我々の手元にはAIがあります。 私はAIの力を借りて、Smalltalk を（少し）学んだ結果、オブジェクト指向とWebのなかった時代のMVCの真髄に触れた気がしました。

このセッションでは、Smalltalkを通してメッセージ指向のオブジェクト言語、またMVCフレームワークではない真のMVCとは何かを紹介することで、現代に生きる我々が過去を学び、日々の開発に対して新しく視野が開かれていくという温故知新を目指します。

何かを志そうと思った時

「どうせ無理」
「そんなのできる訳がない」

と言われたり

「私にはどうせ無理か…」

と諦めてしまったりすることがあるかと思います。

システムエンジニアとして働く中でそんな”どうせ無理”に抗い、今では好きなことを仕事にすることができています。
どう抗い、どう好きなことを仕事にしてきたのかをご紹介します。
誰かが少しでも自分らしく生きるためのヒントになれば幸いです。

皆さん、バイナリやバイトコードはお好きですか？
さて、Java、Python、Lua、Ruby他、モダンな言語は言語VMという機構を備えています。さらに、WebAssemblyのような、特定の言語に依存しないVMもあります。
そしてご多分に洩れずPHPにもVMがあります。とはいえ、PHPプログラマが直接VMのバイトコードを書くわけもなく、「OPcacheが使うなんか高速にするやつ」というふんわりした理解の方も多いのではないかと思います。

このトークではPHPのZend VMを通して、VMとはそもそも何か、なぜ必要か、VM実装の基本についてお話しします。以下のトピックの予定です。

・VMに関する基礎知識
　・レジスタマシンとスタックマシン
　・バイトコードの基本
・言語におけるVMの意義とメリット
・PHPのZend VMに触れてみよう
・Zend VM互換のVMを自作してみた（？）

みなさんはnikic/PHP-Parserをご存知でしょうか？
様々なライブラリの裏側で使われているPHP-Parserですが、実は皆さんにとっても身近な存在かもしれません

このトークではPHP-ParserやASTの概要について軽くお話しするとともに、
PHP-Parserを利用してASTの差分を取り、同じプログラムであることを保証することで軽微なリファクタリングを気軽に行う方法を紹介します

「レガシーな環境だし、テストもないからLinterをかけたいけどかけられない」
そんなお悩みを持っている方の一助になれば幸いです

ソフトウェア工学の70年の歴史において、我々は三つの主要なパラダイムを経験してきました。命令型（How）は実行の手順を、オブジェクト指向（Who）は実行の主体を、関数型（What）は計算の内容を問いました。本講演では、第四のパラダイムとして「存在論的プログラミング（Whether）」を提唱します。それは「存在するか否か」を問う、プログラミングの本質的な変革です。

時間と存在は分割できない – 存在論的プログラミングは「時間と存在の不可分性」を基礎とします。OOPが永遠の現在に囚われ真の自律性が保てなかった一方、このパラダイムにおいてはオブジェクトは時間の中で変態（メタモルフォーシス）し、その各瞬間において完全な自立存在として現れます。

70年間、我々は「より良い命令」を追求してきました。しかし、複雑性の増大、AIとの共生という時代の要請が、新しいパラダイムを必要としています。

自社プロダクトの保守運用では、ユーザーからのお問い合わせに対して技術調査を行う場面があります。プロダクトが大きくなるにつれて自分の知らない知識（コードベース）も増えて、技術調査が難航する場面もあります。

本トークでは、自分の知らない知識に対し、AIを活用した技術調査の方法についてお話します。特にドキュメントに対してはNotionAI、コードベースに対してはGitHub Copilotを使用した知見についてお話します。

話すこと

• AIを使った技術調査の方法
• AIを有効に使うための情報のストック（議事録からアプリケーションログまで）

GitHub Copilot Code ReviewでPHPのコードレビューをしてもらってます。
レビュアーにアサインするだけでコメントを付けてくれるので非常に便利です。

でも概要はあっさりしてますし、もっと多くの観点からレビューしてもらいたいです。
なので自分は、VSCodeのCopilot AgentにCustom Instructionsでレビュー観点を与えた上で、GitHubのMCPを通してブランチ差分のコードレビューをしてもらっています。
PRのレビュー依頼があればとりあえずCopilotに投げてます。
GitHub Copilot Code Reviewよりもう一歩進んだレビューが得られます。

このトークでは実際の業務で使用しているCustom Instructionsの具体的な設定内容と、
設定前後のレビュー品質の違いを実例でお見せします。

個人開発でWebアプリを作成するのにClaude Codeを使ってます。
AIにコーディングしてもらうと開発時間を圧倒的に短縮できるのが非常に良いです。

ただ保守のことも考えてコーディングをするとなると、個人のレビュー能力を超えた速度でコーディングしてもらうことは難しいです。
ちゃんと理解して、正しいコードかどうか判断した上で進める必要があるからです。

AIと壁打ちをしながら仕様を一つ一つ自分で決めていきます。
完璧を目指さない。まずはやってみるというマインドで試行錯誤を繰り返してきました。

本トークでは実際のWebアプリ開発を例にClaude Codeとの協働開発プロセスを解説します。
特に以下の点を具体的に説明します。

・PRDの作成
・コーディング
・画面・コードレビュー

明日からの個人開発で実践できる具体的なワークフローとコツをお持ち帰りいただけます。

「設計ドキュメントは必要か？」
この議論は開発現場でたびたび持ち上がります！

ドキュメントが少ないことでスピードが出るチームもあれば、丁寧な設計が結果的に開発効率を高めるチームもあります。
複数の開発チームを経験する中、『チームトポロジー』を読んで「ドキュメントの最適なあり方は、チームの特性に依存する」という気づきを得ました。

本トークでは、以下の観点から「チームごとに適したドキュメント管理の考え方」について具体的にお話しします。

・ドキュメントの必要性とは
・チーム特性に応じたドキュメント管理
・実際のチームで実践しているドキュメント管理方法

設計やチーム運営に関わるエンジニアにとって、明日からの開発をより良くするヒントを持ち帰っていただける内容を目指します。

「スタイルとは何か。野生とは何か」──元同僚がXでつぶやいたとき、探索的テストにまつわる曖昧さに、改めて目を向けるきっかけになりました。
Cem Kanerが「スタイル」と呼んだこのアプローチは、仕様の曖昧さに対して、観察・仮説・検証を繰り返す“ふるまい”です。それは、私自身の思考のクセに根ざしつつ、チームの存在によってアプローチとしての気づきが促されてきました。

本セッションでは、探索的テストを「スタイル」として捉えることで見えてきた、属人性・再現性・品質との向き合い方を語ります。QAの実践における“野生”──型にはまらない問いとふるまいが、どんな価値を生んできたのか。その軌跡を共有します。

「やべっ！テスト落ちた！！一旦Rerun！！！」
──みなさん、これ、やっていませんか？（特大ブーメラン）

通ればラッキー、通らなければ…まああとで考えるか、というアクションに陥りがちです。
このような"たまに落ちる"Flaky Testを放っておくと、じわじわとテスト全体の信頼性を失っていきます。

私自身、何度も同じ轍を踏んできましたが「そもそもそのようなテストを書かないようにする」勘所を掴んできました。
このトークでは、Flaky testになりそうな臭いのするテストの勘所、そして、そもそも生まないためのテストの書き方について話します。

話すこと
・Flaky Testになりやすいパターン（キーワード: 不定な並び順, 非決定的な現在時刻, 日付が変わると落ちる, ...）
・Flaky Testにしないための書き方
・Flaky Testをそもそも生まないために

Amazon RDS Blue/Green Deploymentは本番DBのクローンを作成し、更新後にスイッチすることで安全かつ高速にリリースを行う仕組みです。
ダウンタイムめちゃ少なく移行できる！！というのが旨みで時間のかかるDBアップデートもユーザーに負担をかけることなく終わらせることができます。

これを完遂させるまでにはいくつかの悩み・ハマりポイントがありました。
そのため実録として、どのように運用したか実際に作った手順書も大公開します。
不安の多いDB バージョンアップをハードルなく進めるための指針となる話をします。

話すこと
・Blue/Green Deploymentとは
・実録〜前もって確認すること・手順書・リアルな所要時間〜
・Blue/Green Deployment を選ぶ場面、選ばない場面
・やってみてわかったDBバージョンアップの勘所

何かを志そうと思った時

「どうせ無理」
「そんなのできる訳がない」

と言われたり

「私にはどうせ無理か…」

と諦めてしまったりすることがあるかと思います。

システムエンジニアとして働く中でそんな”どうせ無理”に抗い、今では好きなことを仕事にすることができています。
どう抗い、どう好きなことを仕事にしてきたのかをご紹介します。
誰かが少しでも自分らしく生きるためのヒントになれば幸いです。

PHPでwebシステムを開発をしていると、必ずと言っていいほど日付に関わる処理を実装します。

「契約開始日から1ヶ月後の契約だけこんな処理を。。。」
「この条件は注文された日から30日間だけ有効で。。。」
「受注日より前の注文だけ取得して。。。」

新人エンジニアの頃、何気なく渡されたタスクで、何気なく実装した日付に関する処理でエラーを連発してしまいました。

• DateTimeImmutableを使わないとどうなるのか？
• DateTime->modify('1 month')が1ヶ月後にならない
• 1ヶ月後って何日後？

簡単そうなタスクに見えて落とし穴がいっぱいの日付について話します。

Laravel開発でphp artisan serveを叩きビルトインサーバを起動するお馴染みの光景。
しかし、公式ドキュメントには「本番環境で使うな」の一文が。
なぜビルトインサーバーは手軽さと引き換えに、本番環境で採用できないのでしょうか。
また、本番環境でデファクトスタンダードとなっている「Webサーバー + PHP-FPM」という構成は、どのようにそれを解決するのでしょうか。

以下についてお話しします。

• ビルトインサーバーが本番環境で推奨されない理由
• WebサーバーとPHP-FPMの基本的な仕組み

laravelの php artisan optimize
開発環境では思わぬエラーになるかも？

TypeScriptやRubyから、
PHPを触りはじめて1番戸惑ったコチラについて、事例も交えてお話出来ればと思います。

この辺りの理解を深める事で、
なんとなく治った謎のエラーから、
ちゃんと理解して解決できるようになりました！

こんな事を話します。

• 事例
  • こけるはずのテストが通ってしまった
  • laravelのAPP_KEY変更が反映されない
• php artisan optimize とは
• optimizeのクリア用コマンドについて
• どういう運用がベターか？
• なぜ本番環境では必要なのか

皆さんはPHPに機能追加してみたくなりませんか？
私はPHP 8.4から機能追加をPHP本体にやってきていて、様々な関数を世に送り込んできました。

• mb_trim、mb_rtrim、mb_ltrim関数
• mb_ucfirst、mb_lcfirst関数
• grapheme_str_split関数

PHP 8.5では以下の関数が追加予定です

• grapheme_levenshtein
• grapheme*関数にロケールを追加する(8月8日現在では投票中です)
  https://wiki.php.net/rfc/grapheme_add_locale_for_case_insensitive

みなさんも、RFCで提案してみるのはどうでしょうか？そのコツなどやり取りをお伝えできればと思います。

LaravelとInertia.jsを使ったフルスタック開発では、バックエンドからフロントエンドへ渡すPropsやリクエストボディの型情報をTypeScriptで手動で定義する必要がありました。これにより、バックエンドとフロントエンドで型定義の不整合が起きやすかったり、データ構造の変更時に複数箇所の修正が必要などの課題がありました。
Laravel Wayfinderは、Laravelのコントローラーやフォームリクエストから自動的にTypeScript型定義を生成するパッケージです。バックエンドを変更すると自動的にフロントエンドの型情報も変更されるので、開発体験が大幅に向上します。

話すこと

• Inertia.js概要
• Laravel Wayfinderの導入方法と基本的な使い方
• Inertia.jsのPropsとフォームデータの型自動生成
• 実際のコード例とライブデモ

謎のIDや変数と複雑な仕様、夜中の手動更新、トラッキング漏れ──20年使われてきたユーザ流入基盤の運用は、もはや限界を迎えていました。「うちら辛くね？」この一言から始まったプロジェクトで学んだのは、システム改善の成功は「仲間づくり」にあるということ。

チーム・上司・運用・ビジネスを巻き込み、刷新プロジェクトを発足。安全性と保守性を備えた新基盤への移行をリーダーとしてやり遂げました。「ちょっと頑張る必要あるけど、めっちゃ使いやすくするから」という言葉を、どう信じてもらえる形にしたか。

本トークでは、フェージングが雪崩になった失敗、重い課題を別PJに切り出す判断、段階的リリースから一気リリースへの方針転換など、9ヶ月のリアルな軌跡を共有します。中堅エンジニアが直面する「与えられた仕事以外」をどう進めるか、「“やるべき仕事”は自分で作りだす」ための実践的なヒントをお話します

PHP 8.5で導入されるパイプ演算子（|>）、楽しみですね！

パイプ演算子を使うと、
strtoupper('hello')
と
'hello' |> strtoupper(...)
が同じ意味になります。

実は、例にあげた2つの式は、opcodeとしても同一です。

このトークでは、php-srcのソースコードを読み解きながら、パイプ演算子がどのように実装されているかを見ていきます。

具体的には以下の内容を扱います

• vldでのopcodeの比較
• opcodeのコンパイルに使われるzend_astとznode
• パイプ演算子を処理するzend_compile_pipe

PHPの新機能を通じてphp-srcに入門してみましょう