にしし らぼらとりー

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

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

RSS Feed

開発放言 ユーザ「にしし」の投稿[539件](3ページ目)

新規投稿 / 管理用

「800文字以上書いた投稿のみ表示」みたいな文字数で検索できる機能が欲しいな……と個人的に思っていたのだが、使えるパラメータを新たに追加するのが結構面倒くさい……。_(┐「ε:)_

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

てがろぐ上で画像をアップロードする際に、アップロード先ディレクトリを選べる機能が欲しい人はどれくらい居るかな……。

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

てがろぐには、サーバの時刻とユーザの時刻が一致して居ないケース(例えば、英国に住んでいるがサーバは日本にあるのを使っているとか)のために、±23.5時間の範囲で表示時刻をずらす機能があるが、そうではなくて、もっと長期にずらす機能に需要があったりするのだろうか。例えば、200年ずらして、今が2223年とか1823年だとかに仮定して日付(と曜日)を表示できるような……?

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

ファイルのタイムスタンプを取得できるような記法を作ろうかな、という案を以前に書いた >>2373 が、そうするよりも、スキンの中にCSSの読み込み記述を見つけたら、問答無用でタイムスタンプをクエリ文字列に加える、みたいな機能を用意する方が便利かもしれない。具体的には link要素があって、そのhref属性値が .css で終わっている場合に限って、その直後に ?d20230430120715 みたいなタイムスタンプを加えるような。もちろんOFFにする設定項目は用意するが、デフォルトではONで良さそうな気がする。こういう仕様の方が、スキン側に何の工夫も要らないし、従来のスキンに対しても適用されるし、望ましいのではないか。それ以外の用途でタイムスタンプを取得したいケースはなさそうな気がするので。

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

Windows環境でXAMPPを使ってCGIを動かすとき、1行目が「#! /usr/bin/env perl」だと /usr/bin/ の位置に env というプログラムが存在しないから動かない問題があるようだが、perl.exe を「env perl.exe」というファイル名でも用意してやるとうまくいったりしないだろうか?(実験はしていない) シンボリックリンクでリンクを張るときに、リンク名に空白文字を含めることはできないんだっけ?(いや、含められたとしても、それに /usr/bin/env perl というパスを使ってアクセスできるとは限らないが。)

by nishishi. <280文字> 編集

ロリポップで動作させている場合専用の自動変換機能を用意したらいいか? /etc/ という文字列が投稿本文に含まれているとき、それを数値文字参照を使って /etc/ に置き換えるような。スラッシュ記号を置き換えるよりも、英字の方を置き換えた方が副作用が少なそうか……? ee にするような。

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

YouTube動画の埋め込み機能を使って出力されるHTMLが <span class="embeddedmovie"><iframe class="embeddedmovie" width="560" height="315" src="…… のような感じで、外側のspan要素にも、内側のiframeにもどちらにも class="embeddedmovie" が付加されていることに気付いたのだが、これ、いつから……? まあ、span.embeddedmovieiframe.embeddedmovie でセレクタは分けられるので大きな問題ではないが、.embeddedmovie でCSSを書いてしまうと装飾が重複することになる。いまさら変更すると悪影響もあるだろうから、このままだな……。

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

例えば [*:pre:あいうえお] と書くと <pre>あいうえお</pre> になり、[*:code:かきくけこ] と書くと <code>かきくけこ</code> になる……みたいな自由マークアップ記法みたいなのを用意すると自由度は少し上がりそうな気がするのだが(属性が不要な要素にしか使えないが)、そこまでするのならHTMLをそのまま書けるようにしろ、という話もありそうな気もする。ただ、HTMLをそのまま書けるようにするよりは実装は簡単ではある。たぶん。

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

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

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

そういえば、このような掲示板モード用の入力欄カスタマイズ機能を用意すれば、掲示板として使わない場合でも、例えば「タイトルと本文を分けたい」という場合に、「1行目をタイトル、2行目以降を本文」という運用にしなくても、物理的に「タイトル入力欄」と「本文入力欄」に分割して用意できるメリットもありそうな気がする。その場合、もちろん「1行目をタイトル、2行目に分類用タグ、3行目以降を本文」としてきたなら、「タイトル入力欄」・「タグ入力欄」・「本文入力欄」に分割して用意できるメリットもある。

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

