全記事インデックス

we’ll always be connected through music♪ というメッセージが私にとても響きました🥲

少し前にFinanaのチャンネルでルンルンが登場したのは、何かの収録なんだろうなと思ったけど、やっぱりこのためだったか。でも、戌亥と鏡音レンの登場は全然予想外だったぞ。今までで一番豪華な周年企画だった。

最近、自分が昔書いたあることについて調べたくてエゴサみたいなことをしていたんだけど、検索に全く引っかからない。何回かキーワードを工夫したら、過去の記事インデックスページだけ何とか引っかかった。しかし、インデックスページは1ページに10本程度リストしたもので、新しい記事が追加されるごとに古い記事が後ろへずれていく仕様なので、検索エンジンのクロールが遅いと、現在そのページを開いても目当ての内容はもう載っていない。

私は自分のサイトをより多くの人に読んでもらいたいとは思っていないけど、検索エンジンに全く引っかからないというのは、これはこれで困る。ただ日記として記録を残すというのはブログの一つの目的ではあるが、少人数でいいから、知を公衆と共有したいという思いもある。すると、そのおまけに承認欲求も少し満たされ、少し安心するわけ。

そこで私のサイトは何が足りていないのか調べたところ、メタデータ（Googleが言う「構造化データ」）のマークアップが足りていないということに気付いた。

https://mingeiinter.net/から、Hugoで作っている他の方のブログを見たところ、実装はかなりまちまちだな。headにJSON-LD形式で概要だけ記述しているものから、全く実装していないものもある。私がフォローする方のブログでは、headの中にDublin CoreとOpen Graph、本文にMicrodataでメタデータを記述していることから、これを見本にすることとした。

私は趣味ブロガーだからこの辺をずいぶん長い間おざなりにしてきたが、アフィリエイターはこういう所までくまなくチェックするという涙ぐましい努力をしているんだろうな。

一口にメタデータと言っても色々あるが、今回は以下を追加した。

• itemscope
• itemid
• itemprop=“blogPost”
• itemprop=“articleBody”
• itemprop=“datePublished”
• itemprop=“mainEntityOfPage”
• itemprop=“keywords”
• itemprop=“thumbnailUrl”
• itemprop=“abstract”

これがちゃんと作用するかどうかは、やってみないと分からないけど。

参考文献

• 構造化マークアップとは？書き方まとめ by やっぷ - Zenn
• 構造化データ マークアップとは | Google 検索セントラル  |  Documentation  |  Google for Developers
• Getting Started - schema.org
• Blog - Schema.org Type

→ Fastest robot to solve a puzzle cube ⏱️ 0.103 seconds - YouTube

米国の大学生グループが達成。去年に三菱電機が0.3秒くらいの最速記録をとっていたと思うけど、それを上回る0.1秒。ほぼ一瞬だ。

いかに壊さず回すかが課題になりそう。ここまでいくつのキューブがお釈迦になったんだろう。

最近、腰痛が派生してみぞおちとか背中とか身体の節々が痛くなることがあって、今日は特にひどくて夜9時にベッドに入った。先月は腰痛が脚に転移して激痛が走ったのでクリニックで見てもらったら、脊柱管狭窄症になりかけていると言われ、湿布を貼りながらコルセットで姿勢を矯正した。3週間くらいでほぼ痛まなくなったので、そこから意識が緩んでいたかもしれない。

会社の健康診断では「全て晴れアイコン」で誰よりも健康体ということになっていたが、曇りが一つ付いている人よりも余程悪いかもしれない。通勤と会社で毎日2時間以上歩いているが、それだけじゃダメなんだろう。クリニックでもらったパンフレットを読みながら、体幹トレーニングとか筋トレしないといけないな。

CuteMouseのDOS/V対応版を作りました。

→ Releases · akmed772/ctmousev

CuteMouseはFreeDOSプロジェクトで開発されたオープンソースのマウスドライバーです。オリジナル版はDOS/Vの疑似的なテキスト画面モード (ビデオモード 03, 73h) に対応していないので、グラフィックモードでしかカーソルを表示できませんでした。この派生版はそれらのモードに対応しています。

DOS J5.0/V標準ドライバーのメモリー常駐サイズは15.2KBなのに対し、CuteMouseは3.9KBと軽量で、UMBメモリーに収まりやすくなっています。BIOSの使用やEGAサポートの削除、メモリー常駐域の最適化によってミニマムを実現しています。

