「アンパンマンDB」に関する日記(10)

アンパンマンDBの、主に開発に関する日記。

<前 次>

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

検索用データ更新処理競合対策が出来上がって、いったん今の状態でリリースしました。
最初の一発はどうしても全更新になるので、初期データ作成中に何度か競合が起きてしまいましたが、なんとか終わりました。

ここから先の検索処理は、関連箇所全部一度に修正しないといけないのはさすがに厳しいので、どうにか一箇所でどうにかなるようにやっていこうかと思っています。

GitHubとアンパンマンDB

GitHub

昔C#で作ってたちょっとしたツールをGitHubでソース公開しました。
ちゃんと作り込んだツールじゃないからバイナリの配布はしないけど、需要があるなら…JavaScriptでWebアプリ化したほうが使い勝手いいか?

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

検索用データ更新処理競合対策中。
変化がないときにまで更新しないというシンプルな対策です。
ただ、動作確認してみたら、うまく動いてるんだか動いてないんだかよくわからない状況…。
動作確認方法も工夫必要かも。

アンパンマンDB

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

来週の放送情報。
ナポレオンパイくん登場多いな。

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

やっぱり大変なので、ちょっと自動テストのほうを拡充中。
関連箇所全部一度に修正しないとエラーになっちゃうんですよね。
で、一箇所だけどうしてもテストできない場所があって…。
まあ、実際に使ってないからなんですが、一応その部分も対応しておきます。

あと…そうだ。
検索用データ更新まではすでにリリースしたんですが、本番投入してみたら、検索用データ更新処理中に別の書き込み作業をやると結構な確率で競合起こしますね。
このあたりはもうちょっと工夫が必要になりそう。

ドラゴンクエスト10とアンパンマンDB

ドラゴンクエスト10

パドレ
ホワイトデーの結果出てました!
先月マローネが勝ったから夫婦で、ということなのか、パドレ個人にも個別に流れが来ていたのか。
報酬のハートのシャボン玉はかわいいですね。

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

昨日時点で役に立たなかったリンク情報、いろいろパターンを考えた末、結局昨日の実装の延長でやることにしました。
載せられないなら載せられるようにデータを引っ張って引っ張って、リンク情報に行情報も入るようにしました。
これを検索に使うのがまたちょっと難儀なのですが…。

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

昨日実装したリンク情報、やりたかったリンク検索には役に立たないものでした。
いえ、本当はリンク検索自体は一応できる仕組みだったのですが、リストの何行目という情報が抜けていて、行情報を差し込めるような形式でもないので、ストリクトクエリによる同一行内複数条件に対応できなかったのです。
「それをわざわざやりたいケースがあるのか?」と言われると、複雑な検索を使い倒している自分でさえも、「ないな…」となってしまうので、こだわる必然性はないかもとは思うのですが、ここまで頑張ったからには、やり切ってしまいたいです。
それはそうとして、今のリンク情報も、あれはあれで使い道はありそうなので、そっちも含めて考えてみたいところです。

アンパンマンDB

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

新たに公開された公式情報を追記しました。

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

リンク情報の件、保存の高速化と安定化を図って、ひとまずリリースしました。
今のところうまくリンク情報を保存できているようです。
これを使ってリンク検索を実装するのはこれから。

アンパンマンDBと更新履歴

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

来週の放送情報。
映画のほうの情報も追加公開されてるけど、それは後日ということで…。

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

リンク情報保存ができました。
ただまあ、実際動かしてみると結構データ量が多くなってしまったので、何かしらもう一工夫したいかな、というところです。

更新履歴

更新履歴のページ、ひっそりこっそり更新しました。
もともと、この更新履歴に表示されないアンパンマンDBの更新履歴にはリンクを張ることで対応していました。
で、同様に表示されていなかった雑多の更新履歴キャラ倉庫の更新履歴にもリンクを張るようにしました。
数も増えてきたので、邪魔にならないように、折り畳みも入れています。

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

