Patterny osobní wiki

25.11.2018 11:25 | Přečteno: 2920× | poslední úprava: 25.11.2018 11:26

Bystroušák v posledním blogpostu položil dobrý dotaz na to, jak používám svou osobní wiki. Tenhle blogpost má být rámcovou odpovědí, zároveň je to možnost osvětlit motivaci pro některé designové rozhodnutí v Trilium Notes. Na rozdíl od Bystroušáka (jeho kvalitní post na toto téma) se nebudu zabývat filozofií, ale jen patterny organizace dat. 

Meta patterny

Jen pro ujasnění, za meta patterny považuji patterny patternů, tzn. pattern často se objevující jako součást jiných patternů.

Hierarchická organizace

Základní meta pattern je, že poznámky řadím do hierarchie - mám určité "top-level" poznámky, které určují základní rozdělení, ty se pak dělí dál podle potřeby. Stromovou strukturu obecně považuju za efektivní způsob organizace velkého množství dat. Omezení některých software (např. Evernote) v tomto směru mě hodně deptalo, protože to zásadně limituje škálovatelnost.

Když tak mluvím o škálovatelnosti, kolik těch poznámek vlastně potřebuju mít? Počítám, že denně můžu vyprodukovat 10 poznámek denně, což je ročně 3 650, za desetiletí už 36 500. Tuhle osobní wiki (míněno primárně data, ne nutně stejnou aplikaci) plánuji používat tak nějak celý život, tzn. desetiletí (až staletí, kdo ví), tzn. se můžu klidně dostat až na 100 000 poznámek nebo víc. Momentálně mám poznámek zhruba 10 000.

Hierarchii vytvářím líně, tzn. nesnažím se prvně vytvořit strukturu, kterou pak naplním. Pro dané téma vytvořím poznámku a "štěpím" pod-poznámky až když je potřeba. V tomto hodně pomáhá fakt, že v Triliu není rozdíl mezi vnitřními uzly a listy (oboje můžou mít jak obsah, tak potomky). Ve chvíli, kdy daná poznámka vyroste za hranici dobré použitelnosti, můžu některé dlouhé části textu vyčlenit do podpoznámek. Klasický filesystém nutí uživatele do "všechno nebo nic" přístupu - pokud je soubor moc dlouhý a chcete jej přeměnit na adresář, je nutné vyndat a rozdělit celý obsah.

Vícenásobné umístění poznámek do hierarchie

Při organizaci poznámek do stromové hierarchie velmi brzy narazím na problém, že logicky dává smysl položku zařadit na více míst. Pokud mám např. poznámku (resp. podstrom poznámek) o bashi, tak fakt nevím, jestli jej zařadit pod "Programovací jazyky" nebo pod "Linux". Je to totiž falešná dichotomie do které nás tlačí omezenost našich aplikací - bash patří pod obě tyto poznámky! Trilium proto nepoužívá standardní strom, ale rozšíření, které každou poznámku umožňuje zařadit pod více rodičů. 

Čtenářům abclinuxu se asi rozsvítí, když řeknu, že Trilium stejně jako linuxové FS podporuje hard linky, s tím zásadním rozdílem, že jde vytvořit hard link i pro "adresář". Pro nedostatek lepšího termínu tuto funkci ale nazývám " klonování". 

Všechny "klony" jsou si ze systémového hlediska rovnocenné (což je jeden z důvodů, proč je slovo klon dost zavádějící), ale sémanticky má poznámka často primární umístění. Např. recenze knihy bude zařazena pod poznámku Knihy, ale i do denní poznámky (viz níže) - v takovém případě považuji Knihy, za primární umístění.

Chráněné poznámky

Trilium mám otevřené konstantně, občas můžu při odejítí od počítače zapomenout jej zamčít nebo jej můžu někomu vědomě na chvíli půjčit. Chráněné poznámky poskytují vyšší ochranu hodně citlivých dat (např. hesla, osobní deník) v tom, že a) data šifrují a b) každých pět minut (resp. jiný nastavitelný interval) vyžadují zadání hesla, jinak se jejich dešifrované kopie vymažou z paměti. Chráněné poznámky mám různě rozeseté po stromě - jakmile určitá poznámka překročí nějakou subjektivní hranici citlivosti, tak ji dám chránit a hotovo.

