にしし らぼらとりー

最小構成ZIPの配布をやめて（一般向けには完全構成ZIPだけにして）、代わりに「バージョンアップ用ZIP」としてプログラム2ファイル(tegalog.cgiとfumycts.pl)だけを含んだZIPを配布するのでも良いかもしれない。いや、3つ全部を配布するのが一番良いかもしれないが。増やすと手間も増えるので面倒だし。……というか、私自身は構成ファイルを生のままサーバにUPする作業だけにして、サーバ上で適宜勝手にZIP化するようなスクリプトを書いておけば、配布ZIPのバリエーションがどれだけ増えても私の手間は増えずに済むか……。そういう仕組みを作っておこうかな……。

「続きを読む」ボタンを押したら何が出てくるのか、という情報を、ボタンのラベルそのもので示せると便利そうな気がするので、やはりボタンのラベルは動的に指定できるような仕様にする方が望ましい気がする。 >>2203 #済

[H:～中身～]という記述で「～中身～」の部分が「続きを読む」というラベルのボタンで隠される仕様で、その「続きを読む」という文字列は管理画面から自由に設定できるが、ボタンのラベルをその都度変更することはできない。これを [H:ボタンラベル:～中身～] のように書くことで、「続きを読む」ボタンのラベルをその都度指定できる仕様にしようか……？ 長くなるので畳みたい場合と、ネタバレだから隠したい場合とで、ボタンのラベルを使い分けたいケースはありそうだ。#済

ハッシュタグ一覧のリスト(li要素)には該当数がclass名に含まれているが、現状の <li class="count172"> だけだと使いにくいので、class="count172 over100 hash1"、class="count95 over90 hash2"、class="count92 over90 hash3"……みたいな感じで、ざっくりな値とか、上からの順位とかも加えておくと何らかの装飾とかに使いやすいかもしれない。

最新投稿を別の静的ページに埋め込む目的でそれ用のスキンを作ると、Powered-by表記を含めざるを得ない仕様なので、やはりmode=embedみたいな埋め込み専用モードを設けるつもりでいる。

てがろぐの画像投稿機能は元々オマケ機能的にしか考えていなかったので、何一つ管理していない。画像管理画面では投稿画像の一覧は出てくるが、その画面にアクセスした際に毎回ディレクトリ内のファイル一覧を取得して、日付の降順に並べているだけだ。なので、ファイルサイズも縦横サイズも（表示が必要になった時点で）その都度取得している。今のところそれで困ることはなさそうだが、画像数がとても多くなってくるともしかしたら何か不都合が出てくるだろうか？ 内部で画像インデックスみたいなファイルを用意して、そこに各画像の属性を記録しておけば、毎回ディレクトリを走査しなくても良いし、画像の属性を毎回取得しなくても済む。たぶん、その方が望ましいのだろうな……とは思っているのだが。画像をメインにUPする用途で使う場合、画像そのものもカテゴリ（ディレクトリ）分けできて検索できる方が望ましいのかもしれない。ただ、その辺の要望が来たことはないのだけども。

キャッシュしておけるものは最大限キャッシュしておいて、動的生成の頻度を極力減らして、そろそろ速度向上（負荷軽減）を図った方が良いだろうなあ。毎回全データを読み込む仕様なので、データファイルの大きさに比例して重たくなっていくハズなので、データファイルを読んでどうにかする以外の部分の負荷くらいは削減しておきたい。