ゼルコバの木テント村

少しだけ歩行距離を伸ばした．スマホを持ち出していないので正確なところはわからないが，3000歩くらいは行ったのではないだろうか？桜も「ほころび始め」どころか，すでに「七分咲き」という感じになっている．「三本桜の実装」に移る前に，これまでの暫定修正をフィックスしておこう．だいぶペースが落ちているが，ぼちぼちと行くことにする．冬物のもこもこスリッパを履き捨てて（と言っても来年もまた履きますが…），夏物に変えた．（去年使っていた）ダイソーのスリッパは流石に作りが悪くあちこち縫い直した（一部はボンドで仮補修）．

一通りフィックス完了した．いよいよ三本桜の復活に進むという段だが，だいぶ離れていたのでカンが鈍くなっている．少しログを読み直しした方がよいと思う．この構想の発端は「ユニバーサルコードシステム」というアイディアがでてきた辺りと思われるので，2月下旬まで遡らなくてはならない．コラッツ木生成ツールの最終ビルド日付は2月26日になっている．マニュアルの更新日付を見てみよう．というか，その前にバックアップを整理して開発履歴が見えるようにしておく必要がある．今回導入した2TBのHDDはそのために購入したものだ．

コラッツプロジェクトには現在3つのバージョンがある．

1. CollatzComplete　最終ビルド：2022/02/26　V2.2.1
2. CollatzCoreTree　最終ビルド：2022/02/22
3. CollatzMilkyway　最終ビルド：2022/02/20

わたしの感覚ではCollatzCoreTreeの方が古いような気がするのだが，違うのだろうか？走らせてみればわかるだろう．CollatzComplete が一番新しいものであることは確かだ．V2.2.1でRel 22/02/26となっている．A面のオプションがFull regularとなっている．つまり，完全正則木を生成するというオプションだが，完全正則でない場合には何を出力するのだろう？⇒少し動かしてみればわかる．Full regularでない場合には3倍数は終端ノードになるが，Full regularの場合にはそうならない，つまり完全正則木が出力される．

CollatzCoreTree はV2.0.1でリリース日付は22/02/11，タイトルはCollatz  Milky Highwayとなっている．この版ではA面のオプションはCore treeとなっている．コラッツ中核木という意味だが…コラッツ中核木では無効ノードが発生しているので，完全正則ではない．1-3-4という設定でビルドしたとき，中核木では有効ノード数41となるのに，中核木オフの場合には46になる．どうも開発者本人すらどういう仕様になっているのかよくわかっていないようだ．

CollatzMilkyway バージョンもV2.0.1 Rel 22/02/11となっていて，CollatzCoreTree とまったく同じだ．ただし，A面のオプションはVirtual Treeとなっている．ただし，名前を付け替えただけで動作的にはまったく同じように見える．タイトルも同じCollatz  Milky Highwayだ．ただし，B面の枝番号数列はコンマ区切りで，CollatzCoreTree になるとそれがピリオド区切りに変化する．ピリオド区切りの方が新しいので，上記リストの順序は妥当なものだろう．

バックアップからマニュアルの原稿を探してみよう．マニュアルの最終版は2022/01/29のCollatzTreeGeneratorManual.pdfのようだ．ownCloudにアクセスしてPDFのバージョンをチェックしてみよう．

ED:1.02 Ver1.1.5 Rel 2022-01-19で確かにこれが最終版と思われる．マニュアルで参照している画像で判断すると，このマニュアルはCollatz Regular Tree Generator V1.1.3 Rel 2022/01/26ということになる．つまり，1月26日以降の修正はマニュアルには反映されていない．少なくともタイトルがCollatz Milky Highwayに変更されたあとの版はまったく未公開ということになる．状況はある程度つかめたような気はするが，ログの読み直しは1月下旬まで遡る必要がありそうだ．

2月17～19日に要対処項目125件というのを拾い出している．これも改めてチェックし直さなくてはならない…1月25日のログのタイトルは「マニュアルはほとんど仕上がった」だ．プログラムの公開版の日付が1月26日となっているので，このころにはプログラムはほとんど仕上がり，マニュアル編集に専念していたものと思われる．併せてかなり長時間のランニングテストを実行している．また，マニュアルの印刷というのも試している．処理速度を計測するためのベンチマークテスト，用語の統一というのも重要なポイントだ．

ZELファイルをダブルクリックで起動してエラーになるという案件がある．ちょっと寄り道になるが，確認しておこう．まず，アプリをインストールする必要がある．

▲最新版ではゼルコバの木フォーマットでエクスポートする機能を廃止して，一般的な隣接リスト出力をゼルコバの木でインポートするという仕様になっている．このとき，隣接リストにはノード番号が記録されているが，インポートした時点でこれを整数範囲内の参照番号に変換（ハッシュ化）している．今のところこれで問題は発生していないが，一般的な（順序不定の）隣接リストで正しく動作するかどうかを調べておく必要がある．

