bit off

Web, který nebyl (NMI18)

Mon, 12 Mar 2018 00:55:00 +0100

Když jsem psal svou diplomku, o které budu dnes mluvit, připomněl jsem si, jak velký jsem bordelář. Pokaždé, když mám zpracovat větší množství informací, propadám se do strašného chaosu, který se snažím přetavit v něco užitečného.

Můj problém není v nedostatku informací; díky webu jich můžu najít a konzumovat neomezené množství. Jenže jaké informace to jsou? Mohl bych se strefovat do plytkých fotek kafíček nebo hlubokomyslných statusů celebrit na sociálních médiích. Případně mluvit o šíření „fejk ňůs“. Jsou to některé příznaky problémů dnešního webu a informační společnosti. Já se však chci zaměřit na web jako takový.

Můj problém – a zároveň motivace proč se věnovat tomuto tématu – je efektivnější získávání znalosti z informací. Konkrétněji, jak nám k tomu může pomoci web. Jistě, téma konference jedno řešení naznačuje¹: přidejte dostatečné množství umělé inteligence a počítač to za nás všechno vyřeší. Původní představy vizionářů, o který budu za chvíli mluvit, však byly odlišné. Počítač měl být nástroj, který nám pomůže efektivněji zpracovávat informace a efektivněji přemýšlet. Neměl za nás udělat veškerou práci udělat sám. Koncept, který nám k tomu měl dopomoci, se jmenuje hypertext.

Hypertext

Hypertext znáte nejčastěji ve formě textových odkazů, které vás ve webovém prohlížeči vezmou na jinou stránku. Myšlenka hypertextu je však hlubší a vychází z konceptu a nehierarchické organizace informací.

Ve fyzickém světě jsme zvyklí organizovat předměty hierarchicky: kniha patří v knihovně právě na jedno místo, do konkrétní sekce. Organizovat takto informace je složité, protože máloco patří právě do jedné škatulky. Ve fyzickém světě nemáme jinou možnost, protože jedna věc může být jen na jediném místě.

Náš mozek neorganizuje informace do jasně dělených škatulek, ale uvažuje v asociacích: jedna informace může mít vazbu na mnoho dalších. To má právě umožnit hypertext, jako forma nehierarchické organizace informací. K jedné věci vede mnoho cest nebo je i na více místech zároveň. Uspořádat takto informace je mnohem snazší, pokud nejsme omezení fyzickým světem.

Paul Otlet (1868–1944)

To si uvědomoval i Paul Otlet, belgický právník a vizionář, který koncem dvacátého století položil základy dokumentalistiky. Z tohoto oboru se později vyvinula informační věda.

Otlet společně s Henri La Fontainem vytvořil fasetový systém Mezinárodního desetinného třídění pro klasifikaci dokumentů. Tento systém je zajímavý tím, že dílo může být zatříděný pomocí více charakteristik současně ve snaze zachytit „sociální kontext“ díla. Zároveň systém umožňuje vytvářet vazby mezi tématickými třídami, takže je možné klasifikaci rozšiřovat tak, jak se rozvíjí oblasti bádání.

Tehdy nejlepším médiem pro třídění informací byly registrační kartičky. Kromě organizace v knihovnách měly zachycovat i informace obsažené v knihách. Otlet se tak snažil informace „osvobodit“ z fyzické vazby. Jednu dobu byla v Belgii provozovaná zásilková služba, kde jste mohli zažádat o informace. Odpověď jste dostali poštou v ceně 27 franků za tisíc kartiček. Takový „protogoogle“.

Otlet si představoval, že informace budou eventuálně spravované mezinárodní institucí Mundaneum. Ta by přes globální síť shromažďovala a poskytovala informace pro celý svět. Otlet se tak do jisté míry přiblížil představě Internetu.

Skrze nové technologie se měla proměnit i forma informací a knih:

Biograf, fonograf, rádio, televize: tyto nástroje, považované za náhradu knihy, se ve skutečnosti stanou novou knihou, nejmocnějším dílem pro rozšíření lidského vědění. Toto bude rádiová knihovna a televizní kniha.

Paul Otlet: Traité de documentation

Mimo zvuku a obrazu mělo dojít i na další smysly, například měla vzniknout i čichová či chuťová kniha.

Pro představu o budoucí práci vědeckého pracovníka navrhnul specializovaný pracovní stůl Mondothéque. Ten by měl eventuálně zprostředkovávat dálkový přístup k informacím v Mundaneu:

Namísto knih je na dosah obrazovka a telefon. Jinde, v ohromné budově, jsou všechny knihy a informace. Odtud se stránka ke čtení (…) zobrazí na obrazovce. Obrazovka může být rozdělená na poloviny, čtvrtiny nebo i desetiny, pokud je zapotřebí procházet více dokumentů současně.

Paul Otlet: Traité de documentation

Shodou okolností měl za Atlantikem jiný pán podobnou představu.

Vannevar Bush (1890–1974)

Vannevar Bush byl vědec, vynálezce a vysoce postavený státní úředník. Za druhé světové války vedl americký úřad pro výzkum a vývoj. Ze své pozice viděl, jak se jednotlivé vědecké disciplíny stále úžeji specializují a obával se, že se výrazně znesnadní výměna informací napříč obory. Proto přišel s nápadem jak využít asociativní třídění namísto rigidní, hierarchické organizace informací.

Ilustrace Memexu od Alfreda Crimiho ke zkrácené verzi Bushova článku As We May Think (Life 19.11, září 1945, str. 123)

Navrhl zařízení Memex (spojení slov memory a extender). Podobně jako u Otleta se jedná o pracovní stůl pro vědomostního pracovníka. Bush byl ovšem technik, proto měl promyšlenou nejen formu, ale i mechaniku fungování takového zařízení. V Memexu jsou všechny dokumenty uložené na mikrofilmu. Nahoře na stole se nachází dvě či více obrazovek pro promítání dokumentů a ovládací panel.

Krom stolu má být pracovník vybavený i fešnou mikrokamerou připevněnou na čelo, pro rychlé focení na mikrofilm. (Ilustrace: Alfred Crimi, ibid., str. 113)

Hlavní myšlenkou Memexu je možnost vytvářet tzv. asociativní cesty (associative trails). Funguje to tak, že si uživatel zobrazí na obrazovkách dvě stránky různých dokumentů a stisknutím tlačítka mezi nimi vytvoří asociaci. Následně může přidávat další stránky, přidávat vlastní poznámky a anotace a vytvářet tak novou cestu publikacemi. Výslednou cestu může kopírovat a sdílet dál.

Ukázka práce s Memexem. Na pravé obrazovce uživatel zapisuje poznámky k materiálu který je na levé obrazovce. Poznámky jsou vyfoceny na mikrofilm a propojeny s referenčním materiálem skrze kód na spodní straně obrazovky. (Ilustrace: Alfred Crimi, ibid., str. 124)

Ačkoli Memex nebyl za Bushova života nikdy realizován, inspiroval celou řadu dalších vynálezců. Mezi jinými to byl i Douglas “Doug” Engelbart.

Doug Engelbart (1925–2013)

Doug Engelbart si poprvé přečetl o Memexu když pracoval v roce 1945 jako radarový technik na Filipínách a přenesl Bushovy myšlenky do digitální podoby. O Engelbartovi jste mohli slyšet především jako o „vynálezci myši“. Myslím si však, že toto označení shazuje jeho přínos.

Engelbartovým cílem byla „augmentace“ (rozšíření) lidských schopností. Člověk si utváří systém nástrojů které rozšiřují jeho vrozené schopnosti: tužka, písmo, abakus… Počítač může tvořit další nástroj v repertoáru, který výrazně posune naše schopnosti. Výsledkem tohoto myšlenkového rámce byl projekt oN-Line System (NLS).

Ukázka hardware pro NLS. Systém pracoval s grafickým monitorem a ovládal se pomocí tří periferií. Vedle klávesnice a myši to byla i „akordová klávesnice“; současný stistk různých kláves předal systému specifický příkaz. V systému nejsou žádné ikonky ani nabídky, uživatel se musel sekvence příkazů naučit (zdroj obrázků).

Hlavní funkce systému, tzv. Journal, sloužil jako hierarchický textový editor. Položky bylo možné řadit, číslovat a propojovat mezi sebou, pochopitelně interaktivně s pomocí myši. Podobné funkce dnes nabízí aplikace nazývané outliner (zdroj obrázku).

Systém mimo jiné podporuje párovou videokonferenci a sdílenou úpravu dokumentů v reálném čase – v roce 1968 (zdroj obrázku).

Položky v Journalu lze propojovat mezi sebou pomocí různých typů odkazů a vazby následně vizualizovat. Proto se také jedná o jeden vůbec z prvních hypertextových systémů (zdroj obrázku).

Všechny tyto funkce byly veřejně představené před padesáti lety – dnes tato demonstrace bývá nazývána jako Mother of All Demos. Engelbart zde ukázal potenciál, jaký nabízí osobní počítač s grafickým uživatelským rozhraním. Bez jeho vizionářství by dnešní počítačové systémy vypadaly pravděpodobně velice jinak.

Řada jeho kolegů odešla do vývojového centra Xerox PARC. Tam vytvořili koncept grafického rozhraní postaveného na oknech, ikonkách a nabídkách (WIMP), který zajisté důvěrně znáte. Tento koncept si „půjčila“ i jistá firma Apple… Ale to už je jiný příběh.

Ted Nelson (1937–)

Ted Nelson byl Engelbartův dobrý kamarád a ve svém projektu Xanadu sledoval podobné cíle. Nelsonova motivace však vychází především z jeho osobních potřeb. Celý život zápasí s organizací informací. Má vrcholný odpor k papíru, především proto, že fyzický dokument nelze založit do více šanonů současně. S tím souvisí i jeho odpor k hierarchickému třídění informací.

Nelson věří, že vše souvisí se vším a že neexistují jasné škatulky pro různé koncepty. Každá hierarchie je dříve či později odsouzená k zániku. Tento fenomén nazývá „intertvingularitou“ a vyjadřuje to maximou Everything is deeply intertwingled (šlo by přeložit zhruba jako „Vše je hluboce prošmodrchané“ – Nelson je specialista na vytváření novotvarů). Tradiční systémy organizace informací nedokážou pojmout komplexní, „intertvingulární“ povahu lidského myšlení. Proto když se Nelson v šedesátých letech potkal s počítačem, spatřil v něm spásu pro jeho problém s organizací informací. Počítač je „kouzelná skříňka“ která má prakticky neomezenou paměť a nezná fyzická omezení papíru.

Původně Nelson přišel s konceptem textového editoru, který by umožnil vytvářet paralelní revize dokumentů a ty propojovat mezi sebou. Tyto představy o práci s elektronickými dokumenty zobecnil pod pojmem, který pojmenoval hypertext. Nelson používá příponu hyper– v matematickém významu „naddimenze“ (např. „hyperkrychle“ je zobecněním krychle nad trojrozměrný prostor). Proto „hypertext“ představuje vícerozměrný text.

Nelson se však neomezil pouze na textovou informaci. Od prvního veřejného představení konceptu hypertextu v roce 1965 hovoří o „hypermédiích“. V knize Computer Lib / Dream Machines (1974) popisuje například hypergram, hyperkomiks nebo hyperfilm. Pro Nelsona jsou hypermédia demonstrací interaktivity, které může být dosaženo skrze médium počítače… Protože nic takového tehdy prakticky ještě neexistovalo. Zároveň vidí velký potenciál hypertextu ve výuce a vzděláváním, protože studenti mají moc procházet materiály s ohledem na své potřeby a tempo.

Xanadu

Své představy o hypertextu chtěl Nelson realizovat v rámci projektu Xanadu. Ten pojmenoval podle básně Samuela Taylora Coleridge Kublajchán aneb Vidění ve snu. Tato báseň se proslavila především tím, že zůstala nedokončená – stejně jako Nelsonův projekt. Nelson za posledních padesát let napsal mnoho textu o tom, jak by Xanadu mělo vypadat a uveřejnil celou řadu prototypů. Přesto velkolepá vize Xanadu nebyla nikdy naplněná.

Během své existence prošel projekt řadou změn, proto panuje řada nejasností a mýtů co mělo být Xanadu vlastně zač. To bylo cílem mé práce a hlavní náplň mé diplomky: popsat Xanadu, jeho rozdíly proti současnému webu a potenciální přínosy.

Přesto, že se podoba Xanadu a dílčí cíle změnily, esence zůstala stále stejná. Xanadu měl být hypertextový systém elektronické literatury. Cílem je přenést do elektronického světa koncepty, které dlouhodobě fungují v literatuře. Koncepty jako citace, reference a odkazy, ale i autorské odměny. V Nelsonově vizi do sebe vše zapadá a ukazuje, jak naše současné chápání elektronického textu zdaleka nenaplnilo svůj potenciál. Popíšu čtyři nejdůležitější koncepty, na kterých Xanadu stojí.

Viditelné odkazy mezi dokumenty

Nejcharakterističtějším znakem Xanadu jsou viditelná spojení mezi konkrétními částmi dokumentů. Hypertextový odkaz jaký známe v prostředí webu, je jednosměrný: nevíme jaké další dokumenty odkazují na webovou stránku, kterou čteme (zpravidla to ví vyhledávače, ale tyto informace poskytují pouze omezeně). Zároveň odkazy zpravidla vedou na dokument jako celek: pokud chci čtenáře odkázat na konkrétní odstavec či větu, často tuto možnost nemám². Paradoxně je v tomto směru je současný web horší než papírové dokumenty: kniha je přirozeně limitovaná velikostí papíru, takže můžu odkázat na konkrétní stránku, webový dokument naproti tomu není nijak přirozeně dělený na menší části.

