SymfonyのFormTypeはフォームの定義をバックエンドとフロントエンドで共有できる非常に強力なツールですが、
FormTypeの一種で<select>などの選択式フォーム項目の選択肢をエンティティと自動でマッピングしてくれる「EntityType」を使う際には、
パフォーマンスの面で気をつけなければならない点がいくつかあります。

特に重要なのは、N+1問題の考慮です。大量のレコードを持つエンティティに対して無造作にEntityTypeを使ってしまうと、しばしばN+1問題が発生し、意図せず大量のクエリが発行されてしまいます。

また、<select>のユーザー体験を向上させるためにSelect2やselectize.jsなどのライブラリを導入してインクリメンタル検索などを実現することはよくあると思いますが、EntiyTypeによってエンティティのレコード数だけ<option>を持つような<select>が出力されてしまうと、Select2やselectize.jsの初期化処理に数秒オーダーの時間がかかってしまい逆にUXが悪化するといったこともよく起こります。

Symfonyユーザーの多くがEntityTypeが持つこれらの問題に長らく苦しめられてきましたが、実はそれも今は昔。
Symfony UX Autocompleteというライブラリの登場でこれらの問題は完全に解決してしまいました。

Symfony UXは、Symfonyアプリケーションにフロントエンドの処理を簡単に追加するためのライブラリ群で、その中でも私の一押しがSymfony UX Autocompleteです。

このトークでは、上述のEntityTypeの問題をSymfony UX Autocompleteによって完全に解決するまでの手順と実際のユーザー体験の変化を具体的にお伝えします。

話すこと：
・Symfony UX Autocompleteについて
・EntityTypeが使われているSymfonyアプリケーションへのSymfony UX Autocompleteの導入方法
・Symfony UX Autocomplete導入前後のユーザー体験の変化について

話さないこと：
・Symfonyの基本的な使い方
・Autocomplete以外のSymfony UXライブラリについて

サービス運営を行う上で切っても切り離せない管理画面ツール。
必要ではあるもののサービス自体と比較すると相対的に工数をかけにくく実際そこまで凝ったものは必要ない、というのがよくある要求で、
そういった背景から*-admin系のライブラリが数多く生まれてきている一方、言語やフレームワークに依存する部分も多く、
既存のプロジェクトで使えていたものが新規プロジェクトでうまく使えず歯痒い思いをするといったこともあるはず。
そんな中、Slackアプリによる管理画面ツール開発は一つの答えになるはず...

Block kitを利用した効率的なviewの開発、Slack APIに機能を移譲することで得られるメリットなど、実際に運用する中で得られた知見を公開します。

ドメイン駆動開発でレイヤードアーキテクチャを採用するパターンが良くありますが、初学者にとっては理解し難いものです。見様見真似でなんとなく層に分けてクラスを設計してみたものの。。アレ？という感じになってたりします。

実際に遭遇したよく陥りがちな避けるべき実装パターンを例に上げて

• 何が駄目なのか？
• どういった設計にしていけばよかったのか？

をまとめてみたいと思います。

想定対象

• レイヤードアーキテクチャで悩んでいる方
• トランザクションスクリプトから脱却したい方
• ドメイン貧血症になってしまっている方

Garbage collection (GC) とは、確保したメモリ領域を適切なタイミングで解放する仕組みのことです。
PHP ではメモリの確保と解放が処理系によって自動的におこなわれるため、あまり意識することはないかもしれません。
しかしながら、メモリが比較的潤沢になった今でも、メモリ溢れによるサーバ障害は決して珍しくありません。
PHP における GC を理解し、メモリを意識したプログラミングをすることで、本番サーバを夜中に落とさないようにしましょう。

主な対象

• 普段メモリを意識してプログラミングしていないかた
• 言語処理系の内部実装に興味があるかた
• メモリ溢れで本番環境をダウンさせたことのあるかた

話すこと

• PHP における GC のアルゴリズム
• あなたが確保したメモリはいつ解放されるのか
• メモリ溢れを意識したプログラミング

話さないこと

• GC のパラメータをいじってカリカリにチューニングする

目標

• PHP でメモリがいつ解放されるのかを知る
• メモリを食い尽くす実装を避ける手段を知る

みなさんはクリーンアーキテクチャを理解している/知っていますでしょうか？
ドメインモデル, ユースケース, アダプタ, インフラストラクチャ...etc, はい、私は全くわかりませんでした。

