Laravel を使う上で、Eloquent にお世話になっている人は多いのではないでしょうか。
ドキュメントを読んでみると、モデル定義、ソフトデリート、クエリスコープ、イベントオブサーバーなど便利な機能がいくつも提供されています。
そんな Eloqunet が内部ではどのような作りになっているのか、実際のソースコードを見ながら解説します。

更なる Laravel の理解や OSS コントリビュートなど "単なる Laravel 使用者のその先" へ進む一歩として、本セッションが少しでもお役に立てればと存じています。当セッションでは Laravel/framework 6.x を用いて解説する予定です。

Rails歴1年半、Laravel歴1年半のよしにゃんが、現場での体験からの比較をお話します。

・環境構築時
・DB作成時
・自分で書いたものや人のソースを読むとき
・DI
・設計

優しいマサカリをください。

フレームワークにより、アーキテクチャスタイルは異なります。
LumenはMVC、Slim 4はSkeltonを使うとADR（Action Domain Responder）、BEAR.SundayはRMR（Resource Method Representation）です。

軽量なAPIサーバーを構築するにあたり、各マイクロフレームワークを比較しました。
アプリケーションを堅牢に構築したいため、実際にテストを書いてみたところ、マイクロフレームワークごとのアーキテクチャスタイルの違いが明確になりましたのでご紹介します。

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

tl:dr

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

概要

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

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

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

Snipe-IT という知る人ぞ知る資産管理ツールがあります。
Version 1.0 が 2014年10月にリリースされて以来、開発が活発に継続しているLaravelベースのOSSプロダクトです。

このトークでは、スプレッドシートでのやや煩雑な管理から脱却することができて業務改善成功を生んでくれたこの Snipe-IT を、
まずは知っていただきたいと考えています。

そして、これから Laravel でプロダクトを作っていこうとしている中級くらいの開発者に向けて、共にこのソースコードを読み、
実に様々な機能が盛り込まれているところから学んでいこう、と呼びかけができるとうれしいです。

新たな世界を開く可能性を感じたこのOSSへのコントリビュートに向き合えるナカマを増やせるよう、話ができればと思います。

PHPのプロではなかったのですが、
Laravelというフレームワークとコミュニティの力で乗り切れました。
話せる範囲で全体のインフラ構成、アプリ設計、注意した点
、営業やチーム開発でのノウハウ、勉強法などについて話そうと思います。

• Typed properties
• Arrow functions
• Null coalescing assignment operator
• Unpacking inside arrays
• Preloading

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 artisan clear-compiled
php artisan config:cache
php artisan route:clear
php artisan view:clear
php artisan cache:clear

そして、 composer dump-autoload

これらをまとめて実行するコマンドは、Makefileで容易に作成できて、再利用性・拡張性も抜群です。
また、docker-compose のように打つのは長いんだけど頻繁に使うツールの活用にも適用可能です。

このトークでは、自身の開発効率化を実現できている この Makefile 作戦の実例と、
簡素化にはつきものなトラブル対処法をご紹介します。

We are lazy because we are developers. :) So we are interested in how to boost our productivity when we develop. In this talk, I will share several tips that could boost your development speed. Bash config, emmet, reformator, CI are included. You could use these tips immediately in your daily job.

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

皆さんは勉強会を主催してみたいと思ったことはありませんか？
私は不定期でPHPで学ぶデザインパターンの勉強会を開催しています。

きっかけは、オフィスの会議室で行った、昨年のPHPerKaigi 2019の動画上映会でした。
当日のセッションで学んだ内容が非常に為になる内容だと思ったので、社内のメンバーにも内容を共有したいと思いました。
上映会は大盛況で、参加者と様々な議論を交わしていくことで、より理解を深めることができました。
このことがきっかけで、「自分が学ぼうとする領域を他の人と一緒に勉強することで、より効率的かつ楽しみながら勉強できるのではないか」と思い、
上映会でも盛り上がっていたデザインパターンをPHPで学ぶ勉強会を開催することにしました。

この発表では、勉強会を主催しようなんて思いもしなかったエンジニアが、自主的に勉強会を開くようになるまでのマインドの変化と自身の環境の変化についてお話できればと思います。

「PHP の仕様は RFC によって決められている。」これは PHPer ならご存知かと思います。
技術ブログや Twitter でときどき取り上げられる RFC ですが、実は自分で読んだことがない方は多いのではないでしょうか。
RFC は大抵の場合、我々より PHP に精通した人が提案し、議論し、要否を決定しているため、RFC を読み、その提案理由を考えることは、PHP 上級者への一歩です。
しかし、RFC は英語で記述されていますし、そもそもの仕組みを理解していない場合はどこから手をつけていいのかわからないなど、ハードルが高くないでしょうか。
本セッションでは、そんな PHP の RFC について、他の言語とも比較しながら、仕様が決定されるまでの基本的な仕組みや、読み方を紹介します。

「PHP の仕様は RFC によって決められている。」これは PHPer ならご存知かと思います。
技術ブログや Twitter でときどき取り上げられる RFC ですが、実は自分で読んだことがない方は多いのではないでしょうか。
RFC は大抵の場合、我々より PHP に精通した人が提案し、議論し、要否を決定しているため、RFC を読み、その提案理由を考えることは、PHP 上級者への一歩です。
しかし、RFC は英語で記述されていますし、そもそもの仕組みを理解していない場合はどこから手をつけていいのかわからないなど、ハードルが高くないでしょうか。
本セッションでは、そんな PHP の RFC について、他の言語とも比較しながら、仕様が決定されるまでの基本的な仕組みや、読み方を紹介します。

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

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

・初学者は何がわからないのか
・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）までには対策を完了し、整理してお話しできるように頑張りますので、期待していてください！