▲CollatzTree 3-5-94.zelのアイコンをダブルクリックしてオープンしたとき，「基準ノード不在」エラーが発生する．描画は可能だが，画面には図面の一部しか表示されていない．データはすべて読み込まれているようだが，再描画しても是正されず，ズーム倍率を変えたりしても一部が切れる現象は残る．⇒いや，倍率100%では完全に描画できた．横書き対応のクリッピングにまだなにか問題が残っているようだ．

最終公開版はV1.1.4 Rel 2022-01-27のようだ．このパッケージを確保しておく必要はある．

▲3倍数が終端ノードとなるコラッツ木で無効ノードカウントを事前に計算する計算式を立てる．（今回の修正が完了するころには容易に書き下ろせるようになっているだろう…）

今日の閲覧数が376という驚異的数字になっている．どうしたのだろう？通常，この数字は今日の訪問者数＋1～3程度のものだったのだが… つまり，ほとんどの訪問者は最初に開いたページから移動しないで離脱するというのがこれまでの常態だったのだが…

考えられる理由としては昨日の投稿のタイトルが「非公開投稿」とあったのをなにか勘違いして，どこかにトップシークレットが漏れているのではないかと思って探し回ったため，くらいのことしか思いつかない．

暖かくなってきたので，昨日からまたウォーキングを再開した．スマホは持ち出していないので歩数はカウントできていないが，かなり短い距離しか歩いていない．おそらく2000歩は超えていないのではないかと思う．去年の冬，ウォーキング休止になる前の歩数が5000歩くらいだったと思うので，その1/3くらいの距離だ．なんとかまだ歩けるだけでもうれしい．少し歩いていれば5000歩くらいまでには回復できると思う．

さて，そろそろクリップ領域の問題にケリを付けることにしよう．クリッピングでは，①現在のクリップ領域と描画の対象となる矩形領域の論理和を取って描画を実行し，②そのあと元の状態に戻すという操作を行っている．②の操作でRGN_COPYモードでSelectClipRgnを実行するとき，第一引数を空にしてやれば問題なく描画することができる．これで事実上描画できているし，それによる実害というのも特に考えられないので，とりあえずはこのままでもよいと思われるのだが，もう少し突っ込んでみたい．⇒問題は以下の3行だ．

SetClipRegion(pdc, crect, RGN_AND, &oldrect);　（１）
DrawNameText(pdc, Frame);
SetClipRegion(pdc, oldrect, RGN_COPY, NULL); 　（２）

しかし，このパターンはここにだけ現れるのではない．少なくとも以下の複数箇所で同じパターンが使われている．しかも，縦書きではこの論理で通っているのだから，その論理が横書きで通らないということは考えられない．というより，問題だ．

1. NAMEBOX::DrawName
2. Bobject::DrawTextBox
3. Bobject::DrawTextLine
4. NAMEBOX::DrawImage
5. PAGESETUP::PrintPage
6. TITLEBOX::Draw

（１）式ではクリップ領域を取り出し，（２）ではそれを書き戻している．（１）ではoldrectをGetClipBoxで取り出している．クリッピングの対象領域crectは論理座標単位で_CDC::LPtoDPで物理座標に直交変換している．この矩形領域をCreateRectRgnIndirectでクリップ領域に変換してCDC::SelectClipRgnが実行される．デバイスコンテキストが保持しているクリップ領域は物理単位でかつ直交変換されたものでなくてはならないと考えられる．（１）と（２）の内部処理は共通でいずれの場合もCDC::SelectClipRgnが呼び出される．

どうも解決したようだ！（１）で取り出したoldrectを直交変換して保持するように修正した．これでよいのではないかと思う．この動作から推定すると，GetClipBoxで取り出される矩形領域は（明示されていないが）論理座標系であると思われる．Bobject::SetClipRegionはBobject::setClipRegionのラッパになっているので，この部分は親のSetClipRegionで実行するように切り分けておくことにする．

これでようやく三本桜の実装に移ることができる．三本桜とはコラッツ木のバリエーションで，①一般コラッツ木，②仮想コラッツ木（長子木），③完全コラッツ木の3種を意味する．小学校の入学式の記念写真を満開の桜の木の下で撮影するというのは，わたしの母校に限らず日本中の小学校で行われていたようだが，年々桜の開花日は早くなっている．今日のコースには桜土手が一部含まれていたのですでにかなりほころび始めているのが確認されたが，桜が満開になるまでにこの改修を完了できるかどうかは確言できない…まぁ，やることは決まっているので，それほど手間取ることもないだろうとは思う…

