ユーザ「にしし」の投稿［484件］（4ページ目） - 開発放言

mixhostの新サーバにPerlモジュールがさっぱり入っていないのは、もはやフリーCGIとか使わせる気がないということなのだろうか。Perlは使えるし、Perlモジュールを自力でインストールする機能も提供されているので、Perl自体を拒否しているわけではないけども。「自作のPerlで何かをしたい人は自由にすれば良いが、一般公開されているフリーCGI的なものを使うことはもはや考慮していない」みたいな？とりあえず、mixhostの新サーバ向けの対策はFAQとかに書いておいた方が良さそうだ。

by nishishi. ⌚ 2022年11月17日(木) 13:51:34〈319日前〉＜247文字＞編集

にしし

No.2281

検索時とかカテゴリ別表示時とか個別投稿表示時とかにはナビ領域に「初期表示に戻る」テキストリンクが出るが、何の条件も限定されていない状況での「2ページ目」とか「3ページ目」とかには出ない。ページ番号リンクが表示されているのなら「1」を押せば最初に戻れるので構わないが、ページ番号リンクを表示しないスキンが使われていると1ページ目に戻る手段がない。『何の条件も限定されていない状況でも2ページ目以降なら最初に戻るリンクを表示する』みたいなオプションがあると良いかもしれない。もしくは、『<<最初 <前のxx件次のxx件> 最後>>』みたいな4段階の前後移動リンクが出力できる機能とか。

by nishishi. ⌚ 2022年11月17日(木) 12:16:56〈319日前〉てがろぐ＜291文字＞編集

にしし

No.2280

なんか、画像インデックス生成機能を作り始める前に、いろいろ解決しないといけない問題が出てきたような気がする。大きな機能の実装を開始してしまうと、それ以外の部分の細かな修正ができなくなるので、細かな修正を済ませてから実装に入りたいのだがががががが。

by nishishi. ⌚ 2022年11月15日(火) 23:28:42〈321日前〉てがろぐ＜123文字＞編集

にしし

No.2279

画像をWeb上に表示する場合、相対パスが使われていれば楽なのだが、絶対パスが使われている場合には、2種類のパス(PATH)を生成しないといけない問題がある。1つはWeb上のパスで、もう1つはサーバのファイルシステム内のパスだ。HTMLとして出力する際には前者のパスが必要だが、ファイルの実在を確認する場合には後者のパスが要る。相対パスだったらそれらの差を気にする必要がないのだが、絶対パスだと「/」が指し示す先が異なるので、両者を別々に扱う必要がある。具体的には、Webでの「/」が示しているディレクトリ（＝ドキュメントルート）がサーバのファイルシステム内ではどこなのかを突き止める必要がある。このドキュメントルートの取得は環境変数から取得しているのだが、あらゆるWebサーバで本当に正しいドキュメントルートが得られるのかどうか知る術がないのでやや困る。

by nishishi. ⌚ 2022年11月15日(火) 23:00:24〈321日前〉てがろぐ＜377文字＞編集

にしし

No.2278

16進数での色指定を本文に書くとハッシュタグとして認識されてしまう問題の回避方法は、5文字書く方法で良ければ存在はする。できれば、HTMLの色指定に該当する場合だけハッシュタグだとは認識しないようにできると良いのだが、それを正規表現1つで表現する方法が思いつかないので、実現できないでいる。果たして正規表現でそんな方法があるだろうか？『「 # で始まる文字列」ただし [a-fA-F0-9] が3文字または6文字続く場合だけは除く』みたいな。正規表現をめちゃくちゃ使いこなしている人だと編み出せるのかもしれないが……。

by nishishi. ⌚ 2022年11月15日(火) 21:27:08〈321日前〉てがろぐ＜259文字＞編集

にしし

No.2277

サーバのシェルにログインできるなら、シンボリックリンクを作れば複数のてがろぐで同じスキンを共有できるだろうけども。

by nishishi. ⌚ 2022年11月15日(火) 13:39:31〈321日前〉てがろぐ＜57文字＞編集

にしし

No.2276

てがろぐのスキンを ?skin=../upperdir/some/skin-dir みたいな感じで指定すると、セキュリティの都合上、CGIが存在しているディレクトリよりも上位(浅い)階層のディレクトリにあるファイルを参照することはできません。と拒否される仕様なのだが、この制限に意味あるかな……？この方法で、サーバ内の（何か漏れるとマズい）ファイルが参照されたところで、それはスキンとしては機能しないのだから「スキンがないよ」と表示されて終わりなので、特に問題ない気がする。

skinパラメータで、相対パスを使って上位ディレクトリを参照できれば、「複数のてがろぐで同じスキンを使う」ということができるので、てがろぐを複数個設置している場合でもデザインの共有が楽になりそうではないか。

……そうでもないか。skinパラメータだと、一時適用にしかならないものな……。#済 >>2294

by nishishi. ⌚ 2022年11月15日(火) 13:16:42〈321日前〉てがろぐ＜393文字＞編集

にしし

No.2275

