Zrcadla - proč používat osobní wiki (diskuse)

[vencour]

Jo jo, souhlasim, něco takového je potřeba. Z kvantity roste kvalita. Na vše mohu navázat. Ve všem mohu najít něco ještě jiného než jsem původně zamýšlel či v tom viděl.

[JiK]

...Z kvantity roste kvalita. Na vše mohu navázat. ..

To mas z VUMLu? O přechodu kvantity v kvalitu nas uci marxleninismus. Porad jsme v 80 letech cekali, kdy se ty, cim dal vetsi, hromady hoven zmeni v neco kvalitniho, treba zapadonemecky kazetak. A ono hovno.

[vencour]

Budiž, stejně tak jsem mohl napsat, že je fajn mít nějaký "aktivní datový sklad".

[Bystroushaak]

Co používáš ty?

[vencour]

Především wiki. A hafo poznámek v textu na různých místech v pc nebo na internetu. Zpětně vidim u sebe v blogu, že i tam něco najdu. I když se snažim psát jen to nejnutnější.
Nedávno jsem se přestěhoval, ještě to nemam doladěný k dokonalosti, i v tomhle mam skluz.

[Bystroushaak]

Jakou wiki?

[vencour]

Pořád twiki (http://twiki.org/), textové soubory, ruční editace.
V principu je to jedno, ať je to jednoduché a dobře se to zpracovává.

[fm4d]

Se clankem z naproste vetsiny souhlasim, konec koncu jsi mel leta na to me presvedcit (:D), jen bych dodal par poznamek o tom jaky je podle meho nazoru rozdil mezi osobni wiki a rozsirenim mysli.

1. System musi byt rozsiritelny, programovatelny, musi umoznovat ohnout si ho kolem tvaru myslenek, pristavet nove casti podle potreby a celkove se musi on prizpusobovat nam a ne my jemu, jinak se nejedna o rozsireni mysli, ale vezeni mysli. Tuto podminku zadny z klasickych mainstream software ala CherryTree, Evernote, Onenote, Zim etc. nesplnuje a ani se o to nesnazi. Jeden ze zpusobu jak docilit takovehoto stavu je ten, aby se nejednalo o hotovy wiki system, ale o programovaci prostredi ve kterem je tento system predprogramovan. Tuto charakteristiku splnuje napriklad Emacs (programovaci prostredi pro emacs lisp ve kterem je naprogramovan editor) a jeho built-in balik Org-mode ktere budu dale pouzivat jako priklad v tomhle komentari.

2. System musi umoznovat interakci s daty. Tento bod stavi na predchozim bodu, ktery rika, ze musime byt schopni libovolne manipulovat s chovanim a interni strukturou (kodem) systemu, s rozvadi tuto myslenku tak, ze je treba zaroven mit moznost strojove a automatizovane manipulovat s daty v systemu. Na prikladech pujde dobre videt co mam na mysli: a) Kod ktery automaticky dohledava metadata ke knizkam, prednaskam, clankum a uklada je pro budouci pouziti a zaroven nam setri praci. Napr. pokud si do casti s prednaskami chci ulozit novy talk, staci mi vlozit odkaz a system ho rozvede do zaznamu s nazvem / odkazem / delkou / odkazem na stazeny soubor ve filesystemu (ktery sam na pozadi stahne) a zaroven otaguje dnesnim datem. b) Kod ktery kontroluje data podle nami definovanych pravidel, napriklad kontroluje hromadeni nezpracovanych clanku a upozornuje nas na ne. c) Kod ktery sleduje data a upozornuje nas na nove udalosti s nimi spojene, napriklad nove knihy naseho oblibeneho autora, slevy na predmety ktere jsme si ulozili pro budouci koupi / buylist etc.

Mohl bych pokracovat dale, ale myslenka je snad zrejma. Sam jsem tyto funkce v Org-mode implementoval a prestoze to neni zcela trivialni, je to mozne.

3. System musi byt schopen aktivne s uzivatelem komunikovat, nebyt jen pasivni storage, coz znamena predevsim moznost ukladat zaznamy s konkretnim datem/periodou ve ktere chceme byt upozorneni, schopnost TODO mangmentu, celkove klasicke featury rozsirenych systemu ala GTD a dalsich. Defacto je nutne aby podobny system byl do jisty miry i centrum notifikaci z vnitrniho (tasks, agendas) a vnejsiho (checkery na ruzne udalosti, crawlery, parsery) sveta. Emacs nativne podporuje notifikace a existuji baliky ktere se timto problemem zaobiraji.

