Patterny osobní wiki (diskuse)

[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.