非公開投稿というのが可能なものかどうかを確認してみよう．投稿カテゴリには「テント村」と「未分類」の2つがある．多分後者は非公開になるのではないかと思う．やってみよう．いや，どうも単純に公開されている．下書きとすれば非公開になる．投稿オプションには下書きとして投稿という選択肢がある．しかし，下書き投稿したものをブラウザで見るためにはログインすることが必要だ．それも結構面倒くさい．ログインして編集するのならそもそもOpen Live Writerを使う意味がない…

なぜこんなことを考えたかというという，進捗が止まって足踏みの状態が続いているため，思いのままに気楽にロギングするという感じがつかめないためだ．読者を意識しないで書くとすれば，非公開という方法しかない．これまではそういうことまでは考えたことがなかったが，思考力や根気の衰えというのは隠しようもない．もしかすると，ロギングに使っているノートを右手に配置するというのが効果があるかもしれない．これは最後の手段と思われるが，藁にもすがってみよう．

悪くないような感じはするが，それほど効果的であるような感じもしない…フルキーボードには右にテンキーが並んでいるので画面から却って遠くなり，余分なストレスが生じるような気もする．キーボードの前面に配置するのが一番楽であることは確かだ．いっそのこと，キーボードとモニターの中間に置くというのも考えられないではない．かなり無理な感じはあるが，ロギングを作業の中心と位置付けるのならあり得ない配置ではない．⇒ただ，少しやり過ぎの感はある…

やはり，ロギング用のノートは左配置しかないような気がする．この配置に慣れてしまえばよいのではないだろうか？⇒それしかないような気がする．今のところは，これがベストと考えるしかなさそうだ．ともかく，しばらくこれで行ってみることにしよう．

何が問題なのか？それが問題だ？一言で言えば横書きにしたときのクリップ領域の問題だ．これまで縦書きでは問題は起きていないと考えられるいので，これは「横書き上の問題」であると言える．また，クリッピングをまったく行わないようにすれば描画可能であるところから，クリップ領域の問題であるとも言える．確かに，「横書き」という設定には多少の問題があることは確かだ．横書き座標系という座標系は存在しない．というか，少なくとも静的なデータとしては保持していない．内部座標系は論理座標系であり，この座標系は本来縦書きで用いられてきたものだ．縦のものを横にすれば横書きになるというのは確かであり，実際その方法で描画可能になっている．

縦のものを横にするという「変換」は描画を実行するプリミティブな関数のところで走行時に直接実施される．物理座標系はウィンドウ座標系であり，座標単位はピクセルである．クリッピングを実施するときには，その直前の状態を退避して，事後に書き戻すような動作になっている．このとき，①元のクリップ領域が復元されない，②描画時にクリップ領域の論理和を取る演算で領域空が発生する，という2つの問題が発生している．まず，①の問題から見ることにしよう．⇒すこしいじり過ぎてしまったようだ．一度バックアップに戻って安定したところから再開することにする．2022-03-17まで戻ることになった．この版ではゼルコバの木3.zelがエラーなしに描画できる．

これよりあとの版ではエラーが出る上，画面の一部が欠けてしまうなどの不具合がある．この図面は横書きに取り組んだときに最初に扱ったもので，結局スタート地点まで戻ってしまった．ともかく，ここから出直すことにしよう．3月17日のログでは最初に「reverseAxisの参照箇所をDrawingObject.cppに集約」するということをやっている．とりあえずこれはやっておくことにする．この日のログには「インポートしたときの図面に系線や人名が表示されないという問題」があるとしているが，少なくともこのサンプルでは問題なく描画できている．なぜだろう？⇒いや，確かに起きている．「インポート」が再現の条件だ．

ログにあるように「Bobject::setClipRegionでつねにpdc->SelectClipRgn(NULL)とすれば描画可能」であることは確かだ．3月21日のログには，「RGN_COPYには第一引数をNULLにしてSelectClipRgnを呼び出すようにすれば，正しく動作する」とある．⇒確かにそのようだ．ただし，Bobject::setClipRegionの中でクリップ領域をLPtoDPするとき，直交変換しないようにすると描画できなくなる．つまり，少なくともここでは直交変換が必須であるように思われる．ともかく，ここから始めるしかない．腰を落ち着けて取り組むことにしよう．

開発機のドライブEから外付けHDDへの転送は3日越しになった．99%まで完了しても，残り時間はまだ5時間15分もある．1GBの転送に6時間というのは流石に遅いのではないかという気がする．今となっては手遅れだが，SSDという選択肢もあったのではないだろうか？SSDでは2TBを超える大容量のドライブというのは見当たらないし，価格もかなり高い…まぁ，当面はこれで行くしかない．

