にしし らぼらとりー

にしし(西村文宏)製スクリプトの公開開発実験場(ラボラトリー)です。各種スクリプトの最新版やβ版の動作確認ができます。バグ報告や、機能面でのご要望などもお気軽にお知らせ下さい。

※当ウェブサイトは、にしし製フリーCGIなどの動作確認サンプルを公開したり、製作進行に関する呟きを掲載している実験場のようなものです。 各種CGIスクリプトの配布パッケージを入手したい場合や、にしし(西村文宏)の個人サイトをお探しの場合は、 本家サイト「にしし ふぁくとりー」へお越し下さい。(╹◡╹)ノ

RSS Feed

開発放言

新規投稿 / 管理用

てがろぐの投稿欄は、Ver.1時代のシンプルなものから、ほぼ行き当たりばったり的な感じで拡張してきたので、エレガントなコードに全くなっていない。このままだと装飾の調整が厳しいので、もうちょっとなんとかすべきなのだが、いきなり仕様を変更してしまうと、(QUICKPOSTでは)既存のスキンで望ましい装飾にならなくなる可能性があるので望ましくない。
とすると、現状の QUICKPOST を QUICKPOST1 としておいて、スキン側に [[QUICKPOSTv2]] みたいに書かれたときにだけ新仕様の投稿欄HTMLを出力する、みたいな配慮が必要だろうな。
いや、今のところ投稿欄を全面改修するような予定はないけども。(必要性は認識してはいるが、優先度が高いとは思っていない、という感じ。)

by nishishi. てがろぐ <345文字> 編集

気力さえあれば、画像管理画面に画像検索窓を実装できる。画像管理画面に表示される画像一覧を(検索で)絞り込むことができれば、ある条件に該当する画像だけを一括削除する操作が可能になるので、あとは「使われていない画像」を見つける処理さえ加えれば、「使っていない画像を削除する」こともできるようになる。

by nishishi. てがろぐ <147文字> 編集

a要素のaはanchor(アンカー)なので、a要素こそがアンカーなわけだが、a要素ではなくspan要素で作ったアンカー的な記述をアンカーと呼んで良いのかどうか微妙な気がしてきた。span要素で <span id="HiddenPoint"></span> とするよりも、a要素で <a id="HiddenPoint"></a> とする方が良かった……?

by nishishi. てがろぐ <177文字> 編集

Ver 4.4.2βで、ギャラリーモード独自の設定として「画像を(原寸画像への)リンクにする」のON/OFFを可能にしたが、それだと自分で使う場合にしか適用できないので、配布スキンでその設定が必要な場合には「そう設定してから使ってくれ」と言うしかない。むしろ、[[ONEPICT:n]] 記法の亜種で、設定に関係なく画像をリンクにせず出力する [[ONEPICT:PURE:n]] みたいな記法を用意する方が便利なのかもしれない……?

by nishishi. てがろぐ <217文字> 編集

TegUpに、てがろぐ丸ごと引っ越し機能も加えるか。てがろぐの引っ越しは、サーバ上の全ファイルをそのまま移動させれば良いだけだけども。TegUpを使って構成全ファイルをZIPに圧縮させて、ブラウザからそれをダウンロードすれば、ちょっとは手間が省ける……?

by nishishi. てがろぐ <127文字> 編集

もはやWebサイトでUTF-8以外の文字コードを採用するメリットが何もないと思うので、てがろぐもUTF-8固定ということで良いかな、ということにしたい。今までは一応は全ファイルの文字コードを一括で修正するなら、UTF-8以外の文字コード(主にSHIFT-JIS)でも動作可能ということにしてはいたのだけど(※配慮はしていたが直接の動作は試してはいない)。ソースの中にサンプル用の絵文字(SHIFT-JISでは定義されていない絵文字)をそのまま書きたいので、もう「UTF-8でしか動かない仕様」ということにしたい。

by nishishi. てがろぐ <256文字> 編集

さんごよみにもカスタム絵文字機能を追加できたあ。(リリースはまだ先)
営業カレンダー的に使われる場合で、営業・休業等の区別を画像で示したい場合には、特にカスタム絵文字機能が便利だよな、とは思っていた。

