にしし らぼらとりー

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

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

RSS Feed

開発放言 カテゴリ「開発ネタ」に属する投稿[24件]

新規投稿 / 管理用

悪質な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文字> 編集

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

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

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

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

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

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

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

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

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

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

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

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

1月を丸々開発月間に充てて、自前の静的サイトジェネレータを作ろうかな……。

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

カレンダー表示ツールとしては「さんごよみ」を用意しているが、スケジュール表示が基本のツールなので、もっとシンプルに「指定した日付に丸を付けられれば良い」というだけの場合には多機能すぎる面があると分かった。もっともっとシンプルなUIで、カレンダーの日付をクリックしたらその場でそこに指定色の丸印が付く、というだけしか機能がないくらいの、ミニマムなCGI(PHP)を作りたい。

by nishishi. さんごよみ,開発ネタ <186文字> 編集

WordPressを使うのをやめて、自前の軽量なCMSをPHPで作りたい。
コンテンツ自体は動的に出力するのではなくて、投稿された時点で静的ファイル(.shtml)に書き出しておいて、ヘッダやフッタ等の固定パーツはSSIで合成するようにすると、閲覧時の負荷が軽くて良さそうな気がする。コンテンツ部分は自力でHTMLソースを書けばそれだけで充分なので、WYSIWYG編集機能は一切要らない。手動で書いたコンテンツ(HTML)を、カテゴリ分けしたり全文検索したり目次を生成したりする機能くらいがあればいい。閲覧数の多い記事をカテゴリ別にリストアップする機能とか、関連する記事を適宜簡単にリストアップして設定できる機能とかもあると良いが。RSSを配信する機能も要るな。

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

汎用のアップローダーCGIを作りたい。設置すると、指定のディレクトリにファイルをアップロードできる感じで。アップロード先ディレクトリは、あらかじめ設定しておけば複数のディレクトリを扱えるようにすると便利な気がする。同種のCGIなりPHPなりは多数あると思うのだが(クローズドな某所に1つ設置して共用しているのだが)、なかなか自分の思ったとおりの機能ではないので、自分で作る方が望み通りになって良いよなと。てがろぐソースを流用して、スキン式にしたい。というか、スキン式にしないと望みのデザインで運用できないので。あとは、複数アカウントで「誰がUPしたのか」を区別できるようにしても良いかもしれない。基本的にはファイル一覧がずらっと表(テーブル)に出てくるだけの機能を考えているが、どうせなら画像だけはアルバム表示(タイル状にプレビュー表示するとか)しようと思えば(スキンで)できるようにしても良いかもしれない。ついでに。ただ、その機能は個人的にはそこまで欲していないので、作るとしても後回しかもしれないが。ファイルには説明文を付けられるようにしたいので、その仕様を流用すれば「キャプション付き画像」の表示にも使えそうだな、という気はする。

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

cronが使えないレンタルサーバ向けに、疑似的なcronを提供するCGIを用意すると便利かもしれない。cronは指定した時刻に指定したプログラムを実行する機能だが、cronが使えない場合はその「指定した時刻」に自動実行させる手段がない。しかし、例えば「ダミー画像を表示してから、現在時刻を確認して、指定時刻が過ぎていたら指定プログラムを実行するCGI」みたいなのを用意しておけば、その画像をWebページに埋め込んでおくだけで、誰かのWebへのアクセスとかをトリガーにしてcronっぽい機能が実現できる。もちろん、滅多にアクセスがないようなWebサイトだったら難しいが。……もう既にありそうだな。その手のCGIは。

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

定期的にサーバ内の全ファイルをZIPに圧縮して自動でメール送信するプログラム(CGIやPHP)があれば良いのかもしれない。自動バックアップ。cronが使えるサーバなら本当に定期起動が可能だが、そうでなくても、適当なテキストなり画像なりを出力する機能を用意しておいて、それをトップページとかに埋め込んでおけば、誰かがアクセスしたときをトリガーにして起動はできるので、前回からの経過日数を計算して処理するようなことはできるだろう。

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

スキン式のメッセージ送信システムをPHPで作りたい。メール送信フォームをスキンで用意できるもの。スキンを複数用意しておけば、複数箇所のメッセージ送信を1つのPHPで扱えるような。入力欄の個数とかもスキン側で自由にできるので単なるメール送信フォーム以外にもコンタクトフォームとかアンケートフォームとかにも使えなくもない感じの。メール不達に備えて一定期間はメッセージ本文を管理画面から再確認できる機能もあると良い。

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

