データ用のSSDを新しいものに交換した。13ヶ月ほど使っていたSunDisk製のSSDで「読めないセクタがある」というエラーが出るようになってしまったので、新たに調達したWestern Digital製のSSDに交換した。

旧SSDから新SSDにパーティションごとクローンを作成すると、「読めないセクタがある」というエラー報告が少なくとも400回出た……。orz 400回で済んだわけではなくて、400回を超えた時点で数えるのをやめて「すべて無視」の選択をしたので、合計でどれくらい読めないセクタがあるのかは把握していない。もうちょっと早めに交換すべきだった。エラーが報告される対象のパーティションは、長期保管用のストレージとして使っている領域であって、日々のデータを蓄積するパーティションは別なので、大きな問題はないと思うのだが。念のために、エラーが出始める直前の時期に作成されたバックアップイメージを隔離して保管しておくことにした。今後、何らかの読めないファイルが出てきたら、そこから書き戻すことにする。次にPCを組むときには、やはりRAID1を構成すべきだ。バックアップイメージは、「失われたファイルがどれなのか」が特定できる場合には役に立つが、「どれなのかは分からないが何かが失われている可能性がある」みたいな状態だとバックアップから書き戻すのは難しい。幸い、「一度保管したら更新することはまずない」というストレージ用途のパーティションでエラーが出ているだけだったので、ちょっと古めのバックアップイメージから上書きさせてはみたが。バックアップと比較すると約1万ファイルほど存在しないことが分かったのだが、それはエラーで消えたのか、それとも過去の私がファイルを整理して消した結果なのか判別できない。うーむ、こんな問題があったとは。新しいSSDは、長く保ってくれると良いのだが。

PCのデータは日々自動バックアップされる仕組みを用意してあるのだが、バックアップ先は「バックアップ用途の内蔵HDD」である。システムやデータを格納するSSDと、パーティションイメージを格納するバックアップ用HDD（※SSDではなくHDDなのは大容量が必要だから）を内蔵させてある。なので、あくまでも同一PC内でバックアップしているだけだ。この場合、ミスやトラブルでデータが失われた場合にはバックアップから復活させられるが、PC全体に及ぶ問題が起きたとき（雷にやられるとか水没するとか盗難に遭うとかランサムウェアに乗っ取られるとか）には対処できない。ので、外部の2ndバックアップもある方が望ましいよな……とは思っていた。最低限、システムドライブとデータドライブだけを外部にバックアップする用途でKIOXIAの128GBくらいのUSBメモリを調達しようかなと考えていた。最初にチェックしたときには3,480円だったが、今はブラックフライデーのタイムセールで2,955円(クーポンでさらに10％OFF)とかになっていたし。しかし、USBメモリは長期保管に向いているわけではないし、どうせならUSBポータブルHDD（またはSSD）の方が良いのではないか、と思って検索してみた。しかし、メジャー処の製品は結構な値段がするし、安い製品は品質が心配だし、何より最近のAmazon返品詐欺の被害も心配である。
ふと、SerialATA機器をUSB接続する変換ケーブルを所有していることを思い出した。それならば、内蔵用のHDDやSSDを単体で調達すれば良いではないかと。用途は「バックアップデータのバックアップ」なので、使用頻度はまあ数ヶ月に1回くらいで良いだろう。とすると、内蔵用のHDDやSSDをUSB接続するのでも問題ない。普段は箱にでもしまっておけば良いのだから。……と考えてみたところで、さらに思い出した。そういえば、退役させた内蔵HDDがいくつかあったはずではないかと。HDDは故障の予兆を感じて交換するケースもあるが、容量が足りなくて交換するケースもある。特に過去のバックアップ用HDDは、さらなる大容量が必要になって退役させたものがいくつかあった気がする。それらは容量以外には問題がないのだから、再活用しても問題ない。というわけで探してみたところ、2016年の夏頃に退役させたWestern Digital社製の1TB HDDを発見した。2010年製造なのでおそらく6年間くらいバックアップ用HDDとして使っていたのだろう。早速これを、SerialATA－USB変換ケーブルに挿してPCに接続してみた。……が、認識がおかしい。ストレージ機器だとは認識されているようだがドライブとしては認識されない。どうやら3.5インチのHDDだとUSB給電では電力が足りなくて動かないようだ……。まあ、若干そうだろうなと思ってはいたのだが。元々このケーブルは、ノートに内蔵している2.5インチHDDをSSDに交換する用途で買ったものなので、3.5インチHDDを接続したことはなかったのだ。というわけで、内蔵HDDのUSBポータブル化はできなかったのだが、せっかく発見された1TB HDDを無駄にはしたくない。ポータブルHDDで容量1TBの製品を買おうと思ったら結構な値段がするのだし。
で、メインPCには4台の3.5インチHDDまたはSSDを内蔵できる空間があるのだが、今は3台しか内蔵させていない。なのでそこに一時的に入れれば良い。HDDはフロントアクセスパネルから交換できる筐体なので、HDDを内蔵させるために筐体を開ける必要はない。HDDをストレージホルダーに4個のネジで留める手間はあるが、使用頻度は少ないのだから良しとする。早速内蔵させてみると問題なく認識した。CrystalDiskInfoによると、12,491時間ほど使ったHDDのようだ。日に換算すると520日である。電源投入回数は4,186回。結構使っているが、特にハードウェアの問題はなさそうなので、まあ、時々接続してバックアップデータをバックアップする用途なら全然問題ないだろう。