by nishishi. さんごよみ <100文字> 編集

ああ、ダメかも知らんな……。details要素とsummary要素で作る折り畳み機能だと、span要素とかの内側には文法的に書けないので、安易に実装してしまうと本文中の装飾が崩れることになる。昔の言い方で言うところの「インライン要素の中にブロックレベル要素は書けない」という話だが。
まあ、自由装飾機能みたいに、デフォルトでは非表示にしておいて、「分かっている人だけONにしてくれ」という形態で実装しておく方法でも良いかもしれないけども。ただ、既に隠せる装飾機能が存在することを考えると、あえて(よく分かっていない状態で使うと他のデザインが崩れる可能性のある)機能を加える必要性もなさそうな気もする。

by nishishi. てがろぐ <375文字> 編集

やはり、「表示できる投稿が1件も見つかりませんでした。」とか「指定された番号の投稿は存在しません。」とか、表示できる内容がなかった場合には、HTTPステータスコードでも404を返すようにした方が良いんだろうな。(今は全部200)

by nishishi. てがろぐ <114文字> 編集

悪質なBot対策とか、攻撃を試そうとする不正アクセス対策とかで、何らかのエラーメッセージを返すときには、単にメッセージを表示するだけではなくて、200以外のHTTPステータスコードも返す。これは単にエラーページがキャッシュされたりしないように、という理由だけではなくて、Webサーバのアクセスログにエラーの発生事実が残るからでもある。HTTPステータスコードはログに記録されるので。自前でエラー発生の履歴を残そうとすると無駄な処理が増えてしまうが、Webサーバのアクセスログならどうせ問答無用で記録されるので、それに頼るのが最も消費リソースが少なくて済む。ただ、何でもかんでも 403 Forbidden とかを返してしまうと、「どの対策に引っかかったアクセスなのか?」が判別できない。Webサーバのログに記録されるのは、本当にHTTPステータスコードの番号だけでしかないから。そこで、対策内容によって「400 Bad Request」とか「429 Too Many Requests」とか、使えそうなHTTPステータスコードを使い分ける。……のだが、それでも足りなさそうな場合に、もっと何か使えそうなHTTPステータスコードはないか……と探すことになる。そこでふと思い出したのが、エイプリルフールジョークから作られた「418 I'm a teapot」。これは無害そうなので、識別のために使っても問題なさそうな気がする。……と思ってMDNの418 I'm a teapotページを見てみたら、一部のウェブサイトでは、自動化されたクエリなど、処理したくないリクエストに対してこのレスポンスを使用しています。と書いてあってちょっと笑った。みんな、考えることは同じなのか。

by nishishi. 開発ネタ <734文字> 編集

以下の3記法を新設した。(全部、[設定]→[補助出力]で設定できる値を表示する機能。「状況に応じた見出し」の出力用途くらいにしか使っていなかった。)
  • [[GALLERY:NAME]] :ギャラリーモードの名称を挿入
  • [[PICTS:NAME]] :画像一覧モードの名称を挿入
  • [[SITEMAP:NAME]] :サイトマップページモードの名称を挿入
要望を頂いて、そういえばその記法はなかったな、と気付いた。需要があるとは思っていなかった、というのもあるけども。広く需要があるのかどうかが分からないので、まあ検討リストに入れようかな、と一瞬思ったのだが、そもそも処理が極めて簡単だったので、何も考えずに実装した。

by nishishi. てがろぐ <310文字> 編集

てがろぐ「画像の管理」画面から、画像ファイルのタイムスタンプを変更できる機能の実装ができた。この機能を使って画像ファイルのタイムスタンプを修正することによって、間接的に画像の並び順(=画像一覧モードでの並び順や、新着投稿画像の並び順や、画像管理画面での並び順)を変更できる。

by nishishi. てがろぐ <137文字> 編集