しかし、今回の最大の利点はUSBマウスが使える事です。DOS/V標準のマウスドライバーはPS/2（ハードウェア）インターフェイスに依存しますが、CuteMouseはBIOSのINT 15hインターフェイスのみを使うので、BIOSさえUSBマウスに対応していれば、DOS/VでUSBマウスを使用することができます。もちろん古いPS/2マウスも使用できます。まあ、この「BIOSがUSBマウスに対応していること」という点がネックですが、Intel製やVIA製チップセット用のUSBドライバーが有志によって開発されているので、これと組み合わせることで、BIOSがUSBマウスに対応していなくてもDOS/V上でUSBマウスを使用できます。

IBM DOS J5.02/VのDOSSHELLとMicrosoft Works 2.5 日本語版、Visual C++ 1.51 日本語版のCodeViewで動作することを確認しています。その他の極東DOS/Vでも動くように作ったはずですが、動作確認までできていません。Windows 3.1のマウスドライバーはINT 33hを介さないため、CuteMouseを入れても特に効果はないどころか、DOSボックスと相性問題を起こす可能性があります。

前回の記事を書いた後、パーサーにデバッグモニターのコードを追加して調べたら、原因はすぐに分かった。パーサーのコード自体には問題はなく、取得したはずのDBCSベクターテーブルへのポインターが違うアドレスを指していたことが原因だった。

ドライバーのコード配置には常駐部と非常駐部があって、さらに、初回実行後に初期化される動的メモリー確保の部分もある。今回の場合、初回起動時にDBCSベクターテーブルへのポインターを変数に入れておいたはずが、常駐後におかしなことになっていたらしい。これは変数の確保場所を常駐部のコード内に変えることで解決した。

後は動作テストとドキュメントを少し書き直して、問題なければ明日にでも公開できそうだ。

西洋版MS-DOSマウスドライバーをDOS/Vへ移植しようとアセンブリプログラミングしていて、コア部分はほぼ完成しつつある。だけど、一つ重大なバグが残っていて、それがなかなか原因を探るのに苦労している。

それは文字がDBCS（2バイト文字セット、全角文字）かどうかを識別するパーサー。テキスト上でカーソルを反転させるとき、DBCSなら反転する範囲をSBCS（1バイト文字セット、半角文字）より2倍の幅にする必要がある。

シフトJISエンコーディングのテキストからある文字がSBCSかDBCSかを調べるには、文字の第1バイトが81-9FhまたはE0-FChの範囲内にあるかどうかを調べればいい。ところが、シフトJISにはDBCSの第2バイトにもこの範囲を含むという致命的な欠点がある。途中のとあるバイトが文字の第1バイトか第2バイトかを見分けるには、前の文字も調べる必要があり、最悪、テキストの先頭までさかのぼらなければならない。

例えば、DBCSは1字目がラテン文字で、2字目は数字またはラテン文字からなる、2文字で表現し、それ以外をSBCSと仮定する。123A1B1C1とあったとき、23だけを見れば3がSBCSであることは確定する。2がSBCSかどうかは前の文字を確認する必要があり、この場合は1なので、そこで初めて2がSBCSだと確定する。では、先からA1を抜き出した時はどうか。これだけ見ればDBCSなのだが、確定するには前の文字を見る必要がある。AA-1というDBCSとSBCSの組み合わせの可能性もあるからだ。今回の場合は3A1であり、3がSBCSだろうがDBCSの2字目だろうが、A1がDBCSであることに違いないので確定する。問題はABCDEA1と続いた場合だ。こうなるとA1のAがDBCSの第1バイトか第2バイトかを調べるには、先頭までさかのぼる必要がある。AB-CD-E[A]-1となるか、BC-DE-[A]1となるか、境界が分からないからだ。

こういう面倒な部分もあるが、単純に2バイトがDBCSかどうかを判断するプログラムはアセンブリコードでもそこまで複雑ではない。

; in: al = char, out: CF = 0 (SBCS), 1 (DBCS)
ischardbcs proc
    push    es
    push    di
    push    bx
    les     di,[dbcstblptr]    ;set ES:DI for DBCS lead-byte table
    cld
@@looknexttbl:
    mov     bx,es:[di]
    or      bh,bl
    jz      @@issbcs
    scasb   ;JPN: 81,9F,E0,FC,0,0h  KOR:81,BF,0,0h  CHT:81,FC,0,0h
    jb      @@issbcs
    scasb
    ja      @@looknexttbl
;@@isdbcs:
    stc
    jmp     @@endscan
@@issbcs:
    clc
@@endscan:
    pop     bx
    pop     di
    pop     es
    ret
ischardbcs endp

そのはずだが、問題はこのコードをドライバーに組み込んで実行したとき、エミュレーター(86Box)では期待通りの結果が出るのに対し、実機では違う結果が出ることだ。実機でドライバーコードをデバッグするのは結構手間がかかる。原因はまだ判明していない。範囲は絞られたので、もう少しで分かると良いのだが。現状は見当がつかない。