Laravelを使っていればご存じの通り、ArtisanはLaravelのCLIインターフェイスです。

その中にはさまざまなサブコマンドが用意されていますし、ユーザーが拡張できるようにもなっています。
Artisanそのものがどのように構成されているのか、そしてそれぞれのサブコマンドがどのように実装されているかについて解説します。

フルスタックWebフレームワークLaravelの最大の特徴はEloquent。
Eloquentを制するものがLaravelを制するといっても過言ではありません。

Laravel利用者同士であれば、Eloquent Modelをどう使うか、太りがちなロジックをどう整理するかなどなど、Eloquentの話だけで一日中語り尽くせることでしょう。

最近のカンファレンスのLaravel系のトークでは、Laravel利用者が成熟してきたせいか、アーキテクチャや設計論が目立ち始め、Eloquent Model自体への評価は下降気味だと感じています。
曰く、Eloquentはやんちゃが過ぎるのでリポジトリに閉じ込めるべきである、ORMの"Model"クラスとは別のPOPOのクラスをドメインモデルとして使うべきである云々。

本トークでお伝えしたいのは、我々が普段書いているEloquent Modelのコードと、カンファレンスで話される理想的な設計の話は地続きであり、決して雲の上の出来事ではないということ。コードの良し悪しはとあるアーキテクチャやパターンを取り入れるかどうかのゼロイチで決まるものではなく、その間にある無数のトレードオフに目を向けることが大事だということ。

目の前にある泥臭いLaravelアプリケーションのコードと付き合いながら、設計について考えていきましょう。

● お話しすること

• ActiveRecordとDataMapper
• ドメインモデルと永続化モデル
• リポジトリパターン
• ドメインモデルとしてのEloquent Model
• Eloquent Modelを分割統治するためのパターン集

● お話ししないこと

• クリーンアーキテクチャ
• ドメイン駆動設計

P.S. Laravel中〜上級者の皆様へ

リポジトリパターンやクリーンアーキテクチャは本当に必要ですか？
それらが利用される本当の目的を理解して利用していますか？
POPOが正義でしょうか？
Eloquentは力をセーブさせざるを得ない悪い子でしょうか？

本トークを通じて、Laravelを使い始めた頃に感じていたEloquentの万能感を、ぜひ思い出していただければと思います。

PHPの25年の歴史にはさまざまなフレームワークがありましたが、現代と過去を分ける一つの画期として「Composer以前／以後」があります。Laravelをはじめとして、近年のPHPフレームワークとライブラリはすべてComposerを基盤にして相互運用できるように構成されています。

この発表ではComposerとPHPの機能の関係およびLaravelがComposerをどのように使っているか、そしてWebアプリケーションを本番環境で運用するためにComposerの観点からどのように注目するかについて解説します。

ステートレスなHTTPをステートフルに変えてくれる仕組みがセッションです。ユーザのログイン、リダイレクト後のエラーメッセージの表示、CSRF対策等、現代のウェブアプリケーションで多用されているセッションですが、セッションがどのように動いているかと聞かれた時に正しく答えられますか？
初心者に近いPHPerがセッションを多用すると、中堅クラスのエンジニアから「セッションは危ないから多用しないように」とアドバイスされることも多いと思いますが、それは何故でしょうか？

本トークでは、ウェブアプリケーションにおけるセッションについて、その正体を分かりやすく解説します。また、セッションの正体を知ることで、ウェブアプリケーションのアーキテクチャーに対してセッションが及ぼす影響についても解説します。セッションにまつわるアレコレを解説することで、初心者とベテランエンジニアの間に存在する知識と経験の差を少しでも埋めることが狙いです。

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

• セッションの仕組み
• Laravelにおいて無意識に利用されているセッションの例
• Laravelが独自のセッション管理を行う理由
• セッションが本番アプリのアーキテクチャに与える影響

PHP7.4から、OPCacheにpreloadという新しい設定が加わりました。この設定を利用すると、既にOPCacheを利用しているアプリケーションでも、動作速度を10倍[注1]に上げることが出来ます。

本トークでは、OPCacheの基本からおさらいし、preloadの機能を丁寧に解説した上で、Laravelで利用する場合の利用法や注意点を紹介します。
また、実際に本番で運用する際の、サーバー構成やデプロイの注意点もまとめます。

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

• OPCacheのおさらい
• preloadの仕組み
• Laravelにおけるpreloadの利用法
• 本番運用でpreloadを使うときの注意点

対象者

• OPCacheの基本を覚えたい方。
• アプリケーションのチューニングに興味がある方。

[注1] DB接続等のIOバウンドな処理が含まれない場合に限る。

