Az élet kódjai

A felhalmozódó szemétről már rengetegen írtak. A halak beleúsznak az eldobott műanyag dobozokba, a fókák nyakkendőként viselik a műanyag fóliákat. Fujj, belegondolni is szörnyű!

Aztán ott vannak a levélszemetek. Tárolni kell őket, fogyasztják a sávszélességet és még az időnket is rabolják, még ha csak annyira is, amíg töröljük őket.

Mi a helyzet a tudományos hulladékokkal? Azon belül is a bioinformatikai szeméttel? Megkapjuk őket egy szépen csomagolt cikk formájában, ami hemzseg az ilyen szavaktól: egyedülálló, újszerű, kimagasló, páratlan. Az ember bekajálja a meredeken felfelé törő grafikonokat, a 99.9999 százalékos hatékonyságot és azonnal ki akarja próbálni. Aztán jönnek a törött linkek, lefordíthatatlan programok. Minek tekintsük az ilyen programot? És a hozzá tartozó cikket?

A hétköznapi szemetet legalább részben újra lehet hasznosítani. Ezeket a cikkeket mire lehet használni? Elrettentő példán kívül?

Felmerülhet a kérdés, mennyi szemét van? Egy kutatócsoport elmerült a szoftver-szemétben és átnéztek több, mint 24 ezer programot. A programok fele nem érhető el, mert régi az URL, vagy nem telepíthető. A cikk alapján, ha egy programot 2012 előtt készítették vagy nincs GitHub link, nyugodtan felejtsük el.

Szakdolgozókat és PhD hallgatókat bevonva kiválasztottak random 99 programot telepítésre. Két órát szánhattak egy programra. Ha ennyi idő alatt nem sikerült működésre bírni, akkor megkapta a használhatatlan plecsnit. A kiadott dokumentáció alapján a programok fele nem telepíthető, kell hozzá vagy valami függőséget telepíteni vagy belenyúlni a kódba.

De miért kell ennyi energiát beleölni egy program fejlesztésébe? Nem elég addig futnia, amíg a cikket el nem fogadják? Azért, mert nem meglepő módon azt vették észre a cikk szerzői, hogy a telepíthető programok több citációt kaptak.

Tehát, aki meg akarja írni a követkeő IGV-t, annak pár egyszerű szabályt kell alkalmaznia: a progit tegye fel a GitHubra (vagy más publikus helyre), mert az intézeti/egyetemi URL-k jönnek-mennek. Használjon minél kevesebb függőséget (könnyebben telepíthető). Próbáljon csatlakozni nagyobb szoftver depóhoz (pip, Bioconductor, cran, bioconda). Az sem árt, ha rendes dokumentációt készít és mellékel egy kis teszt adatot is, amivel azonnal ki lehet próbálni.

De a legfontosabb üzenet - és ezt nem említi a cikk - hogy a program nem készül el a pulikációval. Azután is van élete, hogy mi másik munkahelyen vagyunk, másik témán dolgozunk. Ha nem is adunk hozzá új funkciókat, csiszolgatni továbbra is kell. Legalább annyira, hogy mások is le tudják fordítani.

Úgy általában a kutatásról elmondható, hogy nem jellemzi egységes megoldási rendszer, még olyan alapvető problémákra sem, amire egy céges környezetben esetleg évek óta van bejáratott protokol. Ezért van az, hogy míg egy dolgozó egyik cégtől átmegy egy másikba, ismerős szoftverekkel, környezettel fog találkozni. (Vagy legalábbis hasonlóakkal.) Ellenben minden kutatólabor kialakítja a saját megoldásait minden élethelyzetre, amit ráerőltet tapasztalatlan szakdolgozókra, PhD hallgatókra és ezek alternatív ismeretek híján terjednek, mint a ragály.

Most összeszedek pár olyan rossz beidegződést, amivel az utóbbi időben találkoztam és mutatok példákat, hogyan lehet elkerülni (vagy kijavítani) azokat. A célom nem az, hogy a saját rossz beidegződéseimet terjesszem (mert ezek is biztos vannak), csupán az, hogy választási lehetőséget az olvasóknak.

Kísérletezés a programkóddal

Elég ritka, hogy valaki egyből leírja a tökéletesen működő szkriptet. Általában készítünk egy próba függvényt/rutint és megnézzük, működik-e. Általában nem működik, de ez részlet kérdés. Esetleg másik, hasonló problémára megpróbáljuk egy létező kódunkat használni, de egy kis módosítással.

Szimptómák

Megjelennek a .1 és .2 kiterjesztésű állományok. Esetleg orig, bak és egyéb szörnyűségek (a végső csapás, mikor már a dátumot kénytelenek beleírni). Furcsa függvények maradnak a kódban, amit semmi nem hív meg. Élettelen változók tömegei hevernek szerteszét. A legrosszabb példa, mivel jelenleg dolgozok itt van. Egyik fájlból több, mint 600 sort töröltem ki, funkcióvesztés nélkül! Döbbenet, amit ott találni!

Megoldás

Verzió követő rendszer. Mindegy, melyik, de ha publikálni akarjuk a kódot, akkor GitHub/GitLab/Bitbucket elkerülhetetlen (és miért ne akarnánk publikálni a kódot? A tudományban beszélnek valami reprodukálhatóságról, vagy miről.). Csinálhatunk millió verziót és nem kell félni, hogy bármi is elveszik. Alternatív lehetőségeket próbálhatunk ki anélkül, hogy veszélyeztetnénk kódunk struktúráját.

Kommunikáció

Tartani kell a kapcsolatot a csoport tagjai között, még akkor is, ha valaki konferenciára megy, otthonról dolgozik, átugrik-a-másik-laborba-de-öt-perc-múlva-itt-lesz-és-nem-láttuk-már-két-napja. Erre ugye ott van az intézeti/egyetemi email, ami legtöbbször funkcionalitásában elmarad a GMailtől.

Szimptómák

Elkezdik használni mindkét levelező rendszert és elszaporodnak az olyan jellegű levelek, hogy "ezt most a másikra küldtem", meg "küldd el még egyszer". De olyannal is találkoztam, hogy Facebookon ment minden közlés, mondván "úgyis azt nézi mindenki". Aztán két macskás videó és egy torta recept közé beékelődött egy genom szekvenálási eredmény.

Megoldás

Erre igazából nincs mindenre jó megoldás (vagy legalábbis még nem találkoztam vele). De az biztos, hogy a szabadidős és munkahelyi szolgáltatásokat el kell különíteni, mást nem, szeparált regisztrációval. A másik fontos, hogy egy csatornán menjen a kommunikáció! A JIRA, bár fizetős, mindent tud, ami egy projekt nyomon követéséhez kell. A Slack lebutított verziója ingyen is elérhető. De aki ingyen cuccot szeretne, installálhat fórum motort is saját szerverre.

Programnyelvek

A régi mondás, mely szerint minden programozási nyelven lehet BASIC programot írni, igaz. Elméletileg bármelyik Turing-teljes nyelven megoldhatóak a problémák, azért mégis érdemes olyan nyelvet használni, amivel kevesebb problémánk van.

Szimptómák

Túlbonyolított, Halálcsillag-jellegű programok, ahol a funkciók nagy része nem a problémát kezeli, hanem nyelvi hiányosságokat pótol. Példának okáért nézzük meg ezt. Egy Visual Basic program. A klikkelős alkalmazásoknak megvan a maga helye, de nem ott, ahol nagy mennyiségű adatot kell feldolgozni. A program diszkréten csipog, amikor készen van és az eredményt a vágólapra másolja. Ha elmúlasztjuk a csipogást? Nos, akkor gondolkodhatunk, hogy a vágólapon található eredmény a mostani, vagy a korábbi futásból származik. Nem véletlen, hogy a Galaxy sem egy elterjedt alkalmazás a bioinformatikában.

Sajnos néha a nyelv fejlesztői is hibásak, amikor olyan feladatok elvégzését is lehetővé teszik, amit nem kéne. Azért, mert R-ben lehet XML-t feldolgozni, még nem jelenti, hogy abban kell csinálni. Láttam ilyet. Szörnyű volt.

Megoldás

Több programozási nyelv ismerete. A leggyakoribb kifogás, hogy nincs rá idő. De több száz soros, érthetetlen vackot írni van? Nem kell profinak lenni benne, de addig érdemes eljutni, hogy megértsük a nyelv mögött rejlő filozófiát. Azután eldönthetjük, hogy ezt el akarjuk-e sajátítani.

Adat tárolás

A nagy áteresztő képességű eljárások (szekvenálás, microarray, mikroszkópia) iszonyú mennyiségű adatot adnak a kutatók kezébe. Ezek tárolása a kutatás szempontjából létfontosságú.

Szimptómák

Az adatok szanaszét vannak, több gépen, elszórt könyvtár szerkezetben. A kommunikációs csatornák ilyen párbeszédekkel vannak tele:
- Hol vannak a februári adatok?
- A 3-as gépen, a data mappában.
- Ott nincs data mappa.
- Ja, tényleg. Ott az adatok3-ban lesz.
- Mi van az adatok2-ben.
- Semmi.
A fájlnevek metainformációkkal vannak tele, mint például human_skincancer_youngAndOld_test. Természetesen egységes konvenció nélkül, mert szakdolgozók, PhD hallgatók jönnek-mennek.

Megoldás

Az adatok legyenek egy helyen, de rendelkezzenek biztonsági másolattal. Legjobb, ha van egy dedikált gép vagy NAS szerver. Személy szerint az USB-s tárolásnak nem vagyok híve, mert igaz, hogy könnyű cipelni, de elhagyni és leejteni is. A fájloknevek legyenek rövidek és minden egyéb információt róluk adatbázisban tárolni. Ezt most nehéz leírnom, de a fájlnevekbe kódolt metainformációknál még egy Excel táblázat is jobb.

Végszó

Természetesen ezeknek csak akkor van értelme, ha több ember is el akarja kerülni a fenti problémákat. Vannak, akik annyira hozzászoktak a rossz szokásokhoz, hogy nem tudnak nélkülük élni. Hiába mondják nekik, hogy húzzák fel a redőnyt, kint süt a nap, ők továbbra is dinamós zseblámpával közlekednek a lákásban. Az ilyen hozzáállás miatt könnyű ilyen cinikusan hozzáállni a problémákhoz, de amíg tehetjük, álljunk ellen.

Alapvetően az MTA Cloudon igényelhető gépek kicsik. Nekem például az otthoni, 6 (vagy 7?) éves gépemet egyik instance sem képes megszorongatni. Még az előző munkahelyi ócskavas is lealázza őket memóriában.

Na, de akkor mire lehet használni őket? A kérdés jogos, bemutatok pár felhasználási lehetőséget. Mert igaz, hogy teljesítményben nincsenek eleresztve, de helyi hálózatba köthetőek és kaphatnak egy publikus IP címet.

A másik potenciális probléma, az elérhető operációs rendszerek típusa. Az Ubuntu Cloud csomagkezelőjében ugyanis nem érhetőek el azok a programok, amelyek egy asztali környezetben megtalálhatóak. Bizony elég sok manuális telepítés szükséges. Én például túl későn vettem észre, hogy az elérhető R olyan régi, hogy a Bioconductor alig ment fel.

1. Jupyter szerver

Pont az előbb írtam, hogy kimagasló számítási teljesítményt ne várjunk, akkor mégis miért kéne Jupyter szervert üzemeltetni? Például azért, mert a szakdolgozók még az akadémiai szférában található gépeknél is silányabb masinákkal vannak felszerelve (vagy csak én voltam balszerencsés).

Arról se feledkezzünk meg, hogy nem mindenki tudja IKEA növényként elszámlázni a számítástechnikai beszerzéseket, és a semminél még ezek a gépek is jobbak.

A szervert viszont csak SSH alagutazással lehet használni, ami egy kis plusz munkát igényel a helyi gépen. Cserébe viszont kapunk egy bárhonnan elérhető szervert és valós időben ellenőrizhetjük a munka haladását. Nem kell elfelejtett e-mailekre hivatkozni. Lehet írni megjegyzéseket is, bár a kommunikáció ilyen formáját nem tartom előnyösnek, mert alig komolyabb egy mindenki által szerkeszthető Wordnél.

2. Web szerver

Néha előfordul, hogy szükség lenne egy webszolgáltatásra, de nem akarjuk "terhelni" az intézeti rendszergazdát. Esetleg teljesen felesleges tőle bármit kérni, mert nem tudja/akarja megcsinálni. Ilyenkor saját magunk hozhatunk létre nekünk megfelelő webes szolgáltatást. Készíthetünk saját Wikipédiát, Blast szervert, Galaxy-t, bármit. Még ha nem is akarunk éles szolgáltatásokat futtatni róla, fejlesztői szervernek is megteszi.

A többi instance egy lokális hálózaton kommunikál a publikus IP-vel rendelkező géppel, ezért nem muszáj minden szervert egy gépen futtatni. Az adatbázis motort külön gépre rakhatjuk, így növelve az össz teljesítményét.

Habár közönséges webszervert nem nehéz csinálni, Shiny alkalmazást nem tudtam telepíteni. Máig nem tudom, miért, de 80-as porton a Shiny szerver nem akart válaszolni, más portot megnyitva nem tudtam kapcsolódni hozzá kívülről. (Persze alagutazáson keresztül működött, ami arra enged következtetni, hogy van egy tűzfal a helyi hálózat és a nagyvilág között.)

3. Tárhely

Felesleges a DropBox 2Gb méretkorlátjával bajlódni. Nem muszáj előfizetni Amazon S3-ra sem. Az instance-okat használhatjuk biztonsági mentésekre, kutatási eredmény megosztására. Ha kívánjuk, Hadoopos HDFS-el több gép tárhelyét is összefűzhetjük. De ha csak közönséges FTP-t telepítünk, azzal is javíthatjuk adattároló kapacitásunkat.

4. Fejlesztés

Ha verzió követő rendszert telepítünk rájuk, akkor bárhol fejleszthetjük programjainkat, nem vagyunk multi cégek kényének-kedvének kitéve, mint GitHub/GitLab/BitBucket esetén. Használhatjuk nagyobb projektek integritás ellenőrzésére is, bár kizárt dolognak tartom, hogy a magyar tudományos életben bárki használna ilyesmit, de cáfoljatok meg.

5. Speciális programokra

Vannak elemzések, amelyek nem igényelnek nagy erőforrást, mégis sokáig futnak. Ha aggódunk, hogy a takarítók esetleg a partvissal kikapcsolják a gépet, közeleg a rettegett áramszünet, nyugodtan használjuk a távoli gépeket. Azt is elképzelhetőnek tartom, hogy egyes bioinformatikai programoknak speciális rendszerkövetelményei vannak, vagy egyszerűen csak régiek, mi mégis használni szeretnénk. Szóba jöhet a Docker, VirtualBox is, mint megoldás, de ha valami miatt nem jöhetnek szóba, akkor még mindig itt van az MTA Cloud.

Összegzés

Az MTA felhő szolgáltatás használata vért és verejtéket kíván, aki használni akarja bizonyára rengeteg nehézséggel fog találkozni. Én legalábbis elég sokkal találkoztam. De ingyen van és ennél gyorsabban nem lehet szert tenni egy gépparkra. Cserébe csak annyit kérnek, hogy említsük meg a publikációkban, hogy használtuk és írjunk egy rövid jelentést.