今日は、てがろぐの開発をずいぶん進んだ。ただ、あまり表には見えない部分の実装だけども。いろんなURLに対して短期間に絨毯爆撃してくるBotがサーバ負荷を高めてしまう問題に対処するには、やはりサーバ側の機能に頼るのでは不足なので、てがろぐ自体に『同一IPアドレスからxx秒間にxx回以上の頻度でアクセスがあったら一定時間ほど「429 Too Many Requests」エラーを返す』という負荷軽減機能を用意した。
負荷軽減策なので、極力何も処理しないうち(データファイルを読み込むよりも前なのはもちろん、設定ファイルすら読み込まないうち)にアクセス制限を施す必要があるので、tegalog.cgi と同じ位置に blackcheck.ini という設定ファイルを置いた場合にだけ実行されるようにした。(※管理画面から設定できるようにすると、「設定ファイルを読み込んだ後」のタイミングでしか実行できない問題があるので。)
このファイルに例えば、
  • Duration=60
  • LimitFreq=10
というような記述があれば、『同一IPアドレスから60秒間に10回を超えるアクセスがあったら、次の60秒間は「429 Too Many Requests」エラーだけを返す』というような制限になる。
あくまでも「様々なURLに対して絨毯爆撃してくるBot」(≒毎秒数件みたいな超人頻度でアクセスしてくるBot)への対策が目的なので、「何の表示条件も限定されていないページ」に対しては無制限に閲覧を許可するし、RSSの閲覧も無制限に許可する仕様になっている。もちろん、管理画面へのアクセスも制限の対象外である。それ以外の「サブコンテンツ」のURLに対してだけ、アクセス頻度をチェックして制限を掛ける。要るかどうか分からないが、一応はホワイトリスト的に任意のIPアドレスを制限から除外できる仕様も用意はした。
この機能でしばらく運用してみて、サーバ負荷の高まり(の防御具合)を確認してみるとする。

by nishishi. てがろぐ <843文字> 編集

絨毯爆撃してくるBotによる負荷を軽減させるには、やはり「同一IPアドレスから30秒間に2回以上の頻度でアクセスがあったら一定時間ほど429を返す」みたいな処理が必要か……?

by nishishi. てがろぐ <87文字> 編集

7時間経っても復旧しないとかある……? うちのサイトが原因ではないよな……? と若干心配になるのだが。

by nishishi. <51文字> 編集

うーむ。5時間経っても復旧しないのか。まさか今日中には復旧できないとかそういうことはないよな……?

by nishishi. <49文字> 編集

しかし、メインのドメインを運用しているサーバが落ちると、メールも使えなくなるので困るな……。今日は日曜日なので元々届くメールが少ないのが幸いだが。仕事の連絡はまず来ないし。

by nishishi. <86文字> 編集

動作試験場(兼サポート場)が別サーバ(ここ)にあって良かった。とりあえず(気付かれるかどうかが分からない問題はあるが)アナウンスはできるので。

by nishishi. <71文字> 編集

メインサイトで使っているサーバの障害回復に結構な時間が掛かっている……。2時間以上落ちている障害は、もしかして、さくらインターネット利用歴24年間の中でも最長なのではないか。てがろぐ新バージョンをリリースした翌日だが、今日TegUp等でバージョンアップしようとしている人々に情報が伝わっているかどうか。せっかくメインの .com とサブの .org で2サイトあるのだし、てがろぐの管理画面には動作試験場へのリンクも設けておく方が良いかもしれない。アナウンスの場として。

by nishishi. てがろぐ <235文字> 編集

TegUpを置いている場合は、てがろぐ管理画面HOMEの「アップデートがあります」ボタンからTegUpに飛べる。現状では単に「TegUpにアクセスできるだけ」なので、TegUp上で1クリックが必要になる。それも省略できるようにして、てがろぐからTegUpへアクセスした場合には、ダイレクトにバージョンアップするようにしても良さそうな気もする。最新版の確認は、てがろぐ管理画面側で既にできているわけだし。

by nishishi. てがろぐ <201文字> 編集

details要素とsummary要素で作る折り畳み機能だと、隠されている範囲を表示させた直後に「あ、やっぱり読まなくていいわ」と思ったときに、スクロールもマウス移動も何もすることなく、同じ場所をもう1回クリック(タップ)するだけで閉じられる、というメリットがあるんだな。

