# ShowNote：【オンライン】PHPerによるPHPerのための「PHPニュース他まとめ」TechCafe @ RAKUS 8月

## PHP最新情報/技術的Tips

- **[Qiita【PHP8.0】非厳密な比較演算子`==`の挙動が今さら変更になる](https://qiita.com/rana_kualu/items/82cc8295d2102d14b88a)**
- 各バージョンのPHP実行結果をみることができるサイト
- https://3v4l.org/

- **[Microsoftが「PHP」サポートを縮小 ～「PHP 8.0」バイナリは公式提供せず](https://forest.watch.impress.co.jp/docs/news/1264900.html)**
- MicrosoftによるPHPの公式サポートはPHP7.4までとなり、PHP8.0からはサポートしなくなる。

- **[How Can PHP Strict Types Help Preventing Bugs When Migrating to PHP 7 or
PHP 8](https://www.phpclasses.org/blog/package/11698/post/1-How-Can-PHP-Strict-Types-Help-Preventing-Bugs-When-Migrating-to-PHP-7-or-PHP-8.html)**
- PHPの厳密な型がPHP 7またはPHP 8への移行時にバグを防ぐのにどのように役立つか
- 結局は泥臭いリファクタリングが必要であるという戒めになる

- **[LaravelなどのFWにも使えるPHP処理のパフォーマンスを計測するツール【Blackfire】が最高だった](https://qiita.com/Daara_y/items/0c3d2449c67da1ff55b1)**
- PHPのプロファイラについておさらい
- 簡単にプロファイリングと結果の確認ができる
- [Profiling Tools For PHP7](https://qiita.com/takahashi-yugo/items/8f141e6ca0259a2bd2c8)
- SaaS型：Blackfire, tideways
- tidewaysはプロファイラ自体はローカルで動き、結果も確認できる。便利な可視化ツールがSaaS。
- サンプリング型：xdebug（＋webgrind）, XHProf（+XHGui）
- xdebugは重く、本番環境でも使えるものとして作られたXHProf
- ただしXHProfはFacebookが開発を止めており、PHP7以降の対応がされていない→XHProfの後継がtideways

- [Laravel 8 Will Be Released on September 8th!](https://laravel-news.com/laravel-8-release-date)
- Laravel 8は9月8日にリリースされます！
- そのほかにどんな機能がリリースされるのか

- [【PHP8.0】PHP8.0の新機能](https://qiita.com/rana_kualu/items/fe7998fbe773544d5d25)

- **[Laravel で Docker 使って開発したいなら Vessel にしておこう](https://qiita.com/localdisk/items/80763fcc803f66e1fc52)**
- Laradockについて
- Laravel開発を中心に「これ一つあればだいたいなんでもできる」環境
- であるがゆえに、デカい・重い・複雑というデメリットがある
- https://www.fendo181.me/entry/whats-wrong-with-laradock
- もともとはそうじゃなかったんだけど、ニーズに合わせていった結果巨大になった
- https://laradock.io/
- サポートしている機能は充実しまくっている
- Vesselについて
- Laravelで開発するのに必要十分な環境
- https://vessel.shippingdocker.com/docs/get-started/
- VesselはLaravelプロジェクトが既にある前提のイメージ
- https://vessel.shippingdocker.com/docs/common-issues/#catch22
- そもそもLaravelプロジェクトを作る環境（PHP,Composerなど）が無く、Dockerで開発したい場合は下記(php-composer）を使う
- どうでもいいが``catch-22``って、「どうどうめぐり」の比喩表現らしい
- php-composer
- https://hub.docker.com/r/shippingdocker/php-composer/

- RFC関連（**R**equest **F**or **C**omment。PHPの次期バージョンについての機能変更提案）
- **実装完了 [PHP 8.0 RFC: Nullsafe operator ](https://twitter.com/PHPRFCBot/status/1290912831634673664)**
- ECMAScript（JavaScript）でも同様の提案がある。
- RFC見ていると、ソフトウェア開発のトレンドが分かる
- 実装完了 [PHP 8.0: Named Arguments](https://twitter.com/PHPRFCBot/status/1289707389051006976)
- 名前付き引数
- 実装完了 [RFC: Saner string to number comparisons](https://twitter.com/PHPRFCBot/status/1284059151291711488)
- 『非厳密な比較演算子`==`の挙動が今さら変更になる』の話
- 実装完了 [PHP 8.0: Saner numeric strings](https://twitter.com/PHPRFCBot/status/1289175356629348353)
- 『非厳密な比較演算子`==`の挙動が今さら変更になる』の話
- **否決：[StackFrame class ](https://twitter.com/PHPRFCBot/status/1285543747544059905)**
- エラー発生時のbacktraceを配列ではなくオブジェクトにしようという提案
- 採択されると思いきや否決

## PHPよもやまばなし

- **[10 Cool Features You Get After Switching From YAML to PHP Configs](https://tomasvotruba.com/blog/2020/07/16/10-cool-features-you-get-after-switching-from-yaml-to-php-configs/)**
* YAMLからPHP構成に切り替えた後に得られる10のクールな機能
* IDEによる補完機能を利用できるなど、メリットは大きい

- [Top Common Mistakes that PHP Development Companies Make](https://www.etatvasoft.com/blog/top-common-mistakes-that-php-development-companies-make/)
* ＰＨＰ開発会社が犯すよくある間違い
* 私もやってしまいがち

## PHP以外の最新情報/技術的Tips

- **[「誕生パーティーでWi−Fiに…」モーリシャス座礁…をエンジニア視点で](https://news.tv-asahi.co.jp/news_international/articles/000190769.html)**
- 正式に発表された情報ではないので、鵜呑みは禁物！
- 船舶を安全に航行するために必要な情報は多い
- その全てを適切に人間が処理することには限界がある
- 顕在化した「モラル」というリスク
- 実は既にある自動運転システム → 今後どう改善されていくか？
- [ほぼ日ITエンジニアニュース](https://www.youtube.com/channel/UCv1AIkCCrRB_Tcz_1ZgSoFg)
- https://www.youtube.com/watch?v=hA-lrtxaDk4

## エンジニア・開発一般論

- **[技術書・方法論とのお付き合い](https://speakerdeck.com/tooppoo/how-to-learn-theory)**
- 技術書や方法論を学ぶ上で重要なポイント
- 書籍に書かれている手順や方法が「正解」ではなく、その思想や理論から「問題解決の視点を増やす」のが良い

- **[Webアプリケーション負荷試験実践入門](https://www.slideshare.net/taruhachi/20150224-45099119)**
- パフォーマンステストを行う際の考え方、手順などがまとめられている。
- パフォーマンステストの目的は「どれだけの負荷に耐えられるか」ではなく「期待通りスケールできるか」
- いきなりシステム全体に対してテストすると問題の切り分けが難しいので、段階的（まずは静的ページから）に行う方が良い

- **[テストを自動化するのをやめ、自動テストを作ろう](https://speakerdeck.com/tsuemura/tesutowozi-dong-hua-surufalsewoyame-zi-dong-tesutowozuo-rou)**
- なぜE2Eテストの自動化がうまくいかないのか。E2Eテストは本来どうあるべきなのか。
- ただ手動テストを自動化しても恩恵は得られにくく、腐っていきがち。
- 壊れがちだが開発の終盤で実行されるため、メンテナンスがスルーされる
- 手動テストがカバーしている観点が十分に自動化されたテストに反映しきれていない
- 以下のアプローチが必要
- かっちりしたテスト：（UnitTestと同じように）開発のサイクルと密接に関わり、高頻度で実行される
- ふんわりしたテスト：HTML要素のIDなどを指定するのではなく、ラベルやメッセージを検証対象にする、AIや画像認識などで人間によるテストを疑似的に再現する、など
- テストは網の目的に考え、E2Eテストで何を担保したいのかを認識し使い分けると良い

- [エンジニアなら誰でも配信を](https://speakerdeck.com/tnk4on/serial-experiments-live)
- オンライン配信が盛んにおこなわれている現状。私たちのこのイベントもまさにオンライン配信。

## 小ネタ

- **議論中：[Attriuteの記法についてまだ議論してる](https://twitter.com/PHPRFCBot/status/1288122229708869633)**
- 最初は``<<attr>>``記法で採択　→　からの物言いがついて ``@@attr``に決着
- さらに物言いがついて議論中　⇐　今ココ
- PSRの方でも議論中
- https://github.com/php-fig/fig-standards/pull/1218