4. System musi byt pristupny i mimo workstation, pro neustaly pristup k nasim myslenkam a zaroven pokud integrujeme tento system s problemy bezneho zivota ala kalenar a dalsi, tak musime mit moznost notifikace a manipulace s todo tasky kdekoliv. Toto je slabe misto PC-based systemu a velika vyhoda pomerne jednoduchych systemu ala Evernote nebo OneNote, kdy je tabletova/mobilni experience na podobne urovni jako desktopova. Trochu clumsy reseni pro Emacs je tablet s externi klavesnici a termux. Pro TODO pouzivam mobilni aplikaci Orgzly ktera se automaticky syncuje s Emacsem a mohu tak agendu planovat na pc a vykonavat skrze mobil a zpetne propagovat zmeny.

5. System musi mit nastroje jak pracovat s velkym mnozstvim dat, jak se vyrovnat s neprehlednosti a schopnost generovani jinych pohledu nez je jen textovy. Typicky priklad je mindmapa, ruzne vizualni pohledy na propojeni nodu, grafy, etc. Toto je do velke miry zatim neprozkoumana oblast, existuje mnozstvi aplikaci ktere se zabyvaji ciste timto probleme (The Brain napriklad) a doporucuju si nektere z nich vyzkouset, je to podnetne a zajimave, ale jsou to izolovane systemy delajici spravne jednu vec a nic jineho. Resenim ve svete Emacsu a Org-Mode jsou opet ponekud clumsy protoze jsou graficke schopnosti Emacsu pomerne omezene, ale i tak existuje mnozstvi zajimavych baliku ktere umi generovat staticke nahledy nad daty ala https://github.com/theodorewiles/org-mind-map, take existuje mnozstvi projektu, ktere implementuji ruzne strategie organizace a vizualizace poznamkove struktury ala org-brain a nebo org-wiki.

[Bystroushaak]

Jo, to je ta next gen věc. Sám k tomu mám desítky stránek poznámek a požadavků, ale to tu teď asi řešit nechci.

[fm4d]

Jasne, ja chtel puvodne jen zminit to, ze existuji jine pristupy nez single-purpose pomerne hloupe aplikace jako CherryTree, mozna jsem trohu presahl obsah clanku.

[pedro]

Souhlas, chtel jsem tady upozornit prave na Emacs. V zaplave vsech moznych podobnych SW mne Emacs a Org-mode pripada zdaleka nejsilnejsi.

Z pohledu uzivani na desktopu jsem kdysi mel rad myslenku s tray ikonou v Tomboy, to je mozna jedina vec, ktera mi u Emacsu trochu chybi.

[Heron]

+1

Bez wiki (ať už je to realizováno jakkoliv), si život vůbec neumím představit. Používal jsem a používám kde co všechno, (mediawiki, freemind, gitlab, markdown soubory a jejich snadné zveřejnění třeba pomocí jekyll). Ono je to asi nakonec jedno, asi neexistuje jeden univerzální systém. Na něco se hodí freemind (zejména na rychlé zaznamenání momentálního nápadu, kdy stačí ukládat hierarchii hesel o něco dřív, než myšlenka zmizí z mozku), na něco stačí jen textové soubory, na něco skutečná wiki.

A na něco třeba papíry. Takže na každém stole několik tužek a nějaký ten papír. Zejména na nákresy, grafy, schemata apod. Nevím jak to vhodně digitalizovat, tak to prostě proženu scannerem a strčím do wiki.

Co si myslím, že je hodně důležité, tak ty myšlenky občas setřepat a udělat z toho třeba článek. Je hezké, že mám ve wiki postup instalace něčeho (u instalace každého nového systému si vedu instalační deník, kam opravdu zapisuju každý balík, každé nastavení, každou blbost), ale potom je dobrý to vzít, pročistit, ověřit a zveřejnit. U těch osobnějších věcí je zase dobrý to zkusit zobecnit a ven s tím.

[_]

Geniální, kdysi jsem používal něco podpbného, ale data jsem neměl moc zkomprimovaná, a tak tvorba trvala moc dlouho. Zkusím navázat.

Také mne napadlo, co takhle si udělat osobní wiki z databáze? Tenký klient pro zobrazování dat a dělání sql dotazů, a bum, mám knowledge base i s dotazovacím jazykem.

[Bystroushaak]

Tak pointa osobní wiki je, že k tomu máš nějaké hezké GUI s WYSIWYG klikátkem a tak. Když tohle nepotřebuješ, tak ti stačí prostě pár texťáků/.html naházených ve složce.

[_]

Update k meditaci za účelem znásobení programátorských dovedností.

---