16進数のRGB値だけでなくて、RGBAカラーモデルで透明度も含んだ色を指定したいな……。rgba(255,105,180,0.2) みたいな。まあ、自由装飾機能を使って opacity を指定したclassを事前に用意しておけば似たようなことは今でも可能だけども。

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

もし「掲示板モード」を作るとしたら、投稿を(管理者へ)メールで知らせる機能が必須だろうから、メール送信機能も加えないとな……。すると、掲示板として使わない場合でも、メール送信機能を流用して「メッセージ送信フォーム」にできるような機能も用意できるメリットがある。

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

てがろぐFAQページを、てがろぐを使って生成すれば、現状のような「まとめて閲覧」もできるし、「1ネタ1ページで閲覧」もできるし、検索もできるので望ましそうに思えるのだが、あのFAQを作るにはHTMLソースを自由に書けないとまず無理なので(できるかもしれないがかなり大変そうに思えるので)、まず、てがろぐ上に自由なHTMLソースをそのまま書ける機能を実装する必要がある。

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

関係者だけがアクセスできるクローズドな場所で、既存の(他者製の)掲示板CGIをカスタマイズして連絡板を運営しているのだが、2000年代のCGIなのでカスタマイズになかなか手間がかかる。画像も投稿できないし。なので、てがろぐの「掲示板モード」を作りたい気がかなりしている。No.2366に書いたような、複数の入力項目を作った上で、それらの値を行単位で保存するような形にすれば、現状のてがろぐCGIからそういう大きな改造をしなくても実現できるのではないか、という気がしている。行頭に項目名(id属性名)が記録されるような形にすれば、後から項目を増減した場合でも柔軟に対応できて良いのではないか。
form:name=にしし
form:url=https://www.nishishi.com/
form:title=無題
form:delpass=hogehoge
本文は行頭に何もなしで。

実際の投稿者IDは、全部 guest にするとか。自前のIDでログインしている場合には、(ユーザ設定にある)自前のアイコンで表示される、とすると、管理者と不特定多数とをシステム的に区別もできて望ましそうな気もする。

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

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

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

ファイルのタイムスタンプを取得できるような [[FILE:TIMESTAMP:tegalog.css]] みたいな記法を作ろうかな……。これをCSS読み込みのクエリ文字列に加えれば、「CSSが更新されたときにだけクエリ文字列も更新される」みたいにできるので、確実にキャッシュをクリアできる上に、無駄なキャッシュクリアは避けられる。

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

CSV形式(カンマ区切り)でリンクリストを登録しておけるようなフリースペース「フリーリンクリスト」みたいな機能も用意しようか……? リンクラベルとURLをカンマ区切りで1行1件で書けば、それがul+li要素で出力されるような。レコードに3列目があれば画像ファイルだと判断して画像リンクにしても良いかもしれない。(そういうのは既存のフリースペースにHTMLを書いてくれれば良いと思っていたが、そういう前提にしてしまうと、配布スキン側でデザインを用意しておきにくい問題はありそうだ。)

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

リンクを作るときに [ラベル:NF]URL みたいにすると、出力されるa要素に rel="nofollow" が加わるような機能を加えたい。(現状でも、あらゆるリンクに rel="nofollow" を加える設定機能ならあるが、それだとリンク先に応じた選択はできないので。) #済

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

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

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

てがろぐのヘルプドキュメントも、技術系ドキュメントサイトでよくある「メニュー段と本文段の2段組で、メニュー内のハイライトが現在位置に連動する」ような感じにしたいが、なんか手軽に作る方法はないものか。てがろぐの場合はメニュー項目数が多いので、そこもちょっと大変そうな気もしたりしなかったり。

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