Nelson mluví v kontextu Xanadu o „plovoucích odkazech“ (Floating links), protože „překrývají“ původní text. Na rozdíl od webu nejsou odkazy pevnou součástí dokumentu. Jsou to samostatné entity s vazbou na konkrétní části zdrojového a cílového dokumentu. Zároveň mohou nést význam (typ), například že se jedná o poznámku pod čarou či o překlad odkazovaného fragmentu. Velkou výhodou tohoto návrhu je, že je odkazy možné přidávat i k cizím dokumentům, takže si čtenář může snadno vytvářet vlastní asociace v materiálech.

Ukázka prototypu Xanadu CosmicBook z roku 2003. Prototyp ukazuje viditelné vazby mezi dokumenty přes hypertextové odkazy, v tomto případě jako čáry mezi okny operačního systému.

Ukázka prototypu Xanadu Space z roku 2007. Dokumenty jsou vizualizované ve 3D prostoru, opět s viditelnými vazbami mezi sebou. Nelson blíže demonstruje tento prototyp ve videu, instalátor aplikace pro Windows je možné stáhnout z archivované stránky projektu.

Transkluze obsahu

Pojem „transkluze“ (transclusion) je další Nelsonův novotvar. Jeho význam je podobný jako inkluze, ale s větším důrazem na přenesení. V Xanadu slouží transkluze ke skládání dokumentů z více částí. Citace jiných dokumentů nejsou kopií citovaného textu, ale jsou přímo vložené z citovaného dokumentu, se zachováním autorství a kontextu původního dokumentu. Transkluze není na webu zcela cizí koncept, typickým příkladem je například vkládání videí z YouTube do webové stránky. Tímto způsobem však není možné vložit pouze fragment jiného dokumentu, například část textu do toku stránky.

V kombinaci s plovoucími odkazy je patrné, že dokumenty v Xanadu se skládají z několika vrstev: výsledný text je nejprve složený ze zdrojových dokumentů a následně „překrytý“ odkazy na další materiály.

Transkluze podporuje remixování dokumentů při zachování autorství. Pokud například opravím chyby v cizím textu, můžu svou revizi zveřejnit jako nový dokument, ale zachovám informaci, že většinu textu napsal původní autor. To je užitečné i v případě zpoplatnění dokumentů a konceptu „transcopyrightu“.

Transcopyright

Nelson od začátku předpokládal, že obsah v rámci Xanadu bude zpoplatněný. Uživatelé by platili miniaturní částky (tzv. mikrotransakce) za každý přenesený byte. Díky tomu by autoři mohli dostat honorář na základě čtenosti jejich obsahu. V kombinaci s transkluzí to znamená, že čtenář si zakoupí dokument a částka se rozdělí poměrně mezi všechny autory, jejichž obsah je v dokumentu použitý. Nelson zároveň zdůrazňuje nárok čtenáře na vlastnictví zakoupeného obsahu: co si koupím už je permanentně moje. Můžu si pořídit zálohy a v případě potřeby dokoupit zbytek citovaného dokumentu. V praxi je tento koncept vidět na nejaktuálnějším prototypu Xanadu, aplikaci XanaViewer.

Ukázka prototypu XanaViewer 3 z roku 2016. Vpravo se nachází hlavní dokument, vlevo zdrojové dokumenty. Hlavní dokument cituje placený dokument, maskovaný symboly, který si čtenář může zakoupit. XanaViewer je dostupný jako webová aplikace, viz popis na stránce projektu.

Permanentní revize dokumentů

Aby tyto koncepty fungovaly, musí systém zaručit permanentní dostupnost každé revize publikovaných dokumentů. Protože odkazy i transkluze pracují s konkrétním rozsahem textu ve zdrojovém dokumentu, změna zdroje by mohla odvozené dokumenty rozbít.

V praxi měl být Xanadu centralizovaný systém. Technický rozvoj řídí centrální autorita Xanadu Operating Company. Smluvní poskytovatelé („franšízanti“) hostují obsah s garancí dostupnosti a poskytují službu koncovým uživatelům. Pokud si přejete svůj dokument publikovat, musíte s poskytovatelem uzavřít smlouvu, akceptovat podmínky transcopyrightu a zaplatit poplatek za publikaci. Pokud si přejete publikovaný dokument odstranit, jedná se o několikaměsíční proces, protože je nutné upozornit autory všech odvozených a odkazujích dokumentů. Přestože Xanadu připouští „poloveřejných“ (privashed) dokumentů, které mohou být kdykoliv odstraněny, pouze publikace oficiální cestou umožní autorovi získat autorský honorář. Poskytovatelé mohou zároveň zálohovat a poskytovat obsah od jiných poskytovatelů, což má zaručit integritu systému i v případě výpadku.

V porovnání se současným webem působí model Xanadu se smluvními poskytovateli mnohem uzavřeněji. Je to určitá cena za větší robustnost celého systému a vymahatelnost autorských práv. Z mého hlediska se jedná stále o lepší model, než s jakým operují současné dominantní platformy pro publikování obsahu, zejména sociální média. V diplomce se věnuji projektům, které by umožnily dosáhnout robustnější distribuce obsahu i při zachování decentralizované povahy webu.

Co se stalo s Xanadu?

Jak jsem již zmínil, projekt Xanadu nebyl nikdy dokončený. Nelson má sice jasnou vizi, na rozdíl od Engelbarta však postrádá technické a organizační dovednosti projekt realizovat. Většinu prototypů pro něj implementovali jednotlivci, kteří na projektu dříve či později vyhořeli. Xanadu bylo nejblíže realizaci na přelomu osmdesátých a devadesátých let, kdy byl projekt financovaný firmou Autodesk. Projekt však skončil fiaskem zejména z personálních důvodů a Nelson se na realizaci prakticky ani nepodílel.

Začátkem devadesátých let přišel World-Wide Web, který překonal většinu konkurenčních technologií i díky své trivialitě a adaptabilitě. Nelson nebyl z nástupu webu nijak nadšený. Částečně tím utrpělo jeho ego, protože koncept hypertextu, který vymyslel, proslavil někoho jiného. Zároveň web naráží na řadu problémů, které Nelson ve svých návrzích předpokládal. Web je pouhým odleskem všeho, co Nelson vložil do konceptu hypertextu.

Xanadu zůstává inspirativní vizí, která měla ukázat plný potenciál hypertextu a elektronické literatury. Možná by plně funkční systém Xanadu neobstál střet s realitou. Myslím si však, že Xanadu má stále co nabídnout a myšlenky, které do Nelson do projektu vložil, si zaslouží naší pozornost.

Proč se zabývat hypertextem a Xanadu?

V závěru zmíním několik důvodů, proč si myslím, že proč jsou pro nás myšlenky Xanadu stále relevantní a historie hypertextu má co nabídnout. V diplomce se věnuji řešením v některých z těchto oblastech.

Aktivní získávání znalostí

Jak jsem zmínil na začátku, hledal jsem řešení jak lépe zpracovávat informace ve znalosti. Na Memexu i Xanadu je zajímavé, že čtenář je postaven do mnohem aktivnější role při práci s textem. Může anotovat, remixovat a vytvářet vlastní vazby v materiálech.

Mým přáním je, abychom web nevnímali web jen jako médium pro distribuci, pasivní konzumaci a zveřejňování obsahu. Elektronický text může být mnohem interaktivnější a poskytnout čtenáři mnohem větší volnost než papír. Hledejme proto způsoby, jak na webu aktivněji pracovat s existujícím obsahem.

Multimediální informace

Setkávám se s názorem, že textová informace je dnes na ústupu. Stále více obsahu se přesouvá do multimediálních formátů, zejména videí. New York Times dokonce hovoří o „post-textové budoucnosti“ (ale přiznám se, že mi pojem post-text přijde jako „buzzword“).

Webový model hypertextu je pro práci s multimediálním obsahem značně omezený. Přitom už Otlet pochopil, že dokument může nést informaci v mnoha podobách. Řada raných hypermediálních systémů (v práci zmiňuji například systémy Intermedia a Microcosm) umožňovala vytvářet hypertextové vazby mezi textem i multimediálními formáty. Abychom v „post-textové budoucnosti“ obstáli, musíme překonat technická omezení, která rozdělují hypertext od hypermédií.

Udržitelná monetizace

Tim Berners-Lee původně navrhnul WWW jako nástroj pro sdílení informací v instituci CERN. Monetizace obsahu a kompenzace autorů nebyla jednoduše potřeba. Postupem času jsme si zvykli, že obsah na webu je zadarmo. Platíme tím, že trpíme reklamy a komerční sdělení. Reklama na webu už nejsou jen otravné blikající bannery, ale především sledování uživatelů za účelem efektivnějšího cílení. Techniky sledování jsou stále agresivnější a příjmy z reklamy vydavatelům přitom stále klesají.

Vznikají nové iniciativy jak situaci zvrátit ve prospěch vydavatelů a uživatelů. V diplomce například zmiňuji prohlížeč Brave, který umožňuje uživatelům dobrovolně, automaticky a anonymně přispívat webům, které nejčastěji navštěvují. Vedle nicméně Xanadu ukazuje, jak může být bezbolestná monetizace obsahu zabudovaná přímo do platformy a přitom respektuje nároky čtenáře. Bude však obtížné překonat mýtus současného webu, že obsah je zadarmo.

Permanence obsahu

Že obsah na webu mizí není nic nového. Je to fenomén který má vlastní název: linkrot („hniloba odkazů“). Pro ilustraci uvádím studii z roku 2014, která analyzovala dostupnost odkazů v publikacích Nejvyššího amerického soudu a vědeckých časopisech. V prvním případě zjistila, že je nefunkčních až 50 % odkazů, ve druhém případě to bylo dokonce přes 70 % odkazů.

Naučili jsme se akceptovat web jako nespolehlivé médium, kde obsah zmizí během okamžiku. Máme nástroje které se s tímto problémem snaží bojovat, například webové archivy, ale jedná se o hrdinný boj několika institucí s větrnými mlýny. Pro Xanadu je permanence obsahu zásadním východiskem, zatímco web obětoval tuto vlastnost ve prospěch decentralizace, „živosti“ dokumentů a nezávislosti vydavatelů. V diplomce zmiňuji možné řešení, které kombinuje decentralizovanou povahu webu s příslibem větší robustnosti distribuce obsahu.

Překonání technických bariér

Při pohledu na historii hypertextu mi připadá ironické, že jsme dokázali zbavit informace fyzické formy, abychom mezi nimi následně vztyčili technické bariéry. Ať už se jedná o nekompatibilní a proprietární formáty souborů nebo různé agresivní formy ochrany obsahu (DRM), které omezují naše možnosti práce s legálně zakoupeným obsahem.

I přes veškeré své nedostatky je web stále nejotevřenější platforma, kterou máme k dispozici. Pokud si jej nebudeme vážit, přijdeme o něj.

Novomediální inspirace

Navštěvujeme konference jako je New Media Inspiration abychom zjistili, jaká je současnost a budoucnost našich oborů. Minulost má však také co nabídnout a historie nových médií je plná technologií, které měly všechny předpoklady pro úspěch, a přesto zůstaly zapomenuty. Hledejte inspiraci i v tom co bylo – a co mohlo být.

Zdroj

Přednáška vychází z diplomové práce Web, který nebyl: Xanadu a alternativní pojetí hypertextu, obhájené v roce 2017 pod oborem Studia nových médií na Filozofické fakultě Univerzity Karlovy.

Fotografie Douglase Engelbarta pochází ze stránek Doug Engelbart Institute. Fotografie Teda Nelsona je převzatá z rozhovoru s Nelsonem ve filmu Wernera Herzoga Lo and Behold, Reveries of the Connected World.

Tématem NMI 2018 byla „Umělá inteligence.“ ↩
Můžeme odkazovat na konkrétní část stránky přes tzv. kotvy, které však musí do dokumentu vložit autor nebo redakční systém. ↩

Jak jsem psal o webu, který nebyl

Sun, 31 Dec 2017 21:00:00 +0100

Ohlédnutí za diplomkou a inspirace do budoucna

Konec roku je časem ohlédnutí, kdy vychází články typu „Nejhorší propadáky roku,“ „Nejslavnější celebrity roku“ nebo „Nejlepší ryba roku“… Letos i já přispěju se svou troškou a vrátím se k činnosti, kterou jsem letos strávil celkem dost času: psaní diplomky. Mým cílem je především si uspořádat myšlenky. Nebude to na „Nejlepší diplomku roku 2017,“ ale pro mě je to tečka za studiem na SNM.

O čem má diplomka je

Práce se jmenuje Web, který nebyl: Xanadu a alternativní pojetí hypertextu. Pod krkolomným názvem se ukrývá rešerše na téma hypertextových systémů, předchůdců dnešního Webu. To, že se jedná o předchůdce, však neznamená, že jsou méně dokonalé než dnešní Web – právě naopak. Vizionáři osobních počítačů, jako Douglas Engelbart a Ted Nelson, přišli s návrhy, které v mnoha ohledech předčí schopnosti dnešních systémů a stále mají co nabídnout. Právě Nelsonovu systému Xanadu je věnovaná velká část práce i s náznaky, jak přenést jeho klíčové myšlenky do současného Webu – a jeho možných nástupců.

Vedle PDF je k dispozici i zdrojový kód práce.

Jak jsem se k tomu dostal