BlackHawkのCドライブが逼迫している．容量は27.8GBで空き領域は2.75GB．ユーザデータはCドライブに置いていないのでこれ以上削減することはできない．最後の奥の手としてドライブを圧縮することにした．これまで圧縮ドライブというのは一度も使ったことがないが，背に腹は変えられない．かなり時間は掛かりそうだが，完了すれば数GBくらいの空き容量は確保できそうだ．うまく行けば10GBくらい空くかもしれない．※⇒最終的には4GB程度しか確保できなかった．

リムーバブルドライブとして使っていたUSBメモリの中身を一旦外付けに移して空にすることにした．64GBのメモリが2つある．1本はすでに転送完了しているが，もう1本は転送だけで丸一日掛かりそうだ．フォーマットもクイックでない正規のフォーマットではかなりの時間が掛かるが，まだこれからも使うものなので，やっておいた方がよいと思う．2本目の転送量は58.5GBで残り時間16時間とある．いずれ今日中には終わらない．フォーマットの方はあと1/3になったので，2,3時間後には完了するかもしれない．ドライブの圧縮の方はまだ，1/3程度の進捗だ．

※ELECOM製USBメモリ58.5GBの転送はあまりうまくゆかなかった．History.IE5のようなファイルが残ってしまうことが原因で空にできないフォルダが相当数残ってしまった．これらは主にマイクロソフトなどの外部アプリに関係するものなので，それらを残したままフォーマットを掛けた．正規のフォーマットを実行しているので完了までにはまだだいぶ時間が掛かりそうだが，これで大体の整理が完了したと言える．

ヤマダ電機からは5日前（15日火曜日）に出荷したというメールが入っていたにも関わらず，日曜日になっても届かない．配送番号を手がかりにネットで検索してみると，「宛先不明で預かり」の状態になっていた．「お問い合わせください」となっていたので佐川急便の営業所に電話を入れてみると，確かにそういう状態になっていた．電話は掛けているが，「現在使われておりません」になったという．あとでヤマダ電機の会員登録をチェックしてみたら確かに古い番号のままになっていた．

「今日は最終便の手配がすでに終わっているので明日になります」というのをねじ込んでなんとかその日のうちに届けてもらう．担当はまだ入ったばかりという中学生みたいに小柄なドライバーで一言言ってやるつもりだったが，何も言わなかった．宛名はプリンタで印字されたものだが，部屋番の2Hが行の末尾で右左に別れてしまったため，配達員には「コーポEMI 2」までしか読み取れなかったのだろう．改行が語句で区切ってあればこのような事故も発生していなかったはずだ．製品は5TBということになっているが，実際には4.5TBくらいしかない．仕様書には4GB以上となっているので，まぁこういうものなのだろう．

５TBというのは流石に大きいのでパーティションで仕切った．サイズはまちまちで，1.9TBx1，976GBx2，750GBx1という感じになった．開発機のEドライブの内容を外付けに移動しようとしたが，丸一日掛けても半分も終わらない．2つのサブノートは完全スキャンが大体１時間で完了するくらいまで軽量化したので一応目標はクリアできた．この転送が完了すれば開発機もその程度には軽くなるだろう．このHDはほぼバックアップ専用で普段は外しておくことになるのではないかと思う．

さて，ともかく横書きの不具合を片付けてしまわないことには始まらない．Bobject::setClipRegionでつねにpdc->SelectClipRgn(NULL)とすれば描画可能なので，クリッピングに問題があることは確かなのだが…⇒やはり，問題はRGN_COPYでクリッピング領域を元に戻す操作がうまく行っていないようだ．RGN_COPYには第一引数をNULLにしてSelectClipRgnを呼び出すようにすれば，正しく動作する．

机上のモニターの配置を少しアレンジしてみた．主たる作業には正面のワイドモニターを使うという基本は同じだが，サブノート２機の配置を入れ替えてみた．ログを付けるというのは作業を円滑に進める上での最大のポイントなので，これがまったくストレスなしにというより，何も考えずに移行できるようになっていなくてはならない．現行では，①ネットアクセス・メール送受→BlackHawk，②ログの編集・投稿→VAIO2，③プログラミング→FireBirdという割当てになっている．

これまでは①が②と③の中間に配置されていたが，②をメインスクリーンの近くに寄せて，視線の移動距離が小さくなるようにしてみた．この配置ではVAIO2のキーボードは使えなくなるので，撤去することになる．つまり，ほとんどすべての作業を正面のキーボードだけで行うようになる．これでよいのではないだろうか？

細かい点だが，いくつか余分な手間を掛けているポイントがある．①スマホのカメラとGoogleのPhotoは同期しているので，アップロードする必要はない，②ブラウザの表示は適当なタイミングで更新されているように思われるので，再描画しなくともよい．項目②の動作はあまり確かではないが，ムキになって再描画しなくてもよい（放置しておけばそのうち同期するだろう）という趣旨だ．ともかく，「頭に浮かんだことはその次の瞬間には画面上に表示されている」ことが必要だ．