Východní kultury mají dlouhou tradici jak meditací, tak značně efektivních bojových umění, které z velké části opět stojí na meditaci. Kubáč to kdysi krásně vysvětlil. Dlouhé drily na první pohled zbytečných pohybů veskutečnosti pomáhají zadrátovávat určité reflexy a pohybové rutiny do částí mozku starající se o pohyb. Následná meditace poté slouží k tréninku utišení a vytlačení ostatních mozkových center ve chvíli boje. To aby se nepletly perfektně nadrilovaným pohybovým centrum do prace.

---

Něco na podobném duálním principu existuje pro programování, jen ještě zbývá lapit všechny kousky skládanky dohromady.

---

1) Určitou formu mentálních drilů určených k posílení a zadrátování myšlenkových rutin využívaných při vývoji.

2) Meditace na utišení a vytlačení ostatních (s vývojem nesouvysejících) center ve chvýli zostřeného vývoje.

2.1) Určitá forma likvidace emocí za účelem zklidnění myšlenkového moře je také zajímavá idea.

Nyní se věnuju tréninku obyčejné meditace, jakožto základnímu stavebnímu kameni pro cokoli dalšího.

Co se týče bodu 2, cítím že v tom bude hrát svou roli vizualizace a primitivní operace nad stromy (ať již operací či dat), grafy a maticemi.

[Rob]

můžu dotaz na "soukromý život" (vztahy/potomci) - v jakém to máš stavu?

[Bystroushaak]

Nevím, jestli se mi to chce řešit zrovna tady. Proč?

[Rob]

nemyslel jsem to útočně - spíš mě zajímalo jestli při takovým záběru "koníčků" může zbýt čas na tyhle věci

[Bystroushaak]

Tak já neříkám, že jsi to myslel nějak útočně. Jen prostě nevím, se mi to moc nechce řešit tady pod blogem, speciálně když je to úplný offtopic.

Měl jsem teď asi deset měsíců přítelkyni, nedávno jsme se nejspíš rozešli. To je asi všechno, co k tomu řeknu, fakt se mi to tu nechce řešit.

[_]