レンタルサーバ別のセットアップ方法は詳しく用意したと思ってはいるのだが、それでもまだ情報が足りないという場合、何が足りないのだろうか。FTPソフトを使ってパーミッションを変更する方法が分からないとか、その辺の操作方法?

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

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

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

てがろぐを(不特定多数が利用できる)掲示板的に活用したいとすると、少なくとも「名前」の任意入力欄が要る。しかし、そういうUIを付け加えられるオプションを加えてしまうと、UIもデータもずいぶん複雑になるし、そもそも設定が分かりにくくなる問題がありそうな気がして、望ましくはなさそうに思っていた。のだが、てがろぐには元々「投稿本文を行単位で分解して扱う」機能があるのだから、投稿欄そのものも(スキン側で)分割して用意できる仕様を用意して、投稿欄がいくつに分割されていようとも上から順に1行目扱い・2行目扱い・3行目扱い……というようにデータに記録する仕様にすれば、あんまり複雑にすることなく掲示板のようにできるのではないか、というような気もしてきた。
てがろぐBBSモード的な案
今のところ、スキン側で投稿欄をどうにかする仕様はないし、未ログイン状態で投稿できる機能もないので、これを実現するとしたらその辺は新しく加えないといけないけども。しかし、「投稿本文を行単位で分解して扱う」機能を活用するなら、掲示板の項目数も好きなようにできるし、わりと柔軟な掲示板にできそうな気もしないでもない。

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

てがろぐ設置の創作系サイトサーチ「てがWA!」の反響がすごくて、そんなに需要あったんか、と驚いている。いや、需要あったんか、というか、てがろぐユーザがそんなに居たのか、という驚きもあったが。(笑)
サイトを拝見して、私では絶対にこう上手くは作れなかっただろうから、やはりサーチサイトの文化を理解している人が作ると違うな……と感心している。たいへんありがたい。

私が作りかけて放置している「てがろぐユーザリンク集」的なものは、だいたい以下のような形態を考えていたので「サーチ」という感じでは全然ない。
  • てがろぐが稼働していれば、内容(ジャンル)に関係なく登録可能。
  • てがろぐCGIへの直リンクと、(併載されるバナー等で)サイトTOPへの2つリンクを掲載。
  • 定期的に(登録された各てがろぐを)クロールして、タイトル・概要文・更新日時の最新情報を取得して自動更新。
  • 最終更新日時の新しい順にソートして掲載。
(もしできあがれば)単に更新日時の新しい順にリンクBOXが並ぶだけの、かなり雑多なリンク集になる気がする。
分類から探すような「サーチ」ではないので、ほぼ「一期一会」みたいな? たまたま目に付いたものにアクセスしてみるような。
なので、先の「てがWA!」と競合はまったくしないだろう。

※もし完成したら、の話である。^^;(このまま放置が続いて完成しない可能性もある。)
需要はあるっぽくて、登録者もそこそこ居そうな気配なので、製作を再開しても良いかなとは思っているのだが、1からPHPを書いているので、どちらにしても時間はかかる。

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

てがろぐCGIを1個設置しておくだけで複数個のマイクロブログを作れる仕様になっていると、便利だとは確かに思う。
例えば tegalog.cgi?file=hogehoge.xml のようなパラメータを加えることで、デフォルトのデータではなく hogehoge.xml のデータを読んで表示するような。
最初から複数のデータファイルを扱える仕様で設計を考えていれば、実現はそんなに難しくはなかったとは思うのだが、最初の開発の段階ではそうは考えなかったので、そう簡単にはいかない状態になっている。

便利だとは思うので(実現できたら個人的にも便利に活用するシーンが多々あると思うので)、時々は「何かうまい方法はないかな?」と考えはするのだが。

ハードルは主に2点。

