「例外=\Exception、返すのはいつも500…」そんな状態に悩んだことはありませんか?
Laravel 11/12では、ExceptionServiceProviderによってエラーハンドリングの構成が見直され、独自例外による明確な設計がより重要になっています。
本セッションでは、独自例外をドメインルールを表す手段として活用し、保守性と読みやすさを高める設計のコツを紹介します。
扱う具体例
PermissionDeniedExceptionのようなドメインルールを表す例外の設計方法
Laravel 11以降のExceptionServiceProviderの活用法
セッションで得られること
業務ドメインを意識した例外設計による責務の明確化
「なんでも 500」から脱却し、想定外と想定内を分けた異常系設計
Laravel 11/12 での例外処理構成の考え方と実装の勘所
もぅマヂ無理…PHP の array 関数、多すぎぃ〜😵💫
array_map とか array_filter とか、似た名前ばっかでマヂで呪文かと思ったし🌀
「どれ使えば正解なん?」「テカ違いなに?」「ぇ、もう全部 foreach でよくね?(白目)」ってなって、
ガチで心折れた🥀
でもね、業務でブチ当たりすぎて、
泣きながら調べて、試して、失敗して、やっとちょっとずつわかってきたの🫶
このトークでわ、その時の「array 関数メンタル崩壊事件簿」をゆるっと共有しながら、
それぞれの関数の違いや、こう使えばよくね?って話をしてくよん🌈💡
array 関数で病みかけたギャル(ぅちらギャルだよね?)、全員集合〜💖💖
「実装は今日からです。仕様はまだ決まっていません。」
チームに告げられた計画はあまりに無謀で、誰もが炎上を覚悟した─────。
この発表では、オニオンアーキテクチャによって仕様追加による改修が最小限に抑えられた事例について解説します。
私たちのチームではスケジュールの都合上、仕様が確定する前に実装に着手する必要がありました。
この危機的状況を切り抜けるため、サービスで採用していた ”オニオンアーキテクチャ” の利点を最大限活かし、
ドメインモデルを中心として ”仕様が決まっているところから着手する戦略” を取りました。
この戦略により、仕様の確定を待たずに手を動かせたことによって、スケジュールの遅延を防ぐことに成功しました。
実際にオニオンアーキテクチャによって、開発がブーストした事例を紹介します。
PHPを使用して「サーバーサイド・ブロックチェーン」という新たな概念にチャレンジします。
従来、ブロックチェーンはクライアントサイドで署名したデータを、スマートコントラクトがデプロイされたP2Pネットワークに通知する構成が主流であり、サーバーサイドでの活用事例は多くありませんでした。
この構成は、1対1の当事者間においては高いセキュリティを実現できる一方で、複数関係者の同時関与や段階的な意思決定が求められる実業務の場面においては、柔軟なワークフローの設計や、合意形成の自動化に課題が残っていました。
本トークではSymbolブロックチェーンを活用し、サーバーサイドに部分署名を組み込むことで、既存のWebシステム上に、安全かつ自然に統合する手法を紹介します。
これにより、業務システムに求められる実用性と、ブロックチェーンの信頼性を両立する、新たな実装モデルの可能性を提示します。
本トークはPHPのメタプログラミング技術を活用し、本来の言語設計が提供する制約を超えた操作がどのように可能となるか、またその結果生じるリスクと課題についてをお話します。
PHPにはリフレクションAPIを使用したアクセスやeval()による動的なコード実行など強力な機能が提供されています。
これらの技術はいわゆるメタプログラミング技術に内包されるもので、特定状況下では非常に有用ですが、同時に深刻なリスクが伴うものです。
ちょっとしたいたずら心がどのような災厄を招くのか。
本トークではメタプログラミングの威力をあらためて確認し、その適正な使用範囲とベストプラクティスについてお話いたします。
会計システムを作る時にPHPの数値仕様をしっかり理解した上で作らないと、後々大変なことになってしまう可能性があります。
小数点以下の誤差によって1円が消えたり増えたりしてしまうことがあり、1円の行方を巡って終わりのない、解決もしない調査の旅に身を投じることになるでしょう。
それが今なのか、いつなのかは分かりませんが、知っていれば防げる問題でもあります。
本セッションでは数値にはどんな問題があり、扱う時に何を気をつける必要があって、さらに扱いやすくするためにおすすめの方法をお話しします。