私が担当しているメール共有サービスのメールディーラーは2024年10月に「AIクレーム検知オプション」をリリースいたしました。
「AIクレーム検知オプション」の開発に当たり、メールディーラーの史上初となるβ版をコンテナで構築して、
お客様に実証実験ご協力をいただき、ChatGPTで判定しているクレーム検知の精度向上を行いました。
そしてコスト削減やパフォーマンスの分散化を狙い、製品版をAWSで構築することで、
クレーム検知の精度を実用レベルまで向上させ、約65%のコスト削減に成功しました。
AWSの導入にあたって、どのように目的を整理し、利害関係者を説得したのか?どのようにして目標を達成したのか?
将来的なアーキテクチャの構想も含めて、メールディーラーのテクニカルリーダである私が可能な限り具体的に事例を交えて説明いたします。
AWSやコンテナは新しい技術ではありませんが、2001年にローンチしたメールディーラーにとっては違います。
メールディーラーは全機能がひとつのサーバに実装されており、WebサーバとDBですらひとつのサーバに集約されています。
また、フレームワークを導入しておらず、DBアクセスからprint文によるHTML出力が、1つのPHPファイルに実装され、
プログラムの陳腐化が急速に進んでいます。
その一方で市場開拓の必要性から新機能を定期的にリリースすることが求められています。
さらにLLMに代表されるAIブームがメール共有市場にも影響を及ぼし始め、
LLMを「導入していることがメリット」だったのが「導入していないことがデメリット」に変わりつつあります。
AIブームを背景に、ChatGPTを活用したクレーム検知機能をAWS上で構築し、無事リリースに至りました。
本セッションを通じて、新しい試みを試す参考になれば幸いです。
Laravelの監査ライブラリ「Laravel Auditing」は、Eloquentモデルでのレコードの作成、変更、削除を詳細に追跡する強力なツールです。しかし、Query Builder経由の操作は監査対象外のため、重要な変更が見落とされるリスクがありました。
私たちのチームでは、この課題を解決するため、Query Builderによるレコードの作成、編集、削除も監査ログに残せるように拡張を行いました。
本LTでは、以下の内容をお届けします。
・Query Builderの操作をログに含める必要性
・Laravel Auditingの仕組みを理解するポイント
・Query Builder操作のログ拡張方法(実装の工夫や設計の考え方)
・拡張後のメリットと運用のポイント
これにより、監査ログが取りこぼされるリスクを大幅に低減させ、システムの透明性と信頼性を向上させる方法をご紹介します。
EloquentとQuery Builderの両方を活用するチームにとって、日々の開発に役立つ内容をお届けします。
対象者
・Laravelを使ってシステム開発を行うエンジニア
・Laravel Auditingを導入している、または導入を検討しているチーム
・EloquentとQuery Builderを併用して開発を進めている開発者
Promiseについて、「分からん!」から「そんなものもあるんだ」を経て、「そういう風になっていて、そう動くのか」に至るためのトークです。
Promises/A+の世界観や、概念レベルの「何を課題とし、どう解決を試みるパターンなのか」の共有から入り、
PHPでの実装例を参考にしながら「こうやるんだね」を見ていきましょう。
最後には、低機能で愚直なPromiseオブジェクトを生み出す所まで話を進めます。
PHPを利用した普段の開発では、 Promise を目にすることはあまり無いかも知れません。
しかし、ライブラリの中身などを読んでいると「意外と出てくるよな」と私は感じました。
guzzlehttp/promisesやreact/promiseといったPHP実装が、しばしば登場します。
コイツと仲良くなれたら、少し幸せになれるのではないか…?と感じたので、解剖してやろうと考えたのです。
特に、「Guzzle使っていてPromiseクラス出てきたけど良くわかんないで雰囲気でやっているなー」という人には役に立つはずです。
Promiseパターンについて興味がある人に向けて、概念の説明とPHPでの実装例を示します
このセッションではPHPで作成したアプリケーションをVercelにデプロイする方法を紹介します。
Vercelは「Vercel のフロントエンド クラウドは、開発者にフレームワーク、ワークフロー、インフラストラクチャを提供し、より高速でパーソナライズされた Web を構築します。」(X:@vercelより引用)で、PHPのイメージはありませんが、PHPのアプリケーションをデプロイすることができます。
また、VercelにはVercel PostgresというPostgreSQL(データベース)を提供するサービスもあります。PHPとVercel Postgresを用いてアプリケーションを作成し、Vercelで公開することができます。
このセッションでは、VerceでPHPを用いたアプロケーションを公開する方法とVercel Postgreの紹介をします。
PHPフレームワークとして広く採用されているLaravel。その最初のコミットは 2011年6月8日 のことでした。
それから約14年。Laravelは進化の過程で何を大切にし、どのような機能追加を重ねてきたのでしょうか。
本トークでは、ChatGPT、Claude、Geminiを活用し、14年分のGitHubのコミットメッセージを分析。Laravelの設計思想の進化を取り上げます。
特に以下の観点から解説します:
生成AI時代だからこそ、コードを書くだけでなく「なぜそのような設計を選んだのか」を理解することが求められる今日。
先人たちの試行錯誤から、私たちの開発に活かせるアイデアの種を見つけましょう!
私はコミュニティ活動として、PHPTeaNightというオンラインイベントを定期開催しています。
その会でPHPStanをテーマとして参加者の方からいただいたPHPStanとの向き合い方がとても良かったので共有したいと思います。
baselineは減らすにはどうしたら良いのか?そもそも減らすべきなのか?レベルはどのくらいが良いのか?
など普段疑問に思っていることを利用者はどう感じて、どうPHPStanと向き合っているのかLTでお伝えできればと思います。
(あと、そんな利用者の声が聞けるPHPerTeaNightについても知ってもらえたらと思います)
皆さんyield使っていますか?
使う人は結構使うし、使わない人はとことん使わないyield文ですが、非常に味わい深い挙動となっています。
サンプルコードに対しての期待値を皆で考えてみて学ぼうという趣旨です。
時間が足りなくて銅鑼が鳴るか?それともネタが尽きるのが先か?そんなネタLTです。
このセッションではPHPのマイクロサービスアーキテクチャにおける分散トランザクション管理の新たな方法として、
アクターモデルとPhluxorを使ったSagaパターンの実装を紹介します。
PHPによる分散処理を諦めた方は多いのではないでしょうか?
並行処理の理解やサーバについての知識、結果整合への理解や、
障害対応方法や復旧方法など分散システムになればなるほど難しくなり、PHP以外の知識が要求されます。
アクターモデルはそれらを強力にサポートしてくれる仕組みがたくさんあります。
そんな仕組みを活用したデータ整合性の維持やレジリエンス向上に役立つ例として、
在庫管理やショッピングカートなどをテーマに実践的なアプローチを実装コードを交えて解説します。
アクターモデルによるメッセージングや、アクターによる振る舞いの変更、
state管理やSupervisionの活用、アクターの永続化などを用いて詳しく解説します。
複雑なワークフローをシンプルにし、スケーラビリティとフォールトトレランスを向上させる具体的な手法を習得しましょう!
インターフェイスという言葉は、さまざまな文脈で使用されます。具体的には以下のようなものがあります。
本セッションのスコープとなるインターフェイスは「その全て」です。
本セッションではソフトウェア開発において意識せざるを得ないインターフェイスというものについて考えてみます。
前述したようにひとことでインターフェイスといってもさまざまな種類があります。
それぞれのインターフェイスの特性を明らかにし、それらに共通する要素を探ります。この共通点を本セッションでは「インターフェイスという考え方」と呼ぶことにします。
本セッションではソフトウェア開発において強力な武器となるインターフェイスという考え方について、私なりに言語化して共有します。
例えばテストも、名前重要も、スキーマ駆動開発も、モジュラモノリスも、CQRSも、全てインターフェイスが意識されています。
インターフェイスという考え方は、空気のように当たり前に自然と活用されている一方、意識するだけで開発に新たな視点を得られるものだと感じています。
本セッションを通じて、参加者の皆さんがインターフェイスという考え方に改めて気づき、インターフェイスを意識することで、参加者が自身の開発プロセスに新たな視点を得ることができるようになることを目指します。
リッチなUIを実装するために多くのアプリケーションでjQueryが利用されています。JavaScriptのAPIやCSSの機能拡充によりjQueryの出番は減ってきているものの、導入の簡単さ、APIの使いやすさ、プラグインの豊富さから「MPAで画面の一部をリッチなUIにすること」においてはjQueryはまだまだ最適な技術の1つです。しかしながら、DOM操作の命令的なコードはロジックやUIが複雑になると保守性が悪くなる傾向があります。
一方で、ReactやVue.jsなどのフレームワークは、宣言的UIにより保守性が上がるものの、学習コスト・運用コストの点でtoo muchになるケースも少なくありません。実際、LaravelをAPIサーバーとして利用するようなフルSPAよりも、MPA + 小〜中規模のJavaScriptで十分に要件を満たすアプリケーションがほとんどではないかと思います。
そこで、jQueryに代わる選択肢として注目されているのがAlpine.jsです。Alpine.jsはMPAでリッチなUIを構築するのに適したJavaScriptフレームワークです。Livewireの作者が開発したOSSですのでLaravelやLivewireとの連携も簡単で、ビューファイル内に宣言的UIとして実装できるため保守性が高いことが特徴です。
本トークではLaravel MPAにおけるフロントエンドの実装手法についてお話します。Alpine.jsを使ったフロントエンド実装を中心に、宣言的UIと比べたときのjQueryの優位性、ViteによるビルドやNodeモジュールを使ったバージョン管理、JavaScriptの管理パターン、Blade連携、コンポーネント化について紹介します。このトークが、Laravel MPAにおけるフロントエンド技術選定の参考になれば幸いです。
LaravelはWebアプリケーションを簡単に早く作成できる人気のフレームワークの1つです。Laravel本体の機能は非常に充実しており、3rd partyライブラリを使わなくても柔軟な開発ができます。しかしながら、デフォルトの設定や機能だけではLaravelの強みを十分に活かしきれません。例えば、マジックメソッドを多用したフレームワークなため、コア機能だけではEloquentモデルのプロパティやFacadeメソッドのコード補完が効きません。そこで laravel-ide-helper のライブラリを使うと自動生成されたヘルパーファイルによりコード補完が効くようになり、開発効率が上がります。不正なプロパティ・メソッド呼び出しもPHPStan/Larastanなどの静的解析ツールを入れることで事前検知ができ、より堅牢な開発ができます。
本トークではLaravelのアプリケーション開発で入れるべきツールや設定について紹介します。コード補完、静的解析、ロギング、パフォーマンス改善、デバッグ、フロントエンド、フォーマッター、ライブラリの定期アップグレードなど、それらを導入する理由やできることを紹介します。
このトークで紹介するツールや設定により、皆様のLaravelアプリケーション開発がもっと効率的で堅牢で楽しいものになれば幸いです。
外部システムと連携を行うときに、頭を痛めるのが ”APIでの連携” です。
API で機能連携を行う場合、みなさんも一度はこんな経験があるのではないでしょうか?
「レスポンスデータが扱いづらい」
「エラーレスポンスを適切にハンドリングできない」
私たちのチームでも同様の課題に直面しましたが、
API 呼び出し時に専用の Result 型 を用意することで、解消することができました。
これであなたも、API の仕様に惑わされない実装ができるようになります。
「実装は今日からです。仕様はまだ決まっていません。」
チームに告げられた計画はあまりに無謀で、誰もが炎上を覚悟した─────。
私たちのチームではスケジュールの都合上、仕様が確定する前に実装に着手する必要がありました。
この危機的状況を切り抜けるため、サービスで採用していた ”オニオンアーキテクチャ” の利点を最大限活かし、
ドメインモデルを中心として ”仕様が決まっているところから着手する戦略” を取りました。
この戦略により、仕様の確定を待たずに手を動かせたことによって、スケジュールの遅延を防ぐことに成功しました。
実際にオニオンアーキテクチャによって、開発がブーストした事例を紹介します。
PHP初心者がPHPを2024年11月下旬からこれまで勉強したことを発表します。
発表内容は以下になります。
・直面した課題とそれらをどう克服したか
・学習に使用したリソースやツール
・学んだ具体的なトピックや技術(例:PHPの基本文法、データベース接続、フレームワークの基礎など)
・今後の学習計画や目標
登壇者は現職で5年ほど、レセプト業務を扱うシステムの開発をしております。
レセプト業務はドメインが複雑でミスが許されず、また3年に一度の大きな報酬改定がありロジックがガラッと変わります。
またその改訂作業自体が非常に短期間で行う必要があり、年々と複雑化するシステムと向き合う必要があります。
その中で、ドメインに向き合い取り組んでいった結果、レセプト業務をRezept as a Serviceとして構築して報酬改訂を乗り越えることができました。
ただ最初からXaaS化しようと狙っていたわけではなく、
上記の2回に渡って徐々にアーキテクチャを進化させていきました。
1回目のアーキテクチャ変更を経て感じた課題があり、更にビジネス上の環境の変化に対応する為にどの様にリアーキテクチャしていったのか紹介いたします。
コアドメインをX as a Service化して分かったメリットと勘所について深掘りしてお話したいと思います。
本セッションでは、次の点にフォーカスしてお話しします。
ドメインの蒸留とはなにか?、コアドメインを切り出すとはどういうことか?の一つの事例として紹介いたします。
オブジェクト指向大好きPHPerのみんなで、構造化プログラミング以前のスタイルで考えてみよう というトークです
クラスも無ぇ、制御フローもマトモに無ぇ、globalやgoto頼り!!!
非構造化の世界で、ぼくらの「認知負荷」は、どうなっちゃうの・・!?
開発生産性や変更容易性が特に重んじられる昨今、「認知負荷」との闘いに多くの時間が費やされます。
プログラミング言語もまた、こうした課題を解決する「あるべき姿」へと進化してきました。
一方で、「解決済み」の問題は見えにくいものです。
関数を定義できる、if-elseが使えることに、感謝の気持ちを抱いていますか?
それを理解するためには、温故知新のアプローチが役立ちます。
時代を遡ってみましょう。
オブジェクト指向以前の・・・手続き型?いいえ、もっと根源へ──
脱・構造化です!
この探求の先に、「今とは全く違うように見えるパラダイム」と「現在の姿」が地続きであると実感することでしょう
そして今の世界にも通じる「良さ」の再確認へと繋がるトークを提供します
みんなでスパゲティを食べに行きましょう
システム設計における「美しさ」は単なる見た目や感覚の問題ではありません
それは設計を維持し、守り、そして未来へ導くための重要な基盤です
本トークでは「美しさ」を設計の中心に据える意義と、それがアーキテクチャ全体の秩序や一貫性をどのように支えるのかを深掘りします
美しいコードやシステムに触れ、感動を覚えたことはないでしょうか
技巧を凝らしたコードに感嘆し、理路整然としたシステムの完成度に心を打たれた経験があるかもしれません
美しさには人の本能に訴えかける抗いがたい魅力があります
この魅力はアーキテクトが最も大切にする「システムの未来を形作る力」を秘めています
本トークでは以下の内容をお話します
対象者:
美しさが設計にもたらす力を探求し、設計の未来を描くインスピレーションを手にしましょう
ISUCON(Iikanjini Speed Up Contest)とは年に1度開催されるチューニングコンテストで私自身毎年参加しています!
遅いプロダクトを限られた時間内でチューニングしていき速度が上がっていくのを体験するのはとても楽しいです。
しかし実際に同じような状況が仕事で発生したとしたらどうでしょうか。。
顧客の要求している性能を満たせていないプロダクト、迫る納期、頻繁に連絡してくるクライアント。
やることは同じチューニングなのに冷や汗しかかかない状況に残念ながらしばしば直面することがあります。
ISUCONでは改善に失敗しても良い経験だったで終わりますが現実だとそうはいきません。
制限時間(納期)までに必ず「顧客が求める性能」をクリアしないといけない。
まさにリアルISUCON状態になった時、皆さんはどうするでしょうか?
実際のISUCONと同じように計測してボトルネックを治す。インフラ構成を見直す。対応は色々あると思います。
大会と現実で違うのはサーバーそのもののスペックアップを行う、仕様や画面設計そのものを再検討するなど顧客の要求をクリアするために広範囲の手段を取れることだと思います。
そして大会と同様システムそのもの改善も行いながら達成のために様々な手段を用いて顧客の要求を満たしていきます。
このトークでは、悲しくも現実でリアルISUCONが始まってしまった場合の私なりの戦い方をお話しします。
私が現在開発に携わっている販売管理サービス「楽楽販売」は誕生して15年以上経つプロダクトです。
フロントエンドにフレームワークは利用しておらず、長年にわたり静的に生成されるHTMLの画面部品コードがコピペされ続けており、共通化が行われていない状況に陥っています。
その結果コピペコードは新画面を作成するたびに増殖していき、PhpStormが親の仇の如く「Duplicated Code」を指摘してきます。
この課題を解消するため、私たちは以下の2つの目標を重視し「画面部品のUIコンポーネント化」に取り組みました。
・新しい画面を作成する際に、コピペする必要がない環境を構築する
・画面の構成パーツに何があるのかを容易に把握できる仕組みを作る
ゴールは以下2点です。
・複数画面から共通利用可能なUIコンポーネントを作成する
・将来的なコピペを駆逐すること
本セッションでは、取り組みの背景の課題から具体的な解決策、さらに実践例までを詳しくご紹介します。
■お話しすること
・なぜUIコンポーネント化が必要か
・どのようにコンポーネント化を進めたか
・コンポーネント部品を活用してもらうための施策
■想定する視聴者
・技術負債を解消したい人
・フロントエンドのフレームワークを利用していない人
・画面部品のUIコンポーネント化に興味がある人
・レガシープロダクトから脱却したい人
PHPは1994年に誕生し、現在でも多くのプロジェクトで活用されている歴史ある言語です。
そんな長い歴史を持つPHPには、これまでに多くの「奇妙な歴史的経緯」が存在します。
本セッションでは「PHPマニュアル 日本語版」に記述される「歴史的経緯」について5分で紐解き、その背景を紹介します。
歴史的経緯を知ることは、PHPに対する理解を深め、より良いコードを書ける手助けになるかもしれません。
皆さんはいくつの「歴史的経緯」を知っていますか?