Když jsem se jako absolvent techniky hlásil na humanitní obor, chtěl jsem najít balanc mezi teorií a technickou realizací. Proto jsem si představoval, že má závěrečná práce musí být softwarovou implementací, alespoň prototypem. První návrh diplomky, se kterým jsem se na SNM hlásil, se zabýval kontextem uživatelů: fyzickou lokací, aktivitou, daty z kalendáře a čímkoliv dalším. Jakýsi náznak teorie měl být v problematice autonomie a ovlivnění uživatele, ale to mě ani tolik nezajímalo. Výsledek měl být jakýsi hybrid textu a aplikace, který pracuje s kontextem čtenáře, monitorováním jeho chování během čtení i fyzickou lokací. Vtip byl v tom, že takto realizovaná měla být právě výsledná práce, která by se měnila v závislosti na aktivitě čtenáře. Jak by se to přeneslo na papír byl „implementační detail.“ Ve výsledku mě nenapadlo mnoho způsobů jak využít kontext čtenáře pro čtení teoretické práce a Robert Scoble mi o pár měsíců později vyfoukl pracovní název Age of Context. V praxi tyto nápady skvěle vyjádřila hudební skupina John Moose: vydala hudební album ve formě mobilní aplikace, která funguje jen v lese.

Po několika neurčitých pokusech definovat diplomovou práci související s výukou programování a řadu školních prací později jsem si všiml, jak špatně se mi pracuje s akademickými zdroji. Proč i přes všechny vymoženosti Webu a hypertextu používáme obstarožní citační aparáty? Proč jsou všechny akademické články ve formátu PDF? Proč mě některé nástroje nechají anotovat jen webové stránky, nebo PDF soubory, ale nikdy je nedají dohromady? A proč každý nástroj dříve nebo později zanikne i s mými daty? Jako hlavní inspirace pro vznik hypertextu se udává článek As We May Think, ale je web skutečně tím pověstným Memexem? Přišlo mi, že vize Vannevara Bushe je stále sci-fi oproti realitě současného webu. Stejně jako mnoho lidí přede mnou (což jsem ještě netušil) jsem chtěl přenést Bushovy myšlenky do současného webu a diplomka měla být záminka, jak se dokopat k realizaci prototypu. Můj první pokus o zadání zněl takto:

Cílem práce je vytvořit koncepci systému pro osobní sběr a syntézu informací s ohledem na potřeby znalostních pracovníků. První část práce bude analyzovat rané hypertextové systémy – zejm. Memex, Xanadu – a jejich následovníky jako nástroje pro extenzi lidské paměti a introspekci. Druhá část se bude věnovat současnému stavu: Webu jako dominantnímu hypermediálnímu systému a konvenčním nástrojům pro kolekci a správu informací. Ve třetí části budou tyto poznatky použity pro teoretický návrh systému který by mj. reflektoval kontext, v jakém jsou informace pořízeny a umožnil by jejich rekurzivní syntézu. Zvláštní pozornost bude věnovaná etické problematice takového systému, mj. autonomii uživatele a vlastnictví dat.

Josef Šlerka trefně poznamenal, že to je taková „teorie všeho.“ I tu autonomii uživatele jsem tam nacpal! Po konzultaci nad zadáním jsem se smířil s tím, že hlavním výstupem mé práce nebude implementace, pokud není předmětem navazujícího výzkumu. Josef mi navrhl, abych se zaměřil na Teda Nelsona a jeho Xanadu. Mytický projekt dokonalého hypertextového systému, který od šedesátých let nebyl po mnoha peripetiích stále dokončen – nejdéle existující „vaporware“ v historii software. Tehdy jsem měl jasno, že příčinou problémů Xanadu je osoba Teda Nelsona, kterého jsem měl za egomaniaka a samozvaného génia, jehož představy byly už dávno překonané. Koneckonců jsem přečetl The Curse of Xanadu, kde bylo řečeno o Xanadu vše, co řečeno být mělo. Josef mě odkázal na Alexe Wrighta s přednáškou The Web That Wasn‘t a na Nelsonovu knihu Computer Lib / Dream Machines (s poznámkou „to je psychopatický!“). Ve finálním zadání jsem se zaměřil na analýzu projektu Xanadu a přidal jsem si k tomu vyhodnocení aplikovatelnosti Nelsonových myšlenek na současný web. Od Wrighta jsem si sprostě půjčil název.

Jak mi šlo psaní

Z počátku mi přišla rešeršní práce jako výhoda: stačí toho hodně načíst a nemusím se s nikým bavit. Základní přehled jsem získal ze tří knih:

What the Dormouse Said od Johna Markoffa popisuje okolnosti vzniku průmyslu osobních počítačů v šedesátých letech v Kalifornii, včetně vlivu kontrakultury a psychedelik; soustředí se zejména na kariéru Douglase Engelbarta, který se sám inspiroval Memexem.
Glut: Mastering Information Through the Ages Alexe Wrighta, kde mě zajímala pouze kapitola The Web That Wasn’t. Odtud jsem čerpal zejména informace o Paulu Otletovi, „zapomenutém praotci hypertextu,“ který v historii webu bývá značně opomíjený.
Memory Machines od Belindy Barnet, kde je popsané prakticky vše, čemu jsem se ve své práci věnoval.

Užitečná pro mě byla i diplomka Vision & Reality of Hypertext and Graphical User Interfaces od Matthiase Müller-Prove, která je sice kompilační a technická, ale věnuje se podrobněji fungování jednotlivých hypertextových systémů. Většina ostatních textů spíše řeší záměry tvůrců jednotlivých systémů, ale méně se zabývá tím, jak výsledný systém fungoval, nebo měl fungovat.

Po přečtení několika knih jsem stále měl jen velmi matnou představu co vlastně Xanadu doopravdy je a co se z jeho vize podařilo realizovat. Nezbylo mi než se poohlédnout po primárních zdrojích. Nelsonův problém není v tom, že by toho napsal o svých projektech málo, problém je vše dohledat a vyznat se v tom. Nelsonovy články jsou spletenec odkazů na již neexistující nebo nikdy nepublikované stránky, knihy, které vyšly v omezeném nákladu a „osobní komunikaci.“ Nemůžu se ubránit dojmu, že Nelson chce prakticky demonstrovat nedostatečnost webu, jako hypertextového média, neschopného pojmout jeho komplexní, „intertvingulární“ myšlení.

Dohledávání zdrojů pro mě bylo praktickou lekcí „webové archeologie,“ značnou část Nelsonových zdrojů cituji skrze Internet Archive. Za svůj velký úspěch považuji objevení skenu (beznadějně rozebrané) Nelsonovy knihy Literary Machines, ve které celistvě popisuje projekt Xanadu. Tři z pěti kapitol se nachází se na jeho již neexistující domovské stránce v obskurním formátu JFAX. Naštěstí se dá celá kniha objednat ze zahraniční knihovny. Jindy se mi podařilo najít Nelsonův článek Getting It Out Of Our System publikovaný v obskurním sborníku z roku 1967 v Národní technické knihovně.¹ Mnoho zábavy jsem si užil i při procházení Nelsonových rukopisů a strojopisů:

Hypertext Implementation Notes (TIF)

Čím hlouběji jsem se nořil do původních vizí hypertextu, tím více jsem litoval, že jich tak málo bylo uskutečněno. Jak se mi kupily materiály a výpisky, bylo pro mě stále obtížnější se v nich vyznat. Možná za to může mé zmatkářství, zapomnětlivost a absence systému. Ale i tak se nemůžu ubránit dojmu, že naše prostředky pro syntézu informací se přes veškerý technický pokrok příliš nevyvinuly.

Co mi to dalo

Ve výsledku jsem rád, že jsem pro diplomku zvolil toto téma. Překvapilo mě, jak zásadní byla vize Memexu pro následný rozvoj osobních počítačů a nejen hypertextu. I přes svou počáteční skepsi a nechuť vůči Nelsonovi jsem nakonec docenil jeho vizi a nezřídka jasnozřivost. Jeho psaní je poněkud pompézní a různá podobenství a jazykové hříčky moc nepomáhají v pochopení jeho (zejména raných) textů. Přesto si myslím, že jeho myšlenky jsou stále relevantní a neměly by být zapomenuty. Celkově pro mě byla diplomka exkurzem nejen do historie, ale i do paralelního světa, kde se vývoj počítačových systémů řídil jinými, lidštějšími principy.

Konkrétněji jsem získal odlišný pohled na hypertext a mohl tak formulovat nedostatky současného webu: absenci obousměrných odkazů, omezené možnosti detailního odkazování na konkrétní část dokumentu, omezenou životnost materiálů na webu a další. Nejsou to problémy vycucané z palce, ale konkrétní body, které už byly v jiných systémech vyřešené.

Co dál

O tématu budu přednášet v únoru na Pragoffestu a v březnu na New Media Inspiration. Mimo to bych se rád dostal k praktické realizaci řešení některých z nastíněných problémů. V práci zmiňuji projekt Hypothes.is, který rozvíjí ekosystém pro anotace na webu. Stejnou logiku lze využít pro anotování odkazy, které by obohacovaly existující dokumenty o propojení s dalšími materiály. Jeden z mých problémů by řešil sběr takových anotací na jedno místo, bez ohledu na zdrojovou aplikaci nebo zařízení. Dalším krokem by byla aktivní podpora při psaní textů a vytváření „hluboce propojených“ dokumentů s externím formátováním, jak naznačuje prototyp Hope. Velký potenciál cítím i u projektů pro decentralizaci webu, zejména IPFS. Trochu mě mrzí, že větší pozornost na sebe strhla související technologie Filecoin, která se veze na současném trendu investic do kryptoměn a „ICO.“

A v neposlední řadě bych chtěl o tématu ještě psát, takže tento studijní blog nemám v plánu zatím zavírat.

Poděkování

Poděkování patří samozřejmě vedoucímu Vítu Šislerovi, konzultantovi Josefu Šlerkovi a oponentce Ditě Malečkové. Můj největší dík má Jana Ada, která nejen že trpělivě snášela můj nekonečný stav #píšudiplomku, ale ještě mi celý text zkontrolovala a alespoň částečně napravila mé neohrabané a omezené psaní. Za korekturu a jazykovou konzultaci děkuji i mému otci a Jakubovi Jirůtkovi. Výsledná podoba práce je zásluhou kolegů z ČVUT, kteří vyladili šablonu pro TeX, ze které jsem vycházel: Jakuba, Mira Hrončoka, Ondry Gutha a Davida Labského.

Samotný článek je nyní, shodou okolností, dostupný i elektronicky. ↩

Bůh ve stroji

Tue, 11 Apr 2017 18:00:00 +0200

TempleOS: Operační systém pro Boha

Aktualizace: Na konci května byl zrušen Terryho YouTube kanál a s ním všechna videa, zároveň zmizela většina obsahu webu TempleOS. Odkazy v článku vedou na archivní verze stránek, některá videa se mi však již nepodařilo nalézt.

V průběhu staletí budovalo lidstvo chrámy svým božstvům. Ať už jako místo posledního odpočinku krále-boha, centrum komunity a rozjímání či oslavy Všemohoucího. Starý zákon popisuje Hospodinův chrám, první židovský chrám který král Šalamoun nechal postavit na dnešní Chrámové hoře v Jeruzalémě.

Šalomoun pokryl celý vnitřek chrámu ryzím zlatem. Také svatostánek pokryl zlatem a natáhl před ním zlaté řetězy. Celý chrám byl tedy úplně pokryt zlatem a stejně tak byl zlatem pokryt i celý oltář před svatostánkem.

1 Královská 6:21-22

Ačkoli jsou dnešní svatyně o něco skromnější, lidstvo i dodnes staví svatyně svým božstvům. Byť to nemusí být budovy z kamene a dřeva.

Terry A. Davis, 47-letý programátor z Nevady, se v roce 2003 rozhodl postavit nový Hospodinův chrám. Tím chrámem je operační systém – TempleOS. TempleOS je „oficiálním chrámem Boha,“ místo, kde se Bohu obětují dary a kde je možné promlouvat s božím orákulem. Systém je omezený na rozlišení 640×480 pixelů, 16 barev, jednohlasý zvuk přes PC Speaker a nepřipojí se na síť. Celý systém (kromě aplikací a ukázek kódu) nesmí překročit sto tisíc řádek kódu. Bůh si to tak přál.

Bůh řekl, že grafika 640×480 o 16 barvách je stálý závazek, stejně jako obřízka.

TempleOS Charter

Při prvním spuštění vypadá TempleOS jako návrat do 80. let, doby mohutných katodových monitorů, ohebných pětipalcových disket, jednoduchých tónů ze zabudovaných reproduktorů a výrazných barev grafických rozhraní Amigy a DOSu. Dřívější systémy se však obešly bez agresivního blikání…

Hned po spuštění se systém dožaduje pozornosti na několika frontách. Chceš nainstalovat systém? Chceš prohlídku systémem? Tady jsou základní klávesové zkratky, které fungují všude: Ctrl-M otevře osobní menu (něco jako nabídka Start), klávesou F7 vložíš náhodné slovo od Boha, F6 přehraje náhodnou písničku a Shift-F6 ti načmárá obrázek od Boha.

God Doodle – Standardní funkce TempleOS

Terry usiloval o zjednodušení komunikace s Bohem. Zpočátku zkoušel otevírat Bibli na náhodné stránce, poté stránku vybíral hodem mince – nejprve pouze v Bibli a pak ve všech svých knihách. Nakonec dospěl k využívání vysokofrekvenčního časovače jako generátoru náhodných čísel. (zdroj) TempleOS proto obsahuje Orákulum pro komunikaci s Bohem v aplikaci AfterEgypt:

… Než s Bohem mluvíte, tak byste mu měli nabídnout dar, jako komiks nebo básničku, nebo jen dobrou konverzaci, buďte zábavní a okouzlující… Nebo jej můžete pochválit; například pochválit Boha za písečné hrady, sněhuláky a bubliny a popcorn…

Já jej pochválím za něco nového a to izotopy, třeba jak máte uhlík 14… Myslím, že je to docela cool. Nemuselo to tak možná být…

TempleOS: AfterEgypt

TempleOS: AfterEgypt

