2024年2月11日日曜日

PHP Conference 2024 に参加して #phpkansai

これまではオンラインも含めると３度参加してきて、今回は４度目になります。
対面での参加は久しぶりになります。PHP Conference Kansaiは6年ぶりとのこと！クロージングで今回の参加者は431名と発表がありました。大人数でしたね！

今回はアフターコロナの中で久しぶりの対面開催ということで、会場にも多くの人が訪れており、熱気もすごいですね！下の写真のように事前登録した特別なシールも貰いました！


セッションやLTの様子について Xの投稿情報をみるとほぼ満席だということがわかりますね！他にも人が溢れているセッションも多くありました。


   https://twitter.com/phpcon_kansai/status/1756549971145634198
   Photo by @phpcon_kansai

   https://twitter.com/phpcon_kansai/status/1756585468479799319
   Photo by @phpcon_kansai

オープニング




実行委員長からの挨拶。たくさん来られたのは嬉しい反面、危険を避けるため各 room は入場制限をしないといけない場合があるかもということでした。

以下、各セッション内容を筆者の理解に基づいてメモしています。
そのため、発表者の意図した内容でない場合もあるかもしれませんが、その点ご留意ください。筆者の感想的なものは文章冒頭に # をいれておきます。

レガシーシステムへのPHPStan導入から半年での課題と効果




10:50 - 11:00 - roomB

部屋は満員お礼の状態！椅子を急遽追加されていましたね！

PhpStorm等既存の静的解析ツールでは限界を感じていたところに PHPStanに出会った。
こちらも静的解析ツールではあるが、できる幅が大きいとのこと。
PHPStanでバグを発見例：関数のオーバーライドの引数の型ミス

過剰な指摘に対しては除外ルールを設定していった。
除外：arrayを引数とする場合に正確な型指定（全修正するのは大変）

課題：ローカル実行する手段が少ないために再チェックに時間がかかる

#PHPStanを早速導入してみた。下記あたりを見て、手持ちの Macに composer をインストールしてから、phpstanをインストール。

PHPStan導入のすすめ - Hajimari Tech Blog| 株式会社Hajimari

下記のように a.php を作成して、 <?php echo test;  を入れて PHPStanでチェックしてみた。


test というのが定義されていないよっていうエラーですね。
これを <?php echo "test"; に変更してScanすると下記のようになります。レベル最大の9でもエラーはありませんでした。まぁこれでエラーがでたらどうしようって感じではありますけどね。


これはなかなか便利そう！

令和最新版 PHP メモリ管理術



11:10 - 11:45 - roomB


冒頭、「php -d memory_limit=-1」（PHPのメモリ制限を無効化）を使っていたら手を上げて！という発表者側の問いに、結構な人数が手を上げていました。

#私もローカル環境では設定をいれてます。WordPress など CMSを使っている場合、プラグインなどによるアクセスログなどが数百MBになったり、その他状況によってはデータベースが GBを超えることもあるので、ローカル環境などで開発のためのクローンサイトを作る時には、そうしたメモリ制限を無効化しておかないとエラーになっちゃんですよね。

post_max_size はサーバーが一時ファイルを作成できる容量によって設定すべき
＊メモリはあまり気にしなくて良い

post_max_size >= upload_max_filesize

である必要あり。
PHPの変数は CoW（Copy on Write）。つまり使うときにメモリが消費される。
とはいえ、値の変更があったりなどするとメモリ消費していくので、使わなくなった変数は解放しておくほうがよいだろう（巨大なデータを配列などにいれて、処理中にもう参照しない状態になった場合など）。

#解放は unset ( $sample ); など unsetを使う
参考：PHPメモリ解放の手引き！あなたのスキルを3倍にする6つの方法 | Japanシーモア

ガーベジコレクションは自動で動作するはずだが動作しないケースもある。その場合、gc_collect_cycles 関数を設定することで手動で強制実行させることが可能ということ。

#参考：PHP・GCの話-1話) なぜGarbageCollection? メモリとGCを意識する #PHP - Qiita