by nishishi. <136文字> 編集

実装を検討している各機能について、どれくらいの需要があるのかの把握が難しい。アンケートを採るくらいしか手段がなさそうなのだが、アンケートを採っても(昨年の夏に採った)、この結果は「その時点での需要」でしかない上に、「それ以降に検討対象に加わった機能」については需要が分からない。もうちょっと何か、リアルタイムに需要を把握できるような仕組みを作れると望ましいのだが。そこでなんとなく思ったのは、(作りかけておきながら放置している)てがろぐユーザリンク集のアカウントに投票権を持たせて、検討中機能リストに投票できるようにする仕組みである。この方法を使って、
  • 検討中機能リストにある各機能に、それぞれ「欲しい」・「とても欲しい」みたいな回答(投票)ができる。
  • 検討中機能リストに項目を追加すると、その時点で投票項目が増える。
  • 投票内容(回答内容)は何度でも変更可能で、「以前は不要だと思っていたが今は欲しいと思うようになった」みたいな場合にはいつでも変更できる。
という感じにすれば、リアルタイムに需要の多寡を把握し続けられそうな気がする。もちろん、ユーザリンク集の利用者がそれなりに多ければの話だが。ユーザリンク集のアカウントを利用すれば、
  • 現役てがろぐ利用者に限定した投票ができる。
  • 1つの検討中機能に対して、同一人物が他票を投じるのをある程度は防げる。
というメリットもありそうなので、より正確なデータが得られそうな気もする。いや、協力者(投票者)がそれなりに居たら、の話だが。┌(:3」└)┐

by nishishi. てがろぐ,開発ネタ <655文字> 編集

鍵付き投稿で、「1行目を常に見せる」に加えて、「2行目も常に見せる」設定ができるようにする、設定機能だけはできた。(その結果を反映する本体機能はまだ。)

by nishishi. てがろぐ <76文字> 編集

JavaScriptで指定範囲を隠すのではなく、<details> <summary>見せる部分</summary> 折りたたむ部分</details> のような、HTMLだけでできる折り畳み機能も設けた方が良いような気もする。

by nishishi. てがろぐ <114文字> 編集

正式版リリース作業が面倒すぎる理由の1つは、たぶん間に挟むβ版が多すぎるんだよな……。追加機能がたくさんあるから、リリースノートを書くのも大変になる。もっと、「正式版→β1→β2→正式版」くらいのペースでリリースする方が楽なのかもしれない。

by nishishi. 開発ネタ <120文字> 編集

ああ、TegUpどうしようかな……。そこも整備してから次の(てがろぐ)正式版を出そうとするとさらに時間が掛かりそうだけど。今回はとりあえずTegUpの同梱はやめて、次に回すか……?

by nishishi. てがろぐ <90文字> 編集

TegUpもそろそろ Ver.1 としてパッケージに同梱したいのだが、そのためには公式ドキュメントを(てがろぐ公式ドキュメント内に)設けた方が良いよな……。

by nishishi. てがろぐ <78文字> 編集

結局、[[PERMAURL:KEEPCOND]][[PERMAURL:KEEPCOND:FULL]] の2つの記法を実装した。CONDはCONDITIONの略。>>2490

by nishishi. てがろぐ <89文字> 編集

[[PERMAURL:KEEPCOND]] みたいな専用記法を追加するよりも、[[KEEPCOND]] みたいな記法を追加して、[[PERMAURL]] と組み合わせて使ってもらう方が便利なのではないか。もしかして。

by nishishi. てがろぐ <108文字> 編集

てがろぐCGIで、パラメータ ?mode=around3&postid=123 で、No.123の前後3件の最大7投稿を閲覧できる機能はできた。パラメータを例えば around4 にすれば前後4件ずつの最大9投稿を閲覧できる。投稿単独表示時のURLの末尾に &mode=aroundを加えれば良い。とはいえ、自力でパラメータを加えるのは面倒なので、ユーティリティリンク枠にリンクを追加しておく方が良いか。(もちろん、設定で表示/非表示を選択できるようにする。)

