これはなに
カンファレンス資料だいたい読む
元ネタの一覧はこちら
https://qiita.com/ucan-lab/items/12da9bf12268329bcf3a
読む
ServiceProvider, ServiceContainer 入門
- サービスプロバイダ
- なんか依存性注入を解決してくれるやつ
- DIの説明
- コンストラスタインジェクションの説明
- それまでコンストラクタの中で生成していたインスタンスを、コンストラクタ引数経由で外から渡してあげること
- サービスコンテナ、サービスプロバイダ
- DIすると起きるインスタンスの管理について
- サービスをDIしなかったらコンストラクタに直に書いておわり
- サービスをDIすると呼び出す側で毎回newする。設定内容が多くなると、すべての箇所に呪文が書かれる
- DIのデメリットまとめ
- サービスは本来ドメイン処理とは別もの、ドメインロジックに書きたくない
- 生成処理を別の場所でやってほしい
- 設定内容の管理もしたくない
- サービスコンテナとは？
- サービス名とサービスのファイル？ のグローバルな連想配列
- 配列のことをコンテナって呼んでんのか？
- これどこに書いてあるんだろう
- appもその一つ
- resolve()でサービスをコンテナから取得できる
- サービスプロバイダとは
- サービスコンテナへのデータ登録を管理
- アプリケーションの初期に呼ばれてサービスコンテナの使用準備をする
- このkeyのサービスが呼ばれたらこのインスタンスを返すよ、みたいに書く
- 自動注入
- サービスプロバイダでkeyをクラス名にする
- インスタンスの引数でクラス指定すると、それだけでインスタンス生成してくれる
- ここ、どういう仕組みなんだ、、
- 感想
- もうひとつ欲しかった、引数に型指定するだけでどうやってサービスプロバイダの処理をやらせるんだ
- chatGPT曰く、依存性注入コンテナというのがあるらしい。
- この記事昔読んでわかりやすかったな
- これの、bind()の仕組みを知りたいんだよな、あとresolveなしにやる方法
- chatGPTが答えてくれた
- Illuminate\Container\Containerクラスを拡張して依存性注入コンテナは作られている
- コントローラーとかで型ヒントが使用されるたびに依存性注入コンテナが動いて、インスタンスを返してくれている
- これがどのタイミングで動いてるのか？ とか気になるけど、まあ一旦良いきがする
- まあ、読むしかないのかなコードを、、
フレームワークとの付き合い方
- 概要
- フレームワークは楽をするため
- フレームワークは汎用的
- 合わないところもある、無理に合わせて苦労するのは本末転倒
- どこをカスタマイズすべきか？ の発表
- カスタマイズできる点
- Eloquent使わずにSQLをかく
- えろけんとの中にとじこめて実装
- 特定のEPのみ速度をあげるために、フレームワーク外で処理する
- PurePHPで処理する
- フレームワークのライフタイム
- フレームワークよりもアプリケーションの方が長生きする
- バージョンアップ対応が発生する
- フレームワークと距離を取る
- app配下にぜんぶかかない
- コントローラーにドメインロジックを書かない
- コントローラーはフレームワークと密結合になりがち
- どんなふうにバージョンアップ対応したか？
- サービスレイヤをコピーした
- えろけんとは多少書き換えた
- あとはテストで動作確認
- 感想
- いいねえっておもった！
Laravelでパッケージ開発
- なんか、パッケージ開発のやり方っぽい
- ServiceProviderを起点にと書いてあるから、そんなに難しくなくやれるのかな？
- service providerのbootで色んな指定ができる
- ルートファイルとか、viewとか、migrationとか
- もっと簡単にパッケージ開発
- composerの設定でちいさなLaravelを複数作れる、依存を切り離せる
- たしかにこれは良いかも？ モジュラーモノリス？？？
- 感想
- 具体的なところはわからないけど、app配下にひとまとめになっていたやつを分離できるのは良いかも
SimpleとEasyは違う
- 最近の話
- LaravelMix
- Laravelのwebpackドライバー
- なんか使うためには色々考えなきゃダメだったらしい
- Vue Vuex
- VxexはVueのv-modelが使えない
- vessel
- 21ぱいろっつ
- dockerでLaravel使うやつ
- 簡単に始められてもその後シンプルに進められるとは限らない
- 色々やってくれるやつは、依存しないといけないからややこし
- 不要な複雑性は消そう
- やり方
- いらんもんは消す
- 隠蔽しない
- 隠蔽てかモジュールの流動細かくして扱いやすくする感じがあるが
- 隠蔽って、見えちゃダメなものを見せないことなので、見せるべきなものを見せてないのは隠蔽ですらないのでは
- まとめない
- 密結合はやめる
- 作りすぎない
- めんどくさいことをやってくれるスクリプト
- 感想
- 後輩を公でけなすの、良くないゾォ〜
- 抽象的でLaravel関係ないし…
エキテンとLaravelとわたし
- モノリスなサービスの一部を切り出してマイクロサービスとしたPJの感想
- やばい部分
- Laravelの機能を使えてない
- ひとつのモデルに複数TBLが紐付く
- Service Containerも使えない
- おれおれフレームワーク
- Laravelの闇拡張してるのでそうなる
- 良かったこと
- docker入れられた
- 自動テストできた
- アクセスの70%がマイクロサービス側にいき、重要な施策が打ちやすくなった
- ドメイン層以上は綺麗になっている
- 腐敗防止層を入れてる
- 感想
- Good
- 自分たちで変えていける
LaravelでのAPI開発を爆速にするためにやっていること
- DX向上のためにやっていること
- フロント、API別リポジトリ化
- SPAにしたそうな
- APIスペック自動出力
- SPA, APIの特徴として、通信インタフェースを定義しないと壊れやすいというのがある
- Featureテストの記述でRFC7230ベースのファイルが作られる
- swagger的なものっぽい
- それが必要になるってわからんな、テストの方が必要そうだけど
Webアプリケーションが今こそ知るべきRDBのパフォーマンスチューニングの勘所
- WebアプリケーションのパフォーマンスチューニングをRDBの観点からやるやつ
- SQLを実行するときのながれ
- クライアント
- がSQLを実行
- パーサ、リライタ
- が構文解析、構文木を生成
- プランナ、オプティマイザ
- が最適な実行計画を生成。INDEX利用の有無、JOINのアルゴリズムなどを決める
- エグゼキュータ
- が実行計画に基づきクエリを実行し、データを取得
- で結果が返ってくる
- だいたい遅いのはエグゼキュータ
- 実行計画で決まる
- 実行計画の話はこちら
- エグゼキューターが重いのは
- 苦手な実行計画になってる
- RDBのらしくないやつとは？
- INDEXを利用できてない
- 不要で大きなデータを取得している
- 複数回クエリを発行している（N+1）
- テーブル設計が悪い
- 不要で大きなデータを取得
- いらないデータをselectに含めてる
- インプリシットカラムてアンチパターン
- 小さくするには？
- where句で小さくする
- From句で小さくする
- 不要なJoinをなくす
- N+1問題
- ORMやクエリビルダーが実行するクエリを知るのが大切
- テーブル設計が悪い
- RDBらしくつくる
- 苦手なことはそもRDB使わない
- NoSQLとか使う
- INDEXとJOIN
- INDEXのあるなし
- ありならB+treeの仕組みで高速に検索可能
- なしならフルスキャン
- INDEXの効かない例
- 検索結果が多い
- 全体の件数が少ない
- 条件にその列を使ってない
- カーディナリティの低い列に対する検索
- あいまいな検索
- 統計情報と実際のTBLに乖離がある
- JOINの種類と仕組み
- JOINは集合
- これ分かりやすいな、言われてみればそうだ、すごい簡単
- JOINの種類
- Nested Loop JOIN
- Hash JOIN
- Merge JOIN
- NLJOIN
- 結合キーが一意だったりINDEX貼られたりしてるとうまいこといく
- 基本は掛け算
- 適切なINDEXがあると
- JOINはハイコストだけど、INDEXがあれば高速になる
- フレームワーク依存症
- ORMは完全ではない
- 制約を課すことで生産性を生み出す
- 感想
- やっぱ有名な人は面白いな
- INDEXがどうこうを覚えるのと、あとあれだ、ORMの使い方とか覚える…
Laravelのデプロイ戦略。VPSからDocker、Kubernates、サーバレスまで
- デプロイ戦略の考えるポイント紹介
- 理想のデプロイ
- なんも考えなくて良いやつ
- デプロイを知る
- サーバーデプロイ
- PaaS
- PaaSの流儀に沿ってやる。環境差分は免れない
- Docker
- 環境差分を消せる
- Dockerコンテナをどうデプロイするのかが問題
- それぞれの戦略
- サーバーデプロイ
- まずはデプロイ自動化
- 指定した永続データ以外は捨て去っても問題ない状態を目指す
- PaaS
- 流儀に乗っかるのが大切
- Docker
- なんかポリシーがいる
- 一台からスケール可能なサービスへ
- なんかわちゃわちゃ
- 初期から見据えておくべきポイント
- 早期のオートスケール対応
- CI/CD対応
- Laravelのオートスケール対応
- confとかsessionとか一台前提でやらない
- configuration
- 実値使わない、envや環境変数から取るようにする
- FileStrage
- アップロード先の変更は簡単
- S3をぜひ使おう
- Session
- 変更は実際にスケールするタイミングでよし
- radisかmemcachedがおすすめ
- だいたいクラウドにマネージドサービスがある
- Database
- 最初から読み書きは分けた方がよいらしい
- multi-AZなら分離させてひとつ下のスペックのリードを複数持たせる方がよい
- Queues
- 確実なjob実行におすすめ
- こいつはスケールそんなに意識しない
- Task Scheduling
- cronの実行
- 失敗の管理
- デーモンではないから相性の悪いタスクがあるらしい
- ひとつのサーバーで動かさないといけないタスクに注意
- 周辺ポイント
- docker
- CICD必須
- 本番開発両方で使えるベースコンテナをつくる
- 本番ではかならずソースをビルドしてコンテナ内にいれる
- dockerでローカル開発
- AWSのセキュリティ
- IAMを使おう
- 権限設定もちゃんとしよ
- dockerのセキュリティ
- dockerのコンテナはbuildしたときのまま、脆弱性もそのまま
- ベースコンテナは身元明らかなものを使おう
- クラウド対応
- メールは外部のSMTP
- ログ
- 出す。CloudWatchとかでできる。
- サーバ監視
- やろう、datadogとか入れよう
- 例外ハンドラ
- sentry, bugsnugでいつ何が起きたかわかるようになる
- 感想
- いろんなこと知ってるね
リリース直前にLumenからLaravelに移行した話
- 資料のリンク切れ
チャットディーラーの高速開発を支えるLaravel
- Laravelで開発してみての感想
- はい
Laravelで学ぶ Webアプリケーションチューニングの基本
- パフォーマンスチューニングのやり方
- 全体を見る
- パフォーマンスを科学する
- webアプリの責任？
- サーバーメトリクスを確認する
- webアプリの処理を特定する
- プロファイリングする
- 改善ループを回す
- よくある問題処理とその対処
- 推測すな、計測せい
- 遅い、ではなくどんなときにどれくらい遅いのか？ を明確にする
- 全体を見る
- webアプリの領域はかなりせまい
- そもそも遅いのはアプリケーションが原因ではないかも
- どこが重いのかを科学的に突き止めないといけない
- パフォーマンスを科学する
- レイテンシー
- 状態遷移にかかった時間のこと
- webアプリ単体のレイテンシーに問題がないなら、他に理由がある
- webアプリ単体のレイテンシーはレスポンスタイムで知ることができる
- これはWebサーバからログに出せる
- この遅さは本当にWebアプリの責任か？
- サーバーメトリクスを確認する
- webサーバで他のプロセスが動いていた、とかはある
- 継続的な計測がないとわからない
- ボトルネックを特定する
- どの処理が重いのかをみる
- その上でWebアプリが重たいと分かったら？
- webアプリの処理を特定する
- webアプリの何が重たいか？ はURL単位のレスポンスタイムで測れる
- awk, alp, kataribeなど。newRelicなど。
- プロファイリングする
- どの処理にどのくらい時間かかってるか示したもの
- blackfire.ioとからしい
- 改善ループ
- 重い処理はプロファイラがみつける
- それなおすだけ
- よくある問題と対処法
- APIコール
- キャッシュ
- 複数のAPIをまとめてしまう
- フロントのJSにまかせる？
- メール、slack送信
- 同期処理にすな、Queueにせい
- SQLクエリ
- INDEXとか
- 計算量の多いプログラム
- レビューで防ぐ
- まとめ
- チューニングの方法は結局ふたつくらい
- アルゴリズム変更
- 非同期処理化
- 感想
- ツール入れてみたいかも
新卒2年目がLaravelコントリビュート出来た理由とその面白さ
- 感想
- たのしそうでいいね
- 気軽で良い
抽象化って何？
- ようわからん