トーク

「バグやエラーだらけのソフトウェア」は、開発運用していて大変ですよね。
何をしてもどこかが壊れている、増え続ける問い合わせ‥そんな状態を抜け出したい！と思ったことはありませんか？

エラーやバグの退治に取り組みましょう。
「健全化」されたアプリケーションは、チームの自信や誇りに繋がります。
泥沼から、どうやって一歩を踏み込んで行くかを話します。

お届けしたいこと

• 「なぜエラーを減らしたいか」の理論的な背景、根拠となりそうな情報
  • エラーやバグがもたらす不経済
• 検知や修復を急ぐべき理由。遅れがどんな悪影響をもたらすか
• 組織としてエラーをどう減らしていくか・進め方
  • チーム一丸となって”エラーを減らす”ためのステップ
• エラー管理ツールの活用
  • Sentryを想定

話さないこと

• アーキテクチャや「良いコード」といった品質面の話

先行きの不透明な開発プロジェクト。
鳴り止まない障害アラート。
挙句の果てに、リリースした機能がユーザーにあまり使われていない！
そんな課題を解決すべく、ごく普通の PHPer がある日突然スクラムマスターに任命されて...！？

エンジニアがスクラムマスターに任命される。
まれによくあるイベントです。

このセッションでは、

• スクラムとは何か
• 冒頭で挙げた課題に対して、スクラムではどのように立ち向かうのか
• エンジニアとしてどのような能力をスクラムマスターに活かせるか
• 逆に注意すべきポイントは何か

といった内容を、 PHPer からスクラムマスターに転身した自分の体験を踏まえて紹介します。

定期実行を安定的に行おうとすると意外と考えることは多いですよね

私たちが提供しているサービスの裏側では毎日数百のコマンドが定期実行されており、その安定化に日々頭を使ってきました

本セッションでは、そんな私たちが遭遇した様々な定期実行に関する問題とその解決法、たどり着いた現在の構成に関してお話ししたいと思います

昨今、RDBMSを用いてサービスを作ることは非常に多くあると思います。

堅牢なテーブル設計を行っておく事は非常に重要で、バグが生まれづらくなったり仕様変更にも強いなど得られる恩恵は多いです。
逆に複数の関心事が集まったテーブル設計を行ってしまった結果、データを取得する為のSQLがややこしくなったり、仕様変更に弱くなる事も多くあります。アプリケーションと比べてデータベースは寿命が長く、その頃にはリファクタリングすら着手する事が難しいという事も多いですよね。

本セッションでは、データモデリングを学んでいなくても致命的な問題が起こりづらいテーブル設計手法について大規模WebサービスのDBリファクタリングをやった経験を踏まえて紹介させて頂きたいと思います。

なんか純粋にSymfonyの好きなところをお話ししたいなーって思いました。

PHPのフレームワークはたくさんありますが、その中でもぼくはSymfonyが好きです。
Symfonyの好きなところを20分かけてお話しします。
みなさんにSymfonyって面白そうだなー、さわってみようかなーって思ってもらえるようがんばります。

プロジェクトマネージャー、なりたいですか？

いわゆる「PM」は「プロダクトマネージャー」と「プロジェクトマネージャー」の二つを内包することが多いですが、ここでは後者の「プロジェクト」をマネージする（なんとかする）人についてです。
前者の「プロダクトマネージャー」はPdMなどとも呼ばれ非エンジニアがなることも多いですが、プロジェクトマネージャー（以下PM）はエンジニアが担当することも多いのではないでしょうか。

プロジェクトには数日で終わるものも、数ヶ月かかるものもあるかと思います。最初は単に小さなタスクをこなしていたエンジニアがどうやったらPM（＝プロジェクトを"なんとかできる"人）になれる能力がつくのでしょうか？

本セッションではPMの仕事内容と、それに対応するスキルセットの身につけ方についてお話しします。

【注】会社によりPMの職務範囲は変わるので、私の観測範囲内でのお話です

エンジニア教育を事業としてやって一人エンジニアを2年やってきました。
その中で、