まず、パラメータを絶対にずっと維持しないといけない点。
file=hogehoge.xml というパラメータでアクセスされた後は、あらゆるリンクに &file=hogehoge.xml を漏れなく加える必要がある。どこか1カ所でも抜けてしまうと、そのリンクを踏んだときにデフォルトデータへのアクセスに戻ってしまう。現状のてがろぐ内には(ページ移動でも管理画面内でも)多数の移動経路があるので、本当に漏れなくパラメータを維持させられるか確認するのが面倒という話。(^_^;) これは、「一時適用スキンの維持」と同じ仕組みが使えるので、そこまで大きな問題ではないかもしれないが。ただ、スキンの場合なら「いつの間にかデフォルトスキンに戻っていた」といってもそんなに問題にならないだろうけども、データファイルの場合はそうとも言い切れない。例えば、本当は hogehoge.xml から10件削除するつもりだったのに、デフォルトの tegalog.xml から10件削除されてしまった、とかちょっとダメージが大きそうだし。なので、実装してみてもその厳重な動作テストが要るよな……というハードル。

もう1つは、キャッシュも設定もすべて同じファイル tegalog.ini に記録されている点。
複数のデータを扱う仕様を考慮していなかったので、てがろぐの動作設定も、カウント値とかのキャッシュデータも、何もかもを全部一緒くたにして1つのINIファイルに保存する仕様になっている。なので、複数のデータファイルを扱えるようにするには、既存のINIファイルから「動作設定」部分と「キャッシュ」部分とに分離してファイルを分けないといけない(気がする)。とはいえ、動作設定もデータファイルごとに分ければ良いのではないか(むしろその方が便利かもしれない)という考えもあるかもしれない。しかし、動作設定には「動作に関する設定」だけでなくて「ユーザ一覧情報」も含まれているので、そこを分離すると困る(ユーザ情報は同じデータをずっと保持しないとログイン状態が維持できないので)。
まあ、それなら「ユーザ情報」と「動作設定・キャッシュ」の2つに分割すれば良いのではないか、という話はあるが。

ただ、複数のINIファイルが存在する可能性を一切考慮せずに作り始めたシステムなので、CGIが実行された時点でとりあえずINIを問答無用で読み込むような処理になっている。なので、そこを変えるなら、かなり最初の段階の動作から変更することになるので、連鎖的に変更しないといけなくなる分量が多くなりそうだ。従来なら最初に1回問答無用で1つのINIファイルを読んでおけば良かっただけのところを、INIファイルAだけを問答無用で読み、パラメータに応じてどのINIファイルBを読むのかを判断して読まないといけないわけだし(※これにはさっきの「本当に読むべきファイルの方を間違えずに読み続けられるのか」という問題もある)。そうすると、ただでさえスパゲッティ気味なソースが、救いようのないほどこんがらがるのではないか、という懸念もある。なので、そのような改変を加えるなら、まずは大規模にリファクタリングをして、ソースを綺麗に整頓してからでないと危険だろう。……というハードル。

あと、細かい話だが、
設定ファイルを2つ分割すると、デフォルト状態(=マイクロブログを1個しか用意しない状態)でも2つの設定ファイルが要ることになるので、構成ファイルの数が1個増える。
できるだけシンプルに見えるようにしたいという思惑もあるので、構成ファイル数を増やしたくないという思いもある。
CGIなのでパーミッションの設定をしてもらわないといけないので、ファイルは少なければ少ないほど望ましい。もちろん、1個増えただけでそんなに手間が増えるわけではないのだが。「1個だけで済むのか」は詳しく考えてみるまで分からない。とにかく、あらゆるデータは全部INIファイルに放り込んでいる仕様なので、もしかしたら3つに分割しないとやっていけないかも知れないし。

……というように、わりと考えないといけないことがかなーり結構たくさんあるので、(実現したら便利になるだろうとは思うのだが)なかなか手が出せない。

で、そこまでするのと比較すると、もう「てがろぐを2つ設置してくれ」となるわけである。(笑)

もしかすると、「設置を1個で済むようにする」よりも、「自動でバージョンアップできるようにする」方が、役に立つのではないか。設置を1個で済ませたいのは、バージョンアップの手間を省きたい、という理由も大きそうだし。

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

