Mikor elkezdtem a PhD-t, témavezetőm adott egy hatalmas füzetet és elmagyarázta, hogyan kell jegyzőkönyvet vezetni: minden nap új oldalt kezdeni, dátum a jobb felső sarokban, oldalszámozás a jobb alsóban és az előző munkafázis oldalszámát feltűntetni. Spirálfüzetet elfelejteni, mert abból csak kitépődnek a lapok.
A módszerrel a legnagyobb problémám a kereshetőség hiánya volt, a másik a limitált hely, amit kitölthetek. Legtöbb esetben elég volt egy oldal, de néha nagyon sokat kellett írni és ha volt még két-három gélkép (amit a megfelelő ragasztóval kellett beragasztani), akkor átlógtam a következő oldalra és borult a rendszer, vagy csak helyet pazaroltam.
Ezért kezdtem el számítógépes jegyzőkönyvet vezetni. Közönséges HTML oldalak voltak, a fenti logikát követték, oldalszámozás helyett linkekkel lehetett manőverezni. A formázási lehetőségek limitáltak voltak, eszközök alig akadtak (emlékszik még valaki a Dreamweaverre? Úgy értem, mikor még a Macromedia tulajdonában volt.).
Aztán ahogy átnyergeltem bioinformatikára, minden munkafolyamatot számítógéppel kezdtem végezni, és jött a LaTeX. A formázási problémák megoldódtak, a dokumentumok szép ábrákkal bővültek, de a kódok beillesztése rendszeres probléma volt. Ha csak simán beraktam, a LaTeX fordító értelmezni akarta. Ha nyers szövegként illesztettem be, túlnyúltak a sorok a lapszélen. Nehéz volt megosztani a munkarátsakkal, az e-mailes küldözgetés nem volt jó megoldás.
Később jött a Wikipedia/Confluence. Sokáig ez volt a legjobb módja a jegyzőkönyv készítésnek és bizonyos esetekben mind a mai napig. Könnyű formázni, könnyű megosztani. De nem védett a humán gyarlóságok ellen. Ugyanis nem vagyok egy jó jegyzőkönyv író. Ezt többször a fejemhez is vágták, mikor elhagytam az előző munkahelyemet. Miért nincs jegyzőkönyv arról, hogyan töltöttem fel a szekvenciákat az NCBI-ra? Miért nincsenek a szkriptek még jobban kommentelve? Hogyan csináltam ezt vagy azt? A probléma az, hogy ami számomra triviális, azt nem írtam le. Ha nagyon belemerültem a munkába és gyorsan követték egymást a lépések, a jegyzőkönyv és a valóság inkonzisztens állapotba került, ami csak később derült ki.
Milyen jó lenne egy olyan rendszer, ahol a munkavégzés egyben dokumentáció is lenne! A Bash saját history-ja végül is ilyen, de nem derül ki, mit miért csináltunk, ráadásul a fájlok kimenetét sem tartalmazza. A Screen-nek is van saját előzmény listája, ráadásul a kimenetet is képes tárolni a Ctrl + A és h billentyű kombinációval, ami igen viccesen néz ki egy less vagy vim kiadása után. Az R is tárol minden lépést, amit végrehajtottunk, tehát a hibás paraméterekkel végzett lépéseket, elgépeléseket, mindent. Ez sem tökéletes.
Jó volna egy olyan rendszer, ami egyesítené a Wikipédia formázási lehetőségeit az R/Bash előzménylistájával, de csak azokat a lépéseket tartalmazná, ami tényleg szükséges a munkához, nem a szerencsétlenkedéseket. Igen, van ilyen rendszer. Úgy hívják IPython.
A rendszert úgy kell elképzelni, mint egy Wikipédiát, amibe ha beleírjuk a parancsokat, azok a rendszer végrehajtja. A kimenetek is a dokumentumba kerülnek. A forráskódot is formázza, ami csak hab a tortán. Ez LaTeX alatt szinte lehetetlen lenne. De azért ez sem jelent mindenre megoldást. Először is csak Python alatt működik, én meg egy csomó programozási nyelvet használok. Illetve a napi munka során hármat: Bash-t, amiben a farmra küldöm ki a szekvencia feldolgozást. Azok kimenetéből Python szkriptekkel táblázatokat készítek, végül R-ben csinálom a végső elemzéseket.
A másik, sokkal nagyobb gond, hogy az IPython azon a gépen kell, hogy fusson, ahol végzem az elemzést. Ez legtöbbször egy távoli gép, amihez csak ssh kapcsolatom van. (Igen, lehet X-et alagutaztatni, de aki használt már IGV-t ilyen módon, az tudja, hogy ez minden, csak nem hatékony munkavégzés.)
Ugyan ez a probléma az RStudioval, knitr-el, csak épp R oldalon. De erre is van megoldás!
A Jupyter olyan, mint az IPython, de sokkal több nyelvet ismert. Igaz, egyszerre csak egyet lehet használni. Két részből áll. A kernel, ami a számítási feladatokat végzi. Ez lehet egy távoli gépen is, csak a megfelelő portok legyenek nyitva. A kliens pedig egy böngésző képes számítógépen fusson. Mindent a böngészőből irányíthatunk. A dokumentumunk különböző cellákra van osztva, alapvetően két típusuk van: leírás és kód. A leírásba szépen megfogalmazhatjuk, melyik lépést miért csináljuk, a kód pedig azonnal végrehajtja azt. Azonnal. Itt el is érkeztünk a rendszer egyik hátrányához.
Az egész az úgynevezett interaktív programozás keretében nyer értelmet. Tehát ha van egy lépés, ami három napig fut, akkor nem érdemes Jupyteren keresztül használni. A másik fontos dolog, hogy ez nem szoftver fejlesző környezet. A tesztelést és hibakeresést nem támogatja.
Maga a fájl egy JSON, ezért akár GitHub-on keresztül tárolhatjuk a verziókat. Ha elgépeltünk valamit, csak kijavítjuk azt és újra futtatjuk az adott cellát, nem az egész munkafolyamatot. Vizsgálatunkat exportálhatjuk HTML-be, PDF-be, de akár fel is tölthetjük egy szerverre, hogy megosszuk másokkal.
De a legjobb dologról még nem beszéltem. Ez egy olyan tulajdonság, amivel egyetlen hagyományos jegyzőkönyv sem rendelkezik. Mivel alapvetően böngészőben fut, lehetőség van interaktív elemeket beszúrni. A legjobb példa erre a plotty, Az ezzel elkészített grafikonok tetszőlegesen nagyíthatóak, mozgathatóak. A jegyzőkönyv olvasója kódolási ismeretek nélkül is tanulmányozhatja az eredményeket. Megszűnik a papír jelentette korlát és kód a dokumentációval tökéletes egységet alkot, megőrizve mindent örökké. Vagy legalábbis amíg van áram.
