リッチなUIを実装するために多くのアプリケーションでjQueryが利用されています。JavaScriptのAPIやCSSの機能拡充によりjQueryの出番は減ってきているものの、導入の簡単さ、APIの使いやすさ、プラグインの豊富さから「MPAで画面の一部をリッチなUIにすること」においてはjQueryはまだまだ最適な技術の１つです。しかしながら、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アプリケーションを簡単に早く作成できる人気のフレームワークの１つです。Laravel本体の機能は非常に充実しており、3rd partyライブラリを使わなくても柔軟な開発ができます。しかしながら、デフォルトの設定や機能だけではLaravelの強みを十分に活かしきれません。例えば、マジックメソッドを多用したフレームワークなため、コア機能だけではEloquentモデルのプロパティやFacadeメソッドのコード補完が効きません。そこで laravel-ide-helper のライブラリを使うと自動生成されたヘルパーファイルによりコード補完が効くようになり、開発効率が上がります。不正なプロパティ・メソッド呼び出しもPHPStan/Larastanなどの静的解析ツールを入れることで事前検知ができ、より堅牢な開発ができます。

本トークではLaravelのアプリケーション開発で入れるべきツールや設定について紹介します。コード補完、静的解析、ロギング、パフォーマンス改善、デバッグ、フロントエンド、フォーマッター、ライブラリの定期アップグレードなど、それらを導入する理由やできることを紹介します。

このトークで紹介するツールや設定により、皆様のLaravelアプリケーション開発がもっと効率的で堅牢で楽しいものになれば幸いです。

外部システムと連携を行うときに、頭を痛めるのが ”APIでの連携” です。
API で機能連携を行う場合、みなさんも一度はこんな経験があるのではないでしょうか？

「レスポンスデータが扱いづらい」
「エラーレスポンスを適切にハンドリングできない」

私たちのチームでも同様の課題に直面しましたが、
API 呼び出し時に専用の Result 型 を用意することで、解消することができました。

これであなたも、API の仕様に惑わされない実装ができるようになります。

「実装は今日からです。仕様はまだ決まっていません。」
チームに告げられた計画はあまりに無謀で、誰もが炎上を覚悟した─────。

私たちのチームではスケジュールの都合上、仕様が確定する前に実装に着手する必要がありました。
この危機的状況を切り抜けるため、サービスで採用していた ”オニオンアーキテクチャ” の利点を最大限活かし、
ドメインモデルを中心として ”仕様が決まっているところから着手する戦略” を取りました。
この戦略により、仕様の確定を待たずに手を動かせたことによって、スケジュールの遅延を防ぐことに成功しました。

実際にオニオンアーキテクチャによって、開発がブーストした事例を紹介します。

PHP初心者がPHPを2024年11月下旬からこれまで勉強したことを発表します。
発表内容は以下になります。
・直面した課題とそれらをどう克服したか
・学習に使用したリソースやツール
・学んだ具体的なトピックや技術（例：PHPの基本文法、データベース接続、フレームワークの基礎など）
・今後の学習計画や目標

登壇者は現職で5年ほど、レセプト業務を扱うシステムの開発をしております。
レセプト業務はドメインが複雑でミスが許されず、また３年に一度の大きな報酬改定がありロジックがガラッと変わります。
またその改訂作業自体が非常に短期間で行う必要があり、年々と複雑化するシステムと向き合う必要があります。

その中で、ドメインに向き合い取り組んでいった結果、レセプト業務をRezept as a Serviceとして構築して報酬改訂を乗り越えることができました。
ただ最初からXaaS化しようと狙っていたわけではなく、

1. 2021年4月の報酬改訂に対応する為
2. ビジネス変化と2024年4月の報酬改訂に対応する為

上記の2回に渡って徐々にアーキテクチャを進化させていきました。
1回目のアーキテクチャ変更を経て感じた課題があり、更にビジネス上の環境の変化に対応する為にどの様にリアーキテクチャしていったのか紹介いたします。
コアドメインをX as a Service化して分かったメリットと勘所について深掘りしてお話したいと思います。

本セッションでは、次の点にフォーカスしてお話しします。

1. XaaS化までの道のり
2. なぜXaaS化を目指したのか.
   狙いと実際にどうだったのか？
3. XaaS開発における重要なポイント.
   • コアドメインの見極めと責務の明確化
   • ユーザーとのコミュニケーション設計と開発プロセス
