OSS活動していますか？

多くの人は色々と理由があって活動されていないんじゃないかと考えられます。

• 使ったことあるけど、不便だと思ったことがない
• OSS、どうやって参加すればいいのかわからない
• OSS活動ってめっちゃ出来る人がやっているイメージがあって自分がやっていいとは思えない……

当然、これらの意見はとても共感し、尊重されることでしょう。
これまでの世界であれば……。

AI時代に突入した昨今から、実はOSS活動の参入障壁は最も低くなったのではないかと考えています。
そこで、みなさまにＯＳＳ活動に気軽に参加するためのAI活用方法をお話していきます。

アジェンダ

• OSS活動をするにあたって
• OSS活動その1 - ソースコードを洗い出す
• OSS活動その2 - 過去のプルリクを追ってみる
• OSS活動その3 - 直せそう or 追加したい処理を作ってみよう
• OSS活動その4 - ディスカッションしてみよう（チャンス待ち）
• 実際にやってみた（実例）

このセッションで伝えていきたいこと

OSSは怖くないし、もっと気軽にコントリビューターになれますよ！
「実務以外での経験を積みたいなら」の一つの事例として知ってもらえればと思います

アーキテクチャの刷新は、しばしば「決める人」が限定され、トップダウンでの進行になりがちです。
しかし、その方法では納得感が生まれず、チーム全体が新しいアーキテクチャに適応しきれないのではと私は感じていました。

そこで実施したのが、「俺の/私の最強アーキテクチャ決定戦」というイベントです。
全員が発言できるように場を用意し、メンバーがそれぞれ考える理想のアーキテクチャを持ち寄る形式を取りました。

この取り組みには二つの意図がありました。

1. トップダウンにせず、チームで方向性を決めたかった
2. 不満や現状の違和感を、発言機会を設置することで可視化したかった

実際に開催してみると、若手メンバーからも積極的な発信があり、各自抱えていた困りごと・改善の種を吸い取ることができました。
最終的に決まったアーキテクチャはひとつですが、その結論には全員の声が反映された状態をつくれました。
これによりトップダウンでは得られない、「自分たちで決めた」という納得感とオーナーシップが生まれました。

本LTでは、
・なぜトップダウンではなくイベント開催を選んだのか
・どのように発言機会を設計したのか
・若手の声を拾うことで何が変わったのか

チーム全員が新しいアーキテクチャに適合するための工夫を実体験に沿って紹介します。
アーキテクチャ刷新は設計だけでは進みません。
“決め方”を設計することでチームは刷新に適応できるようになる。
そんな学びをお伝えします。

■想定する参加者層
・トップダウンの設計決定に違和感を覚えたことがある人
・若手の意見を引き出したいリーダー
・設計刷新や合意形成に悩むチームメンバー

■Learning Outcome
・チーム内での考える人作る人の分断を防止できる
・チームが主体的に開発を進めていける
・チームがオーナーシップを持ってプロダクトを育てていける

概要

TiDB は「NewSQL」と呼ばれる分散データベースで、
MySQL 互換のプロトコルを持ちながら水平スケールできるなんだかすごいやつです。

さてMySQL互換というからには、さぞ移行もしやすいことでしょう！
MySQLを利用している既存のLaravelのアプリケーションをローカル環境でTiDBに切り替えてみて、果たしてどこまで動くのか？
実際に切り替えてみてからの躓きからTiDBとMySQLの違いを掘り下げ、完全に理解していきましょう！

ターゲット

• TiDB に興味はあるけど触ったことがない方
• RDBMS以外のDBも学んでみたい方
• DBが好きな方

お話すること

• TiDBの簡単な概要、特徴
• TiDBのローカル環境の構築方法
• Laravel アプリケーションを接続してみて実際に詰まったポイント
• MySQLとの挙動の違いとその理由

本トークはPHPカンファレンス福岡2025で発表した「Node.jsに頼らずにFrankenPHPでリアルタイムWeb通信を実現する
」（30分）をベースに、動作デモの充実させ、Socket通信やプロセス分離の説明を厚くアップデートしたものです。

概要

従来のPHP環境は1リクエスト1プロセスのモデルであり、長時間接続を維持するソケット通信とは相性が悪く、
リアルタイム通知を実装する場合、Node.js等を組み合わせた複雑なインフラ構成は悩みの種でした。
しかしFrankenPHPの登場で取れる選択肢が増えてきました。
この課題を解決するためにMercureが内蔵されており、PHPスタック内でシンプルかつ高速なリアルタイム通信を実現しています。
本セッションでは実際に動作するアプリケーションの動作デモを交えながら、Socket通信の様子やプロセス分離の様子を可視化し、解説します。