Laravelは柔軟で強力なフレームワークです。
その柔軟性は、Laravelの機能をどこからでも利用できることに由来します。
Laravelの公式ドキュメント「構成の概念」章から、「サービスコンテナ」「サービスプロバイダ」「ファサード」「契約」を読み、OOPの観点からそれぞれの考え方を比較します。

tl:dr

このセッションでは、Laravelの上で、新原さんの独立したコアレイヤパターン、テスト駆動開発、 LarastanやPHP Insightsといった静的解析ツール、Circle CIを取り入れて、個人開発でも継続的かつ安定的にソフトウェアを進化させるための取り組みをしているという話をします。

概要

個人開発のウェブサイトでも企業のプロダクトと同じように、ユーザーの満足度を向上させるために日々進化させていかなければなりません。

しかし、個人開発では、平日の朝や晩、土日の予定のない日という限られた時間しか使えません（お金も出ません）。
このため、開発スピードを落とさないことは重要です。
開発スピードが早ければ早いほど、次の施策を考えたり、自分の余暇の時間を増やすことができるためです。

では、節約できる時間は何でしょうか。それは、新機能を開発する時間だけではなく、既存のコードを変更する時間、バグを修正する時間、毎回デプロイをする時間です。
継続的にソフトウェアを進化させるための種々のプラクティスを取り入れたら、開発における無駄な時間を減らし、新しいコードを怖がらずに追加できるようになったので、そのプラクティスを紹介します。

We all love the elegance and high maintainability of Laravel. And we all know the the performance of PHP has amazingly improved from PHP 5 to PHP 7 in the past few years. However, in some cases, when your website faces high traffic, you still need to optimize your code and architecture in case your server went down.

In this talk, I will introduce some performance tuning skills in PHP and Laravel. Moreover, I will share with you some advanced thoughts and web architecture design for high concurrency in different use cases.

In this agenda Sasaya will share with you how to make your Laravel smarter, more convenient and easier to use through magic.
Clever use of SOLID principles and Laravel Container to make testing easier.
Clever use of OOP concepts and Design Patterns to make code more reusable.
Clever use of Metaprogramming to eliminate all unnecessary code, enabling developers to focus on business logic.
Accroding to above, they allow engineers to spend time in the worthy way, thereby improving development efficiency and increasing team production value.

私たちデベロッパーはLaravelを愛用しているが、PHP由来の制限があり、またLaravelのRAMへの負荷によって、高い並列処理 (High Concurrency) 負荷への対応に課題がある。一方、Swooleの登場は、デベロッパーに希望を与えた。そこで、Swooleの速度効果とLaravelの表現力の両立で、開発フレームワークに新たな手法を見せられないかと悩んでいたところ、幸いにHyperfを利用することで、その潜在能力を引き出すことができると分かった。この発表は、まず、各開発フレームワークの効率を比較し、LaravelのデメリットとHyperfのメリットを説明する。次に、アプリケーションを実例として、両フレームワークを利用した開発上の違いを比較する。また、デベロッパーがHyperfを活用しやすくなるように、開発テクニックをシェアする。今回の発表によって、より多くのPHP/Laravelデベロッパーがコンフォートゾーンから一歩踏み出し、更なる開発に取り組んでくれることを期待している。(このトークは英語で発表いたします)

現在プログラミング教室に務めており、生徒にヒアリングしながら教材作成に取り組んでいます。
今勉強中の人、これから勉強する人、初心者に指導していく人に向けて有意義な共有ができればなと思い応募しました！

現在考えている内容としては以下２点を重点的に掘れればいいなと思っています。

・初学者は何がわからないのか
・Laravelこう教えるといい感じ

よろしくお願いします！

普段なにげなく使用しているフレームワークの中身、どのくらい知っていますか？
本セッションではLaravel Frameworkの中でも特徴的な実装をわかりやすく解説します。

ServiceCotainerやFacade(Real TIme Facade)、ミドルウェア、Eloquent…フレームワークの実装はなかなかに興味深いものだということ、フレームワークの実装を知ることでトラブルを未然に回避できるということ、PHPという言語の面白さを伝えることができればと思います。

LaravelはWebアプリケーションを開発する上で必要な機能が揃っているよくできたフレームワークですが、フルスタックがゆえに、遅い・重いイメージを持たれている方も多いのではないでしょうか？
APIサーバーをLaravelで開発し、Amazon ECS上で運用してきた中で、これまでに取り組んできた負荷対策についてお話しします。

ざっくり、以下のような内容を考えています。

• まずは負荷テストをしてボトルネックを明らかにする
• とにかくキャッシュ
• キャッシュし過ぎたせいか、Redisへの接続数が激増
• 一部のキャッシュをAPCuに逃す
• Read Replica / Write Master
• AWS Fargate にて php-fpm が悲鳴をあげる（11: Resource temporarily unavailable）
• AWS Fargate から EC2 へ変更
• Capacity Provider によるスケーリング戦略

