本日はPHPカンファレンスの日だったので、今年も参加してきました。 今回は新型コロナウイルスの影響もあり、21年目にして初めてのオンライン開催になりましたので、Openingと同時に起床して参加しました。（寝起きで参加すみません）
ということで、今年もセッションのメモを書いていきたいと思います。
はじめに
家が会場なので、去年のPHPカンファレンスで購入してきたぬいぐるみと一緒に参戦です。
（だいぶ埃かぶってしまった。。）
セッション
では、セッションを聞いてのメモを残していきたいと思います。
PHPの今とこれから2020
PHPの今とこれから2020
PHPのこれまで、現状についてを知ることができ、PHP8の新機能とかを細かく紹介してもらえた。 また、これからのPHP8のように高速化していった先にAI・機械学習などに利用できる未来というものがみえた気がする。
www.slideshare.net
廣川類さん
- PHPとは
- 現場の課題を簡単に解決してくれる便利なツール
- サーバサイド言語のシェア：78.9%
- CMSシェア
- WordPress：63.6%
- 開発体制
- 2000名くらいが開発している
- PHPの歩み
- 最初はパーソナルツールとして作った
- 言語仕様：PHP 5.3/5.4で現代的なスクリプト言語に
- 性能：PHP 5で高速化、PHP7で最速に
- セキュリティ：PHP 5でCoverity Scan適用
- ステップ数はPythonと同等レベル
- 20年で速度が50倍に！
- ほぼ同じスクリプトが動く
- ほぼ同じスクリプトが動く
- PHPバージョン分布
- PHP7ユーザ：58%（昨年42%）
- PHP5（EOL）のユーザ：42%（昨年57%）
- PHP7.2まで（EOL）のユーザが73%
- WordPressの推奨環境：PHP7.4, MySQL 5.6、HTTPS
- リリースサイクル
- PHPのライフサイクル：3年（バグ修正：2年、セキュリティ修正のみ：1年）
- EOL以降はセキュリティ関連の修正も提供されず、非常に危険
- PHP5、PHP 7.0/7.1/7.2はEOLとなっている
- リリース情報
- X.X.1は1ヶ月起き
- CVE-*は速やかな更新が必要
- 脆弱性件数と種別
- PHP8のパフォーマンス
- ベンチ
- Zend/benchi.phpとZend/microbench.php
- JITなしの場合：改善なし
- JITあり：実行速度が大幅改善
- 実用アプリではそれほどでも無い
- cache/tracing/functionはJITの設定らしい
- その設定を変えてみての比較を載せている
- cache/tracing/functionはJITの設定らしい
- 実用アプリではそれほどでも無い
- 実際のアプリにおけるJITの効果例
- WordPressの例
- WordPressの場合、JITを有効にしてもあまり早くならない
- PHPの処理よりはDBの処理が占めているので、効果はあまり感じられなかった
- WordPressの例
- ベンチ
- PHP8.0 JIT導入
- JIT（Just-in-Time Compiler）
- 将来的にはARM等もサポート
- よくありそうな設定↓とりあえずこれでもいいのかも？
zend_extension = opcache
opcache.enable = 1
opcache.jit = on
opcache.jit_buffer_size = 128M
- コンパイル
- ネイティブコードへの変換に時間がかかるので、JITを導入したからといって早くなるわけではない
- コンパイル
- JITオプション
- PHP 8.0改善/変更のポイント
- Union：引数、戻り値の型の
- 属性（attribute）
- ユースケース：メタデータの記述、フレームワーク
- ユースケース：メタデータの記述、フレームワーク
- static型：
- 弱いマッピング（weak mapping）
- オブジェクトがガーベッジコレクションの対象となることを防げなない
- オブジェクトがガーベッジコレクションの対象となることを防げなない
- 変数::class構文
- 文字列部分一致確認用関数
- ネイティブコードで動くので、これを利用するのをおすすめ
- ネイティブコードで動くので、これを利用するのをおすすめ
- ヌルセーフ演算子
- match式：switch文をより簡易に記述できる
- mixed型
- きっとあまり推奨されないかも
- きっとあまり推奨されないかも
- 名前付き引数
- Constructor Property Promotion
- 数値の定義明確化
- 負の添字の明確化
- 結合演算子の優先順位明確化
- その他
- Union：引数、戻り値の型の
- PHPの将来
- JITの導入により、機械学習、AIなどがこれからたくさん実装されていくかも
- Webアプリケーションでアクセスを機械学習したりすることが増えていくかも。リッチなアプリケーションが増えていくんじゃないか
- PHPで機械学習していこう！
NewRelicプラットフォームを使ったオブザーバビリティ入門
NewRelicにはいろんな機能があることを教えてくれたセッションで勉強になりました。ただ、やはりPHP用のAgentが重い問題があるので、やはり本番環境にNew Relicを投入するのは考えちゃうよね。
BASE株式会社 | 川口将貴さん
- BASEはPHP7.3で動いている
- PHP8で動かすのはちょっと大変そう
- おことわり
- BASEが取り組み始めたこと。入門しているところ
- 可観測性が重要
- オブザーバビリティ
- 定義は一意じゃない
- システムに良い可視性をもたらすこと
- ログ・メトリクス・トレース情報・イベントなどから
- メトリクス：CloudWatch
- ログ：基盤くらいならなんとかなる？
- トレース：全部取る？
- イベント：？
- NewRelicを選択した
- 可観測性プラットフォームを提供
- 2018年から日本法人ができてる
- 最近だとISUCONのスポンサーしてた
- BASEでのNewRelic
- APM（アプリケーションパフォーマンス管理）のみ利用
- ホスト単位の課金のため一部サーバのみ展開
- 負荷が高いときの調査ツールの1つ
- NewRelicが提供しているソリューション
- APMだけじゃないよ
- New Relic Oneがあるよ
- APMだけじゃないよ
- Deployments
- デプロイをイベントとして記録できる
- デプロイ時curlなどでNew Relic APIを叩く
- どの変更タイミングからパフォーマンスが変わったのかをおいやすくなる
- デプロイだけじゃなく、インフラの変更も記録しておく
- 週次の振り返りで、どのタイミングから重くなったのか、とかを振り返ることができる
- APMで観測できること
- PHP用のAgentがちょっと重い。（やっぱこの問題はあるよね。だから本番環境への導入するか迷う）
- マネージドサービスの統合
- AWSでいえば、IAM渡すだけでいろんなサービスを見れるっぽい
- New Relic LOGS
- ログ検索が速いらしい
- kibana + ESみたいな
- deadlockの検索とか、traceidをつけておくとそれに紐づく他のログを見つけることができる
- このSQLってどのリクエストパラメータなんだろう、みたいなのがいろんなログを紐付けて調べることができる
- New Relic BROWSER
- フロントエンドのパフォーマンスモニタリングもできるらしい
- New Relic MOBILE
- iOS/Androidモニタリングもできるらしい
- 可観測性による本当の価値
- エンジニアはコードをリリースしてビジネスに価値提供していく必要がある
- そのために打席に立つ回数を上げる必要がある
- 不安なリリースするのはスピードが出ない===価値提供できない
- 可観測性のあるアプリケーションであれば異常にいち早く気付ける
- New Relicを使いこなすのが目的にしない、武器の1つにする
New Relicの様々な機能を紹介してくれている発表。New Relic ONE！
レガシープロジェクトで、メタプログラミングを使ったPHPStan静的解析レベル上げ
今までPHPStanによる静的解析を利用して改善するってのはあまりイメージはなかったけど、すごい参考になったセッションでした。
弁護士ドットコム株式会社 | 小宮山 太樹さん
- 技術負債とコードレビュー
- 事業成長優先で、リファクタリングできなかった時期があった
- error_reportingをE_ALLにすると、Noticeエラーが大量発生
- PHP7.3だが、フレームワークはYii1
- ユニットテストが少なく、カバレッジが低い
- レビューコストを削減したい
- 大規模リファクタリングしたい
- 動作確認してもぬぐいきれない不安
- 静的解析で攻める
- コード量が多くても、機会なので同じ精度で解析可能
- テストコードを書く必要がない
- CIで実行できるのでレビューする前に実行できる
- PHPStanを選択
- 検知可能なエラー
- 未定義の関数、class、プロパティ
- PHPDocの構文チェック
- 型チェック、分岐のチェック、デッドコードのチェック
- 検知できないエラー
- 無限ループ
- 実行しないとわからないもの系
- PHPStanエラー無視設定
- エラー文に正規表現が使える
- 対象ファイル、発生数が指定可能
- ベースライン機能（エラー無視リストを自動生成）
- ファイルとエラー文、発生数を記録
- 新しく追加したコードだけきれいに書くように制限できる
- PHPStan導入戦略
- 一番ゆるいルールのLevel 0から始める
- できる限りエラーは修正
- エラーは0件がデフォルト
- 汎用性重視、PHPDocで静的解析を補助
- スキャンできるファイルから始める
- メタプログラミングを使って、namespaceがなかったクラスにnamespaceをつけた
- 同名クラスがたくさんあったけど、これで解決
- コードスタイルの修正はphpstormを使った
- PHP-Parserから推測してPHPDocを付与するっぽい
- メタプログラミングらへんについてはスライドを見直しても良さそう
- エラーをPHPStan拡張ツールを作って、修正
- Level2だけでも2500件あったけど、直せたらしい
- 業務効率も上がった
- コードレビュー前に指摘してくれる
- IDEの補完も効くようになった
メタプログラミングでリファクタリング！
長期運用を目指す『Shadowverse』におけるリファクタ事例の紹介 〜テストの導入とメンバーへの普及法〜
やはりテストって重要ですよねってのを再認識できた。テストを書かない文化のプロジェクトに対してのテストコードの導入についての参考になる。 10年、20年続く「最高のコンテンツ」のために、テストの導入に工数を割くのを許可してくれるチームっていいですね。
株式会社Cygames | 髙野 祐輝さん
- Shadowverse
- 3ヶ月に一度のメジャーアップデート
- 新規機能の追加、既存機能の改修、不具合の修正
- サーバ側だけで約1400コミット、約40,000行の変更がある
- アップデートによる開発への影響
- コードの可読性の低下
- コードの綺麗さ優先で実装してばかりはいられない
- コードの属人化
- 機能の追加実装を元の担当者に依頼しがち
- コードの可読性の低下
- ミッション機能
- ユーザーが特定の条件を満たした際、ユーザー荷インセンティブが発生する
- リファクタリングしたいけどできない
- テスト導入
- 和田卓人さんと招いて、セミナー実施がきっかけ
- 入力と出力がはっきりする
- 以上系の動作確認が容易になる
- 不正操作による異常系
- 通信のタイミングによって発生する異常系
- 期間限定イベントの挙動確認
- イベント開始前、イベント中、イベント終了後を人が確認するのは大変
- テストコードはここのチェックを一瞬でできる
- テストで「ミッション」をリファクタできるのでは？
- 10年、20年の運用を目指し、PJにテストを導入することに
- ディレクター、プロマネも快諾
- 10年、20年の運用を目指し、PJにテストを導入することに
- テスト導入チームを結成
- まずはやってみる精神
- テスト導入のフロー
- テスト実行環境を作成
- テスト向けフレームワークのインストール
- 実行コマンドは必ず記録しておく
- 手順をやり直したり、のちに手順書を起こすとき役立つ
- サンプルコードを実行して動作確認
- アプリ用とテスト用のDBは分離が必要
- テスト用：ユーザーデータを作成＆削除をするため
- DBの分離のためFWの修正が必要
- テスト向けフレームワークのインストール
- テスト環境の管理方法検討
- フォルダ階層をどうするか
- 機能ごとにフォルダを分ける
- リポジトリ管理をどうするか
- リポジトリは別にする
- サブモジュールもしてない
- フォルダ階層をどうするか
- 自動テスト環境を作成
- Jenkinsで自動テスト環境
- テスト実行環境を作成
- テストを用いた「ミッション」機能のリファクタ
- テストはリファクタの担保としてのテスト
- in/outを確認できるテストを書く
- テストが問題なければリファクタ成功
- どれだけテストを書く必要があるか？
- 理想：全てのミッションについてテストを書く
- ただ、ミッションの種類も350種類以上もあるので、現実的ではない
- ある程度の粒度で分ける
- 理想：全てのミッションについてテストを書く
- テストを用いたリファクタの流れ
- 大きなスコープでテストを書く
- 大きな処理を切り出す
- 処理の切り出しの繰り返し
- テストを増やす
- 切り出した処理のリファクタ
- リファクタの繰り返し
- リファクタの結果
- 巨大になっていた処理を細分化できた
- コードの可読性が向上
- メンテナンス性の向上
- デバッグ範囲の縮小化
- 大規模リファクタにも関わらずバグがホトんで出ず
- バグが1件、デバッグ中に発覚
- 多言語対応できてない箇所があった
- テストを書けてない箇所のバグ
- どうしても、書けてない場所が出てきてしまうのは仕方ないようね
- 巨大になっていた処理を細分化できた
- プロジェクトにテストを書く文化を根付かせる
- メンバーの多くがテストを書けるようにする
- メンバーのスキルアップにも貢献
- テスト初心者に立ちはだかる壁
- テストを書く環境がない
- テストの書き方がわからない
- そのため、徹底してハードルを下げることが重要
- 徹底してテストを書くハードルを下げる
- 環境構築のハードルを下げる
- 興味を持った人がすぐにテスト着手できるようにする
- そのため、
- 各種インストール手順書の作成
- DB更新スクリプトの作成
- コマンド1つ実行すれば良いように
- テスト作成のハードルを下げる
- まだテストを書いたことがない人への機会提供・フォロー
- そのため、
- テストコードのレビューをしてもらう
- リファクタ案件を「テストを書いてリファクタする」案件に昇華
- 自動テスト実行のハードルを下げる
- PJとして必要なステップ、ここで躓いてテストを敬遠されないために
- そのため、
- CIツールによる自動テストの用意
- CIツールが社内SNSにテスト結果の通知を送るようにする
- こだわり
- まずは、テストに触れてくれる人を増やす
- 環境構築のハードルを下げる
- テストの普及、さらなる効率化
- メンバーによるテスト効率化の知見がたまる
- そして開発効率のさらなる向上に！
- テスト駆動開発について
- 概要
- 設計要件をもとに失敗するテストコードを書く
- テストが成功するようにコードを書く
- テスト成功を維持しつつ、コードをきれいにしていく
- メリット
- テストによりコードの動作を担保しながら実装できるので、後工程で手戻りが発生しない
- 出来上がるコードは要件をすべてパスしたものであり、バグが少なく、実装者の倫理的安心もある
- 概要
- 実際の例
- ユーザに見せたイベント紹介画像がわかりやすい仕様書
- テスト駆動開発をしてみて
- 高速に実装できた
- コマンドライン上での動作確認が主となるため（Unityを起動しない）
- バグ報告がきても素早く対応可能
- 非常に可読性の高いコードが書けた
- 要件ごとに単体テストを書くと、各処理が小さくなるため
- 実装から1年ほど経っても満足のいくコードに
- リファクタでテストを書く経験をしておいてよかった
- 「テストを書きやすい単位で関数を書く」スキルが必要
- このスキルはリファクタ時のテスト導入で養える
- 高速に実装できた
- ユーザに見せたイベント紹介画像がわかりやすい仕様書
- テスト導入の成果
- コードの可読性が向上
- 単体テストとして細かく関数を字っすするため
- テストが仕様と実装の橋渡しをするためコード読解しやすい
- コードの属人化に解消の兆し
- コード読解しやすいため、もともと担当でないメンバーに仕事を割当しやすい
- テストコ増築は簡単なため、手が空いたときに非担当タスクをメンバーに割り当てられる
- コードの可読性が向上
- メンバーの多くがテストを書けるようにする
10年、20年続く「最高のコンテンツ」目指して、テストを導入し、成果を上げることができた
PHPのソースコードから理解するPreloadとJIT
PHP8の目玉であるPreloadやJITって結局なんなのかよくわかってなかった自分にはものすごい勉強になった講演でした。
富所 亮さん
- preloadとjitの肌感を掴む
- 謎の技術にせず、仕組みから理解
- どれくらい速度向上するのか
- 本番環境での採用是非
- PHP高速化の歴史
- 以前はOPCodeをメモリにキャッシュ
- PHP5.5以降あhOPCache
- OPCacheがはいっているかはphp -vですぐに確認できる
- 絶対に入れてね
- コンパイル結果のキャッシュ
- OPCache Preload
- PHP7.4から追加
- サーバ起動時に指定ファイルをコンパイルして、メモリに読込
- 一見すると、中間コードキャッシュと同じことをしているようにみえる
- preload有効化によって処理速度が約14%向上
- OPCache JIT
- PHP8.0から追加
- ZendVMで実行するのではなくNative Codeを実行する
- 機械語実行により処理速度が最適化
- 同様のことはpcre-jitやJSなどでもおなじみ
- JIT
- コード実行が最適化
- JITコンパイルのオーバーヘッドは実行速度で補填
- ベンチマーク
- JIT有効化によって、処理速度は約2.5~5%の向上
- すなわち、DBアクセスのないアプリで2.5~5%なので、実際のWebサービスはどうしたものか。
- 速くなったよっていう記事とかはモンテカルロ法とか、JIT向けのような処理で計測している気がする
- JIT有効化によって、処理速度は約2.5~5%の向上
- 使用上の注意
- 内部の実行パスが変わる
- 開発も同じ設定にするのが吉
- ファイル更新でopcache_clearとか
- phpunitで使うには
- opcache.enable_cli=1
- これを設定しないと、コマンドライン実行時にopcacheが動かない
- 高速化技術が達成すること
- OPCache → コンパイル回数の軽減
- OPCache preload → autoloadの軽減
- OPCache JIT → コード実行の最適化
- 普通のアプリケーションではJITはあまり有効ではない
- 普通じゃないアプリケーションだったらJITは有効かな
- チューニングをするんだったら、DBアクセスを見直したほうが良いと思う
- ボトルネックの大半がDBアクセス
- 本番投入はオススメしづらい
- 今はJITのメンテナンスしている人が1人だけなので、今は様子見で良いと思うとのこと
PHP8はISUCONへの扉を開く鍵となるか
銀の弾丸ほどではないが、DBで処理をしてしまっているところをいかにPHP側に寄せるかが重要そうだなって感じた。
清家史郎さん
- ISUCON
- お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトルそれがISUCONです
- オンライン予選の利用言語比率
- PHPは3.8%と低い
- 本戦出場の33チーム
- PHPは1チームのみ。。
- 次こそISUCONの予選突破をPHPで突破したい
- ちょうどPHP8がリリースされた
- PHP8は銀の弾丸なのか？
- これを検証してみる
- PHPとパフォーマンス
- PHP8の可能性を感じるために、PHP7.3.22とPHP8と比較
- （なんでPHP7.4じゃないんだろう。。）
- 今回計測したいパフォーマンスはPHPなので、コードは触らずパラメータの調整だけをしていく
- QuickSortアルゴリズムで検証
- Xdebug+webgrindでプロファイル・確認する
- webgrindでどこがネックになっているかとかが確認できる
- Graphvizで図式化も可能らしい
- だけど、xdebug,datadog,blackfire,Tideways XHProf,xhprofでSegmentation Fault
- なので、start時にmicrotime、end時にmicrotimeで計測することにした。。
- JITをオフにして計測したら、あまり変わらなかった
- JITをオンにする
- tracing/on
- トレーシングJITを使う
- 設定内容
- tracing/on
- PHP8の可能性を感じるために、PHP7.3.22とPHP8と比較
zend_extension=opcache
[opcache]
opcache.enable_cli=1
opcache.jit=tracing
opcache.jit_buffer_size=100M
- 爆速になった
- けど、これはPHP単体で動いている
- 3倍強の速度が出ている
- 爆速になった
- Webアプリケーションとパフォーマンス
- Client→Nginx→PHP→Storage(RDBなど)
- 今回はPHP CLIにてPostgreSQL
- でも、RDBの処理が支配的であるため、処理改善が非常に小さい
- Locastを使って計測
- PHP単体で確認したら、2倍のパフォーマンスが出た
- そこで
- DBの処理が遅ければその処理をPHPに任せる方法を考えれば良い
- DBからとりあえずデータを取得しておいて、それをPHP側で処理
- DBの処理が遅ければその処理をPHPに任せる方法を考えれば良い
- Client→Nginx→PHP→Storage(RDBなど)
- 言語の速度差異
- まとめ
ウェブセキュリティのありがちな誤解を解説する
今回もたくさん学ばせていただきました。最後のGoogle検索結果で引っかかる記事は間違っていることが書かれている可能性もあるよってのはたしかに注意しなきゃですね。書いている自分も気をつけないといけないなと思っております。（この記事も良くないのかな。。）
www2.slideshare.net
徳丸浩さん
- アジェンダ
- Cookieは誤解がいっぱい
- Doamin属性の誤解
- Domain属性は基本指定しない方が良い
- example.jpとかにするとサブドメイン全てになる
- Domain属性は基本指定しない方が良い
- Path属性の誤解
- Javascriptはオリジンでの制御なので、ディレクトリは無関係。なので、Pathを指定しても必ずセキュリティが高まるってことはない
- なので、最近のPAセキュアプログラミング講座からは外されている
- Path属性に期待してはいけない
- Secure属性の誤解
- TCP80ポートを閉じていれば、Secure属性は不要？
- http://example.jp:443/で送ると平文でcookieが送られてしまう
- なので、Secure属性はつけておきましょう
- TCP80ポートを閉じていれば、Secure属性は不要？
- HttpOnly属性の誤解
- 平文だけで送るわけではない
- JavaScriptからアクセスできなくなる
- HttpOnlyを指定するだけでXSSの脅威を防げる？
- HttpOnlyを指定すると、Cookieの盗み出しができなくなるだけで、秘密情報の盗み出しや不正操作はできてしまう
- SameSite属性
- 異なるサイトから遷移した場合に、クッキーを送信するかどうかを制御するもの
- SameSite=LaxでgetのみCookieが送られる
- SameSite=Strictはgetもpostも送られない
- SameSite=Laxを指定することで、CSRF脆弱性の防御になる
- Doamin属性の誤解
- 脆弱なECサイトはセキュリティコードを保存している
- 入力フォームを改ざんして入力中のカード情報を盗む
- または、ニセのカード情報入力サイトに飛ばす
- あえて決済エラー画面を表示させておいて、正規のページに戻す
- それでユーザもわからない
- なので、クレジットカード情報をサーバに保存しないようにしても漏洩する可能性がある
- クレジットカードをサイトに保存すると漏洩リスクが高まる？
- →よくよく考えると、入力するときに攻撃されることが多くなるので、カード情報をサイトに保存したほうが漏洩しにくくなりつつある
- ハッシュ値で保存されたパスワードは復元されない？
- GPUによる総当りをするのが現実的
- 並列計算が極めて容易で、コストをかければいくらでも高速化できる
- なので、パスワード保存に特化したハッシュ方法を使用する
- 信頼のあるライブラリを使用しましょう
- GPUによる総当りをするのが現実的
- 高価なSSL証明書ほど暗号強度が高い？
- 証明書の価格と暗号化強度は関係ない
- HSTSの設定
- 無料の証明書でも暗号的に強固な設定は可能
- Let’s EncryptでもOK！
- TRACEメソッドの有効化は危険な脆弱性である？
- getやpostの代わりにtraceを使用すること
- →ちょっとここの項目はよくわからなかった。。。
- 怪しいサイトを閲覧すると情報が盗まれたり、ウイルスに感染する？
- ブラウザやブラウザのプラグインに脆弱性がなければ、「怪しいサイト」を閲覧しただけでマルウェア感染することはない
- ブラウザを常に最新の状態にしましょう
- 「怪しいサイト」を閲覧したら自動的にウイルス感染するわけではありません。
- 有名なところだと、FlashPlayerがあるが、そろそろEOL
- フィッシングは注意。そこに追加で情報を入力しなければ大丈夫。閲覧だけなら大丈夫だけど、そこで何かしたら問題
- ブラウザやブラウザのプラグインに脆弱性がなければ、「怪しいサイト」を閲覧しただけでマルウェア感染することはない
- イントラのウェブサイトは外部からは攻撃できない？
- XSSを用いればイントラ内部のサーバを攻撃することができる
- ブラウザ経由で情報が漏れる可能性がある
- セキュリティ情報はウェブで収集する？
- ググっても、上位に出てくる記事が良いものではない
- 他のサイトを切り貼りした記事も出てくる（キメラ記事）
- ちゃんと理解せずに書いていたりもするので、間違った記事でもSEOに強い生地が上に出てきてしまうこともある
- SNSシェアの数とかを見て良記事なのかを見極めても良さそうかも
さいごに
今回はPHP8がリリースされて2週間くらいということで、PHP8についていろいろ学ばせていただいた印象です。 結局はWebサービスはDBがボトルネックになってはしまうので、JITはもしかしたらそこまでの効果は期待できないかもですが、高速化によってはWebサービス上でのリクエストに対しての機械学習だったりと、これからできることがすごい広がるかもと感じた。でも、PHP5系から7系に上げただけでパフォーマンスがものすごい上がったという話はよく聞くので、PHP8もきっと効果はありそうなのかなと信じてる。
今回、初めてペチコンのオンライン開催に参加してみました。 遠方から参加の人も家からZoomで登壇とかもすることができたり、自分も家から出ずにゆっくり見ることができたので、良かったかも。また、Youtubeのライブ配信だったので、聞き逃したら少し戻るってことができたので、より理解ができたかなと思っております。
次回は2021年10月2日と3日の2日間とのことです！今のうちにカレンダーに入れておかないとですね！