中身はすべて必要ないので、一旦フォーマットすることに。NTFSから変更する必要もないのでクイックフォーマットをすれば高速で終わるのだと思うのだが、試しに普通にフォーマットさせてみた。1TBのフォーマットが終わるのに3時間半くらいかかるのだな。最初の頃は100MB/sくらいの速度で進んでいたが、終わりの頃は50MB/sくらいになり、終盤は25MB/sくらいになっていた気がする。ずーっと見ていたわけではないのでハッキリとは分からないが。HDDは記録位置でそこまで(4分の1になるほど)速度が変わるのか。フォーマット中でもPC上で他の作業はできるので、特に問題はなかった。

フォーマットが終わってから、バックアップ用HDDの中からパーティションイメージの完全版（普段は高速化と容量節約のために差分バックアップされる）を、この再活用1TB HDDにコピーしてから、再度シャットダウンしてHDDを取り外した。さすがにHDDは寒い部屋の中でもほんのり暖かい。このHDDに「内蔵バックアップHDDの2ndバックアップ用途」とラベルを貼って、HDD購入時のプラケース（このHDDを買ったときのケースかどうかは分からないが、サイズは3.5インチなら何でも一緒なので問題ない）に入れて保管しておくことにする。
そんなわけで、新しい外部ストレージ機器を調達することなく、余っていたHDDで外部バックアップ手段を用意できた。今のところ、容量が1TBあればメインPCと仕事用PC両方の全パーティションのイメージ(圧縮されている)を格納しても足りるので、しばらくは問題ないだろう。あとは、数ヶ月に1回くらいこの2ndバックアップHDDのことを思い出して、時々コピーすれば良さそうだ。数ヶ月に1回だと、本当にこの2ndバックアップが必要になったときに数ヶ月分の更新内容が失われるわけだが、そもそもこのバックアップが「2重目」のバックアップなのだ。普段の完全なバックアップは内蔵のバックアップ用HDDにある。それすらも失われてしまったときに、何もかもがゼロになるのを防ぐためのバックアップなので問題ないだろう。日常のクリティカルなデータ（仕事のデータとかメールとか開発ソフトのデータとか）は、バックアップ用HDDにバックアップされるほかに、メインPC（ミニタワー）と仕事用PC（ノート）とで相互に同期しているし、ごく一部はネット上の小容量なストレージにもあるので、既に多重なバックアップになっている。なので、今回用意した2ndバックアップHDDは、本当に必要になることはまずないと考えている、保険の保険みたいなものだ。