さて，昨日の問題に戻ろう．インポートしたときの図面に系線や人名が表示されないという問題だ．縦書きでは動作しているので，横書きの実装によって起きていることは確かだ．横書きの実装に関わる修正はできるだけ複数のソースファイルにまたがらないようにしているが，reverseAxisの参照箇所をDrawingObject.cppに集中しておこう．移動した関数は以下の4つだ．

1. TREEVIEW::DrawControl
2. NAMEBOX::getViewFrame
3. NAMEBOX::DrawName
4. Bobject::SetFontOrientation

クリップリージョンが関係している可能性がある．⇒確かにそのようだ．Bobject::setClipRegionの冒頭でBobject::setClipRegionで復帰すれば描画できる．⇒Bobject::setClipRegionから呼び出しているCDC::SelectClipRgnで直交変換を実施しないようにすると，縦書きと横書きの表示が同じになる．つまり，人名枠と系線は表示され，人名は表示されないという状態になる．この方が状態としては良いような気がする．ただし，インポートでは，SelectClipRgnの戻り値が「新しいクリップ領域は空です」という値になっている．RGN_ANDでクリッピングしているので共通領域がないということになる．

やはり，どこかおかしい．SetClipRegionで対象矩形領域を直交変換してからSelectClipRgnを実行するようにして，ZELからの呼び出しの場合は正しく動作するようになったが，インポートでは元の状態に戻ってしまった．ZELを読み込んだ場合と，インポートで異なるフローを通っているということだろうか？⇒まったく表示されていないという訳ではない．画面上部のほぼウィンドウ枠サイズの領域には描画できる．_CDCを参照している箇所を拾い出しておこう．

1. COUPLING::SetTitleBox
2. COUPLING::SetTitleBox
3. TREEVIEW::BuildBitMap
4. Bobject::DrawJoint
5. PrintNumber
6. Bobject::Nprint
7. Bobject::DrawTextBox
8. Bobject::DrawTextLine
9. NAMEBOX::DrawImage
10. TREEVIEW::Refresh
11. PaintCircle
12. TREEVIEW::GetAutoZoomRate
13. PAGESETUP::getViewSizeInmm
14. PAGESETUP::PrintImposition
15. PAGESETUP::PrintPage
16. TREEVIEW::GetTitleRect
17. TREEVIEW::GetFrameRect
18. TREEVIEW::CenteringBox
19. TREEVIEW::GetDrawSize
20. TREEVIEW::DispFrameRect
21. TREEVIEW::GetWheelPosition
22. TREEVIEW::CenteringMove
23. TREEVIEW::GetFramePosition
24. TREEVIEW::GetScrollValue
25. TREEVIEW::GetCenterPoint
26. TREEVIEW::CenterPostMove
27. TREEVIEW::DPtoNormal
28. TREEVIEW::CallCenteringMove
29. TREEVIEW::getOyaFrame
30. Bobject::setClipRegion
31. TREEVIEW::LimitSizeOver
32. TREEVIEW::MouseEnterBox
33. TREEVIEW::LButtonDblClk
34. TREEVIEW::LButtonDown
35. TREEVIEW::LButtonUp
36. TREEVIEW::MouseMove

ヤマダ電機からのメールでは昨日の日付で出荷となっているので，今日中には入荷するのではないかと思う．これが入ったからといって世界が一変するものでもないが，待ち遠しい．なぜだろう？VS2017が立ち上がってこない．管理者権限を持たない通常の起動なら立ち上がってくる．⇒再起動して立ち上がるようになった．

開発機を起動したら，Windows 11インストールのプロンプトが出た．アップグレードした方がよいのか？悪いのか？ネットでチェックしてみる．Windows 10のサポート終了は2025年10月なのでそれまでは使える．ファイルのコピー・ペーストなどの基本操作が使い難いという話もある．とりあえず，今日のところはパスしておこう．

仮修正は一通りフィックス完了しているが，2021年以前の古い修正もあり，かなりの部分が「保留」として残った．横書き対応修正は一応完了しているので，いよいよ三本桜の復活に進むところだが，その前に描画までの時間をもう少し短縮できないものかどうかを確認しておきたい．VerifyTest 2^11 3236.zelは3336点というゼルコバの木としては特大図面に当たるが，初期画面が出る前にマネージドデバッグアシスタントのブレークが入ってしまう．ここまでですでに1分掛かっているが，系統並び替えまでにさらに2分掛かり，さらに1分でようやく描画になっている．⇒この修正はかなり大掛かりなものになりそうなので，後回し．

▲ZELファイルは正しく描画されているが，隣接リストのインポートではほとんど図面になっていない．拡張選択するとカードが反転表示されるので，画面には表示されているようだが，カード#1を除くと枠線も出ない．一覧表には511点のデータが表示されている．縦書きなら描画できる．なぜだろう？見当もつかない…