テスト効率化の仕組みをさらに強化して、本命だったリンク検索に着手!
今できてるのは、「準備の準備」段階ですね。
テスト効率化は「準備の準備の準備」で。
リンク検索は、「実際にリンクで検索する」が最終目標で、その準備段階として、「リンク情報を保存する」があります。

で、今できたのは、「リンク情報を保存できる入り口の仕組み」というわけです。
次は、リンク情報を保存することになります。
記事本体にはリンク情報そのものではなくリンクのヒントが記録されているので、このヒントを探してリンク先を特定していくのが作業の中心となります。

ドラゴンクエスト10とアンパンマンDB

ドラゴンクエスト10(ァォィョッュ、しろいコキン)

ラキ
第12回 アストルティア・ナイト総選挙! (2025/2/25) |目覚めし冒険者の広場
ホワイトデーイベント!
だけど衣装は黒い!!
ラキ君はバージョン7のオープニングムービーでも見かけた子ですね。
私は出会えるまでまだまだ遠いです。

ホワイトショコラ

  • クエスト「ナイトたちの血戦2025」をクリアした!

ミフミン以外はクエストもクリア!
対象モンスターはちゃんと白いですね。
結末はまさかまさかの…!

まあ、ここで結末を言うなんて無粋なことはしませんからね。

他の写真は以下から。
写真置き場「2025/03/03」

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

リスト系の検索構文でワイルドカードが効かなくなっていたので、ひっそりこっそり修正しました。
ちゃんと網羅的にテストしとかないとなァ。
手作業だけでなく自動テストも。
CSVとかで検索対象と検索構文の対応表を作ったら効率よく網羅的なテスト作れるかな。

アンパンマンDBとUno Platform

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

来週の放送情報。

Uno Platform


とりあえずプロジェクト作ってみたけど、UWPをベースにしてマルチプラットフォーム化した感じなのね。
私にとってUWPは今一つだったし、それがベースになってる時点で熱くないな、という印象。

最初のウィザードが充実して、最初の工程を手取り足取りやってくれるけど、その分、ウィザードが終わった瞬間複雑なプロジェクトが目の前に現れます。
Avalonia UIは「UIの他はMVVMだけ用意したから後は好きにやれ」みたいな初期状態だったので、この点は対照的ですね。
UWPをしっかり学んだあとのマルチプラットフォームを目指すステップだったらこの複雑さがむしろ嬉しくなるのかも。

あと、MVUXっていう聞いたことないアーキテクチャが。

がっつり使い倒す前提ならいいかもしれないけど、今の私には重いかな。

アンパンマンDBとドラゴンクエスト10

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

前売り券情報が来たので反映。

来週の放送情報。
ジャムおじさんがタイトルに現れると優しい話になる傾向があるけど、さすがに氷の女王は…!

ドラゴンクエスト10(おきがえリポちゃん)

リボンスターの服
おきがえリポちゃん ~ リボンスターの服 ~ (2025/2/19)|目覚めし冒険者の広場
毎月の!
女性らしいきれいなドレスですね。
ミフミンは男だけどな!!

リボンスターの服
リボンスターの服
他の二人はちゃんと女。

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

地味なところですが、よく使われる検索結果のキャッシュを記事更新時に自動更新するようにしました。
それと、使わないとわかっているキャッシュを早期に消す対応も。

あと、トップページでの映画カウントダウンを2025年版に差し替えました。
5月末ごろからカウントダウンが始まります。

アンパンマンDBとNeoMupl

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

声優が判明したので記入しました。
ついでに判明済みの他の情報も。

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

昨日の問題に対する対応作り始めました。
検索以外に使うこともできそうな気がしたりしなかったりするけど、どうしようか…。

NeoMupl

11月に作ってたやつ、すっかり忘れてたんで今日リリースしました。

アンパンマンDB

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

レンタルDVD。
今回は忘れないうちにね。

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


一番厄介なリスト系の項目も文字列保持検索に対応して、ひとまず一区切り。
自動テストでも見つけきれなかったやり残しがぼろぼろ見つかったので、もうちょっとしっかり確認してからリリースしようと思います。