4. 継続的な開発を通じて得られた知見.
   • 安定した開発を行うための勘所
   • コアドメインと向き合う方法、そのメリットと課題

ドメインの蒸留とはなにか？、コアドメインを切り出すとはどういうことか？の一つの事例として紹介いたします。

オブジェクト指向大好きPHPerのみんなで、構造化プログラミング以前のスタイルで考えてみよう というトークです
クラスも無ぇ、制御フローもマトモに無ぇ、globalやgoto頼り！！！
非構造化の世界で、ぼくらの「認知負荷」は、どうなっちゃうの・・！？

開発生産性や変更容易性が特に重んじられる昨今、「認知負荷」との闘いに多くの時間が費やされます。
プログラミング言語もまた、こうした課題を解決する「あるべき姿」へと進化してきました。

一方で、「解決済み」の問題は見えにくいものです。
関数を定義できる、if-elseが使えることに、感謝の気持ちを抱いていますか？

それを理解するためには、温故知新のアプローチが役立ちます。
時代を遡ってみましょう。
オブジェクト指向以前の・・・手続き型？いいえ、もっと根源へ──
脱・構造化です！

この探求の先に、「今とは全く違うように見えるパラダイム」と「現在の姿」が地続きであると実感することでしょう
そして今の世界にも通じる「良さ」の再確認へと繋がるトークを提供します

みんなでスパゲティを食べに行きましょう

対象者と得られること

• 「どうしたら読むのに疲れるコードを生み出せるのか」に興味がある人
• 逆説的に「普段の開発で避けるべきこと」を知る

話すこと

• 構造化プログラミングの簡単なおさらい(定義・歴史)
• 「非構造化」のルールに則って書いたコードの紹介: お題 => 簡易CMS
• これらを踏まえ「我々が普段やっている&戦っていることはどんな意味があるの？」の確認

「非構造化」のルール(一部)

• 使わない: クラスや例外、while(true)以外のループ、名前空間
• 制限する: ユーザー定義関数 => 引数は使わない、値を返さない
• 使う: gotoや標準関数は使う

システム設計における「美しさ」は単なる見た目や感覚の問題ではありません
それは設計を維持し、守り、そして未来へ導くための重要な基盤です
本トークでは「美しさ」を設計の中心に据える意義と、それがアーキテクチャ全体の秩序や一貫性をどのように支えるのかを深掘りします

美しいコードやシステムに触れ、感動を覚えたことはないでしょうか
技巧を凝らしたコードに感嘆し、理路整然としたシステムの完成度に心を打たれた経験があるかもしれません
美しさには人の本能に訴えかける抗いがたい魅力があります
この魅力はアーキテクトが最も大切にする「システムの未来を形作る力」を秘めています

本トークでは以下の内容をお話します

• 美しさの価値：美しさがなぜ有用で、アーキテクトにとって欠かせない要素であるのか
• 審美眼の鍛え方：美しさを見極め、活用するために必要な視点やアプローチ
• 実践的な活用法：美しさを設計プロセスに組み込み、システムの秩序を守るための具体的な方法

対象者:

• システム設計やアーキテクチャに関心のあるエンジニア・リーダー
• 持続可能な設計を目指す方
• チームでの設計文化を改善し、秩序あるアーキテクチャを構築したい方

美しさが設計にもたらす力を探求し、設計の未来を描くインスピレーションを手にしましょう

ISUCON（Iikanjini Speed Up Contest）とは年に1度開催されるチューニングコンテストで私自身毎年参加しています！
遅いプロダクトを限られた時間内でチューニングしていき速度が上がっていくのを体験するのはとても楽しいです。
しかし実際に同じような状況が仕事で発生したとしたらどうでしょうか。。

顧客の要求している性能を満たせていないプロダクト、迫る納期、頻繁に連絡してくるクライアント。
やることは同じチューニングなのに冷や汗しかかかない状況に残念ながらしばしば直面することがあります。
ISUCONでは改善に失敗しても良い経験だったで終わりますが現実だとそうはいきません。
制限時間（納期）までに必ず「顧客が求める性能」をクリアしないといけない。
まさにリアルISUCON状態になった時、皆さんはどうするでしょうか？
実際のISUCONと同じように計測してボトルネックを治す。インフラ構成を見直す。対応は色々あると思います。
大会と現実で違うのはサーバーそのもののスペックアップを行う、仕様や画面設計そのものを再検討するなど顧客の要求をクリアするために広範囲の手段を取れることだと思います。
そして大会と同様システムそのもの改善も行いながら達成のために様々な手段を用いて顧客の要求を満たしていきます。