G7各国の中でのCOVID-19ワクチン接種率ではカナダに次いで日本が2位という話がTwitterで流れてきたので、そのソースになっているourworldindata.orgでグラフを出してみた。たしかに6月からほぼ一定ペースで線形に伸びているところはすごい。ただ、ほぼ同じ時期に勢いよく伸ばせたカナダが一番すごいが。なんでこんなに一気に伸ばせたのか。人口も理由の1つだろうか？ カナダの人口は約3,800万人くらいらしいので。とはいえ、国土面積は広いのだから、人口が少ないという理由だけで打ちやすくなるわけではないだろうけども。ただ、ワクチンは数の確保が難しかったので人口が少なければ調達の難易度は下がる気はする。他国の人口は、接種率の高い順に、イタリア(約5,960万人)→フランス(6,740万人)→英国(6,720万人)→ドイツ(8,320万人)→米国(3.3億人)である。と書いてみて気付いたのだが、G7の中で一番人口が少ないのはカナダだったのか。今までそこを比較してみようと思ったことがなかったので気付かなかった。ワクチン製造会社を抱えている米国と英国はさすがに早くから伸びているが、アメリカは早々に伸び悩んでしまっている。人口が多くて国土も広いが物流も技術も高いわけだから、理由は自由すぎる国だからだろうか？ 英国も65％くらいまでぐんぐん伸びていたのに今は伸び悩んでいるが、これは何故だろうか。なお、G7の枠組みで比較することにあまり意味はなさそうなので、世界で人口の多い国家ランキングで1位から11位まで（※日本が11位）の国家も比較してみた。それが2枚目のグラフである。ずーいぶん明確な差が付いてしまっている。日本の伸び方がめちゃくちゃ特徴的な気がする。(^_^;) 製薬会社を抱える米国の優位さもよく分かるが。中国は14億人も人が居るのに本当にここまで打てているのか（グラフでは10月23日時点で73.92％）。ただ、国民が何人だろうと、ワクチンの数さえ確保できていれば国家が打たせようと思えば打たせられる国ではあるとは思うが。^^; ロシアはずいぶん初期に自前のワクチンを開発したと言っていたが、まだ32％しか打てていない。たしかNewsweekの記事か何かでロシアに駐在している記者のレポートがあって、外国人でも手続きさえ踏めばワクチンを打てたというような話を読んだ気がするが。ただ、どこ製のを打てたのかは覚えていない。たしかロシア製以外もあるが何を打てるかは自分では選べず直前になるまで分からないという話を読んだことがあるのだが、それがロシアの話だったかどうかは記憶にないので別の国の話かもしれない。接種率が低いのは、単純にワクチンを打ちたい人が少ないのだろうか？ ロシア人でもロシア製は打ちたくないということ？ ロシアの人口は1.45億人で、日本より2千万人くらい多いだけだ。ただ国土は広いが。13.6億人のインドは残念ながらまだ23％のようだ。仮に日本と同じ分量を同じペースで調達(と接種)できたとしても10倍以上の時間が必要なわけだものな。ただ、インドは提携工場を使ってむしろワクチンを製造(輸出)している側だったような気もするのだが。ファイザー製やモデルナ製はかなり低い温度で輸送する必要があるので、交通インフラと医療設備が整っていない地域では苦しいという話がそういえばあったな、と思い出した。

