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から)分からないと実際の表示面積が計算できない。もしかしたら業界では当たり前のことだったかも知れないのだが、私はそこに気付くのに結構な時間が掛かってしまった。

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

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

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

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