にしし らぼらとりー

しまった。サムネイル画像の存在の有無も画像インデックスに最初から含めるように実装すべきだったかもしれない。将来的にはそうするつもりだったが、最初の段階ではそこは飛ばしてシンプルに実装しよう、と思っていたのだが。よく考えると、画像インデックスにその情報がない場合、実際に画像を表示する段階で毎回サムネイルの存在をチェックしないといけないので効率が悪い。動作の効率ではなく（※動作としては現状と同じなのだから現状より悪くはなっていない）開発の効率が。 実際にソースを見て考えたら、そうでもなさそうだと分かった。┌(:3」└)┐

20日までに次のβ版を公開したいと思っていたが無理っぽいな。なんとか24日までには公開したいが。どちらにしても、年内の正式版リリースはちょっと難しそうな気がする。ただ、1月は仕事が忙しくなる可能性があるので、できれば年内にリリースしたいのだがががががが。

画像インデックスXMLは、画像保存用ディレクトリにただ1つ作成されるだけなのだが、これを将来的に拡張するとしたら2通りの方向性がありそうな気がする。
➊画像インデックスは単一のままで、他ディレクトリに存在する画像も収録できるようにする方向。
➋ディレクトリごとに画像インデックスを1つずつ生成して、複数の画像インデックスを扱えるようにする方向。
どちらの方向でも対処しやすいような感じを（なんとなく）考えてコードを書いたような気がしているのだが、もしかしたら「どちらを採用するにしても中途半端」な感じになっている可能性もある。まあ、その辺はもっと先の話だ。とりあえず、今の「画像保存用ディレクトリに画像インデックス1つ」の状態で正しく動作するようにするのが先で。

画像インデックスの読み書き関連処理は全部実装できた気がする。ディレクトリ内の画像数がめちゃくちゃ多い場合に、重たくならずに処理できるのかどうか。

てがろぐでは、たとえエラーメッセージ用のページを表示する場合でも、HTTPステータスコードはすべて 200 を返している。エラーメッセージを表示するなら 500 とか（存在しない投稿番号を表示しようとされたら 404 とか）を返した方が良いのかもしれないが、そういうのを返すと、サーバ側で独自のエラーページが作られている場合に、てがろぐ側のエラーメッセージが見えなくなってしまうので望ましくない。そう考えると、やはり全部 200 を返すしかない気がする。もうちょっと何か「Webページとしては正しく表示できるが、内容はプログラム側からのエラーメッセージを伝えている」みたいなことを示すHTTPステータスコードが用意されても良いのではないか。……というか、そういうのは（Webページとしては正しく表示できるのだから）200 で良い、ということなのか。Webとして出力できないからこそ、代わりにコードを返しているのだものな……。

1つの関数はもっともっと短くするべきだとは思っているのだが、なかなかそうはいかん。_(┐｢ε:)_

年内に Ver 3.9.0 をリリースしようと思うと、ドキュメントを書くのに1週間は必要な点も考慮しておかないといけないのを忘れないように……。今回もたくさん書かないといけないから……。