ただちょっと視点を変えて、それぞれのレイヤーを擬人化してみると、最近なんとなくわかった様な気になることができました。
(例えば、ユースケースをプロダクトオーナー、インフラストラクチャをステークホルダーとした時に、実装について直接会話させると何が起きるのか → なんかアカンそう → じゃあどうするか など)

そこで本トークでは、みなさんにも自分と同じようにクリーンアーキテクチャを少しでも理解してもらえることを目標としてお話しできればと思います。

■ 話すこと

• レイヤーを擬人化してみるとどうなるか
• レイヤーを意識しないとどうなるか
• 依存関係(DI, DIP)について
• クリーンアーキテクチャを理解すると何がうれしいのか

■ 話さないこと

• クリーンアーキテクチャの深い話

■ ターゲット

• クリーンアーキテクチャ？なにそれ、おいしいの？という人
• クリーンアーキテクチャを理解するにあたって、とっかかりが欲しい人
• クリーンアーキテクチャでやっているが、なぜやっているのか分からない、ただの雛形にそって作業している人

■ 補足

※ 決してクリーンアーキテクチャ原理主義者ではありません、あくまでも一つの考え方、知識として持っておくと幅が広がると思い話します
※ クリーンアーキテクチャと書いていますが、なるべくXXXアーキテクチャ全般に通じる話にしようと思っています

私はこれまでビジネスロジックとドメインロジックをほぼ同じものとして捉え、ドメインモデルにビジネスロジックを実装することで業務知識を表現するような実装を意識していましたが、最近の開発の中でドメインロジックとビジネスロジックはレイヤーの異なる概念なのではないかと考えるようになりました。

この2つのロジックを区別し、ドメインモデルからビジネスロジックを追い出すことで仕様変更に強いドメインモデルを構築することが出来るのではないか、という考えを今回のトークでお話ししたいと考えています。

このトークでは、以下のトピックに関する僕の考えを共有することを目標とします

• ドメインとはそもそも何なのか
• ドメインロジックとはどのようなものなのか
• 何をドメインロジックとして扱うべきで、何を扱わないべきなのか

Laravelで多機能なアプリケーションをモジュラモノリスとして開発・メンテナンスしていこうとする時、Modelの依存は悩ましい点になっていると思います。AモジュールにあるModelがUserを、UserがBモジュールにある別のModelを参照してしまうと、結局疎結合にできず、メンテナンス時に依存を排除できません。
LaravelであってもORMとしてEloquentではなくDoctrineを使うことで、モジュール同士が依存しない、疎結合なモジュールによるモジュラモノリスが実現可能です。
実践的なモジュラモノリスLaravelのサンプルコードとともに、LaravelからDoctrineを使う実装についてご紹介します。

SPA全盛の時代ですが、まだまだ古き良きMPA（Multi Page Application）のシステムを触る機会は多いですし、
凝ったUIを必要としない社内システムなどでは、新規開発でもMPA構成を採用することは普通にあります。

MPAだとビューのテストは基本的にPHPフレームワークが提供してくれる結合テスト基盤を使って行うことになると思いますが、
結合テストで検証できるのはあくまでHTTPレスポンスの内容までで、その後ブラウザ上でJavaScriptを使ってある程度複雑な処理が行われる場合に、その部分をテストすることができません。

MPAであっても、一部の画面にだけちょっとしたDOM操作や非同期処理が必要になるケースは多く（例えばいいねボタンとか）、
このようなJSの処理は上記の理由から自動テストがサボられがちです。

このトークでは、こういったMPA上のJavaScriptの処理を楽にテストする方法を、LaravelおよびSymfonyにおける実装例をもとに解説します。
（例としてLaravelとSymfonyを取り上げますが、他のフレームワークにも容易に応用可能な内容です）
既存のMPAに後付けで簡単に導入することが可能なので、すぐにでも実務に活かせる内容になると思います。乞うご期待。

現代では「動的な」ウェブサイトを作ることが当たり前になっています。しかしなぜ「動的」なものを作らないといけないのでしょうか。

「ウェブサイト」とは、かつてはサーバー上にある静的なドキュメントにアクセスするためのものでした。
しかし、CGI の開発により動的なコンテンツを扱うメディアとして進化を遂げていきます。

HTML 内で動的な値を表示することができる「ページインライン」モデルの PHP が生まれ、
データベースと接続したウェブアプリケーションが普及していきます。
全世界のウェブサイトの多くが WordPress によって作られるようになっていきました。
今は動的な値を扱うウェブサイトにおいて、いかに早くユーザー体験を損なわずに必要な情報を届けられるかの工夫がされるようになります。