アマゾンから購入した中古品のWiFi HDDは速攻で返品することになった．アマゾンの返品手続きは明快かつ迅速で，製品を再梱包し，宛名ラベルを印刷したものを貼り付けて，0800-0800-111に電話すると最寄りの郵便局から集荷に来てくれる．伝票も集荷に来た職員が代筆してくれた．返品理由は①スマホにインストールしたministation2アプリから本体にアクセスできない，②バッテリの充電が4時間以上（丸一日）掛けてもフル充電にならないばかりか，かなり発熱するという2点だ．

スマホの設定→WiFiの画面では接続できていることが確認されているのに，アプリでは「接続してください」が表示され，それ以上前に進めなくなる．ネット上にもこの種の不具合は報告されていて，製品交換で解決したという事例もあるが，今回のケースは中古品なのでそれもできない．添付されてきた充電用とPC接続用のUSBケーブルは2本とも新品だったので，多分これは販売店で補充したものだろう．つまり，ケーブルも紛失したような状態で出品されたものが「ババ抜き」のように回ってきたということのようだ．あるいは，すでに何度も返品されたものを繰り返し出荷している可能性すらある．わたし自身あきらめてこのままただのUSB HDDとして使うことも考えてみたし，お金に困っていればヤフオクなどで転売していたかもしれない…

無線HDDに関しては2年前にも一度購入を試みて返品しているので，今回また同じ失敗を繰り返してしまったが，無線HDDについてのわたし自身の思い込みないし錯誤がその原因の一つであったことは否めない．大容量HDDは家電量販店の棚に山積みになっているが，その用途は主にビデオ録画であり，HDDに保存された録画データを他のデバイスで再生するというのが目的のようだ．HDDに録画データを保存するというのは以前は放送局向けのプロフェッショナルな機材でしか使えなかった機能だが，それがごく普通に日常的に使えるようになったという変化がその背景にある．わたしはそもそもテレビを見ないし，持っていないのでその辺りの環境変化にまったく気づいていなかった．

NASというのはそれとはまた少し異なる流れでRAIDなどを使った巨大データベースの構築というむしろどちらかというとビジネス用途向けの構成と考えられる．わたしの場合，無線HDDと言ってもインターネットに接続して外部からアクセスするなどのことはまったく念頭になかったし，むしろ外部から遮断されたクローズドな環境を考えていたので最初から話が食い違っていた．それを無理やり合わせようとしていたのだが，どうやってもうまく組み合わせることができなかった．USB接続なら1万5千円出せばもっと大容量のドライブを手に入れることができるし，わたし自身の用途・目的を考えるなら，USB HDDを所内LANで共有すれば十分というのが最終結論だ．

結局ヤマダウェブコムで5TBのBAFFALO製HDPGF5.0U3GWHA 16,897円というのを購入することにした．これは本体重量250gというポータブルタイプだ．これまで使っていた東芝製HDTC607JS3A1 750GB 本体147gには十分満足していたので，その代替機になると思う．ポータブルタイプを選択したのは，別のPCに繋ぎ変えるときの便ということもあるが，耐衝撃性では据え置き型より優位なのではないかと思ったからだ．（多分電気代もかなり違うのではないかと思う…）

わたしの感覚では750GBですでに大地主なので5TBならどこかの領主にでもなった気分だが，果たしてこれが何年持つ（続く）のだろう？次の大容量HDDを購入するときには，少なくとも100万人規模の系図データベースをネット上で公開するような仕掛けになっているかもしれない．いや，そうでなくてはならないだろう．24時間以内に発送ということになっているが，今日中に届くというのは無理だろう．ともかく仕事の続きに戻ることにしよう．

すでに横書きで表示できるようになっているが，もう少し手を入れる必要がある．というか，拡張選択の動作がおかしくなっている．

▲VerifyTest 1-2047 1631.zelを開いてマウスをドラッグして拡張選択しようとしたとき，選択枠の表示位置がおかしい．クリック位置から離れた場所に表示され，XYが逆転している．⇒この問題はすでに解決しているはずなのに，ぶり返している．

＿CDC::DPtoLPで直交変換しないようにしたら正常動作した．前のバージョン（2022-03-09-1）を見ると，LbuttonUPで使われているLPtoDPとDPtoLPはどちらも基本クラスのメソッドを呼び出している．実際，両側で直交変換すると元に戻ってしまう．ここは，LPtoDPではオリジナルの関数を使うようにしておこう．⇒いや，その逆のようだ．LPtoDPで直交変換し，DPtoLPではしないとすれば動作する．⇒一応これで動作するようになった．

「クリッピングを一時停止する＠20220310」を調べてみよう．⇒このオプションを外しても問題なく動作している．問題はすでに解消しているようだ．これで大体横書き対応修正は落ち着いたのではないかと思う．一度バックアップを取ってから修正をフィックスしてしまおう．

