「推測するな、計測せよ」という言葉は、改善策を探す時だけでなく、新機能をリリースする時も同様で、「計測」することは重要です。
開発環境の少量のデータを扱う場合は問題なく動作するクエリも、本番環境の大量のデータではパフォーマンス低下し、スロークエリになる可能性があります。
今回は、フィルターによる約160万行削除とNested Loopのトータルコストが約12万、実行時間が約600msかかるクエリを、サブクエリを活用し、Nested Loopを無くし、実行時間を約0.2msに改善をした事例を取り上げます。

話すこと

• 実行計画の解読：EXPLAINコマンドの理解
• 実際に行った対応
  • 本番レコードの調査
  • どのようにクエリの再設計を行ったか
  • INDEXの再考

注意：このトークではPostgreSQLを使用しています。

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

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

対象の方

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

ブラウザでクラウドコンソールをポチポチしてインスタンスを立てる時代は終息へ向かい、現在は 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 がいい！」という方

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の概要を知っていただき、少しでも興味を持っていただければ幸いです！

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

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

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

本トークでは、

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

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

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

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

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

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

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

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

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

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

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

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

「マイクロサービスは銀の弾丸なのでは・・！？」以前の私はそう考えていましたが、現実は甘くありませんでした。

今回のトークでは、PHPやRailsでゴリゴリにモノリシックな開発に飽きつつあった私が、ゴリゴリにマイクロサービスな開発をする環境に移ってどのような学びを得たかをお話しします。

・経験の前後でマイクロサービスに対して感じたギャップ
・今更感じる、マイクロサービスの長所と短所
・運用の難しさ（複雑性やトラブルシューティング） ※特にフォーカスしたい箇所

これらのテーマに添いつつ、今の会社に移ってから肌で感じた「マイクロサービスアーキテクチャによるプロダクト開発のリアル」を共有し、お互いの学びの場になればと考えています。

※本トークでは、特定のプログラミング言語やライブラリ、フレームワークを深掘りする話はしませんが、私のさじ加減で組織・チームの話は入るかもしれません。

Google Apps Script（以下、GAS）とはGoogleが提供するローコードプラットフォームです。
単なるJavaScript実行環境にとどまらずGoogleの提供する各種サービス（スプレッドシートやフォーム等）との連携を容易に行えたり、動的なWebページを表示できたりと、まさに「ローコードプラットフォーム」と呼ぶにふさわしい機能を備えています。

何が正解かわからないビジネスの世界において、誤った方向性でプロダクトを作り込んでしまうことを避けたいもの。
そのためにコストをかけずにプロトタイプを作って仮説検証のサイクルを回す必要がありますが、GASの備える特性はその際の強力な助けとなります。

本トークでは、その際に知っておくと役に立つ

• GASでできること
• GASを使うときのコツ、Tips
• GASの限界、使うべきでないところ

についてお話します。

コロナ禍をきっかけとして、テレワークを導入した企業は珍しくないでしょう。
テレワークは働きかたに様々な利点をもたらしてくれた一方で、新たな問題をもたらした側面もあります。

私たちのエンジニア組織は従業員どうしの関係性や勉強会等の活発さといった文化を強みのひとつとしていました。
そして、テレワーク導入直後にはその強みがほとんど見えなくなっていたのです。
もともと組織文化醸成の役割を担っていた「開発組織活性チーム」は、この問題に対して活動内容をテレワークに適応させるための試行錯誤に舵を切ります。

本トークではそこからおよそ 2 年にわたる「開発組織活性チーム」の取り組み内容と、それによって実現できたこと、できなかったことおよびそれらの考察をお話します。

「ユニコーン企業のひみつ」「チームトポロジー」の翻訳もあり、エンジニア組織の形態についての発信が増えたと感じます
主にはシニアテックリードやCTO・VPoEの視点からの、組織全体レベルでどうデザインするか？が多いですよね

コミュニケーションやチームに関する課題は、もっと卑近な単位でも発生します
仕事をうまく行かせるための大〜小の組織づくりについて、学んでみませんか？
「組織パターン」は、発売は10年ほど前ですが、組織に関する知見がパターン・ランゲージ形式で纏められた1冊であり、多くのヒントが得られるはずです