:(

[helb]

Copak, neimponovalo ji, jak tvoje duše září víc než ostatním a jaká jsi celebrita?

[.]

+ 1

[iji]

Cherrytree ma verzi pro Android zatim jen na TODO listu. Resil nekdo osobni wiki i se syncrhonizaci mezi vice zarizenimi, zejmena mobilnimi?
Vim, ze Onenote a Evernote klienty maji, ale zde je pro mne nestravitelne, ze data jsou ulozena v cizim cloudu.

[Pavel Křivánek]

Co TiddlyWiki

[iji]

Kdysi jsem ji zkousel, ale z nejakeho duvodu zavrhl. Kazdopadne ji opet podrobim zkoumani.

[coques]

Pár dní dozadu som musel ručne prepísať celú wikinu do novej verzie tiddlywiki. Síce sú na to nejaké upgrade nástroje, ale moc to nefungovalo. Každopádne zostávam pri nej, zatiaľ som nič lepšie nenašiel. Ak bude najhoršie skúsim este dokuwiki v docker kontajnery, nech sa s tým človek moc nepatlá.

[Josef Kufner]

To bych asi řešil Gitem.

Já tedy na poznámky používám úkoly ve vyhrazeném CalDAV kalendáři. Do wiki nebo něčeho komplexního to má však daleko.

[ehm]

Spíš to vyrenderovat do HTML a rsyncnout na soukromý web server, nebo tak něco. Aspoň by se to dalo číst a nahackovat se to dá relativně snadno. Asi by se dalo vyjít z toho Bystroushaakovo convertoru s tím, že to každý node vyexportuje jako jeden HTML soubor. Pak tam prostě přihodit jednu stránku s table-of-contents, ze které se půjde proklikat na jednotlivé nody. Vizuálně hezčí by samozřejmě byla navigace v bočním panelu vlevo, ale tam zas bude nutné řešit responzivitu.

[Bystroushaak]

Ehm, to by byla snaha udělat z „offline“ wiki „online“ wiki, kde nevím, proč bys rovnou nepoužil nějaké webové řešení.

[ehm]

To by byla snaha si v obchoďáku přečíst, že nemám zapomenout koupit toaleťák, protože výsledek voleb mívá těžce projímavý efekt, a mít jistotu, že provozovatel webové služby mi tam nenarve reklamu na konkrétní značku hajzláku, kterou nutně musím koupit, jinak si prošoupu prdel až do Severní Koreji.

Jaký je rozdíl mezi offline a online wiki? Proč je špatně chtít si poznámky z CherryTree (nebo Zimu, nebo čehokoliv jiného) přečíst na mobilu?

[Bystroushaak]

Jaký je rozdíl mezi offline a online wiki?

Ta první je prostě program v počítači, co nabízí trochu lepší responzivnost a funguje bez internetu.

Proč je špatně chtít si poznámky z CherryTree (nebo Zimu, nebo čehokoliv jiného) přečíst na mobilu?

Špatné na tom není nic. Jen mi přijde víc užitečné mít možnost ty poznámky upravovat - osobně na mobilu většinou chci přidávat třeba nové todo body, než číst si něco co jsem napsal. V tomhle je imho lepší klasická webová wiki, kde to můžeš z mobilu rovnou upravit.

[ehm]

Asi ti rozumím. Ty to bereš tak, že bez editování to není plnohodnotné a vyvíjet to by byla ztráta času, když už je lepší to rovnou udělat pořádně. Je to tak?

V podstatě bych souhlasil, nebýt toho, že už jsi naprogramoval (k úplně jinému účelu) tu nejsložitější část. Tohle je prostě workaround, který rychle ošetří potenciální bolestivý případ, kdy se fakt nutně budu potřebovat do těch poznámek podívat a nebudu mít počítač.

Taky mám zálusk na něco, co bude i editovatelné (podobně jako ty, jen mířím trochu jiným směrem), ale tam to vynaložené úsilí bude o několik řádů větší, takže v mezičase mi docela dává smysl takovýhle workaround řešit (nemluvě o tom, že zmigrovat ty poznámky taky nebude hned; o to se čas, kdy mi poznámky můžou chybět v nejméně vhodnou chvíli, prodlužuje).

To asi udělám.

[Josef Kufner]

Jak už jsem psal, prostě to úložiště spravuj Gitem. V mobilu Git a SSH funguje taky.

[ehm]

Takže si pak budu číst ten surový .ctd, nebo co? Fakt to nechápu.

[Bystroushaak]

Já používám na synchronizaci Syncthing.

[marbu]

+1 za git, ono existují i wiki, které používají git jako storage backend, např. gitit.

[xvasek]

Cherrytree ma verzi pro Android zatim jen na TODO listu. Resil nekdo osobni wiki i se syncrhonizaci mezi vice zarizenimi, zejmena mobilnimi?
Vim, ze Onenote a Evernote klienty maji, ale zde je pro mne nestravitelne, ze data jsou ulozena v cizim cloudu.

Ještě existuje Google Keep. Když už používám gmail a Google search, tak jim tam šoupnu i ty myšlenky, just to be sure. Pak si tam člověk udělá seznam přání a hned vypadají stránky líp, když se v reklamách zobrazují Lamborghini, tropické ráje a relaxační lehátka místo vysavačů a přípravků na hubení švábů.

[hydrandt]

Bohuzel to taky z principu nechci mit resene nejakou proprietarni sluzbou.

Zatim teda nemam nic. Ted jsem zkousel orgzly, docela fajn, mozna do toho pujdu. Obrazky budu muset holt dodavat pozdeji rucne na pc

[Kate]

Dobrá alternativa Keepu je v tomhle ohledu Turtl. Nespornou výhodou je client side šifrování.

[hydrandt]

Taky jsem Turtl vcera nasel, vypadalo to docela dobre. Ale nakonec me to zklamalo: Bud muzu mit poznamku, nebo obrazek. Nemuzu mit obrazek v poznamce.

[.]

Zrcadlo je ti k ničemu, když nejsi schopný vidět, že jsi debil. Koukej dopsat a publikovat tu svoji knihu. Těším se na ohlasy.

[Bystroushaak]

Ty jo. Koukal jsem tak do logu, co jsi všechno napsal na abclinuxu, abych ti mohl přidělit reputaci a na základě ní si vzít tvou radu třeba i vážně. Jsem však zaražen, nad stále stejným patternem, kde někomu něco „autoritativně“ pohejtuješ, ale prakticky se přitom nezapojuješ do diskuzí a celkově jsi nepříjemný jak prdel. Co si od toho konkrétně slibuješ? To má být nějaká filosofie, nebo to děláš nevědomě, jen tak mimochodem? Jakože co dává za smysl chodit do náhodných diskuzí a psát tam pokaždé nějakou variantu na hejt?

• /blog/LinuxGangster/2017/8/wikileaks-uvolnil-dokumenty-z-projektu-dumbo/diskuse#42
• /blog/dumblog/2017/2/usx-1.0-novy-format-pro-textove-a-binarni-reprezentace-dat/diskuse#18
• /blog/dumblog/2017/2/usx-1.0-novy-format-pro-textove-a-binarni-reprezentace-dat/diskuse#19
• /blog/bystroushaak/2017/8/vytvareni-prostoru-oteviranim-dimenzi/diskuse#15

[JS1]

Ja pouzivam org-mode, ale jen velmi lamersky. Ruzne poznamkovace jsem zkousel, ale vzdy po par letech prestaly byt podporovane. Typicky jsou vic nez plaintext (ze umoznuji treba menit trochu styl), ale zjistil jsem, ze to jednak zbytecne odvadi pozornost od text a druhak to zhorsuje prenositelnost. Org-mode je stabilni reseni.

Jinak by se mi libilo, kdyby existoval strojove citelny jazyk, jakym treba zapsat jak neco udelat na pocitaci. (A ne, nechci skriptovaci jazyk.)

[marbu]

Org mode používám na organizaci úkolů a krátkých poznámek, ukládám to do gitu a edituju vimem :)

