今年の4月1日からは店頭の価格表記に総額表示(＝消費税を含んだ額の表記)が義務付けられるらしい。正確には今でも義務なのだが、「値札の貼り替え等の事務負担に配慮する」という理由で今年の3月31日までは特例で（税抜き価格であることが明確に分かるなら）税抜き表記でも良いことになっていた。この特例期間が終わるので、4月からは税込表記だけしか認められなくなるらしい。国税庁サイトに表記例とか現行の特例対象(＝4月からはダメになる例)とかが載っていた。とはいえ、対象は「不特定多数に向けた事前の価格表記」なので、見積書とか請求書とかはどんな表記でも良いとQ&Aに出ていた。物販サイトでWeb上に価格を表記している場合には注意が要りそうだ。クライアントさんに注意喚起せねば、と思ったのだが、いま調べてみたらどこも税込表記を採用していた。そういえば昔々（たぶん8％になったときに）総額表示が義務になったときに総額表記に変更していて、10％に上がったときも総額表記のまま更新したのだったような気がする。

確定申告が終わったので、9年前(2012年)分の領収書ファイルの中身を処分して、今年分の領収書ファイルを用意した。法的には7年間しか保管の義務はないのだが9年分保管してある。処分すべく2012年分の領収書を全部出して、捨てやすいようにサイズ別に分類したら、阪急電車の回数券がトランプかな……？ と思うくらいの厚みになっていた。

やたらと枚数が多くなるのは、土日専用回数券（＝5回分の乗車料金で土日に7回乗れる）や、時差回数券（＝5回分の乗車料金で昼間に6回乗れる）が多いためだ。普通回数券（＝10回分の乗車料金で11回乗れる）は数えるほどしかない。大半は時差回数券である。あまり朝早くに阪急電車に乗ることがなかったからだろう。家を出る時刻が遅いとかそういうことではなく、阪急電車に乗る前にJRに乗る必要があるので、JRに乗っている間に阪急電車の「昼間」時間帯になるからだ。「時差」という名称は分かりにくいと思う。「差」の意味が分からない。「昼間回数券」と言えば良いと思うのだが、土日祝なら全日乗れるので「昼間」という単語を採用しにくかったのだろうか。

今日は車も運転したが、かなり歩きもしたので、今すごく眠い。

マイナポイントでICOCAに付与されていた5千円分のポイントを券売機でチャージしてきた。

チャージ額が5,090円になっているのは、マイナポイント以外の何かで付与されたポイントが90ポイントほどあったのだろう。何なのかは記憶にないが。ICOCAにポイントが貯まることが滅多にないので普段から特に認識はしていないので心当たりがあまりない。クロネコの運送料(たぶん3～4千円くらい)をICOCAで払ったのでクロネコ経由で付いたポイントだろうか。鉄道乗車や駅ナカコンビニではポイントが付かないので。

明日は朝にちょっと車を運転しないといけないのだが、天気予報によるとめちゃくちゃ寒そうだ……。しかし、今日の夕方頃から降るかも知れないと予報されていた雪は降らなかったし、今夜から明朝に掛けても降るような予報にはなっていないので、その点は良かったが。車を運転した後でちょっと歩かねばならないので、気温よりも風の方が問題かもしれない。

プログラミング言語（兼統合開発環境）のDelphiが26周年らしい。あまりメジャーな立ち位置にはならなかった言語だと思うのだが、今どれくらい使われているのだろうか。わりと高額な開発環境がずっと販売され続けていることからして、そこそこな利用者が居るのだろうけども。私がWindows用フリーソフトを開発していた頃は、このDelphiのようなUIでC++言語が扱えるC++ Builderという統合開発環境を使っていた。

Googlebotのクロール頻度を下げる方法は、Googleによる解説がある。Google側がクロール頻度(最大頻度)を指定できる設定ページを用意しているが、90日間しか有効ではなく、90日後には自動判断に戻ってしまう。何より、今回クロール頻度を調整したいのは、外部WebサービスのAPIリクエスト権に上限があることが原因なので、「APIを利用せずに出力できるページのアクセスを制限する必要はない」という点があるのでクロール頻度(の上限)そのものを指定する方法はあまり適切ではない。Googleの解説にはもう1つ「緊急クロールの制限」として、「負荷の増大を動的に検出して対応できるならHTTP 429を返せ」と書かれていたので、今回はその方法を採用した。API利用権の残数が少なくなってきたときに、APIを利用しないと出力できないページにアクセスされた場合にだけ、429を返すようにPHPを書いた。