by nishishi. てがろぐ <230文字> 編集

何か作るときには、「何のツールなのか」という点を決めるのは当たり前だが、「何ではないのか」もしっかり押さえておく必要がある。「これは○○ではない(のでそういう機能は加えない)」というような。そうしないと、同種の既存ツールに寄ってしまいがちなのだが、そうすると存在する意味が薄れてしまう上に、開発の手間も増えてしまって、気力の維持が難しくなるので。そこは避けないといけない。

by nishishi. 開発ネタ <186文字> 編集

パラメータ ?around=123 とかで、No.123 の前後5件ずつくらいの計11投稿を閲覧できるような機能が欲しい。で、そのリンクは投稿単独表示時にユーティリティリンク枠に表示される感じで。

by nishishi. てがろぐ <98文字> 編集

国立国会図書館サーチのAPIを使うと書影データは手に入るのか。これで蔵書管理スクリプトを自作すればいいか……? 何をいつ読んだか、という情報だけでなくて、「その本がどの電子書籍リーダーに入っているのか」の情報を記録しておきたい。そうしないと読み返そうとしたときに探すのが大変なので。

by nishishi. 開発ネタ <141文字> 編集

てがろぐ側の画像表示機能がかなり「行き当たりばったり」的な開発だったので、内側スキンで画像の表示をどうにかしたい場合のカスタマイズ自由度に制限があった反省から、いろいろ細かく情報を得られる記法を用意してみた。需要があるかどうかはともかく。

とはいえ、簡単に書ける記法もある方が望ましいので、単に [[ONEFILE]] みたいに書けば、そこに当該ファイル(画像なら画像、動画なら動画、サムネイルがあるならサムネイル)の表示用HTMLが出てくる。しかし、細かく表示用HTMLを自力で(スキン側で)組み立てたい場合とか、CSSでの装飾のためにclass名を用意しておきたい場合とかには、以下のような記法が使える。

※例えば、300×200pxでNSFWフラグ付きの画像 ./images/sample.png の場合、
  • [[FILE:TYPE]] で種類の大分類: IMG
  • [[FILE:NAME]] でファイル名: sample.png
  • [[FILE:PATH]] でパス全体: ./images/sample.png
  • [[FILE:EXT]] で拡張子だけ: png
  • [[FILE:BASE]] でベース名だけ: sample
  • [[CAPTION]] でキャプション: サンプル画像
  • [[FLAGS]] でフラグ: nsfw
  • [[IMAGE:WIDTH]] で横幅: 300
  • [[IMAGE:HEIGHT]] で高さ: 200
  • [[IMAGE:SIZEATT]] でHTML用属性: width="300" height="200"
今の時点でそう実装してみた、というだけなので、変更する可能性はあるが。
種類の大分類とか、拡張子だけとか、ベース名だけとかを得る記法は、それをclass名に使えば「その条件に該当する画像(とか)」をCSSで一括して装飾する際に活用できる。

by nishishi. 製作中ツール <792文字> 編集

サブフォルダも一覧に表示する場合、(共通のフォルダアイコン画像ではなく)それぞれのフォルダごとに画像を用意しようと思えばできる仕様に実装できた。めでたい。

例えば、
  • 画像の場合、オリジナルファイルが sample.jpg なら、サムネイル画像は ./mini/sample.jpg が(あれば)使われる。
  • 動画の場合、オリジナルファイルが yomple.mp4 なら、サムネイル画像は ./mini/yomple.*** が(あれば)使われる。
  • サブフォルダの場合、そのPATHが ./gopple なら、それ用のサムネイル画像は ./mini/gopple.*** が(あれば)使われる。
……という仕様にできた。なので、「そのフォルダ用のアイコン」的に使いたい画像は、サムネイル画像として用意すれば表示に使われる。

※「***」の部分は、png、jpg、gif、webp のどれか。(この順で走査して最初に見つかったものを採用する。)

by nishishi. 製作中ツール <425文字> 編集

