にしし らぼらとりー

てがろぐ用スキンを作る際などのために、てがろぐをローカルWindows環境で動かしたい場合は、AN HTTPDという超軽量ウェブサーバを使うと良い。これは、ファイル拡張子から実行プログラムを選択してくれるので、拡張子が .cgi ならPerlを実行してくれる。なので、CGIソースの1行目にある #! /usr/bin/env perl のような記述は何でも構わない（読まれないので。つまり書かれていなくても動く）。残念なことに既にAN HTTPDの作者さんは公開を停止してしまっているのだが（閉鎖は2015年だが開発終了は2006年）、Wayback Machineからはダウンロードできる。という話を3年半前くらいに書いた。
➡AN HTTPDはWayback Machineから今でもダウンロードはできる
この記事ではActive Perlをインストールするよう書いているが、Perlなら何でも良いのでXAMPPに含まれているPerlでも良いし、Strawberry Perlでも良い。私の現在の環境ではXAMPPに含まれているPerlを使っている。Perlへのパスが通っていない場合は、自力でperl.exeのフルパスをAN HTTPDの設定画面に書く必要がある。例えば、C:\xampp\perl\bin\perl.exeのような感じで。
AN HTTPDではドキュメントルートを指定する必要があるが、設定画面から簡単に変更できるので切り替えるのも簡単な点が良い。ただ、ちょっとだけ癖のような問題があって「\」記号で終わるフルパスを書くと「そんなディレクトリはない」というエラーが出る。ドキュメントルートをフルパスで指定する際はD:\Projects\FreeCGI\Tegalogのような感じで、フォルダ名の終わりには「\」記号を付けないようにする必要がある。（ただし、ドライブのルートを E:\ のように指定する際だけは例外だが。）

スキンを容易にカスタマイズできるようにする1つの方法として、配色とかを全部CSS変数（カスタムプロパティ）にする、というのがある。とても便利なのだが標準添付の各スキンでは採用していない。なぜかというと、IEでは使えなかったからだ。2017年当時だと、Edgeでも微妙だったし、最新版にアップデートしていない各ブラウザだと使えなかったりもした。なので少数のユーザも排除したくないと考えると、「まだ使えない」と判断するしかなかった（いや、全部のスキンを2017年に作ったわけではないが）。しかし、もはやMicrosoftもIEのサポートを終えたわけだし、全部変数に置き換えていくと良いのではないか……とは思うのだが、いまさら全部を書き換えるのが大変だ。

てがろぐ開発ロードマップを書いておきたい。ローカルの書き殴ったメモはあるが（手書きではない）、そうではなくて、なんかちょっと公開して整頓した方が良い気がしている。

開発方針というか、優先順位の決め方の話ですけども。

今の時代、「JavaScriptが動作しない閲覧環境」というのはまずないでしょうし、考慮する必要性はほとんどないと考えて差し支えないでしょう。また、少なくともGoogleは「JavaScriptを実行した結果」を解釈してくれるようなので（SEO効果の度合いには違いがあるかもしれませんが）検索対策を考える場合でもJavaScriptでページを描画して大きな問題はなさそうに思います。

ただ、

• RSSフィードのようなXML形式のデータ内ではJavaScriptは使えない
• OGPのような「HTML内にmeta要素として静的に存在していないと認識されない物」はJavaScriptで生成・編集できない

というような問題もありますから、「ブラウザ上の描画に関してはJavaScriptを使えば実現できる」ということでも、「できるだけ本体側にもその機能がある方が望ましい」とは言えると思います。

例えば、

• RSSフィード内の何かをJavaScriptで変更したり生成したりしたいと思っても（書かれていれば動くRSSリーダももしかしたらあるかもしれませんが）RSSフィード自体は静的なXMLとして存在しているだけなので無理ですし、
• OGPを読んで利用するSNS等は（たぶん）HTMLファイルを読むだけでその先のJavaScriptまで読んで実行はしてくれないようですから、JavaScriptでOGPを生成したり編集したりしても効果がありません。

これらのような箇所の出力をどうにかしたい場合は、CGI側でその機能を用意するほかありません。
したがって、「ブラウザ上ではJavaScriptで実現できる機能でも、もしかしたら静的に存在していないと効果がないような箇所で出力したいケースもあるかも知れないので(将来的には)本体側にも実装する方が望ましい」とは考えています。

しかしながら、

• 「JavaScriptを使えば（ブラウザの描画上では）実現できること」と、
• 「JavaScriptを使っても（おそらく）実現できないこと」

とがありますから、（この両者を比較すれば）開発を優先するのは後者だと思います。
もちろん実際には「開発のしやすさ」も大きく影響しますから、絶対に後者が優先されるわけではありませんけども。

なので、「JavaScriptで実現できる機能は、（将来的には実装したいと思うものの）開発優先度はそこまで高くならない」と認識しておいて頂けるとありがたい気がします（たぶん）。「気長に待って欲しい」というのは（何もかもを一気に実装するのは無理なので）常に言っていることですが、なお「さらに気長に」待って頂けるとありがたい感じです。

Ver 3.8.2β以降に存在している、ちょっとマズいバグを発見したので修正する。普通に使っている状況ではまず問題は起きないだろうけども。

投稿日時を「xx日前」みたいな相対時間で表示する機能は、日付から閏年を計算して単位を切り替える配慮が面倒なので、「365.25日を過ぎたら年で表示する」という実装にしてあるのだが、これで問題ないよな……？ 閏年は4年に1回なのだから。ちょうど1年前の投稿の場合、「365日前」と表示される場合と「1年前」と表示される場合とがある。年単位は、「年」ではなく「年以上」にしておく方が良いか。「1年と0日前～1年と365.25日前」まで全部を「1年前」と表示するのはちょっとおかしい気もする。「1年以上前」、「2年以上前」……なら良さそう？

画像インデックス生成機能の前に、もう1回β版を出すか……。以前の予定ではこの11月に画像インデックス生成機能を作るつもりだった気がするのだが。いつの間にか11月の残りが1週間を切っていた。なんでや……。