Terry, jakožto „Velekněz oficiálního božího chrámu,“ tvrdí, že hlavním smyslem života je nabízet Bohu oběti, jako Kain a Abel, a užívat si odpověď Boha. Ve svých rozsáhlých poznámkách o rozhovorech s Bohem odhaluje i řadu zjištění: oblíbený sport Boha je hokej, v televizi rád sleduje telenovely a jeho oblíbená zvířata jsou medvědi a sloni.

Terry A. Davis je vystudovaný elektrotechnik a talentovaný programátor. V roce 1996 začal trpět stihomamem a bipolární poruchou, později mu byla diagnostikována schizofrenie. Na TempleOS pracuje od roku 2003, kdy se chytil trendu 64-bitových domácích počítačů.

Terryho operační systém měl v průběhu let řadu jmen: J, LoseThos, SparrowOS a nakonec TempleOS. Terry se o svém projektu podělil se světem, ale nedočkal se vždy vřelého přijetí. V diskuzích komunikuje nekoherentně a zpravidla v dlouhých, náhodně vygenerovaných úsecích textu („božího slova“). Často začne vykřikovat konspirační teorie a ostatní diskutující častuje nadávkami a označením negr.

Terry žije u rodičů a pobírá invalidní důchod. TempleOS stále aktivně vyvíjí. Na YouTube kanálu je už přes tisíc videí které ukazují funkce a kód TempleOS, jednotlivé aplikace a chvalozpěvy, které Terry složil. Vedle toho Terry pravidelně publikuje na web TempleOS.org, který slouží i jako Terryho domovská stránka. Zde mimo jiné sepisuje nápady na vynálezy a zápletky filmů (například Klon Země, kdy lidstvo objeví klon Země posunutý zpět do roku 1859) a v blogu zveřejňuje rozhovory s Bohem (většinou se jedná o sledy náhodných slov občas proložené konspiracemi o pronásledování CIA).

Nedávno se pustil i do livestreamingu. Občas máte šanci jej zahlédnout, jak skládá nové chvalozpěvy, brouzdá po YouTube nebo s úšklebkem odpovídá trollům v chatu odstavci náhodných slov.

Terry je bezesporu zvláštní postava; možná jen schizofrenik který tráví příliš času u počítače, možná génius s nešťastným osudem. TempleOS je snadné odsoudit jako nepoužitelný projekt: s tak směšnou grafikou a bez podpory síťování je použitelný možná jako stroboskop. Ale přesto je na něm cosi fascinujícího.

Práce s TempleOS je jako výlet do paralelního světa, kde se vývoj operačních systémů ubral jiným směrem. Zatímco dnešní dominantní systémy jsou deriváty svých předchůdců, TempleOS je od základu originálním dílem jediného autora nespoutaného existujícími paradigmaty.

Linux je kamion – potřebujete profesionálního řidiče, který zvládne 20 převodů. […]

Windows je auto.

TempleOS je motorka – když se nakloníte moc do strany, motorka havaruje. Nedělejte to!

Decisions Making TempleOS Simple

TempleOS je cílený především na technické uživatele. Není zde žádná ochrana procesů, všechny aplikace společně sdílí paměť – pokud je v jedné aplikaci chyba, může shodit celý systém. Tím je celý systém extrémně jednoduchý a snadný k prozkoumání. V chrámu nejsou žádná tajemství.

V dnešních systémech je absence jakékoliv izolace aplikací nepředstavitelná, přesto populární systémy DOS a Commodore 64 nic takového neměly. Každá aplikace měla 100% kontrolu nad celým systémem. Proto když se „sekla“ nějaká hra, nezbývalo nic jiného, než restartovat počítač. Opravit takovou chybu bez zdrojového kódu aplikace je však velice obtížné.

V TempleOS nejsou binární aplikace, vše je zdrojový kód. Každý program se transparentně zkompiluje při spuštění (tzv. Just In Time Compiler – JIT). K modifikaci systému tak nejsou zapotřebí sofistikované nástroje, stačí upravit textový soubor a znovu jej spustit. Celý systém je psaný v HolyC, dialektu programovacího jazyka C, který zároveň slouží jako hlavní prostředek komunikace se systémem.

TempleOS se tak svým způsobem vrací k tradici počítačů C64, Atari 800 nebo Apple II, kde jazyk BASIC sloužil jako základní uživatelské rozhraní kterým uživatel mohl spouštět i tvořit aplikace. Hranice mezi uživatelem a programátorem byla tenká.

TempleOS jde programátorům vstříc i zabudovaným dokumentačním systémem. Textové soubory jsou ve skutečnosti dokumenty ve formátu DolDoc, který umožňuje vkládat hypertextové odkazy, vektorové obrázky i 3D grafiku. Grafický editor je zabudovaný v systému, stejně jako textový editor. Dokumentace je tak organickou součástí zdrojových souborů, včetně odkazů mezi funkcemi a grafických diagramů. Stírá se hranice mezi grafickým a textovým rozhraním, interaktivitou a neinteraktivitou.

Why Davis‘ TempleOS is better than Torvalds‘ Linux

Ukázka tvorby programu s vloženou vektorovou grafikou.

Součástí systému jsou i ukázkové aplikace, rozdělené na „Zábavné hry“, „Nezábavné hry“, „Útržky kódu“ a „Nehry.“ Například v nezábavné hře „Castle Frankenstein“ pobíháte po 3D hradě kde střílíte monstra („Bůh řekl, že tancují“). V zábavné hře Wenceslas jste Dobrý král Václav, zapalujete stromy aby se zahřáli vaši poddaní. Některé hry jsou záměrně nedokončené a uvítají vás mottem „Pište hry, nehrajte je!“

Od roku 2014, kdy Terry upoutal pozornost širší veřejnosti, ubyly v systému náboženské reference. Dokonce i aplikace AfterEgypt, dříve nejdůležitější součást systému, se přesunula na doplňkový disk. Naopak TempleOS App Store se rozrostl o aplikace od dalších vývojářů, které neodradila svérázná podoba systému, ani jeho omezení.

Jack Whitham, který na TempleOS přenesl interpret textových her, poznamenal:

Tento malý projekt mi neustále připomínal jak moc se spoléháme na softwarovou infrastrukturu, zejména nástroje. Nejen kompilátor C, ale účinné debuggery, textové editory a systémy správy verzí. TempleOS je jako kdybyste nad tím vším provedli reset: vývojářské nástroje jsou zcela jiné. Jsem těžce závislý na nástrojích, které normálně používám. Práce v prostředí kde nic takového neexistuje je skutečně kulturní šok. A proto je to výzva.

Jack Whitham: Porting third-party programs to TempleOS

Dennodenně se potkáváme s chybami v aplikacích, které používáme. Řada chyb je zajisté způsobená vývojáři. Spousta chyb však nemá jasného viníka. Dnešní software je souhra komplexních systémů stojících na mnoha křehkých vrstvách abstrakcí. Chyby počítačových systémů jsou zkrátka „emergentním chováním“ komplexních systémů v důsledku neočekávaných interakcí komponent.

Na jedné straně komplexita software neubývá, na straně druhé software proniká do všech aspektů našich životů. Snaha zjednodušit systém pro koncové uživatele jej učiní ještě složitější a pro uživatele neprůhlednější. Dříve si kutil opravil auto u sebe doma – dnes nějaká krabička v autě usoudí, že je něco špatně a auto se bez zásahu autorizovaného technika nerozjede. Jako uživatelé jsme odkázaní na milost techniků, vykladačů elektronických snů a vymítačů virtuálních démonů.

Kdo jiný je určený ke zvládání komplexity, než stroje samy? Díky strojovému učení a dalším nástrojům „umělé inteligence“ už nemusíme komplexitu zvládat my – stačí, když vytvoříme systémy, které se naučí komplexitu zvládat místo nás. Jak tyto systémy fungují se bude vymykat našemu chápání. Samuel Arbesman ilustruje na příkladu evolučního programování:

Před několika lety se tým výzkumníků pokoušel vylepšit návrh jistého počítačového obvodu. Vytvořili jednoduchý úkol, který měl obvod řešit, a pak se pokoušeli vyvinout potenciální řešení. Po mnoha generacích tým konečně nalezl úspěšný návrh obvodu. Zajímavá je však tato část: v návrhu byly komponenty, které nebyly připojené k hlavnímu obvodu – a přesto byly zapotřebí ke správné funkci obvodu. Evoluční program využil zvláštní fyzikální a elektromagnetický jev, který by žádného inženýra nenapadlo využít pro danou funkci obvodu. Slovy výzkumníků: „Evoluce dokázala využít tento fyzikální jev i přesto, že by bylo obtížné jej analyzovat.“

Samuel Arbesman: Is technology making the world indecipherable?

Jak se postavit ke všeobjímající komplexitě? Arbesman navrhuje, abychom systémy chápali podobně jako počasí – něco, co sice nedokážeme ovládat, ale dokážeme odhadovat jeho chování máme-li dostatečně dobrý model. A k tomu budeme potřebovat interprety modelů, něco jako televizní rosničky. Nebo jako velekněze, kteří budou vykládat vůli našich algoritmických bohů.

A mezitím jeden osamělý programátor v Nevadě bude dále vylepšovat své životní dílo – operační systém, který je chrámem pro Boha. Místo rozjímání a obětování Bohu. Místo, kde uživatel je velekněz a nic mu není zapovězeno. Místo, kde je uživateli nadřazený už jen Bůh.

Zdroje

TempleOS.org (archiv)
Jesse Hicks: God's Lonely Programmer
Richard Mitton: A Constructive Look At TempleOS
Jack Whitham: Porting third-party programs to TempleOS
Samuel Arbesman: Is technology making the world indecipherable?

Animace 3D modelů jsou součást systému TempleOS, který je dostupný jako volné dílo. V článku je použito písmo Fixedsys Excelsior.

Od pastelek ke grafům

Tue, 20 Oct 2015 09:00:00 +0200

Vizualizace dat poprvé a podruhé

Když se zpětně dívám na dosavadní zápisky, vypadá to skoro jako kdyby většina studia Nových médií spočívala jen ve vizualizaci dat. Vizualizovali jsme sociální sítě, text, televizní zpravodajství, text a filmy – nemluvě o vizualizaci nutričních hodnotách džusů kterou jsem, ehm, zazdil.

Nicméně to mi stále nestačilo. Karel Minařík letos exkluzivně poprvé učí předmět Vizualizace dat kde budeme ~~barvit omalovánky~~ vizualizovat ostošest.

Na první hodině jsme dostali pastelky, čtverečkový blok a nějaká data. A úkol nakreslit graf – aniž by vlastně záleželo na tom, jaká data máme.

Náš výchozí zdroj je počet cizinců na území ČR v rocích 2004–2014. Zřejmě nejzajímavější pohled nabízí porovnání napříč jednotlivými roky – jakou úroveň však zvolit? Celkový počet? Země EU a ne-EU? Nebo jen vybrané země?

Pro první skeč jsem se zaměřil na zastoupení cizinců ze zemí EU a ostatních zemí.

Počet cizinců v ČR ze zemí EU (modře) a ostatních zemí (červeně) v letech 2004 a 2014. Představte si že pravý sloupec je ještě o něco vyšší…

Studijní i profesní život se znatelně podepsal na mé zručnosti s psacími potřebami, proto jsem graf rozvinul až v digitální podobě, což byl náš úkol na druhou hodinu.

Tento typ grafu funguje dobře pro malé množství kategorií. O něco lépe by na tom byl čárový graf, i ten však nefunguje s velkým množstvím dat. Existuje však i poněkud obskurní forma vizualizace nazývaná slope graph, který se zdá být ideální pro zachycení relativní změny hodnot i u velkého množství kategorií.

Porovnání počtu cizinců v ČR podle národnosti mezi roky 2004 a 2014

Slopegraph si v Excelu nenakreslím, takže nakonec nejjednodušší mi přišlo si jej naprogramovat. Využil jsem k tomu implementaci od Zacha Bjorsona nad knihovnou D3.js. Vizualizace má ještě řadu much, ale třeba budu mít ještě možnost je vychytat.

Počet cizinců v ČR podle národnosti mezi roky 2004 a 2014

Maličkosti

Sun, 20 Sep 2015 19:15:00 +0200

Po tři dny a tři noci neopustil mistr Javy svou kóji. Čtvrtý den za ním poslali mniši novice.

Novic našel mistra u tabule, jak přemýšlí nad jediným diagramem toku dat. Novic rozpoznal, že se jedná o nevýznamnou část ohromného systému, který mniši spravovali. Nesměle se proto otázal, na čem mistr pracuje.

Mistr odpověděl: „Někde je tu chyba a přemýšlím, jak ji nejlépe opravit.“

Novic řekl: „Často nám kážete o tom, jak důležité je stanovit si správně priority. Jak je tedy možné, že zde ztrácíte čas nad nečím tak malým a bezvýznamným?“

Bez jediného slova mistr pozvedl hůl a udeřil novice do nohy tak silně, že mu zlomil malíček. Novic zakřičel bolestí a zaskočeně se vypotácel z kóje. V ten moment byl novic osvícen.

Překlad The Small Stuff ze sbírky The Codeless Code: Fables and Kōans for the Software Engineer od mistra Qi.
Publikováno pod licencí Creative Commons Uveďte autora–Neužívejte komerčně 3.0 Unported.

Základy studia nových médií: chybějící části

Fri, 18 Sep 2015 18:00:00 +0200

Naposledy jsem poctivě psal domácí úkoly pro StuNoMe před rokem a půl. Resty se však nedají odkládat věčně. Po Marxovi, pejskovi, kočičce a Manovichovi jsou na řadě postmoderní filozofové.

Goodmanova světatvorba

Podle Nelsona Goodmana¹ neexistuje jeden reálný svět; místo toho existuje mnoho alternativních světů, které mají svůj účel, ale žádný z nich není schopen zachytit „skutečný svět“ jako takový – to, co považujeme za empirickou realitu, je pouze náš způsob vidění světa.

