これは2018年08月24日に開催したPHPerイベントYYPHP#49のイベントレポートです。
YYPHPは一言で「PHPerの部室」です。PHPについて、雑に、ゆるく、ワイワイ話し合う集いです。毎回お題を決めずに雑談を出発点にいろいろなことを突発的にやります。集まった人でコードリーディングをすることもあれば、一緒に開発ツールを触ってみたり、フレームワークについての情報交換をすることもあります。開催はほぼ毎週、高田馬場にて。
YouTubeでの配信映像はこちら-> #YYPHP #49【PHPの情報交換・ワイワイ話そう・仲間作り・ゆるめ・にぎやかめ】
参加者18名(うちリモート6名)
- PHP歴
- 1年未満: 6名
- 1年: 1名
- 3年: 1名
- 5年: 1名
- 6年: 1名
- 10年以上: 4名
- 不明: 4名
今日話したいこと
人のソースを読み解くコツを教えて
- 人のつくったものを引き継いで開発したことある人: 8人くらい/12人中
- 仕様書がないときどうしたらいいか
- Controllerが提供しているURLを洗い出して、アクションと結果を見てみる
- 静的解析のツールにかけると、使われていないコードを探すことができる
- Xdebug + PhpStorm, phpdbgでステップ実行する
- PhpStormとEclipse PDT両方を9ヶ月使ってみた比較 | Skyarch Broadcasting
PhpStormの良いところをおすすめして
- PhpStorm使っているひと: 4名
- メソッドにジャンプできる
- InspectionでNoticeやWarningになるようなコードを教えてくれる
- コンパイラ代わりに使える
- 単体テストが実行できて、Code CoverageをIDE上で確認できる
- 補完
- PHPDocをつけたいときに、
/**+ returnで補完
- PHPDocをつけたいときに、
- Php Inspections (EA Extended)
- 静的解析よりいろいろ出してくれる
- https://plugins.jetbrains.com/plugin/7622-php-inspections-ea-extended-
- Php Inspections (EA Ultimate) 有料版
- 潜在的な不具合を見つけられる
- Refactor
- Code Reformatting
- コーディングスタイルの定義
- PSR-2などのプリセットがあらかじめ入っている
- プロジェクトにコーディングスタイルの共有するには、次のXMLをリポジトリに入れておく
- .idea/codeStyles/codeStyleConfig.xml
- .idea/codeStyles/Project.xml
- コーディングスタイルの定義
- Intention
- 検索が早い
- Find Usages結構使います。Laravelの中を追いかけるとき。
- Find Usagesはこのメソッド使ってるのどこかをリストアップしてくれます。クラスみてるので関係ないクラスの同名メソッドについては無視してくれます
- 型をがんばって追いかけてくれるところ
- デフォルト状態がとんでもなく賢いというか、そうそうこの構成がほしいんだよみたいな状態で配布されてる事
PHP（WordPress）で外向けのシステムを作るときに気をつけたほうがいいこと
- 外向け(インターネット)のシステムを作ったことがある人: 4人
- 外部のセキュリティ診断を受ける必要があった
- OWASP ZAP
- AWSのWAFが無料
- 「AWSを使う」
- セキュリティの次は速度ですかね、DBのインデックス貼り忘れとかで死ぬケースが… (みやびさん)
- WordPress
- アップデートを欠かさない
- セキュリティパッチがたまに出るため
- PHPMyAdminもよく狙われる
- HTTPS
- GoogleがSSLじゃないと評価しなくなってきている
- できればPaaSを使ったほうが気にするセキュリティを少なくできる。Herokuとか。
- アクセス元が特定できるようなログの取り方を設定する
- ZabbixとかNew Relicでログをとっておくと改善につなげやすい
- バックアップ取る
- 最低1日1回
- 安全な場所に保管する
- ローカルにバックアップを取っておく。自分が作業中に勝手にやってくれるように設定しておくといい。
- バックアップ取ったら復元テストもしないと駄目ですよ！バックアップから復元出来ずにサービス終了したソシャゲがあるらしいです
- cronがちゃんと動いてないことを検出する
Laravel5.5による既存プロダクトの改修のお手伝い中に遭遇した「Paypal決済処理が失敗する問題」の回避について話したい。
- paypal決済処理が組み込まれている製品だがPHP7.2環境で問題が生じたのでその対処をした。これに関連してワイワイしてみたい。
- netshell/paypal
- netshell/paypalパッケージが paypal/rest-api-sdk-phpパッケージの v1.6.4 に依存しており、paypal/rest-api-sdk-php v1.13.0 で解消した「PHP7.2へのincompatibility問題の対処コード」を取り込めないでいた。
- vendor配下へinstallした netshell/paypal のコードに直接手を入れるようなことはしたくなかった。
- そこで、 netshell/paypal を fork して Requires を paypal/rest-api-sdk-php v1.13.0 に書き換えたものを packagist へアップし、当該プロダクトではこれを使うようにした。
- vendor配下に入ってくるコードに手をいれるのはOKか？
- forkするほうがいい
CakePHP3の情報を効率よく探しだす方法を知りたい
検索してもCakePHP2の情報が出てくる。
- Google検索の期間指定するといい。
- Zend Frameworkでも同じような問題があった
- Cakeは知らないが、Stack Overflowだたたらバージョンによって違うということはよく書いてある
- CakePHP3とLaravelはどう違う？
- 思想は違うけど、目指す大きな方向性は一緒のはず
- MVCのフレームワークであることは同じ
- Laravelは、Vueなど新しいものをどんどん取り込んでいる
- CakePHP3系の勉強・習得におすすめの本！ - 徒然なるままに
エンジニア1年目に知っておけば良かったこと
1年目の手痛い失敗経験とか、「これを知っていたら、ああならなくて済んだのに」といったことを聞きたい。
- 東京に来ておけばよかった
- 勉強会の数もまわりのモチベーションも違う
- エンジニアがエンジニアじゃない（オペレータ）
- 『クリーンアーキテクチャ』を読んだら、難しい本だと思ったが、内容が簡潔で結論がはっきりかいてあってよかった。
- 先輩に自らコードレビューしてもらえばよかった
- トランザクションの書き方を納品したあとに知った
- デプロイ手順をしっかり作ればよかった
- 本をもっと読んでおけばよかった
- TCPとかHTTPとか低レイヤー、実務では直接生かせないけど、先に読んでおくと後で幸せになったかなーと
- PHPは良い本がなかなかない
- Javaの本が参考になる
- Javaの入門書を読んでからPHPに置き換えて進むほうが参考になる
- ベテランとか先輩を捕まえておくこと
- つまったときに聞ける存在
- ひととおりできるようになると、安心しちゃって伸びなくなる
- できない人からすごいと言われる
- もっとすごい人のことを見なくなる
- っていう快適なゾーンが来ちゃうが、満足するな
- 自宅に広めのデスクを用意する
- キーボードのとなりに本を広げられるくらいのスペースができるようにする
リファクタリング・ウェットウェアだったと思いますが、
本当の初心者は今やりたい事をやることしかイメージ出来ないですね。
そこから上達してくると「本質的な所をもっと知らなきゃ駄目だ」と意識が変わる様になってくるそうです。
本を読むのは「本質を知る」というフェイズなので、1年目だと効果的かと言われると微妙かも知れませんね
私は座学と実践は半々が良いんじゃないかなぁと思います。
根性で実装してみた所を、後で本を見て「この技には名称付いてたんだ！！」みたいな
YYPHPは毎週やってます
PHPについてワイワイ話したい方は、YYPHPのイベント情報をチェックしてみて下さい。
以上、YYPHPのレポートでした。次回もワイワイやっていきたいと思います！ では、また来週！