話すこと

• FrankenPHP (Mercure) を使った実装デモと、PHPスタックのみで完結するメリット
• PHPにおける常時接続の難しさと、ポーリング等の従来構成の限界
• Server-Sent Events(SSE) と WebSocketのソケット通信の基礎と違い
• 通信方向の違いによる技術選定のポイント
• PHPランタイムと通信プロセスのプロセス分離

話さないこと

• Mercure（Hub）の技術詳細
• スケーラビリティ、耐障害性等の非機能要件

概要

PHP8以降、match式の登場に代表される関数型言語の取り込みが進み、マルチパラダイムへと進化してきています。
さらにパイプ演算子の導入により、コーディング体験が大きく変わる局面に来ています。
一時変数の命名に掛かるコストや、多用による可読性の低下によるメンテナンス難易度の上昇、
array_mapに代表される配列操作の深いネストや、Collectionでの型情報がないメソッドチェーンに苦労された方も多いでしょう。
本セッションではパイプ演算子を中心にこのような問題を解決し、
より宣言的でわかりやすいコードを書くための手助けをしつつ、マルチパラダイムに向かうPHPについてお話しします。
オブジェクト指向設計に関数型言語の要素が加わることで、どのように設計の幅が広がり、どのようにコードが変化するのか。
そしてそれらにパイプ演算子がどう関わるのかを、具体的なコード例を交えて解説します。

話すこと

• パイプ演算子の基礎と仕様。従来の記述（ネスト・一時変数）との比較
• パイプ演算子がもたらす可読性と型安全性のメリット
• Enum・match式・パイプ演算子を組み合わせた宣言的なコードの実装例
• RFCも含めた、PHPのマルチパラダイムなコード設計

話さないこと

• パイプ演算子の内部実装
• 厳密な関数型プログラミング理論
• 他の言語との詳細な機能比較

「PHPUnitの機能強化と改善の様子を眺めてることで、PHPの進化の軌跡を感じ取ってみよう！」というLTです。

最近のPHPUnitは、(大体)年次でメジャーバージョンアップを行っています。
そして、最近のPHPも年次でマイナー/メジャーバージョンアップを行っています。

PHPUnitを見ていると「より良いテストを、より誰が使っても誤用されずに書けるように」と進化しているような意思が感じられ、
またPHPも「よりエレガントなコードを、安全に書けるように」と進化しているようなエネルギーを感じます。

そんな訳で、PHPUnitには、PHPの「新機能への対応」「新機能の利用」を積極的に取り入れているな！！と感心させられる場面がしばしば。
例えば、少し前に入った「ネイティブのEnumが使えるようになったので、 assertEqualsでEnum同士の比較を通せるようにする」なんて機能追加は分かりやすいでしょう。

数多くの進化を遂げてきたPHP。
PHPユーザーのためのPHP製ツールであるPHPUnitの進化から、PHPのパワーを発見しましょう。

▼ このLTで得られるもの

• 「PHPUnit、そんな風に進化していっているんだね！」という喜び
• 「お、新しいバージョンでは、そんなものも対応していたのか」という発見
• 「新しいバージョン良さそう〜上げて行こうな！」というモチベーション

OpenTelemetryプロジェクトはPHP向けにもゼロコード計装を提供しており、アプリケーションのコードを変更せずにトレースなどのシグナルを生成することができます。これにより、手軽にオブザーバビリティを導入することが可能です。しかし、これはPHP8.0以降でなければ動きません。

前半では、OpenTelemetryのゼロコード計装の仕組みを紹介し、なぜこれがPHP8.0以降でなければ動かないのかを明らかにします。具体的には、Zend Engineに新しく追加されたObserver APIの話をします。

後半では、それでもPHP7.4でもトレースを労力少なくOpenTelemetryで計装したい！というニーズにお応えして2つの手法を提案し比較します。すでに公開されているOpenTelemetry eBPF Instrumentationを使った手法と、PHP8向けのOpenTelemetryゼロコード計装のインタフェースに倣って私が自作したextensionを用いる手法です。後者についてはその実現方法や、生成AIを活用したextension実装の進め方についても紹介します。

本セッションを聞くことで、アプリケーションの内部状態を観測可能にするオブザーバビリティを実現する裏側の仕組みを知ることができます。また、すでにサポートが切れているPHP7系から8系にアップグレードしたい開発者が、アップグレードによって影響があるかどうかを知るために7系のうちから必要なオブザーバビリティを担保するための手法について知ることができます。

