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することで、保存するかどうか切り替えるようにしてみました。
ストリクトクエリの件、区切り子じゃないコロンをどうするかでちょっと悩んでます。
str_getcsvは区切りとして扱わない区切り子を考慮してくれますが、そのためには「"」など囲み記号が追加で必要になるんですよね。
単なるCSV(ここではCharacter Separated Values)であればそれでいいんですが、アンパンマンDBの検索構文では、ルーズクエリ・ストリクトクエリ両方に共通する文法で、スペースや「"」を含む単語は「"」で囲むという仕様があって、クオートの仕様がぶつかってしまいます。
一応ぶつかったところで、どちらにもエスケープ処理はちゃんとあるので、「"」で囲んだものを「"」でエスケープして「"」でさらに囲むみたいなことをすれば、不具合なく取り扱えるはずですが、ちょっとさすがにややこしいかなと。
ストリクトクエリの囲み記号を「"」以外にするか、そもそもstr_getcsvを使わずに完全に独自仕様にするか…。
あと、ストリクトクエリをパースするのとは逆に、ストリクトクエリを構築する機能もアンパンマンDBにはあるんですが、str_getcsvの逆をやる関数が実はPHPには今ないんですよね。
CSVの構築にはfputcsvがありますが、これはファイルに出力されてしまいますし、末尾に余計な改行も追加されます。
多分どうにかする方法はあるとは思うのですが、そこまでしてPHPの標準関数使うべきかな…と思ったり。
やはり独自仕様にする…かなぁ。
昔のアンパンマンDB(アンパンマンDB3)では、編集画面でプレビューすると、どの項目が編集されたか、編集内容を編集前と編集後で比較表示できるようになっていました。
しかし、今のバージョン(アンパンマンDB4)になって、項目の取り扱い方が大きく変わったため、比較表示機能は失われてしまいました。
復活させました。
今回、編集内容の表示機能を復活させるに当たって、以前より見やすくしてみました。
編集前後を並べるのではなく、diffコマンドみたいに差分のあった行を色分けして強調表示しています。
欲を言うならもっとdiffコマンドに寄せて、追加行に+、削除行に-をつけたりするとかあってもよかったかもしれないですね。
これを作るに当たって使ったライブラリは、編集データの文字列化に使うsymfony/yamlと、できた文字列の差分表示に使うsebastian/diffの2つ。
差分表示のほうははJavaScriptでやっちゃおうかなとか思ってたんですが、しっくりくるものがなかったので、結局どっちもPHPでやりました。
symfony/yamlは、構造化されたデータを複数行のわかりやすくdiffの取りやすい文字列に変換(シリアライズ)してくれます。
diffを取りやすいというのがポイントで、JSONだと配列の要素の後ろ(または前)にコンマがつくかつかないかが要素の順序で変わったりして、実質変化のない行まで差分になってしまうのですが、YAML形式だとそういうのが起こりにくくなっています。
ただし、構造化されていないただの文字列を渡すと、JSON形式の一行の文字列にまとめられてしまうので、この場合だけはシリアライズ処理をせずにそのままdiffに渡します。
sebastian/diffは、おそらくPHPUnitにも使われている、行単位の差分検出ライブラリです。
シンプルに使えば、一発でいい感じのdiff文字列を出してくれるのですが、HTMLページに表示するにはdiff文字列ではちょっと都合が悪いので、配列形式のデータを一度出してもらって、そこから自力でHTMLを作るようにしています。
差分行の色は、GitHubと同じ色にしました。
【PHP8.4】メソッド引数のデフォルトnullがついに禁止される #PHP - Qiitafunction foo(int $x = null)みたいな、null許容指定していないのにデフォルト値null入れてたらnull許容(ここでは?int扱い)になるっていう気持ち悪い挙動が今後なくなるみたいです。
で、うちの場合、PHP-CSFixerで@Symfonyの設定を入れていて、これがデフォルト値nullを入れていたら方の左に付いているnull許容指定の?を自動で消しちゃうんですね。
見た目気持ち悪いけど@Symfonyの推奨ならいいかーって思って消されるままにしていたんですが、今後そういうのは通用しなくなっていくので、対応を入れました。
先程の記事にも書いてあるのですが、nullable_type_declaration_for_default_null_valueオプションで、逆に?が足りないところに自動でどんどん付けてくれるようになります。
動くようになりました。
Composerのバリデーションは神経質すぎるところがあるので実行しないことにして、本当にやりたい自動テストだけにしました。
phpdbg使えなかったけど、普通にPHPUnitを動かすだけでカバレッジは取れました。
アーティファクトがばらばらのファイルじゃなくてZIPアーカイブしかなさそうなので、HTML出力したカバレッジレポートを見て回ることはできないけど、まあ手元でZIP展開すれば見られるのでこれはまあOK。
あとは…そう、もういらなくなったCircleCIとの連携を切るだけ。
なんかドメイン追加したらコンテナが立ち上がらなくなったんですが、設定ファイル内のコマンド順序を入れ替えたらなぜか動くようになりました。
カレントディレクトリがおかしい系のエラーみたいだったから、コマンド内部でひっそり変わってるのかもと思ってコマンド順序を入れ替えたのですが、ディレクトリの確認はしてないので、実際のところ本当にこれでよかったのかは謎です。
致命的ではないもののPHPのエラーも起きているようだし、もうちょっとしっかり設定を見直してみてもいいかもしれません。
とりあえず、自分のアカウントへのリンクをうちのサイトのトップページに追加しておきました。
dockerのphp8にGD ライブラリをインストール #PHP - Qiita
このへんを参考に画像ライブラリ入れてみました。
これでとりあえず画像は表示されるようになりました。
文字列の表示とかツイート文字数計測とか、なぜかうまくいかない部分がまだ残っていますが、ひとまず目立つ部分はいい感じに動くようになりました。
.htaccessの調整を進めたのと、PHPの画像関連の拡張の有効化。
ただ、まだローカル開発環境で画像は表示できてないです。
何が足りないんだ？
リダイレクトループの件は、リバースプロキシ兼TLSに使っているNginxとPHPの実行環境になるApacheの間の通信が暗号化なしのHTTP通信だったため、クライアントとの間がすでにHTTPSなのに気付けず強制HTTPSのリダイレクトを繰り返していたということでした。
強制HTTPSに条件を追加することでとりあえずは回避しました。
あとは、画像がうまく表示されないのをどうにかしないと。
ちょっと前からテストが動かなくなっていたので、ちょっと修正していました。
ちょっと修正というにはちょっといろんなところを調べまわってちょっと大変だったのですが。
で、最終的に何が悪かったのかというと、ネットの疎通確認に確実に存在するURLとして http://example.com/ を使っていたら、https://example.com/ にリダイレクトされていて、httpの方に繋がらないぞという判定になっていたことでした。
大変だったのは、それを突き止めるために別ソフトの修正を行ったら、修正が何も反映されず古いビルドが使われ続けたこと。
こっちは、修正が反映されなくなり始める前のバージョンまでソースを差し戻して、そこから新たに修正し直しました。
こういうのをどうにかできるのはGitなどバージョン管理システムのいいところですね。
検索の初手が身も蓋もない感じだけどまあまあよさげなコードに見える。 pic.twitter.com/acwrdhyTNG
— 📛松田美文 (@matsuda323) September 18, 2023
出来上がったコードは、C#側は.NET Framework 2.0、PHP側はPHP 7.0相当のコードが出てきて、両者とも、Haxe自身の言語仕様やライブラリとの互換性のためのファイルがいくつか追加されていました。
C#の方は、丁寧にもDLLにまでビルドしてくれたので、コードで共有しなくても、このDLLをプロジェクトに追加すれば、Haxeで作ったライブラリをC#で使えることになります。
PHPの方は、パッと見た感じ、互換性用のファイルが、PHP 8.2ではエラーになりそうな感じだったので、何か追加対応をしてエラー解消するか、これのためのPHP 7.0サーバーを作るか、何か対応が必要そうです。
プロジェクト実質停止してるけど、funyakあたりでも何かしらの形で使ってみたいんですよね…。
以前別キャラで茶番茶番と言っていたあのクエスト、ァォィョッュでも途中まで進めました。
これ進めておかないとアクセ屋のカーメロさんがずっとうるさいのでね。
本当は一気に終わらせてしまうつもりだったのですが、記憶していた以上にあちこち走り回らされて、今日中には終わりませんでした。
しかし改めて同じクエストをやってみて、ドラクエ10は人間相手だと手ぬるいなぁ…と。
モンスターみたいに息の根を止めてはいけないにしても、元気に走り回れないぐらいダメージ与える(婉曲表現)とか、せめて身柄を拘束ぐらいはしないと…。
ともかく、他の写真は以下から。
写真置き場「2023/09/04」
テスト環境でアップロードができない問題、解決しました。
サーバーとPHPを繋ぐFastCGIが、特に何も指定しない状態だと、ほとんど無に等しいアップロード容量になってしまうのが原因でした。
ここはPHPに合わせて、2GBまでアップ可能にしてみました。
まあ、動画サイトじゃないのでそんなにアップすることはないけど。
テスト環境の方で、ファイルをアップロードできないトラブル発生中。
本番環境の方はアップロードできるので、運営には今のところ支障はないのですが、新機能の開発とかには影響があります。
PHPの方の設定には問題なさそうだから、Webサーバーあたりかなぁ。
【PHP】相対パス(相対URL)を絶対URLに変換する - Qiita
自前で変換処理を書いていてバグったのでこれを機に直して、その副産物です。
ゲーム記に『バイオハザード RE:4 Chainsaw Demo』を追加
ゲーム記にページ作りました。
体験版をやった限りでは高く評価してるんですが、製品版と買うかというと、ちょっと無理かなぁ…と思っています。
以前も書いたように、私がもう操作下手過ぎるんですよね。
視点操作が逆になりがちで、操作中に混乱することが昔から多いんです。
ただ、だからと言ってTPS・FPSを敬遠していると、そのジャンルの面白いゲームを一生楽しめないし、安売りしている過去作で練習してみるというのも一つの手かも…。
まだ開発環境でエラーが起きることがあるので、本番環境となるべく同じになるように設定を調整していました。
デフォルトでZIPが使えないのが盲点だった。
開発環境もPHP8.2に上げました。
Windowsなんで無難にXAMPPでいいかーって思ってインストールしたら、まさかのPHPがバグってるバージョン(正確には拡張モジュール)。
バグってないバージョンでプログラムを上書きとかもしてみたのですが、うまくいかず。
結局、XAMPP抜きでインストールする手順で、最新版をFastCGIとして設定したら、期待通りに動作しました。
もともとXAMPPに入っていたPHP関連の設定は邪魔になるので全部消しました。