blog
public
0が1に変わる変化とそれ以外の変化を分けて考える
10000人のフォロワーより、10人のファン、2人の友人
10年も立てばより安価で良い技術が出てくるので、10年後も同じモノを使用するということは考えないほうがいい
10日で仕上げるタスクであれば、2割の2日で8割のタスクを終わらせる
1つに絞る
1つのツールで全てをこなそうとしない
20%ルール
20点と0点を選ばないといけない場合もある
30 day challenges
3Dをアニメーションに使うことに感じる違和感は、関数の無理な共通化と似ている
<
>
トップページ
/
blog
public
0が1に変わる変化とそれ以外の変化を分けて考える
10000人のフォロワーより、10人のファン、2人の友人
10年も立てばより安価で良い技術が出てくるので、10年後も同じモノを使用するということは考えないほうがいい
10日で仕上げるタスクであれば、2割の2日で8割のタスクを終わらせる
1つに絞る
1つのツールで全てをこなそうとしない
20%ルール
20点と0点を選ばないといけない場合もある
30 day challenges
3Dをアニメーションに使うことに感じる違和感は、関数の無理な共通化と似ている
<
>
トップページ
公開情報はスナップショット
内部に閉じた
流動性の高い情報
と、外部に開いた流動性の低い情報をどう両立するか悩んでいた。
前者の例はObsidianやアウトライナー、その他メモツールやタスク管理ツール(
PKM
と呼ぶ)。
後者の例はScrapboxやサイト、その他配信ツール(
ブログ
と呼ぶ)。
内部情報
を流動性のある
信頼できる唯一の情報源(SSOT)
にして、
公開情報
は
スナップショット
で、ある時点に
ピンどめ
した情報を残すと考える。
公開情報
は時間と情報が結びつくけど、内部のPKMはそうとも限らない
これの良いところは、外部情報は
ノートを育てる
ことを考えなくて良いということ。
今(もしくは特定の時間)に正であったものを残していけばよいだけなので整合性や今後のことを考える必要がない。
それは内部情報で行って、そこから時間で
情報を輪切りに
して公開情報に切り出す。
この考え方は結構しっくり来る。
PKM
Index
Foam
PKMでタスク管理もすると終わったタスクまで候補に出てきてしまう
PKMに時間情報が自動的に付与される必要はあるか?
PKMは一日にしてならず
PKMツールの変遷
Wikiのプロジェクトはわけない方が良い
いつ書いたのかは意識しない
とりあえず中身書いてからタイトル決める
タイトルが文章化することを恐れない
タスク管理・PKMとしての分類と情報閲覧としての分類
ナレッジスタック
ナレッジログ
最終的に見つかればよい
💿PKMのための絵文字
💿❌DailyNote(タスク)とPKMは直接接続しない
💿❌インデックスページは$をプレックスにつける
📐チートシート
ブログ
COPILOT Knowledge
スナップショットログ
信頼できる唯一の情報源(SSOT)
TypeScriptの型定義の方法一覧
各チームがバラバラに点で繋がっても様々な「認識」が飛び交うだけ
スナップショット
スナップショット情報をジャンルに絞って記録する
ピンどめ
この判断があっているのかを悩むのではなく、判断を正解にする力が必要
ノートを育てる
情報を自分の言葉でまとめる
月別アーカイブ
2025年(68)
1月(14)
,
2月(54)
2024年(32)
1月(2)
,
2月(2)
,
4月(3)
,
5月(9)
,
6月(4)
,
7月(3)
,
8月(4)
,
9月(1)
,
10月(1)
,
11月(1)
,
12月(2)
2023年(41)
1月(29)
,
2月(1)
,
3月(6)
,
4月(2)
,
5月(1)
,
9月(1)
,
12月(1)
2022年(84)
1月(16)
,
2月(1)
,
3月(1)
,
4月(5)
,
6月(6)
,
7月(1)
,
8月(9)
,
9月(19)
,
10月(16)
,
11月(2)
,
12月(8)
2021年(47)
1月(10)
,
2月(3)
,
3月(4)
,
4月(13)
,
5月(1)
,
7月(1)
,
8月(1)
,
9月(3)
,
11月(2)
,
12月(9)
2020年(3)
12月(3)
2019年(5)
1月(4)
,
2月(1)