画像を出力（base64）したいなど、memory_limit よりも大きな値を使いたい場合
57*143 bytes ごとに分割した文字列を base64_encodeするとちょうどうまく分割できる（かなりトリッキーだが）。

#このあたりが参照？：PHP: base64_encode - Manual


昼食



グランフロント南館7F のレストランコーナーを訪れましたが、あまりの大行列に断念。LINKS UMEDAの地下にあるマクドナルドで「たまごダブルバーガー」を食べてホッと一息。

レガシーとモダンなシステムが混在する開発環境を改善しよう



13:00 - 13:10 - roomC

サブシステムごとに開発作業の進め方が異なるとミスも発生しやすい状況となる

Windowsマシン + PHPStorm でコーディング
動作確認は、Linux VM環境
ソース管理は GitLab
デプロイは手動だった。モダンな環境だが開発環境が異なってしまう問題があった

これについて、下記を考えた
サブシステムごとのコンテナ環境を開発メンバーのVM環境上に展開
VM環境のディレクトリをコンテナにマウントする
コンテナ実行スクリプト群はアプリソースとおなじリポジトリに管理

WSL（Windows Subsystem for Linux）は使わなかったのか？
　既存のメールサーバーシステムを考えると構成が複雑になってしまうなど

開発用PHP Dockerコンテナ
php.ini や設定ファイルもリポジトリ側で共有（起動時に読み込む）

コンテナ環境実行のためのスクリプトを makeコマンドで実装できるように用意した。

テストコードが書けるようになって「変更したけど壊してないかな」という不安を解消しませんか？〜テスト駆動開発の世界のクイックツアーも添えて〜



13:20 - 13:55 - roomC

発表者は、普段 Python（機械学習）をしている
PHPUnit は 10.5/11.x 系が現在の最新

テストコードがかけるメリット
それぞれの時点でベストの書き方をしているけれど、新しい情報を得たら、そのコードに書き直したいこともあるかもしれない。しかし、そのことによって振る舞いが変更されてしまわないだろうかと不安になる

php -a で対話型モードになるので、これで確認してみる
php -a 
> require 'sample.php';
> echo hogehoge();

しかし関数が多くなっていたら大変。

テストコードでチェックすると、不安というのは退屈に変わる
そのためには負担のかかるテストコードを書くメリットは大きいのではないか
テストコードは良いコードに近づけるものである。したがってコードを不安なく変更できるだろう。

PHPUnit に関するマニュアルは下記がよい

たとえば下記のように書くと、fizzbuss(3) の結果が、"Fuzz"と一致するかどうかのテストになる。

$this->assertSame(fizzbuss(3), "Fuzz");

ただ、下記のように複数の引数をテストしたいなら、 Data Providerで実装できる。
$this->assertSame(fizzbuss($number), "Fuzz");

#Data Provider についてのマニュアル

テストの世界のクイックツアー

モック（Mock）

ある処理の中で他の処理を呼び出すものがあったりして、そうしたテストコードを実装してみたい。たとえば、HTTP通信していて、エラーコード（通信失敗）をチェックしたい場合、仮想的にエラーコードを吐かせるなどのことを、スタブという。

テスト駆動開発

TDD: Test Driven Development 

上記についての考え方は、まずテストコードを先にかくというもの。
つまりもとがないので必ずテストは失敗する。
それから簡単なコードを書いて、テストコードが pass することを確認する。
それからコードを書き、テストコードを pass するコードを書く。それからコードをきれいにする。

たとえば FizzBuzz.php について <?php のみという何も無いデータにしておいて、テストコードを先に書いてテストする。

public function hogehoge{
 fizzbuzz(false);
}

などをテストコード内に書いてPHPUnitが失敗することを確認する。

さらにメインのコードに関数 fizzbuzzを書いた上で、テストコードに下記のようにテストコードを追加する。

public function hogehoge{
 $this->assetSame(fizzbuzz(1), "1");
 fizzbuzz(false);
}

PHP8.2にバージョンアップしたら文字化けが発生して道頓堀に飛び込みたくなった話




14:15 - 14:25 - roomB