本発表ではそうしたウェブサイトの歴史的背景に加え、動的なウェブサイトにおける課題と改善のために生まれた技術・手法について触れ、今後のウェブサイト・ウェブアプリケーションの開発動向についても考えていきます。

新しく入社した会社で任される仕事は既存のシステムの技術的負債の返済。このような経験をほとんどの方が受けているのではないでしょうか。
「なんて醜いコードなんだ」と思ったり「こんなコード，メンテナンスしたくない」と思う時もあるはずです。

さらに言えば「なぜ初めからもっと丁寧に書けるエンジニアを採用しなかったのか」と思うこともあるでしょう。
そして「自分はこのようなコードを絶対に書かないぞ」と決心するはずです。

しかし，技術的負債は，なぜ生まれるのでしょうか。「採用力がなかったから」「経営陣の実力不足」「経営陣がエンジニアへの理解に乏しいから」など様々な理由を思い浮かべるはずです。
また，技術的負債を作った当人達は，人事評価で好印象を与えやすく，逆に後から入社したエンジニアは技術的負債を返済し，堅牢なアプリケーションを作っているのにも関わらず，満足行く人事評価を得られないことがあるなどして，軋轢が生まれやすところです。

技術的負債が生まれないようにするには，技術的負債が生まれる理由を知らなければ根本的な解決は望めません。
本トークでは，CTO という経営に近い立場から，技術的負債が生まれる原因を解明していきます。

そして，本トークを経て，オーディエンスの皆様が技術的負債と前向きに向き合うキッカケの一つになれば幸いです。

※本トークは，PHP に関連するトークではなく，汎用的なトークとなっています。

昨年11月のPHP TechCafe、『PHPerのための「PHPフレームワーク」を語り合う』でLTした、『それぞれの特徴から考えるフレームワーク選び』。それをもうちょっと深掘りし、今までWebアプリケーション開発で経験して感じた"Laravel", "CakePHP", "Symfony"それぞれのフレームワークの特徴と適している利用シーン、今後のプロダクト作りのフレームワーク選定する際に注目するポイントについてお話しします。

LT時のスライド：
https://speakerdeck.com/ippey/soresorenote-zheng-karakao-eruhuremuwakuxuan-hi

お話しする内容

• 各フレームワークの特徴、利点と欠点
• 実際に開発した際に感じた、恩恵と弊害
• フレームワーク選定時に注目したいポイント

発表者のチームではPull Request毎にProduction同等の動作確認用の環境を自動的に生成してリリースサイクルをスムーズに回せるようにしています。
GitOpsを用いたシンプルなインターフェイスと通知によって、デザイナーなどの非エンジニアでも簡単に利用できる工夫があります。
本発表では、その工夫について紹介するとともに、発生した課題に対してOSSを開発したり、ArgoCDに機能追加をした話を交えてお話します。

gRPCというワードを聞いて、「何から始めればいいの？」「何がメリットなの？」「REST
APIでよくない？」という疑問が浮かぶ方に向けて、gRPCの基礎から具体的なアプローチまでお話します。
gRPCの概要をはじめ、gRPCを活用したWebアプリケーション開発を中心にフロントエンドからバックエンドまでの実装における実践的なポイントについてお話します。
私自身もほんの数ヶ月前までgRPCが全くわからなかった人間なので、「大丈夫！gRPCは怖くないよ！」ということがお伝えできれば幸いです。

【トーク予定内容】

・ gRPCの概要
・ 各レイヤー(フロントエンド/バックエンド)の実装方法
・ 周辺ツールの紹介
・ 成功体験/失敗体験

など

以前まで PHP で非同期処理を扱うためには様々な制約をクリアする必要がありました。しかし，昨今の PHP では非同期処理を容易に扱うためのライブラリである Swoole や，parallel，PHP 8.1 からビルトインされた Fibers などがあります。
しかし，そもそも非同期処理とはどういったものなのでしょうか。非同期処理を調べていくと並行処理や並列処理，マルチスレッドやマルチプロセスなど様々な単語が出現しますが理解するのもハードルが高いと感じる方もいらっしゃるかと思います。
本トークは初級者から中級者向けに非同期処理について，拙著「Swooleで学ぶPHP非同期処理」からいくつか引用・補足し，非同期処理の基礎から PHP で非同期処理を実現する方法をお伝えします。

ChatGPTやGitHub Copilot Xなど、今年に入ってさらに熱くなってきたAI業界。
今年からGitHub Copilotを使い、AIと一緒にプログラムを書いていますが、私たちの仕事にも大きな変化が訪れる気配を感じます。

