日記(111)

<前 次>

アンパンマンDB(システム)

コメントのルールは、込み入ったものはハードコード、単純なものはデータベースに登録しているんですが、データベースに入れているほうのコメントルールの管理画面を作りました。
単純とはいっても、文面を動的に変えられないだけで、どういう場合に出すかとかは結構柔軟に指定できて、現在は最新映画のページに出ています。
管理画面向けのルールも同じように編集できるので、変なコメントへの対応がもうちょっとスピーディーになるかと思います。

アンパンマンDB

アンパンマンDB(記事更新)

来週の放送情報。

アンパンマンDB(みんなのタグ)

ちょっといたずら通報もあるので、ちょっと対策を作成中。
とはいえ、悪意があって嘘通報をしているというよりは、通報の趣旨を理解していないような感じが多いので、何をやろうとしているか理解させる方向で考えています。

GitHub

見せられるのはこの2つだけなんですが、作り始めてから動きのないリポジトリを整理しました。
完全に開発終了して続きを作る気のないものはアーカイブして、一応やる気のあるものは課題を立てました。

私は開発をGitHubの課題を使って進めているのですが、開発初期で課題もへったくれもないものは課題立ててなかったんですよね。
そうしたら、課題がないので存在をリポジトリごとスルーしてしまい、課題が立てられる程度まで開発が進まないという悪循環…むしろ何の循環もしていなかったのです。
なので、具体的な課題はないけどやる気だけはあるぞという意思表示だけの課題を立てておいたわけです。
この課題を起点にして、本当に開発を進めたり、本当の課題を見つけて登録したりするのです。

ここでは見せられないプライベートリポジトリだと、「作る」っていうやけくそ極まる課題や、「このリポジトリ何だったっけ?」みたいなどうしようもない課題が続々生まれました。
結局何のリポジトリか思い出せないとか、やけくそになっても手の施しようがないとかだったら、諦めてアーカイブ行きです。

SearchQueryStructure

mifumi323/SearchQueryStructure: 検索構文とかに使われるAND/OR/括弧などの構文解析をするやつ
新しいライブラリとして作り始めました。
「検索クエリ」ってよく言ってるよなってことで、Phrase→Queryに、解析(parse)の逆に構築(build)もできていいかもなって思って、両方に共通する構造化データから、Parser→Structureに名前を変更しました。
実装はまだ始めていませんが、最初の段階はSearchPhraseParserからコピーしてきて結果だけ何かしらのクラスを作って当てはめればいいかなって思ってます。
オプションで柔軟にとか、ビルドできるようにとかは最初の一区切りまでできてから。

SearchPhraseParser

新バージョンか別バージョンか、どうするか決めかねているんですが、データの返し方を大幅に変えようかと思っています。
現状だと、全部連想配列で返しているんですが、今どきのPHPだと、型をしっかりつけたほうがいいんですよね。
まあ、それを想定しての現状の関数名ParseToArrayで、単純にParseToObject関数を生やすのも一つの手なんですが、もう一つやりたいことがあって、そっちが問題なんですよね。
現在、パーサーはParserクラスで、実際にパースするParseToArray関数は、static関数です。
パーサーオブジェクトを作らずに呼び出す形なので、パーサーオブジェクトにオプションを持たせてデフォルト以外の動作をさせるとか、クラスを継承して使用を拡張するみたいなことが一切できません。
だから、オブジェクトを作る前提の別クラスを新たに用意する、というのも考えたのですが、クラス名はParserが完璧すぎて別の名前使いたくないし…。
で、そこまでやると、使い方が根本的に変わってしまうので、そもそも同じライブラリである必要があるのか?って疑問もわいてくるのです。
しかし、別ライブラリとして作るなら、いったいどんな新しい名前にするの?って話にもなるわけで。
サーチに使うと限らないのでサーチの部分変えるか?
検索語の組み合わせを取り扱うのでフレーズという単語を使ったけど、もっとぴったりな単語はあるか?
パーサーの部分は今のところ完璧なので名前から外す気はない。

<前 次>