「てがろぐ」と「さんごよみ」では、出力ページに埋め込まれる「Powered-by表記」と、管理画面TOP右端に見える「このCGIについて」枠はどちらも非表示にできる手段を（有償ライセンスの形で）用意している。しかし、管理画面の下端に小さく表示される Copyright表記を非表示にする方法は用意していない。後者は一般のアクセス者からは見えないので非表示にしたい需要は特にないと思っているのだが、あるのだろうか？（今までそれを希望されたことはない。）いや、あっても積極的に提供しようとはあまり思っていないのだが。一般のアクセス者からは見えないにもかかわらず「このCGIについて」枠を非表示にする機能を用意しているのは、ビジネス用途（Web製作会社が客先に提供するなど）の場合に、「作者にコーヒーをおごる」リンク等は見せたくないだろうからだ。

by nishishi. ⌚ 2022年11月14日(月) 23:19:12〈322日前〉＜371文字＞編集

にしし

No.2274

そもそも、次に実装する予定の（画像キャプションとかをあらかじめ登録しておけるようにするための）画像インデックス生成機能を本当に作れるのか、という気もする。なんかもうちょっと機能(仕様)候補を列挙して、欲しいか欲しくないか、その仕様で良いか良くないか、みたいなのをアンケート取ってから計画した方が良いのかもしれないな、という気もしないでもない。

by nishishi. ⌚ 2022年11月13日(日) 23:31:02〈323日前〉てがろぐ＜171文字＞編集

にしし

No.2273

自分がてがろぐを画像掲載用途には使っていないので、なかなか画像周りの良さげな仕様を思いつかない問題はある。画像に自由なclass名を付けたいという要望を昔々に受けたことがあって、それを元にもっと汎用的な「自由装飾記法」を作ったわけだが、ギャラリーモードのことは考慮していなかった。いや、ギャラリーモードでも（スキンの作り方は普通のスキンと同じなので）スキンの作り方次第ではあるのだけども。画像掲載用途に使っていて、「こんなことはできんのかー？」と思う場合には、私のところに届くように要望をお知らせ頂かないと（私自身が画像掲載用途に使っていないので）理想的な方向には行かない（行けない）気がする。要望はお気軽に。時々、ずいぶん前にツイートされた「こんな機能があったらいいのにな」的な要望の呟きを偶然目撃することがあるのだが、その度に「それ、私に、知らせてくれなきゃ……！」と思う。_(┐｢ε:)_

by nishishi. ⌚ 2022年11月13日(日) 23:22:36〈323日前〉てがろぐ＜397文字＞編集

にしし

No.2272

そういえば、Lightboxの最新バージョンは 2.11.3 だが、あえてCDNからLightboxの 2.11.0 を読み込んでいるのはIE対策だった。最新版でどうなるのか確認していないが、2.11.1 をIEで読み込んだときには何かおかしかったので（具体的に何がどうだったのかは忘れたが）。~~これはどうするかな……。別に 2.11.0 のままでも不都合はなさそうだけども。もはや、IEは気にしなくても良いだろうし、2.11.3 にしておこうか。~~ →した。#済

by nishishi. ⌚ 2022年11月13日(日) 00:14:29〈324日前〉＜231文字＞編集

にしし

No.2271

とりあえず、Ver 3.8.5β として配布しても良いかな……という感じのところまで来た気がする。

by nishishi. ⌚ 2022年11月12日(土) 23:51:35〈324日前〉てがろぐ＜49文字＞編集

にしし

No.2270

おおぅ。すごいバグを見つけた。あまりこのように操作する人は居ないとは思うが、
【前提】「続きを読む」記法を本文中に使っている状態で、
【操作】設定画面で「続きを読む」機能をOFFにすると、
Internal Server Errorになる不具合を見つけた。しかも、一度この状態になると、設定画面から再度「続きを読む」機能を有効にしようとしても、保存時に(保存処理が実行されるより前に) Internal Server Errorになる。ので、一度この状態になったら、データファイル tegalog.ini を直接修正しない限り復帰できない気がする。
どひー！😱
試さないでね……。

原因は究明したのでローカルのソースは修正した。なお、たぶん比較的新しいバージョンでしかこの問題は発生しない。
これ、自分で見つけたから良かったが、ユーザさんからこの現象を指摘されても原因を突き止めるのは難しいだろうなあ。

by nishishi. ⌚ 2022年11月12日(土) 22:43:02〈324日前〉てがろぐ＜402文字＞編集

にしし

No.2269

「IE8対策」なる注釈の入ったコードが残っていて驚いた。消した。

by nishishi. ⌚ 2022年11月12日(土) 20:21:55〈324日前〉＜32文字＞編集

にしし

No.2268

構成ファイル数がめちゃくちゃ多いCMS（例えばWordPressとかMovableTypeとかもそう）をアップロードするときには、ZIPのままアップロードして、サーバにSSHでログインしてunzipコマンドを打って展開する、みたいなことはする。よく考えたら、別に構成ファイル数が少ない場合でもその方法を採って悪いわけではない。てがろぐをZIPのままアップロードして、unzipコマンドを実行するシェルスクリプトも一緒にアップロードして、それを実行する……みたいな手もある気はする。ただ、シェルスクリプトはパーミッションを設定しないと動かないだろうけど。PHPの方が良いか。