てがろぐのメリットの1つがたぶんスキンの自由度だと思うので、スキンの自由度は同じレベルになるようにする。

by nishishi. 製作中ツール <52文字> 編集

今のところ、ソースコードは1,052行ほど書いているのだが、まだ先は長い。>>2480,2477/R

by nishishi. 製作中ツール <50文字> 編集

絵に描いた餅に終わらないように。

by nishishi. 製作中ツール <16文字> 編集

今、開発中の画像等ファイル展示PHP >>2477 だが、掲載順序をパラメータで指定できるようにした。デフォルトではタイムスタンプの新しい順に並ぶが、パラメータに
  • ?sort=time&order=reverse が指定されたら、タイムスタンプ古い順でソートして並べる。
  • ?sort=cap が指定されたら、キャプション文字昇順(ABC…)でソートして並べる。
  • ?sort=cap&order=reverse が指定されたら、キャプション文字降順(ZYX…)でソートして並べる。
  • ?sort=size が指定されたら、ファイルサイズ大きい順にソートして並べる。
  • ?sort=size&order=reverse が指定されたら、ファイルサイズ小さい順にソートして並べる。
  • ?sort=name が指定されたら、ファイル名昇順(ABC…)でソートして並べる。
  • ?sort=name&order=reverse が指定されたら、ファイル名降順(ZYX…)でソートして並べる。
……というような感じの指定ができる。

ファイル名やキャプション文字を使ってソートすることもできるので、事実上、自分の好きな順序で画像を並べて掲載することもできるだろう。ファイル名やキャプション文字を工夫すれば。(登録できる情報なら何でもソートキーに使えるようにするつもりなので、キャプション以外にコメント等も登録可能になれば、そのコメントの文字を使ってソートすることもできる。ただ、最初のリリース時点でそこまで作るかどうかは今の時点ではまだ分からない。)

ソートに使うキーをパラメータで指定できるので、複数の並べ方を共存させられる点が、何かちょっとメリットになりそうな気がする。「標準では新着画像の順に並ぶ」が、別途「ファイル名順に並べるリンクも設けておいて、望みの順序で表示するモードとして使う」とか。

主に画像を並べる用途を想定しているが、画像・動画・その他のファイルを並べることもできる。サブディレクトリの存在も認識するので、ファイラーっぽい感じの表示もできるハズ。(サブディレクトリへのリンクは、画像等と並べて同時に表示することもできるし、表示しないでおくこともできる。設定次第で。)

キャプション等を保持するデータファイルは、てがろぐCGIの画像インデックスファイル(index.xml)と互換性を持たせたので、てがろぐCGIの画像保存用ディレクトリを表示対象に設定して、てがろぐと組み合わせて使うこともできるような気がする。たぶん。

このツール上でファイルをアップロードすることもできるが(※まだそこまでは作れていないのだが)、FTP等の別手段でUPされたファイルもすべて認識する。キャプション等の情報はWeb上で1つ1つ登録することもできるが、データファイルはXMLなので、(FTPで一気に大量UPしたファイル群に対するキャプションは)XMLファイルを直接編集すると一気に登録できて楽かもしれない。

by nishishi. 製作中ツール <1257文字> 編集

WAFによる警告を回避して投稿できるように、フレーズの置き換え機能を用意したら良いのかもしれない。例えば「 @UPUP@ 」と打ったら内部では「 ../../ 」に変換されて解釈されるとか。「 @ETC@ 」と打ったら内部では「 /etc/ 」に変換されて解釈されるとか。「@」記号で挟まれる文字列は、利用者が自由に登録できるようにしたら、好きなように作れて良いのではないか。ショートコードみたいに使う方法もあるかもしれない。

by nishishi. てがろぐ <213文字> 編集

次のてがろぐ正式版からは、TegUp も同梱するようにしたい。

by nishishi. てがろぐ <31文字> 編集

