現在のLaravelは近年の多くのPHPフレームワークと同様にComposerを基盤として構成されており、Packagistに登録された多数のPHPライブラリと簡単に相互運用できるようになっています。
この発表ではComposerの基本機能およびLaravelとComposerの関係、そしてComposerの設定方法などをまとめて解説します。
僕たちが提供したいのはその技術では無く、その技術が実現する価値です。
その価値提供にFull Serverlessなシステムは非常に高い効果を発揮します。
運用レスを目指してFull Serverlessなサービスを作成し、その中での知見を共有します。
■対象
Serverlessに興味がある人
■お話すること
個人開発でLaravelを使ったあるWEBアプリケーションを開発しています。
開発をする際にLaravelを使ってみてとても便利だなと思った点や、使いやすかった機能など色々と勉強になった点がたくさんありました。
このトークではその便利だと思った点、使いやすかった機能を、Laravelを扱ったことのない人にもわかりやすいように、簡単なCRUDアプリのコードを通して、余すことなく紹介できたらいいなと思っています。
PHP7.4から、OPCacheにpreloadという新しい設定が加わりました。この設定を利用すると、既にOPCacheを利用しているアプリケーションでも、動作速度を10倍[注1]に上げることが出来ます。
本トークでは、OPCacheの基本からおさらいし、preloadの機能を丁寧に解説した上で、Laravelで利用する場合の利用法や注意点を紹介します。
また、実際に本番で運用する際の、サーバー構成やデプロイの注意点もまとめます。
このトークでお話すること
対象者
[注1] DB接続等のIOバウンドな処理が含まれない場合に限る。
Serverless PHP は作れる
Serverless Laravel といえば Laravel Vaporを思い浮かべる人が多いのでは無いでしょうか
Laravel Vaporが作れる様にAWSのArchitectureを正しく理解していればServerless PHPは作れます
今回はLaravel Vaporが担っている基本要素を自ら構築してみようと思います
本セッションを通してServerless Architectureの知見が広まる事を本セッションを目的とします
■聴講者ターゲット
■お話する内容
■お話しない内容
Laravel を使う上で、Eloquent にお世話になっている人は多いのではないでしょうか。
ドキュメントを読んでみると、モデル定義、ソフトデリート、クエリスコープ、イベントオブサーバーなど便利な機能がいくつも提供されています。
そんな Eloqunet が内部ではどのような作りになっているのか、実際のソースコードを見ながら解説します。
更なる Laravel の理解や OSS コントリビュートなど "単なる Laravel 使用者のその先" へ進む一歩として、本セッションが少しでもお役に立てればと存じています。当セッションでは Laravel/framework 6.x を用いて解説する予定です。
フレームワークにより、アーキテクチャスタイルは異なります。
LumenはMVC、Slim 4はSkeltonを使うとADR(Action Domain Responder)、BEAR.SundayはRMR(Resource Method Representation)です。
軽量なAPIサーバーを構築するにあたり、各マイクロフレームワークを比較しました。
アプリケーションを堅牢に構築したいため、実際にテストを書いてみたところ、マイクロフレームワークごとのアーキテクチャスタイルの違いが明確になりましたのでご紹介します。
Snipe-IT という知る人ぞ知る資産管理ツールがあります。
Version 1.0 が 2014年10月にリリースされて以来、開発が活発に継続しているLaravelベースのOSSプロダクトです。
このトークでは、スプレッドシートでのやや煩雑な管理から脱却することができて業務改善成功を生んでくれたこの Snipe-IT を、
まずは知っていただきたいと考えています。
そして、これから Laravel でプロダクトを作っていこうとしている中級くらいの開発者に向けて、共にこのソースコードを読み、
実に様々な機能が盛り込まれているところから学んでいこう、と呼びかけができるとうれしいです。
新たな世界を開く可能性を感じたこのOSSへのコントリビュートに向き合えるナカマを増やせるよう、話ができればと思います。
PHPのプロではなかったのですが、
Laravelというフレームワークとコミュニティの力で乗り切れました。
話せる範囲で全体のインフラ構成、アプリ設計、注意した点
、営業やチーム開発でのノウハウ、勉強法などについて話そうと思います。
「PHP の仕様は RFC によって決められている。」これは PHPer ならご存知かと思います。
技術ブログや Twitter でときどき取り上げられる RFC ですが、実は自分で読んだことがない方は多いのではないでしょうか。
RFC は大抵の場合、我々より PHP に精通した人が提案し、議論し、要否を決定しているため、RFC を読み、その提案理由を考えることは、PHP 上級者への一歩です。
しかし、RFC は英語で記述されていますし、そもそもの仕組みを理解していない場合はどこから手をつけていいのかわからないなど、ハードルが高くないでしょうか。
本セッションでは、そんな PHP の RFC について、他の言語とも比較しながら、仕様が決定されるまでの基本的な仕組みや、読み方を紹介します。
昨今、プロジェクトの進め方の一つとして、テスト駆動開発が注目されています。
本セッションでは、Laravelを使ったプロジェクトでテスト駆動開発をどの様に進めればいいのかについて
事例を上げながら、説明いたします。
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)までには対策を完了し、整理してお話しできるように頑張りますので、期待していてください!
Laravelはあらゆる規模や用途のアプリケーションに対応する柔軟なフレームワークです。
柔軟さ故に機能は幅広く、全体に精通するのは容易ではありません。Welcome画面の次に何を学ぶべきなのか解らず戸惑った方は多いのではないでしょうか。
このセッションではLaravelの全体像をユースケースやレイヤー毎に分類することで、これからLaravelを学び始める方やプロジェクトに導入しようとしている方へ学習や検討の指標を提供します。
RDBはアプリケーションの心臓部です。たった1つのSQLがサービス全体に深刻な負荷を与えることも珍しくありません。
SQLを意識せずコードが書けるのはEloquentの大きなメリットですが、実際のSQLを書けない分だけトラブルシューティングは難しくなります。
意図せぬ負荷は避けたいが、普段はSQLを意識せずコードを書きたい。
この両立は可能でしょうか?データベースエンジニアの立場からお話しします。SQLの知識の有無は問わない内容です。
GitHub 上で PHP の関数やクラスにマウスをあてるとポップアップが表示され、該当の引数の数や、サマリを表示したりマニュアルに飛べたりする Chrome 拡張機能の GitHub PHP Function Jumper の開発の苦労話からどのように作ったのか、 Chrome Web Store への公開、そして今後の展望をノンストップでお届けします。
https://chrome.google.com/webstore/detail/github-php-function-jumpe/pmgmgaejgbjiooiklinoelilmnldlhcf
注)この話はフィクションです。きっと。
■対象
・今最新を使っている人(メインターゲットです)
・これからやる人
・もうやって、あるある話を聞いて涙したい人
皆さん、バージョンアップしてますか?
PHPや、Laravel、古くなってきたからバージョンアップしよう。
よくある話ですね。
でも、何も考えずにプログラムを書くと、あとで痛い目を見ます。
これは、本当にあったかはわからない、バージョンアップで悲しみを背負った人の話。
■内容
・vendor配下をいじった報い
・コードをコピペで拡張した悲しみ
・Laravelを見捨ててPHP上げたらLaravelがお亡くなりに
・テストコードなんてなかった
・このライブラリはもう居ない
・消えた機能
・見つからない変更点
・再度襲いかかるコピペの悲しみ
LaravelとVue.jsはセットで使われることが多いと思いますが、MPAに関連する内容というものは中々目にしないように感じます。
このセッションでは、私が実際の業務を通して、
LaravelとVue.jsを使用してMPAを作って感じた課題、それをどう解決していったのかをお話します。
このセッションを聞くと、LaravelとVue.jsでMPAを作るときに、Vue.jsのコードを書く上で快適で柔軟な対応を取る1つの指針になるでしょう。
また、私自身がまだ見えていない課題の領域へ、一歩踏み出す足掛かりになるかもしれません。
※このセッションは、Laravelの資源を利用する形でVue.jsでのフロントエンドの開発を快適にするため、Vue.jsの要素が強めです。
今でこそ PHP は CakePHP, Laravel など多岐にわたるフレームワークがあり、私達開発者はそれぞれのルールに則り言語の仕組み自体をそこまで知らなくても開発ができるようになりました。
品質を担保するためにはチーム開発では、より最適化されたコードをいかに多く生み出せるかだと私は考えています。ルールが存在するということは、そのフレームワークに最適化されているということとも捉えることができます。とても開発しやすい時代になったと考えます。
しかし、昔の PHP はどうでしたでしょうか。 PHP 4 の時代、私達はどのようにしてサービスやプロダクトを作ってきたのでしょうか。そして、 PHP 5 が登場したあの時の感動、 create_function から無名関数に次第に置き換わっていく快感、配列のシンタックスが array から [ と ] に変わった瞬間、そして PHP 7 が登場し、PHPer 達が驚愕したあの瞬間。
そんな PHP 4 の時代, PHP 5 の時代 そして PHP 7 に移り変わる歴史的な瞬間、それらを昔話を交えながらお話しようと思います。
皆さん、Laravelは大好きですか?私は大好きです。
皆さん、オレオレフレームワーク使ってますか?私は使っています。
今やPHPでWEBアプリケーションを作るならLaravelが候補に挙がるくらいには有名になりましたが、それはあくまでも新規案件のお話。
今回ご紹介するのは、レガシーなPHPアプリケーションにLaravelを導入したお話です。
しかしながら、一言に導入すると言っても、それは簡単な話ではありません。
いきなり全部のコードを入れ替えるわけにもいきません。
既存のサービスを止めるわけにもいきません。
Laravelは導入するけど、既存の資産はそのまま使いたい…!
などなど、いろいろな要望や懸念があるかと思います。
そんな中、私が担当するPHPアプリケーションでLaravelを導入するために取った戦略とは…!?
本セッションでは、以下のことを実際の実装を見つつハートフルにお伝えする予定です。
Laravelをレガシーアプリケーションに導入してみたい方、どんな構成になっているのか気になられた方、どなたでも構いません。
ご興味を持たれた方はぜひご参加ください!!
※15分バージョンです
Laravel の Blade 、便利ですよね。テンプレートエンジンとしても優秀だと私は思います。
そこで、 Blade を自作してみたいと思ったことはありませんか? 今回は View ファイルにかかれている HTML をを字句解析していき、 Blade のようなテンプレートエンジンを Laravel を使わずに素の PHP だけで実装するお話をします。
もちろん Blade だけに関わらず、 Smarty など他のテンプレートエンジンのような形にすることも可能です。