Archivace

Poznámky často časem ztrácí relevanci - například pokud změním práci, tak všechny poznámky k firemním projektům už prostě nejsou důležité. To ovšem neznamená, že je chci smazat. V takovém případě podstrom pro danou firmu označím děděným labelem archived, čímž daný podstrom vyfiltruju z vyhledáváním. 

Poznámky jde stále procházet a jinak s nimi pracovat, jen nezaplevelují výsledky vyhledávání (rychlé vyhledávání přes našeptávač je pro mě hlavní způsob navigace mezi poznámkami). 

Archivaci používám i u poznámek, které mají již od vzniku nízkou relevanci - např. importované reddit komentáře. Pokud relevantní poznámky nejdou nějak rozumně oddělit od těch relevantních nějakou kategorizací, tak si prostě vytvořím poznámku "OLD" a přesunu tam ty málo relevantní poznámky (opět s labelem archived).

Patterny

Denní poznámka

Zjednodušeně mám pro každý den jednu poznámku, která (v podpoznámkách) združuje všechno, co se daného dne nějak dotýká. Je to taková pracovní plocha a zároveň inbox - řadím tam věci, u kterých zatím ještě nemám rozmyšlené jejic zařazení a kategorizaci provedu později.

Trilium má tuto funkcionalitu částečně zabudovanou, převážně ve formě API - Trilium ví, kde a jak strukturu Rok / Měsíc / Den vytvořit (pod poznámkou s labelem calendarRoot). Mimo to existuje ještě globální klávesová zkratka CTRL-ALT-P, která vkládá novou poznámku právě pod aktuální denní poznámkou (do inboxu).

Co si pod takovou denní poznámku uložím:

• TODO list pro daný den
• osobní deník
• pokud si např. napíšu interní recenzi knihy, tak kromě zařazení pod "Knihy" si ji nechám i v denní poznámce. Obecně to tak nějak reprezentuje na čem jsem ten den pracoval.
  • Na toto mám ještě skript, který z historie poznámek vytáhne a zobrazí na denní poznámce seznam všech upravených poznámek v tento den
• pokud daný den aktivně řeším dejme tomu pracovní věci, tak si relevantní poznámky (podstromy) naklonuju pod denní poznámku, aby byly po ruce.
• Každý den se mi vytváří i datová poznámka (JSON) obsahující metriky jako váha a nějaké další věci, ze kterých mi pak Trilium kreslí grafy
• Pod denní poznámku se mi taky automaticky importují komentáře z redditu
  • Lidi jsou někdy překvapení proč mám potřebu si schovávat komentáře z nějaké sociální sítě. Mně to zas tak divné nepřijdě - typicky do komentáře vložím nějakou svou myšlenku, kterou mně stojí za to uchovat.

Většina poznámek je primárně zařazena jinam než do denní poznámky a jejich výskyt v denní poznámce je tak nějak sekundární. Tento pattern tedy do velké míry vyžaduje funkci klonování (viz výše).

Projekty

Co je projekt asi každý chápe, v mé taxonomii to ještě značí dlouhodobost (v délce roků) - příkladem může být třeba Trilium Notes. Struktura takového projektu se dost různí a nevidím nějaké jasné patterny. Co je ale vidět je silná provázanost s ostatními částmi - např. mám do projektu naklonované credentials z jiné lokace nebo blogposty o Triliu (jinak uložené v projektu Blog).

Epicy jsou vlastně to samé jako projekty, ale jsou spíš středně dobé - v délce měsíců - a proto je primárně ukládám pod "roční" (např. 2018) poznámku. Sem patří hodně pracovních věcí (které jsou samozřejmě naklonované i do poznámky "Práce"), ale i osobní (např. teď mám velký epic stěhování).

Pro krátkodobé projekty (náročnost den nebo několik dní) zatím nemám označení (i když by se mohlo hodit story) - buď je mám uložené pod měsícem nebo si je každý den přesunuju mezi denními poznámkami.