不特定多数の人間で共用する、画像中心のファイル共有Webを用意する必要が出てきたので、何かそれっぽいツールを開発したい。2月中に。てがろぐのギャラリーモードでは機能的に適当ではないので。
必須の機能はだいたい以下のような感じ。
  • スキン式(てがろぐのようにスキンファイルでデザインを自由にできる)
  • 🔵指定ディレクトリ内に存在する画像ファイル等をすべて認識して表示できる(=このツールを経由せずにFTP等で別途UPしたファイルもすべて認識する)。
  • 🔵サブディレクトリも認識する。
  • 画像を投稿するのが基本だが、PDFとかZIPとか(あらかじめ許可しておいた)任意の形式のファイルも投稿できる。
  • 画像サムネイル(またはファイルアイコン)を並べて表示したり、リストで表示したり、複数の表示形態を併用できる(=複数のスキンを併用できる)。
  • キャプション(タイトル)を付けられる。
  • ハッシュタグで分類できる。
  • サムネイルを自動生成する(投稿時に)。 ※GDライブラリで扱える形式だけ。
  • サムネイル用画像を別途指定もできる。
  • PDFとかZIPとかの画像以外のファイルでは、サムネイルを指定しなければ、デフォルトの分類画像(アイコン)で表示する。
  • 画像(or任意ファイル)1つだけを単独で表示する個別ページも生成できる。
  • ログインしていなくても誰でも投稿できる。(この機能をOFFにすれば、自分専用の画展ツールになる)
  • 非ログイン者が自分の投稿ファイルを削除できるように、投稿時に「削除用パスワード」を設定しておける。
  • 投稿者名も併せて投稿できる。(非ログイン者用)
  • 投稿可能なファイルサイズの上限を指定できる。キャプション等の文字数上限も。
  • 投稿年月日で区切って表示できる。(てがろぐの「日付境界バー」みたいな区切りを自動挿入できる)
  • ページ内に投稿欄を表示できる。(てがろぐのQUICKPOSTみたいな。)

そのほか、あると望ましいが必須ではなさそうな機能は、以下のような感じ。
  • キャプションとは別に、短いコメントも付けられる。(プレーンテキスト)
  • ログインしていれば投稿者を認識して投稿・編集・削除できる。
  • 既にUPされている画像(or任意ファイル)の差し替えができる。
  • ハッシュタグの一覧を表示できる。
  • NSFW等のフラグを付けられる。
  • 検索できる(ファイル名、キャプション、コメント、ディレクトリ名、ファイル種類、投稿者、日付で)。
  • 新着順以外に並べ替えができる。(ファイル名のアルファベット順とか)
  • OGP(+Twitter Card)を出力できる。
  • RSSフィードを出力できる。
  • ファイルのタイムスタンプとは別に「投稿日時」を保持しておける。(手動で投稿日時を編集できるように。)

さらに、あったら便利だろうと思う(最初には作らないが、将来的に作ることを想定しておく)機能は、以下のような感じ。
  • カテゴリで分類できる。+カテゴリの一覧を表示できる。
  • サブディレクトリがある場合は、投稿時にアップロード先ディレクトリを選択できる。
  • 離れた位置にあるディレクトリも対象にできる。
  • 一覧から、複数ファイルの一括削除ができる。
  • サムネイルが生成されていない画像(FTP等でUPされたとか)のサムネイルを一括生成できる。
  • コメントの文字を装飾可能にする。
  • 複数画像の連結表示ができる。(並び順も指定できると良い)
  • NGワードを登録しておける。
  • ダウンロード数(閲覧数)を記録できる。
  • 鍵付きにできる。(アクセス制限された専用ディレクトリにUPしておいて、プログラム側が毎回バイナリを読み込んでダウンロードさせることで、直アクセスを不可にする。)
  • ユーザIDに、名前だけでなくアイコンや紹介文等の付加情報を登録できる。

キャプション等を記録するデータファイルは、てがろぐ画像保存用ディレクトリで使っている index.xml と互換性があると便利かもしれない。

問題は、企画倒れにならないようにモチベーションを維持して開発できるかどうかだ。(何らかのツールが必要なのは間違いないのだが。現状では、2000年代に開発されたファイル共有CGIが稼働しているので最低限の中の最低限くらいのことは実現できているので。絶対的に何が何でも開発が必要というわけではないので、モチベーションの維持材料が何かもうちょっと要るかもしれない。)

