「アイディア」に関する日記(2)

日記の記事内のカテゴリの表記を改める予定です。
「[カテゴリ]」みたいにしていたのを「#カテゴリ」にします。
様々な分野でハッシュタグと言うものが浸透してきて通じやすくなったのと、[]表記を別の用途で使いたくて、区別がつくようにと言う目的です。

ドラゴンクエスト10

ゲーム内資産5000万ゴールド突破。
レンダーヒルズまで折り返し地点です。
まあ、真面目に金策やっている人なら結構すぐ貯めちゃうらしいですが。

アンパンマンDB

Twitterのハッシュタグのページを更新
いよいよ映画公開が明日に迫ったということで、「#映画33作目も公開だし好きなアンパンマン映画を3つあげる」追加です。

キャラ「カマンベールくん」を追加
やっとカマンベール回見たので。

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

「逆引き編集」というアイディア。
現状は、記事を選んでから、タグが当てはまるかどうかを次々投票する仕組みですが、それとは逆に、最初に一つのタグを指定して、それに当てはまる記事・当てはまらない記事を次々選んでいくという考え方です。
具体例で言うと、「女」というタグを選んで、こいつは女だから「+」、こいつは男だから「-」と次々入れていく感じです。
検索に役立てるには、一人のデータが充実するより、みんなのデータが少しずつ出そろった方がいいですからね。

アンパンマンDB

未実装のアイディア。
「ヤーダ姫」とか、「かつぶしまんと鉄火のマキちゃん」とか、タイトルだけで区別のつかない記事がいくつかあります。
そういうのに区別をつけるために、今は「ヤーダ国のヤーダ姫」みたいな説明的な名前を、「他の呼び方」に入れて対応しています。
こういう説明的なタイトルの、タイトルそのものじゃない補助的なテキストを、独立項目として作ろうかと考えています。
ヤーダ姫の例で言えば、「ヤーダ国の」や「ヤーダ星の」などを入れる形です。

NeoMupl

ファイルの場所を開く機能 · Issue #29 · mifumi323/NeoMupl
これまた未実装のアイディア。
ショートカットファイルを右クリックしたら出てくるメニューの項目みたいなやつです。
浮き沈みランチャーには同じような機能を実装しているので、そんな感じで。

更新履歴

先月やっていた根本的な作り直しの続き。
履歴項目の読み込みを作っている最中なのです。

PHP(Today I Learned)

で、そのときに、データベースから読み込んだ結果をPHPのクラスに変換する処理で、callableを渡す新しい書式。

PHP: 第一級callableを生成する記法 - Manual

PHP8.1から出てきた記法で、従来は「['NoteItem', 'fromArray']」と、文字列の配列で記述するしかなかったのですが、「NoteItem::fromArray(...)」という書き方で同じ意味を表現できるようになったのです。
文字列だと、プログラム的に意味があるのか単なるテキストなのか文法的には区別がつきませんが、「(...)」を使った記法だと、明確にプログラム的に意味のあるcallableとして書けるのです。
ただ…見た目気持ち悪いですね…慣れるしかないか。

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

構想段階で全く着手していないアイディアなんですが、「共起度」というもの。
このタグとこのタグは一緒にいることが多いなってやつ。
これの統計を取っておいて、みんなのタグの編集画面での並び替えに活かしたいなと。
例えば、すでに「姫」のタグが付いていた場合、共起することが多い「女」を上の方に表示するとか。
「共起度」というのはわかりにくいから、「関連度」とかの用語にした方がいいかもしれないですね。

Flaky test対策

新VPSに移行してからはなぜか落ち着いているんですが、不安定なテストの対策。
ネットワーク関係など、プログラムが正しくても失敗してしまうテストがあります。
プログラムが正しいならそんなもの無視すればいいんですが、Flaky testだと思っていたものが実はプログラムミスだったということもざらにあるので、ネットワーク関係だからエラー無視、というわけにもいきません。
今のところ、毎回エラーの詳細を出力して、目視確認して、「これは今回だけの偶然だな」とか判断しているのですが、頻度が高いと面倒だし、精神衛生上もよくありません。
で、なんとかFlaky testを自動検出して、あるいはそうでなくとも、FlakyとわかっているテストはFlakyなりの判断基準を持たせて、ただFlakyなだけなら一応テスト成功として扱いたいなと。
実現するには、過去数回のテスト結果を保存しておいて、一定割合までの失敗なら許容する、くらいの扱いが現実的かと考えています。

参考：世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（後編）。DevOps Days Tokyo 2022 － Publickey