Remélem nem unjátok öntömjénező bejegyzéseimet, mert én nem. A következő poszt olvasásához a következő zenét ajánlom:

Eredetileg a fenti címmel akartam egy levelet küldeni a volt főnökömnek legújabb cikkemről. Történt annak idején, hogy sokadszorra kifogásoltam, miért nem DESeq2-t használunk differenciál expresszió számításhoz, amire az volt a válasz, hogy "nekünk még nem sikerült cikket publikálni DESeq-el". Ezzel a kijelentéssel nem tudtam mit kezdeni. Mintha egy orvos azt mondaná, hogy neki még nem volt sikeres műtéte kórházban, csak pajtákban, ahol a legjobb asszisztense egy tehén volt.

Szerencsére mások tudnak DESeq-el is publikálni.

A jelenlegi rákkutatás egyik érdekes kérdése, hogy hiába ismerünk egy csomó mutációt, ami rákos elváltozást okoz, ezek a mutációk nem minden tumorban fordulnak elő. Példának okáért a TP53 mutációk, amit egy igen erőteljes kiváltó oknak tartanak, csupán a tumorok felében fordul elő. Mi történik a tumorok másik felében? Ez kérem egy igen jó kérdés.

De itt még nem állunk meg! Ugyanis olyan mutációk, amelyek rákot okoznak, tömegével fordulhatnak elő teljesen egészséges emberek bőrén, anélkül, hogy bármilyen problémát okoznának.

Tehát egyik oldalon ott vannak a mutációk, amik rákot okoznak, a másik oldalon pedig a rákos mutációk, amikből soha nem lesz rák. Nincs itt valami ellentmondás? Ami azt illeti nincs, mivel az elő szövet egy dinamikus rendszer. A sejtek hatnak egymásra, kommunikálnak és bizony versenyeznek. Ugyan olyan evolúciós mechanizmusok játszódnak le, mint egy gimis bioszkönyvben, ahol a csigapopulációt egy hirtelen keletkezett hegy ketté vágja. Bár meg kell jegyezni, hogy a gimis bioszkönyvekben ennél meredekebb dolgok is előfordulhatnak, például szarvas és szarvatlan tehenek párosodása, de ez más kérdés.

A témához visszakanyarodva: az egészséges sejtek és a kezdődő tumor sejtek versenyeznek és néha a tumor bizony veszít. Persze ezeket mikroszkópikus méretekben kell érteni. Ha egy tumor már látható méreteket öltött, az azt jelenti, hogy az egészséges szövet vesztett.

Először a Nature Cellbe küldték be a cikket, ahonnan elég gyorsan visszadobták. Ezt követte a B-terv, de a főnök közölte, hogy abba az újságba sok bioinfó kell, mert azt szeretik. Ettől persze elkezdett habzani a szám, de végül mégsem én dolgoztam fel a mutációk azonosítását.

Az én részem csak az RNA-seq adatok feldolgozására korlátozódott, mégis jó volt látni, hogyan teszi hozzá mindenki a magáét. A mikroszkópos munka, amely követte a mutáns sejtek osztódását, a matematikai modellezők, akik megpróbálták egyenletekkel leírni a látottakat. Minden módszer más oldalról mutatta meg ugyan azt a jelenséget. Mennyivel erősebb az ilyen eredmény, mintha mindent egy nem paraméteres hipotézis tesztre alapozunk!

De a legjobb munkák mégis azok, amelyek további gondolatokat ébresztenek és más vizsgálatok alapjául szolgálnak. Még csak kézirat szintjén létezett ez, amikor már beküldték szekvenálni az ezen eredményekre épülő új mintákat. Abba a melóba csak belekezdtem, tehát nem biztos, hogy bevesznek a szerzők közé, de az még érdekesebb lesz a normál szövet vs tumor kompetícióban. Ott ugyanis felszeletelték a tumorokat. De ez már egy másik történet.

Az életemben mindig voltak olyan időszakok, amikor hosszabb-rövidebb időre kénytelen voltam abbahagyni a spotolást, de a viharfelhők elmúltával azonnal súlyzót szoktam ragadni. Így történt most is. Angliában nem sok időm volt konditermet látogatni, hazajövet pedig a három órás ingázás szívott ki minden erőt belőlem.

Ennek most vége. Újra itt vagyok, hogy bírkózzam a vasakkal. Lementem a konditerembe, hogy megnézzem, mi változott az elmúlt időben. Az első meglepetés az új emberek voltak. Pofátlanul fiatalok! Úgy köszönnek nekem, hogy "Tiszteletem" meg "Jó napot". Legalább nem Csókolom. Már ennek is örülni kell.

Alig találni bárkit a régi arcok közül. Illetve, ahogy szétnézek, én lettem a régi arc. Üdvözölnek is:

- Te, hol vannak az izmaid?
- Ahol a fiatalságom - válaszolom rezignáltan. Most valahogy jobban el tudnám viselni, ha hazudnának.

Mások sem kíméletesebbek:
- Csá! Milyen rég is gyúrsz?
- Húsz éve.
- Akkor miért nem látszik?
- Lehet, hogy nem látszik, de ha fejbe csaplak, érezni fogod - de nem mondom ki hangosan. Bármilyen hetvenkedésből én kerülnék ki vesztesen.

A vasak a régiek. Van pár új gép, a termet is átrendezték. De a rudak, súlyok még a régiek. Bár hiányolok pár kopott, CCCP feliratú tömör vastárcsát, amit egy régi konditerem szanálásakor mentett ki az akkori tulaj. Mindegy is, úgysem bírnám el őket.

Nem ez az első újrakezdés, ismerem a protokollt. Csak nyugodtan csinálni minden gyakorlatot. Kevés súllyal, nem kapkodni. Még akkor sem, ha mellettem a pattanásos gimisek kétszer annyi tárcsát pakolnak fel.

Minden nehéz, minden lassan megy. De hiába vagyok óvatos, másnap beköszönt egy másik kedves ismerős: izomláz. Marad is pár napra, pedig senki nem hívta. A végtagok kezdenek felébredni egy hosszú álomból és két hét múlva már nem fáradok el annyira. Már négynél több húzódzkodás is megy. Aztán kilépünk önmagunk árnyékából. De addig még sok munka van vissza.

Végezetül álljon itt egy kép annak bizonyítására, miért is szereti egy magam fajta barkácsoló ezt a konditermet:

Mi mindenre nem jó egy biztonsági öv, mi?

A hivatalos ügyek intézésénél egy rosszabb van: két országban intézni hivatalos ügyeket. A Sangerből való távozásom után kaptam egy levelet, amiben az angliai nyugdíj intézet tudatta velem, hogy nem dolgoztam három évet kint, ezért onnan nem vagyok jogosult nyugíjra. Természetesen ha máshol munkát vállalok az Egyesült Királyságban, akkor az eddigi megtakarításaim tovább gyarapodnak.

Alternatív lehetőségként áthozhatom a pénzt egy magyarországi önkéntes magánnyugdíj pénztárba. Jó, tegyük azt - gondoltam. Ki kell tölteni egy papírt az adataimmal, csatolni kell a HMRC által kiállított papírt, amiben elismerik, hogy az tényleg nyugdíj intézet, nem holmi balkáni pénzmosoda. Csatolni kellett egy papírt, amit az adott pénzintézet állít ki, hogy tényleg a tag vagyok, nyilatkozatokat, eredeti anyakönyvi kivonatot (vagy útlevelet) és még kitudja mennyi vackot.

Nekiláttam összeszedni a dokumentumokat. Írtam a magyar pénzintézetnek, hogy adják oda a HMRC által kiállított papírt. Eltelt egy hét, eltelt még egy hét. Először nem értették, mit akarok. Kaptam egy sablon választ. Még egyszer leírtam neki, mire van szükségem, közben írtam, hogy ez sok pénz és nagyon szeretném, ha náluk lenne. Gondoltam ez majd motiválja őket. Még két hét eltelt, majd írták, hogy ők nem felelnek meg ugyan az angol normáknak, de igazából egyetlen hazai magánnyugdíj intézet sem, szóval intézzem csak azt az átutalást.

Nos, ez így ebben a formában nem volt igaz, mert a HMRC weboldalán akkor még fel volt tűntetve két olyan intézmény is, akik megfeleltek. Ráadásul, ha nem mellékelek minden iratot, amit kérnek, nem lesz átutalás, ebben biztos voltam.

Úgyhogy megköszöntem a segítséget és pénztárt váltottam. Ez hihetetlen egyszerű volt, egy hét alatt meg is volt. Közben az idő is szorított, mert az angolok azt írták, hogy a papírjukban közölt átutalási díj csak egy bizonyos naptári napig jó.

Nem is volt meg minden papír, amit kértek, de azért ami volt, azt elpostáztam. Gondoltam a hiánypótlással ki tudom tolni a határidőt. Útlevelemet adtam fel, mert annyira nem őrültem meg, hogy az eredeti születési anyakönyvi kivonatot póstázzam el. Szépen vissza is küldték két hét múlva. (Ez egyébként teljesen általános ügyintézési módszer Angliában.)

Azután újabb levelet kaptam, hogy fizessem be az átutalási díjat. Az átutaláshoz kellett volna az angol telefonom, és hiába volt még rajta pénz, nem tudott se SMS-t küldeni, sem fogadni. Akkor azokkal leveleztem hetekig. Kiderült, inaktiválták a készüléket, mert nem volt rajta forgalom.

Végül sikerült életet lehelni a telefonba, elintéztem az átutalást, majd vártam, hogy átutazzon a tengeren öreg korom jól megérdemelt megtakarítása. Persze nem jött, mert kicsúsztam az időből. Az angolok elküldték újra az összes dokumentumot, hogy ismét töltsem ki az egész paksamétát. Nem értettem. Talán megváltozott a születésem ideje? Mindegy. Ismét kitöltöttem mindent, ismét elküldtem. Eltelt egy csomó idő. Már nem is számoltam mennyi.

Ismét válaszoltak. Két lapot rosszult töltöttem ki, mert azokat nem nekem kellett volna kitölteni, hanem a magyar nyugdíj pénztárnak. A másik kifogás, hogy amin a pénzintézet bankszámla száma szerepel, magyar szöveg van. Nem értem, hogy az "IBAN:" részt miért nem értették, de ezen a ponton már nem lepődtem meg semmin.

De már éreztem a vereség előszelét. Vigyek be egy angol papírt egy magyar cégnek, hogy írják alá? Biztos voltam benne, hogy hivatalos fordítást kérnek róla, megnézetik jogászokkal és még utána is cidriznek, hogy tényleg aláírhatják-e: A kisvezetők azért, mert nincs elég hatalmuk egy ilyen döntéshez, a nagyvezetők azért, mert nem foglalkoznak ilyen jelentéktelen dologgal.

Valószínűleg nem jártam messze a valóságtól, mert nem kaptam semmi választ. Már az angolok nekem írtak, hogy tényleg akarom-e ezt az átutalást, mert a magyarok nem válaszolnak nekik sem. Ekkor kicsit bekeményítettem. Írtam a pénztárnak, hogy vagy írják alá a papírt, vagy mondják meg, ha nem akarják aláírni. Utóbbi esetben keresek egy másik nyugdíjbiztosítót, akik nem akadékoskodnak ennyit.

Ekkor elküldték az összes papírt. Még azokat is, amelyeket korábban nem akartak odaadni és írtak valami ostoba levelet, hogy nem jöhetek át az angol biztosítótól a magyarba, csak átutalást kezdeményezhetek. Én meg voltam győződve róla, hogy egész végig ezt akartam elintézni, de másoknak ezek szerint nem volt ennyire tiszta. Mindegy, nem számít. Megvan minden, amit az angolok kértek. Még a bank adatai is angolul, a pénzintézet fejlécével. Összecsomagoltam mindent és elküldtem nekik.

Aztán jött egy levél, hogy igaz, hogy csatoltam egy levelet, amit a HMRC állított ki, de a HMRC listáján már nincs rajta a pénztár. Korábban mindig kinyomtattam a listát a weboldalról és elküldtem nekik. Most mi történt? Meghülyültek? Megnéztem én is a weboldalt. A szeptember 1 után frissített listán már egyetlen magyar pénzintézet sem szerepelt. Persze továbbra is átutalják, ha nagyon akarom, de annyi adót kell utána befizetnek, hogy nem marad semmi a pénzből.

Sakk-matt. Ha nem csináltam volna semmit, most pontosan ugyan itt tartanék.

Ismét hosszú várakozás előzte meg ennek a cikknek a megjelenését. Az egész úgy kezdődött, hogy még a Sangerben megkértek, hogy egy PhD hallgatónak segítsek az RNA-seq feldolgozásban. Természetesen a csoportomnak nyújtott támogatás mellett, amolyan extra munkaként. Mivel volt még szabad kapacitásom, belementem.

A hallgató az Egyesült Államokból érkezett, túl volt az orvos képzésen. Rendkívül szerény volt. Az első differenciál expressziós vizsgálatokat én csináltam, majd ő a minden lépést megismételt. R-ben dolgoztunk, még csak akkor ismerkedett a nyelvvel, minden féle programozói előképzettség nélkül, de a kódjai szépek és áttekinthetőek voltak.

RStudióban írt mindent, Markdown-al. Én úgy érzem, jegyzőkönyvként soha nem lehet elég szöveget írni (amire természetesen mindig utólag jövünk rá), de azt hiszem ő elég közel volt hozzá, hogy rácáfoljon erre. Mondta, hogy nagyon fél, hogy a vizsgálat végére nem fog emlékezni a kezdeti lépésekre.

Annyira felfejlődött R-ben, hogy még Patrick-ot is képes volt elcsábítani az Exceltől, ami igen csak nagy szó. Patrick ugyanis mindent Excelben csinált, még azt is, amit lehetetlen Excelben megcsinálni. Egy anekdota szerint rajzolt egy fehérje-fehérje interakciós térképet az említett programban. Egész éjjel fent volt és egérrel húzogatott minden egyes csomópontot, hogy egyenlő távolságra legyenek egymástól. (Kb. 2 perc lett volna Cytoscape-el).

Az előzetes ábrák, amiket készített, már cikk minőségűek voltak. Ehhez mondjuk a szerencsés téma is hozzájárult. Legtöbbször kell egy kicsit játszani az ábrákkal, hogy amit be szeretnénk mutatni, az kellően egyértelmű legyen. Itt nem volt rá szükség. Kérdeztem tőle, hogy alkamazott-e bármilyen skálázást, de nemmel felelt.

Később is gyakra visszajött és kérte, hogy nézzem át a kódot, mit írt, nem találok-e valami furcsát, de soha semmi probléma nem volt velük. Sőt, ahogy egyre jobban haladt a PhD-s bioinformatika kurzusokkal, a vége felé én tanultam a kódjából és nekem kellett kérdezgetni, hogy az egyes részeknek mi a feladata. Ő készségesen megmutatott mindent, nem éreztette velem, hogy egy hülye vagyok.

Mert az az igazság, hogy elég hamar túllépett rajtam. A cikk több szekvenálási technikát is felhasznált, amit különböző emberek vizsgáltak, de ő igyekezett mindegyik módszerben elég kompetenciát összeszedni, hogy átlássa a teljes vizsgálatot.

Fantasztikus dolgozni ilyen emberekkel, még akkor is, ha közben csúszó-mászónak érezzük magunkat mellettük. Csak annyit mondhatok, örülnék, ha ilyen lányom lenne.