ローカル実験環境でも、これもまたPHPの方が遙かに簡単で、PHPがインストールされているなら、コマンドラインから php -S 127.1.1.2:8080 -t D:\Web のように打ってやるだけで、PHP内蔵のWebサーバが起動するので、ブラウザで http://127.1.1.2:8080/hogehoge.php にアクセスするだけで D:\Web\hogehoge.php に存在するPHPファイルがローカルで確認できる。ただ、これはPHP専用のWebサーバなので、ノーマルなHTMLとかは一切表示してくれないが。
20221201095209-nishishi.png
終わらせるときは、[Ctrl]+[c]を押す。いちいちコマンドを打つのは面倒なので、バッチファイルを作っておいてデスクトップ等にショートカットを置いておくと楽だ。

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

昔から、FAQを構築できるCGIを作りたいと思うことが何度かあったのだが、てがろぐでFAQスキンみたいなのを作れば、検索もできるしカテゴリ分けもできるしそれで済むのではないか、という気もしてきた。ただ、FAQのHomeページをどうにかして生成する必要がある。FAQ用のHomeページというと「カテゴリ別にFAQタイトルが並ぶ」という形態が定番だし分かりやすいと思うので、そんな感じのHomeを自動生成できると望ましいのだが。現状の機能だと無理だ。いや、「カテゴリ別に新着タイトルを出力する」ことはできるので、それらをSSIとかで組み合わせて1つのページにするHTMLを用意すればHomeとして機能はするとは思うけども。それだと、カテゴリを追加したときに手動修正が必要になるので運用がちょっと面倒だし、なにより配布するには向いていないだろう(別に配布しなくても良いが、どうせ作る労力を掛けるなら配布できるようにもしたい)。なんかそういう「すべてのカテゴリについて、カテゴリ別に分けつつ、各カテゴリに属する投稿タイトルだけを並べる」みたいな自動生成機能が欲しい。「カテゴリ別タイトル掲載機能」とでも呼ぶか。「カテゴリ別の新着投稿リスト出力機能」だとそれなりに需要はあるかもしれないが、FAQの場合は新着かどうかよりも自ら掲載項目を選択できる方が望ましい気もする。まあ、並べたい順に投稿日時を手動で修正する手はあるが。「下げる」機能を使って、「下げられていない投稿だけがリストアップされる」みたいな感じにすれば良いかもしれない。

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

Markdown記法ってクライアントでパースできるのか。全然知らなかった。
ググったところ、markdown-itだとスクリプト本体は100KBしかなくて、CDNで配信されているようなので、ユーザ側には何の追加設置も求めることなく、単に読み込むだけでMarkdown記法が使えるようになるのだろうか……。
そんな簡単だったの……?
スクリプトを読み込んだ後、
var md = window.markdownit();
var result = md.render( マークダウンで書かれた文字列 );

とかやれば良いっぽい。
Markdownって100KB程度のJavaScriptでどうにかなるものだったのか……。

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

たしかに、「アスキーモードでの転送」でうまくいくのは、「FTPソフトに設定された『サーバ側の改行コード』」が正しい場合に限るわな。……と思ったのだが、もしかしてFFFTPに『サーバ側の改行コード』を設定する機能って存在しない……? なんかあったような気がしていたのだが。問答無用でLFに揃える機能だったっけ? 「改行コードがLFだと動かない」ようなサーバを見たことがないので、改行コードは全部LFなら良いのではないかという気はする(なので、てがろぐ3.0.0からは改行コードがLFだけになっている)。ただ、Windows環境でソースを編集すると一部に[CR+LF]が混入する可能性はあって、そこを防ぎにくい。設定を全部 config.pl とかに分離しても良いのだが、そうしても1行目の #! /usr/bin/env perl を修正する必要(がある可能性)は残るからな……。

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

サーバ上では Perl 5.8.9 と 5.14.4 で動作確認していて、ローカルでは Perl 5.32.0 で動かしながら開発しているので、Perlのバージョン違いで動いたり動かなかったりという可能性はあまりないと思っているのだが。(最新のPerlは 5.36.0らしいのでそれでは確認できていないけども。)なお、Perl 5.6以上でしか使えない機能を使っているので、Perl 5.6未満だと動かないのは間違いない。ただ、もはやPerl 5.6(2000年5月22日リリース)未満が稼働しているレンタルサーバはないと言って良いのではないかとは思っている。

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

