トーク

みなさん、PHPを書いたことはありますか？
この画面を見ているほとんどの方は「YES」と答えるでしょうが、もちろん書いたことのない方もいらっしゃるでしょう。

私は昨年のPHPerKaigiを皮切りにPHPコミュニティに触れるようになり、2024年には某地方のPHPカンファレンス実行委員長をやることになりました。
しかし、PHPを実際に書き始めたのは2023年の11月。
普段はQAエンジニアとして勤務していたこともあり、開発自体にも少し苦手意識がありました。

本セッションでは、「PHPどころか開発経験も少ない私が、2ヶ月でどんなことに取り組んでPHPの理解を深めたのか」に焦点を当て
PHP未経験者が「実際にPHPを書く」ことにまずは興味を持ってもらうことを目標にします。

対象者

• PHPを書いたことのない方
• PHPを始めたての人に興味があるPHPerの方

話すこと

• 私が感じたPHPコミュニティの雰囲気
• 2ヶ月間で私がやったこととその工夫

わたしのチームでは、KPTをベースとしたふりかえりを9年以上にわたり実施してきました。
ふりかえりの議題はアプリに記録しているのですが、先日そのふりかえりアプリに登録された議題が1万を越えました。
現在ではふりかえりは職能やサブチームにかかわらず欠かせない活動となっています。

しかし、ふりかえりが定着するまでには苦労もありました。
Problemの登録ばかりで盛り上がりに欠けたり、言い出しっぺに改善の負担が集中するといった問題が発生していました。

本トークでは、1万のふりかえり内容をもとに、チームがどのようにしてKPTベースのふりかえりを定着させ、成長していったのかをご紹介します。

いつも目の前のコードとにらめっこしている皆さん！
「このコードには問題がある(気がする)、どうにかしたい」
・・・そんな風に感じつつも、「効率的にリファクタを実施していくぞ！！」と踏ん切りがついていない、なんて事はありませんか？

そうなるのは、コード自体や環境まで含めて、多種多様な要因があるでしょう。しかも、複合的に絡み合っています。
大きく複雑な問題だからこそ、「解き明かすための最初の一歩」を踏み出す勢いが欠かせません。
定量的なデータによって「ここから手を入れるべきだ」を語れたら、勇気を育めるのではないでしょうか。

このトークでは、ソフトウェア開発を「活動」「成果物」の両面から捉えて、現状を数値で表す指標ってどんなものがあるのかな？を示していきます。

ターゲット

• 「メトリクスベースで、リファクタや品質管理を考えたことがないな」という人
  • 既に実践している人や経験者は対象外
• 「リファクタが必要そうとは感じるが、どこから始めるか判断しあぐねている」人、計画を立てたい人

話すこと

• どのようにリファクタリング戦略を立てるか？
• 眠っている問題の大きさを示す、コード品質に関する指標
• 改善時の効果の大きさを示す、活動量や利用量に関する指標

話さないこと

• 「メンテナビリティやリファクタの価値、どう金額に置き換えるか？」の踏み込んだ話

NotionにはデータベースにCSVでレコードを一括投入するための 「CSV取り込み」 という機能が標準で搭載されています。
が、少なくとも2023年11月現在においては正直だいぶ貧弱な機能で、本当に最低限のことしかできません。
（例えば、インポートできるプロパティの種類が限られている、ページ本文はインポートできない、「名前」カラムの値が重複している行があると正常にインポートできない、など）

そこで最近、必要に迫られてPHPでNotionのデータベースにCSVをおインポートするフォームを自作しました。
このトークでは、このフォームの具体的な実装手順を、デモを交えつつサクッと解説します。

どうも、要件ヒアリングに自信ニキです。
私はフリーランスエンジニアとして受託開発のお仕事をよく頂くのですが、お客さんとの対話・ヒアリングを割と得意としています。

お客さんはシステム開発のプロではないので、説明が的を射ないことも多く、複雑なシステム要件のヒアリングには根気と体力を要しますよね。
そればかりか、なかなか合意や結論に辿り着けずいたずらに時間が奪われた挙句、結局失注して悲しみ、といった経験はないでしょうか。

私はよくお客さんから「1しか言ってないのに100のアウトプット出てくるんやが」「話が早すぎてもはや笑える」などと言われます。
一体私はお客さんとの対話中に何を考え、どんな手順でヒアリングを進めているのでしょうか。

このLTでは、お客さんとの対話中の私の頭の中身をまるっと皆さんにシェアします。
明日からのお客さんとの対話・ヒアリングに少しでも役立てていただけると嬉しいです！