今セッションでは、PhpStormとGitHub Copilotを使ったライブコーディングを行いながら、AIと協働するメリットや気をつけるべき点などをご紹介します。

超強力な統合開発環境 PhpStorm
今や多くの PHPer にとって無くてはならないエディタでありIDEであることに疑いはありません
多機能であるがゆえ、「えっ、何そんな便利機能があるの？知らんかった！」がまれによく発生します

PhpStorm を使い始めてそろそろ12年 (マジかよ) になりますが
まったく使いこなせている気がしません

ライブで「こんな機能あるんだよ」を紹介しますので
おおーなどと反応したり
こんな機能もあるぞーなど紹介(ガヤ)してほしいです

(ショートカットキーの話はしないです)
(PhpStorm を使っていない方はその便利さに圧倒されてください)

2018年のPHPカンファレンス関西で発表した「すばやく実装するための戦略とテクニック」から5年、「速さは力」をモットーに相変わらずスピードを出してコードを書いています。
自分では「長く在籍してドメイン知識がついたせいでは？」と思っていましたが、副業に行っても、転職しても、やはり「プルリクが光速」「レビューが追いつかない」と同僚から褒められたりクレームを言われたりします。
文系ですし、20代半ばで初心者からPHPを始めた身なので、才能があるわけではありません。
速さを実現するために積み重ねている工夫や使っているテクニックを、2023年現在の内容にアップデートしてお伝えします。

マネジメント、「私には無理」とか「億劫だな、やりたくないな」と思っている人も多いでしょうか？
その一方で、組織は何かしらの期待を持って、プログラマーに対して「マネジメント職をやってほしい」と依頼をしてくる事があります。

さて、最近では「マネジメント」というと「1on1をしよう」という話がありませんか。
そして、「1on1」と聞くと「コーチングを〜〜」という単語も、関連して想起されることがあるのではないでしょうか。

では、「1on1」「コーチング」という言葉から、何を思い浮かべますか？
あるいは「良い1on1」「良いコーチング」を自分の言葉で説明できるでしょうか。
私は、プレイヤー→リーダー→マネジメント(8人程度)→マネジメント(15人程度)→ジュニアなマネジメントも対象に含むマネジメント(35人程度)と、職務上の役割がシフトしてきました。
それに備えて、パーソナルコーチングのトレーニングを受けたり、組織開発や臨床心理学の領域に近いような学習も進めています。

そんな経験の中で、個人的には「コーチングのマインドやスキルを知ることで、良かった・明らかに役に立っている」と感じています。
本トークでは、主観的な経験を踏まえて「なぜ、どうやって、どうして役に立ったのか」をシェアしていきます

本トークの想定聴衆

• マネジメント職を担う(これから取り組む)上で、人と向き合う「難しさ」を感じている人
• コーチングという言葉は知っているが、それが何をもたらすのか・どういった概念なのかを知らない・興味がある人
• メンティーの立場から「効果的な1on1を実施できていない」と感じている人

本トークのねらい

• マネジメント(する側・される側)における、「幅」を増やして、苦しさや辛さを少し軽減する
• いち個人と向き合って、その人のエネルギーを充実させることの楽しさを知ってもらう

免責

• 発表者はコーチングのトレーナーとしての訓練を受けているわけではなく、プロとしてコーチ業を提供している訳ではありません
  • そのため、本セッションは「コーチングのやり方」を提供する事は目的としません

Composer大好きな皆さん、その愛をもっと強い形でぶつけてみたいな〜と思ったことはありませんか？
好きなものを自分のものにするには、やはり作ってみるのが1番ですよね。
既に高い完成度で存在しているComposerを、コレを機にわざわざバラバラにして再発明してみましょう！

このトークのねらい

• Composer内部の主要な概念/実装についての解釈を進めて、理解を深める
• それによって普段使っているツールの気持ちをちょっと理解する

このトークで得られるもの

• (Packagist等のリモートや、ローカルファイルなどの)レポジトリ情報・パッケージ情報の内容を理解できる
• それらを扱うためのプログラムとしてのComposerの仕組みを理解できる
• PHPのautoloaderの設定方法について理解できる

やること

• composer install や composer dumpautoload の「端折った」実装を行い、解説します
• そのために前提知識として必要な概念の解説をします
  • Composerのレポジトリ
  • Composerのパッケージ
  • PHPのオートロード
  • PSR-4

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