ここTGWSで使っているテストツールのPHPUnitをバージョン9から10に上げました。
以前11に一気に上げようとして、必要な変更のあまりの多さに撃沈してしまったのですが、10までならひとまず大きなトラブルもなくスムーズに移行できました。
まあ、そのスムーズさで300ファイルほど修正が必要だったんですけどね。
ほとんどが機械的な置き換えで済むシンプルなものだったので、普通の置換やコピペで済ませました。
最近はAIエージェントとかもありますが、変なところで独創性を発揮しちゃうことが少なくないので、AIに求めるのは助言程度にして、今回は自分で作業をしました。
お宝集めて大航海！「幻の海トラシュカ2025」 （2025/7/23）｜目覚めし冒険者の広場
お宝集めだ！
今回はなんだか例年以上にラグがひどいみたいで、何が起きてるかわからないうちに何度も海に落ちました。
普段ならラグ読みで早めに回避したりしていたんですが、そもそもいつの間にか画面から自分がいなくなってますからね。
本当は全員分一気に行く予定でしたが、今日のところは一回だけで終わらせました。
報酬集めるならもうちょっと空いてから周回かな。
他の写真は以下から。…って程にも多くないけどさ。
写真置き場「2025/07/30」
まだ本番環境には反映してないですが、紹介botの本日の情報、短縮表記を試しています。
TwitterAPIの制限が本当に厳しくて、なるべく情報量を落とさない範囲で投稿数を減らしたいんですよね。
で、実際に同じ日付の投稿と見比べてもらえればわかると思うんですが、投稿数を2から1に圧縮できました。
効果あるんだからさっそく使おう…と言いたいところだったのですが…
画像もまとまっちゃうので、その他大勢の合成画像が異様に縦長になっちゃう！
こっちもうまく対応できてから、本番適用と行きたいところです。
文字列(という名のバイト配列)から画像を読み込む関数。
紹介botに出す画像はPNGとJPEGなんですが、将来的にはWebPも使う可能性があるので、imagecreatefrompngとかimagecreatefromjpegとかを一つ一つ使っていたらきりがないなって思ったんですよね。
これなら、ファイルをメモリに読み込むのは自前でやる必要はありますが、ファイルフォーマットは自動で判別していい感じに読み込んでくれるはずです。
とりあえずは、本当に使えるかどうかの確認からかな。
このプルリク、どうしよう。
セキュリティ上の修正なんだから、本当ならとっとと採用したいところなんですが、これ、ビルドは通るけど実際に実行するとエラーで落ちるんですよね。
動かなかったらもうセキュリティもへったくれもないわけで。
さすがに不採用というわけにもいかないから、自分でエラーをどうにかしてマージかな。
[PHP]DateTimeのtimezone_typeって何だ？ #PHP - Qiita
記事投稿しました。
アンパンマンDBで日時の出力をDateTimeそのままjson_encodeしてみたら見たことないプロパティが出て来たんで不思議だったんですよね。
で、json_encodeに限らず出てくるので、題材としては変数の中身を見るためにより広く使われるvar_dumpのほうを挙げた次第です。
それはそうと…
【PHP】Qiita デイリーいいね数ランキング【自動更新】 #LGTM - Qiita
なんか1位になってました。
他誰もいないけどな！
鶏口となるも牛後となるなかれということわざがあるけど、鶏どころか単細胞生物ですな。
古いスタイルシート整理してました。
レスポンシブ対応前の古いページ用の古いスタイルシートもまだ残しているんですが、さすがに数が少なくなってきたので名前を変えたり。
コメントに関するちょっとした機能実装中。
関係あるのは一部の人に限られますが。
ここんとこ自動テストが開始まで時間がかかるようになったので、テスト初期化処理の改善をやっていました。
まずは、一部のテストでしか使わないファイルのコピー処理を実際に使うまで遅延させて、部分的なテストの場合に不要なコピーをしないようにするところから始めました。
ただ、計測したところ、ファイルコピーにはさほど時間はかかっておらず、逆にテストの邪魔になるファイルの削除が時間的には支配的でした。
ファイル検索に時間がかかっているようなので、RecursiveDirectoryIteratorあたり使ったらどうかなーとか思っています。
「#2025年はアンパンマンでこんなエピソードが観たい」の追加です。
PHP: fputcsv - Manual
> escape が空の文字列("")以外に設定されているとき、 » RFC 4180 に準拠しない CSV が生成されたり、PHP の CSV 関数を介してラウンドトリップ(往復変換)でデータが壊れる可能性があります。
CSVが変な理由、これでした。
エスケープ方法設定したらバグるから設定消さなきゃいけないって完全に罠じゃねーか！！
アンパンマンDB以外のCSV出力機能も同じ罠踏んでそうな気がするので、他も確認してから修正版アップしようと思います。
ｶｲﾏｼﾀｰ pic.twitter.com/IMtzge1UbQ
— 📛松田美文 (@matsuda323) November 20, 2024
コラムから転記。
CRONとかで動かす方のCLIのPHPも8.3にバージョンアップしました。
今のところは問題なさそう。
メテオンもどきのあれ以外は特に問題なさそうだったので、本番適用。
今のところ問題は起きてなさげ。
PHP8.4もリリース間近ですが、しばらくは様子見です。
7.2で追加された強ボス一通りやってみました。
まあ基本的には昔の強ボスと同格なので、そんなに苦戦せず。
大切な家族を失った遺族の弱みに付け込んだド畜生。
こちらのレベルが高いこともあって、特に強さは感じなかった。
飴舐めてるやつ。
強モードになっても飴舐めまくってたけど、まめちしきでは飴への言及なし。
なんかピラミッドの奥で出くわしたやつ。
こいつだけちょっと強く感じた。
超ちからためからのノータイムはげしく斬り裂くで一度死んだ。
本編では地獄の連戦であまりにしつこくしんどかった魔勇者。
強ボスでは闇のころももなく連戦もなく、聞き分けのいいお嬢様でした。
多分ネルゲル強のほうが強い。
そしてこちらが特に関係のないキラーマジンガ。
他の写真は以下から。
写真置き場「2024/11/11」
ゲーム本体はもうとっくに動かないんだけど、微妙な警告が出ていました。
PHP8.3の動作確認中だったのですが、バージョンアップの影響かどうかは不明です。
どのみち、良い傾向とは言えないので、修正しています。
というわけで、ステージング環境的な場所で、動作確認中。
表示時にエラーが起きないかどうかだけなら、クローラーを走らせればいいだけなので楽。
まあ、でたらめに走り回るので、エラー発見効率はお察しですが。
コミットメッセージが紛らわしいですが、アンドゥ・リドゥ機能の実装を始めました。
GitHub Copilot を試しに使ったんですが、チャット機能で生成させると微妙で、履歴の一動作に相当するインターフェースを作ってやると、それに沿っていい感じに作ってくれました。
アンドゥ・リドゥ機能自体はエディタ系のプログラムでは定番なので、お手本となるコードも豊富なんでしょうね。
こっから先の、各動作を実際にやり直す機能は、さすがに自力で実装しようと思います。
とりあえず主要なファイルは一通りアップ終わりました。
また発動していないバグ修正。
話数が空欄じゃなくて「0」になっていた場合に、「第0話」とかになってしまうんですが、アンパンマンDB的には「0」も空欄扱いしたいので、空欄の処理に飛ぶようにしました。
さっきのHTMLと一緒にアップ済みです。
もうそろそろPHP8.4の正式リリースも近そうですが、うちはまだ8.2だったので、ひとまず8.3まで上げることにしました。
とりあえず開発環境での動作は一部のライブラリ以外はコードの修正なしで大丈夫そう。
本番サーバーはオプションを変えるだけだからいいとして、DockerとCI環境も対応しておかないと。
コラムからの転記。
この程度なら毎日いっぱいやってもいいのにね。
リストをNULL検索できないバグを修正しました。
ただ、今のところ、何もない項目はNULLじゃなくて空文字列が入っているので、実質的に影響はありません。
Xdebug - Debugger and Profiler Tool for PHP
Xdebug導入しました。
すなわち、Xdebug使わない縛り辞めました。
もともとデバッガとしては、PHP標準のphpdbgを使ってました。
PHPUnitのカバレッジもphpdbgだったんですが、PHPUnit10以降(最新版は11)には使えなくて、phpdbgのために古いのを使う続けるのも厳しいなって思ってました。
カバレッジ計測の選択肢としては、PCOVもあったんですが、あんまり更新されてなさそうだったし、カバレッジ「だけ」というのもどうかと思ったので、デバッグ並びにカバレッジ計測の定番、Xdebugを導入した次第です。
そもそもXdebugを避けてphpdbgを使っていたのは、XdebugはPHP標準に入っていないというのと、カバレッジ計測が遅いという話を聞いたからだったのですが、実測してみると、今はXdebugのほうがphpdbgより1割ほど早く終わりました。
実装は特に進まず。
やっぱりエラー処理となると、やみくもに実装を始めるより、ちゃんと考えないと詰みますからね。
エラーが起きたときも、途中までのパース結果はエラー本体とともに返したい、というのは昨日言った通り。
どこでエラーが起きたかというのも返せると、修正もしやすくなりますね。
となると、字句解析の時点で、各シンボルに位置情報を埋め込む必要がありそう。
あと、空文字列を渡されたときの特別対応もあっていいかな。
旧来の機能をおおむね移植完了。
ただ、異常系に対しては、途中までの結果を返すのではなく、例外を投げたいので、もうちょっと調整が必要ですね。
できれば、専用の例外を作って、例外オブジェクトの中に途中までの結果を詰め込んで、例外をキャッチすれば失敗時も旧来の動きにできるという方向で作りたいですね。
やっと作り始めました。
美しい設計で作り直せるはずだと夢想して、「で、美しいって具体的には？」で止まって、長いことほったらかしになっていました。
これ、アンパンマンDBの検索機能の機能強化に使おうと思ってたんですよね。
だから、美しさを目指していつまでもスタートラインでぐるぐる回ってちゃアンパンマンDBも変われんのです。
ともかく、最初にやるべきことは旧来のコードのコピペと最初に決めたし、出力が美しければ中身が泥水でも結果は変わらんので、とりあえずほぼコピペでどうにかなる部分だけ持ってきました。
既にINodeインターフェースを用意していることからもわかるように、最終的な結果はINode実装クラスで返そうと思っています。
昨日のふくろうおじさんの流れで今度はおじいさんを追加しました。
こっちはコラムから転記組。
元気倍率アップ系ですね。
300より200のほうが見た目豪華なのがポイント。
テストが不安定な問題、直接の原因は一応わかりました。
エラーコード0xC0000005(-1073741819)、アクセス違反です。
アクセス違反なら何でもこのエラーが出るので、このエラーコード一つで真の原因の特定はできません。
傾向として、カバレッジ計測なしだとエラーは起きず、計測ありのときだけエラーが出ることがあるので、カバレッジと何かの競合だと思われます。
落ちる部分のコードがやってることと言えば、同じPHPスクリプトを条件を変えて2回呼び出していることなので、ここで何らかのロックがかかってしまってカバレッジを邪魔しているのでは？と考えています。
完全解決までは、カバレッジ計測の頻度は減らすかなぁ。
サーバーサイドでの自動生成の目次の仕組みを作って、各ページに適用中。
うちのサイトって、昔はいろんなページに自動生成の目次がありました。
ただ、それはInternet Explorer、それも古いバージョン専用だったので、もう動いてなかったんですよね。
静的HTMLファイルに労せず目次を取り付けたいという動機でJavaScriptを使ったのですが、動かなきゃ世話ないですね。
私の思想として、サイトの基本的な機能はなるべくJavaScript抜きでも動作するようにしたいというのがあり、この思想にも反する仕組みでした。
一方で、URL上は.html拡張子に見えるファイルは、現在は大部分をHTMLファイルに見せかけたPHPファイルを裏で動かしています。
詳しく言うと、ただのHTMLファイルに見せかけたPHPファイルが出力したただのHTMLファイルを最終的に表示しているのですが、とにかくサーバー側でいったん動的な処理を挟んでいるわけです。
この動的な処理の部分に目次自動生成を差し込めば、JavaScriptに頼らず、ブラウザに依存せず、それでいて労せず目次を作れるのです。
今のところ、自動生成の仕組みはできたので、今は各ページに適用するのを頑張っているところです。
先ほどまで自動化だの労せずだの言っていましたが、目次以前にまずHTMLそのものを修正しないといけないのです。
PHPを使う仕組みに切り替えた時点から、HTMLも4.01から5をすっ飛ばしてLiving Standardに切り替えているのです。
…切り替わってないのです！
PHPに切り替えた時点で、自動生成のヘッダとフッタにより、ガワだけはLiving Standardになりましたが、中身はほとんど手付かず。
4.01のままのHTMLからじゃ、Living Standard用のシステムで目次を自動生成はできないのです。
ブラウザはだましだまし動いてくれますが、ブラウザほど気を利かせてない自作システムは、だませないのです。
ということで、労せず目次を自動生成するために、現在、労しています。
mifumi323/SearchQueryStructure: 検索構文とかに使われるAND/OR/括弧などの構文解析をするやつ
新しいライブラリとして作り始めました。
「検索クエリ」ってよく言ってるよなってことで、Phrase→Queryに、解析(parse)の逆に構築(build)もできていいかもなって思って、両方に共通する構造化データから、Parser→Structureに名前を変更しました。
実装はまだ始めていませんが、最初の段階はSearchPhraseParserからコピーしてきて結果だけ何かしらのクラスを作って当てはめればいいかなって思ってます。
オプションで柔軟にとか、ビルドできるようにとかは最初の一区切りまでできてから。
新バージョンか別バージョンか、どうするか決めかねているんですが、データの返し方を大幅に変えようかと思っています。
現状だと、全部連想配列で返しているんですが、今どきのPHPだと、型をしっかりつけたほうがいいんですよね。
まあ、それを想定しての現状の関数名ParseToArrayで、単純にParseToObject関数を生やすのも一つの手なんですが、もう一つやりたいことがあって、そっちが問題なんですよね。
現在、パーサーはParserクラスで、実際にパースするParseToArray関数は、static関数です。
パーサーオブジェクトを作らずに呼び出す形なので、パーサーオブジェクトにオプションを持たせてデフォルト以外の動作をさせるとか、クラスを継承して使用を拡張するみたいなことが一切できません。
だから、オブジェクトを作る前提の別クラスを新たに用意する、というのも考えたのですが、クラス名はParserが完璧すぎて別の名前使いたくないし…。
で、そこまでやると、使い方が根本的に変わってしまうので、そもそも同じライブラリである必要があるのか？って疑問もわいてくるのです。
しかし、別ライブラリとして作るなら、いったいどんな新しい名前にするの？って話にもなるわけで。
サーチに使うと限らないのでサーチの部分変えるか？
検索語の組み合わせを取り扱うのでフレーズという単語を使ったけど、もっとぴったりな単語はあるか？
パーサーの部分は今のところ完璧なので名前から外す気はない。
正式な曲目が公開されたので反映しました。
『森は枯れても2024』が新録ですね。
映画も森を舞台とした話なので、実際に使われる可能性が高そうです。
名前空間とか調整して、再公開しました。
これでもうばっちりだと思ったのですが、試しに自分のプロジェクトに入れようとしたら、うまくいきませんでした。
他の人のライブラリとかと見比べても決定的に足りないものはなさそうに見えるけど…。
急ぐ用事ではないし、ちょっと後日考えてみよう。
他のライブラリも名前空間変更したのですが、どうにも微妙な感じです。
一応、メジャーバージョンを上げておいたので、バージョン指定で導入している人には悪影響ないとは思うのですが。
リストの現行のストリクトクエリのテストを作成。
新記法にする前に、内部処理を変える必要があって、旧記法でも同じ内部処理を使う必要があるので、内部処理を変えても旧記法が通用することを確認するためのテストが必要なのです。
PHP-CS-Fixer/PHP-CS-Fixer: A tool to automatically fix PHP Coding Standards issuesには、ドキュメントコメントでもないくせにドキュメントコメントぶっているただのコメントを本当のただのコメントに戻す機能があります。/** ただのコメント */→/* ただのコメント */
しかし、/** @var ADBValueList $adb_value */みたいに、ローカル変数の型を指定しているコメントまで、ただのコメント扱いされてしまいます。
Intelephenseでは、ちゃんとローカル変数のドキュメントコメントも認識してくれるので、PHP-CS-Fixerにぶち壊されると困るのです。
そこで使うのが以下のオプション。
Rule phpdoc_to_comment - PHP Coding Standards Fixer
ドキュメントコメントをただのコメントに戻す処理の制御ができます。
今回の件なら、ignored_tagsオプションにvarを入れれば、@varのドキュメントコメントだけは見逃してくれるようになります。
PHPUnit自体の機能とは特に関係ないんですが、うちのサイトの自動テストでは、HTMLの表示とかのテスト(結合テストに近いところ)もある程度やっていて、出力結果の保存とかもやっているんですね。
テストやるたびに、たとえ何の変更もなくて何の問題もなくても、何百ページ分ものHTMLファイルが出来上がります。
たとえ何の変更もなくて何の問題もなくても、改めて毎回テストをやること自体は、回帰テストといって、とても有意義なのですが、回帰テストは正しいか正しくないかだけわかれば充分なので、何が出力されたかまで細かく残す必然性はありません。
とはいえ、たとえ何の変更もなくても問題が起きることがあるから、回帰テストが必要なわけで、回帰テストに落ちたときだけは、何がおかしくなったのかを残す必要があります。
なので、普段邪魔になるからと言って、一律で保存をやめるなんてことはしないほうがいいでしょう。
だからといって、テストに落ちたときだけ保存するという器用なこともなかなか難しいわけで。
ということで、出力結果を破棄するオプションを作って、それをON/OFFすることで、保存するかどうか切り替えるようにしてみました。