[xkucf03]

Někde jsi tu psal, že bys tu osobní wiki chtěl řešit ideálně objektově… Já jsem nad tím teď taky trochu přemýšlel a za hodně důležitou vlastnost považuji historii, verzování – abych se mohl vracet zpět, abych mohl bez obav promazávat (kdybych to chtěl obnovit, tak můžu, takže mne to neomezuje v tom, dělat si v poznámkách pořádek), abych věděl, kdy která část vznikla… Máš nějak vymyšlené jak tohle řešit, jak tam dostat tu časovou dimenzi? Resp. počítáš vůbec s verzováním?

Nejjednodušší je vyplivnout data do nějaké textové serializace a tu uložit do verzovacího systému, ale to není úplně optimální, protože jednak verzovací systém (resp. diff) nerozumí tomu formátu a bere to jen jako řádky textu, a jednak pokud chceš používat nějaký WYSIWYG/WYSIWYM editor, tak těžko promítneš tu informaci o tom, kdy která část vznikla, odkud se přesunula atd. protože tu historii eviduješ jen na úrovni řádků zdrojáku/serializace. Možná by šlo použít nějakou databázi a ukládat si všechny provedené operace – takže by si člověk mohl přehrát žurnál a dostat se do nějakého bohu v minulosti – ale zase to neřeší to zpětné dohledání (kdy vznikl daný uzel?). Nebo použít databázi, která tu časovou dimenzi nativně podporuje…

[Bystroushaak]

Někde jsi tu psal, že bys tu osobní wiki chtěl řešit ideálně objektově… Já jsem nad tím teď taky trochu přemýšlel a za hodně důležitou vlastnost považuji historii, verzování – abych se mohl vracet zpět, abych mohl bez obav promazávat (kdybych to chtěl obnovit, tak můžu, takže mne to neomezuje v tom, dělat si v poznámkách pořádek), abych věděl, kdy která část vznikla… Máš nějak vymyšlené jak tohle řešit, jak tam dostat tu časovou dimenzi? Resp. počítáš vůbec s verzováním?

Ano.

Nejjednodušší je vyplivnout data do nějaké textové serializace a tu uložit do verzovacího systému, ale to není úplně optimální, protože jednak verzovací systém (resp. diff) nerozumí tomu formátu a bere to jen jako řádky textu, a jednak pokud chceš používat nějaký WYSIWYG/WYSIWYM editor, tak těžko promítneš tu informaci o tom, kdy která část vznikla, odkud se přesunula atd. protože tu historii eviduješ jen na úrovni řádků zdrojáku/serializace. Možná by šlo použít nějakou databázi a ukládat si všechny provedené operace – takže by si člověk mohl přehrát žurnál a dostat se do nějakého bohu v minulosti – ale zase to neřeší to zpětné dohledání (kdy vznikl daný uzel?). Nebo použít databázi, která tu časovou dimenzi nativně podporuje…

Jsi nepochopil objektově. Tím myslím skutečné objekty v paměti. Historie je prostě property .history obsahující odkaz na předchozí verzi objektu. Že je to paměťově náročné? No a? Optimalizace budu řešit, až je budu potřebovat. Serializace je fajn, ale beru to jako export. By default chci mít textové ukládání, ale do formátu objektů programovacího jazyka nezamýšlenou pro lidskou editaci. Mým cílem je mít z toho v každém kroku pokud možno vždy existující objekty bez jejich transformování do běžných formátů, proto to chci stavět nad image-based systémem. To má taky další výhodu, že tvůj systém je doslova programovací jazyk a IDE, což posouvá scriptování taky někam úplně jinam.

Osobně bych to hrozně rád založil na Selfu, ale mé průzkumy zatím ukazují, že na to nejspíš není ready. Prototype based OOP by na to sedělo hrozně moc (doslova máš jen objekty a jejich reprezentace, kód není specifikován nikde jinde v nějakém class browseru), ale momentálně si pohrávám se Smalltalkem.