Přístupové údaje

Ukládám si credentials pro všechny služby, mám je rozdělené do kategorií (typicky práce, projekt, osobní podle země atp.). Tyto poznámky jsou samozřejmě chráněné a často naklonované do jiných částí (např. login do githubu mám naklonovaný i v projektu Trilia). Tohle je pro mě docela zásadní výhoda oproti specializovaným toolům (např. KeePass) - všechny data mám na jednom místě (bez ztráty na bezpečnosti).

Knihy

Mám standardní "To Read" seznam. Vedu si recenze knih - co kniha to podstrom, kde kořen má nějaké základní labely (autor, rok vydání, čteno od, čteno do) a má pod-poznámky "Highlights" (importované zvýrazněné pasáře z Kindle plus můj komentář), další pod-poznámka je samotná recenze a pak jak se uvidí.

Zatím tyto recenze řadím přes roky, ale mám v plánu použít již uvedené labely definující interval čtení na vytvoření nějakého timeline grafu, který bude zobrazovat co jsem četl a kdy (ne jako vlastní feature Trilia, ale jako custom skript). Jsem docela zvědavý vizuálně vidět, kdy jsem měl čtecí maratony a kdy jsem polevil.

Krom toho si ty knihy ještě klonuju pod poznámky autorů (teda jen u vybraných autorů). U poznámky autora mám pak ještě související materiály - linky na rozhovory, eseje atp.

Podobný systém mám i pro filmy a seriály, ale míň propracovaný.

Profily lidí

Tohle někomu může připadat "creepy", ale vedu si na lidi záznamy. Standardně věci jako datum narození, bydliště, kontakty, ale i třeba pracovní historii, základní info o jejich zájmech, názorech atp. - tak nějak všechno co považuji za důležité a bojím se, že to můžu zapomenout. Není nad to, když si dokážu během konverzace vzpomenout, že už jsem se X-krát dané osoby ptal na práci, ale už si nepamatuji odpověď.

Známých lidí je samozřejmě hodně a víceméně je třídím přes sociální kruhy - tak nějak odkud je znám - ze základky, vesnické hospody nebo z knižního klubu. Některé lidi znám z více kruhů zároveň, ale pak je prostě naklonuju do víc kruhů.

Speciální kategorií je kruh rodina, který je stále příliš velký a proto mám podkategorie podle "klanu", např. "Novákovi". Na rodinné vztahy se mi hodně hodí relační mapy, které jsem představil v posledním blogpostu.

U lidí si často vedu i důležité (IM, mail, i meat space) konverzace.

Dokumenty

Všechny důležité dokumenty (občanka, pas, maturitní vysvědčení atp.) mám naskenované a uložené v Triliu. Je to dobré jako záloha nebo pokud fyzické dokumenty nemám u sebe.

Inventář

Informace a dokumenty k věcem, které vlastním - např. auto u kterého si vedu datum zakoupení, datum technické kontroly a naskenovaný techničák, servisní zákroky a cena za ně atp. To samé pro telefony, PC, foťáky, jinou elektroniku atp. Tohle dělám jen pro věci, které jsou pro mě nějakým způsobem důležité.

Studijní poznámky

Tady si to vedu prostě podle jednotlivých kurzů - ať už je to Coursera, pracovní training nebo jen čtení knihy. Typicky se to dělí na nějaké jednotky - lekce, kapitoly, tréninkové dny atp. Knihy jsou samozřejmě naklonovány i do poznámky "Knihy", tréninky do "Práce", denních poznámek atp.

Osobní znalostní báze

Tady mám uložené už tak nějak sesumírované znalosti a poznatky z daných domén. Přestože to tvoří velkou část obsahu mé "wiki", tak v tom jde těžko najít nějaký pattern. Základní dělení je dost subjektivní - klasické vědy jako Filozofie, Fyzika, Ekonomie, Historie atp. ale pak třeba Apps pro popisy aplikací nebo Mental models. Je tam často překryv se Studijními poznámkami, rozdíl je v tom, že ty jsou spíš procesně strukturované.