V takto relativistickém systému pochopitelně nemůžeme nic hodnotit objektivně. Například „pravda“ – pokud v daném světě vůbec něco jako „pravda“ existuje – má pokaždé jinou podobu. Světy můžeme posuzovat nanejvýš mezi sebou. Pokud si určitý svět stanovíme jako referenční (naši „objektivní realitu“), můžeme v jejím referenčním rámci považovat některé světy za pochybné. Jestli v našem světě máme „empirické důkazy,“ podle kterých se Země otáčí kolem Slunce, tak víme, že heliocentrický model je mylný; přesto byl v minulých světech považován za reálnou pravdu.

Typickým případem světatvorby – či spíše reflexe různých verzí reality – jsou různé úrovně abstrakce. Jeden objekt můžeme popsat v rámci různých sytémů, které budují vlastní vidění světa na základě určitých axiomů. Potom například jablko může být z botanického pohledu plod krytosemenné rostliny, z chemického pohledu shluk molekul či složitějších vazeb aminokyselin, z fyzikálního pohledu skupenství atomů a z nutričního pohledu je to zdroj vlákniny a vitaminu C…

Co zde provádíme je zvýrazňování a potlačování určitých aspektů v té které verzi reality. Goodman konkrétně jmenuje několik způsobů světatvorby: kompozice / dekompozice – stejnou věc můžeme rozložit či složit více způsoby; zvýrazňování – záměrně vyzdvihujeme určité aspekty světa; uspořádání – jaký je vnitřní řád světa²; vylučování a doplňování – přidává či ubírá některé prvky ze světa; deformace – zkreslení či naopak korekce některých aspektů.

Krásné na Goodmanově irrealismu je, že je prakticky neprůstřelný. I pokud jej zavrhnete, děje se tak ve vaší verzi světa, s čímž ovšem Goodmanova teorie tak nějak počítá.

Pochopitelně ani Goodmanova teorie není vyňatá sama ze sebe. Přesněji řečeno: světatvorba je jeden z pohledů na světatvorbu. Tím, že nám Goodman nabízí určité nástroje pro světatvorbu, provádí určitou redukci pohledu na realitu. Zároveň je zapotřebí mít na paměti, že pokud posuzujeme světy mezi sebou, činíme tak z pozice „našeho světa.“ To určuje jaké aspekty v porovnání zvýrazníme či vynecháme…

Už vás z toho bolí hlava? Pustíme si radši písničku.

Röyksopp – Remind Me: Videoklip v infografikách mnoha světů.

Příspěvky od spolužáků

Baudrillardova simulákra

Podle Jeana Baudrillarda³ naše postmoderní civilizace už dávno neexistuje v realitě. Místo toho žijeme v hyperrealitě utvářené simulákry. Ve zkratce se jedná o kopii bez předlohy, která je reálnější než realita – předčí realitu a stává se realitou.

Jsou to zejména symboly vytvářené kulturou a médii; naše existence je zcela saturována mediální realitou, kterou nedokážeme oddělit od „skutečného světa.“ Baudrillard v tomto směru dával za příklad válku v Perském zálivu – válka, která fakticky existovala pouze v mediálním prostoru, avšak její každodenní přítomnost ji učinila reálnější než reálnou.

Mým oblíbeným příkladem v tomto směru je film Vrtěti psem (Wag the Dog), ve kterém prezidentští poradci vytvoří jako součást kampaně naprosto fiktivní válku s Albánií. Včetně dojemných záběrů prchajících dětí.

„Pan prezident si přeje bílou kočku.“ (kompletní klip)

Svým způsobem je ironické, že pro ilustraci konceptu simulákra používáme filmy a seriály. Tato média se totiž zásadně podílí na konstrukci hyperreality. Nicméně se mnohdy jedná o přiznanou fikci, na rozdíl například od reality show, která si ze své podstaty „hraje na realitu.“ Jak píše Hana:

Podle Baudrillarda je za oblíbeností tohoto druhu hyperreality touha po banalitě (!) a po stejnosti. Obraz banality se při sledování reality show stává důležitější než skutečnost, že sám žiju banální život a koukám se na desítku lidí zavřených ve vile, kde je 24/7 za tmavými skly sledují kamery.

Mediální konstrukce reality představuje pouze nejobligátnější příklad. Peníze, průmysl, jazyk…; co mohlo být dříve určitým odrazem reality, bylo povýšeno na symboly s intrinsickou hodnotou, které nemají žádný předobraz. Nejsou však falešné či nereálné. Jsou skutečnější než skutečné. Utváří tvárnou a vždy proměnlivou hyperrealitu.

Baudrillardova teorie představuje zajímavý nástroj pro kritickou reflexi přemedializované kapitalistické společnosti. Není mi však zcela jasné co je podle Baudrillarda ona prapůvodní realita, kterou simulákra nahrazují. Baudrillard spojuje vzestup simuláker s industrializací a „konsumerizací“ společnosti. Společnosti, která se oprostila od všeho sakrálního a vydala se na sestupnou spirálu materiálního konzumu.

Je však cesty zpět? S pokrokem vědy paradoxně odhalujeme stále více o své „skutečné nátuře“ a zbavujeme se posledních iluzí o výlučnosti vlastní existence. I lidské vědomí tak nakonec může být pouhým konstruktem, simulákrum, které nemá žádný odraz v realitě. Jen evoluční trik organismu řízeného biologickými imperativy. A simulákra tvoří obranný mechanismus kultury, kterou se tento organismus obklopil, jako zámotek.

Tohle začíná být moc depresivní, chce to nějaký veselý obrázek na rozptýlení chmurných myšlenek…

Zdroj: Nihilisa Frank

Příspěvky od spolužáků

Heideggerova Otázka techniky

Martin Heidegger, zaručeně jeden z nejobtížněji čitelných filozofů vůbec, se v eseji Otázka techniky⁴ věnuje podstatě technologie. Techné je činnost, která odkrývá něco skrytého; když řemeslník vytvoří stříbrnou misku, odkrývá ve stříbru jeho možný potenciál za určitým účelem. Rozdíl oproti moderní technologii je v pasivu: v dřívějších dobách se příroda nechávala odkrýt, moderní technologie si však vynucuje odkrytí. Zatímco větrný mlýn využívá přirozeně se vyskytující zdroj, přehrada postavená pro potřeby vodní elektrárny přizpůsobuje tvář krajiny ke svému účelu: pokud není proud pro turbiny dostatečně silný, prostě si jej vymůžeme. Zběsilým příkladem tohoto přístupu je frakování – vymůžeme si suroviny z půdy i tam, kde se nenachází dostatečně velká ložiska.

Moderní technologie s sebou nese kompletní způsob myšlení, který od základu mění náš pohled na přírodu i nás samotné. Heidegger to nazývá Gestell (v angličtině bývá v tomto kontextu překládáno jako enframing). Jde o vidění světa jako pasivní zásobárny zdrojů. Skála se stává „zdrojem stavebního materiálu,“ řeka „zdrojem energie,“ ale třeba i krajina se stává „zdrojem turistického ruchu.“ Zároveň si technika na člověku vymáhá, aby vymáhal zdroje.

Nakonec i člověk se stává zdrojem. Nad pojmem „lidské zdroje“ už se dnes málokdo pozastaví. V digitální éře se naše činnost a naše pozornost stává zdrojem skrze data, která produkujeme, a reklamy, které vnímáme.

Téma se vlastně točí kolem Heideggerova ústředního tématu bytí – technika nás v tomto směru odvádí od bytí. Paradoxně skrze proces odkrývání dochází k zakrývání bytnosti; setrváváme ve stavu vymáhání a zavíráme si tak další cesty. Můžeme to uchopit i z Goodmanovy či Baudrillardovy perspektivy. Technika nás odkazuje do vymezené množiny světů, které souhrnně tvoří Gestell. Technika jsou zároveň i simulákra, která nám zakrývají podstatu bytí tím, že se sama povyšují na princip bytí.

Další zdroje

Eva Peterková má skvělé výpisky k Otázce techniky.

Chytré hlavy z Wisecrack také zpracovaly 8-bitovou interpretaci Heideggerovy eseje. Se Star Wars. Martin Heidegger versus Darth Vader.

Příspěvky od spolužáků

McLuhan: Médium je mesáž

„Médium je poselství!“ prohlásil Marshall McLuhan a zmizel v obláčku mediální teorie. McLuhanovo chápání „média“ však přesahuje naši běžnou představu masmédií. Médium utváří prostředí, ve kterém se šíří obsah a zároveň jiná média. Média se tak stávají extenzí jiných médií; jako knihtisk je extenzí psaného textu, text je extenzí řeči… Média jsou však nedílně spjatá s obsahem, který šíří; jako když text linearizuje nelineární rozhovor a fixuje jej v čase. I žárovka je médium; médium bez obsahu, které vytváří prostor pro další média, jaká by bez její přítomnosti nemohla existovat. The Medium is the Message.

„Médium je masáž“ – tak McLuhan pojmenoval koláž „sbírky efektů,“ které na nás média mají. Neboť média masírují naše smysly, jsou všudypřítomná a neponechají na nás nic nezměněného. Kompletně nás přepracují. The Medium is the Massage.

Média jsou extenzí nás samotných. Kolo je extenzí nohy. Oblečení je extenzí kůže. Kniha… …je extenzí oka. Elektrický obvod je extenzí centrálního nervového systému.⁵ Média mají potenciál rozšířit náš „pohled,“ naše zorné pole, a přesto nás připoutávají na místo. Elektronická média vytvořila „masu“ individuí, která si však drží svůj fixní pohled na realitu – namísto zkoumání jiné perspektivy,⁶ jiných světů. The Medium is the Mass Age.

The Medium is the Massage zní jako důmyslná slovní hříčka. Přitom vznikla omylem, chybou v tisku. Když McLuhan chybný titulek viděl, prý radostně zvolal: „Takhle to nechte!“⁷ Hlubšímu smyslu předcházela náhoda. Kniha má i zvukové zpracování; řečník, který čte úryvky z knihy, je přehlušován jinými řečníky a hudbou. Protože jak lépe zachytit fragmentovanost a kognitivní zátěž současného přemedializovaného světa než skrze nahodilou a nesmyslnou koláž? Možná se zde ukrývá nějaká důmyslná zpráva. Možná jen celá tiráda zakrývá skutečnost, že zde nic není. The Medium is the Mess Age.

Goodman, Nelson. Způsoby světatvorby. ↩
Krásným příkladem je dominance desítkové soustavy v našem světě; proč slavíme „kulatá“ výročí a měříme dekády, staletí či milénia? Nejspíše proto, že máme deset prstů… ↩
Baudrillard, Jean. Praecessio Simulacrorum. In: Host, č. 6. 3-28. ↩
In: Heidegger, Martin. Věda, technika a zamyšlení. Vyd. 1. Praha: OIKOYMENH, 2004, 62 s. Knihovna novověké tradice a současnosti. ISBN 80-729-8083-1. ↩
McLuhan, Marshall a Quentin Fiore. The Medium is the Massage: An Inventory of Effects. Vyd. 1. Corte Madera: Gingko Press, 2001,c1967, 159 s. ISBN 15-842-3070-3. str. 26—41 ↩
ibid. str. 68—69 ↩
Commonly Asked Questions (and Answers) by Dr. Eric McLuhan, Marshall’s eldest son ↩

Zredukuj, znovupoužij, zrecykluj

Sun, 05 Oct 2014 19:10:00 +0200

Žák se zeptal mistra: „Co je to Cesta?“

Mistr odpověděl: „Psaní kódu je Cesta.“

Žák se pak zeptal: „Co není Cesta?“

Mistr odpověděl: „Psaní kódu není Cesta.“

Žák prohlásil: „Potom je psaní kódu úplně vše.“

Mistr odpověděl: „A nepsaní kódu je také vše.“

Žák se zeptal: „V tuto chvíli píšeme, nebo nepíšeme kód?“

Mistr odpověděl: „To my jsme kód.“

Překlad Reduce, Reuse, Recycle ze sbírky The Codeless Code: Fables and Kōans for the Software Engineer od mistra Qi.
Publikováno pod licencí Creative Commons Uveďte autora–Neužívejte komerčně 3.0 Unported.

IRuby: IPython naRuby

Wed, 04 Jun 2014 22:00:00 +0200

Jak jsem se naučil nedělat si starosti a mít rád notebook

Text vychází z mé přednášky na květnovém Ruby srazu v Praze.

tl;dr

Je otrava přednášet o programování s klasickými slidy.
Lepší přístup je notebook.
IPython není jen pro Python, ale i pro Ruby – a takhle to vypadá.
Notebooky v praxi fungují dobře.
S notebooky se dá přednášet.
Ale zprovoznit to nemusí být sranda…

Problém se slidy

Od loňského roku jsem začal učit programování v Ruby na Fakultě informačních technologií ČVUT, v předmětu MI-RUB. Jestli mě na přednášení něco nebavilo, je to příprava materiálů. Bez ohledu na množství obrázků a jak moc to „zaobalíme,“ nevyhnutelně dojde na ukázky kódu.

Prezentační slidy pak slouží jednak jako vodítko pro přednášející, jednak jako reference pro studenty. Typicky sáhneme po nějakém „slideware“ typu PowerPoint, případně po LaTeXu, který se alespoň postará o obarvení kódu. Progresivnější přednášející si připraví prezentaci v prohlížeči třeba s Reveal.js, ještě lépe psanou v Markdownu – například s Remark.js. Jenže ať obarvíme kód sebelépe, neřeší to jeden zásadní problém.

