らぼらとりーにしし(西村文宏)製スクリプトの公開開発実験場(ラボラトリー)です。各種スクリプトの最新版やβ版の動作確認ができます。バグ報告や、機能面でのご要望などもお気軽にお知らせ下さい。各種ダウンロード※当ウェブサイトは、にしし製フリーCGIなどの動作確認サンプルを公開したり、製作進行に関する呟きを掲載している実験場のようなものです。ふぁくとりー」へお越し下さい。(╹◡╹)ノにしし@Pawoo開発状況に関する情報だけを知りたい場合には、Pawooのアカウントもどうぞ。今のところ、フリーCGIのリリース情報(正式版・β版とも)をつぶやく専用アカウントっぽい感じの運用になっています。しし@TwitterTwitterアカウントもありますのでお気軽にフォロー下さい。だいたい日々の駄文をつぶやいておりますが、開発状況とか新しいUIの画像とかをツイートしていることもあります。ししのメインSNSはこれです。管理用にししNo.227816進数での色指定を本文に書くとハッシュタグとして認識されてしまう問題の回避方法は、5文字書く方法で良ければ存在はする。できれば、HTMLの色指定に該当する場合だけハッシュタグだとは認識しないようにできると良いのだが、それを正規表現1つで表現する方法が思いつかないので、実現できないでいる。3文字または6文字続く場合だけは除く』みたいな。正規表現をめちゃくちゃ使いこなしている人だと編み出せるのかもしれないが......。編集にししNo.2277サーバのシェルにログインできるなら、シンボリックリンクを作れば複数のてがろぐで同じスキンを共有できるだろうけども。セキュリティの都合上、CGIが存在しているディレクトリよりも上位(浅い)階層のディレクトリにあるファイルを参照することはできません。この方法で、サーバ内の(何か漏れるとマズい)ファイルが参照されたところで、それはスキンとしては機能しないのだから「スキンがないよ」と表示されて終わりなので、特に問題ない気がする。skinパラメータで、相対パスを使って上位ディレクトリを参照できれば、「複数のてがろぐで同じスキンを使う」ということができるので、てがろぐを複数個設置している場合でもデザインの共有が楽になりそうではないか。......そうでもないか。skinパラメータだと、一時適用にしかならないものな......。編集にししNo.2274そもそも、次に実装する予定の(画像キャプションとかをあらかじめ登録しておけるようにするための)画像インデックス生成機能を本当に作れるのか、という気もする。なんかもうちょっと機能(仕様)候補を列挙して、欲しいか欲しくないか、その仕様で良いか良くないか、みたいなのをアンケート取ってから計画した方が良いのかもしれないな、という気もしないでもない。編集にししNo.2273自分がてがろぐを画像掲載用途には使っていないので、なかなか画像周りの良さげな仕様を思いつかない問題はある。画像に自由なclass名を付けたいという要望を昔々に受けたことがあって、それを元にもっと汎用的な「自由装飾記法」を作ったわけだが、ギャラリーモードのことは考慮していなかった。いや、ギャラリーモードでも(スキンの作り方は普通のスキンと同じなので)スキンの作り方次第ではあるのだけども。画像掲載用途に使っていて、「こんなことはできんのかー?」と思う場合には、私のところに届くように要望をお知らせ頂かないと(私自身が画像掲載用途に使っていないので)理想的な方向には行かない(行けない)気がする。時々、ずいぶん前にツイートされた「こんな機能があったらいいのにな」的な要望の呟きを偶然目撃することがあるのだが、その度に「それ、私に、知らせてくれなきゃ......!」と思う。して配布しても良いかな......という感じのところまで来た気がする。編集にししNo.2270おおぅ。すごいバグを見つけた。Errorになる不具合を見つけた。修正しない限り復帰できない気がする。試さないでね......。原因は究明したのでローカルのソースは修正した。比較的新しいバージョンでしかこの問題は発生しない。これ、自分で見つけたから良かったが、ユーザさんからこの現象を指摘されても原因を突き止めるのは難しいだろうなあ。いうのは「デフォルトのままで何もしなくて良い」と考えて問題ないと思う。しさえすれば、あとは全部デフォルトのままでも問題ない気もする。違いがあるのかどうかがよく分からん。なってくれそうな気がするのだが(suEXECだと)そういうわけではなさそうだし。してあるので、パーミッションが見えるような値になっていても特に問題はないが。確実に安全なのは、Webからアクセスできないディレクトリに置くことだとは思うけども。使ってアクセスを拒否しておくとなお安心かもしれない。(.htaccessでのアクセス拒否は、Webからのアクセスを拒否するだけなので、サーバ上にあるプログラムからはアクセスできるので拒否しても問題ない。含まれているとリンクにならない仕様をどうにかしたい。登場した時点でそこが「リンクラベルの終わり」だと認識する仕様なので、どうしようもない気もしないでもないが......。単純に考えれば、「\」でエスケープすれば良い仕様にすれば良い気もするけども。編集にししNo.2265画像投稿関連の機能についてだけを言うと、まず「サムネイル用画像があったらサムネイル側を先に表示する」機能は既に実装したので次のバージョンで提供できる。(※注意:サムネイル画像は自動生成ではないので、自らサムネイル用画像を作る必要がある。その点はむしろ『自分の納得のいく画質のサムネイルにできる』とか『自分が望む通りのトリミングができる』とか『クッション用画像に差し替えられる』とか、自動生成ではないことのメリットもあるとは思うので、必ずしもデメリット(機能不足)だとは考えていない。)ただ、現状ではサムネイル画像をアップロードする機能がないので、FTP等の別手段が必要だ。それで良いと思っているわけではないので、将来的には「サムネイル用ディレクトリに画像をUPする機能」も作る予定ではいる。●OG:image用の画像を「本文のテキスト」で動的に生成したい場合(=テキストの画像化ツールへ本文の冒頭文字列を送りたい場合)のために、本文テキストを任意のパラメータ付きでog:imageに加えられる機能......のようなToDoリストっぽいものがある。上の方は「計画」だが、下の方は「なんとなくの予定」みたいな感じで、下の方へ行くほど需要を感じなければどんどん先送りする感じである。どれも一気には提供できないので、1つずつ作ることになる。一気に提供できないかというと、理由は主に2つある。一気に複数の機能を実装すると、もしトラブルが起きたときの原因究明が難しくなるのでその後の開発が行き詰まる。あれもこれもと盛りすぎると、モチベーションの維持が難しくなって企画倒れになる危険性がとても高くなる。1も重要だが、何よりも2の方が極めて重大な実際の問題である。過去20年くらい、『作りかけたまま放置して未完成のまま日の目を見ることのなかったフリーソフトやフリーCGI』が多々あるが、そのどれもが「機能を盛りすぎて完成までのモチベーションが維持できなかった」のが最大の原因なので。仕事ではない以上、モチベーション(開発意欲)が失われたらそこで終わりである。「機能はほんの少しずつ加えて、ちょくちょく公開する」という方策を採るのが鉄則だ。生成」機能がわりと大きな改造を必要とするので、「機能はほんの少しずつ加えて、ちょくちょく公開する」という方策を採りようがないことなのよな......。するかねえ......。編集にししNo.2264管理画面の「設定」ページを生成するソースをリファクタリングしている。ブラウザ上での見た目は一切変わらないのだが、後々カスタマイズしやすくなるような気がする。具体的な計画がない段階でのリファクタリングは、もしかしたら不毛なのでは......という気もしないでもないのだけども......。プログラムサイズ(ソース分量)がいくらか減るメリットはある。編集にししNo.2263管理画面の「設定」では、冒頭にショートカットリンクが掲載されているが、このショートカットリンクの横にチェックボックスを置いて、「チェックを外した項目は非表示になる」みたいな機能を用意しようか。その表示/非表示の選択状態はクエリ文字列(URLの?以降の文字列)に反映されるようにしておいて、「うちのスキンを使うときには、このURLで設定画面にアクセスすれば、余計な設定項目を見ずに済むよ」的なことにできるとか。自分用に取捨選択する場合は、選択後のURLをブックマークしておけば良い、とか。➡試験場No.3204新着画像リストでも、サムネイルの方を表示するようにした。カテゴリ登録機能を実装したとき並に計画して取りかからないと実現しなさそうだ。編集にししNo.2259ハッシュタグの認識で、全角/半角の切り替わりをハッシュタグの終わりだと認識する仕様にしたのは悪手だったな......。半角角括弧で括れば何でもいけるのだが、その仕様に気付く人は滅多に居ない気はする。一応、セットアップ直後のデフォルト挨拶文の中にサンプルは書いてあるのだけども。編集にししNo.2258「miniディレクトリに同名画像ファイルがあったらサムネイルだとみなす」機能は、ほぼできた。画像保存用ディレクトリにminiサブディレクトリがある場合はもちろん、それ以外のディレクトリにある画像を表示する場合でも、その画像の位置にminiサブディレクトリがあればサムネイルの存在を認識できる。あと、新着画像リストで、サムネイル画像(がある場合にはその方)を表示する機能を作れば完成だ。編集にししNo.2257昔から、FAQを構築できるCGIを作りたいと思うことが何度かあったのだが、てがろぐでFAQスキンみたいなのを作れば、検索もできるしカテゴリ分けもできるしそれで済むのではないか、という気もしてきた。FAQのHomeページをどうにかして生成する必要がある。FAQ用のHomeページというと「カテゴリ別にFAQタイトルが並ぶ」という形態が定番だし分かりやすいと思うので、そんな感じのHomeを自動生成できると望ましいのだが。現状の機能だと無理だ。いや、「カテゴリ別に新着タイトルを出力する」ことはできるので、それらをSSIとかで組み合わせて1つのページにするHTMLを用意すればHomeとして機能はするとは思うけども。それだと、カテゴリを追加したときに手動修正が必要になるので運用がちょっと面倒だし、なにより配布するには向いていないだろう(別に配布しなくても良いが、どうせ作る労力を掛けるなら配布できるようにもしたい)。なんかそういう「すべてのカテゴリについて、カテゴリ別に分けつつ、各カテゴリに属する投稿タイトルだけを並べる」みたいな自動生成機能が欲しい。「カテゴリ別タイトル掲載機能」とでも呼ぶか。「カテゴリ別の新着投稿リスト出力機能」だとそれなりに需要はあるかもしれないが、FAQの場合は新着かどうかよりも自ら掲載項目を選択できる方が望ましい気もする。並べたい順に投稿日時を手動で修正する手はあるが。「下げる」機能を使って、「下げられていない投稿だけがリストアップされる」みたいな感じにすれば良いかもしれない。編集にししNo.2256設定項目だけは作った。編集にししNo.2255「管理画面そのものもスキン式にしたい」という需要があるっぽいことは分かったが、なかなか実現は難しそうな気がしている。スキン式にすることを微塵も考えていなかったので、実装に一貫性がないのよな。行き当たりばったり製作というか。ファイルを使うことで実現はできそうな気がする。このファイルに、設定項目のON/OFFも指定できる機能を加えておけば、「そのスキンがメインスキンとして適用されている状況では、特定の設定項目は見えないようにできる」みたいなことはできそうだ。たしかに、「そのスキンで利用していない項目」をすべて非表示にできれば、設定画面がスッキリするだろうとは思う。編集にししNo.2254【ナビゲーションリンクの表示】関連の設定項目は、スキン側からも強制指定できる方が望ましいのかも知れない。「スキン側の指定を使う/ここの指定を使う」みたいな選択肢で切り替えられるとか。編集にししNo.2253画像インデックスを生成することそのものはまあ良いのだが、それを使って画像管理画面を作ろうとすると、画像管理画面での画像一覧生成処理をかなーり大きく書き換えないといけないことが分かった。これは......、大変だ。この実装をしようと思ったら、クッキーとチョコレートがめちゃくちゃたくさん要る。あと、それらをたくさん食べても太らない身体が......。編集にししNo.2251画像インデックス生成機能を作ってキャプションとかを登録できるようにする前に、No.2211の「./mini/ディレクトリに同名画像ファイルがあったらサムネイルだとみなす」機能の方を先に作った方がいいか......?(なんとなく、そんな気がしてきた。別々に登録できるようにすると汎用性は高まるような気はするが、登録画面が複雑で面倒になる気もする。「手軽」という設計思想にはそぐわないような気もしてきた。]日未満なら日を表示(デフォルト:365.25)それ以上なら年を表示とか。3つ目の選択肢だけ(=単位を「時間」から「日」に切り替える時間)を設定できれば充分かも知れない。いうアラートがサーバのエラーログに記録されるな......。Perl5.8.9では記録されたが、Perl5.14.4では記録されなかった。5.8.9あたりではサポートされていないっぽい。どのバージョンからサポートされたのかは分からんけども。「垂直方向の空白」というのは、改行(LF)、復帰(CR)、垂直タブ(VT)、フォームフィード(FF)の4つくらいのことを指している。SEPARATORとかも含むようだけども。がろぐではそこまで全部調べたいわけではなくて、単に「LFとCRを一気に指定できる」くらいの意味で使っていた。書くようにしておこう......。書けるようにしてみた。内側スキンに書いた場合、投稿本文やその他(内側スキンで生成される内容すべて)に含まれる各種リンクやフォーム(=鍵付き投稿の鍵入力フォーム)で、「現在適用中のスキンでの表示」を維持しないようになる。実験してみた限りでは、うまく動作しているような気がする。編集にししNo.2245さっき、『「ここ本当に変更して大丈夫なのか」みたいな疑問』と書いたが、よくよく考えるとそういう疑問が出るケースはあまりない。コメントがたっぷりあるので、だいたいの役割は分かるから。それよりもよくあるのは、「書き換えるのは本当にここだけで充分なのか」みたいな疑問だ。ソースがスパゲッティすぎて、1つの機能を実現するための記述が1カ所に留まっていない場合がよくある。「ここを書き換えるなら、あっちも同時に書き換えないといけない」みたいなケースがあって(そういう箇所はまさしくリファクタリングすべき箇所なのだが)、そういうのを見逃していないかどうかの確認が必要なケースがよくある。編集にししNo.2244設計はほぼナシの、思いつきだけでちょくちょく機能を増やしてきたツールなので、ソースがスパゲッティすぎるのよな......。「ここ本当に変更して大丈夫なのか」みたいな疑問は、やってみて動かしてみて確かめる、という方法しかない。なんかちょっとリファクタリングをする方が良いとは(ずっと)思っているのだが、リファクタリングは重い腰を上げてするものではなくて、もっと頻繁にやっとかないといけないものだよな......。あまりにもソースが絡まりすぎると、もはやリファクタリングする気力が出なくなる。「オブジェクト指向?ナニそれ」というソースだしな。久しぶりにソース量を確認したら17,636行あった。書いたな......。3割くらいはコメントだと思うけども。コメントは本当に潤沢に書いておかないと未来の自分がソースの意味を把握できなくなるので、過剰気味に書いておかないと開発が続けられなくなる。編集にししNo.2243今のカスタマイズ方法ページに掲載しているリファレンスはやはり見やすいとは言い難いので、なんか専用記法だけを独立させた(PDFとかで)「てがろぐカスタマイズ・チートシート」みたいなのを作った方が良い気がしている。編集にししNo.2242次のβ版は、明日(もう今日だが)には出せる予定である。今回はほとんど、スキンを自前で大きくカスタマイズする方々向けの機能ばかりだけども。それを配布したあとは、画像管理機能の強化に進みたい。11月のてがろぐ開発はそればっかりになる気がしている。編集にししNo.2241INCLUDEされたファイルの中からでも、さらにINCLUDEの記述を可能にした。別に何階層でも単にループすれば良いだけなので処理は簡単だが、同じファイルを呼び出して無限ループにはならないように。3階層もたどれば充分だろう。「複数のスキンで埋め込みたい一連のファイル群を1つのINCLUDEファイルにまとめておきたい」みたいな需要は、2階層で充分満たせるだろうから。全部反映されるようにして欲しい』という感じの要望を頂いた(※表現はもっと丁寧だった)。いえば、そのような動作になる可能性もあった(そうならない場合もある)。その点もソースを修正したので、次のバージョン(β版)からは、どの記述もすべて(INCLUDEされたファイル内でも)使えるようになる。figure要素+img要素+figcaption要素を出力する......みたいな処理でいいか。img要素だけを出力すれば良いわけで。3.8.4βとして配布してしまってから、11月で画像管理機能を作り上げる感じにしたい。正式版をリリースできるようにする。次の正式版までに予約投稿機能くらいは追加したかったが、そこは余力次第な気がする。先送りの可能性が(今のところは)濃厚な感じだ。index.xml(画像インデックス)は、とりあえず初回実装時の仕様としてはだいたいこんな感じでどうか。:</tegalogimages>代替文字(alt)とキャプション用文字列(cap)を別々に登録できる需要があるかどうかはよく分からないが、代替文字に指定したい文字列とキャプションとして見せたい文字列が同じとは限らないので、別にできる方が望ましそうな気はする。今はそのキャプションを表示する機能がないので、キャプションの登録機能を用意するなら表示機能も同時に用意しないといけないが。登録機能の実装だけはしておいて、最初の公開時にはそこだけ無効(非表示)にしておいても良いかもしれない。画像を一覧に表示して良いかどうかを知るため(とか、そのほか将来的に何らかの属性を保存するため)にフラグ(flag)も記録できるようにする。その画像自体の仕様として、縦横サイズ(size)とファイルサイズ(bytes)もここに記録しておけば、何度も再取得する必要がなくなる。ユーザがFTP等で画像を差し替えた場合に備えて、実際の表示に使う際の縦横サイズは、毎回取得する方が良い気はする。考えると、別にデータファイルに縦横サイズを記録する必要はないかもしれない(原寸サイズではなく手動指定したサイズで表示したい場合に、それを記録しておく仕様にしても良いかもしれないが)。ファイルサイズの方は、まあ記録しておけば合計サイズを計算するのが早くなるだろうから記録しておく意味はある気はする。誰がUPしたのかのユーザID(user)を記録しておけば、ファイル名からユーザIDを抜き出さなくても良くなる(というか、ファイル名を自由にしてUPしている場合でもユーザを記録できる)。ファイル名(file)には、とりあえずファイル名だけを記録することを考えてはいるが、パスを加えることで他のディレクトリに存在する画像も扱えるようにしても良さそうな気がする。将来的に、画像保存用ディレクトリを複数用意できるようにすることを考えるなら特に。そのほか、サムネイル画像の存在有無も記録できるようにしても良いかな......という気もするが、「./mini/サブディレクトリに同名のファイルがあればそれをサムネイルと見なす」みたいな仕様にするなら、別にそれは記録する必要はない気もする。最初から盛ってしまうと企画倒れになる可能性が高いので、最初の段階ではシンプルにしておきたい。デフォルトの画像ファイル名が「YYYYMMDDhhmmss-USERID」の形式なのは、このようなindexを一切設けず、ファイルのタイムスタンプすらも調べずに、ただファイル名を得るだけで「UP日時」と「UPユーザ」が分かるようにするお手軽仕様だったからだ。......が、もはやファイルの整列にはタイムスタンプを参照しているし、UPユーザもindexから分かるようになるなら、ファイル名をこの形式にする必要性が全くない。みたいな感じの意味のないファイル名にする方が良いだろうか?たぶん、画像をカテゴリ分けする需要はあるのだろうな......。そこまで一気に実装するのは無理なので(※カテゴリを表す文字列を記録すること自体は簡単だが)、そこは先送りだ。データファイルにカテゴリを記録できなくても、UP先のサブディレクトリを選択できるようになればそれでカテゴリ分けの役割になるだろうけども。UP先のディレクトリを選択できるようにするのもそこそこ手間はかかりそうだが。ユーザがFTP等の手段で手動UPした画像も漏れなく記録するために、画像管理画面にアクセスされた際には毎回ディレクトリを走査して、index.xmlに含まれていない画像を発見したらその都度追記する仕様にする必要がある。少なくとも、altとcapは自動復元ができないのだから、このindex.xmlもバックアップディレクトリに自動バックアップするようにしておいた方が良いだろう。編集にししNo.2236投稿されたのがどれくらい前なのかを「40秒前」とか「3分前」とか「12時間前」とか「50日前」とか表示できるようにした。ように表示(未来の日付だと、-1日、-2時間、-3分のように表示)するようにした。表示するかどうかはスキンの書き方次第だ。(記号にAを採用したのは、Agoの意味で。)デフォルトのスキンでどうするかは考え中。あまりにも加えすぎると画面が煩すぎる気がするので、サイトマップページ用スキンに加えておくくらいに留めておくので良いかもしれない。全投稿を一覧で見るための(サイトマップページ)スキンなら、何日前に投稿されたのか、という表示もあれば分かりやすくて便利な気もしないでもないので。削除すれば動く』という仕様が用意してある。自力でPerlモジュールをインストールできない場合にはこの方法が使える。この方法が必要っぽい状況があることも明らかになったことだし、もうちょっと具体的に解説しておくと後々役に立つかもしれない。編集にししNo.2234Twitterで直近投稿に表示されるような「n秒前」、「n分前」、「n時間前」、「n日前」みたいな表示ができる日付表記オプションもそういえば簡単にできそうなので作ろうか......。Twitterでは「n日前」とは出ないけども。「前」は含めない方が良いか。数値+単位(秒・分・時間・日)だけの出力にすれば、自由な文字と組み合わせて表示をカスタマイズしやすい気がする。需要があるかどうかは分からないけども。編集にししNo.2233以下の2つが同じファイルを読み込むようになるようINCLUDEの仕様を修正した。中身」を読み込んで挿入する。※PATH:~記法は、必ず「/」記号で始まって「/」記号で終わることが保証されている仕様。Rootからの絶対パスだと解釈して読み込まれる。(従来は、相対パスだけで記述するようリファレンスに書いていた。)さらにサブディレクトリに存在するファイルを読むこともできる。中身」を読み込んで挿入する。同じことができる記法が2つあってもあんまり意味はないが。後者の書き方は、バリエーションとしては以下のようなこともできる。←ギャラリーモードに指定されているスキンのディレクトリ内にあるhogehoge.htmlが読み込まれる。←サイトマップページモードに指定されているスキンのディレクトリ内にあるhogehoge.htmlが読み込まれる。使って画像保存用ディレクトリにあるファイルを読み込むこともできるが、あまり需要はない気はする。HTMLに画像データ(バイナリ)を読み込んでも意味がないし。いうことにして早めにリリースしたい。12月上旬あたりを目標にしようかな......。なんか嘘を書いた気がするな......。設置している場所がドメインの最上階層なら確かに、以下の2つの記述は、同じ結果(=同じファイルの挿入)になる。設置している場所が何らかのディレクトリの中なら、上記の2つは同じにはならない。いうか前者しか正しく動作しない。カレントディレクトリを示す「.」を頭に付けることで、ドメインの最上階層に設置されている場合にだけ例外的にうまくいく。編集にししNo.2228細かな機能を一気に実装してしまおうと思って、記法をいろいろ追加した。RSSフィードが出力されている設定の場合にだけ、RSSの所在をlink要素で出力する。RSSフィードが出力されない設定なら何も出力しない。(これで、RSSを使わない設定にしているのにAuto-Discoveryの記述だけはある、という状態を避けられる。これをスキンの先頭に記述しておけば、そのスキンがプレビュー適用されていたり簡易適用されていたりしても、(CSSの読み込み等で使われる)link要素や(全文検索フォーム等で使われる)form要素で、スキンディレクトリを強制挿入する自動調整が入らなくなる。