Pracovní znalostní báze

Mám top-level poznámku pro firmu, kde aktuálně pracuji (předchozí zaměstnání jsou odsunuté jinam). Vedu si základní organizaci firmy (divize, business unity), kdo je kdo (hodí se relační mapy), projekty na kterých pracujeme atp. 

Samozřejmě si sem píšu přístupy ke spoustě firemních služeb. Firma má většinou nějaké vlastní (komplikované) procesy a tooly, které je dobré zdokumentovat. Píšu si sem shrnutí meetingů. Linkuju věci na firemní wiki (ve které je peklo něco hledat). Obecně existuje spousta specificky firemních věcích, kterou musím mít při ruce ve struktuře, které rozumím. Často jde vlastně o jakousi filtrování a transformaci dat z firemních zdrojů do něčeho mně srozumitelného.

Ze skušeností mě dokáže efektivní užití takové osobní wiki značně zvednout produktivitu a hlavně dramaticky snížit míru frustrace.

Závěr

Dalo by se pokračovat dál s výčtem dalších věcí, ale už teď cítím, že to musí být nudné i pro ty, co dočetli až sem ... Budu rád, pokud popíšete některé vlastní patterny v diskusi. Obecně považuji tyto patterny za docela přenositelné, resp. dá se z nich minimálně vytáhnout nějaká inspirace.

       

Komentáře

[Jendа]

Pěkné, hlavně že v tom máš pořádek. Já v tom mám bordel: školní poznámky v papírových sešitech podle data, generické adminovské poznámky v textových souborech, poznámky týkající se dané firmy v jejich wiki, věci co stojí za to zveřejnit na brmlabí wiki, mentální highlighty v moudra.txt a bonmoty.txt, poznámky týkající se konkrétních projektů v textovém souboru přímo v daném projektu, „osobní deník“: soubor, kam jednou za rok napíšu ~10 nejdůležitějších událostí co se mi přihodily - pomáhá to udržet časovou kontinuitu, a loguju polohu (podle okolních wifi sítí).

[luky]

zkousel jste orgmode v emacsu/vimu?

[Jendа]

Ne.

[kolcon]

vypada to dobre, ja se o neco podobneho (v mensi - pracovni - mire) snazim v OneNote. Ten ma par vyhod (mobilni klient), integrace s Widlemi v praci i nevyhod - proprietarni reseni, neexistence klienta pro Linux, nikdo nevi, jestli to MS "nevypne".

K te osobni wiki by to chtelo dodelat klienty pro android/ios a/nebo integraci do own/next cloudu...

[kolcon]

jo a jeste integraci s todo/kalendarem ;)

[Cal]

Co se tyce portu pro Android/iOS, tak tam to momentalne nevidim ruzove. Je to prilis mnoho prace pro (z meho pohledu) maly benefit - prace na takove osobni wiki nemuze byt nikdy moc produktivni.

Osobne to vcelku spokojene resim tak, ze pokud si neco chci poznamenat nebo tak neco, tak pouziju Google Keep a pak to zanesu do wiki.

Obecne mne prijde, ze tlak na podporu ruznorodych platform (hlavne smartphony) tlaci programy tohoto typu k podpore jen nejake omezene podmnoziny ficur, ktere jdou slusne realizovat vsude. Moje filozofie je spis se soustredit na hlavni platformu (PC) a ostatni platformy jsou explicitne druho rade.

Mam ale v planu udelat zjednoduseny mobile-friendly frontend pro webovou verzi, coz by melo pokryt aspon nektere use casy.

Co se tyce (predpokladam synchronizace) Owncloud/Nextcloud, tady je problem, ze toto jsou principialne souborove skladiste, kdezto Trilium Notes je charakterem spis databaze a mapovani na soubory je obtizne, coz je problem pro inkrementalni synchronizaci.

[Josef Kufner]