Macユーザーの皆さんにはお馴染みのHomebrew。
Macの初期設定時のみならず、日々新たに便利なコマンドを見つけてはbrew installしていることと思います。
そんなお馴染みのHomebrewですが、裏側はどんな仕組みになっていて、コマンド自体はどこからダウンロードされているのかはご存知でしょうか？

実はこれ、とても簡単な仕組みになっていて、誰でも自分のGitHubリポジトリを通して自作のコマンドをHomebrewで配布することができます。

このLTでは、実際にPHPでCLIツールを作ってHomebrewで公開するまでの流れをお話しします。
自作のコマンドをHomebrewで公開して、世界に羽ばたきましょう！

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

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

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

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

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

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

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

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

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

API Platformは、SymfonyをベースとするPHP製のオープンソースAPIフレームワークです。
Symfonyアプリケーションにアトリビュートを1行追加するだけで一瞬でREST APIとOpenAPIドキュメントを生成できてしまう優れもので、
Symfonyのエコシステムにおいてはすでに決定版と言える存在となっています。

このトークでは、API Platformの導入方法から、State Provider・カスタムコントローラ・State Processorといった重要な基本機能の概要までを、
実際に動作するデモをお見せしながら丁寧にご紹介します。

皆さんにAPI Platformの概要を知っていただき、少しでも興味を持っていただければ幸いです！

API Platformは、SymfonyをベースとするPHP製のオープンソースAPIフレームワークです。
Symfonyアプリケーションにアトリビュートを1行追加するだけで一瞬でREST APIを作れてしまう優れもので、
Symfonyのエコシステムにおいては既に決定版となっています。

しかし、ある程度複雑なことをしようとすると途端にフレームワークについての深い理解が求められたり、
痒いところに手が届かず強引なワークアラウンドが必要になったりするという面もあり、入門と実戦の間には大きな隔たりがあります。

このトークでは、API Platformの導入方法から基本機能の概要、さらには実践投入に向けた各種ワークアラウンドや実装テクニックを、
実際に動作するデモをお見せしながら丁寧にご紹介します。

API Platformの実戦投入、あるいはその検討の一助になれば幸いです！

PHPUnitには、テストの起動〜実行〜終了の様々なタイミングで任意の処理を挟み込める、「Extension」というプラグイン機構があります。
これを利用することで、単体テストの実行やCI運用にまつわる「痒い所」に手が届くかもしれません！

例えば、
「テストが増えてきて、実行に時間がかかる・・・改善をしていきたい」
「テスト実行中にNOTICEが出た時に、処理を挟み込みたい」
「独自のアノテーションやAttributeを扱えるようにしたい」
などなど、細かい需要に向き合える可能性があります！

いざという時に、知っておくとお得かもしれない・・・？
そんなExtensionの仕組みについて、紹介していきます！

はなすこと

• PHPUnitのExtensionの概要
• 例えばどんな機能を提供できるのか、実例
• 簡単なサンプルを用いた開発・利用方法の紹介

一緒に働いていて「この人に相談したらどうにかなる」って人、いますよね。
この「どうにかする力」って何なんだろう。
力を持ってる人に聞くと「気合」「経験」「勘」と言った回答が来ることが多いです。
本LTではこれをもう少し噛み砕き、「どうにかする力」の正体に迫ります。
みんなで「どうにかする力」を身につけていきましょう！

パフォーマンス改善と聞くとどんなことを想像するでしょうか？
大半の人はクエリチューニングであったり、ロジック改善であったり、キャッシュ化であったり
元の仕様を変えずに速度向上をする、というイメージがあるかと思います。
ISUCONなどはまさにこれで、元のテスト（ベンチマークツール）が通るように改善を行っていきます。

しかし現場で10年ほど開発経験を積んできた私の持論としましては
「あれ？これちょっと仕様変えるだけで劇的にパフォーマンス良くなるのに、元の仕様を変えない理由ってなんだっけ？変えれば良くない？」
という結論に至りました。
もちろんケースバイケースで絶対仕様が変えられない状況下でパフォーマンス改善していく、ということはあると思います。
しかしもし仕様から変えて良いものであれば、それは仕様再検討から実施することで圧倒的なパフォーマンス改善を実現できると私は考えています。

本セッションでは

• パフォーマンス改善の勘所
• 実際に行った「仕様変更を伴うパフォーマンス改善」

このあたりをお話できればと思っております。

昨今、よく分からず不用意にGitHubのパブリックリポジトリに上げてしまうなどの、コードの流出事故が問題になっています。
またChatGPTやGitHub Copilotなど、ソースコードを読み込んで学習し自動でコードを生成してくれる技術も進歩がめざましいです。

コード上に秘匿情報を持つべきではありません。
万が一流出した時にリスクになります。
ChatGPTなどに不用意に打ち込んでしまうとそれを学習し外部に漏れるリスクとなります。