サービスに途中から参加すると、最初の頃はコードとドメインがどのように積み上がってきたのかを追いかけるところから始まります。私が担当しているユーザー領域も、サービスの成長に合わせて機能が増え、その結果としてバリデーションや判定処理がいくつかの層に分散していました。本セッションでは、これらを読み解きながら整理していったプロセスを紹介します。

まず、散在していたユーザーまわりのバリデーションをドメインサービスに集約し、どのような処理をドメイン側で扱うべきかをチームで合意できるよう、簡単なマニフェストを用意しました。また、利用者ごとのケーパビリティを導入し、エンドポイント単位でアクセス制御を行うことで、コントローラへの細かな分岐を避けられるようにしました。

さらに、DB のインデックス追加を安全に進めるために、GitHub Actions から実行できる “alterguard” を開発し、作業手順を極力シンプルにしながら pt-osc を併用できる環境を整えました。これにより、ユーザー領域以外の改善も継続的に進められるようになりました。

成長中のプロダクトに後から加わった立場として、どのようにドメインを理解し、どこから整えていったのか。その具体的な進め方をお話しします。

皆さんはLaravelのアップデートを定期的に行っていますか？

私たちのチームは段階的にLaravelのアップデートを行い、最終的に9から12まで上げることに成功しました。
その過程の中、10→11の段階でアップデートしようとしてみたところ
composer updateの実行で何のエラーログもなく実行エラーとなってしまいました。

最初は原因が分からず困惑しましたが、なんとか解決し
その過程でLaravelが起動される時の流れをいい感じに学ぶことになりました。
今回はLTでその流れをご紹介したいと思います。

「テスト」という言葉は、文脈によって全く異なる意味を持ちます。
例えば、プログラマーとQAが「テスト」について話すとき、よく認識のズレを感じることがあります。
不思議ですよね。

それは、テストには「開発手法（設計）」としての側面と、「品質保証」としての側面の二面性があるからです。
この違いを理解せず、開発手法としてのテスト（TDDなど）だけで「品質は保証された」と判断してしまうことは危険です。
それと同時に、品質保証の側面だけから開発手法としてのテストを語ることも、また危険です。

本セッションでは、テストを「事実から学習し、意思決定するためのフィードバックループ」と捉えます。
そして、アジャイルテストの4象限を用いて、その役割の多様性を整理します

チームを支援するテスト

テストから得られた情報によって、チームを導き、支援するような役割を表すのがこの側面です。

製品を批評するテスト

一方で、作り手が考える「あるべき姿」とはまた違った視点から、批判的に評価し、チームの自信とステークホルダーへの説明責任を果たす役割を持つのがこの側面です。

ビジネス面と技術面

上記の左右の軸に加え、それが「ビジネス（ユーザー）視点」なのか「技術（内部品質）視点」なのかでマッピングすることで、テストの目的はより鮮明になります。

テストの二面性を知り、アジャイルテストの4象限を使うことで、漫然とテストをしていたことに気づくかもしれません。
これらは「誰のために、どんなことをするのか」に気づくことができる強力なツールです。

テストの二面性と4象限へのマッピングを使って、チームで納得のいくコミュニケーションを行うためのヒントをお話しします。

「バグ」という言葉を聞くと、ネガティブな気持ちになるプログラマーは少なくありません。
多くの人にとって、バグ報告は「自分のミスへの指摘」のように感じられ、決して気持ちの良いものではないでしょう。
その結果、バグ報告を躊躇したり、見なかったことにしてしまう心理が働くことも理解できます。

しかし、1人のテストエンジニアとして一貫して思うのは、バグは誰かの「罪」ではなく、単なる「事実（期待結果との差異）」です。
この事実と正しく向き合うための技術こそが「バグ管理」だと考えています。
そして、それを運用するのは感情を持った人間です。

本セッションでは、バグ管理を「(意図的でないにせよ)開発者を責める場」から「チームが前進する場」へと変革した実践事例をお話しします。

バグ管理の本質は「事実」の管理

バグとは「現実で起こっている問題」であり、リスク管理の対象として適切に管理すべき対象です。
バグを全て修正するのではなく、限られたリソースの中で建設的に対処することが必要です。

「バグ」ではなく「チャンス」と呼ぶ

「期待と違う挙動」は、実はプロダクトを良くする機会であることに気づきました。
呼び方を変えるだけで、バグ起票や対処のハードルが下がった事例を紹介します。