>>2361 ただ、標準添付スキンをベースにしてちょっとだけ(配色とかを)書き換えるだけの小さなカスタマイズだけをして使っていて、バージョンアップのたびに標準添付スキンも(自分のカスタマイズ箇所だけを書き換えて)上書きアップロードしている……という場合、標準添付スキン側のソースが大改造されてしまうと困る可能性がある問題はあるかもしれない。そういう使い方をしているユーザさんが居るかどうかは分からないが……。

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

画像のタイムスタンプ(≒画像ファイルのUP日時)を出力できる記法って要る?

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

てがろぐ標準添付の各スキンは、IEを考慮したCSSになっているので、さすがにそろそろ全面的にモダンなソースに書き換えた方が良い気はしている。気は。特に2段組の作り方。

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

今、唐突に気付いたのだが。てがろぐ配布ZIPの中には、データファイルが3つ含まれている。tegalog.xml と tegalog.ini と psif.cgi だ。これらは、バージョンアップ時に誤って上書きしてしまうとデータが消えてしまうので、あえて 2017年 という古いタイムスタンプにして収録してある。その場合、仮に全ファイルをまとめて上書きアップロードしようと操作してしまっても、FTPソフトで「新しい場合にだけアップロード」みたいなオプションを使っていれば、上書きが阻止されるだろうから。仮にその機能を使っていないとしても、展開したファイルを更新日時でソートすれば、上書きが必要なファイルだけが上に並ぶだろうから。
……のだが、ZIPの展開ソフトによっては、中身を展開した時点で元ファイルのタイムスタンプを破棄して、「展開した瞬間の日時」に書き換えてしまうのもあるのな……。その場合、あえてタイムスタンプを古くしてある配慮に意味がなくなる。
てがろぐZIP
そして、Windowsの標準機能でファイルを展開した場合も、元のタイムスタンプは破棄されて「現在日時」がタイムスタンプになることに、いま気付いた……。_(┐「ε:)_
なんでやねん。┌(:3」└)┐

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

投稿日時として50年以上前の日付(1973年とか)を指定したとき、相対時間表記(=投稿時点からの経過時間の表記)が正しくなくなる問題を修正した。さすがにそんな日付で投稿するユーザは居ないと思うが。エポック秒から日時を割り出す localtime では「年」の値が1900年からの相対値で得られるので、日時をエポック秒に変換する timelocal でも「年」の値をわざわざ「西暦-1900」にしてから渡していたが、この方法だと「現在から50年以上前の日付」に対しては未来の日付だと解釈されてしまう仕様らしい。解説を読んで初めて知った。localtimeとは違って、timelocalの年の値は最初から西暦4桁をそのまま渡せる仕様なので、何も加工せずに西暦4桁の数値を引数に与えれば良いのだった。

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

一定の間隔(月一とか週一とか)で、データファイル(tegalog.xml)と設定ファイル(tegalog.ini)を指定のメールアドレスに自動送信するバックアップ機能でも用意しようか……?

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

設定画面の「フリースペース」に、『上書きスタイル』という専用の汎用入力欄を設けておいて、そこにCSSソースを書けるようにして、それをhead要素の最後に読み込む仕様にしようか。そうすると、標準添付スキンをそのまま利用していて毎回上書きしている人でも、自力で作成した配色スタイルだけはずっと維持できる。(head要素の最後に読み込めば、そこに書かれている内容でスタイルが上書きされるから。)した。#済

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

そうか。予約投稿機能も作らないとな……。作った。#済

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

インライン系要素の中にブロック系要素を入れると、ブロック系要素の開始位置でインラインが終わったと解釈されてしまうHTMLの仕様があるので注意が必要だ。
てがろぐが出力する [[COMMENT]] には、ブロック系の要素が出力されることがある。例えば、箇条書きリストの <ul>~</ul> とか。なので、もし <p>[[COMMENT]]</p> のようなHTMLを書いてしまっていると、<p><ul>~</ul></p> と出力されることになる。これはHTML的には誤りで、<ul>タグが登場した時点でp要素は終わったと解釈されてしまう(=HTMLの文法的に、p要素の内側にul要素を含めることはできないため)。なので、CSSが意図通りに適用されなくなる問題が出る。
このような問題を避けるには、とにかく [[COMMENT]] を『ブロック系要素を含められないような要素』で囲まないこと。
[[COMMENT]] を何かで囲みたい場合は、div要素だけを使うと考えておくのがお勧めである。