「一区切り」という煮え切らない言い方になっているのは、やり残しがあるからということのほかに、今回の対応範囲となる「単なる文字種保持検索」では結局「ばいきんまん」と「バイキンマン」を実用的に区別できないから、なんですよね。
さっきの画像を見ての通り、文字種保持検索を使えば、「バイキンマン」というカタカナを明示すれば、「ばいきんまん」と区別して検索できます。
しかし、キャラDBからボタンで移動できるリンク検索は、文字列の正規化とは別枠であいまい検索をしているので、ここの厳密さに関しては全く手つかずということなのです。
リンク検索は従来のやり方の延長線上だとどうしても「ばいきんまん」と「バイキンマン」を区別しようがないので、根本的に作り直そうかと思っています。

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


テキスト系項目も文字種保持検索に対応。
この辺りは間接的な影響とかもまあまあ多いので、一箇所の変更が複数に波及する部分がありました。

カテゴリ系は、内部的にはテキストマッチじゃないので、文字種保持検索には今のところ対応しない予定です。

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


文字種保持検索、ひとまず一番使うインデックス検索(キーワードだけ入力したら発動するやつ)を対応させました。
この写真でいうと、「Baby」の部分に「baby」で反応するかどうかが変わっています。

キーワードだけ入力の場合はもちろん従来通りあいまい検索になるんですが、ストリクトクエリで新たに追加した文字種保持用演算子を使う(containsなど)と、大文字小文字ひらがなカタカナなども区別するようになります。
このあたりの追加された演算子などは、後日別課題として、詳しい解説ページを作るつもりでいます。

あと、文字種保持検索を実装すると、ルーズクエリの構文側、例えば「キャラ:ブルーベリーちゃん」の「キャラ:」の部分などが、文字種区別するようになるんですが、確認してみたらここはもともと区別してました。
なので、構文の固定文言部分はまあ文字種区別しない検索でも文字種区別で統一してもいいかな、というところ。

今回の対応範囲、一応テストは通っていますが、今は中途半端な状態なので、本番リリースはもうちょっと先になります。

アンパンマンDB

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

来週の放送情報。
再放送ですね。

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

正規化と言いつつ正規化じゃないところ、本当に正規化と言える部分と冪等じゃないエスケープ処理に分割。
このあたり、既存処理の拡張で作るつもりでいましたが、そもそもの実装がまずい部分があったので、新規処理として作成中です。
少しずつ修正して少しずつリリースしていくと、新旧入り混じる期間が出るので、新仕様で旧処理を壊さないためでもあります。

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

正規化が正しく正規化である限りは、正規化したデータを正規化しても正規の状態を保つ、冪等性があるので、元の正規化処理を残したまま、後続処理における「本当に必要だった正規化」を作っています。
受け取った瞬間以降すべての精査、やっぱりやっちまうほうが正攻法だよなってことで。
検索機能に対しては自動テストも組んであるので、ある程度は修正が必要なところも検出できます。

アンパンマンDB

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

「かがやけ太陽!」「氷のせかい」「クレープマン」「すなぼうや」「ガレットさん」「ベビーアンパンマン」「ベビーロールパンナ」「チャポン」「ヒーロー!」を追加しました。
ええ、はい。去年の映画以降、更新し忘れていた分も含めての更新です。
2024年初登場の面々が入っていなかったのは更新忘れ期間だったから仕方ないとして、2013年のクレープマンを忘れていたのは痛恨の極み!
もしかしたら他にも入れ忘れあるかもしれないし、どうにか入れ忘れ検出システム作れないかな。

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

文字種保持検索(ほぼばいきんまんとバイキンマンの区別専用)の実装に取り掛かりました。
…が、あまりに大変すぎたので、いったん白紙に戻しました。
検索クエリを受け取った瞬間にはもう正規化をしていて、正規化された文字種が来ることを想定してその先のすべての処理は作られているんですよね。
この「受け取った瞬間」の正規化をやめて必要に応じて…と考えていたら、受け取った瞬間以降すべての精査が必要になってしまったということです。
ばいきんまんとバイキンマンの区別だけならもうちょっとシンプルにできそうな気もするので、もうちょっとやり方考えてみようと思います。

<前 次>