キャラ倉庫

Bomber丸Worldの当初のストーリー予定 – 美文のキャラ倉庫
古い資料が発掘されたのでキャラ倉庫更新。
これに適当にサブイベント生やしていったらあの途方もないキャラ数になったんですよね。
正直、ゲームとして完成させるにはあのストーリーは何かしら変更する必要があるんじゃないかと思っています。

アンパンマンDB

「ドロリンとバケ〜るカーニバル（劇場版ベストCD）」の商品情報を更新
映画サントラの正式な曲目が出ていたので更新しました。
テーマ曲の『おばけなんてないさ』はおそらく新録じゃないだろうと思っています。
ジャケット裏見られれば著作権表記で確実にわかるんですがね。

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

通報機能の前段階として、絞り込み機能を作っています。
一度通報されて不適切扱いされたタグも、実はいたずら通報で闇に葬られそうになっただけ、という可能性はあるわけで、基本的に不適切タグは表に出さないけど、望むなら深淵まで光を当てる選択肢は提供しておきたいなと。
ただ、根本的にタグ自体が多いので、まずは通報とは関係なく、単なるテキスト検索としての絞り込みを作っています。
ここで一度仕組みを作ってしまえば、いろいろある絞り込みのルールの中で、「不適切なタグ以外」という条件を作ってやれば、無理なく通報結果を反映できるわけなのです。
通報からどのように不適切なタグを判断するのか、という点についてはまだ結論出せてませんがね。

日記

うちのサイトは、ほぼ毎日何かしら更新しているわけです。
「更新」カテゴリいらないんじゃないかなって思えてきました。
特に、今日の日記の上の方みたいに、CMSによる更新も日記に書くようにしたら、収拾がつかなくなってきました。

それとは別に、「アイディア」カテゴリから実現済みと放棄したアイディアを分離しようかなとも考えています。
一度アイディアとして出しておいて、終わったものは「アイディア」とは違うカテゴリに入れて、「アイディア」カテゴリをこれからやる可能性があるアイディアだけに絞るということです。
日記を後から修正すること前提のカテゴリにするわけですね。

みんなのタグは、ユーザーが勝手に追加できるので、変なタグも当然追加される可能性があるわけですが、結構数が増えてきたので、そろそろ対策が必要な時のようです。
ひとまずは、通報機能を作る方向で考えていますが、通報結果を管理人が精査して削除だと結局管理人に頼るシステムになってしまってコンセプトに反するし、管理しきれなければそこで通報機能も機能停止するわけです。
そうなると、通報も多数決の原理にするべきかと思うのですが、じゃあ通報の乱用を抑止する対立票はどうするの？って話で。
現状の投票の統計から不適切そうなタグの傾向を観察して、適切な通報がある程度溜まれば不適切なタグは排斥され、不適切な通報が多少あっても適切なタグは守られる、そんないい塩梅のやり方を探っていくところから始める必要がありそうです。
通報データをある程度溜める必要があることは確実そうなので、通報データを蓄積するためだけの画面は先に作ってしまってもいいかもしれません。

おきがえリポちゃん　～ カントリードレスセット ～ （2022/5/23）｜目覚めし冒険者の広場
毎月のやつ。
ついてクンとのお散歩も楽しいかもねって言われたのでこの衣装の雰囲気と合いそうなメルサンディ穀倉帯でついてクン出してお散歩的な写真を撮ろうとしたのですが、このアングルでちゃんとついてクンが付いてきてお散歩的な穏やかな歩き方して写真撮るの、地味に難しかったですね。
カメラは真ん前か真後ろに回り込もうとするし、ついてクンは付いてこないし、コントローラを慎重に調整しないと歩かずに走り出すし…まあ歩くのだけはキーボード操作では簡単にできるんですけどね。

なんかさ、ジブリのあの映画の歌が聞こえてきそうな感じの写真にしたかったんですよ。
写真コンテストとかで凝った写真撮ってる人、どれほどの苦労をしているんでしょうね。

残り二人は諦めて何のこだわりもない写真を撮りました。
以下のリンクからどうぞ。
写真置き場「2022-05-25」

おきがえリポちゃんの日記も結構溜まってきたし、ドラクエ10のおしゃれ着の変遷をコメント付きの写真で一望できるように、日記のカテゴリ作ってもいいかもなァ。

mifumitter

「-is:retweet」は、このフレーズ以外全部を括弧でくくったら効きました。
多分、「filter:retweet」あたりも仕様が変わってるんじゃないかと思うので、ちょっと確認しようと思います。