Twitterのトレンドに「Windows11」の話題が出ていたので、Win11リリース関連のツイートを眺めていたら、「Win10スタートメニューの右側は全然使わないよね」的な意見があって、それに賛同が多くて驚いた。あの領域は端をドラッグすれば領域を拡張できるのだが、そこに自分の好きなようにアプリを配置しておけば、[Windows]キーを押すだけで開くランチャーとしてすごく便利なのだが。デスクトップにアイコンを並べていると、ウインドウをたくさん開いているときにはデスクトップへアクセスするのが面倒だが（いや、デスクトップにはタスクバーの右端の端をクリックすれば開いている全ウインドウを一気に最小化できるからアクセス自体は簡単なのだが、その方法でデスクトップを表示すると、最小化されたウインドウを元に戻すのが面倒くさい）、この方法ならスタートメニューを表示するだけでアクセスできるので、ランチャー（＝アプリを簡単に起動できるアプリ）としてとても楽に使える。

Windows10でのMicrosoftの失敗があるとすれば（たくさんあるが）、スタートメニューの右側の領域を有効活用する方法をユーザに分かりやすく提示できなかったことだろう。デフォルト状態でもっと右側に余った空間を見せておいて「ここに好きなようにアプリをピン留めできますよ」と示しておく方が良かったのではないか。なお、この話は2016年にブログ記事「Windows10のスタートメニューは面積を縦横に大きく広げてアプリを一望できるようにすると便利」にも書いた。

日付を入力するだけで「その日が祝日かどうか」を判定する処理はそんなに難しくないだろうと高をくくっていたのだが、「振替休日」と「国民の休日」という2種類の臨時休日の判定が意外と複雑なので、単に日付を指定するだけではその日が祝日なのかどうかは分からないことが分かった。少なくとも「調べたい日の直前の日曜日」から「調べたい日の翌日」までの毎日が休日なのか平日なのかを調べないと特定できない。「振替休日」は、祝日が日曜日と重なった場合に「次の平日」が休日になる制度なので、ほとんどの振替休日は月曜日になるのだが、5月の連休時だけは祝日が連続するので、火曜日や水曜日が振替休日になる可能性がある。なので、祝日リストを持っているだけではダメで、「調べたい日の直前の日曜日」から当日までの状況を調べてからでないと「今日が休日なのか平日なのか」が特定できない。「国民の休日」は祝日と祝日に挟まれた1日が休日になる規則だが、祝日と祝日に挟まれた1日が日曜日の場合には特に何もないし、最初の祝日が日曜日の場合には自分自身(当日)は振替休日になるだけであって国民の休日ではない。なので、調べたい日の前日と翌日が祝日かどうかを判定してから、その日が日曜日または振替休日ではないことを確認する必要がある。昔はこの規則によって5月の連休が構成されていたのだが、今では5月の連休は本当に「3連続の祝日」になっているのでこの規則は使われていない。しかし、数年に1回だけ、この規則によって9月にシルバーウィークができる（次回は2026年だ）。なお、今のところの祝日規則上では発生しなさそうだが、『振替休日と祝日に挟まれた平日1日』が「国民の休日」になるのかどうかがよく分からない。将来的にそういう状況が発生するよう祝日が新設されたり移動されたりしたら、またカレンダー生成プログラム製作者が苦労しそうである。いや、苦労するかどうかは分からないが、少なくともプログラムはアップデートする必要があるだろう。昨年と今年には臨時に祝日が移動する法律ができて一時的に祝日が変化したが、このような臨時移動に対応できるカレンダープログラムはそうそうない気がする。祝日リストを編集できるプログラムはあるだろうが、「ある特定の年だけは異なる祝日リストを使う」というような状況を事前に想定しているプログラムはさすがになかったのではないか。そういうのを今作っているのだが、なかなか手間が掛かる。祝日規則はシンプルにして頂きたい。