Ale uvidíme. Jsem spíš ve fázi zkoumání konkrétních frameworků a jazyků a vší silou se snažím odolat cukání si navrhnout vlastní.

[xkucf03]

Jsi nepochopil objektově. Tím myslím skutečné objekty v paměti. Historie je prostě property .history obsahující odkaz na předchozí verzi objektu.

Ano, nad tím jsem taky přemýšlel, jenže tady nejde zdaleka jen o paměťovou náročnost. Nevím, jak v těch objektech („property .history“) namodelovat plnohodnotnou historii. Představ si, že si napíšeš nějaký odstavec na stránku X, ale pak zjistíš, že patří spíš na stránku Y, tak ho přesuneš. Jak to bude zaznamenané v historii objektů? Budeš mít uložené starší verze stránek X a Y, které budou mít shodou okolností stejné časové razítko? Bude tam někde zaznamenaná ta vazba, že to je pořád ten samý odstavec a jen se přesunul z jednoho místa na druhé? Mě by totiž občas zajímala informace typu „kdy jsem poprvé začal přemýšlet o …“ (tom, co je v tom odstavci).

Taky mi přijde, že uvažuješ o jakýchsi objektech typu „stránka“ (a pak asi nějaké kategorie/štítky/složky nad tím, což jsou jiné typy objektů). Já bych mnohem radši viděl celou tu wiki jako jeden strom/graf složený z uzlů – kde uzel je všechno: kořen, kategorie/složka, štítek, stránka, nadpis, odstavec, formátovaný/vyznačený text (obdoba <b/>, <i/>, resp. spíš sémanticky vyznačený text), odkaz, obrázek… tzn. jednotný model – něco jako kdyby celá wiki byla jedno obrovské XML, což je taky strom uzlů, jedna hierarchie – na vyšší úrovni by byly ty kategorie, stránky, pak obsahy stránek… ale celé by to byl jeden strom, ve kterém by šlo přesazovat uzly z místa na místo. Zřejmě by to nebylo XML, ale logickým modelem se to tomu nejvíc podobá. A k tomuhle bych potřeboval přidat tu časovou dimenzi. Když např. tučně vyznačím kus textu, tak to znamená, že se textový uzel přesunul do uzlu něco jako <strong/>, který je ve stromu na místě toho původního textového uzlu – ne, že se změnil nějaký řádek a ne že vznikla nová verze nějaké stránky. Pojmenované verze (obdoba commit ve verzovacích systémech) mohou seskupovat více atomických změn, ale zaznamenané by tam měly být i ty jednotlivé změny/operace. (běžný verzovací systém neví o tom, že se přesunul odstavec odněkud někam nebo že se změnilo formátování – pro něj prostě jen nějaké řádky/bajty zmizely a jiné se objevily, ale „nechápe“ proč a jaký to má význam)

Nicméně celé je to jen teorie – udělat něco tak dokonalého mi přijde dost pracné a nevím, jestli to za to stojí. Takže v současnosti to řeším tak, že mám disku složku „znalosti“ a v ní různé podsložky, kam sypu jak soubory od ostatních (obrázky, schémata, PDF, výstřižky z webu), tak svoje poznámky (většinou .txt soubory, někdy .xhtml nebo .xml, občas .tex). Časem si nad tím udělám nějaké indexování a vyhledávání, metadata uložím asi do rozšířených atributů souborů a historii zajistím Mercurialem. Je mi sice proti srsti cpát binární soubory do verzovacího systému, ale tady to asi nějak skousnu.

[Josef Kufner]

To, co popisuješ, se jmenuje ontologie. (Viz také RDF, OWL a Nepomuk.)

Takové poznámkovadlo by vydalo na pár pěkných diplomek a co jsem ve škole koukal, tahle technologie je ještě docela v plenkách a je tam spousta prostoru pro seberealizaci.

[Bystroushaak]

V tomhle doporučuji přečíst si knihu Dreaming in code ^{(Scott Rosenberg, 312s, 978-0-307-38144-6)}. Osobně jsem si z toho, a taky ze studia, které jsem na tohle téma dělal v knihovně, odnesl poučení, že čemukoliv, co má v názvu ontologie, je dobré se vyhnout velkým obloukem. Zatím tak nějak všichni, kdo se do toho pustili skončili v hluboké propasti řešení napůl neřešitelných filosofických problémů.

[Josef Kufner]

To vůbec nerozporuju. Ale zas na druhou stranu to nemusí celé vymýšlet znovu a utopit se v tom, když se v tom může utopit rovnou

