にしし らぼらとりー

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

今の時代、「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週間を切っていた。なんでや……。

レンタルサーバ別のセットアップ方法(15件)を加えたついでに、パーミッションの値の考え方も書いた。

1. まず、「suEXEC」の方の値に設定してみて下さい。それで動けばそのままお使い頂けます。
2. もし動かなかったり不都合がある場合は、次に「一般の場合」の 705 や 604 のように真ん中がゼロの値を設定してみて下さい。それで動けばそのままお使い頂けます。
3. それでも動かない場合は、「一般の場合」の 755 や 644 の方の値を設定してみて下さい。

これ、「3」でないと動作しないWebサーバって、果たして存在するだろうか……？ グループ権限が動作に必要なケースってたぶん存在しないよな……？

「suEXECではない環境」のことの表現は「一般の場合」のままにした。良さげな表現を思いつかなかったので。いや、「その他の場合」でも良かったかもしれないが。「suEXEC対応／非対応」という表記も考えたが、なんか（初心者に）難しそうに感じられると困るなと思ったので。名称は「一般の場合」のままでも、上記のように詳しい考え方のステップを書いておけばまあ良いかなと。

……ということは、「suEXEC環境なのかそうでないのか判断が付かない」みたいなアンケート結果になっていたサーバは、『どっちの値でも問題なく動作する』サーバということなのか。もしかして。

WitchServerの環境についてはアンケート結果がばらけていて（700で動かしている人も居れば755で動かしている人も居るし、Perlパスを変更している人も居れば変更していない人も居る）判断できなかったので、WitchServerの運営者さんに問い合わせてみたところ、丁寧な返信が来た。
それによると、WitchServerはsuEXECを採用しているが、
「設置方法3：パーミッションの設定」の項目で提示されているパーミッションであれば、
suEXEC用、一般用、どちらでも動作します。
とのこと。
どちらでも動作する、という環境もあり得るのか……。知らなかった。CGIが新規ファイルを出力するディレクトリのパーミッションも、別に 705 でも 777 でも構わないようだ。
余計なパーミッションはない方が良いだろうという立場からsuEXEC用を推奨、とさせてください。
ということなので、案内としては「suEXEC側のパーミッションに設定」ということで問題なさそうだ。
Perlパスも書き換える必要はないとのことだった。
それよりも、改行コードを LF にして、バイナリモードでアップロードする点に注意して欲しいという回答だった。

WitchServerさんは、てがろぐセットアップTIPSページを公開して下さっていてたいへんありがたい。そこにパーミッションの話は書かれていないのだが、まさか「どっちでも問題ない」とは予想しなかった。