重大度を「妖怪」で定義する

重大度という、そのバグが持つ悪い結果を予知するステータスがあります。
これは一般的に「Critical/Major」などの言葉がありますが、私がいたチームでは「座敷童（軽微）」「鬼（重大）」「八岐大蛇（致命的）」と定義しました。
これにより「今週は鬼を退治しよう！」とチームの会話がポジティブに変わりました。

バグ管理は重要です。一方で、嫌な気持ちを放置するのも違います。
バグ管理をハックして、毎日の開発を楽しくしませんか？

「全数テストは不可能」というソフトウェアテストの原則があります。
ごく単純なソフトウェアを除けば、すべてのバグを見つけることは不可能です。
では、私たちは不完全さを理由に、テストという活動やその責務を放棄してよいのでしょうか？

私はそうではないと考えます。
無限のテストに立ち向かうためには、「どこまでやれば我々の責務を果たしたと言えるか」を定義し、チームで納得する必要があります。
私はそれを「テスト計画」によって示せると考えています。

多くの現場において、テスト計画は「スケジュール調整」「テンプレートを埋める作業」と誤解されていますが、それは本質ではありません。
本来のテスト計画とは、ソフトウェア開発におけるコンテキストを深く理解し、「テストすべきもの」と同時に「テストしないもの」を定義します。
そして、「我々はこれでリリースできる」と納得することです。

本セッションでは、QAエンジニアである私の視点から、テンプレ埋め作業ではない、「テスト計画」という活動を構成するプラクティスを一部紹介します。

「コンテキスト」を集める

「テストはコンテキスト次第」という原則があります。
「なぜ作るのか」「誰が使うのか」、そして「制約」そういった情報を集め、整理することがテスト計画の第一歩となります。

「作ってはいけないもの」を見つける

我々は「作るべきもの」に集中することが多いです。
一方テストでは、「作ってはいけないもの」ということも考える必要があります。
プロダクトリスクと言いますが、これを批判的な問いによって見つけていきます。

完璧なソフトウェアが存在しないように、完璧なテストも存在しません。
しかし、我々はプロとして、「これなら大丈夫」と胸を張って顧客に届ける必要があります。

その方法のひとつとしての「テスト計画」について語りたいと思います。

"Official PHP SDK for MCP"、mcp/sdkというライブラリがあります。
これを使うと、簡単にPHPアプリケーションを「MCPサーバー」化できます。

例えばToolsを提供するなら、「jsonを返すPHPのメソッドに、「Tools」用のattributeを付けて、 Mcp\Server クラスを run() する」で、もうAIエージェントから使えます！
あまりに簡単。魔法のようですよね。

これは、一種のフレームワーク(FW)としての開発体験を提供していると言えます。
すなわち、

• 開発者は、自分の必要なロジック(アプリケーション機能)にだけに関心を払えば良い
  • それより下の、「クライアントとのやり取り作法」については、全てカプセル化
• 「実装した機能」の検出と呼び出し = ルーティングを一式備えて、正式で唯一のエントリーポイントを提供する
• この2点により、「制御の逆転」を実現する

というものです。
──さて、phper的には「どうやって、”足場”と”アプリケーション機能"の分離を行っているのか」「MCPならではの特殊な事情を繋ぎ込んでいるのか」が気になりませんか？
なぜ、こんな少ない労力で「すぐ動く」のでしょうか。

そんな訳で、「MCPそのもの・便利な使い方」はさておき、「FWとしてのmcp/sdkはどう設計され、機能を実現しているのか？」を読み解こう！というトークです。

このトークでは、次のような知識と知恵を提供します。

• 「FW」とは何を指しているのか、目的と要件
• mcp/sdkの「制御の逆転」と手続きの隠蔽、MCP的な事情をクリアするための実装
• 現代PHPのエコシステムに則った拡張性の実現(PSR関連)

PHPのsocket機能を利用すると手軽にネットワークプログラミングができます。
私は今までにPHPでHTTPS(TLS)プロトコル、TCP/IPプロトコルを実装してきました。
PHPでTCP/IPを実装？と思うかもしれませんが、意外とPHPでも下の層のプロトコルが自作できます。
PHP8.5からはその下の層のイーサネットプロトコルも扱えるようになり、ついにPHPで物理層以外のプロトコルが実装できるようになったのです！