もし今Web拍手系のフリーCGIを開発するとしたら、スパム対策機能が必須だよな……。ただ、自由に入力された文章からそれがスパムかどうかを判定する処理を自力で書くのは困難なので(外部に何かそういうのを判定してくれるライブラリとかがあってそれを使えれば良いけども)、自由文の入力は不可に設定できて、「あらかじめリストアップされた絵文字だけ」とか「あらかじめリストアップされた短文だけ」とかから選択できるようにできるとか、くらいか。最初の拍手は、連打可能にする方が需要があるっぽいので、総数だけでなく「連打なのか単発なのか」を把握できる仕様もあると良いのかも知れない。

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

過去に書いたページからリンクしているウェブサイトがとっくに閉鎖されていることがよくある。閉鎖されているだけならまだ良いのだが、そのドメインが他人に取得されていて、まったく異なるウェブサイトに変化していることもよくある。ただの個人サイトとか別企業のサイトとかならまだマシなのだが、いかがわしい広告サイト(というかアダルトサイト)になっていることもある。長くウェブを運営するつもりの場合、直接相手サイトにリンクを張ってしまうのもリスクがあるのだな……と気付いた。少々面倒だが、他サイトへリンクする際には何らかのクッションを挟んでおく方がメンテナンスしやすくて望ましそうだ。過去に作ったCGIに短縮URLを生成するCGIがあるのだが、外部サイトへのリンクには必ずこのCGIを挟んでおくことにして、リンク先がNot Foundとかになった場合には、管理者に通知が届くような機能を加えておくとか。そうすると、外部サイトの閉鎖に気付きやすくなるメリットがありそうな気はする。同一URLに対しては必ず同じ短縮文字列が生成される仕組みにしておけば、自サイト内の様々な場所にリンクが散らばっていたとしても、CGIのデータ1つを修正するだけでリンク先を変更できるメリットもある。

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

不特定多数のユーザが、投稿時に毎回自分の名前も入力するタイプの(つまりよくある普通の)掲示板を用意したいのだが、てがろぐCGIのソースを流用する形で「新たなCGI」として作るか、てがろぐCGIそのものの仕様を拡張してそういう掲示板用途としても使えるようにするか、ちょっと迷う。前者は作るのが面倒くさいが、出来上がったら「掲示板CGI」としてリリースできるので分かりやすい気がする。後者は、そもそも「普通の掲示板として利用する選択肢もある」という事実がたぶん伝わりにくい(デフォルト設定ではそうはならない)ので、作ったところで掲示板としては活用されない問題がありそうな気がする。自分で使うだけならそれでも良いのだが、それだと開発モチベーションが維持しにくい。あと、そもそも後者だと仕様が複雑になりすぎて実装が大変な可能性もありそうな気がする。掲示板CGIは世の中にたくさんあるので、あえて自分で作らんでも良い……という気もしないではないのだが。

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

てがろぐCGIにTwitterのようなアンケート機能を直接載せるのはたぶん現実的ではないが、独立したアンケート機能CGIを作って、iframeで合成しやすい形状に出力できる仕様にして、てがろぐCGI側に埋め込めるようにすれば、似たようなことはできるかもしれない。その場合、てがろぐ以外の場所に埋め込むこともできるし、アンケートCGI単独で使うこともできるので、もしかしたら便利に活用できる可能性もありそうな気もしないでもない。

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

いいねボタンにもなるWeb拍手CGIを作りたい気もしている。単にボタンを押すだけのシンプル運用にもできるけども、ボタン押下後にコメントの投稿を可能にもできるし、ボタンの連打を許可する設定にもできる……みたいな、カスタマイズ性の高いCGIを用意して、これ1つあれば「いいね」機能にもWeb拍手機能にもなる、というような感じの。idを分ければ同一ページ内にいくつでも掲載できるような。拍手機能をてがろぐに載せるのはちょっと機能が異なりすぎると思うので、独立した汎用的なCGIを用意する方が良い気がする。独立した汎用的なCGIなら、てがろぐを使わない箇所でも使えるし。ボタンは「いいね」・「超いいね」・「おにぎり」・「すいか」・「ドーナツ」とか好きなだけボタンを並べておけるようにすると、なお良いかもしれない。てがろぐのカテゴリ編集機能あたりのソースを流用して、いくつでも好きなだけ登録できるようにしておくと良さそうな気がする。もちろん、ボタン1種類だけで運営したいならそうすれば良い。 →doさんの「いいねボタン改」が良さげだ。

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

Powered by てがろぐ Ver 4.5.7.

DASHBOARD

■開発放言について

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

編集

■全文検索:

■日付検索:

■カレンダー:

2024年7月
123456
78910111213
14151617181920
21222324252627
28293031

■ハッシュタグ:

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

24件

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

2025年04月18日(金) 11:30:15