……という話をFAQに追加しておきたい。カスタマイズ方法ページに書いた

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

正式版リリースの場合でも、β版で普段やっているように「バージョンアップ用のパッケージ」(=更新されたファイルしか入っていないZIP)を用意する方が良さそうな気配だな……。容量の問題ではなくて、上書きしちゃいけないファイルを上書きしないようにするために。

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

てがろぐのログイン画面では、IDをプルダウンメニュー(セレクトボックス)から選択するようになっている。これは、「自分のIDをここから現実的に選べる程度の人数が上限と考えてくれ」という感じの意味合いもある。仕様上はユーザ数の上限はないのだが、データベースを使っていない構造からしても、たくさんの人数が同時に投稿し合うような用途に使うのは現実的ではない。管理者権限を持つIDを複数作成することもできるが、Aさんが設定画面にアクセス→Bさんが設定画面にアクセス→Aさんが設定を変更して保存→Bさんが設定を変更して保存……のようなタイミングで操作されると、Aさんの設定変更はなかったことになる。(そういう操作から保護するような機能は一切ない。)「全員が1つのTLを共有する」形なので、まあ、そんな大人数で使われる(使おうと思われる)ことはないだろうと思ってはいるのだが。具体的にどれくらいが上限だとかは何も考えていないのだが、せいぜい「数人」くらいが現実的なのではないかと思ってはいる。

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

Twitterから全データをダウンロードすると、ツイート本体は tweets.js というファイルの中にJSON形式で入っている。"full_text"という項目にツイート本文があって、"created_at"という項目に投稿日時がGMTで入っているので、この2つを抜き出して tegalog.xml で使えるXMLに変換すれば、過去ツイートをてがろぐ形式にはできるだろう。てがろぐ側には文字数制限がないので、そのまま抜き出すだけで良いだろうし。Twitter側には文字を装飾する機能がないのでプレーンテキストだし。たぶん、\n<br>に変換するくらいの手間だけで良いような。掲載URLが全部 t.co ドメインになっているのはどうしようもないが。GMTの日付は「Thu Nov 03 11:54:17 +0000 2022」みたいな形式で収録されているので、これをJSTに直した上で YYYY/MM/DD hh:mm:ss 形式にしないといけないが。PHPとかにその辺のことを楽にできる関数でもあっただろうか? ただ、画像は面倒くさそうだ。画像は tweets_media フォルダにまとめて格納されているので、"media_url"項目にあるURLからファイル名部分を抜き出して、さらに"expanded_url"項目にあるURLから数字列を抜き出して、「1588137486144114688-FgoyWg9aAAEKTjj.jpg」みたいにハイフンで繋げれば、画像ファイルを特定はできそうだけども。全部この方法でいけるのかどうかは分からん。

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

せめて配色部分だけでもカスタム変数にしてCSSソース冒頭にまとめておく方が親切かな、という気もしないでもない。ただ、カスタマイズする人はもっと全体的にカスタマイズするだろうから、配色だけカスタム変数にしてもあまり意味ないのではないか、という気もする。

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

画像インデックスXMLファイルを直接編集する方法については、どこに書こうか迷ったのだが、投稿データファイルであるtegalog.xmlの直接編集方法を「FAQ・豆知識」ページに書いていたので、それと同じにしておいた。
大量の画像キャプションを一括設定(編集)したい場合は、XMLデータを直接編集すると楽かもしれない
全画像データの先頭には、全画像データをまとめた <total>~</total> という情報行があるのだが、ここは実データから常に自動更新されるので、手動でXMLファイル内を編集するときにここを自力で計算して書き換える必要はない。てがろぐ側で再生成されるまで、画像総数とかトータルサイズとかの表示が正しくなくなるが、表示上の問題なので特に不都合はないだろう。すぐにてがろぐ側で画像インデックスを更新させれば問題は何もない。そもそもこの <total>~</total> 行は削除しても(すぐにてがろぐ側で再生成させるのなら)何も問題はない。

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

