2024年の投稿［60件］ - 開発放言 - にししらぼらとりー

さんごよみのヘルプドキュメント拡充を早めに済ませたい。Ver.2をリリースするために。

by nishishi. ⌚ 2024年12月10日(火) 21:49:41〈14時間前〉さんごよみ＜43文字＞編集

てがろぐのデータファイル tegalog.xml の中身が人間にもそのまま見やすいXMLベースのテキストデータなのは、てがろぐを使うのをやめる場合にも書いた内容を他のツールに転用しやすくする目的もある。……のだが、文字装飾機能が増えた結果、「生のデータ」をそのまま他のツールに持っていこうとすると、（てがろぐ独自形式の装飾を使っている場合には）少々手間がかかってしまう。最初からプレーンテキストしか投稿していないならその問題はないのだが。最初期のてがろぐにはプレーンテキストしか投稿できなかったので、そこまで考えていなかった。てがろぐ独自の文字装飾機能をすべて排してエクスポートできる機能を用意すると（最後には）良いのかもしれない。

by nishishi. ⌚ 2024年12月06日(金) 21:59:58〈4日前〉てがろぐ＜316文字＞編集

にしし

No.2533

付箋を付ける機能。表示はされず、ログイン者のみが確認できるような。投稿本文にはコメント機能があるので、画像の方にあると便利かもしれない？

by nishishi. ⌚ 2024年12月01日(日) 14:24:15〈9日前〉てがろぐ＜68文字＞編集

にしし

No.2532

新規投稿した直後にだけ、あらかじめ指定しておいたURLにping的なものを飛ばす仕組みを加えると、「新規投稿したタイミングに合わせて外部サービスでも同時に何かする」みたいな仕組みが作れて、何かの役に立つかもしれない……？

by nishishi. ⌚ 2024年11月30日(土) 13:58:03〈10日前〉てがろぐ＜110文字＞編集

にしし

No.2531

解決した。>>2530 丸括弧1対と「?」記号の計3文字を追加するだけで、正規表現2セットを1セットにまとめられた。ちょっと考えれば分かるので、最初からそうしておくんだった。_(┐｢ε:)_ とはいえ、この方法だと若干の（害のない）副作用はあるのだが。それもなくすことはできるが（その方法は思いついたが）、動作速度の面でよろしくないかもしれないので、「まあ、害がないならいいか」ということで副作用は容認することにした。

by nishishi. ⌚ 2024年11月18日(月) 21:31:28〈22日前〉てがろぐ＜209文字＞編集

にしし

No.2530

ああ、そういえば、No.4785で指摘された不具合をまだ解消していなかった。┌(:3」└)┐ そこを何とかせねば。たぶん、2つの正規表現で実現している部分を、1つの正規表現で実現できるように知恵を絞れば解決するはずだ。たぶん。たぶん。

by nishishi. ⌚ 2024年11月17日(日) 20:05:31〈23日前〉てがろぐ＜117文字＞編集

にしし

No.2528

新しい「未使用画像を探す」機能は、わりとうまくできたような気がする。

by nishishi. ⌚ 2024年11月10日(日) 14:15:12〈30日前〉てがろぐ＜34文字＞編集

にしし

No.2527

Fumy News Clipperの動作サンプルの公開をひっそり終了した。ここに書いたら「ひっそり」ではないかもしれないが。「Fumy News Clipper」は2000年代に開発したCGIで、「てがろぐ」の前身になったCGIである。Fumy News Clipper側に存在する機能の大半は、てがろぐ側にもある。本文中にHTMLを直接書ける機能だけはFumy News Clipper側にしかないので、今でもCGIの配布自体は続けているが（てがろぐ側にその機能ができるまでは公開は続ける予定ではある）。もはや継続開発の意欲はないことと、何でも書ける動作サンプルがありすぎると管理しきれないので、サンプルだけは閉じることにした。（『表示はできるが投稿はできない』というようなデモモードを搭載していれば良かったのだが、Fumy News Clipperにはそういう仕様を用意していないので。いまさら追加するのも面倒だし、もはや需要もそこまでないだろうから。）

by nishishi. ⌚ 2024年11月08日(金) 09:52:18〈33日前〉 Fumy News Clipper ＜429文字＞編集

にしし

No.2526