Ta integrace by stačila v podobě spolupráce s CalDAV kalendářem, kdy by si Davdroid na mobilu mohl synchronizovat úkoly a události s odkazy na tu webovou verzi. Tím dostaneš upozornění a provázání s kalendářem i jednoduchým úkolovníčkem (OpenTasks). To by na mobilu mělo stačit.

[Cal]

CalDAV vypada zajimave, urcite se na to podivam.

[otasomil]

Zdravim
Pekny zapisek.
Uz dost roku pouzivam DokuWiki, LionWiki, Etherpad pro jednoduchost a snadne pouziti. Co se tyce pouzitelnosti pro nasledujici roky ba i desitky let tak to vidim na prosty textovy soubor jako ma Jenda svoje Moudra. Takze se drzim wiki ktere pouzivaji pro ukladani pouhe textove soubory a pripadny prilohy jsou ulozeny zase jako soubory. Kdysi jsem uvazoval i o variante jedineho index.html souboru + pridruzene obrazky, prilohy s tim ze jak budou PC stale vykonnejsi a mit vice operacni pameti a muj adresar spolu s index.html bude bobtnat do stovek MB... tak jeho prohlizeni a vyhledavani v nem bude porad rychly a snadny. Nejak jsem vsak od tohoto upustil a jsem docela rad. Dnes mame mnoho PC, chytry telefony, tablety a to jsou vse zarizeni ktere se hodi k okamzitemu ulozeni poznamek, postrehu... Tim se pro mne stalo podstatny ulozit aktualni kus textu rychle, snadno a na jakymkoli zarizeni pripojenym do site i za cenu toho ze bude pozdeji potreba upravit, uhladit do finalni podoby ve wiki.

[kralyk z abclinuxu]

Pěkně sepsáno.

Taky jsem si nedávno začal vést wiki, v podstatě to u mě je (kontinuální) přechod od disorganizovaných poznámek v adresáři ~/doc a různých dalších místech do organizovanější wiki. Zvolil jsem software mdBook.

Můj hlavní požadavek a důvod, proč právě mdBook, je, že chci na poznámky pokudmožno používat svůj normální editor, který mám nastaven k plné spokojenosti. Nechtěl jsem se učit / nastavovat nový editor specielně pro wiki.

mdBook je primárně generátor dokumentačních brožur, tj.počítám, že nejspíše nebude vyhovovat fanouškům dynamických prototypových systémů. Mně vyhovuje díky své až primitivní jednoduchosti.

mbBook mě překvapil v tom, jak pohodlně to funguje. Je tam sice to rozdělení, že na vstupu je struktura Markdown souborů a "na příkaz" se vygeneruje html výstup, nicméně mbBook umí běžet jako démon, který si sám zdetekuje změnu ve vstupní struktuře a následně vygeneruje a lokálně naservíruje výstup, který se při změně sám reloaduje. mdBook taky umí to, že při přidání nové položky do SUMMARY.md dovytvoří soubory/složky na disku chybějící, takže operace přidání nové pozmánky nebo celého podstromu je dost snadná.

Je to sice hodně subjektivní, ale výstup mi přijde celkem velmi pěkný a dostatečně funkční - pomocí JS umí provádět rychlé vyhldávání/skákání pomocí kliku nebo klávesové zkrátky 'S'. Taky umí MathJax pro vzorce/rovnice/etc. Podpora Markdown je spíše základní, umí třeba základním způsobem tabulky, ale neumí nějaké jiné rozšíření/fíčury navíc, např. mi trochu chybí škrtnutý text (který dá udělat pomocí <s>), ale moc to neřešim.

Hierarchii vytvářím líně, tzn. nesnažím se prvně vytvořit strukturu, kterou pak naplním. Pro dané téma vytvořím poznámku a "štěpím" pod-poznámky až když je potřeba. V tomto hodně pomáhá fakt, že v Triliu není rozdíl mezi vnitřními uzly a listy (oboje můžou mít jak obsah, tak potomky).

Dělám to stejně (to štěpení do hierarchie až když je potřeba) a s mdBook to jde triviálně tak, že pro každý nový uzel udělám rovnou podsložku, tj. místo foo.md vytvořim rovnou foo/0.md a další pod-uzly do toho buď přibudou nebo ne.