今回はその機能を使って簡単なIPルーターを自作する方法を解説します。
異なるネットワークのホスト同士がどのように通信するのか、それをルーターとしてどう処理するのか。
PHPを使うことでこの処理の理解がしやすく、C言語よりは手軽に自作ルーターが体験できます。

このセッションを通して次のことが学べます

• IPアドレスとイーサネットとの関係
• MACアドレスの役割
• パケットを転送する仕組み
• PHPのネットワークプログラミング
• LinuxなどOSが提供するsocket機能の役割

アジェンダ（予定）

• PHPのsocket機能
• ルーターの仕組み
  • ARP
  • MACアドレス書き換え
  • パケット転送
• PHPでルーターを作る場合の注意点
• PHPを使ったネットワークプログラミングの面白話

Laravelアプリケーションの運用において、エラー調査にどれくらいの時間を費やしていますか？ 「ログ検索（Kibana等）をしているが、POSTパラメータが欠落していて再現できない」「スタックトレースだけでは原因が特定できない」——かつての弊社もこのような課題を抱え、調査に数時間を費やすことも珍しくありませんでした。

本トークでは、Sentryを導入していない、あるいは基本機能のみ利用している方に向けて、エラー対応の効率化からパフォーマンス改善までの一連の流れをお話しします。

前半では、Sentry導入による劇的な開発体験の変化を紹介します。 リクエスト時のパラメータや実行環境などの豊富なコンテキスト情報の記録、そして類似のエラーを自動でまとめる「インテリジェントなグルーピング」機能により、Slack通知のノイズを大幅に削減。以前は困難だったエラー原因の特定が数分で完了するようになった経緯と実績をお伝えします。

この「守りの効率化」を踏まえた上で、後半は「Laravel Insights」を活用した「攻めのアプリ解析」について詳しく見ていきます。 ここでは、ループ内で過剰にDBクエリを発行してしまう「N+1問題」の検知や、遅延しているHTTPリクエストの特定など、パフォーマンス低下の要因（ボトルネック）を可視化する方法を解説します。さらに、AIエージェントによる根本原因の推論機能を用いたデバッグフローも紹介します。

Sentryを導入し、「ログを探す時間」を「コードを直す時間」に変えましょう。チームの開発生産性を高めるための具体的な実践手法を持ち帰っていただければ幸いです。

テストコード、書いていますか？

今日において、自動ユニットテストを整備することが開発生産性の向上に寄与することはもはや疑う余地がありません。また AI の活用により、テストコードを書くコストは従来に比べて大幅に減っています。

しかし「テストコードの書き方や導入方法がわからない」「テストコードがあるだけで満足してしまい十分にその効果を発揮されていない」「テストコードが負債化し開発の足枷になっている」などの課題に直面している方も多いのではないでしょうか。

AI がコードを書く時代になっても……いや、むしろ AI がコードを書く時代だからこそ「価値のある」ユニットテストについて一緒に考えてみませんか？

お話しすること

• AI 時代における自動ユニットテストの価値とは
• 価値のあるテストコードを書くための基本的な考え方
• よくあるアンチパターンと処方箋・テクニック

MVC フレームワークが普及してから約20年。Web アプリケーション開発において「層」を分けることは当たり前の「お作法」になりました。

その効果は「関心の分離」というキーワードでよく語られます。しかし、あなたの現場ではその言葉の意味が正しく理解されているでしょうか。そこで分離したい「関心」とは一体なんなのでしょうか。

意味を理解しないまま、フレームワークや流行のアーキテクチャの表層だけをなぞり、雰囲気で「層」を分けていると、次のような事態に陥ります。

• Controller から Repository へデータを右から左へ流すだけの「土管」Service
• DB のスキーマ変更が、なぜかフロントエンドの修正にまで波及してしまう
• ビジネスロジックがあちこちに分散し、調査に時間がかかる

これでは「層」を分ける恩恵を受けられないどころか、コードを複雑化させ、開発速度を落とす無駄なコストが増えるだけです。「層」の分割は、その意図を正しく理解し、適切な「抽象化」によって本当の「関心の分離」を実現することで、初めてその効果を発揮します。

本セッションでは、形骸化しがちなレイヤー設計に意味を取り戻すための考え方を解説します。

こんな人に向けて話します

• なんとなくルールに従って層を分けているけど、面倒なだけに感じている
• 層を分ける理由をきちんと言語化し、後輩にもっと丁寧に説明したい