このトークでは、悲しくも現実でリアルISUCONが始まってしまった場合の私なりの戦い方をお話しします。

私が現在開発に携わっている販売管理サービス「楽楽販売」は誕生して15年以上経つプロダクトです。
フロントエンドにフレームワークは利用しておらず、長年にわたり静的に生成されるHTMLの画面部品コードがコピペされ続けており、共通化が行われていない状況に陥っています。
その結果コピペコードは新画面を作成するたびに増殖していき、PhpStormが親の仇の如く「Duplicated Code」を指摘してきます。

この課題を解消するため、私たちは以下の2つの目標を重視し「画面部品のUIコンポーネント化」に取り組みました。
　・新しい画面を作成する際に、コピペする必要がない環境を構築する
　・画面の構成パーツに何があるのかを容易に把握できる仕組みを作る

ゴールは以下２点です。
・複数画面から共通利用可能なUIコンポーネントを作成する
・将来的なコピペを駆逐すること

本セッションでは、取り組みの背景の課題から具体的な解決策、さらに実践例までを詳しくご紹介します。

■お話しすること
　・なぜUIコンポーネント化が必要か
　・どのようにコンポーネント化を進めたか
　・コンポーネント部品を活用してもらうための施策

■想定する視聴者
　・技術負債を解消したい人
　・フロントエンドのフレームワークを利用していない人
　・画面部品のUIコンポーネント化に興味がある人
　・レガシープロダクトから脱却したい人

PHPは1994年に誕生し、現在でも多くのプロジェクトで活用されている歴史ある言語です。
そんな長い歴史を持つPHPには、これまでに多くの「奇妙な歴史的経緯」が存在します。
本セッションでは「PHPマニュアル 日本語版」に記述される「歴史的経緯」について5分で紐解き、その背景を紹介します。

歴史的経緯を知ることは、PHPに対する理解を深め、より良いコードを書ける手助けになるかもしれません。
皆さんはいくつの「歴史的経緯」を知っていますか？

開発をしているときにコメントがあると助かりますよね。
「なるほど、ここはそういう処理をしてるのか！」と、コードの中身を詳しく読まなくとも実装を進めることができます。
しかし、時としてコメントは嘘をつき、あなたを陥れます。
特に古いシステムではこれまでに蓄積され、忘れられ、熟成されたコメントが至るところに散りばめられています。

私が以前開発に関わっていたメール共有サービス「メールディーラー」はリリースから20年以上経過しているサービスであり、熟成されたコメントが多数存在します。
このLTでは私が実際に遭遇したレガシーコードに潜む奇妙なコメントをご紹介し、コメントを盲信することが如何に危険なことであるかを知っていただきます。

コメントを信じるか信じないかはあなた次第です！

※PHPカンファレンス関西2024で発表した内容と同じものです

OpenAPIはAPIの仕様を記述するための仕様で、リクエストやレスポンスの詳細をYAMLまたはJSON形式で記述することができます。これを採用すると、記載内容を統一できる、バージョン管理しやすいなど様々なメリットがあります。
しかし、単なる仕様書と考えていると、徐々に実装との乖離が生まれてしまうリスクがあります。

これを防ぐための仕組みとして、OpenAPIドキュメントを使ってコードを生成したり、実行時に検査をする手法があります。
本セッションでは、Slimフレームワークを採用したシステムにOpenAPIドキュメントを用いたバリデーションとテストを導入した実例をご紹介します。
具体的には以下のような内容を含みます。

• OpenAPIを導入する際のポイントと注意点
• 具体的な実装方法 (league/openapi-psr7-validator)
• 導入の効果と進め方の反省点

Slim以外のフレームワークをお使いの方にも役立つセッションになるはずです。

PHPUnitのデータプロバイダーは、1つのテストメソッドを引数を変えて実行する「パラメタライズドテスト」を実現する仕組みです。
PHPUnit 10以降ではアトリビュートを使って実装しますが、そのときに使えるアトリビュートは実は4種類もあるのをご存知ですか？

このLTでは、これら4種類のアトリビュートを紹介した上で、私自身がどう使い分けてデータプロバイダーを実装しているのかお話しします。

お話しすること