1. ユーザーの方が困ったこと
2. 運営としてやってみたこと
3. 現場に入ってもらう上で解決したこと

ということがいくつかあります。その辺りを共有することで、

1. エンジニアという職種を楽しめる人が増えること
2. 新卒教育で気をつけてもらえること

が進むのではないか？と考えていることをお話しします。
「リードエンジニアいねえ！」問題を解決する足掛かりになればなぁと思います。

Laravelでアーキテクチャをしっかりと決めずに開発を進めてしまった結果について話します。

• どの程度ルールを決めていたのか
• どの程度アーキテクチャをゆるふわしていたのか

と開発の変遷をお話しすることでだんだん 「疎結合で変更に強いアプリケーション開発」から離れる開発になっていくフローがどのようになるのかがわかるように話そうと思います。また、その結果支払うことになったコストがどれくらいなのかをまとめて話します。

PHP 8.1 から Fibers が導入されました。それ以前の非同期処理といえば、Swoole などが筆頭になっていました。
非同期処理ライブラリが PHP にビルトインされるのは PHP に革命をもたらしたと言っても過言ではありません。
しかし、Fibers ではできないこと、Swoole でできることなど、実際には分かれています。
そこで、Fibers と Swoole の違いはなにか、それぞれの使い方を広く浅く本トークで解説します。

PHP に FFI が導入されてから、どういう用途で使えばよいか悩んでいる PHPer も多いかと思います。
PHP FFI を介したモジュールの呼び出し方から、自作 の C/C++ のモジュールの作成から呼び出し方、
そして libusb と呼ばれるモジュールで USB で接続された機器の一覧を取得する方法など、どのように FFI を活用していけばよいのかを本トークで解説します。

重たい処理をキューに任せることで、早めにレスポンスを返すことが可能です。しかし、Laravel 標準のキューサーバーの処理速度にはある一定の限界があります。
弊社では、1 回あたり数十秒かかるような処理をキューに任せているのですが、キューが積まれすぎて処理しきれず破棄されるといった事象が起こっていました。
Laravel には Laravel Horizon と呼ばれる並行並列でキューを処理ができるライブラリがあるのですが Redis のみのサポートで、弊社では Amazon SQS を使用しているため、導入には至りませんでした。そこで、Amazon SQS 向けに Laravel のキューサーバーを自前で実装し直し、処理速度を 4 倍に向上させました。
どのように処理速度を高めるのか、そのテクニックのご紹介と実際のプロダクションへの投入、得られたパフォーマンスなどを本トークでお話します。

B+木というデータ構造をご存知でしょうか？RDBMSでよく採用されているデータ構造で、ディスクの効率的な利用や、検索を行いやすいなどの特徴があります。しかし、耳学問で聞いてみてもイマイチ特徴がピンと来ないのです。

本トークでは、PHPでB+木のデータ構造を実装して、RDBMSでB+木が採用される理由、インデックスの構造的な仕組み、何故検索が速くなるのか？などなど、データベースの仕組みの根幹を覗いてみましょう。

このトークでお話すること

• B+木の特徴
• B+木は何故ディスクの利用効率が高いのか
• インデックスとは何か
• なぜ、データベースはB+木を採用しているのか

みなさんはデータベースクエリのパフォーマンスを意識して実装されていますでしょうか？
実装した当初は軽快に動いていたアプリケーションもサービスの成長とともに少しずつ遅くなっているかもしれません。あるタイミングで最適化プロジェクトを発足させたり、日々のコードレビューで指摘し合う際に役立つヒントをお届けできればと考えています。

このトークではデータベースクエリ最適化のヒントをサンプルコードを交えて解説いたします！

こんな方におすすめ

• 業務でLaravelを利用されている方
• サービスが成長してきたので、クエリの最適化をしたい人
• 日頃からパフォーマンスを意識した実装をしたい人

LaravelのEloquentモデルイベントって何？という人も多いかもしれません。私も知ったのは去年くらいで、それまでは知りませんでした。

