これは2019年8月30日に開催したPHPerイベントYYPHP#98のイベントレポートです。
YYPHPは一言で「PHPerの部室」です。PHPについて、雑に、ゆるく、ワイワイ話し合う集いです。毎回お題を決めずに雑談を出発点にいろいろなことを突発的にやります。集まった人でコードリーディングをすることもあれば、一緒に開発ツールを触ってみたり、フレームワークについての情報交換をすることもあります。開催はほぼ毎週、高田馬場にて。
今回の配信動画
YYPHP#98「未経験から就職したとき、どういうことを意識したらいい?」 「LaravelのFacadeって使うべき?避けるべき?」 「プロダ... https://t.co/rpOf5xKr6x
— suin❄️TypeScriptが好き (@suin) August 30, 2019
過去回の配信動画
雑談
未経験から就職したとき、どういうことを意識したらいい? (せの)
新人が入ってきたらどういうことを意識してもらいたいか?
メモをとること、など。
...
- 新人への指導経験のあるひといます?
- はじめは丁寧にやりかたを教えてたが、途中からやめた。
- 手順通りにやってもらうより、
- 考え方を伝えたほうがいいのかなと思ったから。
- 依頼されたことに対して、なんでやるのかその背景を聞くようにしてほしい。
- 報告をとにかく早くして欲しい
- 仕事が終わったタイミングと思われがち。
- 仕事が止まっているときも報告してほしい。
- つまっている時点で聞く。
- 思っている10倍も20倍も早いタイミングで聞く。
- 「〜で調べようと思ってますが、どうですか?」くらいでいい
- これから作業しようとしている段取り、それを宣言するのも有用
- それがだめだったら、「一緒に段取り考えてください」というのもいい
- 段取りは、料理のレシピみたいに分解してくださいと伝えています。
- それは新人に作ってもらってる?
- 一度作ってもらうようにしてます
- 大事な作業、本番公開などは、実行計画を作ってレビューしてもらうようにしている。
- それは新人に作ってもらってる?
- リモートの場合
- まとめて投げてみるほうがいいと思う。
- suinさんの分報が役立つのでは?
- 新人教育する人へは仕事を減らして欲しい、新人教育に裂ける時間をあらかじめ作る事によりギスギスが減ると思う
- はじめは丁寧にやりかたを教えてたが、途中からやめた。
- 新人として教えてもらう立場の人?
- 業務的なことは
- 教える側
- 忙しいオーラを出さないようにしてはいけない。
- 新人が遠慮してしまうから。
- もくもくと作業しているとき、表情が怖いと言われる……
- Slackではニッコニコの絵文字ついまくるのはどう?
-
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ〜Problemが10分で解決するチャットを作ろう | | Craftsman Software Inc.
- リアルタイムに課題が解決しやすい
- 質問のハードルがすごく低い
- 分報、チームで使っているが、評判がいい
- リーダーがどういうことをしているのかいちいち聞かなくていい
- つまってそうなら、リーダーから能動的に聞きにいける
- 分報を実施したんですけど、コミュニケーションを取る人/取らない人で格差が発生したので、チームメイトによると思います
- 日報ですら読まない人いるので、意識改革的なハードル下げるアピールは必要かと思いますね。
- 忙しいオーラを出さないようにしてはいけない。
1年半のサービス、ソースが汚い。リファクタリングどうしよう…… (ぴろし)
1年半くらい開発してきたサービス(オープンソース)がある。
ソースがどうしても汚くなってきている。
どうリファクタリングしていったらいいか?おすすめの方法を聞きたい。
既存のサービスをリファクタリングしている方がいたら聞きたい。
...
- どうにもならなかったら非互換のバージョンを作る
- テストってあるんですか?
- リファクタリングするならテストがあるのが前提
- 最初にテストを書いて、リファクタリングする
- ここをきれいにしたい、という部分にテストを書く
- 今の挙動を確実にする
- リファクタリングする
- テストで壊れてないことを確認する
- 全部テストを書くイメージでした
- そんなことない、必要なところ、変えたいところだけテストを書けばOK
- 最初にテストを書いて、リファクタリングする
- リファクタリングするならテストがあるのが前提
- テストファースト
- テストのことを全く考えないコードを書いてると、テストを書くためにリファクタリングってことありませんか?
- 普通にある
- 急ぐべきところと急がないところは見極めるべき
- コアに近い部分
- いろんなところで使われる
- 重要なコンポーネント
- メリハリをつけるといい
- 現在テストがなければ Laravelの次期LTSをベースに作り直してもいいんじゃないかと思う
- 非互換にするなら
- ボーイスカウトルール
- 来たときより綺麗にして帰る
シナリオクラスってビジネスロジック? (よだか)
『現場で役立つシステム設計』を読んでいる。複合サービスクラス(別名 シナリオクラス)というのがあって、それを作るとメソッドが実行される順番を制御できる。しかし、メソッドの順番ってビジネスロジックじゃないの?という疑問。
...
- サッパリワカラン
- ビジネスロジックかどうかと言われると、そうだと思う。
- 注文を受け付けて、在庫を確認する、出荷する
- その流れを制御するためにシナリオクラスにまとめるのはどう?
- いいと思う
- その流れを制御するためにシナリオクラスにまとめるのはどう?
- Clean Architecture
- ユースケースと呼ばれる
- MVC
- コントローラに書かれがち
- IDDD
- アプリケーションサービス
- レイヤーが1つ増えるごとに1.5倍ずつ難しくなるイメージ
LaravelのFacadeって使うべき?避けるべき? (きたむら)
普段はUseして書く事が当たり前だったので、Facadeは使った方がいいのか。それとも使わなくていいなら使わないべきなのか。完全に理解出来ていないので、使い分けをどうしているのかが知りたい。
...
- Facadeで用意されているサービスがあるならそのまま使っちゃえばいいのでは?
- ここはFacadeでここはFacadeじゃないってなるとわかりづらくなる面がある
-
Laravel ファサードを利用しないメリット - ytake blog
- Facadeをつかないほうがちょっとはやい
- newしなくていい
- DIされるから
- 使っても使わなくても、、、楽になるなら使ってもいいのでは
- サービスプロバイダを先に覚えたので、Facadeを使ってこなかった
- コントローラをテスタブルにしたいなら、Facadeよりサービスプロバイダがいいかも
- Laravelのファサードは中でDIコンテナ使っているから結合が固定されるみたいなことはないので、テストで入れ替えるとかそういうのはできるように考慮されているんですよね。
- Taylor Otwellの答え
-
Response: Don’t Use Facades | PHPNews
- 2014年1月の記事(Laravel v4.1のころ)
- 古すぎて当てにならない気も
-
Response: Don’t Use Facades | PHPNews
- コンストラクタインジェクションをするならFacadeは不要だから、Facadeで全部書くみたいなのは無いかな
- コントローラじゃないところで使うのはやめた方が良いかも
- Authとかはもう完全的にFacade使っちゃう
- どこでも使うものはFacedeにするのはありだと思う
- ミドルウェアとかはFacedeでいいとして、ビジネスロジックはコンストラクタインジェクションにしったほうがいいと思う
- 複数人の開発だとどっちか決めないと人によってまちまちになる
Laravelに依存したDDDってあり? (よだか)
Laravelでドメインモデルを作っていこうと思っている。
とりあえず、フレームワークの機能に依存させて作っていいかと思っている。
(本当はだめだと思うが)。
RequestとResponseだけに依存して、作るのはありか?
それをやるなら、DDDやらないほうがいいのか?
...
- DDDは堅牢なシステムを作る手法で、インフラに依存しない設計手法
- 依存しないかどうかは、DDDの本質ではない
- なぜフレームワークに依存しちゃいけない?
- アプリケーションと業務のライフサイクルが別
- アプリケーションと心中しないために
- フレームワークを一生変えない可能性がある
- 切り離そうとすると、切り離せるけど、開発コストはだいぶ高まる
- EC-Cubeでも似たような乗り換え問題が発生している
- 2系: 5.6までしか対応していないので乗り換えたい
- 3,4系へは互換性がなく乗り換えられない
プロダクション環境ってみんなどうやって構築してる? (れおりん)
サービスとかやってる人がいたら、こんなふうにやっているというのを教えてほしいです。
...
- サービスやってる方、教えて。
- AWSのEC2に入ってシェルを実行
- マンパワーでやっちゃってる
- WinMergeで差分確認して、差分をSCPでアップロード
- セキュリティの対策ってどういうのあがあります?
- WAF置いたり
- subnet分けたり
- 踏み台サーバ置いたり
- Deployerを使ってデプロイしてみたら想像以上に楽だった - Qiita
-
DeployerでLaravelをデプロイする - Qiita
- Deployerは使ったことないけど興味はある
- GitHub ActionsでLaravelデプロイしてます
SPAのセキュリティって何を注意したらいい? (にしかわ)
JavaScriptはソースが見れるからセキュリティが弱いって上司に止められた。
Laravelを使っている。
非同期処理が多いところは、Vue。ログインまわりは、Bladeで書いてる。
...
- ソースが見れるかどうかはセキュリティにあんまり関係ない。
- 攻撃者はソースコード見れる見れないに関係なく、「弱点」をついてくる。
- ちゃんと書かれてるかどうか。
- Vue.js
- 認証周りのAPI使うときはIP制限かけたりしてる
- 認証情報をlocalStorageに入れるのは危ない
- Cookieを使う
- XSS
- サーバサイドでエスケープしててもクライアントサイドでもエスケープする必要がある
- 大量の「はまちちゃん」を生み出したCSRFの脆弱性とは? - ITmedia エンタープライズ
- SPAにする必要があるか
- 考える必要のある事柄、場所が増えるから
- ソースコードは難読化できる
- 見えなくすることはできない
- サーバサイドは送られてきたデータを全く信用せずにバリデーションするというのは変わらない。
TypeScriptとNuxt、次に勉強するならどっち? (にしかわ)
ある程度Vueを分かってきたので。
...
- どっちも並行してやったらいい。
- TypeScriptってゆるやかにいける
- .tsで作ってJSを書いて、徐々に型をつけていく、というのもあり
- Nuxtって何?
- Laravelのフロントエンド版(語弊)
- Vueとの違い
- Vue.jsが使われているフロントエンドのフレームワーク
- Nextは、Reactが使われているフロントエンドフレームワーク
- Nextがあって、NuxtがVue版として出た
- 「NuxtにとってのVue」は、「LaravelにとってのBlade =」という似た立ち位置
- PWA、SSRをできる。
- サーバサイドはNode?
- SSRするならNode
- 画面だけなら、Firebase使ってサーバを持たないというのも結構ある
YYPHPは毎週やってます
PHPについてワイワイ話したい方は、YYPHPのイベント情報をチェックしてみて下さい。
以上、YYPHPのレポートでした。次回もワイワイやっていきたいと思います! では、また来週!