[xkucf03]

Tyhle ontologie každého jen otravují :-)

Ne, já o tom vím, i když jsem to zatím nějak moc do hloubky nezkoumal. Ale to, co jsem tu popisoval, mělo být trochu jednodušší a asi by to šlo poskládat i z hotových nástrojů – vzít nějaký SŘBD, který by udržoval tu časovou dimenzi (jenže jaký?) a do této databáze prostě nacpat ten strom. Pak by to chtělo WYSIWYM editor, kterému bys ukázal na část stromu a on by ji vykreslil jako stránku a umožnil editaci, to už je trochu složitější. A k tomu si dopsat nějaké indexování, štítkování atd. to už je poměrně jednoduché (technicky).

Ale dohromady je to pořád spousta práce, takže se do toho asi v nejbližší době nepustím. Přeci jen bych chtěl dělat radši nějakou reálnou práci, než si jen „organizovat poznámky“ (i když i to je důležité). Takže v té složce ~/znalosti jsem udělal hg init a párkrát hg add a hg commit a zatím to budu udržovat takhle. Časem přidám nějaké indexování a vyhledávání, symbolické odkazy (např. pro štítky) a rozšířené atributy souborů (další metadata) + něco na jejich správu, možná nějaký lepší editor/prohlížeč… Třeba to jednou přehodím do něčeho lepšího – ten jednotný strom a sémantické verzování pořád považuji za ideál, ale ta pracnost prostě převyšuje můj osobní užitek z toho.

[marbu]

Takže v té složce ~/znalosti jsem udělal hg init a párkrát hg add a hg commit a zatím to budu udržovat takhle. Časem přidám nějaké indexování a vyhledávání, symbolické odkazy (např. pro štítky) a rozšířené atributy souborů (další metadata) + něco na jejich správu, možná nějaký lepší editor/prohlížeč…

Takže něco jako ty wiki ukládající data do gitu, jak se tady v jiném komentáři snažím propagovat? :)

[xkucf03]

Ano, je to něco podobného. Akorát spíš než k webu směřuji k nějaké desktopové aplikaci – hodilo by se mít kombinaci správce souborů (Dolphin), GUI k verzovacímu systému (Tortoise Hg), prohlížeče souborů (Okular, Gwenview, Firefox/Chromium) a editoru (to je zatím nejslabší část – chtěl bych dobrý WYSIWYM editor) + indexování, vyhledávání, štítky a nějaký nástroj pro jejich správu. Rád bych se držel blízko souborovému systému, tzn. metadata jde ukládat do rozšířených atributů, propojení udělat přes symbolické odkazy a dovedl bych si představit i smysluplné využití nějakého FUSE souborového systému, který by přidával funkcionalitu.

Ono, když se tohle dotáhne do konce, tak se to složitostí pracností už blíží tomu ideálu, co jsem tu popisoval o kousek vedle (jednotný strom uzlů s integrovaným verzovacím systémem), ale na rozdíl od něj lze tento ekosystém budovat iterativně a užitečný/použitelný je už v té první/nejprimitivnější fázi (soubory + adresáře + Mercurial).

[marbu]

Jo, pro osobní použití bych tu git based wiki nechal běžet na lokálním stroji, takže bych pořád mohl k souborům přistupovat přímo, pokud by se mi to hodilo.

[xkucf03]

kde uzel je všechno: kořen, kategorie/složka, štítek, stránka, nadpis, odstavec, formátovaný/vyznačený text

P.S. resp. ne nadpis, ale kapitola (jejímž atributem je nadpis) – a pod uzlem kapitoly jsou uzly dalších kapitol nebo odstavců. Tzn. nemělo by to vypadat tak, jako v HTML, kde nadpis a jemu podřízené odstavce jsou ve stromu na stejné úrovni.

[Bystroushaak]

Chápu jak to myslíš. Do velké míry se ale imho zaměřuješ na řešení problémů, které ve skutečnosti nejsou problémy. To trackování toho kde se vzaly jednotlivé části by bylo asi fajn a umím si ho představit v mém systému, ale ruku na srdce - jak moc velkou má tohle prioritu? Je to docela minoritní featura, kterou já třeba nepotřebuju prakticky vůbec a když už náhodou ano, tak se dá řešit fulltext pattern matchingem nad historií.

Jinak mi přijde zábavné, jak máš do velké míry stejnou představu, jako já. Přijde mi, že ta myšlenka se tak nějak vznáší v prostoru, jako mrak nabitý energií, který jen čeká, až z něj vyšlehne blesk do nějakého konkrétního projektu, který jí uzemní.