キャラカード

今mifumitterを開発していることからもわかるように、2年ほど前に考えたキャラカード、全く開発は進んでいません。
CharaBoxからオンラインのどこかに自作キャラのデータを移行したくて、うちのこまとめはどうかなって思ったけど、私の望むものとは違っていて、それで自作しようかと考えたのですが、この体たらくです。
いずれキャラカードができることがあれば移行することを前提に、もっと他のオンラインシステムを使えないかなと模索中です。
とりあえず、Wikipediaという偉大な実用例があるMediaWikiを試してみるのもいいかなとか思っています。
まあ、WikiはWikiでBomber丸WorldのときにPukiWiki使って放置されましたが…。

星のカービィディスカバリー

ワンダリア跡地のびっくりホラーハウスまでクリア。

久々の一発コンプリートだったのです。

スターアライズに引き続きポピーブラザーズジュニアかわいいしたくて不殺で進んでいたら、ボムトレジャーで詰みました。
ファイアトレジャーはタイムを犠牲にすれば横道から迂回できたのですが、ボムは高度を稼ぐ必要があったので無理でした。
スターアライズのときはこだわらずに倒しながら進んでたし、今回もこだわり捨てるべきか…？
レアストーンは全部クリアしなくても足りそうな気はするけど、100%クリアにはトレジャーもクリアしておく必要はありそうだし…。

アンパンマンワンドロ

一度出たお題のお休み期間を約1年に延長したのですが、それでも繰り返し出ているような印象を受けてしまうことがあるようです。
実際にはお休み期間はしっかり開けているのですが、幼少期を過ぎてアンパンマンを好きな人は結構長期的に愛し続ける傾向があるようで、数年程度では記憶に新しいことが珍しくないようです。
1年以上開けているとはいえ、繰り返し出ること自体は事実なので、いっそのこと何年ぶり何回目の出題ってことも表記しちゃった方がいいのかなとか考えています。
それができるような履歴をしっかり残しているわけですし。

最近はシステムの実装の方に注力していてデータの記入が滞っているわけですが、今後のデータ記入の方針について。
全部わかってから全部埋めるように書こうとすると、どうしても時間がかかってしまうわけです。
情報提供の扱いについても、反映や却下で扱いが決まったものもあれば、判断保留で後回しにしたものもあるわけです。
だから、ある程度、書きかけのまま保存して公開する必要があるのです。
で、書きかけを書きかけのまま放置しないために、「何がまだ終わっていないか」というのを、今後書いていくことにしました。
こうすれば、私が後で見返して、何を確認すればいいかわかるし、情報提供者も何が求められているわかるというわけです。
今日更新したいくつかの記事にて、「調査中事項」という形で記載しています。

うちのサーバーもすでにPHP8に対応しているのですが、サーバーは対応していてもプログラムが正常に動かなかったため、移行できていませんでした。
そろそろどうにかしたいので、デバッグ可能な検証環境を用意したいなと考えています。
当初、Dockerがちょうどいいかなと思っていたのですが、PHPだけでなく、サーバーやドメインも関わってくるので、仮想マシンまるごと用意した方がいいのではないかと考えています。

ドラゴンクエスト10

おきがえリポちゃん　～ ポップスターセット ～（2021/8/25 更新）｜目覚めし冒険者の広場
いつもの貸衣装。
いかにも女子向けって感じの衣装だったのでうちの女の子キャラにも似合うかなと思ったのですが、しろいコキンは耳から髪が生えちゃうし、ァォィョッュは地毛の中にウィッグが埋もれるしで、意外と散々な結果でした。
ミフミンは男だけどむしろ何もないので、かえって着こなしている印象さえあります。

はてなブログ

はてなブログ個人営利利用ガイドライン（2019年10月1日施行） - はてなブログ ヘルプ #日本音楽著作権協会（JASRAC）の管理楽曲の掲載について
はてなブログはJASRAC包括契約の関係で歌詞を掲載できる…？
ただ、非営利目的に限られるので、アフィリエイトを置くことはできない、ということですね。
過去にJASRACに直接問い合わせて、アンパンマンDBにおいては、「歌詞を掲載することも、検索できるようにデータを置いておくこともできない」ということを確認していました。
しかし、アンパンマンDBではなく、はてなブログなら、「歌詞を掲載して、検索できるように置いておくことができる」ということになるのです。
アンパンマンソング専用ブログを作るというのも一つの案としてありかな…。