Při učení se nového jazyka (a programování vůbec) mi připadá důležitá fáze experimentování, možnost spustit existující kód, upravit jej, pozorovat změnu chování, rozbít jej, zjistit proč to nefunguje atp. Statické slidy s ukázkami kódu od experimentování spíše odrazují; pokud si chci ukázky sám vyzkoušet nebo předvést jejich variaci, kód musím postupně zkopírovat do samostatného souboru nebo do interpreta (například IRB) – „ideálně“ je kód přes několik slidů s vnořenými bloky. V případě MI-RUB udržujeme část ukázek stranou. To znamená více práce s údržbou pro nás a ztrátu času s hledáním kódu pro studenty (nemluvě o porušení DRY).

REPL FTW!

Ve snaze najít lepší přístup k přednášení mě napadlo, zda by se řešení nemohlo skrývat v REPL – Read–eval–print–loop, tedy interaktivní shell pro jazyk, jako již zmíněný IRB pro Ruby. Kouzlo REPL spočívá ve velice krátké smyčce mezi vstupem a zpětnou vazbou: napíšu řádku kódu a vidím výsledek – nebo chybu. Je to mnohem přístupnější než tradiční práce s textovým editorem nebo IDE, kde jsou fáze psaní kódu a spouštění kódu striktně oddělené. Velice pěkně toho využívá stránka TryRuby, která spojuje lineární výklad s experimentováním v REPL pro výuku jazyka.

Některé programovací jazyky a prostředí používají REPL jako primární způsob interakce. Na SNM jsme tak vytvářeli analýzy v jazyce R. RStudio IDE funguje především jako velký REPL s pokročilou historií a náhledem na data. Naše analýzy v R však většinou byly jednoduché dávkové skripty pro které je tento způsob práce naprosto ideální.

Pro účely výuky má však REPL řadu nevýhod. Není úplně jednoduché se vrátit zpět a změnit starší definici; musím si ji najít v historii, upravit a znovu spustit. Velký problém je i reprodukovatelnost; schválně, jak si v IRB uložím do souboru to, co jsem napsal? Že jsem měl použít Pry? Výsledkem však bude stále jen neokomentovaný textový soubor s mými vstupy, který můžu spustit jako celek, nebo řádku po řádce. S přípravou materiálů to příliš nepomůže.

Potřebovali bychom zkombinovat interaktivitu REPL s přenositelností prezentace nebo textového dokumentu. Dobrá zpráva je, že řešení existuje – a matematici nemusí číst dál.

Notebook je kamarád

Zdá se, že vědci tento problém vyřešili už před více než dvaceti roky. V aplikacích pro symbolickou matematiku a vizualizace, jako je Maple nebo Mathematica, se pracuje s interaktivními dokumenty, tzv. worksheety nebo notebooky.

Notebook v aplikaci Wolfram Mathematica (zdroj)

Notebook se skládá z jednotlivých buněk (cells); do buňky zapíšu kus kódu, který spustím a výsledek se mi zobrazí pod buňkou. Funguje to podobně jako REPL, ale se všemi výhodami textového dokumentu. Můžu změnit libovolný kus kódu a ten opět spustit.

Navíc v buňkách nemusí být jen spustitelný kód – mohou být i textové, ať už se jedná o zformátovaný text nebo třeba nadpisy. Notebook se ukládá i s výsledky výpočtů, takže ho můžu sdílet dál, převést do jiného formátu nebo vytvořit interaktivní prezentaci. Skvělé na tom je, že mám jediný zdrojový dokument s textem, kódem i jeho výsledky, který můžu sdílet dál beze ztráty informací nebo interaktivity. A nepotřebuji dělat vědecké výpočty, jako je třeba vizualizace Batmanovy křivky, abych využil výhody, které mi notebook nabízí.

Maple i Mathematica jsou však proprietární aplikace – a docela drahé. Proto vznikly svobodné alternativy; například Sage, který poskytuje mj. rozhraní pro notebook v prohlížeči sagenb.

Sage však trpí dalším neduhem: je primárně navržený pro práci v Pythonu, společně s ekosystémem knihoven a rozšíření specifických pro Sage. Celý systém je úzce provázaný, takže používáme-li jiné jazyky, moc nám nepomůže.

IPython – univerzální notebooky

Sage se zaměřuje na výpočty a vizualizace, přičemž jako prostředek používá Python. Paralelně však na bázi Pythonu vznikl jiný projekt: IPython. Původním cílem bylo vytvořit lepší REPL, avšak postupem času vznikl jeden z nejpropracovanějších interaktivních shellů vůbec, který umí zobrazovat i vizualizace. Ale zatímco Sage od základu nabízí vše „all inclusive,“ IPython je čistý Python s podporou pro grafické formy výstupu. Podobně jako Sage také nabízí rozhraní pro práci s notebookem v prohlížeči – IPython Notebook.

Notebook v tomto případě představuje jeden ze tří standardních frontendů – vedle textového rozhraní a grafické Qt konzole. Frontend je striktně oddělený od výpočetního jádra, které od něj přijímá zprávy a vrací výsledky.

Notebook běží jako webserver a komunikuje s výpočetním jádrem; editor zároveň běží jako klientská aplikace v prohlížeči, která se serverem komunikuje přes websockets.

Oddělení jádra od frontendu může na první pohled vypadat jako samolibý overengineering, ale je to zcela zásadní výhoda IPythonu. Komunikace s jádrem probíhá pomocí ZeroMQ, takže jádro může klidně běžet na jiném stroji než frontend. Jader může být i více – IPython má podporu pro paralelní výpočty. Můžete tak ovládat výpočetní cluster přímo z pohodlí notebooku.

Pro nás je ovšem zásadní fakt, že výpočetní jádro nemusí být vůbec napsané v Pythonu. Alternativní jádra jsou vítaná a těší se stále lepší podpoře. Existuje například jádro pro Haskell, jádro pro jazyk Julia je dokonce oficiální součástí projektu Julia. A ano, existuje i jádro pro Ruby, obligátně nazvané IRuby.

Co je v notebooku

IPython notebook je soubor s příponou .ipynb. Jedná se o obyčejný JSON, ve kterém je jak obsah jednotlivých buněk, tak výstup spuštěného kódu. Příkazem ipython notebook (případně iruby notebook) se pak v aktuálním adresáři spustí webový server s editorem notebooku.

Buňky v dokumentu mohou být různých typů – kromě samotného kódu i bloky textu psané v Markdownu nebo nadpisy různých úrovní (pro lepší strukturování). Vedle toho může buňka nést i různá metadata – to se hodí především pro tvorbu prezentací (popisuji níže). Metadata buňky lze editovat přes Cell Toolbar.

Buňky s kódem můžu spustit dvojhmatem Ctrl+Enter. Rozhodující přitom není pořadí buněk v dokumentu, ale pořadí jejich spuštění – to indikují čísla nalevo od buňky. Definice si pamatuje aktuálně běžící jádro, takže pokud server mezitím restartuji nebo notebook otevřu na jiném počítači, je většinou dobré spustit všechny buňky v pořadí, v jakém jsou definovány. Tím, že buňky běží ve stejném kontextu, z nich lze postupně sestavit aplikace, které sahají přes několik tříd a metod.

Číslo nalevo od buňky označuje pořadí spuštění tak, jak si je pamatuje jádro.

Speciální funkce pro vizualizaci v noteboocích jsou nejlépe podporované v Pythonu (nepřekvapivě). IRuby se však v tomto směru začíná zlepšovat, takže s využitím dalších gemů je možné i v notebooku vytvářet elegantní grafy.

K čemu se notebooky nehodí

Notebooky jsou ideální na ukázku syntaxe a základních konstrukcí jazyka, případně na demonstraci jednoduchých aplikací. V některých případech se formát notebooku z principu nehodí.

U základních aplikací se často pracuje s přímým uživatelským vstupem z klávesnice (gets a podobně) – ten však v notebooku bohužel neumíme nasimulovat, takže příklady by s tím neměly pracovat.

Problém může nastat také u rozsáhlejších aplikací, například nad frameworkem Rails – notebook sice může načítat vnější závislosti, ale třeba webový server přímo z notebooku nejspíš nepoběží: jádro se zablokuje na vstupu ze socketu a nebude přijímat další příkazy. Leda by se spustilo v separátním vlákně… Na druhou stranu, zprovoznit konzoli Rails v IPython notebooku, to už je zajímavá výzva.

Velký problém mohou být i chyby v jádru jazyka. IRuby funguje tak, že nahrazuje některé standardní třídy (včetně třídy Kernel) vlastní implementací, která posílá výstupy zpět do notebooku. Občas se pak může stát, že v jádru zkrátka není implementovaná nějaká metoda, kterou nějaký gem používá. V takovém případě to chce klid a hlásit chyby.

Notebooky v praxi

Během prvního semestru jsem přepsal část přednášek z LaTeXu do formy notebooků a osvědčilo se mi to v několika směrech.

Příprava materiálů se stala mnohem pohodlnější. Mám jistotu, že ukázkový kód bude fungovat a bude vracet správný výstup. Navíc se v Markdownu pracuje mnohem lépe, než v LaTeXu.

Práce s výstupy je jednodušší. Když mám zdrojové materiály v LaTeXu, musím je upravit, vyexportovat do PDF (zpravidla ve více variantách), a ty nahrát na náš server pro podporu výuky. Zdrojový notebook verzuju ve veřejném repozitáři a kdokoliv si jej může zobrazit přes nbviewer, i pokud nemá nainstalovaný IPython. Jakmile dojde na prezentaci nebo jiný výstup, můžu jej zkonvertovat jedním příkazem do řady dalších formátů, včetně LaTeXu.

A v neposlední řadě, vše se rychleji upravuje a lépe se mi pracuje se zpětnou vazbou. Pokud si během přednášky někdo všimne chyby, padne zajímavý dotaz nebo nastane nějaká nejasnost, můžu chybu hned opravit, případně doplnit další kód, který problém lépe vysvětluje. Po přednášce pak změny jen uhladím a publikuju.

Po IRuby jsem sáhnul i na Rails Girls, kde jsme si v notebooku ukázali dědičnost tříd.

Včera jsme programovali psa. Goofy je basenji. 😉 @RailsGirlsPRG pic.twitter.com/jEcbKqbYhW

Hana Svabova (@HanaSvabova) May 18, 2014

Nicméně já s IPythonem v podstatě teprve začínám. Například Eric Matthes používá IPython pro úvod do programování a C. T. Brown s ním učí evoluční biologii.

Jak na to

IPython a IRuby

Zprovozněte IPython Notebook alespoň verze 1.2 (aktuální je 2.1) – viz oficiální dokumentace.
Pro instalaci gemu je nutné mít správnou verzi knihovny ZeroMQ (alespoň 3.2) pro gem ffi-rzmq:
- pod Debianem a Ubuntu buď balíček libzmq3-dev (pro kompilaci), nebo ruby-ffi-rzmq s libzmq3;
- pod Windows (netestoval jsem) bude nutné nainstalovat ZeroMQ.
Gem nainstalovat přes gem install iruby.

Server se spouští příkazem iruby notebook v adresáři s notebooky. Chová se stejně jako příkaz ipython, ale pracuje se zcela izolovaným adresářem pro profily.

Prezentace s notebookem

Pro vytváření prezentací používám výše zmíněná metadata u buněk. Buňce nastavím příslušné chování (-/Slide/Subslide/Fragment/Skip/Notes), podle kterého se vygeneruje výsledná prezentace. Tím pádem mohu některé buňky z prezentace zcela vynechat a některé použít jako poznámky přednášejícího – názorně je to ukázané v tomto článku. Zkonvertovaný notebook pak bude používat Reveal.js. To má však jeden zásadní háček: vygenerovaná prezentace obsahuje opět jenom statické ukázky kódu, tím pádem celá anabáze za lepším přednášením ztrácí smysl.

Editor notebooků je jenom JavaScript, HTML a CSS, takže není problém jej rozšířit o další funkce. K tomu existuje celý repozitář notebook-extensions, konkrétně rozšíření slidemode, které umožňuje editor notebooku přepnout do režimu prezentace. Ta se potom chová podobně jako vyexportovaná prezentace (používá stejná metadata), ale všechny buňky je možné upravovat a spouštět.

Slidemode v prohlížeči

Systém rozšíření se však v IPythonu 2 změnil, takže současná rozšíření fungují zřejmě jinak. V mezičase nabízím svou verzi slidemode pro IPython 1.2.1, kompatibilní s profilem IRuby.

Třeba se časem dočkáme i oficiální podpory.

Další zdroje

Jiné nástroje a postupy

Beaker Notebook je alternativa IPython Notebooku od základu navržená pro podporu více jazyků. V současnosti je ve fázi betaverze a využívá část existujících jader pro IPython. Beaker existuje sotva půl roku, takže je příliš brzo činit závěry; určitě se však vyplatí sledovat jeho vývoj.
repl.it řeší REPL přímo v prohlížeči – interpret jazyka je zkompilovaný pomocí Emscripten do JavaScriptu.
Pro jazyk R existuje R Markdown, standardní Markdown dokumenty, kde se bloky kódu automaticky spustí. Z takových dokumentů je možné i generovat prezentace.
GitBook slouží primárně pro psaní interaktivních knih, ale také umožňuje vložit interaktivní kusy kódu – v současnosti je podporovaný JavaScript, ale podle autorů je plánovaná podpora Ruby i Pythonu.
Ještě pokročilejším nástrojem pro interaktivní knihy je Runestone Interactive, pod který spadá i web Interactive Python.
Zajímavé je využití notebooků pro ukázku API. Projekt RAML pro popis REST API nabízí API Notebook. Jedná se spíše o obecný notebook pro JavaScript s knihovnou pro import RAML.

Jiný přístup k notebooku

Emacs IPython Notebook přidává práci s IPython Notebookem přímo do editoru.
Obdobný plugin existuje i pro Sublime Text.
Naopak pro editor v prohlížeči je možné použít rozšíření IPython Vimception, které simuluje chování Vimu.

O IPythonu