アーカイブ機能があれば良いのかもしれない。投稿の編集画面で「アーカイブする」ボタンを押すと、その投稿の中身を指定のテンプレートに沿って静的なHTMLファイルに出力できるような機能が。それをそのまま公開しても良いし、そのファイルを自力で再編集してWebページとして好きな場所で公開しても良いし。

by nishishi. ⌚ 2024年10月26日(土) 12:56:48〈45日前〉てがろぐ＜146文字＞編集

にしし

No.2525

今月中にはVer 4.4.4βを公開したいのだが、そのためには未使用画像を探す機能を（主な処理をJavaScriptで実行させることで）ローカルマシンパワーを使って実行するよう作り直す必要がある。そのためには、ある程度まとまった時間と気力が必要なので、なかなか進まない。_(┐｢ε:)_

by nishishi. ⌚ 2024年10月12日(土) 12:30:14〈60日前〉てがろぐ＜143文字＞編集

にしし

No.2524

てがろぐ完全版パッケージ(ZIP)に同梱している各種スキンも、もうちょっと現代的なCSSに修正したいと思う気持ちもなくはないのだが（今のはまだ「IE考慮」を含んでいるくらい、かなり古いブラウザでも閲覧できるソースなので、あまり現代的ではない）、面倒くさい。_(┐｢ε:)_ 最近はありがたいことにスキンを配布して下さる方々も増えたので、もう「そっちを使ってくれ」という気にもなっている、という点もあってなおさら。
そもそも、てがろぐに添付している各種スキン（のうち標準スキンではないスキン）は、元々「そのまま使ってもらう」ことはあまり考えていなくて、カスタマイズできる幅を示すのが主な目的だった。付箋型スキンとか、黒板スキンとかが特にそうだ。標準スキン・付箋型スキン・黒板スキンくらいを見れば、『スキンを書き換えるだけで、わりといろいろカスタマイズできそうだ』と思ってもらえるだろう、という考えで。なので、今でも時々、付箋型スキンや黒板スキンをそのまま活用しているページを目撃すると驚く。(笑)

by nishishi. ⌚ 2024年10月12日(土) 12:27:23〈60日前〉てがろぐ＜447文字＞編集

にしし

No.2523

というか、検索アルゴリズムの問題だよな。大学とかのプログラミング講義でほぼ最初の方に出てくるあれだ。線形に検索するから時間が掛かるのであって、もうちょっと何か賢い検索アルゴリズムを採用しろという話だ。

by nishishi. ⌚ 2024年09月20日(金) 22:33:22〈81日前〉てがろぐ＜100文字＞編集

にしし

No.2522

てがろぐ関連のアナウンス場所をもうちょっと何か一元化した方が良いよな……。公式サイト、動作試験場、PixivFANBOX、Pawoo、Twitter とかで分散し過ぎな気がする。

by nishishi. ⌚ 2024年09月19日(木) 21:43:47〈82日前〉てがろぐ＜89文字＞編集

にしし

No.2521

未使用画像を探す処理が重たい問題は、処理すべき内容を一旦JavaScript用に出力して、ブラウザ側で検索処理を実行して、その結果だけをCGIが受け取ればよいのではないか。実行速度はローカル端末の性能に依存するだろうけども、どれだけ時間が掛かってもサーバに負荷はかからないし。JavaScriptで実行するなら、プログレスバーとかで進捗を見せることもできるだろうし。

by nishishi. ⌚ 2024年09月19日(木) 21:22:09〈82日前〉てがろぐ＜183文字＞編集

にしし

No.2520

昨年、てがろぐVer 4.1で搭載した「投稿No.を1から連番で振り直す機能」は、あくまでも『連番でないと抜けが気になって嫌だ！』という気分になる人のために用意した機能であって、別に『そうしないと動かない』からあるわけではないよ、という話をどこかに書いておいた方が良いのかもしれない。現在の仕様では、投稿番号は連番である必要はないし、降順である必要もなく、重複さえしなければどうでも良い。（重複していてもとりあえず表示はできるのだが、再編集したくなっても最初に見つかった1つしかできない。）ただ、将来的な無用なトラブルを避けるためには、連番でなくても良いが、少なくとも降順ではある方が望ましいとは思う。

by nishishi. ⌚ 2024年09月13日(金) 15:16:12〈88日前〉てがろぐ＜301文字＞編集

にしし

No.2519

ローカルで稼働しているてがろぐと、Web上で稼働しているてがろぐとで、データや設定の同期を簡単に取れるような仕組みがあると便利なのかも知らんな……と、ちょっと思ったりした。（思っただけ）