Taky mi přijde, že uvažuješ o jakýchsi objektech typu „stránka“ (a pak asi nějaké kategorie/štítky/složky nad tím, což jsou jiné typy objektů). Já bych mnohem radši viděl celou tu wiki jako jeden strom/graf složený z uzlů – kde uzel je všechno: kořen, kategorie/složka, štítek, stránka, nadpis, odstavec, formátovaný/vyznačený text (obdoba <b/>, <i/>, resp. spíš sémanticky vyznačený text), odkaz, obrázek… tzn. jednotný model – něco jako kdyby celá wiki byla jedno obrovské XML, což je taky strom uzlů, jedna hierarchie – na vyšší úrovni by byly ty kategorie, stránky, pak obsahy stránek… ale celé by to byl jeden strom, ve kterém by šlo přesazovat uzly z místa na místo. Zřejmě by to nebylo XML, ale logickým modelem se to tomu nejvíc podobá. A k tomuhle bych potřeboval přidat tu časovou dimenzi. Když např. tučně vyznačím kus textu, tak to znamená, že se textový uzel přesunul do uzlu něco jako <strong/>, který je ve stromu na místě toho původního textového uzlu – ne, že se změnil nějaký řádek a ne že vznikla nová verze nějaké stránky. Pojmenované verze (obdoba commit ve verzovacích systémech) mohou seskupovat více atomických změn, ale zaznamenané by tam měly být i ty jednotlivé změny/operace. (běžný verzovací systém neví o tom, že se přesunul odstavec odněkud někam nebo že se změnilo formátování – pro něj prostě jen nějaké řádky/bajty zmizely a jiné se objevily, ale „nechápe“ proč a jaký to má význam)

:)

Mrkni se na Self a na jeho objektový model. Vážně :)

[zzz]

Tem tvojim pozadavkum (vsechno je uzel stromu) trochu odpovida Dynalist - https://dynalist.io/

[xkucf03]

Dík, to vypadá zajímavě. Ten proklik, kterým si člověk zobrazí danou část stromu, to je přesně ono. Tedy samo o sobě to nestačí, ale zrovna tahle část je to, jak jsem si to představoval.

[marbu]

Trochu jsi mě nakoplnul, abych nějakou osobní wiki konečně pro sebe nasadil. Zatím používám spoustu různě (ne)ogranizovaných soborů v plain text formátu (org mode, rst, markdown, ... podle toho, co se hodí nejvíc) a největší překážka v nasazení je překonání současného nepořádku, podobně jako když jsem kdysi přecházel na správce hesel.

Před nějakou dobu jsem pro jeden projek používal gitit wiki, která ukládá data do git repozitáře a na webu je zobrazuje pomocí pandoc knihovny, takže lze použít různé textové formáty. Git pak umožnůje pohodlnou synchronizaci, případně off line použití a následné řešení konfliktů. A díky tomu, že se používají už existující textové formáty, lze s takto organizovanými daty pracovat přinejhorším i bez gitit samotného (stačí git a textový editor).

Uvidíme, jak to bude fungovat jako osobní wiki, ale z mého pohledu je to v podstatě dokonalý design. Navíc si nedovedu moc představit, že bych si nepsal poznámky v plain textu a ve vimu (nebo něčem, co jako vim funguje).

[ondatra]

Taky to aktuálně řeším. Léta jsem používal OneNote, ale nedávno jsem ho opustil.

Na OneNotu mi vadilo:

- proprietární formát. Dostat ven data v čemkoliv rozumném není úplně jednoduchý.

- není nativní Linux aplikace a web aplikace byla donedávna dost hrozná. Pomalá a neuměla vyhledávat. Teď už je to o trochu lepší.

- malý počet hierarchických úrovní. Končil jsem s mrakem poznámek na stejné úrovni hierarchie. Nakonec jsem ty poznámky vyklofal do adresářové struktury ve formátu docx a používám je tak, jak jsou.

Výhoda - možnost si soubory uspořádat, jak chci, s libovolným počtem podsložek. Snadné je přikládání souborů v dalších formátech (pdf...). Další výhodou je standardní formát. Docx/odt má prostě nejširší podporu.

Nevýhodou je omezená možnost linkování poznámek mezi sebou, ale to mi díky pružnější adresářové struktuře celkem nevadí.

Vyhledávání se dá řešit obecným trackerem typu Recoll. Výhodou je, že vyhledává i v dalších souborech.

U CherryTree a spol se bojím speciálního formátu, který jinde nezobrazím.

[Diskobolos]

U CherryTree je možné zvolit formát uložených dat v SQLite či XML. Co je na tom speciálního?