コードを書く時に、「文法」って無視できないですよね。
巨大な存在すぎて、「何かそういうもの」「所与のものとして、そう在る」と思ってしまっているフシはありませんか？
しかし、プログラミング言語もソフトウェアです。
私たちが業務や趣味で書いているものと同様に、「仕様があり、それを実装している」に過ぎません。つまり、文法も「仕様に対する実装」と言えるのです。

「最初からある」から「そういうものに見える」のなら、視点を変えるために逆のアプローチを取るのが効くことでしょう。
自分で作るのです！文法を、実装してみましょう。

このトークでは、ドメイン固有言語(DSL)の自作を通じて、「プログラミング言語と文法の関係」に光を当てます。
最後には、文法が「そういうもの」から「仕様と実装があるだけ」と感じられるようになるでしょう。

話すこと

最終的にPHPに変換される、小さなDSLを作成します。
その過程で、「ソースコード(つまり、ただの文字列！)」→「語句に分解された集まり」→「語句同士の連なりである文(構文)」へと変換される手続きと、そこに必要な登場人物を追いかけていきましょう。
字句解析・構文解析といった概念のざっくりとした理解と、文法や言語仕様を読み解くための基礎知識を提供します。

話さないこと

字句解析・構文解析の理論や実装パターンについての網羅的な解説は行いません。「流れを体感する」ことを優先します。
(構文解析器の生成にはパーサージェネレータを利用し、実装における詳細なアルゴリズムは本トークで扱いません。）

代わりに、参考にした書籍等の紹介を発表資料と一緒に展開します。

想定するターゲット

• 言語やパーサーを自作した経験はないが、興味はある方
• YAML、SQL、正規表現などを日常的に使っているが、「作る側」の視点を持ったことがない方

概要

GitHub Copilot は優秀な相棒ですが、あなたのプロジェクトの「空気」まで読んでくれていますか？
特に長く運用されているレガシーコードや、独自のフレームワークを採用している現場では、AIが良かれと思って提案する「モダンで洗練されたコード」が、逆に修正の手間を生むノイズになることがあります。
「そこは namespace ではなく、アンダースコア区切りで……」と、AIの提案を人間が修正する作業に疲弊していないでしょうか。

本セッションのテーマは、Copilot への「教育」です。
単なるコード生成ツールとしてではなく、プロジェクトの文脈を理解した「専属の一流エンジニア」として育てるための、 Custom Instructions の活用と実践術を深掘りします。

話すこと

• Custom Instructions について: 設定ファイルの仕様と、AIに「空気を読ませる」ための基本的な記述ルールについて解説します。
• 独自ルールの徹底: モダンな学習データには少ないルールをどう言語化すればAIに伝わるか解説します。
• Before/After: 同じプロンプトでもインストラクションの有無で、AIの提案コードがどう変化するのか見てみます。

ターゲット

• AI の出力修正に時間を取られているエンジニア
• 長期運用中のレガシーシステムや、厳格な独自規約を持つプロジェクトに携わっている方
• チーム全体のコード品質均一化を目指す、2〜5 年目のリーダー層

曖昧な指示を排除し、意図通りに動かすプロンプトエンジニアリングの基礎から、標準規約とレガシー規約の共存テクニックまで。
明日からチームの Copilot が「新人」から「熟練の古参メンバー」へと変わる、実践的な育成技術をお持ち帰りください。

Laravelアプリケーションのデプロイは、特にクライアントにDevOpsの経験がない小規模プロジェクトでは困難を伴うことがあります。
そこで、モジュール式のLivewireベースのパッケージ開発者がアプリケーションにセルフサービスインストーラーを埋め込むことを可能にする。このインストーラーにより、エンドユーザーは自分でLaravelアプリをデプロイして設定できるコマンドラインを操作したり、環境変数を手動で設定したりする必要はありません。
この講演では以下の内容を取り上げます。
特に共有サーバーでの小規模な Laravel プロジェクトによくあるデプロイメントの課題。
私たちのインストーラーはこれらの問題をどうやって解決するのでしょうかモジュラーLivewireコンポーネント。
デモ: 小さな Laravel アプリケーションを最初からデプロイします。
開発者がインストーラーをアプリに統合し、ニーズに合わせてカスタマイズする方法。
セルフサービス インストーラーを構築するための教訓とベスト プラクティス。

この講演は次のような方々に役立ちます:
Laravel プロジェクト (小規模なアプリ/Web サイト) を頻繁にクライアントに提供するフリーランサーや小規模な代理店。
自分自身またはユーザーのために展開を簡素化したい開発者。
実際のアプリケーション向けの Livewire ベースのモジュラー アーキテクチャに興味のある方。