トーク

僕たちが提供したいのはその技術では無く、その技術が実現する価値です。

その価値提供にFull Serverlessなシステムは非常に高い効果を発揮します。

運用レスを目指してFull Serverlessなサービスを作成し、その中での知見を共有します。

■対象
Serverlessに興味がある人

■お話すること

• AWSで構築するFull Serverlessサービス
• 個人利用を目的とした簡単なサービス
  　
  ■内容を約束出来ないこと
  　- PHP
  　- Laravel

個人開発でLaravelを使ったあるWEBアプリケーションを開発しています。
開発をする際にLaravelを使ってみてとても便利だなと思った点や、使いやすかった機能など色々と勉強になった点がたくさんありました。
このトークではその便利だと思った点、使いやすかった機能を、Laravelを扱ったことのない人にもわかりやすいように、簡単なCRUDアプリのコードを通して、余すことなく紹介できたらいいなと思っています。

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

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

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

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

対象者

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

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

フレームワークにより、アーキテクチャスタイルは異なります。
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 は 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を入れるまでの苦労話について
• どのようなハマりポイントがあったかについて
• Laravelのどの機能を使っているのかについて
• プレーンなLaravelと比べて制限される機能について

Laravelをレガシーアプリケーションに導入してみたい方、どんな構成になっているのか気になられた方、どなたでも構いません。
ご興味を持たれた方はぜひご参加ください！！

※15分バージョンです

Laravel の Blade 、便利ですよね。テンプレートエンジンとしても優秀だと私は思います。
そこで、 Blade を自作してみたいと思ったことはありませんか？ 今回は View ファイルにかかれている HTML をを字句解析していき、 Blade のようなテンプレートエンジンを Laravel を使わずに素の PHP だけで実装するお話をします。
もちろん Blade だけに関わらず、 Smarty など他のテンプレートエンジンのような形にすることも可能です。