そんな問題をgitleaksを使って解消しましょう！

• gitleaksの使い方
• どんなことができるか
• 実際に活用した例

本セッションではこのような内容のトークを予定しています！

生成系AIの勢いは止まりません
先日のOpenAI DevDayではGPT-4 TurboやAssistants APIなど更に出来ることや夢が広がったと感じました

一方で現状はCode InterpreterがPython前提になっていたり、
生成系AIの領域はPythonの領域のような感触もあります

そこで今回はインフラ構築、サーバーレスアーキテクチャ構築が得意なPHPerが
生成系AIのアプリケーションを作成する時にどのような選択肢があるのかを考えながら
実際にPHPの得意領域であるWebアプリケーションと生成系AIを組み合わせるサンプルアプリケーションを作成します

その中で感じたライブラリ選定まで含めた時の、プログラム言語の選択を含める課題感の共有を行います
今現状の課題感の共有と共に、皆さんと私自身の選択に関して議論できると幸いです

• お話すること
  • PHPerを中心に据えた時に生成系AIのWebアプリケーション構築
• 前提条件
  • PHP以外の選択肢も制限しません
  • 一部マイクロサービス化することも検討します
• 今回のトークに対する期待
  • 私のトークは答えではありません。しかし私の選択に対して皆さんと議論出来ると嬉しいです

フォーム等の入力があるシステムでは、必ず実装しなければならないバリデーション処理。
Laravelでは、標準で便利なバリデーションルールが定義されています。しかし、シンプルなチェックであれば実装は容易ですが、フォームが少し複雑になると、どのように実装するか悩むことも多いのではないでしょうか？

カスタムルールを定義して一からバリデーション処理を実装するのも一つの方法ですが、標準のバリデーションルールだけでも、ある程度複雑なパターンにも対応可能です。
今回は相関バリデーション（他の入力欄の値によって入力のチェック内容が変わる）の実装について、標準のバリデーションルールを活用して実現した方法を紹介します。

近年、急速に"(コードの)質と(それの高さからくる開発)スピード"が注目されるようになってきました。

一方で「何故、"質とスピード"を求めるのか」に対するお話はあまり見かけません。

このトークでは「孫子の兵法」から見た「"質とスピード"は何のために必要なのか」、「"質やスピード"は本当に必要なのか」についてお話します。

このトークで得られる知見

1. あらためて考える「なぜ"質やスピード"が必要なのか」
2. "質やスピード"を求める場合の基準
3. 組織人として持続可能な組織を維持するために考える事

このトークで話さない事

1. 孫子の兵法の詳解

DDDを始めるにあたってしんどい気持ちになるのが「事前に用意しておくべきドメイン層のコードが案外ある」こと。

また、DDDを中心に据えた場合「ドメイン層のコードがどうあるかは本質ではない」とされ、具体的な指標がなく座りの悪い状態になりがちです。

"TacDDD"（タックディー）はそんな「ドメインの話に集中したいので、極力コード側に注力したくない」をお助けするライブラリです。

このトークでは"TacDDD"を用いる事で何が省略できるのか、どんな所の「質」が向上するのかについてお話します。

なんとなく口にしがちな「"品質"が高いコード」。

定義があいまいで要領を得ないため、すり合わせはおろか万人が万人の「願望する"品質"」の話に終始してきました。

一方で「品質」は工業規格としての定義があります。

このトークでは工業規格の定める「品質」に基づいて、「"品質"が高いコード」の定め方と達成の仕方についてお話します。

このトークで得られる知見

1. "品質"の定義
2. "高品質"の達成の仕方
3. ユニットテストにおける"「どこまでやるか？」の割り出し方"
4. "品質"を高めるためのテストとは

このトークで話さない事

1. 品質工学

PHPUnitを利用していると、たくさんの単体テストが出来上がってきます。
段々と、「単なる単体テストの集合」を超えて、「あれしたい！これしたい！」という欲求が湧いてくることがあります。
テスト自体の運用・実行を考えてみたり、あるいは「プロジェクトの健全性にまつわるデータを収集したい」といった例は、枚挙に暇がないでしょう。

PHPUnitを拡張することで、より良い開発体験を手に入れられそうです。
PHPUnitには、「エクステンション」という仕組みがあります。
コレを利用することで、何が手に入るでしょうか？
このトークは、出来ることや実用例を紹介します

はなすこと

• PHPUnitのエクステンションってどんなもの？(全体感)
• どんなことができるの？世の中に存在する実例を見てみよう(OSSの詳解)
• 前提として、PHPUnitの動きやライフサイクルを知ろう
• エクステンションはどんな仕組みで動いてるの？(詳細)
• 実際に作って動かしてみる(コードとデモ)