春分の日、秋分の日や、夏至・冬至は、日付が決まっているわけではなく毎年微妙に異なるので、カレンダー生成プログラムを作るようなときには計算式で日付を求める必要がある。それぞれ以下の通りだ。
●春分：int( 20.8431 + 0.242194 * ( $year - 1980 ) - int( ( $year - 1980 ) / 4 ) )
●秋分：int( 23.2488 + 0.242194 * ( $year - 1980 ) - int( ( $year - 1980 ) / 4 ) )
●夏至：int( 22.2747 + 0.24162603 * ( $year - 1900 ) - int( ( $year - 1900 ) / 4 ) )
●冬至：int( 22.6587 + 0.24274049 * ( $year - 1900 ) - int( ( $year - 1900 ) / 4 ) )
未来永劫使えるわけではなく、夏至・冬至に関しては2099年まで有効な計算式らしい。なぜこの計算式で計算できるのかは理解していない。
なお、$yearは西暦4桁の数値を入れる変数で、intは小数点以下を切り捨てて整数化する関数を指している。

節分も2月3日固定ではなく年によって変化するという驚きの事実を昨年末に初めて知った。今年は2月2日が節分だった。124年ぶりのことらしい。そんなに間が空くのなら、今後しばらくは2月3日固定で良いのかな……、と思ったらそうでもなく、2025年、2029年、2033年など閏年の翌年が2月2日になるパターンがしばらく続くらしい。そんなわけで、節分もカレンダーに表示したければ以下の計算式を使う必要があるようだ。
●節分：int( 4.8693 + 0.242713 * ( $year - 1901 ) - int( ( $year - 1901 ) / 4 ) ) - 1
こちらは最後に1を引かないといけない点に注意が要る。

画像の遅延読み込み（画像の掲載場所付近までスクロールしない限り画像ファイルを読み込まないようにしてくれるブラウザ側の機能で、HTML5で正式に追加された仕様）は通信量削減に役立つので、最近では問答無用でimg要素にloadiong="lazy"を加えている。ただ、この属性を加える際には注意しないと、ページ内リンクの移動距離が正しくなくなって、ページ内リンクがうまく機能しなくなることがある。その原因は、img要素にwidthやheight属性を書いていないことだ。昨今、レスポンシブなデザインが当たり前になったので、img要素にwidth属性もheight属性も書かないことが多かったのだが（CSSでサイズを指定するからHTMLにサイズを書いても無駄だろうということで）、widthやheight属性を省略してしまうと、実際に画像が読み込まれるまで専有面積が分からないので、ページ内リンクで長距離を移動する際には移動先の座標がズレてしまうのだ。これを防ぐには、とりあえずwidthとheight属性をimg要素に書いておくこと。実際に表示されるサイズである必要はなく、たぶん縦横比が分かれば良いのだと思うので、画像の原寸サイズでも指定しておけば良い。このwidth・heightの両属性がHTMLにあれば、CSSと組み合わせることで画像の表示面積が分かるので、遅延読み込みによって画像が読み込まれていなくてもページ内の座標が確実に決まるから、ページ内リンクがズレることもない。HTML側でサイズの指定がなくても、CSS側でピクセル単位でサイズが指定されていれば問題はないだろうが、レスポンシブWebデザインだとたいてい画像サイズは割合で指定されているから、画像の縦横比が(HTMLから)分からないと実際の表示面積が計算できない。もしかしたら業界では当たり前のことだったかも知れないのだが、私はそこに気付くのに結構な時間が掛かってしまった。

世の中には部屋を真っ暗にしないと眠れない人も居るようだが、長年の試行錯誤から私は真逆だと分かった。私は室内にある程度の灯りがないと眠れない。もちろん真っ白な蛍光灯色の灯りで室内を照らした状態では寝ないが、淡い橙色の灯り（デスクに置けば読書が可能な程度の光量が必要で、豆電球では全然足りない）くらいはあった方が良い。光源が直接目に届かない間接照明のような感じになる配置で灯りを置いている。適度なホワイトノイズもあると望ましい。ちょうど良いのがタワーPCの稼働音(主に冷却ファンの音)なので、PCの電源は寝ているときも入れっぱなしである。ついでに液晶ディスプレイの灯りもある。寝るときに液晶ディスプレイは見ない方が良い云々と言われるかもしれないが、別にモニターの真ん前で寝ているわけではない。それは間接照明くらいにしかなっていないので何も問題ない。長年「寝るときには真っ暗に」という世間の常識(？)に縛られて気付けなかったのだが、室内に多少の明るさ(とホワイトノイズ)を維持するようになってからは明らかによく眠れるようになった。必要な明るさの目安は、壁に貼ってあるさくらたんポスターがギリギリ見えるくらいである。明るいとメラトニンの分泌が抑制されてしまうが、それは網膜に直接光が入っていたらの話なようなので、間接的な灯りだけだったら問題ないようだ。