by nishishi. ⌚ 2024年09月12日(木) 18:20:02〈89日前〉てがろぐ＜93文字＞編集

にしし

No.2518

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

by nishishi. ⌚ 2024年09月02日(月) 21:32:32〈99日前〉てがろぐ＜345文字＞編集

にしし

No.2517

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

by nishishi. ⌚ 2024年09月02日(月) 19:20:04〈99日前〉てがろぐ＜147文字＞編集

にしし

No.2516

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

by nishishi. ⌚ 2024年09月02日(月) 17:40:47〈99日前〉てがろぐ＜177文字＞編集

にしし

No.2515

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

by nishishi. ⌚ 2024年08月25日(日) 20:20:00〈107日前〉てがろぐ＜217文字＞編集

にしし

No.2514

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

by nishishi. ⌚ 2024年08月22日(木) 15:29:09〈110日前〉てがろぐ＜127文字＞編集

にしし

No.2513

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

by nishishi. ⌚ 2024年08月11日(日) 12:06:53〈122日前〉てがろぐ＜256文字＞編集

にしし

No.2512

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

by nishishi. ⌚ 2024年08月05日(月) 21:58:48〈127日前〉さんごよみ＜100文字＞編集

にしし

No.2511

ああ、ダメかも知らんな……。details要素とsummary要素で作る折り畳み機能だと、span要素とかの内側には文法的に書けないので、安易に実装してしまうと本文中の装飾が崩れることになる。

details要素の親要素になれるのは「フローコンテンツを受け入れる要素」だが、
span要素の内側に書ける要素は「記述コンテンツ」のみ。

昔の言い方で言うところの「インライン要素の中にブロックレベル要素は書けない」という話だが。
まあ、自由装飾機能みたいに、デフォルトでは非表示にしておいて、「分かっている人だけONにしてくれ」という形態で実装しておく方法でも良いかもしれないけども。ただ、既に隠せる装飾機能が存在することを考えると、あえて（よく分かっていない状態で使うと他のデザインが崩れる可能性のある）機能を加える必要性もなさそうな気もする。

by nishishi. ⌚ 2024年08月04日(日) 16:49:11〈128日前〉てがろぐ＜375文字＞編集

にしし

No.2510

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

by nishishi. ⌚ 2024年08月01日(木) 20:58:41〈131日前〉てがろぐ＜114文字＞編集

にしし

No.2509

悪質な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. ⌚ 2024年07月27日(土) 23:13:12〈136日前〉開発ネタ＜734文字＞編集

にしし

No.2508

以下の3記法を新設した。（全部、[設定]→[補助出力]で設定できる値を表示する機能。「状況に応じた見出し」の出力用途くらいにしか使っていなかった。）

[[GALLERY:NAME]] :ギャラリーモードの名称を挿入
[[PICTS:NAME]] :画像一覧モードの名称を挿入
[[SITEMAP:NAME]] :サイトマップページモードの名称を挿入

要望を頂いて、そういえばその記法はなかったな、と気付いた。需要があるとは思っていなかった、というのもあるけども。広く需要があるのかどうかが分からないので、まあ検討リストに入れようかな、と一瞬思ったのだが、そもそも処理が極めて簡単だったので、何も考えずに実装した。

by nishishi. ⌚ 2024年07月25日(木) 22:10:43〈138日前〉てがろぐ＜310文字＞編集

にしし

No.2507

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

by nishishi. ⌚ 2024年07月23日(火) 09:12:21〈141日前〉てがろぐ＜137文字＞編集

にしし

No.2506

今日は、てがろぐの開発をずいぶん進んだ。ただ、あまり表には見えない部分の実装だけども。いろんな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. ⌚ 2024年07月21日(日) 21:09:42〈142日前〉てがろぐ＜843文字＞編集

にしし

No.2505

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

by nishishi. ⌚ 2024年07月14日(日) 16:40:18〈149日前〉てがろぐ＜87文字＞編集

にしし

No.2504

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

by nishishi. ⌚ 2024年07月07日(日) 21:01:07〈156日前〉＜51文字＞編集

にしし

No.2503

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

by nishishi. ⌚ 2024年07月07日(日) 19:01:15〈156日前〉＜49文字＞編集

にしし

No.2502

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

by nishishi. ⌚ 2024年07月07日(日) 17:28:18〈156日前〉＜86文字＞編集

