トーク

Laravel開発でのフロントエンドとしても使用されるVue/Reactは、コンポーネントを分割して開発する手法が多く取り入れられています。
その際、コンポーネント単位での開発を可能にするStorybookを活用し、コーディングはもちろん、Visual Regression TestやUIレビューのような、コーディングの先の運用についても活用してみませんか？

本トークでは、Storybook開発元のSaaS「Chromatic」について、実際に導入して感じたメリットや、導入のハードルを突破する知見を共有し、フロントエンド開発をスピードアップする方法をご紹介します。

対象の方

• Storybookをもっと活用したい方
• VRT入れるの大変そうで手を出せてない方
• イケてるSaaSを入れたいけど、(セキュリティやコスト的に)うちの会社じゃ無理かな、という方

生成AIはときに新しい発見や、気づきを与えてくれます。

昨今話題のChatGPTを始めとした生成AIですが、みなさん使い方に迷ってませんか？
まずは身近なところから始めましょう、そうです、自分の登壇をまず分析しましょう。
ということで去年ペチコン(2022)の私の登壇「フィーチャートグルを使って素早く価値を検証する 早く安全に失敗し学ぶために」を題材にして
生成AIに分析させてみようと思います。

分析例

• Wisper による文字起こし
• GPTによる要約や評価
• DALL-Eを使った登壇内容からの画像生成
• Moderation を使って問題のある発言を検知する
• マルチモーダルによる分析
  聞いた人はきっと自分の登壇を分析したくなるはずです(たぶん)

ブラウザでクラウドコンソールをポチポチしてインスタンスを立てる時代は終息へ向かい、現在は IaC によって 「コードでインフラを構成する」 ことが一般的になってきました。

AWS CDK は AWS CloudFormation を生成するマルチ言語ツールですが、実は AWS CDK TF と呼ばれる、 Terraform に向けて出力を行うものが存在します。

今回は AWS CDK TF を使い、多くのクラウド(ローカル仮想環境含む)で利用出来る、 LAMP ベースの Kubernetes 環境をデプロイできるようにする事例を紹介します。

対象者

• IaC をプログラミング言語で書きたい方
• Kubernetes もプログラミング言語で構築したい方

MySQL や PostgreSQL は非常に安定した信頼できるプロダクトです。これまでの数々の実績を見てもそれは確実でしょう。

しかし、 IT 業界の規模が急速に拡大し、クラウドサービスが席巻している今、「1インスタンス1DB」を前提として設計されたそれらプロダクトには性能限界が来ています。つまり スケーラビリティの問題 です。
その問題を解決しようとしているのが Google Spanner や PingCAP TiDB などの NewSQL と呼ばれる新時代のリレーショナルデータベースです。
今回はその中でも TiDB に焦点を当てて、 MySQL や Spanner と比べたメリット/デメリットを実際に使って検証します。

対象者

• MySQL でスケーリング大変だ、と思っている方
• NewSQL(TiDB) の実力がまだわからない方

「なんで PHP をメインで書いているのに、 JavaScript(TypeScript) も一緒に書かないといけないんですか！ React ってなんですか！今は Svelte が良いって聞いたけどじゃあどれ使えばいいんですか！」

という問題を解決するかもしれないのが Laravel Livewire です。これを使えば、 PHP でフロントエンドのロジックを記述することが可能です。

今回は、 LaraconUS 2023 で発表された Livewire v3-beta と関連パッケージを使って、(ほとんど) PHP だけでフロントエンドロジックも実装してしまう技術を紹介します。

対象者

• JavaScript(TypeScript) しんどい方
• 「全部 PHP がいい！」という方

PHP はデータベース通信、ファイル操作などの I/O バウンドなユースケースで多く使われています。

これまでの PHP では I/O 処理でブロックし、処理が終わるまで待機する仕組みになっていましたが、 PHP 8.1 から Fiber がコア実装に含まれたことにより、 PHP でも非同期な処理をサードパーティ extension なしでより簡単に実装することが出来るようになりました。

中でも注目を集めるライブラリ群が amphp です。このライブラリ群は、 HTTP サーバや MySQL クエリの非同期化など様々な高レベル実装を提供しています。

今回は、現段階で実装済みの各ライブラリを紹介し、今後 PHP でも非同期処理を使いやすくなるぞ、ということを紹介したいと思います。

もし何かの間違いで採択されてしまったら
https://www.youtube.com/watch?v=F71zTEPwy5c
これのPHPerバージョンを頑張って作ってLT会場を温めます！出順はトップバッターでお願いします！

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

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

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

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

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

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

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

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

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

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

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

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