発表者はメールディーラーサービスの管理運用をされている
メール共有管理サービスで、メールの処理を複数人で対応可能にするWebメーラーのこと。

PHP8.0から8.2にバージョンアップしたときに、顧客からメールが文字化けしたという問い合わせがあった。

メールは大きくヘッダーと本文の２つに分かれている。
本文の中には、パートに分かれている場合もある（テキストパート、HTMLパート、添付ファイルパートなど）
文字コード部分については、各パートごとに下記のような情報が付与されているはずだが、それがないメールはRFCの規格上おかしい。これはメールディーラーの問題ではないではないと思っていたが、顧客にはそんなことはわからない。

Content-Type:text/plain; chatset="utf-8"

文字コードのないメールの場合には、 mb_detect_encoding によってチェックして付与していた。しかし、PHP 8.1以降 でこの仕様が下位互換性のない変更になった。

mb_detect_encodingについては、これまでは前から順に正常にエンコーディングされた最初のエンコーディングを返していた。つまり評価というのはしていなかったということ。


しかしPHP8.1以降は全チェックして、評価してもっとも適切なものを返すという仕様に変更。この適切なものの判断に誤りが生じる問題が生じているということ。

解決策は、mb_check_encoding を使ってエンコーディングの種類を手動チェックしていくとのこと。

#下記辺りも参考になるかも
PHP8.1でのマルチバイト文字列関数の文字エンコーディングの挙動について #PHP - Qiita

#ただ下記の別資料をみると、mb_check_encoding も状況によっては危ないかもしれないようですね。ただエンコーディングのあるなしのみであれば、問題はなさそうです。
Garoon開発チームではPHP8.1の仕様変更とどう向き合ってきたのか / How we have responded to the PHP 8.1 mbstring specification changes - Speaker Deck

#筆者は以前、mb_convert_encoding の処理で文字化けした。筆者の場合には、そもそもデータソースをUTF-8に統一して、mb_convert_encodingは使わないようにした（メール処理ではなく、CSVデータに対する処理だったので）。そうできるならよいが、メール処理などではどのような種類のものがくるか特定できないので、それは無理だろう。

14:30 - 15:10 スポンサーブース


セッション中にも関わらず、それなりの人数がスポンサーブースにいました。


どこから来たのかについて、注意書きをみておらず適当な色のものを貼り付けてしまいました。またセッション間で廊下も結構人で一杯でした。

PHPの「歴史的な理由」ってなんだ！？



15:10 - 15:20 - roomC

scalar型について、 php-internals で検索すると 1998-05-01 の時点で存在していた。

snmprealwalk についての経緯（PHP3.0.8のときにいろいろあったとか？）
https://www.php.net/manual/ja/function.snmprealwalk.php

PHPで生成AIのAPIをやってみた



15:30 - 15:40 roomA

composer で探すと、openai-php というものを見つけてこれを使ってやってみた。

API利用は有料であることに注意。
API Keyについてはセキュリティ設定を施しておかないと、誰でも使えるので注意！
＊有料なので、誰かに利用されると支払いがやばいことになる（公開サービスなど、API Keyを知られてしまう状況の場合）。

クロージング - roomA



他の地域での PHP Conference の紹介

#下記にスケジュールあり
PHPイベントの世界 #PHP - Qiita

上記によれば
また、東京でも PHPカンファレンスJapan 2024が12月に開催 することがきまったとのこと。

懇親会 - roomD



懇親会冒頭の挨拶。後ろの参加者が見えるように前側の参加者が座っていく様は日本ならではかなぁと思いました。それにしても参加人数がものすごい。


十分な量の食事が用意されていて美味しくいただきました！


歓談中の名刺交換は、事前登録しておいたバッジ交換となりました！これは今後もどこかで使っていきたいと思います！


私にとって対面での PHP Conference 参加は、7年ぶり（前回2017年）です。2017年はPHP7に関する情報収集をしていました。今回は PHP8.1/8.2 をベースに情報収集しました。いくつか気になるキーワードも入手できたので、また時間があるときに深堀りしてみたいと思います！

2024年2月11日 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル:
登録: 投稿 (Atom)