本トークは「ちいとぽよりも小さく、明日から使える組織づくり」を主眼に、書籍の内容・使い方を、実際の活用経験を交えて紹介します

対象

• 全体までは見ていないが、組織について考えている人
  • チームリーダーやEMなど

※諸事情により参加できなくなったため、プロポーザルを取り下げます。申し訳ありません。

Fiber は、PHP 8.1 から導入された stackful な coroutine です。
ここで一度、Fiber の実装を PHP の処理系レベルまで追いかけることで、Fiber が何であるか、そして、裏で何をしているのかを理解することにしましょう。

主な対象

• 非同期処理の内部実装に興味があるかた
• 言語処理系の内部実装に興味があるかた

話すこと

• PHP における「Fiber」とは何か
• PHP の VM (virtual machine) のおおまかな構造
• Fiber を実行・停止・再開・中断したとき、PHP VM に何が起こるか

話さないこと

• Fiber を裏で利用するライブラリやフレームワーク

※諸事情により参加できなくなったため、プロポーザルを取り下げます。申し訳ありません。

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

主な対象

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

  話すこと

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

  話さないこと

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

不正アクセスが怖くて夜しか眠れない、情報流出のニュースを見るたび不安で寿司しか喉を通らなくなる、
Webエンジニアはこういった日々を過ごしていると思います。

このセッションではLinuxの機能 AppArmorを用いて、PHPアプリケーションのセキュリティを外側から強化する方法を紹介します。

自分達が書くPHPコード自体の脆弱性だけではなく、フレームワークやライブラリ、またHTTPサーバー自体の脆弱性もカバーできる便利な機能です。
OSの機能でアプリケーションに対してファイルシステム・ケーパビリティ等の制限ができ、設定ファイルを用意すれば使えるため採用の手間も大きく有りません。

お客様のデータを預かるWebサービスでは信頼が第一、まだ使われていない方も使おうと思えるよう、具体的な設定例も踏まえて説明できればと思います。

【想定対象】
バックエンドエンジニア、インフラエンジニア

「良いプロダクトを作るためにもっとエンジニアとビジネスサイドで協力していきたい！！」
その想いを胸に半年前からスクラムを使ってプロダクトを作っています。

それまではエンジニアとビジネスサイドが同じチームで深く関わって仕事をすることがあまりありませんでした。
スクラムを入れる上でコミュニケーションの取り方をガラっと変えたかったのですが、ちょっとハードルが高いかもな、、と感じました。

そのため最初は敢えて「不完全」な形式でスクラムを始めました。
スクラムの良さをチームで実感するにつれて、徐々に「完全」なスクラムになっていきました。
そして今は「チーム全員で良いプロダクトを作っている」という感覚があります。

本トークでは、どのようにスクラムの体制を改善していったのか実体験をベースにして紹介します。

このトークの対象

• スクラムに興味がある人
• 組織的な課題でスクラム導入に悩んでいる人

フロー効率という言葉を最近耳にしたことはありますか？
その対比としてリソース効率が用いられているのを目にしたことはありませんか？

このトークでは「フロー効率」と「リソース効率」という言葉をキーワードに

1. フロー効率が良くなると何が嬉しいの？
2. リソース効率を追求するとどうなるの？
3. 仕事をする上で２つの効率とどう向き合う？

という３つのテーマを使って、我々開発者を取り巻く環境における事例を交えながら人間にとって最も重要な資源である「時間」について深掘りしていきます。

タイトル見て共感した人、このトークのターゲットです。
データベースにおいてインデックスとは超重要な要素の1つです。
適切にインデックスを貼ることで処理を効率よく行うことができます。
「なんかよく分かんないけどじゃあとりあえず全部にインデックス貼っとくか」
これはアンチパターンです。
何故闇雲にインデックスを貼ってはいけないのか、適切にインデックス貼るとはどういうことか
実際に計測したデータを交えながらお話したいと思います。