▲アプリ終了時にメモリリークが検出されている．⇒いや，これは以前から出ていたもののようだ．少なくともNODULEとして管理されている分に関してはリークは発生していない．

メールをチェックしても，「発送した」という連絡は入ってこないので，どうも今日中に配達というのは望み薄という気配になり，スマホのバッテリーもあがり掛けたりなどしていたので，待ちくたびれて椅子で寝てしまった．一度目を覚ましたのでスマホをチェックしようと思ったが，そのままベッドに転がりこんでしまった．朝メールをチェックすると，なんと昨日の午後4時半には配送完了という通知が入っていた．ドアを開けると廃棄待ちのコピー機の鉄製の台の上に荷物が載っている．多分ピンポンは押したのだろうが，あいにく故障していて音がしない．「置き配」ということになっているので，これはルール違反にはならない…下図↓は開封後に撮影したもの．

開封してみた．一見してかなり使い込んだもろセコハン品という感じで，同封の「初期設定ガイド」なども擦り切れてぼろぼろになっている．これで使い物になるのかな？というのが第一印象だ．ともかく充電してチェックすることにしよう．充電完了まで4時間くらい掛かるという話だが，充電中でも使えないことはないだろう．USB3.0でPCに接続すると問題なく認識できた．スタートメニュー→ディスクの管理を開いてみる．ドライブ名はHDW-PDU3でドライブ文字にはFが割り当てられている．NTFSフォーマットで931.51GB．1TBからだいぶ目減りしているが，まぁ，こんなものかもしれない．1GB程度がすでに使用済みになっている．ファイルの転送時間を計測してみる．153GBの移動で1時間5分という予測が出ている．いま5:42なので6時50分頃には完了ということになるのだが…転送レートは10～50MB/sくらいだ．20分経過して残り時間は1時間30分に延長された．

「仕様・詳細情報」には「本製品は，恒久的なデータの保存場所ではありません」とあり，「定期的なバックアップを強くお勧めします」と書かれている．わたしは「本機」を「定期的なバックアップ用ドライブ」として使用するつもりだったのだが…とんでもない錯誤だったようだ．「お使いの環境や使用状況によって数年で寿命となることがあります」だと…コロナワクチンの副作用の説明にもどこか似てるような…まぁ，ともかくはUSBドライブとして「しばらく」は使えるだろう．開発機のEドライブは単独で831GBもある．これをバックアップしただけでもう満杯だ！1TBというのは相当大きいと思っていたが，むしろ「到底足りない」と言うべきだろう．この点でも機種選定を誤っていた可能性はある…Eドライブはすでに649GBが使われている．

mmm… 78%完了，残り32GBというところでまだ残り時間20分と表示されている…⇒ようやく，残り時間17分になった．1TBというのがそれほどのものではないということがわかったので，むしろ，ロスのない使い方をしなくてはならないということになった．とすると，このドライブの用途は主に，①開発用フォルダのバックアップ，②メールのバックアップ，③作業ログのバックアップ，④その他後日参照する可能性のあるファイルに絞り込まれるということになる．それ以外は消耗品としてPCに残すということになるだろう．スマホと無線HDDの同期という機能※は見当たらないので，画像ファイルの管理は当面Googleフォトに任せることにしよう．現行でもスマホとGoogleフォトは同期しているのではないだろうか？※この機能は実装されている．

いま，逼迫しているのはサブ機のCドライブとGoogle Driveだ．Google Driveは15GBしかないので，全部抜き取っても大したことはないが，Cドライブを空けるのは結構難しい．⇒転送完了した．現在時刻7:30で1時間50分掛かっている．サブ機で18.7GBの転送を仕掛けたところ，残り時間2時間10分と出た．確かに，このマシンは開発機に比較すると低速であることは間違いないところだが…

「在庫1点ご注文はお早めに」という惹句に乗せられてアマゾンに注文を入れた．BUFFALOの1TB HDW-PD1.0U3の中古品，15,200円．その他，書籍１点と保温ポットで計３点．送料が無料になるというので，プレミアム会員の30日お試し期間を使う．1ヶ月500円という会費は経常的に無理なので，入荷したら速攻で解約することになりそうだが…ポットはすでに昨日のうちに発送されているが，それ以外は週明けになりそうだ．保温ポットはかなり迷ったが，ピーコックのWCI-12 1.2L を選択した．前使っていた象印のCH-CE10 1Lは蓋がねじ式でとても使い易かったのだが，再沸騰ができないという不満があった．

