公立高校の入試って今頃なんだっけ。

ねむい。凄まじく、ねむい。

「カロリー取り過ぎ」や「マイルを貯める」のカロリーやマイルはどちらも単位だから良いと思うのだが、「ギガが減る」のギガは単位ではなく補助単位に過ぎないので違和感が強いのではないか。ギガバイト(Giga Byte)なのだから単位のByteを使って「バイトが減る」ならまだ許せる。間違いなく異なる意味に解釈されるだろうが。またはビット(Bit)でも良い（1バイト＝8ビットだ）。「カロリー取り過ぎ」だってkcal(キロカロリー)の補助単位の方を使って「キロ取り過ぎ」と言ったら意味が分からないだろう。

今朝の5時頃に、API 4.0が停止したとメールで連絡が来ていた。「As of today, March 9, 2020, the upgrade to PA API 5.0 should have been completed. Any application calling PA API 4 will no longer be able to retrieve information.」とのこと。日本時間の10日5時に送ってくるというと、どこの標準時が基準なのか。米国西海岸だと9日13時、東海岸だと9日16時、UTCだと9日20時だ。まあ、アメリカでのだいたい昼頃に送ったということだろうか。(^_^;)

株価下落で日本でも証券会社のサーバに接続できなくなっていたとかTwitterに流れてきていた。今朝S&P500の指数を見ると、だいたい1年前くらいの値にまで下がっていた。

グラフは左側が1年スパン、右側が3年スパン。2019年1月頃に大きく下がったときほどまではまだ下落していないけど、どうなるかな。とりあえず、ちょっとだけお買い得にはなっているな、とは思う。しかもここ数日でちょっと円高になっているし。

昨夜は真夜中でも室温が19度くらいあって、毛布はなくても良かったくらいだった。今日も暖かいらしい。明日はまた少しだけ寒くなるような予報だったけども。

キャッシュデータの保存先は分散せずに単一のディレクトリに記録しているのだが、1つのディレクトリに10万ファイルとか存在してもパフォーマンスに悪影響はないだろうか？ ディレクトリ内のファイル一覧を取得して何かをしようとするなら当然遅くなるだろうが、そうでない限りは特に問題ないと思っているのだが。キャッシュの読み書きをする場合、「あるデータに対するキャッシュファイル名」は生成規則(命名規則)が明確なので、ファイル名を決め打ちで読み書きすれば良いから、「ディレクトリ内のファイル一覧を取得してから何かを探す」というような処理は不要だ。単に「指定のファイルが存在するかどうか」だけをチェックすれば済む。この場合、10万ファイルでも100万ファイルでも、複数のディレクトリに分散していようが単一のディレクトリに保存していようが、パフォーマンスに差はないと思っているのだが、この認識は正しいだろうか？（ファイルシステムにも依りそうだが。） とりあえず、現状の7,600ファイルくらいなら体感速度に影響はない。ただ、キャッシュファイルを無限に作るわけにもいかないので、どこかの時点で「古いファイルを消す」という処理が必要だが、このときには「ファイルの一覧を得て1つ1つの更新時刻を調べる」という作業が発生する。これはファイル数が莫大だとパフォーマンスが落ちそうな気はする。どれくらいの頻度で実行するか次第だろうけども。そこはまだ考えていない。