Laravel.shibuya 3 IRTまとめ
IRT 1 -- PHP
traitについて
- いつ使う・使わない
- テストで使いました
- 認証が必要なテストで、認証コードとテストデータだけtrait化
- プロダクトコードではオブジェクトの委譲のほうがうまくいった
- 特定のメソッドだけmockしたいときに、無名クラスを普通に注入したほうがうまくいった
- cf. mockeryだとすべてのメソッドがモックされてしまう
- partial mock使えばいいよ!
- テストで使いました
- interface (-able)を実装するために使ってます
- 多重継承ができないため
- interfaceとtraitとclass 3つ見ないといけないのつらい
- PHPのtrait、機能が十分でない説
- traitがないころのPHPで、継承しまくりコードを触っている。つらい
- 「xxできるooクラス」を表現するためにTemplate Method Patternが4重くらいになったクラス
- 垂直ではなく水平に逃がすためのtrait
- そもそもtraitってなに
- 処理をまとまった単位で切り出すためのもの
- あるクラスに直接処理を記述すると、その処理はそのクラスと密結合になってしまう
- ヘルパに近い
- 委譲は大げさなケース
- まさにテストでの使い方
- AOPをTraitで実現できる
- 処理をまとまった単位で切り出すためのもの
- ところでAOPってなんですか
- traitのアンチパターン
- 依存の向きがおかしい
- traitがtraitをuseしているクラスに依存している
- 依存の向きがおかしい
IRT 2 -- PHP
型について
- PHPでジェネリクスしたいけどできない(ぼく)
- ジェネリクスが欲しくなる例
Maybe<T>
とか[成否,データ]
の積集合データにしたくない- 補完も効かないし…
- (Maybeの説明が面倒だったので)
Collection<T>
とか- これも補完が効かなくて困ることがある
- どうしてる?
- Fail-First
- 早期にエラーで止まってくれたほうが嬉しい
- 止まるのが遅いと追うのが大変
- 早期にエラーで止まってくれたほうが嬉しい
- 2016 t_wadaさん PHPで堅牢なプログラミング
- 契約プログラミング
- 事前条件が整っていることを引数型で担保する
- メソッド内のバリデーション不要に
- 契約プログラミング
strict(type=1)
論争- 後から付けると既存のコードが動かなくなる
- 暗黙の型変換等
- 後から付けると既存のコードが動かなくなる
- タイプヒンティング
- 「あえて書かない」はある
- 「書けないから書かない」はやばい
- 実装コストと相談しながら定義しましょう!
IRT 3 -- PHP
5000行くらいあるメソッドを見つけたらどうしたらいいか
- スクレイピングで多発
- 「小説」
- 消していいか聞く
- 消せたら幸せ
- まずif文で分割してみて!
- if文の中身に名前を付ける
- みんなで解読
- 漫画を見るようなノリ
- 楽しげ
- 真剣に読まない
- まず全部読む
- 漫画を見るようなノリ
- 変更を加えずにすめば一番良い
- 製品の寿命によっては、解決しなくてもビジネスドメインごと消滅してくれることも
- どうしても変更を加えなければならない場合は、加害者にならないように
- 仕様を再定義して作り直したほうがよいことも
- ボーイスカウトルールを実践しようとしたが、ゴミだらけで「どれを拾えばいいのかわからない」
辞書攻撃対策
- 共通: throttleかける
- nginxで制限
- 403 Forbiddenとかにする
- アプリケーションコードに改修不要
- DOS detectとかをslackに流す
- 403 Forbiddenとかにする
- アプリケーションで制限
- 特定のIPからのアクセスを制限する
- 特定のIPに対してthrottleをかけづらい例
- 大きなお客
- bastion