• データプロバイダーとは何か
• データプロバイダーを使う利点
• PHPUnitにおけるデータプロバイダーの実現方法
• 4種類のアトリビュートの使い分け方の提案

想定する観客

• PHPUnitを使っているがデータプロバイダーを知らない人
• #[DataProvider]/@dataProviderしか使ったことがない人

2,147,483,647
これ何の数字か分かりますか？
そうですね！INTの最大値ですね！

DBを設計していて何となくIDカラムをINT型にしている人、多いのではないでしょうか？
初めのうちはいいのですがサービスの成長と共にレコードが増え、INTの上限値になった場合どうなるのでしょうか？

本セッションでは

• 実際に弊社で起きた事象と対応
• DB設計において気をつけるべき点

をお話できればと思っております！

ソフトウェア開発を行うエンジニアで「『技術的負債』という言葉を知らない」という方は今日においてほとんどいないと思います。その一方で「技術的負債とは何か」を正しく理解し、自信を持って説明できる人はあまり多くないように思います。その相手が非エンジニアであればなおさらです。

また、技術的負債についての理解が不十分なことによる誤解や偏見も散見されます。例えば「技術的負債＝悪」というイメージから無用・無謀なリファクタリングを行ったり、逆に放置しすぎた結果、ビジネスにおけるリスクが表面化してしまうこともあります。

このトークを通じて技術的負債についての理解を深め、技術的負債とどのように向き合えばよいのか、その具体的なアプローチを考えるきっかけにしていただければと思います。

お話しすること

• 技術的負債とはなにか
• 技術的負債はいつ・どうして生まれるのか
• 技術的負債を放置することで発生するビジネス面・技術面でのリスクとは
• 技術的負債を最小限に抑えるいくつかのテクニック
• 技術的負債とどう付き合っていくべきか

現代のソフトウェア開発において、脆弱性への対応は非常に重要な課題です。PHPを使用したウェブアプリケーションにおいても例外ではなく、フレームワークやプログラミング言語、ミドルウェア、OSなど、様々な要素において脆弱性が発見される可能性があります。

このパンフレット記事では、そんな脆弱性情報をどうやって日頃から収集するのか、そしてどのようにして自分のウェブアプリケーションが脆弱性にさらされていないのか確認・検知するのか。
また、実際の対応方法について紹介します。

本記事で記述する内容

• 脆弱性情報の収集方法
• 脆弱性検知の方法
• 検知された脆弱性の対応優先度の決め方
• 実際の対応方法

メンター「力がほしいか、、、？」
私「ほしい！」
メンター「ならばLaravelを写経せよ」
私「？？？」

会社のメンターに実力をつけたいと相談したところ、自分の使っている道具を細部まで知ることによって、誰よりも強くなれると教えられました。
幅広く使ってもらうように作るフレームワークとそのフレームワークを使って作る業務に特化したアプリケーションでは、そもそも作るときの思想が違うのでは？と一度は思った私でしたが、そういう言い訳はやってから言わないといけないと思い、素直に写経を行うことにしました。

そこで写経の際にどのような順番で取り組み、その都度どのようなことを考え、そこで学んだこと、そして写経に意味があったのかどうかという、この挑戦の足跡を伝えていきたいと思います。

様々なサービスがサブスクリプション・SaaS化したことで、企業や開発者の固定支出が増加し始めています。
「サブスク疲れ」というワードは、経営陣からも注目を集めており、もはやサブスクリプションで提供するだけでは選ばれにくい現状が生まれつつあります。

そんな中、サブスクリプションビジネスを成功に導くために意識すべきポイントは何か？
Stripeがサブスクリプションビジネスを運営する企業にヒアリングして集めたデータを元に、
システムの要件として事前に考慮すべき５つのポイントを紹介します。

トピックの例:
・無料トライアルや無料プランは提供すべきか否か？
・どのような料金体系でサービスを提供すべきか？
・売上と解約率の関係、そして解約率を下げるためにやるべきこと、やるべきでないこと

ソフトウェアエンジニアには抽象化の能力が重要と言われます。
では実際に抽象化とはどのような能力なのでしょうか？

実際の事例を交えながら、抽象化を理解し、実務に活かせるようにします。

話すこと

• 抽象化と具体化とは
• 抽象化のメリット
• 現実で身につける抽象化の階層
• 抽象と具象の往復とは
• ソフトウェアと抽象化

話さないこと

• 具体的なソフトウェアの実装における抽象レイヤーの話