このモデルイベントは、モデルでcreate、save、delete,、updateなどの操作をした際のイベントを指しています。そして、これらのイベントを実行する際、合わせてなんらかの処理を行わせたい場合に使用します。
例えば、モデルのデータを新規作成する際にはdateカラムに現在の日付を初期値として入れたい時などに使用します。

他にも実際にどのようなケースでモデルイベントを使用するケースがあるのか、モデルイベントの注意点などを話していきます。

途中から入ったLaravelでの開発プロジェクトで様々なコードのリファクタリングを提案していった話をします。
例えば、外部サービスを使っているロジックはServiceクラスに切り離し、ビジネスロジックはModelに切り離しました。
その他には、データベースtransaction処理の可読性向上。返却するステータスコードの整理。定数などになり得る箇所はEnumに移動。
ルートモデルバインディングの活用など。
このように様々なケースでのリファクタリングの例をお話します。

「完全に理解した」から「なにもわからない」へのステップアップ目指します。
https://bit.ly/3JldwsX

Laravelは初学者の敷居がとてつもなく低いフレームワークです。豊富なスターターキットや書き方の自由度の高さ故、小規模のアプリケーションなら未経験からものの数時間で作れてしまうことでしょう。

一方、いざ案件で本格的に使おうとした途端に戸惑う方も多いように感じます。PHP熟練者の方でもフレームワークのベストプラクティスが解らないまま「愚直なphp」でつい苦労してしまうことが多いのではないでしょうか。

これら解決方法はLaravelの公式ドキュメントには紹介されていません。
（最初のとっつきやすさに大きく比重を置いて書かれているためです！）

「完全に理解した」後、Laravelの持つ豊富な機能を深く知るにはどのような手順を経ていくのか、それをご紹介していきます。

はじめてPHPUnitを使ってみたいという方，依存性注入という言葉を初めて聞いた・どこかで聞いたことがあるという方に対して，初心者が初心者なりに頑張ってテストを書いてみたり，依存性注入について理解してみようと試行錯誤してみた過程とその中で思ったこと，学んだことについて語りたいと思います．
私はまだ学生という身分ではございますので，職場で使える小技などといった内容にはなり得ませんが，初めてPHPを使ってみた方がテストを書くためのPHPUnitというツール，そして依存性注入というものについて知ってほしいという気持ちで発表を行いたいと思います．

皆さんはどのようなスタイルでLaravelアプリケーションを開発されておりますでしょうか？今回はディレクトリを業務関心に応じて区切り、その中にクラスを配置して開発していくスタイルをお伝えしていきます。これを行うことで、疎結合で変更に強いアプリケーション開発がしやすくなります。フレームワークに対しても疎結合な実装を目指していくことで、Laravelのバージョンアップにも追従しやすくなるかと思います。

昨今PHPでHTMLをレンダリングすることは少なくなり、SPAとrest APIを使ったクラサバ構成のwebアプリケーションが増えてきました。
そこで問題になってくるのは、双方のインターフェースを担保するのをどうするかというところです。
Rest APIのIDLとしてOpen API specificationを用い、IFを担保するケースは多いと思いますが、どうしても運用メンテに工数がかかってしまいます。

今回Laravelを用い、1行コードを追加するだけでOASのファイルを吐き出せるようなライブラリを作ったのでその紹介をさせてもらいます。

Nuxtを使いクライアントから呼び出す方法、ないしはmswを使ってサーバーレスにAPIモックを作る方法も紹介させていただきます。

Event SourcingはCQRSとの組み合わせだけでなく、そのエッセンスは様々な仕組みに取り入れることができます。
マイクロサービスアーキテクチャ化、大規模なデータ処理の改善、
リアクティブシステム構築などではほぼ必須のテクニックとなりますが、
ネット上にある記事を鵜呑みにしてしまうと致命的なアンチパターンに繋がってしまうことも多くあります。
状態をもたせないイベントでマテリアライズドビュー化してしまう、
巨大なランタイムを持たせてしまったハンドラ、
分割しすぎて時系列を無視したイベントなどなど。
いくつかは実際にやってしまったこともありますが、体験や例をもとに
Event Sourcingとは何かを説明しながら、何をすべきでやるべきでないのかを楽しくお伝えします