by nishishi. 製作中ツール <1829文字> 編集

ログインしていない限り全部見えなくする「完全プライベートモード」的な動作も、そんなに手間を掛けずに実装できそうな気がしてきたので、実装しようかな……。
主に「自分(または仲間内)専用の空間にする」という用途だけども、同時に「ゲスト権限(Lv.1)での投稿を禁止する」という設定も可能にすると、「読めるだけのユーザID」を用意することもできそうな気もする。その場合、事実上「すべての投稿を(共通)鍵付きにする」のと同じ効果にできそうな。(そういう要望もあった気がする。)

by nishishi. てがろぐ <234文字> 編集

自前の静的サイトジェネレータを作るとしても、時間(と気力)が確保できそうなのは早くても3月か4月頃になりそうな気がする。気温が春になってからだな……。_(:3」z)_ ざっくり、1月は寒くて気力が減退気味だし他の用事もあるし、2月は税金で忙しいし、3月は別件でちょっと忙しい可能性があるので。ただ、3月の別件は、3月に始めたのではやや遅いので2月中には始めないといけないのだが。なので早ければ3月には予定が空く可能性はあるのだけども。もちろん、仕事の入り具合にも依って異なるけども。

by nishishi. <241文字> 編集

てがろぐで、最新の1投稿だけを別ページに埋め込みたい場合、今は「埋め込み用のスキンを作ってSSIやPHPで合成する」とか「RSSを読んで整形して合成する」とか何かそういう感じの方法しかないので、何にしても「最新の1件を出力するために、てがろぐCGIが動作する」という背景は避けられない。なので、『最新の1件だけを指定のスキンを適用して出力した結果を、静的なHTMLとして出力しておく』という動作をする「埋め込みモード」みたいなのを用意できれば、埋め込むためだけにCGIを稼働させずに済むので、埋め込み先ページの速度向上(というか速度低下の防止)に役立つ気がする。もちろん、サーバの負荷軽減にもなる。埋め込み先ページはたいていHOMEみたいな「アクセス頻度の高いページ」だろうから。

by nishishi. てがろぐ <340文字> 編集

ようやく申請が通った。20分弱くらいだ。予想よりは早かった。数時間は待たねばならないのかと思っていた。

by nishishi. <51文字> 編集

私のネット環境では、既にこのドメインは新サーバに繋がっているのだが、まだSSLの申請ができない……。(ので、HTTPSでアクセスするとセキュリティ警告が出る。)

by nishishi. <80文字> 編集

《ここは移転先の新サーバ》

by nishishi. <13文字> 編集

今は、ChatGPTとかのAIによる補助が得られるから、もっと速度UPできそうな気はする。

by nishishi. 開発ネタ <45文字> 編集

自分が最低限欲しいと思える機能を実装した静的サイトジェネレータを作るのに、もし(ほぼ)その開発だけに集中できるとしたら、どれくらいの期間で出来上がるだろうかな……? てがろぐを最初に開発しようと思ってからVer.1をリリースできるまでに4~5ヶ月くらい掛かっていたような気がする。夏から作り始めて12月リリースだったような。(その期間は、開発だけに専従していたわけではなく、日常業務の合間に進んでいたわけだが。)

by nishishi. 開発ネタ <206文字> 編集

Powered by てがろぐ Ver 4.4.2.

DASHBOARD

■開発放言について

にしし製CGIの開発進行に関する放言です。思いついたことを適当に放り込む空間なので、どんな呟きも確定的な開発予定というわけでは全くありません。しかしながら、機能面でのご要望や開発予定機能への支持表明はお気軽にどうぞ。ただし、ここには直接は投稿頂けませんので、公式動作テスト用てがろぐ等をご利用下さい。

編集

■全文検索:

■日付検索:

■カレンダー:

2024年9月
1234567
891011121314
15161718192021
22232425262728
2930

■ハッシュタグ:

▼現在の表示条件での投稿総数:

568件

▼最後に投稿または編集した日時:

2024年09月02日(月) 21:32:53