古いVPS解約した。 pic.twitter.com/0AdK2zuCiN
— 📛松田美文 (@matsuda323) June 18, 2022
去年言っていたことですが、どうやら無理そうでした。
はてなブログにはJASRAC管轄曲の歌詞を掲載できるので、アンパンマンソングの歌詞を集めたサイトを作れるんじゃないかと思ったのですが、歌詞掲載を主体とした利用は明示的に禁止されていました。
はてなブログにJASRAC管理楽曲の歌詞の掲載が可能になりました - はてなブログ開発ブログ
タスクリストについて - GitHub Docs
GitHubのタスクリストをコミットメッセージで操作できないかと調べてみたのですが、どうにもできなさそうですね。
まあ、できたとして、番号も振られていないチェック項目をどうやってコミットメッセージで特定するんだって話ですが。
「ふわふわフワリーと雲の国」の作品情報を更新
昨年の劇場版テレビ放送後半の情報を入れました。
そして来週は今年の劇場版も封切りですね。
現在の更新履歴からデータを取ってきてデータベースに入れるための仕組みを作成開始。
チャンネルの仕組みがまだできていないので、完全移行はまだ無理ですが、どこまで本当に移行できるか確かめながら開発していけるようになる…といいなあ。
根本的な作り直しの続き。
履歴項目の書き込みが出来ました。
履歴項目本体以外にも、チャンネル(何についての更新か)も作る必要があります。
未実装のアイディア。
「ヤーダ姫」とか、「かつぶしまんと鉄火のマキちゃん」とか、タイトルだけで区別のつかない記事がいくつかあります。
そういうのに区別をつけるために、今は「ヤーダ国のヤーダ姫」みたいな説明的な名前を、「他の呼び方」に入れて対応しています。
こういう説明的なタイトルの、タイトルそのものじゃない補助的なテキストを、独立項目として作ろうかと考えています。
ヤーダ姫の例で言えば、「ヤーダ国の」や「ヤーダ星の」などを入れる形です。
ファイルの場所を開く機能 · Issue #29 · mifumi323/NeoMupl
これまた未実装のアイディア。
ショートカットファイルを右クリックしたら出てくるメニューの項目みたいなやつです。
浮き沈みランチャーには同じような機能を実装しているので、そんな感じで。
先月やっていた根本的な作り直しの続き。
履歴項目の読み込みを作っている最中なのです。
で、そのときに、データベースから読み込んだ結果をPHPのクラスに変換する処理で、callableを渡す新しい書式。
PHP: 第一級callableを生成する記法 - Manual
PHP8.1から出てきた記法で、従来は「['NoteItem', 'fromArray']」と、文字列の配列で記述するしかなかったのですが、「NoteItem::fromArray(...)」という書き方で同じ意味を表現できるようになったのです。
文字列だと、プログラム的に意味があるのか単なるテキストなのか文法的には区別がつきませんが、「(...)」を使った記法だと、明確にプログラム的に意味のあるcallableとして書けるのです。
ただ…見た目気持ち悪いですね…慣れるしかないか。
内部処理をいじって、カテゴリの処理を切り分けました。
内部的に使ってるけど日記では何の意味もないシステムを削除したくて、でも結構影響範囲が大きくて、なので、影響範囲を狭めつつ、リグレッションテスト可能なように作り替えているということなのです。
ついでにテストのカバレッジも上がるので、精神衛生的にもよくなります。
なお、外部仕様を1ミリも変えない内部仕様の変更なので、これが成功した暁にも読者にとっては特に意味はありません。
コーディングは1行も進んでいません。
タイルの当たり判定をしっかりやろうとすると、様々なテストパターンが必要なわけで、抜け漏れないか確かめるなら、グラフィカルに表示できた方がわかりやすいし、何より楽しい！
というわけで、タイルと当たり判定図形(線)を描画して当たった位置をリアルタイムに表示できるものを作りたいなというところ。
構想段階で全く着手していないアイディアなんですが、「共起度」というもの。
このタグとこのタグは一緒にいることが多いなってやつ。
これの統計を取っておいて、みんなのタグの編集画面での並び替えに活かしたいなと。
例えば、すでに「姫」のタグが付いていた場合、共起することが多い「女」を上の方に表示するとか。
「共起度」というのはわかりにくいから、「関連度」とかの用語にした方がいいかもしれないですね。
新VPSに移行してからはなぜか落ち着いているんですが、不安定なテストの対策。
ネットワーク関係など、プログラムが正しくても失敗してしまうテストがあります。
プログラムが正しいならそんなもの無視すればいいんですが、Flaky testだと思っていたものが実はプログラムミスだったということもざらにあるので、ネットワーク関係だからエラー無視、というわけにもいきません。
今のところ、毎回エラーの詳細を出力して、目視確認して、「これは今回だけの偶然だな」とか判断しているのですが、頻度が高いと面倒だし、精神衛生上もよくありません。
で、なんとかFlaky testを自動検出して、あるいはそうでなくとも、FlakyとわかっているテストはFlakyなりの判断基準を持たせて、ただFlakyなだけなら一応テスト成功として扱いたいなと。
実現するには、過去数回のテスト結果を保存しておいて、一定割合までの失敗なら許容する、くらいの扱いが現実的かと考えています。
パソコンのメモリを換装して、12GB→16GBに増やしました。
足りなくて困っていたというわけでもないんですが、開発環境のメモリが多いに越したことはないのです。
忘れないうちにさっさと移転完了しました。
リバースプロキシの設定移行だけちょっと大変だったかも。
自作のサーバー(サーバーそのものとして機能するプログラム)もあって、そいつを保護するために表向きIISがいないといけないのです。
あと、ハードウェアスペックは変わってないですが、お値段は安くなりました。