にしし

No.2501

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

by nishishi. ⌚ 2024年07月07日(日) 17:23:35〈156日前〉＜71文字＞編集

にしし

No.2500

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

by nishishi. ⌚ 2024年07月07日(日) 17:14:45〈156日前〉てがろぐ＜235文字＞編集

にしし

No.2499

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

by nishishi. ⌚ 2024年07月06日(土) 19:40:20〈157日前〉てがろぐ＜201文字＞編集

にしし

No.2498

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

by nishishi. ⌚ 2024年06月10日(月) 14:22:50〈183日前〉＜136文字＞編集

にしし

No.2497

実装を検討している各機能について、どれくらいの需要があるのかの把握が難しい。アンケートを採るくらいしか手段がなさそうなのだが、アンケートを採っても（昨年の夏に採った）、この結果は「その時点での需要」でしかない上に、「それ以降に検討対象に加わった機能」については需要が分からない。もうちょっと何か、リアルタイムに需要を把握できるような仕組みを作れると望ましいのだが。そこでなんとなく思ったのは、（作りかけておきながら放置している）てがろぐユーザリンク集のアカウントに投票権を持たせて、検討中機能リストに投票できるようにする仕組みである。この方法を使って、

検討中機能リストにある各機能に、それぞれ「欲しい」・「とても欲しい」みたいな回答(投票)ができる。
検討中機能リストに項目を追加すると、その時点で投票項目が増える。
投票内容(回答内容)は何度でも変更可能で、「以前は不要だと思っていたが今は欲しいと思うようになった」みたいな場合にはいつでも変更できる。

という感じにすれば、リアルタイムに需要の多寡を把握し続けられそうな気がする。もちろん、ユーザリンク集の利用者がそれなりに多ければの話だが。ユーザリンク集のアカウントを利用すれば、

現役てがろぐ利用者に限定した投票ができる。
1つの検討中機能に対して、同一人物が他票を投じるのをある程度は防げる。

というメリットもありそうなので、より正確なデータが得られそうな気もする。いや、協力者(投票者)がそれなりに居たら、の話だが。┌(:3」└)┐

by nishishi. ⌚ 2024年06月04日(火) 12:48:45〈189日前〉てがろぐ,開発ネタ＜655文字＞編集

にしし

No.2496

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

by nishishi. ⌚ 2024年05月21日(火) 23:28:35〈203日前〉てがろぐ＜76文字＞編集

にしし

No.2495

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

by nishishi. ⌚ 2024年05月20日(月) 22:52:11〈204日前〉てがろぐ＜114文字＞編集

にしし

No.2494

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

by nishishi. ⌚ 2024年05月13日(月) 18:01:02〈211日前〉開発ネタ＜120文字＞編集

にしし

No.2493

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

by nishishi. ⌚ 2024年05月04日(土) 17:54:34〈220日前〉てがろぐ＜90文字＞編集

にしし

No.2492

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

by nishishi. ⌚ 2024年04月09日(火) 02:18:31〈246日前〉てがろぐ＜78文字＞編集

にしし

No.2491

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

by nishishi. ⌚ 2024年04月02日(火) 22:36:02〈252日前〉てがろぐ＜89文字＞編集

にしし

No.2490

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

by nishishi. ⌚ 2024年04月01日(月) 22:46:09〈253日前〉てがろぐ＜108文字＞編集

にしし

No.2489

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

by nishishi. ⌚ 2024年03月16日(土) 01:24:13〈270日前〉てがろぐ＜230文字＞編集

にしし

No.2488

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

by nishishi. ⌚ 2024年03月13日(水) 00:27:31〈273日前〉開発ネタ＜186文字＞編集

にしし

No.2487

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

by nishishi. ⌚ 2024年03月09日(土) 22:07:53〈276日前〉てがろぐ＜98文字＞編集

にしし

No.2486

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

by nishishi. ⌚ 2024年03月08日(金) 17:44:47〈277日前〉開発ネタ＜141文字＞編集

にしし

No.2485

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

とはいえ、簡単に書ける記法もある方が望ましいので、単に [[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. ⌚ 2024年03月04日(月) 01:44:32〈282日前〉製作中ツール＜792文字＞編集

次の50件»

1 2

初期表示に戻る

DASHBOARD

■開発放言について

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

編集

ランダムに1件を表示

RSSフィード

■全文検索：

■日付一覧：