稀に遭遇するのだが、「実際に作業してくれなくても、やり方さえ教えてくれれば良い（ので安くして欲しい）」という旨の要望を受けることがある。本当に稀で、滅多に遭遇はしないがゼロではない。しかし、「自分で作業する」のと「作業方法を教える」のとでは、後者の方が遙かに手間が掛かるのだ。「自分で作業する」場合はただ自分の頭で考えた作業を進めれば良いだけだが、「作業方法を教える」場合は（自分でもその作業を仮に進めつつ）1手1手その手順を文書化したり図示したりする手間がかかる。なので、「作業方法を教える」ということで手間が減ることはなく、むしろ大幅に手間は増えるのだ（たいていの仕事がそうだと思うが）。おそらく「ここをこう書き換えたら良い」的なアドバイスが存在すると思われているのかも知れないが、「ここをこう書き換えたら」と言えるなら、それは既に作業が完了している状態である。もちろん「ここを」の対象は少なく見積もっても数百行くらいはあるのだ。参考書を読んで学ぶ手間を省くために教師を雇ったら、教師代の方が高くつくだろう。おそらくそれは誰でも分かっているだろうが、それでもなお「やり方さえ教えてくれたら」云々と言ってしまうのは、「ちょっと方法を知れば簡単にできる」と思われているのかもしれない。もしくは、「情報は無料だ」と思われているのかもしれないが（その方がより酷い）。思うのは自由なのでその点に文句はないのだが、そういう方とは極力仕事をしたくない。経験的に、精神力を必要以上に消耗すると分かっているからだ。仕事を長く継続させる良法は、無駄に精神力を消耗してしまう機会を排除することである。

続刊の発売を心待ちにしていたのはこれだ。

「さよならの言い方なんて知らない。」第4巻（新潮文庫nex）。写真は左が新刊、右が既刊。前巻がどんな終わりだったかをしっかり確認してから新刊を読まねば、と思ったので第3巻を本棚から出していて、終わり部分だけをいま読み返した。ああ、こんな終わりだったっけ。と、ずいぶん忘れていた。

Wall Street Journalは(もちろん)日本語版を読んでいるのだが、ふと気になったので記事原文の英語版を表示させてみたところ、明らかに日本語版よりも遙かに長くて驚いた。下記画像の左端が日本語版記事で中央が原文(英語)表示だ。

一瞬、これだけの長い英文を日本語に訳すとこの程度の文字数で済むのかなと思ったのだが、全体を俯瞰して見るとそんなわけはなかった。^^; 詳しく見ると日本語版記事は628文字くらいなのだが、原文の英語記事は8,850文字ある。試しにDeepL翻訳に掛けてみると、無料版で一括翻訳できる限界の英語5,000文字分の日本語訳結果だけでも1,975文字あった。(^_^;;; DeepL翻訳の方が冗長になるので人間が自然な日本語に訳せばもう少し短くはなるだろうが、さすがに628文字にまではならないだろう。^^;
日本語記事での記載は外観をざっくり説明しているだけで、各国の誰々が何と言った、というような詳細は省いている感じだった。
これは、後々にアップデートされるのだろうか？ ニュース記事は速度も重要だろうから、まずざっくりな簡易翻訳バージョンを公開しておいて、後から完全バージョンに差し替えるとかそういうこともあるのかな、とも思ったのだが。📗