Honza Cibulka popsal jak na analýzu dat v IPython notebooku.
Fernando Perez, autor IPythonu, sepsal zajímavou historickou perspektivu o IPython Notebook – jaký je vztah k projektu Sage a co všechno umožnila zvolená architektura IPythonu.
Andrew Gibiansky popsal velice podrobně co zahrnuje vytvoření jádra pro IPython.
Eric Matthes popsal, jak IPython a GitHub změnily jeho způsob výuky programování (k lepšímu).
C. Titus Brown popisuje svou zkušenost s IPythonem pro výuku evoluční biologie a shrnuje výhody a rizika tohoto přístupu.

Rails Girls Prague pohledem kouče

Sat, 31 May 2014 00:00:00 +0200

Před dvěma týdny jsem měl možnost koučovat na třetím ročníku Rails Girls v Praze. Byla to natolik výborná zkušenost, že jsem se rozhodl k ní sepsat pár myšlenek – a zároveň shrnout připomínky, které jsem probíral s účastnicemi a ostatními kouči.

Rails Girls je iniciativa s cílem zpřístupnit programování ženám a dívkám skrze vývoj webových aplikací v Ruby on Rails. Začalo to v roce 2010 ve Finsku víkendovými workshopy, které se dnes konají po celém světě. Od minulého roku se také pořádá Rails Girls Summer of Code, kde účastnice tři měsíce pracují na vybraných open-source projektech – a dostanou za to zaplaceno. Jde vlastně o ekvivalent Google Summer of Code pro začínající programátorky.

Kromě Prahy se workshopy pořádají také v Ostravě, v Brně (zrovna tento víkend) a údajně se chystá i Olomouc.

U nás se Rails Girls konají zpravidla jednou ročně a probíhají zhruba takto:

V pátek se koná „install party,“ kde kouči pomohou účastnicím zprovoznit základní nástroje: terminál, Ruby, Rails, Git a textový editor.
V sobotu projdeme základy programování, jazyka Ruby a webových aplikací. Během odpoledne si pak účastnice vytvoří jednoduchou aplikaci v Rails – podle návodu a za asistence koučů.
V neděli se aplikace vypustí do světa a účastnice si ji přizpůsobí k obrazu svému.

Na jeden víkend je toho skutečně hodně, avšak cílem akce není udělat z účastnic ostřílené programátorky během tří dnů. Cílem je ukázat, že počítače nejsou černé skřínky žijící si vlastním životem a programování není magie, kterou by měla ovládat jen úzká skupina vyvolených. Řada účastnic má „ajťáky“ ve svém okolí a díky Rails Girls nahlédnou do žargonu, na kterém celé IT stojí. Zároveň získají základní představu, jak fungují webové stránky, které denně používají, ať už jde o Seznam, iDnes nebo Facebook. A v nejlepším případě je programování zaujme natolik, že po workshopu pokračují dále a v některém z dalších ročníků začnou samy koučovat.

Poslední možnost zní jako zbožné přání, jak by to hypoteticky mělo fungovat. Ovšem zdá se, že to skutečně funguje: právě letos koučovaly i dvě účastnice předešlých ročníků. Děvčata už pracují i na vlastním projektu – Bezlepci, databáze obchodů a potravin pro lidi s bezlepkovou dietou. Rails Girls mají reálný dopad.

Proč vůbec Ruby?

Když se o Rails Girls bavím s jinými vývojáři, občas dojde na otázku: „Proč by se holky měly učit právě Ruby? Proč ne třeba ${můj oblíbený jazyk}?“ Název Rails Girls samozřejmě odkazuje na framework Ruby on Rails, který stojí na jazyce Ruby.

Osobně si myslím, že samotný vznik Rails Girls nebyl předurčen pouze syntaxí nebo jinými vlastnostmi jazyka, jako spíše základními myšlenkami a konkrétními osobnostmi, které formovaly komunitu Ruby vývojářů.

Začal bych u tvůrce jazyka Ruby – Yukihiro „Matz“ Matsumoto. Matz možná není geniální programátor, ale klade důraz na přístupnost programování pro lidi, nejen pro stroje. To bylo i principem pro návrh Ruby:

Doufám, že Ruby pomůže všem programátorům, aby byli produktivnější, aby je programování bavilo a aby byli šťastní. To je hlavní cíl jazyka Ruby.

Yukihiro Matsumoto, Ruby 1.9 na Google Tech Talks

Matzův nekonfliktní a přátelský přístup vedl i ke rčení Matz is Nice So We Are Nice jako určitému pravidlu komunity. A přestože toto pravidlo časem ztratilo váhu a ne všichni rubysti jsou tak přátelští, komunita kolem Ruby je rozmanitá a plná lidí, které prostě baví programovat.¹

Další unikátní postavou mezi rubysty byl why the lucky stiff; byla to právě whyova tvorba, která mě přivedla k Ruby. Programátor, spisovatel, hudebník a kreslíř v jedné osobě – why viděl programování jako další formu exprese; způsob, jak vyjádřit své myšlenky.

when you don‘t create things, you become defined by your tastes rather than ability. your tastes only narrow & exclude people. so create.

why the lucky stiff, via Joey Devilla

Why skrze projekty jako TryRuby a Hackety Hack! zkoumal, jak zpřístupnit programování neprogramátorům, především dětem; v textu Průšvih malého kodéra shrnuje, že problém tkví v uzavřenosti systémů a nepřístupnosti nástrojů.

why‘s (poignant) Guide to Ruby, why the lucky stiff

Mimo to napsal i legendární whyovu (srdceryvnou) příručku Ruby. Nejedná se ani tak o učebnici jazyka, jako post-moderní hybrid poezie, komiksu a kódu. Upřímně, není to kniha pro každého, ale garantuji vám, že si s ní rozšíříte slovní zásobu, představivost a (v kombinaci s psychotropními látkami) vědomí – a nezapomeňte, že ke knize existuje neméně skvělý soundtrack.

Už to bude pět let, co why ukončil svou digitální existenci, ale jeho projekty stále existují a na jeho odkaz navazují další lidé.

To mě přivádí k Lindě Liukas – jedné ze zakladatelek Rails Girls a autorce chystané knihy Hello Ruby – učebnice programování pro děti ve věku od čtyř do sedmi let. Kniha vypráví o děvčátku Ruby, které se během svých dobrodružství skamarádí se Sněhovým leopardem, upeče perníčky se zelenými roboty a také potká moudré tučňáky a kluka, který se jmenuje Django… Podobnost s existujícími softwarovými projekty je zcela záměrná, ale není to hlavní pointa knihy.

Hello Ruby, Linda Liukas

Linda chce svět softwaru ukázat jako svět netušených možností, svět, ve kterém se nápady snadno stanou skutečností – a programování jako prostředek, který nám umožní nápady realizovat. Stejně jako u whye, za každou řádkou kódu se skrývá příběh a cílem je radost z tvoření skrze programování. Tak, jak si to přál Matz.

Takže proto Ruby.

Nicméně můj pohled je trochu zkreslený tím, že jsem rubysta. Jiné jazyky mají své vlastní iniciativy, ať už se jedná třeba o pyLadies, Clojure Bridge nebo PHP Women. Cílem není pokračovat svatou válku o nejlepší jazyk, ale zpřístupnit programování všem, kteří mají aspoň trochu zájem, bez ohledu na rasu nebo pohlaví. Nedostatek diverzity v IT se týká celého odvětví, nejen Ruby.

Proč koučovat?

Sice jsem o programování v Ruby přednášel celý semestr na FIT ČVUT, ale teprve na Rails Girls jsem si vyzkoušel, co o tom skutečně vím. Vysvětlit principy programovacího jazyka studentovi IT a někomu, kdo právě napsal první řádku kódu, není různě obtížné, je to naprosto nesrovnatelné. A práce s neprogramátory má řadu výhod – nemají špatné návyky z jiných jazyků a nepošlou vás do háje s tím, že v jejich jazyce se to řeší mnohem lépe!

Část práce odvedou přednášející – Karel Minařík v úvodu vysvětlil, že „algoritmus“ je vlastně totéž, jako kuchařský recept. A Robin Pokorný zase ukázal, k čemu jsou dobré kaskádové styly. Ale je potom na koučích vysvětlit konkrétní koncepty a provést účastnice nejastnostmi. K tomu koučové potřebují tři věci: znalost Ruby, trpělivost, ochotu a kofein. Schopnost počítat do čtyř je výhodou.

Pokud něco zůstane nepochopeno, zkuste to vysvětlit jinak. Mně se třeba osvědčilo popisovat „co počítači říkám“ – a proč a jak si to počítač vykládá. A pokud ani to nepomůže, zkuste přivolat jiného kouče, třeba to prostě vidíte jinak.

Po dvou dnech vysvětlování jsem necítil hlasivky a na nohou mě drželo především maté – ale stálo to za to! Atmosféra workshopu se nedá popsat; ještě jsem nezažil takový zájem o učení se, natož u tak složitých technických konceptů. Motivace všech účastníků dělá tyto workshopy skutečně výjimečné. A každé drobné vítězství nad kódem, každý úspěšně pochopený koncept, je pro kouče ohromná radost.

Co udělat lépe?

Na konci workshopu jsme ještě s ostatními kouči probírali, co by bylo možné do budoucna zlepšit. Píšu si to jako referenci do budoucna, ale zároveň jako výzvu pro další programátory, aby přiložili ruku k dílu.

TryRuby stojí za zkoušku, ale…

Sobotní dopoledne věnujeme TryRuby, které obsahuje krátký úvod do konceptů jazyka, provázeného whyovými ilustracemi. Ačkoli témata i texty jsou dobré, narazili jsme na několik konkrétních problémů:

Rychlost: Aplikace běží kompletně on-line a odpovědi někdy trvají příliš dlouho, někdy nepřijdou vůbec.
Nepředvidatelnost: Ačkoli by se mělo jednat o plnohodnotný interpret jazyka, nechová se tak – některé standardní metody zkrátka nefungují. Opačný problém je naopak v lekcích, kde se najednou pracuje s předdefinovanou proměnnou – přitom její definice není vidět.
Motivace: U lekcí jsou sice řečené dílčí kroky, ale není už příliš dobře vysvětlené, k čemu se směřuje. Je fajn, že si můžeme vypsat všechny prvky z pole, ale co s tím? Buď musí nastoupit koučové, nebo by měl být nejprve stanovený cíl a pak probrány dílčí kroky.
Míra abstrakce: Fakt, že aplikace běží v prohlížeči bez jakékoliv vazby na reálné prostředí, může být překvapivý problém. Když přijde na vypisování souborů, odkud se ten soubor vzal? Kde se nachází? V takovém případě je nejlepší vzít irb a ukázat tytéž příkazy na lokálním systému.

Bohužel stávající kód TryRuby není dostupný, takže není v naší moci tyto problémy řešit v on-line verzi. Asi jako nejlepší alternativa se nabízí vytvořit tutorial nad irb v podobě gemu, který si každý spustí u sebe.

Ruby Warrior je super, ale ne pro každého

Některé workshopy vedle TryRuby pracují i se hrou Ruby Warrior – to je takový drsnější Robot Karel. Cílem hry je provést rytíře přes hordu nepřátel až k východu.

Jde o výborné cvičení pro algoritmizaci, ale s velice rychle rostoucí obtížností. Navíc mi připadá, že úlohy nejsou příliš dobré na pochopení principů jazyka, ale jsou spíše vedené ke strukturování kódu. To pro Rails Girls není úplně přínosné.

Pro pokročilejší programátorky a odhodlané bojovnice je to však skvělá výzva. Po mnoha pokusech a omylech jsme se probojovali až do páté úrovně.

Yep, that‘s it! I am a programmer! :) #railsgirlsprg pic.twitter.com/i39hA1Gz3j

Barbora Dušková (@chillipes) May 17, 2014

Dokumentace je dobrá, jen místy nepřehledná

Pro workshopy existuje společná příručka – Rails Girls Guides. Po obsahové stránce je vymyšlená dobře – vysvětluje, co kam zkopírovat, ale současně dává prostor pro vlastní iniciativu a další zdroje.

Problémem se však překvapivě ukázalo být formátování, respektive jeho nedostatek. Příručka sice pracuje s určitou symbolikou, přesto jsme stále museli řešit, která řádka má přijít do terminálu a která do kódu – a zda před <body> nebo </body>; to občas vedlo ke kuriózním chybám. Svou roli mohla sehrát i angličtina; přestože jazyková bariéra nebyla v našem případě zásadní problém, v cizojazyčném textu se člověk snáze ztratí.

Příručku bychom proto rádi přeložili a současně zlepšili její formátování. Osobně si myslím, že by pomohlo rozdělení na jednotlivé kroky, podobně jak to řeší GitBook.

Windows 8 mají problém JavaScriptem

Většina účastnic používá Windows, kde jsme vývojové prostředí řešili přes RailsInstaller. Na Windows 8 nás však čekalo nemilé překvapení, aplikace havarovala na nedostupnosti interpreta JavaScriptu. Korektní řešení je oprava ExecJS, na kterou čekáme už dva roky. Jednoduché řešení je odstranit ze souboru app/assets/application.js řádku:

//= require_tree .

Anebo nainstalovat Node.js.

Heroku není na soubory

V neděli jsme aplikaci nasazovali na Heroku. To s sebou nese ne zcela zřejmý problém: aplikace zahrnuje ukládání obrázků. A ukládání souborů v cloudových službách není jednoduchá věc – instance aplikace jsou dočasné a všechny lokální soubory se dříve nebo později ztratí. Oficiální doporučení zní: ukládejte soubory na Amazon S3. To je pro workshopy nepoužitelné.

Vojta Hýža s Karlem Minaříkem proto vytvořili gem carrierwave-blob, který ukládá soubory do databáze; ideální pro potřeby workshopu, ale už ne pro produkční nasazení.