by nishishi. ⌚ 2022年11月12日(土) 19:10:53〈324日前〉＜286文字＞編集

にしし

No.2267

たぶん、ファイルをアップロードするとデフォルトでファイルのパーミッションは 604 か 644 になっていると思うので、パーミッション設定指示の 644 (604) というのは「デフォルトのままで何もしなくて良い」と考えて問題ないと思う。特に、suEXEC採用サーバの場合は、tegalog.cgi を 700 にしさえすれば、あとは全部デフォルトのままでも問題ない気もする。というか、suEXECが採用されているサーバで 600 と 604 に違いがあるのかどうかがよく分からん。600 というと、そのファイルにブラウザでアクセスしたら Forbidden になってくれそうな気がするのだが(suEXECだと)そういうわけではなさそうだし。見えたら困るファイルはセッション情報(psif.cgi)で、これは見えなくするために拡張子を .cgi にしてあるので、パーミッションが見えるような値になっていても特に問題はないが。一番確実に安全なのは、Webからアクセスできないディレクトリに置くことだとは思うけども。そこまでしなくても、念のために .htaccess とかを使ってアクセスを拒否しておくとなお安心かもしれない。（.htaccessでのアクセス拒否は、Webからのアクセスを拒否するだけなので、サーバ上にあるプログラムからはアクセスできるので拒否しても問題ない。）

by nishishi. ⌚ 2022年11月12日(土) 18:16:59〈324日前〉てがろぐ＜587文字＞編集

にしし

No.2266

リンク文字列の中に半角角括弧 [ ] が含まれているとリンクにならない仕様をどうにかしたい。ただ、] が登場した時点でそこが「リンクラベルの終わり」だと認識する仕様なので、どうしようもない気もしないでもないが……。単純に考えれば、「\」でエスケープすれば良い仕様にすれば良い気もするけども。エスケープする手間を考えれば、[ ] を消す手間と大した違いがないので、そこまで必要かな……？という気もする。

by nishishi. ⌚ 2022年11月11日(金) 13:21:16〈325日前〉てがろぐ＜201文字＞編集

にしし

No.2265