あと1時間以内くらいにはリリースできるはず……。

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

標準添付各スキンのCSSでは、figcaption要素に display: table-caption を適用している都合で、figure要素に border プロパティで枠線を付けても、キャプションは枠線の外側に表示されてしまう。「キャプション自体も含む画像ボックス全体」を枠で囲みたい場合は、border プロパティではなく outline プロパティを使って線を引く方法はある。ただ、outlineプロパティで引いた線は、border-radiusの影響外なので、線の角を丸めることはできないが。

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

てがろぐの投稿をePub形式に出力して、そのまま電子書籍リーダーで閲覧できるようにならんかな?

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

てがろぐの公式ドキュメント内で何かを探す場合には、まず、「使い方・設定方法」ページや「カスタマイズ方法」ページや「FAQ・豆知識」ページをブラウザで表示した上で、[Ctrl]+[F]キーを押してブラウザの検索窓を開いて、ページ内検索して頂きたい。たいていこの3ページのどこかに情報があるので、3ページで探せば見つかるのではないか。^^; 細かくページを分けていないので、サイト内検索窓を使って検索してもあまり役に立たない気がする。というか、細かくページを分けていないのは、ブラウザ側のページ内検索機能で探しやすくするためでもある。

by nishishi. <265文字> 編集

代わりに誰か書いてくれー。_(┐「ε:)_

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

ドキュメントをー、書くのがー、想像以上にー、面倒くさい。_(┐「ε:)_

by nishishi. <36文字> 編集

さすがに昨日のでは見づらすぎるので、リリースノート用の項目を整理した。
20230105002348-nishishi.png
目次の段階でそこまで詳しく書かんでも良いだろうし、開発段階のToDoとしては別項目でも、ユーザ側から見れば「単独の新機能」に過ぎない項目もあるので、統合できるのは統合した。分かりやすくする目的もあるが、何より項目数を減らさないと(リリースノートを)書きにくいので。

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

今後のβ版では、追加機能の解説をFanbox上に書くのではなくて、β版の追加機能の説明自体も本番解説サイトに追記していくようにしたい(正式版にはまだ含まれていない機能であることは、『β版』みたいななんかタグで示しておけば良いだろう)。そうしないと、正式リリースのたびにドキュメントを書く作業がめちゃくちゃ大変で、気力が維持できない……。_(┐「ε:)_
特に今回は、めちゃくちゃ多いから……。
20230103221827-nishishi.png
もうちょっと手前で正式リリースを刻むべきだった……。orz

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

てがろぐの設定画面で表示/非表示を切り替えられる機能については、できれば設定画面の設定項目を利用して消してくれると嬉しい。
CSSを使って消されてしまうと、
  • てがろぐ設定画面での設定でON/OFFできなくなる。
  • バージョンアップで新たに追加された機能による出力があっても(CSSによって)最初から見えないままになる。
という問題があるので……。(それに、設定画面で非表示にすれば、無駄なHTMLが出力されるのを防げるメリットもある。)
いや、どう使うのも自由なので、本人が理解した上でCSSで消すなら構わないのだけど。

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

集中してドキュメントを書く日を作らないと、いつまで経っても書き上がらない気がする。1月の早い内に確保したいが……。

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

ドキュメントの追記だけで1ヶ月くらいかかりそうやな……。_(┐「ε:)_

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

Powered by てがろぐ Ver 4.2.3.

DASHBOARD

■開発放言について

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

編集

■全文検索:

■日付検索:

■カレンダー:

2023年5月
123456
78910111213
14151617181920
21222324252627
28293031

■ハッシュタグ:

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

539件

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

2024年03月20日(水) 14:34:18