このトークでは、こういったMPA上のJSの処理をe2eテストによって楽にテストする方法を、Laravelにおける実装例をもとに解説します。

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

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

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

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

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

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

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

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

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

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

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

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

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

このトークでは、こういったMPA上のJSの処理をe2eテストによって楽にテストする方法を、LaravelおよびSymfonyにおける実装例をもとに解説します。

PHPカンファレンスに参加される方の中には、まだプログラミング未経験で、
これからPHPを勉強しようと考えているという方も多くいらっしゃると思います。

そんな方々へ向けて、アプリケーション開発に必須の知識である
データベースやSQLというものを、世界一分かりやすく解説します。

このトークのゴールは

• データベースという概念をなんとなく理解する
• 簡単なSQLを自力で書けるようになる

です。

私自身が「初心者の頃にこういう説明をしてほしかった…」と思うような
順序と言葉遣い、例示を用いて、本当に世界一丁寧に（当社調べ）解説します！
初心者の方の「データベースってなんだか難しそう」という印象を吹き飛ばせたらと思います。

※分かりやすさを優先して厳密さを多少犠牲にする場面があります。上級者の方はご注意ください。
※このトークはPHPに直接関連しない汎用的なトークとなっています。

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

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

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

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

コミュニケーションにおける「パス」について、「コミュニケーションパス」がまず頭に浮かぶと思います。

いわゆる、1対1のコミュニケーションがどれだけ発生するか？というコミュニケーションパスとともに、チーム間を跨ぐ場合に誰を経由してコミュニケーションするか？という経路としてのパスもあります。

個人的に、直接のコミュニケーションにおけるやりとりも「パス」(pass)することだと考えていて、相手にいいパスを出せるか？というのもチームコミュニケーションにとって大切な要素ではないでしょうか。

本トークでは、

• コミュニケーションパスの数
• 1対1のコミュニケーションにおける対話（パス交換）
• チーム間のコミュニケーション経路

というような、チームコミュニケーションにおける「パス」に着目して、私が大切にしている考え方を共有させていただきます。

ある日、「手動オペレーションに定評がありますね！」（意訳）と言われたことがあります。（全然ネガティブな文脈ではないので安心してください！！！！！！！！！）

特にプロダクトの初期フェーズにおいては、プロダクト自体の機能や価値提供のために、管理画面の開発などの優先順位が下がることがあると考えています。

運用フロー、提供フローが定まっていないうちに画面を作り込んでしまうなどが、「早すぎる最適化」になってしまうこともあるでしょう。

そのような事態を避けるためにも、作り込めるポイントがくるまで、安定した手動オペレーションを行うことはチームにとってもプロダクトにとっても大切なことなのかもしれません。

本トークでは、手動オペレーションを行う際に私がどのようなことを心がけているのか？という話を中心に、作り込めるポイントをどう判断しているのかをお話ししてみたいと思います。

コードの問題点は見た目には分かりにくいことがあります。

知らず知らずのうちに悪いコードが増え、気付いた時には『レガシーコード』と呼ばれるような状態になっているかもしれません。

そこで、問題点に気付くための1つの方法として、コードを計測する方法があると考えています。コードの計測によって得られる情報は多岐にわたり、コードのサイズ、重複コードの有無、コーディング規約の遵守状況、循環的複雑度、エラーの有無などが含まれます。これらの情報を分析することで、コードの状態を知ることができます。

ただし、計測した数値は必ずしもそれ単体で問題点を示す訳ではありません。そのため、他の数値と組み合わせたり、実際にコードと対比して判断・行動することが重要です。

本トークでは、特にコードをツールで計測することによって得られる結果に着目し、コードの改善にどのようにアプローチするかをお話しします。

Laravelには便利な機能がたくさんあります。

Eloquent、Facede、サービスコンテナ、認証、ミドルウェア、Blade、artisanコマンドなどなど…
さまざまな機能を活用することで、スピード感のある開発ができることは間違いありません。

ただ、それらにどっぷり依存することによる弊害も少なくないでしょう。
あまりにも依存しすぎると、ビジネスの変化への対応による作り直し、各機能のバージョンアップの際に思わぬ量のコード修正になってしまうことがあります。

そんなことを想定し、Laravelのコードからドメインのコードが独立するよう、主にInterfaceを利用してドメインロジック（＝わたしたちのコード）を切り出すことを心がけています。

Laravelでプロダクト開発を行う中で、どのようにしてLaravelのコードとドメインのコードの距離を保っているかを紹介させていただきます！