わたしはもともとケトル派なので，電気ケトルと保温ポットのどちらにするかというので相当迷った挙げ句の結論だ．というか，そのあと，IH卓上コンロというのが出てきたのでさらに迷いが深まった．確かに，卓上コンロというのは前々から欲しかったものだし，「お一人様」向けの製品がいろいろあり，これからの暮らしを考えると室内で煮炊きができるというのは画期的であるように思われたのだが，500W製品というのを見て，以前使っていた「ラーメンヒーター」を思い出した．もう使うこともないだろうと思って天袋に押し込んであったが，ガスが止まったとき，急遽K子ちゃんから送ってもらった唯一の熱源だ．100/220V共用で海外に買付けに出かけるとき携行していたものだという．

また，これを使ってみようかな～と思ったのだが，お湯が沸くまでの時間が掛かり過ぎる．200CCくらいの水量で20分も掛かる．いまのIH製品なら1分足らずで沸かしているのではないだろうか？電気代もかなり掛かりそうなので，これを使うという選択肢はないような気がする…という辺りでもう一度反転して保温ポットに落着したという次第だ．保温ポットはヨーグルトを作るときの保温熱源にも欠かせない．

象印の前に使っていた2Lのポットは普通の家庭用ポットで，明け方まだこちらが布団に入っている時間帯に「シュンシュン」と沸き始めるのがわたしには「朝ですよ～起きなさい～」と聞こえていた．そのあとの象印は無音で一度も再沸騰音というのを聞いたことがなかったが，最近になって（朝方冷え込みが厳しくなった関係だろうか？）朝の沸騰音が聞こえるようになってきたので，「ようやくうちの子になったね」と思っていた矢先，なんの前触れもなくコト切れてしまった．おそらくサーモが切れてしまったのだと思うが，分解できず蘇生を断念した．

昨日はスマホがなぜか発熱していたので，電源を切って早めに休んだ．電源に接続しているのにバッテリーが上がってしまうという事象があり，ケーブル不良かと思っていたが，むしろこれが原因だった可能性がある．朝チェックしてみたら100%になっていた．最近は充電率80%くらいで止まってしまうことが多かったので，100%という数字を見ただけで少しうれしくなってしまう．

なぜだろう？また，開発用フォルダ内の.vsフォルダサイズが1.56GBになってしまっている．再設定するしかない．[ツール]→[オプション]→[テキストエディター]→[C/C++]→[詳細]→[常にフォールバック位置を使用] という項目をTrueに変更し、[フォールバック位置] というところにフォルダ名を指定する．確か，つい最近VS2017を再インストールしたような気がする…

第一陣が届いた．ピーコックの電気ポットだ．思ったより大きかったが，サブノートをデスクトップに移動して長机が広く使えるようになっているので，まぁ，いいんじゃないかと思う．

手前にある取っ手付きのガラス容器はさっきダイソーから買ってきた茶こし（500円）だ．もらいモノの急須が壊れてからマグカップを急須代わりにお茶を淹れていた．マグカップは起き抜けのお茶を淹れるとき，茶殻を捨てて流しでパパパっと洗えるという利点があるが，湯呑に注ぐときどうしてもこぼれてしまい，すぐに拭いてもカップの底が卓面に粘り付いてしまうようになる．急須は洗う手間が掛かるので取っ手付きの片口のようなものを探していたのだが，ぴったりのモノを見つけた．

わたしは渋いお茶が好みなので茶こしの茶葉（200g195円の粉茶）をスプーンで押して絞り切るという流儀だが，なるほどうまいものを考えるものだ．電子レンジに掛けられないのはちょっと残念だが，実用的には不足はない．（カップをチンすればよい）ただ，これは一度で完璧に絞ってしまうので，二煎三煎というのは難しいかもしれない．

無線HDDと書籍の方はまだ届いていないが，ネットで取説を探して読んでみた．どうも，現物はわたしがイメージしていたのとはかけ離れたものだった可能性がある．かなり慎重にスペックを読んだつもりだが，「人の目は自分が見たいものしか見えない」のかもしれない．①初期設定ガイド，②仕様・詳細情報，③リファレンスガイド，④ヘルプ（Android）をすべて読んでみたが，どうもこの製品はファイルのバックアップ用というより，オーディオ・ビデオ機器でコンテンツを共有する（それもかなり不十分に）というのがそもそもの目的であるように読み取れる．つまり，最初から方向性が違う．

USBでPCと接続した場合には多分通常のドライブのように見えるのではないかと思われるが，USB接続と無線接続を併用することはできない．無線接続でルーターに接続し，複数デバイスとデータを共有することは可能だが，「再生可能」なファイルは画像や動画などに限られているようだ．何がどこまでできるのか，実際に接続してみないことには本当のところはわからないが，どうも，またしても選択に失敗したような気がする…USB HDDとして使うのなら，もっと容量の大きなものが同じ価格帯で手に入った可能性はあるし，ルーター接続が必須というのならNASに特化したHDDの方がよかったかもしれない．無線接続しながら充電していると発熱することがあるなど怖いことも書いてある…