ちなみに、同様な状況のブログサービスはほかにもあって、JASRAC公式サイトの以下のページにまとめられています。
利用許諾契約を締結しているUGCサービスの一覧

アンパンマンDBのコメントや掲示板の記事などのユーザー生成コンテンツ(UGC)に関して。
この取り扱いについて、権利的なことはこれまで何も定めていなかったのですが、Anpanatorとか、みんなのタグとか、ユーザーの投稿なくしては成り立たないコンテンツも出てきたので、ルールをはっきりさせた方がいいかなと思い始めました。
以下のサイトが参考になりそうな感じ。
ウェブサービスにおけるUGCの著作権処理について : 企業法務について

昔ウディタを検討しているみたいなこと書いたことあるんですが、ウディタはWeb向けの出力がないんですよね。
RPGツクールだとその辺強いので、こっちを検討してもいいのかなって思っています。
体験版とかあったかな…。

実は、と言うほどでもないんですが、プレイしているだけでゲーム記にページ作ってないゲームっていっぱいあるんですよね。
全部作ってるときりがないんですけど、画面写真を撮っているものぐらいは作ってもいいんじゃないかなとか思っています。

システム化を前提に実装案。
キャラ一人当たり、識別名とメイン画像が各々ひとつずつ、キャラカードが0以上複数。
キャラカードひとつ当たり、省略可能な表示名(省略時識別名)、省略可能な表示画像(省略時メイン画像)、紹介文が、各々ひとつ。
キャラカードの画像はJavaScriptで生成、編集中はリアルタイムに反映。
設定資料を兼ねるなら、カードとは別に説明文も付けた方がいいかも。

ふにゃとかギヤバネとか、うちのキャラクターを紹介するのに、Wikiとかうちのこまとめとか、使ってたんですが、どうにも紹介のためには大げさかなという気持ちがあるんですよね。
もっと気軽に、一言紹介をたくさんのキャラに少しずつ書けるのがいいなって思うのです。
ということで、キャラクターの名前と、アイコン程度の画像と、ちょっとした説明を一定のフォーマットで書いて、カードみたいにしてみたらどうだろうかと考えてみました。
具体的な実現方法はまだ何も考えていませんが、たくさん作る想定なので、システム化するか、最悪でもテンプレートを用意するぐらいはしたいところです。

ちょっと2点ほど考えていることがあるのです。

一つは、キャラDBとモノDBの統合。
ロボット系に特に顕著なんですが、キャラと呼べるかどうかの境界線があいまいだったり、声優や登場話などキャラと共通する項目が結構多かったりするのです。
言ってみれば、作中に物理的実体として存在するという意味では同等なのです。
一応、私の中でのキャラクターとそれ以外の区別はあって、自我があるかないかで分けているのですが、しゃべらないキャラクター、しゃべるロボットなど、モノの性質に片足突っ込んだキャラクター、キャラクターの性質に片足突っ込んだモノなど、区別はあってもやはり両者は混ざり合うのです。

もう一つが、ユーザーコンテンツ。
今あるのはコメントと、個人メモ(プレビュー版)の2つですが、ここにみんなのタグを加えて、アンパンマンDBに検索可能な形で集合知を取り入れようかと。
みんなのタグに関しては、ずっとアンパンマンDBでやるか別サイトとして独立させるかで迷っていたのですが、タグをつける対象となる「記事」の管理が二重管理となるのが今の管理体制から考えて無謀だと思ったので、アンパンマンDBと一緒に管理しようと思っています。
で、ユーザー中心のコンテンツの比重が増えてくるなら、記事のおまけみたいな扱いでなく、専用のまとまったスペースも必要かなと感じています。
そのまとまったスペースが、ユーザーコンテンツってわけです。

まだ構想だけで現実的ではない状態ですが、アンパンマンDB4の開発と一緒に進められたらと考えています。

データベース関連を一手に担うADB_DBクラスでは、記事一つを取得するために必要な、検索・取得・変換を、クラス一つで全て担っていた。
検索：どの記事を見せるかを決める
取得：何を見せるかを決める
変換：どう見せるかを決める
これらは、それぞれがそれなりに複雑な処理であり、ADB_DBクラスが肥大化・複雑化して手に負えなくなる原因となっていた。
次期バージョンでは、これらをうまく分けて、理にかなった設計にしていきたい。

日記に書く内容って毎回思いつかないんだけど、よく考えたらTwitterでほぼ毎日何かしらつぶやいているし、Qiitaや外部サイト等に投稿をすることもあるし、そういうのへのリンクをどんどん羅列していったらいいんじゃないかとか思い始めている。