Beteg vagyok. Krónikus Function megvonásban szenvedek. 2015 óta csak weben követem az eseményeket. Ezért is tetszett, hogy az idei tematika arról szólt, hogy a party részvétel egyfajta kúra. Az nem teljesen tiszta, hogy mi ellen, de mindezt saját magamra vetítve egyértelmű: hiánypótlás.

Az teljesen világos volt, hogy valamit vinni kell. Először wildot akartam, valami teljesen szoktalan platformra, de azzal nem úgy haladtam, ahogy terveztem, ezért jött a B-terv: film. Volt néhány elfekvőben lévő time-lapse videóm, azokat gyúrtam egybe, közös koncepcióba helyezve őket. Majd meglátjuk, mire jutunk.

Az entryk feltöltése után Spenóttal vitattam meg az 1K-k világát. Nagyon örültem, hogy végre aktivizálta magát. Ebben az évben - ha jól emlékszem - három partyra is adott be intrót. Megmutatta őket, volt néhány igen jó. Azt mondta, már nem tud úgy elmenni partyra, hogy ne adna be valamit. Azt hiszem ráérzett a lényegre.

A kivetítőn Unreal harcol a telep töltöttséggel. Rajzol, de a laptopja nincs hálózati áramforrásra dugva. Kíváncsi vagyok mi fog előbb bekövetkezni: befejezi a rajzot, vagy lemerül a gép. A slussz poén, hogy két képet rajzol egyszerre, mint azok a szimultán sakk bajnokok, akiknek egy meccs már unalmas. Unreal győzött, még maradt pár csepp elektron az akkuban.

Első előadás egy Amigás játék bemutatója volt, a Legacy-é. Egy fantazy-szerepjáték, amit egy régi PDA-s játékból portoltak. Jó dolog látni, hogy aktívan foglalkoznak Amigával és nem csak beszélnek róla.

A zene kompó az elején jól indult, jobb és közepes zenékkel, majd vagy én fáradtam el, vagy tényleg a színvonal zuhant, de egyre fájdalmasabb volt hallgatni. A Giants például egymaga egy kompó volt, mert egyes részei, mintha 8 bitesek lettek volna, majd minden átmenet nélkül váltott valami teljesen másba. Két szám múlva felnézek a vászonra, még mindig a Giants megy. Kérem, kapcsolják már ki! Szerencsére a végére ismét javult a hallgathatóság, bár élek a gyanúperrel, hogy a hangosítás egy kicsit torzított.

Ezután jött a Kolmogorov Toolbox nevű formáció, ami igazi kocka-nyálcsorgató volt. Egy lány meg egy fiú ült két laptop előtt és amit kódoltak, az rögtön hallgató volt. Még egy igazi bug is ízesítette az előadást, amikor is egy elírás következtében recsegett a hangszóró. Feltételezem egy kliens-szerver architectura volt, mert a két művész gépelése valós időben, egyszerre volt látható.

 Közben pedig palancsinta kezelés Korgógyomritisz ellen.

A fotók szokás szerint széles sávot öleltek fel, mind mennyiségben, mind minőségben. Az én fotóm sem tűnt vállalhatatlannak a mezőnyben. A grafikák viszont nagyon jók voltak. A kézi rajzok kifejezetten kellemesek. Jó volt látni ennyi különböző gépre készült képeket egyben.

Az elmaradhatatlan DJ fellépés előtt rutinosan kimenekültem. Ahogy kint álldogáltam a kellemesen hűvös sötétben, feltűnt, hogy az épület nem akar szétesni a nagy hangzavarban. Óvatosan visszamerészkedtem, visszaültem a helyemre, és megállapítottam, hogy ezt a hangszintet elviselem. Ez is nagy pozitívum volt, úgyhogy kódoltam egy kicsit a zene hallgatása közben.

Végül jöttem a kompók sorban. Wildra rajtam kívül hárman adtak be prodot, ebből az egyik Maugli kétségbeesett harca volt. Egyik oldalon az agy, másik oldalon valami alkohol. Abban biztos voltam, hogy ennél jobb leszek. A másik oldalon egy Raspberry Pi hajtotta ledkocka volt, ami tuti nyertesnek tűnt, ezért csak az volt a kérdés számomra, hogy második vagy harmadik leszek-e?

A 256byteok eszméletlenül durvák voltak. Nem is tudtam, hogyan szavazzak rájuk. Az elején volt három kimagasló, de a végére még jobbak jöttek. Mit csináljak? Pontozzam le azt, ami az elején jónak tűnt? Végül mindenkinek 5-t adtam. Megérdemelték.

A demók is jók voltak. Archee a tavalyi lovat ülte meg, két daruskocsi győzött le különböző akadályokat, Gargaj pedig egy impresszionista demót készített, középpontban a magánnyal. Elég depressziós, de pozitív értelemben. Nem tudtam szabadulni a gondolattól, hogy valami személyes tapasztalás áll a háttérben. Slyspy gyárában a Rainbow Clash futószalagról újabb termék gördült le, immár cimke nélkül.

A Tesco Gazdaságos Demócsapatra viszont komolyan oda kell figyelni! Úgy készítenek vicces produkciókat, hogy közben nem igénytelen, amit kiadnak.

Az eredményhírdetés igazi meglepetést tartogatott: A fotóm harmadik lett. A videó második. Jó party volt.

Új stratégiát eszeltem ki a csapat motiválására. Eddig előadtam az ötleteimet, majd mindenki dolgozni kezdett, majd jöttek a különböző csúszások és végül összecsaptuk az egészet. Egy-két kivételtől eltekintve mindig ez volt. Az új módszer viszont az lenne, hogy elkészítem az egész demót, random zenével, saját gyártású modellekkel. Ebből mindenkinek lesz egy benyomása, mit is akarunk csinálni. Később, ahogy a mindenki hozzáteszi a saját részét a munkához, úgy fog átalakulni és a demó, és nyeri el végső formáját. Nem lesz "várunk a kóderre" effektus, minden szép lesz és jó és nyerjük a versenyeket sorba és a Pixar állást ajánl és...

Ahogy Móricka elképzeli.

El is kezdtem készíteni a vázat egy érdekes wildhoz. Közben ismét összefutottam Grassal és egy baráti csevej keretében megtudakoltam, van-e kedve továbbra is demókat készíteni. Sajnos nem volt.

A legrosszabbtól tartva írtam Betasectornak is, aki megerősített gyanúmban. Neki sincs kedve alkotni. Shament meg sem mertem kérdezni, bár neki a zene az élete, és elkészült műveit eddig is használhattuk nyugodtan.

A lényeg, hogy egyedül maradtam.

Alapvetően három stratégia maradt: új embereket keresni, egyedül csinálni mindent (netről levadászott tartalmakkal dolgozni), feladni.

Feladni még nem fogom, bár nem tesz jót a motivációnak, hogy kódban nem vagyok olyan erős, mint mások, szépérzékem nulla, zenélni meg nem tudok.

Ez a probléma az új társakkal is. Ki akarna olyan csapatba kerülni, ami vesztésre ítélt?

Ha egyedül folytatom, akkor két módja van, hogy ne végezzek teljesen az utolsó helyen: vicces produkciókat készíteni, vagy nagyon elvontat. Egyik sem áll olyan messze tőlem, bár a vicces produkciók utolsók szoktak

De talán a legfontosabb, hogy azt érezzem, jó móka demókat készíteni. Mert a demó készítés igazából a legnagyobb szabadság, amit számítógéppel végezni lehet. Ha szoftver fejlesztőként dolgozik valaki, annyi ember áll felette, akik megmondják, milyen technológiával, milyen programozási nyelven, mit kell csinálni. Egy demónál nincs kód review, üzleti döntés, vagy bármi más, ami gátol a kiteljesedésben. Mindent én határozhatok el. Bármi, ami visszatart, én magam vagyok.

Kár lenne ezt a szabadságot eldobni olyan indokokkal, mint időhiány. Magamból kiindulva rengeteg időrabló tevékenységet végzek (például blogot írok kb. tíz embernek, akik közül talán egy szokta elolvasni a demoscene tartalmú bejegyzéseket, legalábbis az oldal korlátozott statisztikája szerint).

Mindegy, még itt vagyok, még alkotok, csak lassabb ütemben.

Igazából több okom is van a teszt megvetésére. Először is, jelenleg mindenre ezt kell használnom, ha kell, ha nem. Hiába vannak jobb módszerek például a differenciál expresszió meghatározására, csakis Wilcoxon-tesztet lehet rá használni.

Első ránézésre semmi gond nincs a próbával, hiszen nem paraméteres, tehát nem kell azzal foglalkozni, hogy normál eloszlású populációból származó mintákra alkalmazzuk. De tényleg csak ennyi az egész? A több száz oldalt megtöltő statisztikai könyveket dobjuk ki, és redukáljuk a tudásunkat egyetlen tesztre?

Természetesen nem, és ez a teszt első nagy hibája. Olyan, mint az Excel. Azt sugalmazza, hogy nem kell érteni semmihez, csak használni. Lustává teszi az embert, dilettánssá, aki végül akkor sem távolodik el a jól ismert módszertől, amikor semmi nem indokolja a használatát. Pedig ennek a tesztnek is van feltétele, amit nagyvonalúan el szoktak felejteni, de erről majd később.

A második hiba, hogy igazából nincs is Wilcoxon-teszt. A név szintén a lustaság eredménye, amikor használói arra sem veszik a fáradságot, hogy rendesen megnevezzék a tesztet, majd szerencsétlen bioinformatikusok (természetesen nem rólam van szó, én egy rózsaszín felhőn élek a szivárványon túl) olyan leveleket kapnak, hogy "Wilcoxon teszt helyett használj Mann-Whitney-t".

Szóval van a Wilcoxon-féle rangösszeg teszt (amit Mann-Whitney-próbának is neveznek, angolul pedig a Wilcoxon rank-sum test) és a páros Wilcoxon-próba (angolul Wilcoxon-signed rank test). A hanyagságot erősíti, hogy R-ben a két teszthez ugyan azt a függvényt kell használni: wilcox.test(). A különbség a paired opció használatával érhető el. Ha értéke igaz, a második módszer alapján számol.

De mit is számol igazából? Mi az, ami miatt óvakodni kell a használatától? Először is, a teszt a számok növekvő sorrendbe rendezett sorszámával dolgozik. Ha tehát van három számunk (23,3; 44,3; 65,1), abból csak 1, 2, 3 lesz. Elveszítünk minden eloszlással kapcsolatos információt. Ez ordinális adatoknál nem nagy probléma, de folytonosak esetén igen.

Tehát, ha valaki használni akarja ezt a tesztet, előtte alaposan gondolja át, mit is akar, mielőtt gondolkodás nélkül alkalmazza azt.

A döntési fák alapötletét egy viccel lehet szemléltetni:

Az öreg székely a vacsora asztalnál ül a feleségével és a fiával. Egyszer csak egy hatalmas szellentés hallatszik. Az öreg megkérdezi:
- Asszony, te voltál?
- Nem.
- Fiam, te voltál?
- Nem.
- Akkor én - vonja meg a vállát az öreg.

Vagyis a döntési fák egy sor bináris feltétel összessége. Első sorban osztályozásra használják, ahol a feltételek (és ezáltal a döntések) végén egy kategória található. A való életben, anélkül hogy tudatában lennénk, számtalan helyen alkalmazzuk: ehető gombák meghatározásánál, annak eldöntésére, hogy át fogunk-e menni a vizsgán (ha ez a tanár vizsgáztat, bármennyit is tudok, nem fogok átmenni), fog-e esni az eső (párás a levegő, sötét felhők vannak az égen, stb). De a barchópa nevű játék lényege is a helyes döntési fa felállítása.

A fenti példákból is látszik, egy döntés csak bizonyos eséllyel jósolja meg a választ. Minél több döntésünk van, annál pontosabb lesz a válasz. Természetesen ha a rendelkezésre álló adatok nem elég pontosak, nem terjednek ki mindenre, akkor a döntések számának növelése nem fog pontosabb választ adni. Tipikusan ez a helyzet, ha bi- vagy multimodális eloszlású adat alapján akarunk osztályozni.

Hogy mindez érthetőbb legyen, vegyük azt a példát, amikor a testmagasság alapján akarjuk eldönteni egy emberről, hogy férfi vagy nő. A férfiak általában magasabbak, de egy női magasugró besorolása már nehezebb.

Épp ezért léteznek különböző mérőszámok, amelyek megmutatják, hogy az adott döntési ág mennyire pontos. Ilyen például a Gini tisztasági szám (Gini impurity). Azt adja meg, hogy az adott döntési ágat figyelembe véve egy véletlenszerűen kiválasztott elem, milyen eséllyel kerül rossz kategóriába. Minél kisebb, annál jobb.

Nézzünk egy példát! Tegyük fel, a tüdő adenokarcinómát és sejtes karcinómát akarunk elkülöníteni génexpresszió alapján. Meg akarjuk tudni, mennyi gén alapján lehet eldönteni, hogy milyen típusú betegségben szenved valaki. A döntési fa elkészítéséhez a scikit-learn Python csomagot fogjuk használni.

Először is töltsük le a TCGA-LUAD és TCGA-LUSC adatokat a innen. Csak a már normalizált expresszióra lesz szükségünk. Ezek az adatok regisztráció nélkül is elérhetőek. Készítsünk két könyvtárat az egyes rák típusoknak és mentsük a fájlokat oda. Példaként itt az egyik képernyőkép, amit látni kell, ha mindent jól állítottunk be.

Ezután készítünk egy mátrixot, ahol a sorok a páciensek lesznek, az oszlopok a gének. Kis túlzással minden fájl egy páciensnek felel meg (valójában egy páciensből több adat is lehet, de most ezzel nem foglalkozunk), a fájlokban a gének ugyan olyan sorrendben vannak, ami megkönnyíti a feldolgozást.

def getMatrix(root):
  files = glob.glob(root + "/*/*.gz")
  matrix = list()
  for i in files:
    expfile = gzip.open(i)
    matrix.append([])
    for lines in expfile:
      expression = lines.decode("utf-8").rstrip().split()[1]
      matrix[-1].append(float(expression))
    expfile.close()
  return matrix