画像投稿関連の機能についてだけを言うと、まず「サムネイル用画像があったらサムネイル側を先に表示する」機能は既に実装したので次のバージョンで提供できる。(※注意：サムネイル画像は自動生成ではないので、自らサムネイル用画像を作る必要がある。ただその点はむしろ『自分の納得のいく画質のサムネイルにできる』とか『自分が望む通りのトリミングができる』とか『クッション用画像に差し替えられる』とか、自動生成ではないことのメリットもあるとは思うので、必ずしもデメリット（機能不足）だとは考えていない。）

ただ、現状ではサムネイル画像をアップロードする機能がないので、FTP等の別手段が必要だ。それで良いと思っているわけではないので、将来的には「サムネイル用ディレクトリに画像をUPする機能」も作る予定ではいる。
そのほか、

●画像キャプションをあらかじめ登録しておける機能（＝画像情報のみを記録する index.xml の生成）
●画像単体に「鍵付き」のフラグを登録しておける機能（＝新着画像リストに出すか出さないかを選べる機能）（※上の index.xml での管理機能が先に必要）
●画像をimg要素だけでなく、figure要素＋img要素＋figcaption要素を使って『キャプション付き』でも出力できる機能
●画像のファイル名をもうちょっと自由にできる機能（※先の index.xml での管理機能が先に必要）
●画像のUP先サブディレクトリを選べる機能か、もしくは画像をカテゴリ分けできる機能（※先の index.xml での管理機能が先に必要）
●画像管理画面で、既にUPしてある画像のファイル名（やキャプション等の情報）で画像検索できる機能
●OG:image用の画像を「本文のテキスト」で動的に生成したい場合（＝テキストの画像化ツールへ本文の冒頭文字列を送りたい場合）のために、本文テキストを任意のパラメータ付きでog:imageに加えられる機能

……のようなToDoリストっぽいものがある。
上の方は「計画」だが、下の方は「なんとなくの予定」みたいな感じで、下の方へ行くほど需要を感じなければどんどん先送りする感じである。
どれも一気には提供できないので、1つずつ作ることになる。なぜ一気に提供できないかというと、理由は主に2つある。

➊ 一気に複数の機能を実装すると、もしトラブルが起きたときの原因究明が難しくなるのでその後の開発が行き詰まる。
➋ あれもこれもと盛りすぎると、モチベーションの維持が難しくなって企画倒れになる危険性がとても高くなる。

1も重要だが、何よりも2の方が極めて重大な実際の問題である。過去20年くらい、『作りかけたまま放置して未完成のまま日の目を見ることのなかったフリーソフトやフリーCGI』が多々あるが、そのどれもが「機能を盛りすぎて完成までのモチベーションが維持できなかった」のが最大の原因なので。仕事ではない以上、モチベーション(開発意欲)が失われたらそこで終わりである。
なので、「機能はほんの少しずつ加えて、ちょくちょく公開する」という方策を採るのが鉄則だ。

いま直面している問題が、「画像情報のみを記録する index.xml の生成」機能がわりと大きな改造を必要とするので、「機能はほんの少しずつ加えて、ちょくちょく公開する」という方策を採りようがないことなのよな……。どうするかねえ……。

by nishishi. ⌚ 2022年11月11日(金) 12:34:18〈325日前〉てがろぐ＜1427文字＞編集

にしし

No.2264

管理画面の「設定」ページを生成するソースをリファクタリングしている。ブラウザ上での見た目は一切変わらないのだが、後々カスタマイズしやすくなるような気がする。なんとなく。ただ、具体的な計画がない段階でのリファクタリングは、もしかしたら不毛なのでは……という気もしないでもないのだけども……。まあ、プログラムサイズ（ソース分量）がいくらか減るメリットはある。

by nishishi. ⌚ 2022年11月08日(火) 22:02:44〈328日前〉てがろぐ＜177文字＞編集

にしし

No.2263

管理画面の「設定」では、冒頭にショートカットリンクが掲載されているが、このショートカットリンクの横にチェックボックスを置いて、「チェックを外した項目は非表示になる」みたいな機能を用意しようか。で、その表示/非表示の選択状態はクエリ文字列（URLの?以降の文字列）に反映されるようにしておいて、「うちのスキンを使うときには、このURLで設定画面にアクセスすれば、余計な設定項目を見ずに済むよ」的なことにできるとか。自分用に取捨選択する場合は、選択後のURLをブックマークしておけば良い、とか。

by nishishi. ⌚ 2022年11月07日(月) 17:55:55〈329日前〉てがろぐ＜245文字＞編集

にしし

No.2262

もしサムネイル画像がアップロードされていたら、最初はサムネイル画像の方を表示しておいて、Lightboxではオリジナル画像を見せる機能の動作テスト ➡試験場No.3204
新着画像リストでも、サムネイルの方を表示するようにした。

by nishishi. ⌚ 2022年11月06日(日) 22:32:13〈330日前〉てがろぐ＜115文字＞編集

にしし

No.2261

「このまま書き進めたら、凄まじいスパゲッティソースになる……！」という確信が得られてしまって、どうするか悩む。┌(:3」└)┐

by nishishi. ⌚ 2022年11月06日(日) 22:02:18〈330日前〉＜63文字＞編集

にしし

No.2260

画像インデックス生成機能（※これがあると、「画像の代替文字やキャプションを事前に登録しておける」・「新着画像リストに鍵付き投稿で使った画像が表示されないようフラグで除外できる」等の利点が得られる）は、Ver 3.0.0 でカテゴリ登録機能を実装したとき並に計画して取りかからないと実現しなさそうだ。まず計画。

by nishishi. ⌚ 2022年11月06日(日) 21:43:11〈330日前〉てがろぐ＜211文字＞編集

にしし

No.2259

ハッシュタグの認識で、全角/半角の切り替わりをハッシュタグの終わりだと認識する仕様にしたのは悪手だったな……。半角角括弧で括れば何でもいけるのだが、その仕様に気付く人は滅多に居ない気はする。一応、セットアップ直後のデフォルト挨拶文の中にサンプルは書いてあるのだけども。

by nishishi. ⌚ 2022年11月06日(日) 21:12:14〈330日前〉てがろぐ＜134文字＞編集

にしし

No.2258

「miniディレクトリに同名画像ファイルがあったらサムネイルだとみなす」機能は、ほぼできた。画像保存用ディレクトリにminiサブディレクトリがある場合はもちろん、それ以外のディレクトリにある画像を表示する場合でも、その画像の位置にminiサブディレクトリがあればサムネイルの存在を認識できる。あと、新着画像リストで、サムネイル画像(がある場合にはその方)を表示する機能を作れば完成だ。たぶん。 >>2258,2256,2251,2211

by nishishi. ⌚ 2022年11月06日(日) 01:17:34〈331日前〉てがろぐ＜218文字＞編集

にしし

No.2257

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

by nishishi. ⌚ 2022年11月05日(土) 01:15:19〈332日前〉てがろぐ,開発ネタ＜661文字＞編集

にしし

No.2256

設定項目だけは作った。 >>2251

by nishishi. ⌚ 2022年11月04日(金) 01:05:15〈333日前〉てがろぐ＜19文字＞編集

にしし

No.2255

「管理画面そのものもスキン式にしたい」という需要があるっぽいことは分かったが、なかなか実現は難しそうな気がしている。元々スキン式にすることを微塵も考えていなかったので、実装に一貫性がないのよな。行き当たりばったり製作というか。ただ、「スキンで利用しない設定を見えなくしたい」というだけなら、以前ちょっと考えた skin.ini ファイルを使うことで実現はできそうな気がする。このファイルに、設定項目のON/OFFも指定できる機能を加えておけば、「そのスキンがメインスキンとして適用されている状況では、特定の設定項目は見えないようにできる」みたいなことはできそうだ。たしかに、「そのスキンで利用していない項目」をすべて非表示にできれば、設定画面がスッキリするだろうとは思う。

by nishishi. ⌚ 2022年11月04日(金) 00:04:48〈333日前〉てがろぐ＜336文字＞編集

にしし

No.2254

【ナビゲーションリンクの表示】関連の設定項目は、スキン側からも強制指定できる方が望ましいのかも知れない。「スキン側の指定を使う／ここの指定を使う」みたいな選択肢で切り替えられるとか。

by nishishi. ⌚ 2022年11月04日(金) 00:00:08〈333日前〉てがろぐ＜91文字＞編集

にしし

No.2253

画像インデックスを生成することそのものはまあ良いのだが、それを使って画像管理画面を作ろうとすると、画像管理画面での画像一覧生成処理をかなーり大きく書き換えないといけないことが分かった。これは……、大変だ。この実装をしようと思ったら、クッキーとチョコレートがめちゃくちゃたくさん要る。あと、それらをたくさん食べても太らない身体が……。_(:3」∠)_

by nishishi. ⌚ 2022年11月03日(木) 00:05:44〈334日前〉てがろぐ＜174文字＞編集

にしし

No.2252

どうせ作るなら需要のあるものから作りたいとも思うのだが、問題は需要がなかなか分からんことだ。┌(:3」└)┐

by nishishi. ⌚ 2022年11月03日(木) 00:02:57〈334日前〉＜54文字＞編集

にしし

No.2251

画像インデックス生成機能を作ってキャプションとかを登録できるようにする前に、No.2211の「./mini/ディレクトリに同名画像ファイルがあったらサムネイルだとみなす」機能の方を先に作った方がいいか……？（なんとなく、そんな気がしてきた。ちょっとだけ。）

by nishishi. ⌚ 2022年11月02日(水) 00:39:04〈335日前〉てがろぐ＜128文字＞編集

にしし

No.2250

うーん、1枚の画像に対して、代替文字とキャプションを別々に登録できる必要はない……か？別々に登録できるようにすると汎用性は高まるような気はするが、登録画面が複雑で面倒になる気もする。あまり、「手軽」という設計思想にはそぐわないような気もしてきた。

by nishishi. ⌚ 2022年11月02日(水) 00:00:33〈335日前〉てがろぐ＜124文字＞編集

にしし

No.2249

相対時間をどういう単位で掲載したいかを設定画面から指定できるようにしようか……？

[ ]秒未満なら秒を表示（デフォルト：60）
[ ]分未満なら分を表示（デフォルト：60）
[ ]時間未満なら時間を表示（デフォルト：48）
[ ]日未満なら日を表示（デフォルト：365.25）
それ以上なら年を表示

とか。
……あんまり需要はないか？ 3つ目の選択肢だけ（＝単位を「時間」から「日」に切り替える時間）を設定できれば充分かも知れない。

by nishishi. ⌚ 2022年10月30日(日) 14:47:36〈337日前〉てがろぐ＜229文字＞編集

にしし

No.2248

なんか、比較的古いバージョンのPerlで実行すると、Unrecognized escape \\v passed through at tegalog.cgiというアラートがサーバのエラーログに記録されるな……。Perl5.8.9では記録されたが、Perl5.14.4では記録されなかった。垂直方向の空白を一括で示せる正規表現内の記法 \v が、Perl 5.8.9あたりではサポートされていないっぽい。どのバージョンからサポートされたのかは分からんけども。「垂直方向の空白」というのは、改行(LF)、復帰(CR)、垂直タブ(VT)、フォームフィード(FF)の4つくらいのことを指している。Unicode環境だと、他にもLINE SEPARATORとかPARAGRAPH SEPARATORとかも含むようだけども。てがろぐではそこまで全部調べたいわけではなくて、単に「LFとCRを一気に指定できる」くらいの意味で使っていた。ここは、\v ではなく \r\n と書くようにしておこう……。

by nishishi. ⌚ 2022年10月30日(日) 12:28:00〈337日前〉てがろぐ＜443文字＞編集

にしし

No.2247

外側スキンだけでなく、内側スキンにも [[NO-LINKADJUSTMENT]] を書けるようにしてみた。内側スキンに書いた場合、投稿本文やその他（内側スキンで生成される内容すべて）に含まれる各種リンクやフォーム（＝鍵付き投稿の鍵入力フォーム）で、「現在適用中のスキンでの表示」を維持しないようになる。実験してみた限りでは、うまく動作しているような気がする。

by nishishi. ⌚ 2022年10月29日(土) 22:53:02〈338日前〉てがろぐ＜179文字＞編集

にしし

No.2246

/usr/bin/perl と /usr/local/bin/perl とでPerlのバージョンが異なるというケースもあるのか。ロリポップの「eco7xx、eco8xx、lit7xx、lit8xx、std7xx、std8xx、ent7xx、ent8xxのサーバーの場合」だとそうなっているようだ。

by nishishi. ⌚ 2022年10月29日(土) 17:29:26〈338日前〉＜148文字＞編集

にしし

No.2245

さっき、『「ここ本当に変更して大丈夫なのか」みたいな疑問』と書いたが、よくよく考えるとそういう疑問が出るケースはあまりない。コメントがたっぷりあるので、だいたいの役割は分かるから。それよりもよくあるのは、「書き換えるのは本当にここだけで充分なのか」みたいな疑問だ。ソースがスパゲッティすぎて、1つの機能を実現するための記述が1カ所に留まっていない場合がよくある。「ここを書き換えるなら、あっちも同時に書き換えないといけない」みたいなケースがあって（そういう箇所はまさしくリファクタリングすべき箇所なのだが）、そういうのを見逃していないかどうかの確認が必要なケースがよくある。

by nishishi. ⌚ 2022年10月28日(金) 17:25:50〈339日前〉てがろぐ＜287文字＞編集

にしし

No.2244

設計はほぼナシの、思いつきだけでちょくちょく機能を増やしてきたツールなので、ソースがスパゲッティすぎるのよな……。「ここ本当に変更して大丈夫なのか」みたいな疑問は、やってみて動かしてみて確かめる、という方法しかない。さすがになんかちょっとリファクタリングをする方が良いとは（ずっと）思っているのだが、リファクタリングは重い腰を上げてするものではなくて、もっと頻繁にやっとかないといけないものだよな……。あまりにもソースが絡まりすぎると、もはやリファクタリングする気力が出なくなる。「オブジェクト指向？ナニそれ」というソースだしな。久しぶりにソース量を確認したら17,636行あった。よく書いたな……。まあ、ざっくり3割くらいはコメントだと思うけども。コメントは本当に潤沢に書いておかないと未来の自分がソースの意味を把握できなくなるので、過剰気味に書いておかないと開発が続けられなくなる。

by nishishi. ⌚ 2022年10月28日(金) 16:03:03〈339日前〉てがろぐ＜393文字＞編集

にしし

No.2243

今のカスタマイズ方法ページに掲載しているリファレンスはやはり見やすいとは言い難いので、なんか専用記法だけを独立させた（PDFとかで）「てがろぐカスタマイズ・チートシート」みたいなのを作った方が良い気がしている。

by nishishi. ⌚ 2022年10月27日(木) 11:21:10〈340日前〉てがろぐ＜105文字＞編集

にしし

No.2242

次のβ版は、明日（もう今日だが）には出せる予定である。今回はほとんど、スキンを自前で大きくカスタマイズする方々向けの機能ばかりだけども。それを配布したあとは、画像管理機能の強化に進みたい。たぶん11月のてがろぐ開発はそればっかりになる気がしている。

by nishishi. ⌚ 2022年10月27日(木) 00:05:21〈341日前〉てがろぐ＜124文字＞編集

にしし

No.2241

INCLUDEされたファイルの中からでも、さらにINCLUDEの記述を可能にした。ただし3階層（3重）まで。別に何階層でも単にループすれば良いだけなので処理は簡単だが、同じファイルを呼び出して無限ループにはならないように。3階層もたどれば充分だろう。「複数のスキンで埋め込みたい一連のファイル群を1つのINCLUDEファイルにまとめておきたい」みたいな需要は、2階層で充分満たせるだろうから。

いま実施中のアンケートの自由入力欄で、『INCLUDEしたファイル内に [[CALENDAR]]、[[DATEBOX]]、[[LATESTLIST]] 等を書いても埋め込まれないが、[[SEARCHBOX]]、[[CATEGORY]]、[[HASHTAG]] は反映された。全部反映されるようにして欲しい』という感じの要望を頂いた（※表現はもっと丁寧だった）。そういえば、そのような動作になる可能性もあった（そうならない場合もある）。その点もソースを修正したので、次のバージョン(β版)からは、どの記述もすべて（INCLUDEされたファイル内でも）使えるようになる。

by nishishi. ⌚ 2022年10月26日(水) 18:12:07〈341日前〉てがろぐ＜481文字＞編集

にしし

No.2240

代替文字とキャプションを画像管理画面で登録できるようになるなら>>2238、投稿本文内に代替文字やキャプションを含ませる必要はないわけだから、No.2212みたいな複雑な記法は必要なくて、単に [PICT:FIG:ファイルパス] みたいな感じだったら登録済みの代替文字とキャプションを使って figure要素＋img要素＋figcaption要素を出力する……みたいな処理でいいか。もし引数FIGがなくて [PICT:ファイルパス] だったり、引数にFIG以外の文字列が指定されている場合 [PICT:ぶひぶひ:ファイルパス] だったら、従来通り img要素だけを出力すれば良いわけで。

by nishishi. ⌚ 2022年10月26日(水) 10:17:41〈341日前〉てがろぐ＜302文字＞編集

にしし

No.2239

今月中に、今の時点でできている細々したものを Ver 3.8.4βとして配布してしまってから、11月で画像管理機能を作り上げる感じにしたい。で、12月に Ver 3.9.0 正式版をリリースできるようにする。次の正式版までに予約投稿機能くらいは追加したかったが、そこは余力次第な気がする。先送りの可能性が（今のところは）濃厚な感じだ。

by nishishi. ⌚ 2022年10月25日(火) 20:35:01〈342日前〉てがろぐ＜167文字＞編集

にしし

No.2238

画像保存用ディレクトリに自動生成する index.xml（画像インデックス）は、とりあえず初回実装時の仕様としてはだいたいこんな感じでどうか。
<tegalogimages>
<image><date>2022/10/15 17:35:30</date><file>20221015173530-admin.png</file><user>admin</user><bytes>1286</bytes><size>800x600</size><flag>lock</flag><alt>代替文字</alt><cap>キャプション</cap></image>
<image>～</image>
<image>～</image>
　　　：　：　：
</tegalogimages>

代替文字(alt)とキャプション用文字列(cap)を別々に登録できる需要があるかどうかはよく分からないが、代替文字に指定したい文字列とキャプションとして見せたい文字列が同じとは限らないので、別にできる方が望ましそうな気はする。もっとも、今はそのキャプションを表示する機能がないので、キャプションの登録機能を用意するなら表示機能も同時に用意しないといけないが。登録機能の実装だけはしておいて、最初の公開時にはそこだけ無効(非表示)にしておいても良いかもしれない。
画像を一覧に表示して良いかどうかを知るため（とか、そのほか将来的に何らかの属性を保存するため）にフラグ(flag)も記録できるようにする。
その画像自体の仕様として、縦横サイズ(size)とファイルサイズ(bytes)もここに記録しておけば、何度も再取得する必要がなくなる。ただ、ユーザがFTP等で画像を差し替えた場合に備えて、実際の表示に使う際の縦横サイズは、毎回取得する方が良い気はする。そう考えると、別にデータファイルに縦横サイズを記録する必要はないかもしれない（原寸サイズではなく手動指定したサイズで表示したい場合に、それを記録しておく仕様にしても良いかもしれないが）。ファイルサイズの方は、まあ記録しておけば合計サイズを計算するのが早くなるだろうから記録しておく意味はある気はする。
誰がUPしたのかのユーザID(user)を記録しておけば、ファイル名からユーザIDを抜き出さなくても良くなる（というか、ファイル名を自由にしてUPしている場合でもユーザを記録できる）。
ファイル名(file)には、とりあえずファイル名だけを記録することを考えてはいるが、パスを加えることで他のディレクトリに存在する画像も扱えるようにしても良さそうな気がする。将来的に、画像保存用ディレクトリを複数用意できるようにすることを考えるなら特に。

そのほか、サムネイル画像の存在有無も記録できるようにしても良いかな……という気もするが、「./mini/サブディレクトリに同名のファイルがあればそれをサムネイルと見なす」みたいな仕様にするなら、別にそれは記録する必要はない気もする。あまり最初から盛ってしまうと企画倒れになる可能性が高いので、最初の段階ではシンプルにしておきたい。

デフォルトの画像ファイル名が「YYYYMMDDhhmmss-USERID」の形式なのは、このようなindexを一切設けず、ファイルのタイムスタンプすらも調べずに、ただファイル名を得るだけで「UP日時」と「UPユーザ」が分かるようにするお手軽仕様だったからだ。……が、もはやファイルの整列にはタイムスタンプを参照しているし、UPユーザもindexから分かるようになるなら、ファイル名をこの形式にする必要性が全くない。もっとTwitterとかでやっているような、短いランダムな文字列を生成して gPfKn4tsWI.png みたいな感じの意味のないファイル名にする方が良いだろうか？

たぶん、画像をカテゴリ分けする需要はあるのだろうな……。ただ、そこまで一気に実装するのは無理なので（※カテゴリを表す文字列を記録すること自体は簡単だが）、そこは先送りだ。データファイルにカテゴリを記録できなくても、UP先のサブディレクトリを選択できるようになればそれでカテゴリ分けの役割になるだろうけども。ただ、UP先のディレクトリを選択できるようにするのもそこそこ手間はかかりそうだが。

ユーザがFTP等の手段で手動UPした画像も漏れなく記録するために、画像管理画面にアクセスされた際には毎回ディレクトリを走査して、index.xmlに含まれていない画像を発見したらその都度追記する仕様にする必要がある。

少なくとも、altとcapは自動復元ができないのだから、このindex.xmlもバックアップディレクトリに自動バックアップするようにしておいた方が良いだろう。

by nishishi. ⌚ 2022年10月25日(火) 20:03:05〈342日前〉てがろぐ＜1994文字＞編集

にしし

No.2237

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

by nishishi. ⌚ 2022年10月25日(火) 15:16:35〈342日前〉開発ネタ＜310文字＞編集

にしし

No.2236

投稿されたのがどれくらい前なのかを「40秒前」とか「3分前」とか「12時間前」とか「50日前」とか表示できるようにした。投稿日時を表示できる [[DATE:～]] 記法で、

「A」と記述すれば、5秒前、6分前、7時間前、8日前、9年前のように表示（未来の日付だと、1日後、2時間後、3分後のように表示）
「a」と記述すれば、5秒、6分、7時間、8日、9年のように表示（未来の日付だと、-1日、-2時間、-3分のように表示）

するようにした。なので、表示するかどうかはスキンの書き方次第だ。（記号にAを採用したのは、Agoの意味で。）

デフォルトのスキンでどうするかは考え中。あまりにも加えすぎると画面が煩すぎる気がするので、サイトマップページ用スキンに加えておくくらいに留めておくので良いかもしれない。全投稿を一覧で見るための（サイトマップページ）スキンなら、何日前に投稿されたのか、という表示もあれば分かりやすくて便利な気もしないでもないので。

図は標準スキンの投稿日時区画で、[[DATE:Y年G月N日(b) h:m:s （A）]] と書いてみたところ。

by nishishi. ⌚ 2022年10月25日(火) 14:02:39〈342日前〉てがろぐ＜489文字＞編集

にしし

No.2235

あまり必要性はないと思っていたので公式サイト上でも軽く述べるに留めて詳しくは解説していなかったのだけども、てがろぐには『サーバに存在しないモジュールは、tegalog.cgiと同じディレクトリ上に（モジュールのディレクトリ構造を維持した状態で）アップロードした上で、89行目にある#use lib '.';の先頭の # を削除すれば動く』という仕様が用意してある。自力でPerlモジュールをインストールできない場合にはこの方法が使える。この方法が必要っぽい状況があることも明らかになったことだし、もうちょっと具体的に解説しておくと後々役に立つかもしれない。

by nishishi. ⌚ 2022年10月24日(月) 21:45:24〈343日前〉てがろぐ＜278文字＞編集

にしし

No.2234

Twitterで直近投稿に表示されるような「n秒前」、「n分前」、「n時間前」、「n日前」みたいな表示ができる日付表記オプションもそういえば簡単にできそうなので作ろうか……。Twitterでは「n日前」とは出ないけども。「前」は含めない方が良いか。数値＋単位(秒・分・時間・日)だけの出力にすれば、自由な文字と組み合わせて表示をカスタマイズしやすい気がする。需要があるかどうかは分からないけども。#済 >>2236

by nishishi. ⌚ 2022年10月23日(日) 23:16:13〈344日前〉てがろぐ＜207文字＞編集

にしし

No.2233

以下の2つが同じファイルを読み込むようになるようINCLUDEの仕様を修正した。どちらも「現在適用中のスキンが存在するディレクトリ内にある hogehoge.html の中身」を読み込んで挿入する。
[[INCLUDE:FROM-THIS-SKIN-DIR:hogehoge.html]]
[[INCLUDE:[[PATH:SKINDIR]]hogehoge.html]]　←ドット記号は不要。

※PATH:～記法は、必ず「/」記号で始まって「/」記号で終わることが保証されている仕様。
※INCLUDE:～記法に「/」で始まる絶対パスが指定された場合は、WebサイトのDocument Rootからの絶対パスだと解釈して読み込まれる。（従来は、相対パスだけで記述するようリファレンスに書いていた。）

さらにサブディレクトリに存在するファイルを読むこともできる。
[[INCLUDE:FROM-THIS-SKIN-DIR:moemoe/sakura.txt]]
[[INCLUDE:[[PATH:SKINDIR]]moemoe/sakura.txt]]
どちらも「現在適用中のスキンが存在するディレクトリ内にあるサブディレクトリ「moemoe」の中にある sakura.txt の中身」を読み込んで挿入する。

同じことができる記法が2つあってもあんまり意味はないが。
後者の書き方は、バリエーションとしては以下のようなこともできる。
[[INCLUDE:[[PATH:SKINDIR:GALLERY]]hogehoge.html]]　←ギャラリーモードに指定されているスキンのディレクトリ内にあるhogehoge.htmlが読み込まれる。
[[INCLUDE:[[PATH:SKINDIR:SITEMAP]]hogehoge.html]]　←サイトマップページモードに指定されているスキンのディレクトリ内にあるhogehoge.htmlが読み込まれる。

同様に [[PATH:IMAGEDIR]] を使って画像保存用ディレクトリにあるファイルを読み込むこともできるが、あまり需要はない気はする。HTMLに画像データ(バイナリ)を読み込んでも意味がないし。

スレッドを時系列順に見る

by nishishi. ⌚ 2022年10月22日(土) 14:26:20〈345日前〉てがろぐ＜965文字＞編集

«前の50件 / 次の50件»

01 02 03 04 05 06 07 08 09 10

初期表示に戻る

DASHBOARD

■開発放言について

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

編集

ランダムに1件を表示

RSSフィード

■全文検索：

■日付一覧：