Rails Girls bez Rails

Nepřekvapilo by mě, kdyby účastnice měly po víkendu hlavu nafouklou jako balon – během cca 20 hodin jsme probrali témata, která většina vývojářů vstřebává roky. Jenže taková je koncepce Rails Girls: od všeho trochu. Jak už jsem zmínil, cílem není pochopit vše do hloubky, ale poznat základní principy.

Svou roli hraje i určitý „wow efekt“ – za víkend si vytvořit vlastní aplikaci bez předchozích zkušeností. Je to mnohem efektnější a užitečnější než vytvořit jen aplikaci pro terminál nebo statickou stránku. Mám však obavy, že tento přístup může být polarizující – někdo se zalekne nad množstvím a šířkou témat, případně utvrdí v přesvědčení, že programování je jenom pro programátory.

Užší záběr by však měl řešit separátní workshop.

Třeba Czechitas, které pořádají Rails Girls na Moravě, berou na separátních srazech algoritmizaci od základu v prostředí Scratch.

Mohli bychom zůstat u samotného Ruby a věnovat se jednoduchým terminálovým aplikacím, klikátkům v Shoes nebo hrám v Gosu. Mohl by to být ekvivalent Code Retreat pro úplné začátečníky – jedno téma, zato dopodrobna a s testy. To už však předpokládá určitou znalost nebo mnohem větší odhodlání naučit se dobře programovat.

Anebo to můžeme vzít přes webové technologie. Dobrým příkladem je Mozilla Webmaker – sada nástrojů a postupů, jak začít tvořit na webu pro web. Koneckonců jsem si všiml, že účastnice zaujala možnost upravit existující stránky pomocí inspektoru, tedy standardního nástroje v každém prohlížeči – to je zajímavá motivace pro pochopení webových technologií. Sám jsem se mnoho naučil psaním jednoduchých userscriptů pro Greasemonkey, které upravovaly existující služby – v praxi to může být přínosnější, než schopnost napsat si aplikaci vlastní.

Možností existuje celá řada, proto pevně doufám, že začátečnické workshopy v ČR nezůstanou jen doménou Rails Girls – nejenom Rails a nejenom pro holky.

Ale třeba jen o takových akcích nevím.

To však není kritika Rails Girls – je to iniciativa, která už si vybudovala jméno a která rozhodně má smysl.

Chtěl bych poděkovat organizátorům – Karlovi, Láďovi, Elišce a Vojtovi – že akci uspořádali a že jsem měl možnost být součástí téhle výborné iniciativy. Těším se na další ročník.

Díky hlavně všem koučům co věnovali svůj čas na tuhle skvělou akci. #railsgirlsprg pic.twitter.com/dQnVnp2DWu

Rails Girls Prague (@RailsGirlsPRG) May 18, 2014

Další reporty

Tomáš Dundáček: Jaké byly pražské Rails Girls?
Nguyen Bach Luu Ly: Rails Girls Prague 2014
Fotografie
- Oficiální: Pátek, Sobota
- Láďa Prskavec
- Lidmila Maršálková
- Matěj Vaněček

(Pokud jsem na někoho zapomněl, pošlete Pull Request nebo se mi ozvěte.)

Což neznamená, že jiné programovací jazyky takové lidi nemají – tedy kromě Rasmuse Lerdorfa. ↩

Muži, kteří nenávidí filmy

Wed, 19 Mar 2014 20:30:00 +0100

Vizualizace filmů na tři způsoby

V závěru Digital Humanities jsme opustili text i grafy a pustili se do zkoumání pixelů. Vzorem nám nebyl opět nikdo menší než Lev Manovič, který se v rámci kulturní analýzy zabývá zejména zkoumáním obrazového materiálu. Možná, že jsou Van Goghovy obrazy mistrovským dílem, ale pro nás je to jen shluk čísel vykazujících určité vlastnosti: světlost, dominantní odstín, poměr stran… Namísto kvality děl nás zajímá kvantita dat – vlastnosti, které lze objektivně měřit a porovnávat. Svým způsobem je to leitmotiv Digital Humanities, který nejradikálněji vyjadřuje Franco Moretti jako Distant Reading: proč bychom měli díla číst, když je může analyzovat stroj? Při množství informací a děl, které lidstvo každý den vyprodukuje, má tento přístup něco do sebe. Redukce informací však nemusí být cíl sám o sobě, analytický pohled „z dálky“ nám může odhalit nové souvislosti.

ImagePlot: Larsson v grafu

V naší analýze jsme se zaměřili na filmy. Nejprve jsme si je rozsekali na jednotlivé záběry pomocí aplikace Shotdetect, se kterou jsem se již důvěrně seznámil při analýze zpravodajství. Výsledné záběry jsme si zanesli na graf prostřednictvím ImagePlot, což je zajímavý „hack“ nad aplikací ImageJ.

Software ImageJ byl původně vyvinutý pro analýzu radiologických snímků, jedná se však o dobře rozšiřitelnou platformu pro zkoumání obrazových dat. Manovič a spol. si jej proto vybrali jako základní nástroj pro své kulturní průzkumy a vytvořili makro ImagePlot. Ten vezme výsledek analýzy sady obrázků z ImageJ a zanese je do grafu; co budou jednotlivé osy grafu znamenat, to záleží na tom, co zkoumáte. Podrobný postup popsal Pavel, včetně kreativních triků jak data pro ImagePlot poupravit.

Pro účely analýzy jsem si vybral rovnou dva filmy; konkrétně švédskou a americkou adaptaci románu Stiega Larssona Muži, kteří nenávidí ženy. Není v tom nějaká speciální záliba v předloze nebo v některé z adaptací, na americké verzi mě zdaleka nejvíc zaujal soundtrack od T. Reznora a A. Rosse (Nine Inch Nails). Je to však zajímavý materiál pro porovnání, protože oba filmy zpracovávají stejný příběh a přitom vznikly krátce po sobě (2009 a 2011).

Přes ImagePlot jsem zanesl záběry z filmů na graf ukazující závislost mezi časem a průměrnou světlostí snímku. Pro získání dat o záběrech jsem sáhl do výstupů ze Shotdetectu a pomocí skriptu si je převedl na tabulku. Výsledná data jsem přidal jako další sloupce do výsledku analýzy z ImageJ; tímto způsobem se potom dá se stopáží filmu pracovat jako s dalším parametrem pro ImagePlot.

Grafy záběrů z obou filmů; osa X představuje čas snímku ve filmu, osa Y jeho průměrnou hodnotu šedé („světlost“).

Švédská adaptace Män som hatar kvinnor (2009)

Americká adaptace The Girl With the Dragon Tattoo (2011)

Co z toho? Obligátně lze konstatovat, že americká adaptace je celkově ponurejší, možná i vizuálně méně kontrastní. Zdá se však, že co do celkové barevnosti jsou si oba filmy podobné; že by se zde projevovala severská bezútěšnost polární zimy?

Hustota informací je v této vizualizaci až tak vysoká, že celek není dobře čitelný. Namísto jednotlivých střihů by stačilo snímky z filmu sesbírat s konstantním odstupem času, třeba každé 3 sekundy. Tím by se eliminovaly „clustery“ střihů a graf by se zpřehlednil. Případně by reálné obrázky z filmů mohly zastoupit barevné body v dominantní barvě záběru (nepodařilo se mi však zjistit, jak k tomu ImagePlot donutit).

Pokud chci analyzovat pouze barevné složení a vyváženost, je pro mě časová informace zanedbatelná. Zajímavě vyšel graf porovnávající průměrnou světlost a směrodatnou odchylku (standard deviation).

Grafy záběrů ze švédské (první obr.) a americké adaptace (druhý obr.); osa X je průměrná hodnota šedé, osa Y je směrodatná odchylka šedé barvy.

Zde rozdíl mezi světelnou (ne)vyvážeností obou filmů bije do očí. Přitom však mají oba filmy jednu věc společnou: nejsvětlejší záběry tvoří detaily obrazovek či papírů. Málo scén se odehrává na denním světle a Fincher zřejmě více pracuje s barevným tónováním scén. Porovnání trochu zkresluje fakt, že řada snímků ve švédské adaptaci je jakoby zduplikovaných, zřejmě v důsledku častějších střihů či chybné automatické detekce záběrů.

Vizuální stopa

Postupnou redukcí informací se můžeme od zdrojového materiálu vzdálit natolik, až nám zůstane jen pouhý záblesk původního díla. Některé projekty se zabývají právě vytvářením takového „perceptuálního hashe,“ otisku, který film jednoznačně identifikuje. Ten může říct něco o obsahu filmu, ale současně třeba umožní jeho porovnání s dalšími díly.

Moviebarcode: Film jako čárový kód

Velice jednoduchý systém představuje moviebarcode. Snímky filmu se zredukují na jeden pixel široké proužky, čímž vznikne barevný „čárový kód.“ Ačkoli nenese mnoho informací o původním díle, jedná se o poměrně efektní a nenáročnou vizualizaci. K tomu existuje řada open-source implementací (já jsem použil tento skript – ano, má čínský manuál a ne, není v něm nic důležitého).

Moviebarcode pro švédskou (první obr.) a americkou (druhý obr.) adaptaci románu Muži, kteří nenávidí ženy.

Rozdílná světlost i barevná příbuznost obou filmů je zde už zcela zřejmá, ale to je asi tak vše, co se z tohoto kódu dá odvodit. V každém případě si budou žánrově bližší než třeba… Planeta Teror od Roberta Rodrigueze.

Moviebarcode pro film Planet Terror (2007)

Cinemetrics

Naopak o co nejkomplexnější pohled se pokusil Frederic Brodbeck v projektu Cinemetrics.¹ Jeho cílem je zachytit většinu aspektů filmu – kromě barev a střihů pracuje i s mírou pohybu, zvukovou stopou, rozdělením kapitol či sentimentem titulků. Část kódu pro sběr dat byla zveřejněna, byť bez dokumentace a s chybami; ty se mi podařilo opravit, takže jsem mohl provést analýzu.²

Samotný proces sběru dat je poměrně zdlouhavý; skládá se z minimálně deseti kroků a počítá s tím, že se data budou upravovat. Pro manuální výběr střihů se ze záběrů sestaví slitscan, kde se z každého snímku vezme proužek odpovídající jeho pořadí v průběhu záběru.

Slitscan záběru z The Girl With the Dragon Tattoo (2011). Záběr začíná pohybem kamery zleva, ale pravá část obrazu pak zůstává nehybná.

Já jsem však záběry po automatickém zpracování netřídil, nebylo to zapotřebí. Sběr dat už neřeší samotnou vizualizaci; výstupem může být plakát či interaktivní animace – k tomu autor vytvořil zajímavou aplikaci, kterou už však nezveřejnil. Tak jsem si jím navržený systém vizualizace implementoval s použitím knihovny D3.

Vizualizace pohybu a barev pro kapitoly obou adaptací románu Muži, kteří nenávidí ženy.

Män som hatar kvinnor (2009)

Pro zobrazení animace navštivte článek na původním webu.

The Girl With the Dragon Tattoo (2011)

Vizualizace se snaží zachytit barevnost jednotlivých kapitol filmu (výseče kruhu) a celkovou míru pohybu v záběrech (znázorněný soustředným pohybem výsečí). V případě americké verze filmu jsem ještě vyjmul úvodní titulky, které se od zbytku filmu výrazně liší.

Na první pohled se zdá, že švédská adaptace bude akčnější, avšak spíše se projevují nedostatky vizualizace v této formě; míra pohybu je spočítaná jako medián záběrů v celé kapitole, takže se ve výsledku akční záběry vykrátí s pomalými. Tempo americké verze je velice proměnlivé, proto pohled na celkovou kapitolu mnoho neodhalí. Zajímavější by bylo vizualizovat míru pohybu po záběrech, což je i myšlenkou Brodbeckovy původní implementace. To by však bylo celkově náročnější na zpracování dat i výsledné zobrazení.

Dalším nedostatkem této vizualizace je zobrazení barev: tím, že zůstávají staticky na místě, to budí dojem, jako by vnější a vnitřní barvy měly větší celkový podíl na záběrech. To není úmysl. Zadřel jsem si mozkové závity na středoškolské geometrii, ale problém se mi vyřešit nepodařilo. Každopádně kód vizualizace je k dispozici (zralý na celkový přepis).

Upřímně, očekával jsem o něco vizuálně atraktivnější výsledek, ale zjevně jsem si vybral špatný žánr. Inu, není to Planeta Teror…

Vizualizace pro Planet Terror (2007)

Vizuální otisk filmu vypadá jako esteticky zajímavá, leč neužitečná hračka. Nicméně představuje jednu z cest jak uvažovat nad multimediálním dílem ve snaze postihnout co nejvíce jeho aspektů. Pro zkoumání určitého žánru nebo filmografie konkrétního režiséra to může být užitečný nástroj.

Sen o robotickém divákovi

Strojová analýza filmů je podstatně tvrdší oříšek než analýza textu. Dat je mnohem více a užitečné informace se z nich získávají mnohem obtížněji. Své o tom ví i Netflix, který si pro svou absurdně podrobnou klasifikaci filmů najal armádu lidí, kteří filmy hodnotí v měřítkách jako je „míra romance“ či „morálka postav.“ Výsledek však představuje jen další vstup pro algoritmy strojového učení, které vám doporučí filmy v žánrech typu „Kontroverzní vězeňské satiry z 90. let.“ Nejspíše je pouze otázka času, než nás ve sledování filmů také nahradí dostatečně sofistikované programy…

Neplést s projektem Cinemetrics.lv, který se zabývá především manuálním sběrem dat o filmech. ↩
Zde bych rád poděkoval Tomáši Bartoňovi, který mě na tento projekt upozornil a současně vyřešil část problémů s kódem a dokumentací. ↩