NO nop_thread
- ログインID: nop_thread
- 登録日: 2022/09/01
- 最終ログイン: 2026/07/17
チケット
プロジェクト
| プロジェクト |
ロール |
登録日 |
| 生活 |
全体管理者, プロジェクト内管理者 |
2026/03/01 |
| Journal |
全体管理者, プロジェクト内管理者 |
2026/01/26 |
| 設備・備品管理 |
全体管理者, プロジェクト内管理者 |
2026/03/01 |
| 趣味・娯楽 |
全体管理者, プロジェクト内管理者 |
2026/03/01 |
| コンテンツ鑑賞 |
全体管理者, プロジェクト内管理者 |
2026/03/01 |
| 鯖缶 |
全体管理者, プロジェクト内管理者 |
2024/03/15 |
| 人生管理運用 |
全体管理者, プロジェクト内管理者 |
2024/03/15 |
2026/07/17
-
NO
09:29
鯖缶
機能 #486: 統合通知チャネルの選定
- nop_thread さんは #note-17 で書きました:
> 「詳細を確認したかどうか」とか「処理済みかどうか」のような状態を管理したくば他の手段を使うほかないだろう。
古いものから順番に処理するとは限らないことから考えても、通知そのものをプライマリな機能とするアプリは基本的に設計思想と用途が合わないと思われる。
また、処理済みのアイテムは非表示にする機能 (名目は削除でも「アーカイブ」でも未読フィルタでも何でもよい) が欲しいことを考えると、 Matrix ...
nop_thread
-
NO
09:24
鯖缶
機能 #486: 統合通知チャネルの選定
- ntfy の機能はやはり通知であって、TODO リスト的な使い方がしづらい。
つまり対処を後回しにする可能性のあるタスクを積むのに向いていない。
プライマリな機能としてリアルタイム通知の発信がある。
加えて ntfy の web UI やアプリには、非アクティブ期間の開いていなかった通知に未読フラグを立てて提示してくれる機能もある。しかしこの未読フラグはアプリでチャンネルを確認した瞬間に全てがリセットされるので、「この通知だけあとで再確認する」のようなことはで...
nop_thread
2026/07/15
-
NO
05:53
鯖缶
機能 #62: ポスターとタペストリーのカタログ管理
- データ入力に先立って写真か画像を用意しておく必要があるかもしれない……。
nop_thread
-
NO
05:52
鯖缶
機能 #62: ポスターとタペストリーのカタログ管理
- nop_thread さんは #note-11 で書きました:
> #1136 で [Mathesar](https://mathesar.org/) という RDBMS のリッチなフロントエンドのようなものを立てたので、これが使えるかもしれない。
たぶん使える。
実際にデータを入れてみないと (できれば画像の扱いも確認してみないと) なんともいえないが、最悪の場合 URI で代用することもできるので、やりようはある。
nop_thread
-
NO
05:47
生活
機能 #1134 (進行中): 蔵書管理のセットアップ (と、蔵書の洗い直し) (2026-07)
- nop_thread さんは #note-5 で書きました:
> #1135#note-7 のとおり、真面目に (ILS が想定する形で) 使おうとすると相応の理解と習熟を求められる気がしてかなり時間がかかることが想定されるので、一旦スプレッドシートで誤魔化す。
nop_thread さんは #1135#note-13 で書きました:
> ...
そういうわけで、当面は Mathesar で RDB を使って管理する。
既に28冊ほど入力してみたが、まあやれるだろう。...
nop_thread
-
NO
05:45
鯖缶
機能 #1135 (終了): 蔵書管理方式の検討
- ##1136 で立てた Mathesar で実際にデータを入れてみたところ、少なくとも在庫管理には十分使える (それなりに使いやすい) ことがわかったので、当面はこれを使って管理する。
とはいえ Koha 等の “ちゃんとした” ILS を使うことを諦めたわけではない。
そちらは ##625 の状況なども考えつつ追々ということで。
nop_thread
-
NO
05:42
鯖缶
機能 #1136 (終了): Mathesar インスタンスを立てる
- nop_thread さんは #note-8 で書きました:
> 使い物になるかはこれから確認する。
非常に使いやすい。
たとえば foreign key で参照しているカラムの編集で、参照先レコードを再帰的なダイアログで新規作成して必要なレコードを作ったら戻ってくる、といった画面遷移の抑制された web UI が整備されている。
foreign key のカラムにどう表示されるかについても (foreign key を辿った先のレコードの値まで使って) カ...
nop_thread
-
NO
05:20
シリーズ購入管理
機能 #933 (進行中): 魔法医レクスの変態カルテ (バンチコミックス, 新潮社)
- 5巻が 2026-07-09 に発売。
nop_thread
2026/07/14
-
NO
13:05
braindump
機能 #1012: タスクやチケットの「優先度」とは何?
- nop_thread さんは #note-9 で書きました:
> 結論としては、「優先度」は工数割当の優先度と着手・再開の優先度を、担当者固有の重みづけと担当者固有の期間での平滑化によって、担当者固有の尺度へと評価した値と解釈すると整合しやすい。
この平滑化に使う期間の長さが私にとってどの程度であるかは、たぶんちゃんと考える必要がある。
nop_thread
-
NO
13:04
braindump
機能 #1012: タスクやチケットの「優先度」とは何?
- ## 評価値と平滑化
Redmine や Vikunja にデフォルトで用意されている優先度には非対称性がある。
Redmine の「低め」「通常」「高め」あるいは Vikunja の「低」「中」「高」の3つは割当工数の配分としても解釈できるが、 Redmine の「急いで」「今すぐ」や Vikunja の「至急」「大至急」の2つは自然に考えれば行動順 (キューの先頭への近さ) あるいは緊急度を示していると受け取られるだろう。
もちろん「低め」などもすべて行動順を表現...
nop_thread
他の形式にエクスポート: Atom
ロード中...