外側の消えない余白もだけど、内側のアイコンとテキストの余白も気になったので、こっちを先に対応。
画像ではわかりやすくするため極端な余白にしたけど、目的はあくまで自然な余白を作るためです。
Anpanatorの自動テストを作っていて、その内部エンジンにして本体であるMifuminatorに、PHP8.4での問題が発見されたので、修正予定。
例外クラスのコンストラクタの書き方がダメっぽいです。
そもそもコンストラクタを書く必要がない説もある。
デバッガーで追跡したら案外あっけなくケリが付きました。
昨日言ってたCloseする対応。
HideをCloseに変えて、元のHide/Close時にやってた処理をApp(タスクボタン管理側)に移動したのが中心。
もっと全体的にApp側に寄せるのも考えたけど、ひとまずはこれで。
で、昨日言ってた問題への対処がこれ。
ディスプレイケーブルを抜くなどしてディスプレイの状態が変わるとwindow.Screens.ScreenFromPointがなぜか値を返さなくなってしまうようだったので、値が返ってこなかった場合のフォールバックを入れています。window.Screens.Allならそういった厳しい環境でも値を返してくれていたので、そっちから自力で該当スクリーンを特定するという流れです。
ログイン機能、動作確認したら意外と…というか、全然うまく動いてなかったのでまあまあしっかりめに修正しました。
とりあえず、開発環境ではログインに成功。
ただ、ログイン・ログアウトはできるようになったけど、ログイン中に何か特別なことができるわけでもないので、今はまだ意味がありません。
ひとまずは、メール通知登録をログイン中にはメールアドレス記入なしでできるようにしたいね。
動画投稿しました。
#106 古い情報対策と表示リセットの件、両方一挙に解決する方法として、MainWindow(一覧画面)を消すときにHide(非表示)ではなくClose(完全に閉じる)をして、毎回0から画面を作り直すのを試してみました。
そうしたら、なんか予想外すぎるバグが出てしまったので、今回はちょっとコミットしてません。
なんか、いつの間にか表示位置がずれるようになるんですよね…。
まさかそんなバグり方するとは思っておらず、いきなりリリースビルドで試したので、今度はちゃんとデバッグモードで再現を試みよう。
行が広すぎる問題、対応しました。
オプションの受け渡し受け渡しで変更ファイル多くなっちゃったね。
ただ、余白0にしてもまだ余白がある模様。
リストボックス側に固定のパディングがあるパターンか？
ついでにこの課題も対応しようと思ったけど、コメント見ればわかるとおり、試行錯誤した結果、錯誤の結果しか残せませんでした。
なんか、どうあっても表示中の状態でしか表示の変化が起こらないようなんですよね。
表示リセットの課題ともども、根本的にやり方変えなきゃいけない気がします。
もう発売後半年たったし、重大なネタバレとグロ以外は畳まずに書いていくよー。
隔離病棟に入ったら何事もなくリストタグLv.3ゲット！
病棟内のファイルから、あの強い変異体の名前はブリスターヘッドと判明。
ブリスター（Blister）は水ぶくれという意味。
あのぶくぶくの見た目通りってわけですね。
こいつへの変異を防ぐには破血アンプルが必要とのこと。
リメイク1の火葬みたいなものかな。
そしていよいよ、白い少女エミリーとも直接対面。
目が見えないからこそ読めるものを読んでもらうために、隔離病棟に連れていく必要が出てきました。
他の写真は以下から。強敵警戒しまくった割りに全然出てこなかったから今回はグロ画像なし。
バイオハザード レクイエム(2026/08/31)の画面写真集
バイキンメカ情報追加。
昨日の件へのデータ側からの対応として、リンクがない項目の記事化を進めていて、その中で実は記事が既にあるけど名前が違っていてリンクされていなかった項目がこれ。
他の完全新規になる記事は、数が多いのと、あくまでリンク用でほとんど中身がないので、ひっそりこっそり更新です。
管理メモの未記入スタッフ、大幅に機能拡張しました。
もともとリンクがない項目を見つけ出すためのページだったのですが、どこに記入された項目なのか、いくつ記入されているのかがわかるようになり、記入の優先順位をつけやすくなりました。
とりあえず、統計用のリクエストは問題なく記録されている模様。
AIとも検索ともつかないよくわからないロボットが徘徊しているけど、統計への影響はないし、Metaみたいに狂った大暴れをしないのでひとまずは放置。
そろそろちゃんと記事の更新をして、統計をする意味がある状態を作っていきたいなァ。
なんかまたおかしなのが増えてきている模様。
本当はユーザー側で自主的にどうにかしてほしいけど、なんかまた対策考えるかなぁ。
来週の放送情報。
そうめん…残暑だからまだ季節か。
Bot対策しつつアクセスログから人気のページを集計するための仕組み、作ってみました。
mw.hook('wikipage.content').add(function () {
const id = mw.config.get('wgArticleId');
if (id === 0) {
return;
}
const d = new Date().getTime();
setTimeout(async () => {
try {
const url = '/a.md?' + id + '-' + d + '-' + (new Date().getTime());
await fetch(url, { method: 'HEAD' });
} catch (error) {
}
}, 5000);
});グローバルスクリプトのMediaWiki:Common.jsに処理を書くことで対応しています。
このスクリプトでやるのは、集計に使えるリクエストをサーバーに送ってアクセスログに残させるところまでです。
実際の集計は、後日、これとは別に作ります。
まず前提として、ここではJavaScriptを使って行います。
私の個人的なこだわりとして、JavaScriptを使わずに済むなら使わずに済ませたいのですが、MediaWikiの時点でJavaScript使いまくっているので、相対的にデメリットは少ないかなと。
そして、Botはページ本文だけ見に来て、JavaScriptの実行まではしないことがほとんどですからね。
mw.hook('wikipage.content')は、コンテンツロード後に関数が発動するする仕組みです。
で、最初にページIDを取って、有効なページのときだけ処理を進めるようにしています。
特別ページなど、記事じゃないページを集計しても仕方ないですからね。
ちなみに、このMediaWiki:Common.jsのページも記事IDを持つ立派な記事なので、みんながこのスクリプトを見に行くと、スクリプトが人気ページになります。
まあ、これは今後実際に集計する仕組みを作るときに除外すればいいだけの話かな。
処理が進んだら、時刻を記録してタイムアウトを仕込んで、サーバーにリクエストを送ります。
このときのリクエスト先URLは、できるだけ短い名前にした静的ファイルのa.mdに、パラメータでページIDとタイムアウト前後の時間を加えています。
URLに時刻を含めることで、リクエストせずキャッシュからレスポンスが返るのを防ぎつつ、URLと実際のリクエスト時刻を照合してリクエストの整合性を検証できるようにしています。
タイムアウト仕込む前とタイムアウト後の時刻両方を含むので、ちゃんと待ったかどうかの検証もできます。
Botが昔見つけたURLをもう一度叩いても期限切れなので意味がないというわけですね。
もちろん、人間のアクセスでも、ちゃんと読まずに一瞬で通り過ぎた場合は集計対象になりません。
なお、ただのタイムスタンプなので明確な悪意があれば偽装は容易ですが、そんなことする意味もないので、偽装するやつはいないという想定です。
ちなみに、わざわざ有効な静的ファイルを用意しているのは、MediaWikiの手を煩わせないためです。
静的ファイルがあればそれを直接読むように設定してあります。
もしファイルを置かなければ、MediaWikiに処理が渡り、a.mdというありもしない記事を探した挙句、本来必要のないエラーログを残して404エラーを出すことでしょう。
そうさせないための、静的ファイルです。
そして、サーバーへリクエストを送る際は、HEADメソッドで送ります。
目的はあくまでも「リクエストを送ること」までなので、レスポンスは要らないし、ましてやリクエスト先のコンテンツなんかも全く必要ありません。
なので、コンテンツを返さないHEADメソッドが無駄がなくてよいということになります。
厳密に言うと、レスポンスヘッダは返ってきますが、不要なので受け取らずに捨てています。
Botはむしろリクエスト先の中身が欲しいので、GETメソッドでリクエストするでしょうが、HEADメソッドではないので集計対象にはしませんし、もちろんリクエスト先のa.mdの中身は無意味なものしか入っていません。
一応、a.mdの中身は下記リンクから見えるようにしておきますが、本当に意味のないことしか書いていませんし、これを読んだところで人気ページ集計には寄与しません。
a.md
というわけで、まとめると、こうなります。
なんかPCが一挙手一投足ごとにタスク切り替えだのゲーム起動画面だのが出てきておかしいなと思ったら、ゲームコントローラが誤作動していました。
USBケーブル差しなおしたら改善したので、どうやら繋ぎっぱなしだったケーブルが外れかけて接触不良を起こしていたようです。