Ha a letöltést a gdc-client programmal végezzük, akkor az mindegyik páciensnek létrehoz egy alkönyvtárat, azért szerepel /*/*.gz a glob paramétereként. Hozzuk létre az adat mátrixot.

luadmatrix = getMatrix("luad")
luscmatrix = getMatrix("lusc")
data = luadmatrix + luscmatrix

Szükségünk lesz még egy listára, ami a jelöléseket tartalmazza, hogy a mátrix adott sora melyik betegségtípusba tartozik.

category = ['luad'] * len(luadmatrix) + ['lusc'] * len(luscmatrix)

Szükségünk van még a gének neveire. Jelen esetben ez csak EnsEMBL azonosítókra korlátozódik, de legalább nem fenyeget az a veszély, hogy kedvenc génünket nézegetjük. Mivel mindegyik fájlban ugyan olyan sorrendben vannak a gén azonosítók, ezért választunk egy tetszőleges fájlt és kiszedjük az azonosítókat belőle.

genenames = list()
expfile = gzip.open("lusc/5dd30ba1-2051-42f6-8fb4-3c49c93b8bf1/6976923e-a954-4ba0-9d1d-f97d7373ba48.FPKM.txt.gz")
for lines in expfile:
  gname = lines.decode("utf-8").split()[0]
  genenames.append(gname)
expfile.close()

Nagyszerű! Nincs más hátra, mint betanítani a döntési fánkat. Egy igazi adat elemző munkánál persze ellenőrizzük az adatokat, átrendezzük őket, tisztítjuk. Ha prediktív modellt akarunk építeni (jósolni akarunk valamit), akkor az adatokat szétválogatjuk tanuló és teszt adatszettre, paramétereket állítgatunk, stb. De ennek a posztnak most nem az a lényege, csak egy gyors bemutatás, ezért a teljes adatszettet felhasználjuk a tanításra.

from sklearn import tree
dectree = tree.DecisionTreeClassifier(max_depth = 5)
dectree = dectree.fit(data, category)

Viszonylag gyors, nem? Nézzük meg, mit kaptunk.

import graphviz
dot = tree.export_graphviz(dectree, out_file=None, feature_names=genenames, class_names=['luad', 'lusc'], rounded=True, filled=True)
graph = graphviz.Source(dot, format='png')
graph.render("output1")

Ez már valami. Nézzük meg a fát kicsit közelebbről. Példának okáért vegyük a ENSG00000186081.10 és ENSG00000236699.7 géneket. A döntési fa szerint ha az első gén expressziója nagyobb, mint 14.678 és a másodiké kisebb vagy egyenlő, mint 1.568, akkor 30 LUAD és 468 LUSC mintát kapunk, és az algoritmusunk a LUSC kategóriába sorolja ezeket. Tehát ezen a szinten 30 minta rosszul van kategorizálva, amit a Gini tisztasáigi szám is megerősít (0.113). Amint lejjebb megyünk a fán, egyre jobb értékeket kapunk, de a mintaelem szám is csökken. Néha még 4 mintát is tovább akar bontani az algoritmus, ami remek példája a túltanításnak.

A döntési fák ugyanis hajlamosak a túltanulásra, ami azt jelenti, hogy ezen az adatszetten nagyon szép eredményeket kaptunk, de ha ráeresztenénk egy független adathalmazra, borzalmas hatékonysággal osztályozna.

A másik dolog, amit érdemes észben tartani, hogy ha az adatok transzformáción esnek át, az egész döntési fa használhatatlan lesz. Nagyon érzékeny az adatokra, amit a következő demonstrációval érzékeltetek. Távolítsuk el azokat a mintákat, ahol az átlagos expresszió 5 alatt van. Ilyen szűrést előszeretettel csinálnak expressziós adatok elemzésénél.

subsetdata = list()
subsetcateg = list()
for i in range(len(data)):
   average = sum(data[i]) / float(len(data[i]))
   if average > 5.0:
     subsetdata.append(data[i])
     subsetcateg.append(category[i])

dectree2 = tree.DecisionTreeClassifier(max_depth = 5)
dectree2 = dectree.fit(subsetdata, subsetcateg)
dot = tree.export_graphviz(dectree2, out_file=None, feature_names=genenames, class_names=['luad', 'lusc'], rounded=True, filled=True)
graph = graphviz.Source(dot, format='png')
graph.render("output2")

A fa teljesen más! Még a legfelső szinten is. Éppen ezért önmagában egy döntési fát ritkán használnak bármire is. Több fa viszont képes arra, amire egy nem. Ezért egy későbbi posztban a random erdőkkel fogunk megismerkedni. A Jupyter notebook itt található.

Felhasznált források:

Hands-On Machine Learning with Scikit-Learn and TensorFlow

http://scikit-learn.org/stable/modules/tree.html

Photo

Az idei képek nem annyira a művészi kompozícióról szóltak, mint inkább az ügyes technikai megoldásokról. Sok esetben a képek mellé adott fázisok segítettek értelmezni, mit is látok. Így akadtam a legszokatlanabb műhelyre is, amiben az It spawns című kép is készült. Eheti feladványunk: hány hobbija van a szóban forgó scenernek?

De nem ezért vagyunk itt. A Gateway to Assembly 2049 igen ötletes és jó kép. De miért pont 2049? Talán majd ott kiderül.

Fast graphics

A képek megtekintése után úgy tűnt az X volt a központi motívum. Talán némi nosztalgikus hangulat hatására az I have your files tetszett a legjobban.

Pixel graphics

Őszintén szólva, nem értem, milyen kategória ez. Elvégre minden digitális kép valamilyen szinten pixel. Régi platformokon persze a limitált lehetőségek miatt érdekes ez a technika, de PC-ken? A szabályok nem sokat írtak, ezért kicsit gondban voltam, miként is értelmezzem ezt a kategóriát. Gondolom mások is, ezért volt csak 4 induló. A győztes kép is kézi rajzként kezdte a fázisok megtekintése alapján.

Graphics

Itt már nem volt gond a kategóriával. Ismerős terep volt a résztvevőknek is, amit a 13 induló is mutat. A felhasznált technikai tudás erős korrelációt mutat a helyezéssel, vagyis a győztes képek nagyon gondosan voltak elkészítve, nem pedig művészileg voltak kimagaslóak. Ez persze nem baj, de szívesen láttam volna olyan képeket is, amelyek túlmutatnak önmagukon. Ezért is szúrom be a második helyezett Party Animalt.

Game

A játékokat többnyire hanyagolom, de most úgy döntöttem, kipróbálom őket. A Clay egy fanatsy szerepjáték, sok-sok hibával (a főhős például -8437 életponttal vígan hadakozott az óriás pókok ellen), de nem untam túlságosan. A biztonságos közlekedés oktatására ott van a City Bike Simulator, ahol kocsik között kell átmanőverezni. A PlanetA18 igazi különlegesség volt, mert nem Unityvel vagy Unreal-el készült és egész sokáig el tudtam vele szórakozni.

Dance music

A legjobban a kimondhatatlan (és szinte leírhatatlan) Saat mun tuulettimet huutamaan tetszett. Ha valaki büntetést akar rám kiszabni, ezt fogja leíratni velem ezerszer. Igazából a többi zenével sem volt különösebb bajom.

1k intro

A JavaScriptesek nagyon elszaporodtak az intrókban. Értem én, hogy nehéz értelmes tartalommal megtölteni egy 1k-s HTML-t, de nekem akkor is zsibbasztó volt látni a sok próbálkozást. Talán ezért sem tudtam értékelni a többi alkotást. A kompót számomra a Geelimanipulatio mentette meg. Linuxos 1k! És nem is rossz.

4k intro

A 4k-nál már jobb volt a felhozatal. Talán azért, mert az effektek helyett már némi tartalmat is lehetett csempészni a pixelek közé. Ezt láthattuk a Core critical és a BR4096 esetén. A Final territory, a kedvencem viszont tisztán technikai alkotás volt, kimagasló látvánnyal.

64k intro

Épp a Coercion-t néztem, amikor a lányom az ölembe ült, nézte egy darabig, majd megszólalt: Inkább nézzük a Productot, az szebb. Ezzel nehéz volt vitatkozni, de nem jelenti azt, hogy ne lettek volna jó 64k-k. Örültem a Cassininek, amiért Linuxon is próbálkoznak az emberek és nem is volt rossz a téma. Tetszett a Hardwood élethű textúrája, a 100% mozgás animációja. A Pyrotech megpróbált Conspiracy-t/Mercury-t játszani (legalábbis enyhe Fermi paradox és When silence dims the stars above beütés volt érezhető), ami technológiai szempontból nem sikerült, de történet mesélés szintjén ott volt.

Short film

Rettenetes volt az összes. A Randomheads megpróbálta folytatni azt a hagyományt, amit a Tekotuotanto elkezdett, egy olyan folytatással, aminek az első része is förtelmes. Volt egy figet spinner harcos videó is. Kérem, már elmúltak azok az idők, amikor a blue screen előtt topogást el lehetett adni gyaloglásnak. Drónok, akció kamerák vannak a piacon. De ha nincs rá pénz, akkor is meg lehet kérni egy havert, hogy mozgassa azt a nyomorult kamerát. Az egyedüli nézhető film az Agent 404 volt.

Listening music

A kategóriában bemutatott zenén nem okoztak csalódást. Aikapallo teljesen dobta a metálos stílust, de nincs oka szégyenkeznie.

Demo

Sok infantilis demót láttam már, de a Journey to Breadzembly biztosan ott van a 10 legagyalágyultabb között. Valami intergalaktikus kenyér utazik az űrben, amikor egy csillagromboló megsüti. A legfájóbb pont a végén a folytatás ígérete. A Pyrotech új demójukban úgy tűnik felülkerekedtek az elavult engine problémáján, nemes egyszerűséggel Unreal 4-re tértek át. A demó ennek ellenére nálam csíkos volt (és a többi UE-s demó is). A sztori nem volt olyan ütős, de azért a mezőny átlagából kiemelkedett.

Az ASD hatalmas demót produkált. Rosszmájúan azt is mondhatnám, hogy most sikerült lemásolniuk a Fairlight 2010-2011-es demóit, csak a mai csúcshardverekkel. (Két GTX460-ason a felénél leállt) Az igazság viszont az, hogy nagyon jó és látványos alkotást sikerült készíteni, aminek a központi témája az elmúlás volt. Technikailag a motorháztető alatt továbbra is a jó öreg OpenCV dolgozik, és tényleg kihoztak mindent a hardverből, amit lehetett.

Akkor miért nem nyert? Azért, mert a Fairlight tanult a korábbi hibákból. A Sokiáról elég rosszat írtam korábban, de amikor megláttam a Number One-t, azt mondtam: végre! Végre láttam, hogy mi történik a képernyőn. Nem tudom, hogy ez kinek az érdeme. Talán Smash megfogadta a kommenteket, talán egy designer a kezére csapott, mikor a 435. pixel shadert akarta ráhúzni az framebufferre, de nagyon jót tett a demónak. Személyes véleményem az, hogy valószínűleg az összes effektet már láttuk a Fairlight korábbi demóiban, de szerencsére nincs rajta az a zajtenger, ami korábban. Talán ezért is futott simábban a gépemen. Szóval, ha valaki tudni akarja, hogy mi a mai demoscene csúcsa, akkor ezt feltétlenül nézze meg.

Akinek szüksége lenne némi aláfestő zenére, itt megtalálja:

Az itt leírtak elsősorban Python kernellel működnek.

A Jupyter funkcióit ki lehet egészíteni úgynevezett varázslatokkal, amelyek további lehetőségekkel bővítik a rendszert. Ha aktiválni kívánunk egy varázslatot, akkor a cellába a % jel után írjuk a varázsigét. Ha az egész cellát fel kívánjuk használni a parancsokhoz, akkor %%-t használunk. Az elérhető varázslatokat a %lsmagic listázza ki.

Pythonban mindent meg lehet csinálni, amire szükségünk lehet, de vannak dolgok, amelyeket egyszerűbb a jó öreg parancsértelmezőben. A %%bash segtségével nyugodtan rendezkedhetünk a fájlok között.

Aki annyira elvetemült, mint én, és nem elégszik meg csupán a Bash és a Python adta lehetőségekkel, az használhatja az rpy2 kiegészítést, és máris keverheti a nyelveket. Még a változók megosztására is van lehetőség.

Hasonló elgondolás szerepel a %%perl mögött is, bár nem tudom, a mai világban kinek lehet ez fontos. Ha viszont a cellák szegényes formázási lehetőségei miatt aggódnánk, akkor a %%HTML segítségével bármit megvalósíthatunk, amit a HTML szabvány megenged. De ha ez sem elég, a %%latex tényleg kárpótol mindenért.

Már érzem, hogy valaki azzal a kifogással jön, hogy az Ő rendszerében egy ezeknél is egzotikusabb szkript nyelv működik, amit napi szinten használ. Mit tegyen? A varázslat attól varázslat, hogy határtalan. A %%script pontosan úgy működik, mint a #! a szkriptek elején.

 Persze az is lehet, hogy nem kívánunk kódot futtatni, csupán jegyzetként elhelyezni a szövegben. Jó lenne, ha szintaxis kiemeléssel tehetnénk mindezt. Erre is van lehetőség. Ha a cellánk leírást tartalmaz, a következőt kell tennünk (JavaScript esetén):

```javascript
```

A szöveg JavaScipt forrásként kerül feldolgozásra.

Ennyi lehetőség még Harry Potternek is elég lenne.

Manapság komolyabb publikációk nem elégszenek meg egyféle vizsgálati típussal, az összetett biológiai rendszerek feltérképezéséhez több szekvenálási módszer eredményét ötvözik. Ezek közül talán a legegyszerűbb az eQTL, ahol a mutációs és expressziós adatokat vetik össze.

A módszer lényege, hogy egy genomi pozíció homozigóta recesszív, heterozigóta, homozigóta domináns genotípusa egy gén expresszióját befolyásolja. Ha tehát a három genotípushoz tartozó expressziós értékekre egy lineáris modellt alkalmazunk, statisztikailag megállapíthatjuk a kapcsolat erősségét. Az elmondottakat sokkal jobban szemlélteti a következő ábra:

A CC genotípus mintáiban az expressziók magasabbak, mint a GG genotípus esetén.

Az eQTL számítása igen idő igényes. Minden egyes SNP és gén expresszió kombinációra ki kell számolni a korábban említett lineáris modellt. Természetesen a kellő statisztikai erő eléréséhez rengeteg mintára van szükség. A régebbi programok nem ritkán hónapokig futottak.

Attól függően, hogy milyen az SNP és az expresszálódó gén távolsága, megkülönböztetünk cisz, illetve transz eQTL-t.  Előbbi esetben a két jellemző ugyan azon a kromoszómán fordul elő, utóbbinál különbözőn.

A fejlettebb programok képesek kovariánsokat is figyelembe venni. Képzeljük el azt az esetet, amikor az egyik genotípus véletlenül csak azonos típusú mintákból származik. Például valami miatt csak nőkben található meg. Ebben az esetben nem az SNP hatását vizsgáljuk, hanem valami más jelenségét. A kovariánsok felhasználásával ezek a nem kívánt események kiszűrhetőek.

Én eddig csak a MatrixEQTL csomagot használtam R-ben. A program minimum öt mátrixot vár bemenetként. Az első az SNP mátrix. A genotípust a 0, 1, 2 számokkal jelölhetjük. A mintákat az oszlopokban kell feltüntetni, míg a sorok az egyes SNP-k, egyedi azonosítóval. Hasonlóan épül fel az expressziós mátrix is, de itt a normalizált expressziót adjuk meg a cellákban. Mindkét fájlnak van egy genomi lokalizációt tartalmazó párja. A kettő között a különbség, hogy az SNP egy pozíciót tartalmaz, míg a géneknél régiót adunk meg. Ez alapján tudja a program meghatározni, hogy cisz vagy transz helyzetű-e a kapcsolat.

Végezetül kell egy kovariáns táblázat is. A sorok a kovariánsok, míg az oszlopok a minták. Minden mátrixban a mintáknak ugyan abban a sorrendben kell lennie és a pozíció fájlokban is olyan sorrendben kell feltüntetni az SNP-ket/géneket, ahogy a másik mátrixban is megtalálhatóak.

A programot könnyű használni, gyorsan lefut, folyamatosan fejlesztik. Nem véletlen, hogy a GTEx is ezt használja.

Azt hiszem a Wigner Jenő Kutató Központ álltal szervezett GPU nap egy olyan esemény, amit minden szempontból meg kellett látogatnom. Sajnos csak az első nap vehettem részt rajta, de nem bántam meg. Mint az várható volt, a demoscene is képviseltette magát Blala személyében.

Bevallom, nem én voltam a célközönség. Az előadások egyes részei érthetetlenek voltak számomra, hiszen én ilyen mélységeiben nem foglalkozom a számítógép tudománnyal, de talán nem teljesen felesleges egy kívülálló beszámolója.

Először egy FPGA-t mutattak, amit C#-ban programoztak. A rendszer érdekessége, hogy egy új típusú számábrázolást vezettek be, ami kedvezőbb tulajdonságokkal rendelkezik. Nevezetesen a Type I unum. Érdekessége, hogy nem fix bájt hosszúságon tárolja a lebegőpontos számokat, hanem változó hosszúságon. Ez azt jelenti, hogy ha csak egész számokat kell tárolni, nem pazarol helyet a tört résznek. A pontosság is változtatható, annak függvényében, hogy mekkora precizitásra van szükség.

Egy előadás keretében a kvantum számítógépekről is adtak egy áttekintést. Ebből leginkább az maradt meg, hogy ez jelenleg inkább egy játék, mint munkaeszköz. Egy GPU-n futó emuláció majdnem gyorsabb, mint egy valódi kvantum számítógép.

Betekintést nyertünk a C++ Standard könyvtár párhuzamosított verzióiba. Szép, gyors, de a bemutatott példakód kegyetlenül ronda volt. Értem én, hogy C++14, de lassan több lesz a nem alfanumerikus karakter a kódokban, mint betű. Ez egyáltalán nem az a C++, amit én annak idején tanultam. Alkottam is egy új elméletet: előbb-utóbb minden programozási nyelv a Brainfuckig fejlődik.

A következő három előadás összefüggött, a Pázmány Péter Katolikus Egyetemről jöttek az előadók. Először egy fordító programot mutattak be, ami egy magas szintű nyelvből különböző platformra optimalizált kódot tud előállítani. Ezt különböző egyenelt megoldó algoritmusok optimalizálására találták ki, hogy utána egy lépésben elkészüljön a kód Cuda, SIMD vagy OpenMP-re.

A második előadás arról szólt, milyen egyenleteket oldanak meg az előbb bemutatott módszerrel. Kitaláltak egy új algoritmust, amivel hatékonyabban lehet a strukturálatlan hálókon alapuló egyenleteket megoldani. A strukturálatlan hálókat különböző szimulációk esetén használják a tér felbontására. Ahol a háló sűrűbb, ott a szimuláció részletesebben fut le, mint ahol tág. Az előadás során például a repülőgép szárny profilokra ható erők hatásait mutatták, mint példa alkalmazást.

A harmadik előadás egy olyan optimalizációs eljárásról szólt, amiben az egyenleteket a lineáris algebra műveleti elemeire bontják, majd egy permutációs módszerrel megkeresik azok legjobb kombinációját. A gyakorlatban a felcserélhető műveletek egyes esetekben jobban optimalizálhatóak, de ez mindig az adott számítógép architektúrától függ.

Demoscener szempontból a modern sugárkövetési módszerek bemutatása volt a legérdekesebb. Bemutatták az NVIDIA Optix-ot, Radeon Rays-t és a Baikalt. Természetesen a Microsoft új DirectX API-ja sem maradhatott ki. Aki nem rendelkezik nagy teljesítményű grafikus kártyával, az Intel által fejlesztett Embree-vel tehet próbát.

Megismerkedhettünk a fotogrammetria tudományával is, habár csak felületesen. Az előadás azt mutatta be, hogy a bonyolult, zárt kódú alkalmazások helyett hogyan lehet egy funkcionális alapokra helyezett programozási nyelvet készíteni, amivel magas szinten lehet a szükséges lépéseket megvalósítani.

A következő három előadás szintén összefüggött. Három előadáson keresztül mutatták be, hogyan álltak át egy C++-os, nehezen fejleszthető grafikus rendszerről egy F#-ba átírt funkcionális engine-re. Számomra már az is hihetetlen volt, hogy megtették ezt a lépést. A legtöbb cég inkább hegesztené az elavult motort, amíg szét nem esik vagy a fejlesztők rituális öngyilkosságot követnek el.

A rendszer előnye, hogy könnyebben fejleszthető, egyszerűbb a hibakeresés. A performancia alacsonyabb, és a rendszer felhasználóit is át kell képezni, de összességében úgy gondolják, megérte. A rendszer nyílt, bárki megnézheti. A legérdekesebb a shaderek megvalósítása, ami szintén F#-ban írtak és abból fordul az OpenGL saját shader nyelvére.

Láthattunk egy másik előadást, amiben egy épület fény térképét készítették el. Egészen pontosan egy régi kastély sötét zugait kellett megkeresni. Első lépésként drónnal körberepülték a környéket és minden szögből lefotózták a kastélyt. A Reality Capture programmal elkészítették a 3D modellt tesztúrákkal együtt. A Nap helyzetét letöltötték a sunearthtools.com-ról, majd minden napszakra legenerálták az árnyék textúrát (shadow map). Ha az adott hely fényt kapott, eggyel növelték ott az értéket. Gyakorlatilag a kastély textúráját heatmapnak használták. Ahova kevés napfény jut, ott a textúra alacsony értékeket tartalmazott és magas volt ott, ami napfényben fürdött.

Egy másik előadás is a funkcionális programnyelvek grafikus motorként történő alkalmazásáról szólt. Amíg a korábbi előadásokban bemutatott Aardvarkot több fejlesztő, kb. másfél évig programozta, addig ezt a rendszert egy lelkes magyar szabadúszó megcsinálta otthon. Ő egy Haskell-szerű nyelvet készített. Még a Quake3-t is lefordította rá.

A nap utolsó előadása a Microsoft Hololens volt. A YouTube-on fellelhető összes reklám videót megnéztük. Ha kicsit gonosz akanék lenni (és miért ne tenném?), akkor azt mondanám, hogy a pocsék dokumentálás kiváltására találták ki.

Összességében jó kis nap volt, kár hogy másnapra, ahol tudományos eredményeket mutattak be, nem tudtam maradni.

Egyszer láttam egy TV műsort, ami különös baleseteket dolgozott fel. Az egyiknél egy 17 éves fiú egyedül üldögélt egy lőtér bódéjában. Nem ment be rajta kívül senki, ő mégis meghalt egy fejlövésben. A nyomozók végül kiderítették, hogy egy ember a megengedettnél erősebb lőszerrel lőtt a lőtéren, elvétette a célt, a golyó átment az eltévedt lövedékek megállítására felállított palánk alatt, eltérítette egy fém akadály, végül a bódé falát átütötte és megölte a fiút.

A tanúság, hogy egy-egy hiba kivédhető, de néha több hiba összhatása hihetetlen kárt tud okozni.

Most valami ilyesmit csináltam. Az én esetem inkább vicces lesz, mint tragikus. Legalábbis akinek eddig elmeséltem, az nevetett rajta.

Már korábban is utaltam rá, hogy egy webes szolgáltatást kell most készítenem. Részletekbe nem megyek be, de a rendszer egy gén nevet vár bemenetként, majd zötyög egy kicsit, mint valami traktor és kidob más génneveket. Főnököm letesztelte a PD-L1 génre. Illetve tesztelte volna, mert a PD-L1 valami régi azonosító, a HUGO nomenklatúrában nem található, ezért a weboldal egy böffenés digitális megfelelőjével válaszolt.

A főnök ezután nekem támadt, hogy miért nem talál semmit a rendszer? Mondtam, hogy a CD274-el kell próbálkozni, akkor lesz eredmény. (Persze előtte megnéztem a Wikipédiát, attól voltam ilyen tájékozott.) Közben képbe került egy másik számomra teljesen random gén, a PD-1, ami meg a PDCD1-nek felelt meg.

Egyik nap éppen a weboldalt teszteltük. A főnök nem emlékezett a HUGO azonosítókra, de én már annyit dolgoztam velük, hogy fejből mondtam. A keresőbe beírta, a program meg kidobott kb. 500 gént. Se nekem, sem a főnökömnek egyik azonosító sem mondott semmit. Akár a Szilmarilok családfáját is kiköphette volna a program. A főnök mégis egyre türelmetlenebbül kérdezgette, hogy ezek milyen gének? Miért adta ki őket a program? Én csak vonogattam a vállam és azt mondtam: azért adta ki őket, mert a statisztikai számítás ezeket adta eredményül.

Aztán észrevettük a NOP14-et. Szerelem volt első látásra. Máig nem tudom, mi váltotta ki ezt a szenvedélyes tüzet, de onnantól a NOP14 csodagénné lépett elő. Voltak nála szignifikánsabb eredmények, voltak nagyobb változást okozók, de azoknak csúnya nevük volt, mint például POM121C vagy ARHGEF10L. A NOP14 pedig a maga szemérmes, egyszerű nevével maga volt a csoda. A főnök különféle beállításokat eszközölt a weboldalon, állítgatta a paramétereket, de a NOP14 kiállt minden próbát. Amikor kiderült, hogy a másik vizsgált gén eredményei között is ott a NOP14, akkor elindult a lavina.

Estére már egy absztraktot kaptam, a főnök riasztotta a tengeren túli kapcsolatát, hogy ellenőrizze a betegek NOP14 mutációit, mert itt valami nagy dolog van készülőben. Nekem már csak annyi dolgom akadt, hogy a weboldalt átalakítsam, hogy a régi gén szinonimákra is működjön.

Át kellett tervezni az adatbázist, de nem volt túl bonyolult. Csupán az adatok ismételt importálása miatt húzódott el az egész. Mikor végeztem, leteszteltem a programot a PD-1 génre. A NOP14 a maga szerény módján továbbra is ott állt, félénken meghúzódva a többi szignifikáns eredmény mellett. Kipróbáltam a PD-L1-t is, de a NOP14 eltűnt!

Nem értettem. Ha beírtam a CD247-t, a NOP14 ott volt. Ha beírtam a PD-L1-t, a NOP14 hiányzott. Néztem az adatbázis tábláit, ellenőriztem mindent, de sehol nem találtam a hibát. Újra elővettem az absztraktot, amikor feltűnt, hogy rosszul emlékeztem a HUGO névre. Nem CD247, hanem CD274! Rossz gént mondtam a főnökömnek a tesztelés idején. Véletlenül azzal is kijött a NOP14, és írtunk egy absztraktot egy webszolgáltatásról, ami forradalmasítja az immunterápiát. Bizonyítékként pedig a két gént hoztuk fel, amelyek megtalálják a NOP14-t.

A főnök elég jól fogadta a hírt. Azt mondta, az absztraktot már nem tudjuk megváltoztatni, de a poszteren már nem fog ez szerepelni.

Elkezdtem Function-re demót készíteni. Mivel a csapat tagjait elég nehéz motiválni, ezért elhatároztam, hogy készítek egy vázlatot, ami már egy működő demó lesz és akkor talán nagyobb lelkesedéssel vetik az emberek magukat a munkába.

Ezért Blenderben elkészítettem egy színteret - természetesen Linux alatt - majd áttértem Windowsra, hogy megírjam a kódot. Majd később elmondom, miért kell Windows alatt futnia a következő alkotásnak, de most legyen elég annyi, hogy az alatt kell futnia, mindenféle hardveres gyorsítás nélkül.

A jelenetet OBJ-be mentettem el és szerettem volna megnézni a szerkezetét. A vacak Notepad nem boldogult vele (Linuxos sorvége jel), ezért egy hirtelen ötlettől vezérelve megnyitottam Visual Studio alatt. Elvégre az is képes szöveget megjeleníteni.

A Visual Studio elkezdett tekerni veszettül. Én egyre nyugtalanabbul ültem a gép előtt és vártam, hogy visszakapjam az irányítást. Már azon voltam, hogy lelövöm az egészet, amikor megjelent az alakzatom.

Régen döbbentem meg ennyire. Lehet forgatni, mozgatni, mintha csak egy 3D szerkesztőben lennék.

Az egyik szerverré előléptetett PC bemondta az unalmast. Mégpedig az, amelyiken mindenki vigyorogva mutatja, mennyire jól érzi magát a csoportunkban és mennyi-mennyi impakta faktort kapart össze az évek során. A főnök kezembe nyomta a gép lelkét képező vinyót, hogy próbálja meg kimenteni a csoport honlapot. Ő maga megpróbálta, de a vinyón "nem látszik semmi, még az otthoni gépen sem". Ezen nem is csodálkoztam. Linuxos fájlrendszer ritkán látszik Windows alól.

- Kicsit kiegyengettem a csatlakozókat - mondta búcsúzóul.

Csing-csing-csing - szólt a vészjelző a fejemben. Mitől görbült el? Megnéztem a csatlakozót, és először fel sem tűnt a turpisság.

Ennek így kellene kinéznie:

Éljen a változatos munka, még halálra untam volna magam. Mikor először csatlakoztattam a gépre, a vinyó nem látszott, bizonyára nem volt jó az érintkezés. Aztán Szent McGyverhez fohászkodva megjött az ihlet:

LVM-es partíció volt rajta, az lvscan paranccsal megkerestem az eszközt és gond nélkül felcsatoltam. A /var/www konyvtárban megtaláltam a honlap anyagát, de azt is észrevettem, hogy Drupal alapú, tehát szükségem lesz az adatbázis bejegyzésekre is.

A settings.php-ból megtudtam, hogy Postgres-ben tárolták a cuccot. Szuper, életemben nem használtam. A netet böngészve megkerestem a biztonsági mentés opciókat. Mivel csak a fájlrendszerhez fértem hozzá, pg_dump szóba sem jöhetett. Lementettem a /var/lib/postgresql/9.4/main könyvtárat és reménykedtem benne, hogy nincs semmi eldugott konfig, ami nem szabvány viselkedésre kényszeríti a rendszert.

Az adatok megvoltak, már csak migrálni kellett. Kiválasztottunk egy másik leharcolt PC-t a szerver parkból, amin már futott egy weboldal és az mellé próbáltam tenni. A weboldallal nem volt gond, hiszen azt a megfelelő helyre másoljuk és kész, de az adatbázissal ezt nem tudtam megtenni. Felül írtam volna a már létező bejegyzéseket.

Nem volt más megoldás, mint telepíteni Postgrest a gépemre, belerakni a fájlokat, majd a pg_dump-al kimenteni az adatokat. Akkor az eredmény egy csomó SQL utasítás lesz és azt már könnyedén berakom a végleges helyére, a létező adatbázisok mellé.

Sajna az én Kubuntu verziómhoz nem volt csomag repo, csak a páros verzió számúakhoz. Oké, fordítsunk egyet magunknak forrásból. De melyik verziót? 9.4, addig oké, de mennyi különbség van az egyes alverziók között? Lesz-e kompatibilitási gond? Azután gondoltam egy merészet. Mivel mindkét PC-t ugyan az a rendszergazda telepítette, feltételeztem, hogy ugyan azokat a szoftver komponenseket használta. Rövid kutakodás után az új gépen megtaláltam: 9.4.15. Ez lesz a szerencseszámom.

A fordítás simán ment. Mivel nem terveztem sokáig használni, csak a tmp-be raktam és az inidb-vel ott hoztam létre az adatbázisok helyét is. Következett a nagy pillanat. Vajon képes lesz egy "megegyengetett" csatlakozójú merevlemezről lementett, ismeretlen verziójú adatbázist beolvasni valami, amit maga fordítottam a /tmp könyvtárba?

Igen, a dolog működött! Az import már nem volt vészes, bár nem volt elég jogosultságom, úgyhogy a rendszergazdának is kellett ügyködni egy kicsit.

Az impakt faktor dicsőség táblát ismét megcsodálhatja mindenki. A Világ megmenekült, hála a Pindúr Pandúroknak.

A legkülönbözőbb fórumokon találkozni azzal, hogy növeljük a női programozók számát vagy hogy a programozást kötelezővé kellene tenni az iskolákban. Legutóbb épp QBPartyn jött föl a téma. Amint ezek a kezdeményezések szóba kerülnek, rögtön jön a Nagy Programozó Macsó klán és hangosan bizonygatja, hogy ez milyen rossz, haszontalan, káros. Érveik szerint felhígulnak a programozók és egyre hülyébbek lesznek, olcsón csinálják meg azt, amit a Nagy Programozók verejtékes munkával (és drágán) előállítanak.

Szerintem ez nem arról szól, hogy mostantól maszkban, lesben állva ártatlan nőket rabolnak az utcán és KGB-s módszereket megszégyenítő agymosási eljárással programozó-ügynököket telepítenek szoftver fejlesztő cégekhez, ahol aztán romboljuk a jó hangulatot, aláássák a morált. Ez az egész arról szól, hogy akit érdekel a programozás, azt hagyjuk kibontakozni.

Ez látszólag triviálisnak tűnik, de igazából nem az. Például ismertem olyan PhD hallgatót, akit érdekelt a programozás, jól is ment neki, de a tanulási szakaszában voltak kérdései. (Kinek nincsenek? Erre épül az egész StackOverflow.) Férje szintén az IT valamelyik bugyrában tevékenykedett, nyilván ő volt az első, akit megkérdezett. Ahelyett, hogy segítette volna, ingerülten azt válaszolta, hogy használjon guglit.

Mellékesen megjegyezve mások intellektuális elnyomása nem korlátozódik a férfi programozókra. Annak idején az egyetemen sok kurzust orvosisok tanítottak nekünk. Emlékszem, volt egy prof, aki minden egyes előadáson elmondta, hogy mi, biológia tanárok semmik vagyunk a medikus hallgatókhoz képest. Nem érti, miért akarunk mi genetikával foglalkozni, hiszen erről az egyetemről csak muzeológusként tudunk elhelyezkedni, hiszen ennyi tanárra sem lesz szükség. Így is hívott minket: muzeológusok. Becsületére legyen mondva, mindkét nemet egyformán lenézte, ha nem orvosok voltak.

De akár az általános iskolai pályaválasztással kapcsolatos esetemet is említhetném, ahol minden gyerekre, aki olyan szakmát említett, amihez egyetemi végzettség kellett, az osztályfőnök valami gúnyos megjegyzést tett, miközben az arcán leplezetlen undor tükröződött. Példaképként kiállította az osztály egyik legbutább gyerekét, mert ő asztalos akart lenni. Ó, igen, bár számítástechnika osztály voltunk, a legtöbb tanár azt hangoztatta, hogy "ennyi informatikusra nem lesz szükség".

Szóval én át tudom érezni azt a hátrányos megkülönböztetést, amivel a női programozók szembenéznek. Ráadásul mindezt egy ostoba ideológia mögé bújtatják, mint amilyen a férfi és női agy különbsége. Biológusként tudom, hogy van különbség az átlagos férfi és átlagos női agy között. De ezt egyénekre vetíteni súlyos hiba. Hiszen az átlagos férfi izomzat és női izomzat között is van különbség, de kíváncsi vagyok ki akar verekedni az olimpiai judo verseny utolsó helyezettjével (a bajnokról nem is beszélve). Arról nem is beszélve, hogy az első programozó nő volt.

Egyébként meg nem csak a szoftver fejlesztőknek van szüksége programozásra. Ez a másik, amit a Nagy Programozó Macsók nem képesek megérteni. Azt hiszik, mert az ő munkájukhoz valami bonyolult kliens-szerver architektúra kell, a programozás csak arra való. Ez szűklátókörűség. A programozás annyira szerte ágazó lett, hogy szerintem nem lehet egy szakmának tekinteni. Bár nem láttam egyetlen statisztikát sem a témában, biztos vagyok benne, hogy minimális az átjárás például egy beágyazott rendszer vagy web fejlesztő között.

Én sem vagyok szoftver fejlesztő, de napi szinten kell kódolnom. Sőt, ez a hobbim is. Egy PhD hallgató ismerősöm például magán szorgalomból elkezdett Pythont tanulni. Később elhagyta a pályát és növény nemesítéssel kezdett foglalkozni. De mikor kiderült, hogy egy saját maga által írt kóddal egyszerűbben meg tudja csinálni azt, amit Excellel csak nagy nehezen, más feladatot is rábíztak, fontosabbá vált. Tud adatbázis szerverrel kommunikálni? Nem. Képes operációs rendszert írni? Nem. Multiplatform játékmotort programozni? Nem. Szüksége van minderre? Nincs. Egy analógiával élve: jobban vezet egy rally versenyző, mint egy családapa? Igen. Kell egy autóversenyző tudása, hogy a gyereket elvigye az iskolába? Nem.

Sokan tudunk írni, mégsem tud mindenki újságot írni. Nem hígultak fel a taxisofőrök sem, most, hogy szinte mindenkinek van kocsija.

Nem kell félni, hogy mások is jobban megismerik a számítógépet és a programozás segítségével hatékonyabban tudják azt használni. Ez a számítógép lényege: hatékonyabban megcsinálni azt, amit mi, emberek nem tudunk. A hatékonyabb felhasználás pedig nem azt jelenti, hogy fogyasztóként csak klikkelünk mások termékein.

Például volt egy gyakornok, aki amellett, hogy 10000x10000-es képeket akart készíteni, a nálunk megszerzett programozó gyakorlatával készített egy alkalmazást, ami kikapcsolta a gépet, mikor elaludt film nézés közben. Nem volt egy szofisztikált megoldás, de működött. Én személy szerint nagyon örültem, mikor elmesélte, mert kitágult a látótere, felismert egy problémát és megoldotta. Mások is felismerik a problémát, de csak siránkoznak, hogy a gép nem csinálja azt, amit akarnak. Igen, mert senki nem mondta meg a gépnek, hogy azt csinálja. Senki nem programozta be rá.

Tehát szerintem nem kell félni, hogy felhígul a programozók tábora azzal, hogy mások is megismerik a programozást, de ha a Nagy Programozó Macsó klán felhígulna, az üdvözítő lenne.

Van egy régi vicc, amiben egy öreg bácsi afrikai szafari utat nyer. Mikor hazatér, barátai kérdik tőle, milyen volt az út.
- Mit láttál?
- Láttam tevét.
- Az meg milyen?
- Tudjátok, milyen a ló?
- Tudjuk.
- Ez pont olyan, csak van egy púp a hátán.
- És még mit láttál?
- Láttam zsiráfot.
- Az meg milyen?
- Tudjátok, milyen a ló?
- Tudjuk.
- Ez pont olyan, csak hosszabb a nyaka.
- És még mit láttál.
- Láttam zebrát.
- Az meg milyen?
- Tudjátok, milyen a ló?
- Tudjuk.
- Ez pont olyan, csak csíkos.
- És még mit láttál?
- Oroszlánt.
- Az meg milyen?
- Tudjátok, milyen a ló?
- Tudjuk.
- Na, ez egyáltalán nem olyan.

Ugyan ez elmondható az egy sejtes RNA-seq-ről is. Akik dolgoztak laborban, tudják, hogy az RNS feltárása nehezebb, mint a DNS-nél. A DNS izolálást akár hallgatókra is rá lehet bízni az egyetemi oktatás során, de az RNS izolálás nem egyszerű. Még szakavatott labor dolgozók is szembesülhetnek vele, hogy több ezer sejtet tartalmazó mintájukban egy molekula RNS sincs. Most képzeljük el, hogy mindezt egy sejten kell végrehajtani! Egy sejtnyi RNS-t kell megmenteni az emésztő enzimek karmaiből. Természetesen a droplet eszközök megpróbálják még a legügyetlenebb kutatót is támogatni, de akkor sem kell meglepődni, ha a több száz mintából nem lesz mindegyikben értékelhető RNS.

Több száz minta? Miért kell több száz minta? Azért, mert ha sikerül is a feltárás és izolálás, az RNS-t sokszorozni kell. A sokszorozás nem minden régiót amplifikál fel a kellő mértékben, előfordulhat, hogy egyes genomi pozíciókról nem lesz értékelhető read. Szerencsére ez a hiba nem teljesen szisztematikus, ezért a mintaelem szám növekedésével kiküszöbölhető.

A másik ok, ami miatt több mintára van szükség, mint egy átlagos RNA-seq esetén, a tény, hogy egy sejtből indulunk ki. A szövetek génaktivitása nagy mértékben változhat. Még a hagyományos RNA-seq esetén is találkozhatunk olyan "anomáliákkal", hogy a minták közötti különbség nem a kezelésnek köszönhető, hanem annak, hogy az izolálás más napszakban történt. Egy sejt esetén mindez sokkal jobban felerősödik. A sejtciklus minden sejtben másik fázisban fog tartani, ezért a legerősebb különbség a cirkadián ritmust szabályozó génekben lesz.

Ezek után nem meglepő, hogy a kontrolok jelentősége megnő. Az ERCC egy olyan mesterséges transzkriptek gyűjteménye, ami nem mutat homológiát egyetlen humán génnel sem. Mennyisége nem függ egyetlen biológiai folyamattól sem, ezért bármilyen különbség az expresszióban csupán a szekvenálás számlájára írható. A normalizálás sokkal könnyebb lesz általa. Nem véletlen, hogy szinte valamennyi program igényli meglétét.

A másik nagyon fontos mutató a mitokondriális gének aránya a mintában, ami a feltárás sikerességének egyik mutatója. Ha valami miatt a laborban az RNS lebomlott az izolálás során, a mitokondriális RNS képes megúszni ezt, lévén hogy újabb membránnal van körbevéve.

A scater nevű eszköz egyben képes az összes lényeges minőségi mutatót meghatározni és szép abrákat készít.

A feldolgozás tehát nagyrészt ugyan úgy kezdődik, mint egy hagyományos RNA-seq esetén, de mikor elkészül a nyers táblázat a read mennyiségekkel, más eszközök után kell nézni. Említettem, hogy a legjobb eredmény a negatív binomiális regresszión alapuló módszerekkel érhető el. Sajnos a "közönséges" modell rosszul teljesít, ha sok nulla van. Kezdetben ezért a nulla tartalmú modelleket használtak (zero-inflated negative binomial), de ez is amolyan kényszer megoldás volt.

Még jelenleg is kutatócsoportok dolgoznak azon, hogy kidolgozzák a legjobb módszereket, ezért nem lehet kijelenteni, hogy a téma lezárt lenne. Inkább nézzük meg, milyen stratégiákat alkalmaznak és milyen kérdésekre keresik a választ.

Talán nem meglepő, hogy a szöveti differenciálódás az, amit a legtöbben kutatnak. (Azon belül is az immun sejtek leszármazási képét, mert vért izolálni a legkönnyebb.) Egy főkomponens analízishez hasonló projekciós módszerrel a sejteket egy olyan síkra vetítik, ami a fejlődési állapotoknak feleltethető meg. Ezt nevezik pszeudo-időnek (pseudo-time). Ezt az idővonalat vizsgálva beazonosítható a sejtek leszármazási térképe és akár új sejttípusok is felfedezhetőek.

Egy másik, felfutóban lévő terület a sejtek térbeli elhelyezkedésének vizsgálata. Ezt a Humán Sejt Atlasz kezdeményezés teszi sürgetővé. Alapvetően két módszer létezik: Az egyikben egy Gauss-i kevert modellt használnak, a másik pont jelöléses módszeren alapul (marked point process, nem tudom, mi a magyar megfelelője). A téma annyira friss, hogy jelen pillanatban még korrekt összehasonlító módszer sem létezik, hogy melyik a jobb.

Természetesen a jó öreg differenciál expresszió is létezik, de a hiányzó értékek miatt új módszereket kellett kifejleszteni. Példának okáért, míg egy hagyományos RNA-seq esetén tudjuk milyen csoportokat akarunk összehasonlítani, addig egy sejtből kiindulva gyakorlatilag teljes homályban tapogatózunk. Érdemes ezért felügyelet nélküli klaszterező módszerekkel a mintákat csoportokra bontani, mielőtt expressziós különbségeket keresnénk.

Ezzel próbálkozik az SC3 is. Mivel ez is az EBI terméke, remekül kiegészíti a scater-t. K-közép klaszterezésen alapul, ezért előre meg kell mondani, mennyi klasztert akarunk találni. Ha megtaláltuk a csoportokat, az scde csomaggal már meg is határozhatjuk a géneket.

A feldolgozás egyébként nem ritkán iteratív. Meghatározzuk a klasztereket, megnézzük a géneket, majd ha valami furcsaságot tapasztalunk, újra klaszterezünk. Ez a módszerek kiforratlansága miatt van így.

Ezzel el is érkeztünk sorozatunk záró részéhez. Megpróbáltam az RNA-seq-et annyira kivesézni, amennyire csak lehet. Bizonyára akadnak tévedések és hiányzó részek az epizódok között, hiszen senki nem lektorálta a leírtakat, de reménykedem benne, hogy sokkal hamarabb elvaul az itt felgyülemlett tudás, mint hogy kiderülnének ezek :-).

Nagy mennyiségű szöveg feldolgozásánál jelentkezhet az igény, hogy jó lenne a szavakat jelentés alapján csoportosítani. Erre az egyik módszer a Google által fejlesztett word2vec. Felületesen szólva az algoritmus nem csinál mást, mint a szavakat egy topológiai térképre helyezi. Ez azt jelenti, hogy az azonos jelentésű szavak közelebb kerülnek egymáshoz. Vagyis ha megnézzük, milyen szavak vannak a térképen a macska közelében, akkor megtalálhatjuk a cica szót. De ami még ennél is érdekesebb, hogy ebben a térképben vektorműveleteket végezetünk, ami további kapcsolatokat fed fel a szavak között. Mit is jelent ez? Ha a Németország - Berlin vektort rávetítjük Franciaországra, akkor Párizs fog kijönni!

Az algoritmust és a példakódokat bárki letöltheti és kipróbálhatja. Vannak példák a Wikipédiára és más nyilvános szöveg adatbázisokra, de én arra gondoltam, ki lehetne próbálni, mit tud az algoritmus, ha az összes elérhető tudományos publikációt beadom neki.

Először is letöltöttem az EuropeanPMC-ről az összes cikket XML formátumban. Egy saját fejelsztésű szkripttel kiszedtem a cikkek törzsét, azon belül eltávolítottam az összes XML tag-et, táblázatokat, magányosan álló számokat. Hevenyészett nyelvtani tudásomnak megfelelően az összes kötőszót, névelőt és hasonló, jelentéssel nem bíró nyelvtani elemet. Nem törekedtem tökéletes eredményre (nem is lett az), mindent szóközzé alakítottam.

Elég sok fájl volt, ezért a szuperszámítógépen futtattam a programot. Mivel a miniDOM-ot használtam, ami nem a legjobb megoldás nagy XML-ek kezelésére és elég lassú is, ezért optimalizáció helyett nagyobb erőforrást adtam csak alá. A végén már 80GB memória kellett a szkriptnek. Nem akartam túl sok időt bohóckodni vele. A végső korpuszt egybe gyúrtam, és egy 32 processzoros gépen elkészítettem az összes publikáció vektor reprezentációját.

Nyilván a feltárt kapcsolatok függenek a beadott korpusz tartalmától. A fent említett példák ezért biztosan jól működnek egy Wikipedia-szerű, általános információkat tartalmazó szövegben. Meglepő módon a publikációkból is kinyerhető ez az információ!

Először tumorok neveivel kísérleteztem, de csak más tumorok jöttek ki. Ha beírtam, hogy breast, rögtön kijött, hogy cancer és prostate. Nem rossz, nem rossz. Kíváncsiságból beírtam a főnököm vezeték nevét, mire az első 10 találatban ott volt, hogy kmplot. Ezen jót nevettem, de érthető is, mert az a legidézettebb cikke. Ezt követően elkapott a gépszíj és egy csomó csúnya szót is beírtam. Nagyon meglepődtem, amikor mindegyik találatot kapott. Ha nem említettem volna, az algoritmus alapértelmezetten az első 10 ezer leggyakoribb szót használja csak a térkép elkészítéséhez, és ebben benne van az angol káromkodás java része. Ennyit a tudományos nyelvhasználatról.

Még az én rég elfeledett programom, a mofext is reprezentálva van, motifscannerrel, fuznuccal esik egy kategóriába, ami igaz is, tényleg hasonló feladatot látnak el. A 24. helyen pedig a doopsearch jött fel. Le voltam nyűgözve.

Ezt követte a szókapcsolatok felderítése. Itt már jóval nehezebb volt a dolgom. Igazából az ok, ami miatt belekezdtem a projektbe, hogy szövegbányászattal lehet-e új géneket találni az egyes ráktípusokhoz. Olyan géneket, amelyek megvannak a publikációkban, de valahogy elkerülték mindenki figyelmét. A programnak három szót kell beadni, és a válasz egy analógia lesz. A bevezetőben bemutatott példa valami miatt nem működött, de a berlin germany paris hármasra megkaptam a france-t.

Sőt, a kutatók karrierjét is elég jól fel lehet térképezni a módszerrel. Például az altschul blastn loman hármasra a minion jön ki. (Nick Loman elég sok MinION-os cikket publikál. Altschul pedig a Blast fejlesztője.)

Ez után jött a kísérletezés. A retinoblastoma rb1 breast-re az esr1 jött ki első helyen. Brca1 csak a 8. volt. Arra számítottam, hogy előkelőbb helyet foglal el. A cancer tp53 metastasis kapcsolat a ctnnb1, pten, p53, kras találatokat kaptam. Igazából bármilyen kapcsolatra, amiben szerepelt a cancer, ezeket a géneket hozta fel.

Ilyen szempontból az eredeti célokat nem értem el, nem találtam új géneket. Igazából elég sok időt el lehetne játszani vele, mert a korpuszt is válatozhathanám. Például a különböző rák típusokat nem hagynám elveszni (breast_cancer). De nem hiszem, hogy egy projektet érdemes lenne rááldozni.

A RUFUS eredetileg egy PhD disszertációnak indult, de csakhamar életcéllá vált. Egy korábbi hozzászólásomban megígértem, hogy kipróbálom, amit most be is tartok.

A GitHubról letöltött legfrissebb verzióval próbálkoztam, ami valószínűleg több problémát okozott, mint hasznot, de a végére már csak dacból sem töltöttem le a legstabilabb verziót.

Telepítés

A telepítés nem ment simán. Illetve simán ment, de használat közben derült ki, hogy nem sikerült. Az is másfél óra futás után. Szóval az alap telepítés nem működik. Leszedi a szükséges függőségeket, de valahogy a tabix kimaradt és elkeseredetten vinnyogott miatta. A program által letöltött samtools csomagból viszont könnyedén fordítottam egyet és betettem az általa elvárt könyvtárba (bin/tabix) A RUFUS.interprettel viszont komolyan meggyűlt a bajom, mert nem értettem a linker által adott hibaüzenetet. Mint kiderült előre fordított fájlok voltak az src/include könyvátrban. Azokat letöröltem és az src/external/fastahack könyvtár kódját újra fordítottam -fPIC opcióval, majd kézzel a .o kiterjesztésű állományokat az src/include könyvtárba másoltam. Végül már csak a beleégetett elérési utakkal kellett megbírkózni a scripts könyvtárban. A hibákat kijavítva már futott.

Használata

A leírás szerint képes referencia szekvencia nélkül futni, de a valóságban csupán FASTQ fájlokat nem lehet beadni neki. A bemeneti állomány BAM fájlok és egy BWA által indexelt referencia állomány! Igen, egy indexelt referencia. Nélküle meg sem nyikkan. Tesztfájlnak a TCGA-ról letöltött adatot használtam. Ez két BAM fájlt és négy VCF állományt tartalmazott, amive összehasonlíthatom az eredményeket.

runRufus.sh -s 9ea8bfdf928ö15cb155f3fö86beb8191_gdc_realn.bam -c 7db35f69f8d0c825a29073137a70dd99_gdc_realn.bam -t 2 -k 25 -r human.fa

A program 101 percet futott (Core i5, két szálon) és 5 darab SNP-t azonosított, ebből 2 mitokondriális. A Mutect2, amiben a legjobban bízom, csak ez utóbbiakat találta meg, a többit nem. A SomatiSniper volt képes egyedül megtalálni az egyik autószómális mutációt. Az egyik mutáció, amit csak a RUFUS talált meg, egy EHF génbe esett, ami érdekesnek tűnik és még le is írták bélrákban, de őszintén szólva elég nehéz elhinni, hogy ez az egy mutáció felelős ennek a betegnek az állapotáért, akit ráadásul mellrákkal diagnosztizáltak.

A másik ok, ami miatt szkeptikus vagyok az eredményeket illetően, hogy nem találtunk egyetlen TTN mutációt sem. Még Patrick is tudja, hogy rákos minták szekvenálásánál ennek lenni kell :-)

A program rengeteg átmeneti állományt készít és mivel nincs parancssori kapcsoló a szabályozásukra, rengeteg felesleges fájl marad hátra a futás után. Kicsit kényelmetlenné teszi a használatot.

A stabil verziót is megpróbáltam lefuttatni, hogy ne mondhassátok: bizonyára a forráskódban való turkálásom rontotta el a programot, de az sem fordult le magától és ott is ugyan úgy megvannak a beégetett elérési utak.

Összegzés

A program valamikor valószínűleg referencia mentes variációkat keresett, legalábbis a legelső kód GitHubon még FASTQ fájlokat olvasott. Időközben viszont elkezdett hízni és lett belőle valami, ami már köszönő viszonyban sincs az eredeti célokkal. Ennek nem tudom, mi lehet az oka. Talán a referencia még mindig több előnyt kínál, mint amennyi problémát okoz, amit végül barátunk is belátott. A másik lehetőség, hogy a rákos minták nagyobb kihívást jelentenek a program számára, mint a trió adatok, amin eredetileg fejlesztették. Minden esetre én nem akarom többet használni.

A veszekedés után éberen feküdtem az ágyban. Hallottam, amikor a zárnyelv minden igyekezet ellenére csattan a kulcs elfordítása után. Elment. Biztos azt hitte már alszom. De hogyan is alhatnék, egy ilyen helyzetben? Tudtam, hova megy. Biztosan a barátjához, ahhoz a szerencsétlen alakhoz, aki tizenkilenc évesen is azt gondolja, holmi zenélésből meg lehet élni és el lehet tartani egy családot. Nem, családra biztosan nem gondol. Csak a lányomat akarja taperolni, amihez immár minden körülmény adott. Illetve adott lesz, amint megérkezik hozzá.

A gondolatra éreztem, ahogy megkeményedik az államon egy izom. A dac izma. Ezt nem hagyhatom! Levetettem a takarót és öltözni kezdtem. Nem kellett sietnem, tudtam, hova kell mennem. Azt, hogy mit fogok tenni, még nem volt tiszta. Soha sem tiszta, mit kell tenni. Az ember csak megadja a kezdő lökést és a dolgok beindulnak. Az első lépés után a rendszer saját tehetetlensége folytán mozgásba lendül. Ilyenkor késő meggondolni magunkat, mert a sors csak széttárja a karját és annyit mond: Te akartad!

- Mit csinálsz, fiam?

- Apa, te hogy kerülsz ide?

- Tudod, te jól - természetesen tudtam. Egyre élethűbb volt, ami az időnek és a kitartó munkámnak volt köszönhető.

- El kell mennem. A lányom hülyeséget akar csinálni.

- Minden gyerek azt akar csinálni - nem tette hozzá: Te is. Nem is kellett.

Pillanatok alatt felöltöztem. Az ajtóhoz léptem, nekem nem kellett attól félnem, felébresztek valakit. Gyorsan kiértem a hűvös éjszakába. Ideges voltam, az állam még mindig egy kőre hasonlított, mégis kényszerítettem magam, hogy lassan menjek. Nem akartam, hogy ő észrevegye, követem. Abban biztos voltam, hogy azzal csak tovább rontom a helyzetet.

Tíz perc séta, ennyi kell, hogy elérjem a kétszintes családi házat, ahol a fiú lakott. Azt is tudtam, hogy az emeleten van a szobája. A szüleivel élt, akik az alsó szinten aludtak. Vajon a lányom hogy jut fel? Remélem nem akar egy feminista Júlia módjára egy fordított erkély jelenetet eljátszani. Leesik, eltöri kezét, lábát. De a gerincét is eltörheti! Lebénul és pelenkáznom kell élete végéig.

- Min vesztetek össze? - kérdezte apám, aki hirtelen ott sétált mellettem. Könnyedén tartotta a lépést velem, holott mindig lassan és megfontoltan lépkedett. A térdműtétje után pedig még megfontoltabbá vált.

- Szokásos, akar valamit és nem érti meg, hogy amit akar, az nem jó. Tudom, hogy nem jó, mert a Józsi lányával is pont ez volt, aztán terhes lett és hat ujja lett, miután megszületett... - és csak folyt belőlem a szó, összefüggéstelenül egyre lazább logikai kapcsolatokkal, de annál tágabb asszociációkkal. De ez is csak utólag tudatosult bennem. Akkor és ott nem. Akkor és ott a sok zagyvaság kristálytiszta dedukció volt. Apámat természetesen nem zavarta. Soha nem zavarta. Mindig türelmesen megvárta, míg kiapadt a mondanivalóm.

A lányomat annál inkább zavarta. Legtöbbször tudok uralkodni magamon. Erős érzelmi behatásra viszont előjön belőlem. A normális beszélgetéseknél észre sem lehet venni. De ha elkezdi mondani a terveit, rögtön felmegy bennem a pumpa. Elkezdek érvelni, miért ne csinálja, és akkor átszakad valami. Valami, amit igyekszek kordába tartani. Kibukkan belőlem, mint a szennyvíz csőtöréskor és onnantól már nem lehet elállítani. Ez az, amit a lányom nem bír elviselni. Ilyenkor elviharzik és hangos csattanással bevágja maga mögött a szobája ajtaját.

De ma más is történt. Nem a szobájába menekült, hanem el a lakásból.

- Most már érted, mit jelent szülőnek lenni - összegezte apám. Mindig csodáltam ezt a képességét. Nem volt magasan iskolázott, de mindig tisztán és röviden ki tudta fejezni magát.

- Tényleg ennyire nehéz?

- Még nehezebb - hamiskás mosoly bujkált az arcán, mintha én is csatlakoztam volna egy titkos klubbhoz.

Szép lassan megérkeztünk a házhoz. A mentők nem vonultak ki, tehát akár hogyan is jutott be a lányom, nem tört el semmilye. Az emeleten égett a villany, bizonyára épp most ecseteli, mennyire rossz apa vagyok. Az utcán volt egy pad, oda telepedtem le. Csak oldalról láttam rá az ablakra, csupán azt láttam, hogy ég-e a villany, vagy sem.

- Most mit fogsz tenni? - kérdezte apám.

- Bemegyek és leverem annak a gyökérnek a veséjét.

- A te vesédet sem verte le senki, mikor ennyi idős voltál.

- Az más volt, ő a feleségem lett.

- Honnan tudod, hogy nem fog hozzámenni?

- Ez csak egy zenész, semmit nem tud a világról.

- Mert te mindent tudtál? Úgy tűnik, még most sem nőtt be a fejed lágya. Itt ülsz a hidegben és velem beszélgetsz.

- Megnyugtat, ha veled beszélhetek.

- Attól még szedned kellene a gyógyszereket.

- Ha szedem, nem látlak - mondtam egészen halkan. Egy pillanatra úgy éreztem, egyedül ülök a padon és magamban beszélek. - Elvesztettem a feleségem, elvesztettelek téged.

Talán a hűvös szél tette, nem tudom, de éreztem, hogy egyedül vagyok. Összeszorítottam a szememet, kényszerítettem magam, hogy térjen vissza a látomás. Csak halványan hallottam a hangot, mintha víz alól jönne. Majd megismételte mondnandóját, és mire kimondta, már megint ott ült apám teljes valójában. Még azt is láttam, ahogy a szél borzolja őszes haját.

- Így a lányodat is el fogod veszíteni. Ő nem tudja, hogy problémáid vannak.

- Tanácsra van szükségem.

- Amit én adni tudok, azt te már mind tudod, mégsem fogadod meg, miközben elvárod, hogy a lányod azt tegye, amit mondasz.

- De ha nem mondom, mit tegyen, hibázni fog.

- Igen, hibázni fog. De abból az egy hibából többet tanul, mint egy óra prédikációból.

- Elszúrja a jövőjét!

- Ejj, ha a gyerek gyufát gyújt, valószínűbb, hogy a kezét égeti meg, mint, hogy felgyújtsa a házat.

- Ez nehéz. Látni, hogy fejjel megy a falnak, miközben ki is kerülhetné.

- Senki sem mondta, hogy könnyű. Egyébként csak egy hétvégét akarnak eltölteni a Balatonon, ettől nem lesz hat ujjú gyereke. Elég idős már, hogy megbízz benne.

- Túl fiatal, hogy tanács nélkül kiengedjem a világba. El fog tévedni. Port csempésznek az italába, elkábítják, kioperálják a veséjét és a szervkereskedőknek adják és ott lesz a nagy heg rajta, a ronda nagy heg... - és csak jött és jött belőlem a szóáradat. Amikor megindultak a könnyeim, a hangom motyogássá degradálódtak. Összeszorítottam az öklömet és ahogy a körmeim vésőként fúrták magukat bőrömbe, ismét kezdett kitisztulni a világ. A hűvös éjszakai szél felszárította könnyeimet. Apa már nem ült mellettem. Többet nem is fogom látni. Most tettem meg az első szükséges lépést.

Felálltam és hazamentem. Az út visszafelé hosszabbnak tűnt, mint idefelé. Aludni viszont nem tudtam. Bevettem a gyógyszert és vártam, hogy hasson. Leültem a konyhába és néztem maga elé, próbáltam gondolkodni, de csak ürességet éreztem. Nem kellett sokáig várnom, tíz perc telhtett el, amikor a zár lehelet lassan elfordult, majd jött a jól ismert csattanás, ahogy a rugó visszahúzza a zárnyelvet, majd hosszú másodpercekig nem történt semmi. Biztos azon gondolkodik, hogy ez a zaj felébresztett-e. Végül a kilincs is megmozdult.

Belépett és meglepődve nézett rám. Állán az izom kezdett megkeményedni, ahogy felkészült az újabb összecsapásra velem. Le sem tagadhatná, hogy az apja lánya.

- Hallottam, ahogy elmentél - kezdtem.

- Szükségem volt valakire, aki meghallgat - azzal a daccal nézett rám, ami a kíméletlen őszinteség forrása. Készen állt rá, hogy rám borítsa az egészet, és nagyobb fájdalmban részesítsen, mint az összes korábbi hazugságával egyszerre.

Meg kell tennem. Újra meg kell tennem az első lépést. Féltem, mert nem tudtam, mi lesz a reakciója. Féltem, mert ha belekezdek, többet nem lehet semmissé tenni. A földet bámultam, nem mertem a szemébe nézni, de mégis a zsebembe nyúltam és kitettem az asztalra a gyógyszeres fiolát.

- Az micsoda? - kérdezte.

Miután megtettem az első lépést, onnantól már ment minden könnyedén, mint hullámvasút, amit csak felvontatni nehéz.

- Vannak bizonyos problémáim - azzal elkezdtem mesélni mindent. Az első tüneteket, amiket a feleségem halála után vettem észre és a kitartó munkát, amivel emlékeimből és a halucinációkból újra teremtettem édesapámat. A beszélgetés során többször összegubancolódtak a mondatok, de a lányom gyengéden kibontotta őket. Gyerekké váltam, de ezt akkor egy cseppet sem bántam. Csend lett, én pedig vártam a szidalmat, vártam a feloldozást, vártam, mi lesz a lányom reakciója. Végül felnéztem egyenesen a szemébe.

- Jajj, apa - mondta enyhe megrovással, amikor végeztem.

A második generációs szekvenáló platformok read mérete kicsi. Önmagukban, az esetek döntő többségében, használhatatlanok. A szekvenálási módszerekre a referencia genom teszi fel a koronát. A vizsgálatok tehát annyira lesznek jók, amennyire a referencia genom.

Egy picit nézzük át a referencia genomok fejlődését a humán genomon keresztül! Kezdetben ez csak egy FASTA fájl volt, minden kromoszómáról egy kópiában tartalmazott megvétózhatatlan információt. Minden, ami egy kicsit is más volt, "mutáció", abnormalitás lett és elkezdték gyűjteni olyan adatbázisokba, mint amilyen a dbSNP. A bonyolult részeket N-el töltötték fel és bíztak a tudomány töretlen fejlődésében, hogy megoldja ezeket a problémákat. Mindenki boldog volt. Kivéve talán Ventert, akinek a referencia genomját nem akarta az egész világ használni.

Azután megindult az emberek szekvenálása. Egyre többet, egyre alaposabban szekvenáltak. A kezdeti N-el feltöltött lyukakat foltozták, de közben egyre több bizonyíték gyűlt össze, hogy a referencia genom bizony nem egy mindenkire alkalmazható séma. A variabilitás meglepő mértéket öltött. Nem csak "pötty" mutációk voltak (snpk, kis indelek), hanem kópia szám változások, genetikai átrendeződések. Rákos genomokat szekvenáltak, amelyek mintha mit sem törődtek volna a genom stabilitással. A read méretek még mindig szánalmasan kicsik voltak és bár az IBM böhöm gépeket akart eladni a rutin szintű de-novo assemblyhez, a tudós közösség továbbra is referenciához illesztett.

A szép, csodálatos referencia genom elkezdett szeplősödni. Először extra kontigok kerültek bele. Olyan szekvenciák, amelyekről gyanították, melyik kromoszómáról származnak, de pontos helyét nem ismerték. Aztán gyakori haplotípusok, mert a hipervariábilis régiókra rémálom volt az illesztés. Közben egyes mutációk gyakorisága megnövekedett és már nem tűntek olyan abnormálisnak, mint korábban. Bizony, bizony a referencia már nem volt olyan előnyös, mint annak idején. Már nem volt mindenki boldog.

Elkezdtek tehát olyan megoldásokat keresni, amikor nincs szükség referencia genomra. Hiszen egyes vizsgálatokhoz nem is volt kifejezetten szükség rá, csak arra, hogy megmondjuk a különbséget két minta között.

Az egyik ilyen program a RUFUS volt. Elsősorban trió adatok feldolgozására tervezték, de igazából bármilyen összehasonlító vizsgálatra alkalmas, akár tumor-normál mintákra is alkalmazható. Érzékenysége a szerző szerint megegyezik a GATK érzékenységével, de nem igényel olyan időigényes előkészítést, mint az, tehát a futási idő is rövidebb.

Hasonló ötlet húzódik meg a Salmon/Kallisto páros mögött is. (És itt kicsit kapcsolódunk a "Majdnem mindent az RNA-seq-ről" sorozatunkhoz is.) Differenciál expressziós vizsgálatoknál is csak az érdekel minket, milyen expressziós eltérések vannak a mintáink között. Mindkét program a nyers FASTQ fájlokon fut, elhagyhatjuk a referencia indexelését, és az illesztést. Alacsonyabb a memória igény, gyorsabban kapunk eredményeket. Én a Kallistot használtam egy olyan adatsoron, amit korábban TopHat/Cufflinks-el már feldolgoztam. Az igazság az, hogy az eredmények drasztikusan eltértek. Érdekes módon általában alacsonyabb readszámok jöttek ki Kallistoval.

Egy másik ötlet szerint nincs szükség a referencia eltávolítására, csupán egy modernebb köntösbe kell bújtatni azt, ami jobban megfelel a kor követelményeinek. A FASTA fájl helyett egy gráfot kellene használni. Ebbe aztán felvihetjük az alternatív szekvenciákat, mint amilyenek a haplotípusok, struktúrális átrendeződések. Az illesztés is átalakulna, mivel nem csak a legjobb útvonalat kellene megtalálni, hanem az eltéréseket is, mindezt egy diploid genomon. A gráfokról, mint számítógépes adatstruktúrákról tudni kell, hogy tárolásuk memória intenzív. A gráf bejárása NP-teljes, ezért hatékony indexelés kell. Szerencsére ilyen módszer már létezik (cikk), de a BWA teljesítményét nyújtó index két éve még 300GB tárhelyet igényelt. Ráadásul, míg a BWA referencia indexelése csak kis mértékben befolyásolja az illesztést, addig a gráf indexelés egy trade-off. A hatékonyabb indexel több találatunk lesz, de a tárhely igény növekedik. Kisebb indexel viszont találatokat fogunk veszteni.

Ígéretes kezdeményezés, de még messze van attól, hogy laptopunkra telepítsük és ráeresszünk több száz egy sejtes adatot.

Közben azt sem szabad elfelejteni, hogy a szekvenálás maga is változik. Annak idején poénnak szántam a humán genom szekvenálást MinION-al, de azóta ez komollyá vált. A cikk csak egy koncepciót vázolt fel, mert hatékony, Illumina-szintű eredményt nem értek el, ráadásuk a szükséges számítási teljesítmény egy kisebb intézmény igényeivel vetekedett, de az üzenet egyértelmű: meg lehet csinálni. Ugyan akkor a cikknek egy másik fontos üzenete is van: a jelenlegi formátumok és programok a rövid read méretre vannak szabva. Teljesen használhatatlanok lesznek ha széles körben elterjednek a harmadik generációs szekvenálási eljárások.

Akár így, akár úgy, de a hagyományos értelembe vett referencia szekvencia el fog tűnni. Jó volt a maga idejében, de szerepe az idővel egyre jobban háttérbe fog szorulni és végül elfoglalja méltó helyét az GCG, a CD-n terjesztett Blast adatbázis és a kézzel bepötyögött szekvencia fájlok mellett.

Jó estét, jó szurkolást minden kedves nézőnknek. Majdnem élőben jelentkezünk a 2018-as QBPartyról. Itt, a stúdióban ülünk kommentátór társammal, Néma Leventével. Levente, kérlek köszöntsd a nézőket!

Biccentett. Ezen is megvolt. Itt vagyunk már 11 óra óta a party helyszínén, de eddig nem sok mindent láttunk. A budapesti kontingens még nem érkezett meg. A teremben tapintani lehet az ürességet. Értik! Hahaha. Tapintani...az...ürességet...hahaha. Ahogy Levente arcára nézek, mintha nem osztaná mondatom komikus voltát.

Az előtérben ketten próbálgatnak egy C64-ből, egy meghatározhatatlan játékkonzolból és számtalan vezetékből összetákolt gitárt. Csak reménykedni tudunk, hogy ez egy nagyszerű bemutató előkészületei. Én legalábbis nagyon izgulok, míg Levente csak a szemét forgatja.

A hangulat egyébként remek, az alacsony látogatószám ellenére élénk beszélgetések zajlanak mindenhol. Spenót büszkén mutatja raytracelt gömbjeit, de elmondása szerint nem várhatunk releast tőle. Micsoda varjú, micsoda varjú. Értik! Kár. Hahaha. Jajj! Levente kollégám fejbe csapott egy összecsavart újsággal.

ÉÉÉÉs közben el is kezdődött a Combined Music Compo! Elsőre Teo adta meg az alaphangot egy jó kis zúzós számmal. Nem tudom, ti hogy vagytok vele, de nekem máris táncolhatnékom van. Utána mindjárt Nagz dübörögteti a hangszórókat. Mintha törzsi dobok lennének a ritmus alá keverve. Ennyi. Nincs több zene. Csalódott vagyok. Levente pókerarccal néz rám, de én biztos vagyok benne, hogy ő is csalódott.

Talán a grafika elűzi a csalódottságot. A kompó öt fényképpel kezdődött, amelyeket megszokhattunk már kis partikon: vicces, de inkább kínos. Érdemes megjegyezni, hogy az összes kép a partin készült, vagy az ide vezető úton.

Bobic képe volt az első átmenet a kattintás és alkotás fázisában, a fotót már Photoscape-pel módosították. Rascy képe volt az első, ami már grafikai munkát is tartalmazott, még ha csak nyomokban is. Aztán GeriJ rendere minőségi ugrást jelentett. Egy gyönyörű sportautót ábrázolt. Leon második bemutatott képe már C64 grafika, ahogy tőle elvárjuk. Dorcyy sci-fi témájú kézi rajza megmutatta, hogy nem csak fénnyel lehet képeket készíteni. Értitek! Fény képek. Aúú! Levente, honnan szedted azt a széklábat?

Most játsszunk egyet! Legalábbis a Game compo keretein belül. Az első a Drunk Wizard, egy Harry-Potter témájú flappy bird klón. A második egy autóverseny játék volt, szép, jó. A harmadikban az égből hulló mókusokat kellett láncfűrésszel szétvágni, miközben a két, egymás ellen játszó játékos egy gumikötéllel volt összekötve. Levente szája sarka aprót rángott, amit én egy mosolynak tudnék beazonosítani. Ez bezzeg tetszik neki!

A compok szünetében nézzünk ki a kerthelységbe, hogy lássunk mi zajlik odakint. Az öreg Amigások egy asztal köré sereglettek, isznak és közben a kilencvenes évek diszkó slágereit hallgatják. Szomorú látvány, hogy csak a régi ingerek éltetik őket. Egy olyan időutazásban vesznek részt, ahol a csak a testük halad a korral, ők maguk megálltak a kilencvenes években. Rázzák magukat ugyan azokra az ütemekre, amelyekre régen és rég elfeledett számokat pocskondiáznak, ahogy azt annak idején is tették.

Mások viszont láthatólag képesek haladni a korral. Poison két kis lurkóval érkezett. Üdvözli a régi arcokat, de nem felejti el, mi is a fontos.

Ha már végeztünk az old school arcokkal, nézzünk be az Old School compóba. Az első a Lethargy demója, Grass logójával. Nos, láttunk már jobb alkotást is. A második release a scrollerek népes táborát gyarapítja, de a kreatívabb fajtából. Majd egy Plus4 tracktro következik. Látszik rajta, hogy sok random részből rakták összes, de elég szeretet volt benne, amit a végén a credit is megerősített.

De itt az idő, hogy bevaduljunk, mert jön a Wild compó. Értitek! WÁÁÁÁÁÁJD. Levente, eltörted a karom azzal a baseball-utővel! Először egy mikrokontrollert láttunk, de csak scroller volt. Biztos többet is tudott volna a szerkezet. Másodiknak Musk magánelőadását kísérhettük figyelemmel, bevallom, mi itt a stúdióban nem értettük, miről van szó, mert a hangosítás torzított. A harmadik a jól ismert Minden Gargaj poén folytatása. Ez is olyan hagyomány már, mint a Rob is Jarig. A nézők annyira fellelkesültek, hogy szótagonként ismételték: min-den-Gar-gaj, ahogy a filmen látták. Az előtérben látott előkészületek a negyedik releasere értek be. Nem semmi volt! A tervezettnél hosszabb technikai szünet következett, majd jött a múlt években nagy sikert aratott Viti lézershow újabb fejezete. Ahogy hallom a közönséget, megérte minden perc várakozás.

De nincs megállás! A 256b intrók már itt toporognak az ajtóban, hogy a közönségre vessék magukat. Elsőként a kl nevű intrót láthattuk, ami sokkal fantáziadúsabb, mint a neve. A She egy 256 bájtos kép megjelenítő, sok zajjal. Mind a képen, mind a hangszóróban. A harmadik egy 32b-os zene volt. Levente ádámcsutkája kettőt liftezett. Mi tagadás, én is elérzékenyültem. Végezetül egy tűz effekt az Undefined Behaviortól.

Még be sem sötétedett, de már hívják az embereket a demókhoz. Először egy fekete-fehér demót nézhettünk meg Pasyék alkotóműhelyéből. Csak nem az Adjective monopóliumát irigyelték meg az érthetetlen demók terén? Nem ez hozza el a trónfosztást, az biztos. A Tesco Gazdaságos Demócsapat sem tétlenkedett. Az előbb említett Adjective azzal okozott meglepetést, hogy nem elvont, bonyolult művészi alkotást hozott, hanem egy demót. Mi történt, kérem? Mégis, hogyan skatulyázzuk be a demócsapatokat, ha így váltogatják a stílusokat? Végére maradt két demó, aminek nem Nagz szerezte a zenéjét. Az első az Air a Dilemmatól. Nagyon szépen összeszedett kis alkotás, meg kell hagyni. A zene is nagyszerű. Talán még a kompót is megnyerik. Végezetül a szivárványok csaptak össze, ahogy SlySpytól megszoktuk. A Rainbow Clash ismét nem maradhatott el a címből.

Búcsúzunk nézőinktől, akik velünk együtt izgulhatták végig ezt a remek partyt. Kiváló hangulat, remek szervezés és végtelen jókedv. Ezzel jellemezhetném az eseményt. Az utolsó poéntól megkímélem a hallgatóságot, mert Levente az asztalra tett egy Magnumot. Nem akarom, hogy a célozgatásból célra tartás legyen, ha értik, mire gond...