Vícenásobné řazení do hierarchie se udělá tím, že se prostě daný md file dá do SUMMARY.md na více míst.

mdBook používám tak, že mám napsán krátký systemd service, který běží mdBook na pozadí pod user instancí systemd (tj. po přihlášení), service mám trvale otevřený v prohlížeči. Když chci poznámky přidávat / měnit, přepnu nebo otevřu projekt v editoru (který je vesměs taky trvale zapnutý) a provedu co potřebuju.

Pro účely archivace a záloh mam obsah wiki v gitu.

Co se týče obsahu wiki, nemam to určitě tak podrobné jako ty. Dobudoucna chci mít wiki podrobnější a organizovanější, ale asi ne až tolik. Budu se snažit najít nějaký balanc, nechci trávit neúměrné procento času psaním wiki

[Bystroushaak]

Díky za sepsání.

[Andrej]

klon mi pride ako symlink.

nebolo by lepsie zaviest nieco ako stitkovanie (labels) tak ako to maju v gmaile?

[Cal]

Klonovani ma charakter symlinku i hardlinku:

• Jako symlink to umoznuje linkovat i adresare
• Jako hard link jsou si vsechny hard linky rovnocene a soubor (poznamka) se efektivne smaze se ztratou posledniho hard linku

Labely ma Trilium taky, ale typicky je nepouzivam pro primarni organizaci. Jejich zakladni problem je, ze labely jsou "ploche" - nejdou strukturovat a proto dobre neskaluji.

[Josef Kufner]

Trochu to rozšířit a uspořádat labely do hierarchie by nemělo být moc obtížné, ne?

[Cal]

Soucasny design je vysledek dvou pozadavku:

1. je potreba mit moznost poznamky radit do vice mist/kategorii/labelu
2. vzhledem k tomu, ze danych kategorii/labelu bude moc, je nutne je mit moznost strukturovat

Je pravda, ze by se to dalo vyresit tim, ze labelum dam hierarchii, ale pak si rikam - proc tvorit jakousi druhou paralelni hierarchii, kdyz uz jednu mam (tu poznamkovou)? Vic elegantni mi prijde proste umoznit danou poznamku/podstrom zaradit do vice mist ve strome.

Puvodne Trilium labely nemelo a melo jen tohle klonovani. Do jiste miry vidim klonovani jako funkcne nadmnozinu labelu (umi vsechno co labely a neco navic) a proto labely nejsou potreba.

Labely byly pridany pozdeji primarne pro schopnost pripojit poznamkam nejaka metadata, moznost vyhledavani (napr. jde hledat @book @author=Tolkien @year>=1955) a nektere systemove potreby.

[Josef Kufner]

Tohle ale nejsou úplně typické labely jak je známe z Githubu a podobných.

Spíš než labely to vypadá jako RDF (Semantic) triples. V podstatě tam tu ontologii už máš … Mohlo by být zajímavé to trochu posunout k existujícím nástrojům a umožnit nad tím nějaké šikovnější dotazování s odvozováním. Mohlo by se to hodit, když bys nevěděl úplně přesně co hledáš. Případně by to mohlo ukázat nějaké ne úplně zřejmé souvislosti.

[Cal]

No je to nadmnozina labelu, tak jak je zname treba z githubu, ale stale se tak daji pouzit - staci vynechat hodnotu - napr. vyse uvedeny "book" je tradicni label.

Momentalne mne v kontextu osobnich wiki prijdou ontologie jako velky overkill. Nejak mne nenapada zadny konkretni use case, kdy bych ji chtel pouzit ...

[Tom.š Ze.le.in]

V emacsím org mode jde definovat hierarchii labelů a to jak výčtem tak regexpem (https://orgmode.org/manual/Tag-hierarchy.html); z toho odkazu to není vidět, ale jeden label může být ve více hierarchiích. U velkých souborů (typu knowledgebase.org) to trochu pomáhá, ale pořád je v přehlednosti rozdíl mezi zřejmou stromovu strukturou headingů a tagama přes které se musí explicitně hledat.