プロポーザル提出時点で、取り組んでいる最中の対策も含みますが、当日（2020/3/21）までには対策を完了し、整理してお話しできるように頑張りますので、期待していてください！

プッシュ通知の配信は、ReproやOneSignalといったサービスを利用する事が一般的です。
しかし、リミアではサーバ側の入稿及び配信システムを内製化しました。
内製化した理由、プッシュ通知の仕組み、開発したシステム、それを使った業務改善事例について説明します。
このセッションを聞く事で、プッシュ通知の仕組みや改善事例について把握できるだけでなく、静的型付言語が使われている場所にPHPを導入する参考事例を知る事ができます。

中学生の頃にMSXというパソコンのCPUであるZ80のプログラミングを体験していました。

その約25年後、2016年にPHPで書かれたゲームボーイエミュレータのコードを読んで衝撃を受けました。ゲームボーイのCPUはZ80ベースであり、エミュレータで実装されていたのはまさにZ80の命令だったのです。この体験で、エミュレータがハードウェア仕様をソフトウェア的に表現したものであることを理解しました。

そしてさらにその3年後。名著「CPUの創りかた」で紹介されているCPU、TD4を実装し衝撃を受けました。そこに見たCPUは電気回路として表現された状態機械でした。

このトークではPHPでTD4のエミュレータを実装し、マシン語実行環境、エミュレータの対象、そして電気回路としてのCPUがどの様に動作するのかを解説し、CPUの魅力をみなさまにお伝えします！

昨年のデプロイ戦略に続き、今年はAWS Lambdaへのデプロイ一本でお話します。
PHP以外の言語では、サーバレスの話題が多くなっていますが、PHPではまだまだ実例が少ないと思います。

本トークでは、Brefを利用し、既存のLaravelプロジェクトを明日からでもLambdaで動かすために必要なポイントを解説します。
LaravelをLambdaで動かすことにより、PHPerはよりコードに集中できるようになり、スケーラブルなシステムを構築可能です。コストも大幅に削減できます。

明日からサーバレスの世界に踏み出しましょう。

開発初期段階ではテーブル構成の変更が激しく、マイグレーションファイルの管理が混沌となっていました。

• カラムの増減のたびに追加されるマイグレーションファイル
• 使用されないテーブルのマイグレーションファイル
• upとdownの整合性を保つコスト
• 最新のテーブル構成をマイグレーションファイルから読み取れない

開発段階はカジュアルに、スムーズにテーブル構成を変更して高い開発をしたい！

そんな要望に応えるためLaravel開発者のDX(開発者体験)を爆上げする、
Laravelのマイグレーションファイル生成サポートツール「laravel-dacapo」を開発したお話をします。

RDBはアプリケーションの心臓部です。たった1つのSQLがサービス全体に深刻な負荷を与えることも珍しくありません。

SQLを意識せずコードが書けるのはEloquentの大きなメリットですが、実際のSQLを書けない分だけトラブルシューティングは難しくなります。

意図せぬ負荷は避けたいが、普段はSQLを意識せずコードを書きたい。

この両立は可能でしょうか？データベースエンジニアの立場からお話しします。SQLの知識の有無は問わない内容です。

注)この話はフィクションです。きっと。

■対象
・今最新を使っている人(メインターゲットです)
・これからやる人
・もうやって、あるある話を聞いて涙したい人

皆さん、バージョンアップしてますか？
PHPや、Laravel、古くなってきたからバージョンアップしよう。
よくある話ですね。

でも、何も考えずにプログラムを書くと、あとで痛い目を見ます。

これは、本当にあったかはわからない、バージョンアップで悲しみを背負った人の話。

■内容
・vendor配下をいじった報い
・コードをコピペで拡張した悲しみ
・Laravelを見捨ててPHP上げたらLaravelがお亡くなりに
・テストコードなんてなかった
・このライブラリはもう居ない
・消えた機能
・見つからない変更点
・再度襲いかかるコピペの悲しみ
・見えない終わり
・把握できない予算、見積もり
・PHPのアプデは簡単だったという圧力
・本当はマイナーバージョンアップではない誤解
・把握できないバージョンアップの利点

「 LaravelDB.com 」
https://qiita.com/daisu_yamazaki/items/3755467b39ef158b81a3
を参考に見てください。『Laravelを使う人を幸せにしたいという思いから作った』アプリケーションです。
これは「あったら便利だ！！」の思いから作った始まりから〜完成するまで、そして操作方法や勘所など全て話せたらと思います。
一念発起して作り始めたはいいが、、、カラムとMigration等の想定外のことやCRUD生成処理の想定外など結構大変な開発でした。
操作方法含め、お話できればと思います。