Az élet kódjai

Egy időben a prog.hu fórumon minden tejfeles szájú operációs rendszert akart írni, amihez csapatot toborzott. Ez alól természetesen én sem voltam kivétel. Utólag visszanézve ezeknek a kezdeményezéseknek a 99%-a elenyészett, a maradék egy százalék pedig egy poros CD tokban hever valahol a warez filmek mellett. De mégis, honnan szerezhet ehhez megfelelő tudást valaki?

A válasz Andrew S. Tanenbaum könyvében keresendő, aki oktatási céllal készített egy operációs rendszert, a Minixet. Az egyetem alatt az akkor még 10 floppy lemezt kitevő rendszert felraktam egy 386-osra, és azon tanultam meg a Unix alapjait.

A rendszer azóta sokat fejlődött, újabb szolgáltatásokkal bővült, ezért itt az ideje, hogy megnézzük, mennyire használható egy 20 éves laptopon.

Bár a floppys telepítés még elérhető, én mégis a CD verziót választottam. A telepítés simán ment, viszont a telepítés utáni teendőket manuálisan kell végrehajtani. Például, ha új felhasználót hozunk létre, akkor a home könyvtár root tulajdonú, nekünk kell beállítani. A támogatott hardverek száma kevés, még magyar billentyűzet kiosztás sincs alapból. Internet támogatás van, de csak minimális számú hálókártyához.

Viszont meglepően sok csomag található a rendszerhez. Sokan, akiknek csak egy minimalista webkiszolgáló kell, Minixet használ, ezért van Apache, Python (igaz, csak 2.7 verzió), PHP. Sőt, X kiszolgáló is van! A programok nagy részét csak neten keresztül lehet telepíteni, de a csomagkezelő erről az FTP szerverről szerzi be a szükséges fájlokat. Elméletileg ezek CD-re írva is telepíthetőek, ezt ki is fogom próbálni.

Pár csomag elérhető a telepítő CD-n is, mint a C fordító, Python, Perl. Ezekkel már lehet kezdeni valamit, aki nagyon elhivatott. Nekem egy hello world szintű program telepítése is gondot okozott. Először, mert nem találtam a magyar billentyűzeten olyan fontos karaktereket, mint a #. Utána az ld-t hiányolta a fordító.

Apropó fordítás! GCC nincs, helyette az LLVM-el kell beérni, és mint említettem, Pythonból is csak az elvault verzió érhető el.

A rendszer nálam stabilan működött, de üresen is elég sok erőforrást vett el. A top szerint az 500 MHz-es CPU 50%-on pörgött. A fórumok tanúsága szerint nem ez a fő prioritás, hiszen egy oktatási céllal készült operációs rendszerről van szó. Ha a gépem netre tudnám kötni, valószínűleg jobban kihasználhattam volna a rendszer lehetőségeit.

Elsősorban azoknak jelenthet alternatívát, akik meg akarják tanulni a Unix környezetet, vagy a rendszer programozást.

Eddig elég sok negatív dolgot írtam az intézeti rendszergazdákról. Álmomban sem gondoltam volna, hogy egyszer egyikük megoldja egy problémámat. Pedig most pontosan ez történt!

Elkészültem a programmal, aminek az lenne a szerepe, hogy koherenciát csempésszen abba a kaotikus világba, amit úgy hívnak pályázati adminisztráció. A program egy lokális adatbázist használ, aminek az a feladata, hogy megkönnyítse az életemet, de ezt valami Microsoftos mellékízzel teszi.

A fejlesztői gépen egy Visual Studio 2015 volt, adatbázis kezelőnek pedig egy SQL Server 2012. A program elkészülte után megpróbáltam a Publish menüponttal egy telepítőbe tuszkolni mindent, de elsőre nem sikerült. Mint megtudtam, alapértelmezetten nem rak bele minden szükséges komponenst a telepítőbe. Miután kiválogattam, hogy a PDB fájlokat, DLL-eket is tegye mellé, akkor már használható lett az eredmény.

Gondoltam kipróbálom a telepítőt a feleségem gépén is, mert azon nincs fent a több giga Visual Studio, közelebb áll az adminisztrátor konfigurációjához, aki majd használni fogja a programot. Ekkor szembesültem vele, hogy a futtatáshoz kell egy .Net Framework, és egy SQL Server LocalDB.

Szerencsére be lehet állítani, hogy milyen függőségei vannak a programomnak, és azokat a telepítő próbálja meg letölteni. A .Nettel még nem is volt probléma, de a LocalDB nem akart települni. Illetve települt, de utána hibaüzenetet adott, a kész program meg kivételeket dobott, hogy a szervert nem találja.

A Stackoverflow szerint a baj az volt, hogy a letölteni kívánt függőség megváltozott ahhoz a verzióhoz képest, amivel fejlesztettem. Ezt én nem értettem. Hogyan tudna megváltozni egy több, mint nyolc éves program?

Közben a programot egyre inkább használni akarták, én meg kapcsolatba kerültem egy fertőzött emberrel, amitől az intézet vezetősége kitiltott. Kénytelen voltam a telepítést az intézet rendszergazdáira, azon belül is Pan-ra bízni. Mondanom sem kell, ő sem jutott közelebb a megoldáshoz.

Ezért készítettem még egy telepítőt, de most azt állítottam be, hogy ne töltse le a komponenst, hanem csapja a programom mellé. Erre több, mint nyolc hibaüzenetet dobott, hogy neki azok nincsenek meg. A Microsoft dokumentációja szerint nekem kell letölteni azt a komponenst, aminek az URL-je ott van a Visual Studio könyvtárhierarchiájának mélyén, és amelyiket a programom telepítésekor le is tud tölteni.

Rendben, akkor letöltöm én. A dokumentáció arra viszont nem tért ki, hogy mind a 32 bites, mint a 64 bites verziót le kell tölteni, és elhelyezni az XML-ek mellett x86, illetve x64 alkönyvtárakban, és akkor a Visual Studio mellékelni tudja. A telepítő már több száz megabájtra duzzadt.

Ez sem jött be. Azt a hibaüzenetet kaptuk, hogy "...SQL Network Interfaces, error: 50...". Ezt sem tudtam értelmezni, mert nem használtam hálózatot, lokális adatbázist adtam meg kapcsolatként. Közben Pan kiderítette, hogy hiába lesz telepítve az SQL Server, a program képtelen lesz használni az adatbázist, kivéve, ha előtte az SqlLocalDB parancssoros eszközzel létre nem hozzuk az adatbázis bejegyzést. Mi van? Nem ezért van a telepítő? Nem az lenne a feladata, hogy a felhasználónak ne kelljen parancssorban bogarászni?

Egyébként ez a OneClick telepítő megérne egy külön bejegyzést. Fogja az elkészített programot, és kérdés nélkül elrejti a felhasználó AppData könyvtárának a bugyraiba, olyan intuitív elnevezésekkel, mint 8342-12312-74. Mikor megkaptam a hibaüzenetet, győztem megkeresni a program helyét.

Hanem, amikor elkészült az adatbázis bejegyzés, települt az SQL Server, még mindig nem lehetett használni a programot. Nem stimmelt az SQL Server verziószáma! Ekkor tudtam meg, hogy három féle verziószáma van a programnak. Van egy, amit mi, halandók használunk: SQL Server 2012, van egy belső adatbázis verzió, ami 706, és van még egy verziószám, amit akkor ír ki, ha parancssorban turkálunk benne, ami V11. Tényleg szükség van minderre? A hibaüzenet szerint, nekem 852-es adatbázisra van szükségem. A táblázat alapján ez SQL Server 2016!

Mikor Pan először kezdett beszélni nekem arról, hogy a programom a 2016-os adatbázist vár, azt hittem túl sokat ivott. Hiszen nekem SQL Server 2012-m van. Csak tudom, mi van a gépemen, még a Visual Studio is kilistázza nekem az elérhető szoftver komponenseket, és ott csak a 2012 szerepel.

Azért megnéztem, mi van a gépemre telepítve. Legnagyobb meglepetésemre volt SQL Server 2008, 2012, 2016 is. Amikor elkezdtem használni a LocalDB-t, ott valahogy a 2016-t kezdte el használni, bár nem emlékszem, hogy felajánlotta volna, melyik verziót akarom használni. A Visual Studio OneClick telepítője viszont csak a 2012-t ajánlja fel, mint telepíthető függőséget.

Hanem ekkor még nem volt vége. Pan hiába rakta fel a 2016-os verziót a célgépre, az még mindig nem működött. Ugyanis ez a szemét SQL Server képes különböző verziókat egy helyen tárolni. Mikor Pan 2012-es verziójú adatbázist hozott létre a 2016-os SQL Serverben, akkor a programom még mindig nem működött. Amint rájött erre, és javította, azonnal futott minden.

Mindig is tudtam, hogy nem értek a Windows-hoz, de azt hittem képes vagyok megoldani bármilyen problémát. Itt viszont semmi nem az volt, aminek látszott. Teljesen érthetetlenek számomra a telepítő készítés logikája, az opciók, az alapérelmezett beállítások. Semmit mondó hibaüzenetek és szürreális megoldások. Pan mégis átlátta az egészet és végigevickélt rajta. Egy rossz szavam sem lehet rá ezután.

Emberek veszítik el szeretteiket, munkanélküliség, sosem látott gazdasági recesszió. túlterhelt kórházak, szükségállapot, kijárási tilalom több országban. Mindeközben mit csinálnak a demoscenerek? Természetesen partit tartanak, és buliznak.

Sokáig úgy tűnt, hogy a demó partik gerincét képező Revision bedobja a törölközőt, és elmarad, de a kockákat egy világjárvány nem állítja meg. Amíg áram és net van, addig parti is lesz. Csak kicsit máshogy.

Az otthonunk ugyanis már nem csak munkahely, iskola, mozi, edzőterem, hanem immár egy demó parti helyszíne is. Ami azt jelenti, hogy igazából egyik sem teljesen, ami kihat az élményre. Például ha a fotó kompó egybe esik az esti fürdetéssel, akkor az eredmény, hogy egyik sem sikerül igazán.

Én két dologgal készültem. Az egyik egy fotó volt, amit nem adtak le, a másik egy videó, ahol nem volt kép. De ezzel egy kicsit előre szaladtam.

Tehát kezdjük az elején. Egy héttel Revision előtt eszembe jutott, hogy akár csinálhatnék is valamit. Futtatható stuff szóba sem jöhetett, de a szokásos videó+fotó kombináció kivitelezhetőnek tűnt. Találtam egy félig használható zenét Shamen tíz éves CD-jén. Azért mondom, hogy félig használható, mert egészen jól indult, de három perc után témát váltott. Mivel a korábbi videómnál is az volt a legfőbb kritika, hogy túl hosszú, ezért itt elvágtam a zenét, hogy teljesen használható legyen.

Három nap alatt össze is vágtam az anyagot és feltöltöttem. Egy ponton nagyon aggódtam, mikor kérték a zeneszerző lakcímét. Ezt nem tudtam, de nélküle nem engedték feltölteni a cuccot. Végül beírtam valamit, majd jeleztem a szervezőknek, hogy mit tettem.

A fotóra egy 360 fokos kamera képét választottam. Bevallom, nem számítottam semmi galibára, de tudtam, hogy nem egy égbekiáltó eredmény.

A szombati kompók este 6-kor kezdődtek. A fotók egy része nagyon jó volt, de azt nem értettem, ha előválogatás volt, akkor a szőnyegről készült kép miért maradt benne? Végül is mindegy, de azért elkeseredtem egy kicsit. Az animációknál sem lett jobb kedvem. Nosfe ismét egy zajdemót adott be, és én első alkalommal örültem neki, hogy otthonról nézhetem ezt a rettenetet, és közel a hangerő szabályozó.

Majd jött az én entry-m, de a streamen csak valami feketeség látszott. Egyesek szerint még így is jobb volt, mint a zajdemó, de ez nem sok vigaszt jelentett. Majdnem fél perc lement, én meg úgy éreztem magam, mint 2010-ben, bár akkor hang nem volt. Szerencsére leállították a vetítést és elkezdték előről, de addigra annyira elment a kedvem mindentől, hogy tovább már nem is néztem, inkább olvastam.

Másnap azért ránéztem a streamre. A 8K elég vérszegény volt. A feltöltött alkotások böngészése közben még nekem is feltűnt, Jézus milyen aktív volt. Időről-időre feltűnik egy feltűnési viszketegségtől szenvedő valaki, aki a pocsék releaseket azzal ellensúlyozza, hogy egy ideológia mögé bújik. Ilyen volt annak idején a Horror Terror Elite Legion, most meg a Love Jesus.

Aztán elkezdődtek az Amiga demók. Igazából a vége felé elég hangulatos alkotások voltak, de nem ültem a székem mellé. Amit nagyon sajnáltam, az a Titan demó. Olyan ígéretesen indult, aztán ellaposodott.

A PC demók jó része valami keretrendszerrel készült. Még Godot is volt. A legrosszabb mégis az volt, hogy szinte lehetett látni, mely alkotások készültek saját motorral. Még a Unity demók is, amelyek öt éve még tehetség pótlásnak számítottak, olyan minőségű eredményt produkálnak, hogy csak nézek.

Nem tudom, mit is gondoljak az idei Revision-ről. Egyrészt jó, hogy a szervezők nem adták fel, és sikerült valamit összehozniuk. Nem látok a színfalak mögé, de szerintem elhivatottság kell ahhoz, hogy úgy is végrehajtsák az emberek a feladatukat, hogy nem felügyelik őket. Másrészt nem tudtam rákoncentrálni a compókra, annyi minden történt.

Egyik demópartin, mikor megkérdeztem valakit, hogy miért nem csinált produkciót, a következő válaszolta:

- Most real-ben nyomtam, nem volt időm molyolni.

A beszélgetés alakulása közben vált világossá számomra, hogy a mindennapi élet viszontagságai a "real", és nem az észlelt valóság. Egy pillanatra ha elfelejtjük a képzavart, egyet érthetünk, hogy néha fel kell kötni a gatyát, ha úgy akarunk véghez vinni valamit, hogy közben más frontról érkező támadásokat is vissza kell vernünk. Mint történt a most bemutatásra kerülő cikkünknél is.

Az első bonyodalmat a csapat bioinformatikusának eltűnése jelentette. Elhagyta az országot és beszüntette a kommunikáció minden formáját. Illetve az elején még egy-két hét csúszással válaszolt, majd a csúszások csak hosszabbodtak, hosszabbodtak, míg végül a végtelenhez nem kezdtek tartani.

Én vettem át a helyét és szomorúan tapasztaltam, hogy még a szekvenciák jó részét is magával vitte, hogy majd "dolgozzon" rajtuk. Néhány hibásan elnevezett szekvencián kívül nem sok maradt, no meg az ábrák, amelyeket valahogy elkészített. Jegyzőkönyv nélkül nehéz volt bármit is kiokoskodni.

Mikor beszálltam a projektbe, először az elkészült kéziratot kellett megnéznem, hogy azok elég részletesek-e, helytállóak-e a következtetések. Mivel ez is egy leíró jellegű cikk volt, elég hamar elvesztettem az érdeklődésemet. Pár választ odafirkantottam a kézirat szélére és letudtam.

Ilyen könnyen nem úsztam meg. Szépen, finoman megkértek, hogy nézzem át még egyszer. Még egyszer átnéztem, de továbbra is egy leíró jellegű cikk volt. A kéziratban szerepelt négy kladogram Salmonella törzsekkel. Az első a teljes genomok alapján készült. A második a központi gének alapján. Volt egy, ami az egyedi géneket vette alapul, végül egy, ami a genomi szigetek viszonyait tükrözte. A kladogrammok teljesen különböztek egymástól, nem mutattak sem időbeni csoportosulást, sem földrajzi izolációt. Négy teljesen különböző reláció volt.

A szöveg is ezt tükrözte. Mindegyik kladogrammról volt egy fejezet, és leírta, hogy ott mit lehet látni. Nem értettem, mi a célja a publikációnak, miért készült, miért kell ennyi különböző módszert belevenni, ami semmi érdemi konklúziót nem tartalmaz.

Ezért tartottunk egy megbeszélést, ahol felvilágosítottak a dolgok hátteréről. Megjelent ugyanis egy cikk, ahol európai Salmonella törzseket vizsgáltak, majd a cikk zárásaként levonták azt a következtetést, hogy a svájci törzsek magyar eredetűek, sőt egész Európát magyar Salmonella törzsek fertőztek be. Következtetésként mindenért mi vagyunk a hibásak.

Ezen néhányan nagyon felhúzták magukat. Egyesek odáig mentek, hogy olyan kijelentéseket tettek, miszerint "Magyarország támadás alatt áll". Eleinte jól is hangzott, hogy az országot az én kis számítógépem védi meg a gonosz felforgató elemektől, valahogy úgy, ahogy affektáló Hujber Ferenc is tette a katonai hírszerzés hackereként. A megbeszélés további részeként szidtuk a svájciak anyját, apját, az editort, aki átengedte a cikket, meg a bírálókat.

Tehát a cikk igazi célja az volt, hogy bebizonyítsuk, a svájci törzsek nem magyar eredetűek. Ezért volt a számtalan módszerrel elkészített fa. Bármelyiket is néztük, a két ország törzsei messze voltak egymástól. Ráadásul mi több törzset használtunk fel, aminek az egyik következménye az lett, hogy szerológiailag Salmonella Infantisnak tartott törzsekről kiderült, genetikailag semmi közük az Infantisokhoz.

Az első feladat az volt, hogy elő tudom-e állítani az ábrákat, a rendelkezésre álló adatokból. A teljes genomok szekvencia fájljai megvoltak, de az hiányzott, hogy mely géneket tekintették központinak, és melyeket egyénieknek. A genomi szigetekről nem is beszélve.

Itt tennék egy kis kitérőt. Ha fogunk egy csomó baktérium törzset, lesznek gének, amelyek minden törzsben előfordulnak, és lesznek, amelyek csak a törzsek egy részére jellemzőek. Tehát minden gén kaphat egy százalékos értéket, hogy a törzsek mekkora hányadában fordul elő. A központi, vagy core gének, amelyek a törzsek 90%-ban előfordulnak, míg az egyedi, vagy cloud gének csak maximum 10%-ban. Ezek a meghatározások igen képlékenyek, mert nem csak a százalékos határok szubjektívek, hanem az is, mikor tekintünk hasonlónak két gént. Melyik az a százalékos határvonal, amikor azt állíthatjuk, hogy a gének szekvenciái egyformák?

Sőt, van még egy probléma, ha már így belemerültünk a baktérium genomok elemzésébe. Ha csak a genomhoz feltöltött annotációt nézzük, akkor nem találunk meg mindent gént. Ugyan annak a génnek egy másik törzsben  másik neve lesz. Ezt úgy oldottuk meg, hogy minden baktérium genomot újra annotáltunk egységes módon.

A helyzetet tovább bonyolította, hogy a fák alapját képező többszörös illesztést két különböző módon is el lehet készíteni. Fogom a gének szekvenciáit és összefűzöm őket egyetlen virtuális szekvenciává (ezt a módszert követték a svájciak), vagy nem fűzöm össze, és a Mauve-ra bízom, hogy megoldja a problémát. Mondanom sem kell, két teljesen különböző eredményt kapunk.

Mivel a teljes genomok alapján készített fák megegyeztek azzal, amit én készítettem, feltételeztük, hogy a többi fa is ugyan olyan lenne, ha meglennének a szekvenciák. Úgy gondoltuk, a módszer reprodukálható.

Sajnos az összes képet módosítani kellett, mert a nevezék nem tetszett a csapatnak, más betűtípust akartak és módosítani akarták a kiemeléseket is. Mivel nem tudtam újra előállítani a képeket, kénytelen voltam Gimp-el átrajzolni a már meglévő ábrákat. Ez egy rendkívül unalmas meló. Már nem éreztem magam szuper hekkernek, csak egy szerencsétlen flótásnak, akinek hülye feladat jutott. Magyarország becsületének védelme egy grafikus programon múlik.

Igazából letölthettem volna a szekvenciákat, és elkészíthettem volna újra a fákat, de a többszörös illesztések több napot vettek volna igénybe, míg a Gimp-el egy óra alatt megvoltam. Mivel tapasztalatom szerint az ábrákkal mindig akad pepecselni való, ezért előrelátó módon a feliratokat külön rétegekbe raktam. Ezért a második, harmadik, sokadik módosítás már könnyen ment.

Ahogy teltek az idők, a kézirat gyökeresen megváltozott. A szerkezete megmaradt, továbbra is különböző módszerekkel elkészített fák voltak benne, de ezek kezdtek egy egységes koncepció köré csoportosulni. Az ábrák is egységes stílust kaptak. Összeállt az anyag. Tartottunk egy utolsó megbeszélést, ahol ismét elszidtuk a svájciak anyját mindennek, lehülyéztük őket, mindezt olyan magas röptű stílusban, ahogy csak az akadémiai szférában lehetséges.

December 24-én kaptuk meg a bírálók anyagát. Azt szerették volna, ha több törzset veszünk be a vizsgálatokba és megnézzük az antibiotikum rezisztencia géneket is. Eredetileg ezt nem akartuk, de ezek után kénytelenek voltunk ezt is megcsinálni. Egyedül a határidővel volt probléma, mert egy hónapot adtak minderre, ami figyelembe véve az Ünnepeket, tarthatatlannak bizonyult. Rögtön halasztást kértünk, amit meg is kaptunk.

Közben újabb bonyodalom történt, az egyik szerző balesetet szenvedett, így az ő segítségét nélkülözni kellett.

Letöltöttem az új baktérium szekvenciákat, hozzácsaptam a korábbi genomokhoz, amelyekkel korábban dolgoztam és elkezdtem az elejéről mindent. Most már meg kellett csinálni az összes illesztést, annotálást. Már nem volt elég Gimpezni. De a sok munka mellett volt ennek egy előnye is: Nem kellett a régi ábrákra, elnevezésekre támaszkodni, ezért minden szekvencia, annotáció, kép, egységes nevezéket kapott. A szekvencia fájl neve, azonosítója ugyan az lett, később ez a név jelent meg a fákon is. Ezzel eléggé fel tudtam gyorsítani a munkát.

Ennek során megszegtem az egyik elvemet, miszerint nem használok szóközt fájlnevekben, de azt hittem sokkal egyszerűbb lesz a munka. A munkafolyamat nagy részén igazam is volt, a dolog akkor bukott meg, mikor a Roary képtelen volt azokat a fájlokat beolvasni, amelyek szóközt tartalmaztak. Ezt leszámítva, nem volt fennakadás, a neveket végig lehetett követni a munkafolyamat teljes hosszán.

Azért aggódtunk egy kicsit, hiszen említettem, hogy a központi és egyedi gének meghatározása elég szubjektív. Félő volt, hogy eltérő eredményt kapunk, és az egész diszkussziót új alapokra kell helyeznünk. Szerencsére az új fák nagyon hasonlóak lettek, csupán több törzset tartalmaztak. A svájci-magyar kapcsolat továbbra sem tűnt valószínűnek.

Tartottunk egy megbeszélést, ahol megvitattuk az új eredményeket. A vége felé ismét szóba került a svájciak anyaja, apja, és konstatáltuk, hogy a bírálók (akik bizonyára svájci szimpatizánsok) terve nem jött be, nem tudnak megállítani minket. Már csak az antibiotikum rezisztencia rész volt vissza, de abban nekem nem volt szerepem. Még az ábrák végső formáját sem kellett megcsinálnom, aminek örültem.

Hanem, az antibiotikum rezisztencia kapcsán az egyik szerző észrevette, hogy a magyar törzsekből hiányzik néhány olyan gén, amelyek létezéséről egy korábbi publikációban írtunk. Kiderült, hogy a magyar törzsek szekvenciái hiányosak. Néhány kontig hiányzott ahhoz képest, mint ahogy annak idején feltöltöttem az NCBI-ba.

A helyzet az, hogy a munka legelején, mikor átvettem a volt kolléga fájljait, nem ellenőriztem teljesen a szekvenciákat az NCBI-ban található verziókhoz képest, csak megnéztem, mekkora a fájlok mérete, az meg nagyjából stimmelt, nem foglalkoztam a dologgal. Ez elég súlyos hiba volt a részemről, még szerencse, hogy nem a bírálók vették észre. Tehát még egyszer letöltöttem mindent, összeraktam a genomokat, annotáltam őket, felépítettem a fát. Viszont ez már koránt sem volt akkora munka, mint korábban, mert Jupyterben volt a teljes elemzés, dokumentálva minden lépés. (Mikor az egyik bíráló arról beszélt, hogy a módszerünk nem megismételhető, akkor megkapta a linket.) Csupán kicseréltem a szekvenciákat egy könyvtárban, és mondtam, hogy futtasson le mindent.

Viszont az eredmények láttán majdnem hagyatt estünk. A svájci és magyar törzsek minden egyes elemzésben szépen együtt klasztereződtek. Egészen pontosan a magyar törzsek két csoportra oszlottak, az izolálás idejétől függően, és az újabb izolátumok tényleg a svájciakkal egy csoportba kerültek.

A csapat becsületére legyen mondva, ezután nem szidtuk a svájciak anyját, hanem elfogadtuk az eredményeket. Ezekért a pillanatokért szeretem a tudományt, amikor nem a prekoncepció, az érdekek alapján vonunk le következtetést, hanem a színtiszta adatok alapján. Nem próbálták rám erőltetni, hogy "használjunk másik programot", "másik statisztikát". Nem volt vádaskodás, hogy "biztos elszúrtad", "ez nem lehet". Át kellett írni mindent és a csapat ezt professzionálisan meg is tette. Elküldtünk mindent, mire meg is jött a válasz, hogy a bírálók mindent rendben találtak. Hurrá!

Hanem a befektetett munka miatt a szerzők sorrendje megváltozott. Emiatt mindenkitől beleegyező nyilatkozat kellett, hogy ehhez hozzájárul. Attól a bioinformatikustól is, aki beszüntette a kommunikációt. Ekkor felmerült a lehetőség, hogy ha nem érkezik válasz tőle, akkor kihagyjuk a cikkből. Ez nekem nagyon nem tetszett. Én sem szeretem, ha engem hagynak ki, ezért ahol lehetett védtem az érdekeit.

Ezzel sikerült is jól magamra haragítani pár embert. Ha ugyanis ki akartunk volna hagyni valakit, akkor a cikket vissza kellett volna vonni, majd újra beadni a módosított szerzőkkel. Kezdhettünk volna a teljes procedúrát előről. Ezért azt javasoltam, hogy mi lenne, ha mégsem változtatnánk meg a szerzők sorrendjét. Nekem estek, hogy miért védem azt, aki "ennyire hátráltatta a cikk megjelenését", meg "miért nem képes válaszolni".

Csak halkan jegyzem meg, hogy aki a leghangosabb volt, az egy korábbi cikkünknél szintén hátráltatta egy évig a publikálást, mert családi zűrjei voltak. Elég gyorsan elfelejtette ezt.

Egyébként csupán pragmatikus célok vezettek, hiszen ha vissza kell vonni a cikket és újra beadni, akár az is megeshet, hogy az új bírálók elkaszálják a cikket, és az mindenkinek rossz lesz. De mások ezt nem látták, nekik fontosabb, hogy első szerzők legyenek. (Nekem nem fontos, meg is látszik :-)

Szerencsére az elveszett munkatárs végül válaszolt, és nem kellett drasztikus dolgokhoz folyamodni. Aztán elért minket is a világjárvány, a cikk utolsó simitásait már otthonról végeztük.

Ennek a munkának rengeteg tanúsága volt számomra. Először is, ahogy Richard Marcinko is megmondta: Soha ne feltételezz! Ha kapsz egy fájlt, nem feltételezed, hogy jó. Ha látsz egy ábrát, de semmi leírást róla, akkor nem gondolod, hogy "biztos X-el készült". Második tanúság: Ha valamit rendesen is meg lehet csinálni, akkor úgy csináld, még akkor is, ha ez több időt vesz igénybe. Ha mindjárt az elején vettem volna a fáradságot, hogy rendesen elnevezem a fájlokat, elkészítem a munkafolyamatot, akkor megkíméltem volna magam egy csomó Gimp-es bohóckodástól. Végül pedig felejtsük el a prekoncepciókat. Itt mi meg is tettük, de mikor először megláttam az új eredményeket, féltem, hogy nagy veszekedés lesz miatta. Szerencsére a genetikai eredményeket a tőlem függetlenül végzett antibiotikum rezisztencia vizsgálatok gyönyörűen alátámasztották.

Az Enterprise 128 régóta egy vágyálom számomra. Gyerekként a gépeket nem fejlesztettük, hanem újab vettünk. Ezért az egészséges versenyszellem keretében nem azzal fejeztük ki felsőbbrendűségünket, hogy semmitmondó processzor paraméterekkel dobálóztunk, hanem félig lehunyt szemmel kimondtuk gépünk nevét.

Ebben a - mai szemmel nézve nevetséges - versenyben a legtöbb gép 64 kilobyte memóriával volt ellátva. A következő nagy ugrás a 128 kilobyte-os gépek voltak. A C128 és az Enterprise. Az Amiga már akkor is a király kategória volt, azok nem versenyeztek mikroszámítógépekkel, hanem különböző bővítő kártyákkal felvértezve egymással mérték össze erejüket.

Én erről akkor semmit sem tudtam. Nem jártam klubbházakba, copy partikra. Számomra az informatika fejlődéséről egy műszaki bizományi kirakata adott felvilágosítást, ahol az elérhető legjobb gép az Enterprise volt. Szép, színes gombjai voltak, beépített joystick, sztereo hang, és nem utolsó sorban 256 szín. Hazafelé az iskolából mindig megálltam a kirakat előtt és megnéztem a gépet. Aztán a gépet eladták, én meg még évekig játszottam a C64-el, majd jöttek a PC-k. Az Enterprise feledésbe merült.

Mikor megismerkedtem a demoscene-vel, ahol nem nézik hülyének az embert, mert használhatatlan gépeket programoznak, ismét felrémlett bennem, hogy akár még szerezhetnék is egy ilyen gépet. Az idők viszont megváltoztak, gyakran tetemes pénzt kérnek el ezekért a gépekért, mert retro. (Ez a retro őrület azért kicsit túlmegy a józan ész határain. A legdurvább eset ezzel kapcsolatban, mikor egy bolhapiacon ezer forintot akartak elkérni egy kicsi, koszos gumilabdáért, mondván, hogy ez nem gyerekeknek van itt, hanem gyűjtőknek.)

Nem akartam egy fél vagyont egy Enterprise-ra költeni, amit még a maga idejében sem vásároltak, miközben Grass azzal dicsekszik nekem, hogy valami ócskásnál ötezerért talált egyet. (Ilyenkor bezzeg nem gondol rám.) Ezért csak különösebb cél nélkül böngésztem a különböző weboldalakat, eredménytelenül.

Azért néha nekem is lehet szerencsém. Találtam egyet, ami ha nem is ötezer volt, de az a kategória, amire azt mondtam, hogy "egye fene". (A feleségem inkább megrökönyödött, hogy milyen hülyeségeket vásárolok, de ez egy másik kérdés.) Így lettem egy Enterprise boldog tulajdonosa.

Azért a gépről igencsak hiányos ismereteim voltak, ami rögtön meg is mutatkozott, mikor kibontottam a csomagot. Először is, nincs rajta bekapcsoló gomb! Mintha nem is számítógép lenne, hanem egy hűtőszekrény, vagy vasaló. Szinte nincsenek is rajta csatlakozók, csak kivezetések az alaplapról.

Azt sem tudtam, hogy a gép kétféle billentyűzet kiosztással került forgalomba. Egy némettel és egy angollal. Természetesen németet vettem, német hibaüzenetekkel. (Később tanultam meg átállítani angolra.) Azt sem értettem, mit ír ki a gép. Ha már a billentyűzetnél tartunk, az valami katasztrófa. Egyszer régen vettem egy összehajtható gumi billentyűzetet, mondván az milyen menő, de használni valami borzalmas volt. Az Enterprise billentyűzete még ennél is rosszabb. Egyáltalán nem kényelmes, szenvedés használni. A 10 print "hello", 20 goto 10 program megírása itt volt a leglassabb.

Először be sem tudtam kapcsolni. Kaptam hozzá egy SCART csatlakozót, amit ha beköttöttem, és még a magnót is rákapcsoltam, nem volt képe. Ha nem kötöttem be a magnót, akkor halványan felderengett a gép képe. Kétszázötvenhat szín? Egy színt láttam, 5 árnyalatban.

Végül maradt az RF csatlakozó, mert úgy bejöttek a színek. A kazettáról a cikk megjenéséig még nem sikerült betölteni semmit, mert a betöltésnél a hangerő szabályozó állása nem mindegy milyen szinten áll. Ezt a képernyő tetején egy szines csíknak kellene jeleznie, ha a hangerő megfelelő.

Ennyit a negatívumokról. Lássuk, melyek az értékek. Először is, a BASIC értelmező egy kis dobozban, külön kapott helyet a gép oldalában. Ez hallatlanul jó ötlet. C64-en nekem nagy fájdalmam volt, hogy közönséges BASIC-ből nem lehet elérni a grafikát. Volt ugye a Simon's Basic, ami orvosolta ezt a problémát, de ha azt is betöltöttük, újabb értékes memóriát vesztettünk. Enterprise alatt erről szó sincs. Az egyetlen probléma, hogy a gép ezen tulajdonságát nem használták ki annak idején. A modern kor felhasználói azok, akik ide terveztek egy SD kártya olvasót.

A hardver elég erős, hogy más Z80 számítógépet emuláljon. Tehát elméletileg a ZX Spectrum és Amstradt CPC demók is futhatnak rajta. Majd meglátjuk, ki fogom próbálni. A gép még most is szépnek tűnik a maga egyedi megjelenésével. Még a lányom is ki akarta próbálni, annyira tetszett neki.

Meglepő, de kicsi és csendes közösség formálódott a gép köré. Nekik is van klubbjuk, szerveznek találkozókat, és jól elvannak. Ezt elég furcsa látni az Amigás közösség után, akik nagyon hangosak tudnak lenni, és napokon keresztül el tudnak vitatkozni azon, mi is az Amiga.

Az első benyomások nem túl pozitívak a részemről, remélem a későbbi kalandok érdekesebbek lesznek.

Időről-időre megpróbálnak kitolni a Linuxosokkal, de azok elég jól veszik az akadályokat, noha a megoldás során néha-néha csúnyább szavak is előfordulnak szókincsünkben.

Az egyik ilyen akkor történet, amikor szekvenálási eredményeket kaptunk BitLockerrel titkosított pendrive-on. A tároló sertés metagenomikai mintákat tartalmazott. Hiába, már a disznók belében élő baktériumok személyiségi jogaira is tekintettel kell lennünk.

Mindegy, a lényeg, hogy nekem el kellett olvasni a tartalmát. Az egyetlen elérhető program a dislocker. A fordítása fájdalommentes, a szükséges dependendciák szinte minden repoban megvannak. A használata koránt sem triviális. A dokumentáció szerint csak egy bejegyzés kell a /etc/fstab fájlba, és már kész is.

Ne higgyünk neki.

Mivel az eszköz titkosított, az automount megdöglik rajta. Az lsblk parancs segítségével kell kideríteni, USB tárolónk melyik eszközleírót kapta. Ha megtudtuk, kezdődhet a munka érdemi része.

Először is dekódolni kell a partíció tartalmát:

sudo dislocker -r -V /dev/sdc1 -u pendrive

Itt meg kell adnunk a dekódoláshoz szükséges jelszót. Ha a pendrive egy könyvtár, akkor lesz benne egy dislocker-file nevezetű állomány. Ez a teljes partíciót tartalmazza egyetlen fájlban. Használatához ezt még egyszer csatolni kell, pont úgy, ahogy egy ISO képfájllal is teszi az ember.

sudo mount -o loop,ro pendrive/dislocker-file pendrive2

Na, ekkor érhetjük el a fájlokat a pendrive2 könyvtárban. Erre azért van szükség, mert a dislocker csak dekódol, a partíciókat magukat nem kezeli.

A kutatók néha olyanok, mint a gyerekek. Nagyon akarnak egy ábrát. Minden nap rágják a fülem: az nagyon jó ábra, olyan kell az én cikkembe is! Elkészítem nekik, mire a következő hónapban már egy másik ábrára fáj a foguk, amit megláttak kedvenc újságjuk hasábjain.

Az ábráknak az a feladatuk, hogy információt közöljenek. De egyes ábrák nem adnak semmi új információt, csak szokatlan köntösben mutatnak valamit, amit egy oszlop diagramm is képes bemutatni, de ez elég egyes kutatóknak, hogy zombi üzemmódba kapcsoljanak. Szemük üvegessé válik, réveteg mozgással kezdenek közlekedni, és nem azt kántálják: "agy, agy", hanem "ábra, ábra". Ebből az ábra éhségből csak a filmekből  ismert módon gyógyíthatóak ki.

Az első ilyen ábra a floral venn-diagram. Mikor meghallottam, nem erre gondoltam. A venn diagrammnak az a lényege, hogy lássuk, az egyes kategóriákban mennyi átfedés van. Pont ez az, amit a floral venn-diagramm nem mutat meg. Megkérdezték, tudnék-e ilyet készíteni. Azt válaszoltam, ilyet mindenki tud készíteni, még a hat éves lányom is. Kell rajzolni egy virágot, a szirmaiba meg számokat kell rakni. Szerintem ehhez nem kell dedikált R csomag, csak egy Paint.

A második eset több fordulós volt, mint egy mérkőzés. Először egy PowerPoint prezentációt kaptam, amiben megláttak egy szép interakciós hálózatot. Olyat akartak, függetlenül attól a ténytől, hogy nem volt egyetlen iterakciós adatuk sem. Megsajnáltam őket, és mondtam, hogy a GO adataikból lehet hasonlót csinálni, de az biztosan nem ilyen lesz, mivel a GO egy irányított aciklikus gráf. Természetesen nem ezekkel a szavakkal mondtam el, mert ettől kiolvadt volna az agyuk. Ennek ellenére láthatóan csalódottak volta, amikor meglátták a végeredményt.

Ezután jó ideig nem kellett semmit csinálni nekik, de ők tovább olvasták a cikkeket, és csak idő kérdése volt, hogy valami kiváltja náluk a nyálfolyást. Következő kiszemeltjük a toxpi ábra volt, amit egyetlen programmal, a ToxPi-al készíthetünk el. Bevallom, nekem többszöri nekifutásra sem sikerült kitalálni, mit is csinál ez a program. Valami adatokat be kell nekik adni, amitől kiszámolja a ToxPi pontszámot. Kaptam egy cikket is, amibe a normalizált expressziós adatokat felhasználva elkészítették ezeket a szörnyű kör diagrammokat.

A cikk alapján ugyan azzal a módszerrel elkészítettem az ábrákat az ő adataikra is, de az eredménynek semmi értelme nem volt. Főleg azért, mert nem lehetett tudni, mit jelent az eredményül kapott pontszám. A levélváltások során teljesen egyértelmű volt, hogy a partnereknek fogalmuk sem volt, mit várnak az ábrától, de látták, hogy van ilyen, akkor nekik is kell.

Egy korábbi munkahelyemen sem volt elég ha R-ben elkészítettem az ábrákat. Azt a kritikát kaptam, hogy az "összes kínai ilyen ábrát produkál a cikkeiben". Nem értettem, ez miért baj. Nem sztárokról írunk pletykákat, hanem tudományos eredményt mutatunk be. Ennek ellenére olyan erős volt a nyomás az egyedi ábrák elkészítésére, hogy egyik munkatársam soha nem olvasta el a rendszeresen kézhez kapott folyóiratokat, csupán ebéd előtt átlapozta, hogy van-e benne "érdekes ábra". Ha nem volt, bele sem olvasott.

Szerintem elsődlegesen jó cikket kell írni. Jó cikk alatt azt értem, hogy a módszerekbe ne lehessen belekötni, az alkalmazott statisztika kifogástalan legyen. Ha ez mind megvan, akkor ezt megkoronázhatjuk egy olyan ábrával, ami szemléletesen bemutatja az eredményeket. Ha csak azért akarunk szép ábrákat, hogy a bírálókat hipnotikus állapotba hozzuk, hogy könnyebben elfogadják a cikket, akkor érdemes lenne új karrier lehetőség után néznünk. Mondjuk egy sztármagazinnál.

Ha egy munkán elsőre látszik, hogy biztosan nem lesz belőle értelmes eredmény, azt nem kell elvégezni. De mi a helyzet azokkal a munkákkal, ahol kb. 90%-ig vagyunk biztosak, hogy felesleges? Mi a helyzet, ha ezzel a véleményünkkel egyedül vagyunk?

Ezek a vesztes csaták, amit meg kell vívni, mert nem bizonyítható teljesen, hogy vesztesek. Ezek csak kósza érzések, amelyek alapján senkit nem lehet meggyőzni, hogy az erőforrásokat másra fordítsuk. Plána, ha valakinek annyira megbízhatatlanok a megérzései, mint nekem.

A bioinformatikusokra általánosan igaz, hogy a világ összes számítástechnikai kapacitása sem lenne nekik elég, mert bármennyi erőforrást is kapnak, csak még több folyamatot futtatnának, még nagyobb memória igénnyel, több processzor maggal, stb. Ezért, mikor kaptunk egy lehetőséget, hogy ingyen és bérmentve verjünk el 1 csillió dollárt az Azure-on, rábólintottunk. (Ezt csak a hatás kedvéért írtam, a tényleges összes alacsonyabb volt. De tényleg rengeteg pénzről volt szó.)

A Microsoft mostanában erősen lobbizik az akadémiai szférában, hogy a szolgáltatásait minél többen használják. Ezért cukorka helyett hatalmas pénzösszegeket vágnak csoportokhoz, hogy rászoktassák őket az Azure használatára. Az egyik ilyen csoport is, akik tématerveikben dobálóznak az aktuális trendek vezérszavaival (big data, machine learning, stb.), kaptak is 1 csillió zsét meghatározott időre. De nem költötték el, mert nem értettek a cloud használatához.

Mikor már csak két hét volt vissza a határidőből, akkor kezdtek aggódva rohangálni, hogy mit is csináljanak. Ekkor léptünk mi a színre, akiknek ugye nem probléma processzorokat, tárhelyet és memóriát teleszemetelni mindenféle adattal, kutatás címszóval.

Az első hiba a rendszerben az volt, hogy nem mértük fel, mire is van szükségünk. A terv az volt, hogy egy teljes GATK folyamatot futtatunk több száz mintára. Ehhez a mintaszámnak megfelelő mennyiségű 20 magos gépeket kértünk, amelyek reményeink szerint 12 óra alatt emésztik fel a rendelkezésre álló pénzösszeget. Csakhogy 12 óra alatt még senki a csoportból nem futtatott le GATK-t.

A második hiba az volt, hogy nem használtuk ki a felhőben rejlő lehetőségeket. Az összes nagy szolgáltató lehetőséget biztosít, hogy egyszerre felügyeljünk több gépet, van load balancing, virtuális gép képfájlok létrehozása, mozgatása, paraméterezett számítógép indítás, speciális adatbázisok, stb. Ezekből én semmit nem kaptam. Még azt sem engedték meg, hogy magam indítsam a gépeket. Adtak egy mester gépet hatalmas tárhellyel, de szerény teljesítménnyel, és két darab nagy teljesítményű gépet, hogy készítsek egy rendszert, ami megoldja az adatok, programok, stb. utaztatását és a feldolgozás vezérlését. Ha pedig elkészültem a tesztekkel, akkor elindítják nekem az összes igényelt gépet.

Történt még egy apró konfigurálási hiba a részemről, ugyanis a mester gép tárhelyén MBR partíciót hoztam létre, és utána csodálkoztam, miért csak 2TB-ot tudok elérni a 16-ból. Túl sok retro géppel bohóckodom.

Ekkor kezdtem úgy érezni, hogy ez egy vesztes csata lesz, de adtam még 30% a győzelemre. Neki is álltam a "szegény ember Dockerét" megírni. A szkript először yum-al felpakol egy csomó szükséges szoftver komponenst, majd a pip végez telepítéseket. Amint ezek megvannak, a mester gépről scp-vel lemásolja a bioinformatikai programokat, genom fájlokat és egy minta szekvenciáit. Snakemake-el lefut a GATK, majd az eredményeket visszamásolja a mester gépre.

Ez volt a könnyebb része. Hogyan indítsam el a felmásolt szkriptet? Az szóba sem jöhetett, hogy több száz gépre egyenként lépjek be, és adjam ki a parancsokat. Szerencsére az ssh képes parancsot futtatni távoli gépen. Ez bárki ki is próbálhatja egy egyszerű példán:

ssh remote 'ls -la'

Hátránya, hogy amíg a távoli parancs fut, addig fenntartja a kapcsolatot a két gép között, addig nem kapom vissza az irányítást a mester gépen, amíg a parancsoka le nem futnak. Ha több száz gépet akarok vezérelni, akkor mindegyik gépen az elemzés egymás után lesz végrehajtva. Nekem viszont párhuzamos végrehajtás kell.

Ezért készítettem még egy szkriptet, aminek semmi más dolga nem volt, mint nice-al a háttérben futtatni az első szkriptet. A mester gépről ezt kellett csak elindítani. Ez az indítás után azonnal visszaadja a vezérlést nekem. Valami ilyesmi formája van:

nice poormansdocker.sh $1 &

A tesztek ígéretesen haladtak, de azért volt pár probléma. A két tesztelésre adott gép nem volt teljesen ugyan az. Az egyik CentOS volt, a másik Oracle Linux. Bár mindkettő Red Hat alapokon nyugszik, de természetesen teljesen más csomagokat lehetett elérni hozzájuk, például Oracle Linuxon nem lehetett fejlesztői csomagokat telepíteni 3-as Pythonhoz. Ettől nem fordult a Snakemake és nem ment az elemzés.

A másik probléma az idővel volt. A tesztek alapján csak az illesztés 30 óráig futott. Különböző trükkökkel sikerült 27 órára lecsökkenteni, de ez még mindig messze volt az áhított 12 órától, és a leglassabb lépést, a HaplotypeCaller-t még nem is számoltuk. Ekkor már 85% esélyét láttam a kudarcra.

Jött az új terv: csak az illesztési lépést hajtjuk végre, de nem több száz mintára, csak a "legfontosabbakra". Nos, a legfontosabb mintákból 18 hiányzott, és senki nem tudta, hol vannak. Elvesztek valahol a Dropbox-Excel-PhD hallgatók Bermuda-háromszögben.

Az idő közben szorított, mert a határidő közelített, az elemzésre szánt idő viszont hosszabbodott. Végül elindították nekünk a száz gépet. A szkriptet módosítottam, hogy a munka befejeztével kapcsolja ki a gépt. Itt viszont elkövettem a második fiaskót. Abban a hiszemben voltam, hogy ezek a gépek olyanok lesznek, mint amiket tesztelésre kaptam, és nem ellenőriztem ezt. Természetesen nem olyanok voltak. Hiányzott róluk a privát kulcs, amivel elérhetik a mester gépet.

A szkripteket felmásoltam, azok telepítettek mindent, megpróbálkoztak az adatok letöltésével. Ez nem sikerült nekik, ezért búcsút intettek, és lekapcsolták a gépeket. Akkor módosítottam az indítást, hogy ne csak a szkripteket másolja ki, hanem a kulcsokat is, a lekapcsolást pedig kivettem, hogy elkerüljem az újabb bonyodalmakat. (Mivel nem az én kezemben volt az irányítás, ezért emaien kellett kérnem, hogy indítsák újra a gépeket.)

Ez már jól ment. Hanem az előzetes terveket egy újabb fejlemény nehezítette: a száz gép egyszerre rácuppant a mester gépre, és próbálták letölteni az adatokat, amitől persze minden másolás lelassult. De mikor letöltöttek mindent, akkor végre egy kellemes meglepetés is történt. A 30 órás tesztfutásokhoz képest valami csoda folytán az illesztések lementek 8 óra alatt. Hurrá, végre valami jó is történt!

Ezután kicsit összekuszálódtak számomra a történések. Egyik nap még arról volt szó, hogy ezzel a felgyorsult futással az 1 csillió pénznek csak a felét költöttük el, másnap reggelre viszont kiderült, hogy mindent elköltöttük. Nem tiszta, mi is történt. Kicsit furcsa volt, az biztos.

Már csak az adatokat kellett lementeni. Ez sem ment zökkenő mentesen. A BAM fájlok letöltése olyan hosszúra nyúlt, hogy attól féltünk, lekapcsolják a gépeket, mielőtt letölthetnénk az összes mintátt. Ezért különböző gépekre pánik-szerű letöltéseket kezdtünk. Minden további kapcsolat persze lassabb volt, de szerencsére nem lassították a már elindított letöltéseket.

Végül sikerült mindent letölteni, és a gépeket lekapcsolták. A vesztes csata végül nem vereséggel végződött, mert határidőre elköltöttük a pénzt, és a munkával is előrébb jutottunk, de győzelemnek nem könyvelném el, hiszen még rengeteg futtatás van vissza. Az illesztés igazából csak az alapja mindennek.

Az ár egyébként érdekes gondolatokat vetett fel bennem. Alapvetően elég sok pénzbe került, de ha azt nézzük, hogy ezért a pénzért kb. 2 darab Dell munkaállomást lehetne venni, közel hasonló specifikációban (közbeszerzést és egyéb, a kutatók életét színesítő eseményt figyelmen kívül hagyva), akkor már nem olyan durva a helyzet. Mi pedig kaptunk száz számítógépet, igaz, csak két napig. Ha az áramot nem számoljuk költségként, és továbbra is 8 órát adunk egy illesztésre, akkor a két munkaállomással 20 nap alatt végeztünk volna.

Számomra meglepetés volt, hogy a sávszélesség költsége minimális volt. Négy terabyte adatot töltöttünk fel, ez az adat mennyiség utazott a gépek között, végül az eredmény BAM-ok is hasonló nagyságrendben mozogtak, ennek ellenére a költségek fél százalékát tették ki.

A tárhely sem volt vészes. A teljes költség 10%-t emésztette fel. A száz gép 400GB SSD-t használt két napig, a mester gépen pedig 16TB tárhelyet használtunk két hétig.

De ha azt nézzük, hogy ingyen kapunk szuperszámítógép hozzáférést (aminek használatával be fogom fejezni a munkát), akkor elképesztően drága.

A screen-t nagyon szeretem, mert megadja nekem mindazt a terminál támogatást, amit egy SSH kapcsolat elvesz tőlem. Egyik hátránya, hogy könnyű elveszni a megnyitott ablakok sorában. Másik hátránya, hogy néha jó lenne két ablakot látni egyszerre, amit jobb híján az ablakok gyors váltogatásával próbálok orvosolni.

De mindez már a múltté, mert megismertem a tmux-ot. Ebben nem csak különböző ablakokat nyithatok meg, de a képernyőt fel is bonthatom kisebb darabokra, vizszintesen vagy függőlegesen. Az egyikben futhat a top, miközben a másikban írhatom a szkriptet, amivel felzabálom az erőforrásokat.

Ha ez még nem lenne elég, kapok kis státusz mezőt a képernyő alján, ahol láthatom, mennyi ablakot nyitottam meg, melyik az aktuális, mi a pontos idő, melyik gépen vagyok. Nem keverednek össze a munkafolyamatok.

A mágikus billentyűkombináció, a ctrl + b (szemben a ctrl + a-val, amit a screennél használtunk). Ez azért is jó, mert a screen belsejében indíthatok tmux-ot. Ennek természetesen alapvetően nem sok értelme van, én is egy véletlen folytán jöttem rá, de akkor nagyon hasznosnak bizonyult.

Nekem ugyanis be kell lépnem A gépre, hogy elérjem B gépet, ahol az érdemi munkát végzem. De néha A gépen is kell dolgozni. Ha A gépen elindítom a screen-t, majd egy másik ablakban belépek B gépre, ahol tmux-ot futtatok, akkor A gépen a screen parancsaival tevékenykedhetek, míg a tmux-al szabályozhatom B gépet. Nem állítom, hogy ez egy követendő példa, vagy értelmes munkamódszer, de meg lehet tenni.

A dokumentációja külön weboldalt kapott. Ezért bárki azonnal megtalálja a neki szükséges billentyűzet kombinációt.

Nálam a retró számítógépek felhalmozásának van határa. Ezek közül az egyik, hogy olyan eszközt nem szerzek be, amit nem használok. (De azért senki se firtassa, mikor kapcsoltam be utoljára az Amigámat) Azért, hogy rámutassak egy porosodó vasra, hogy van, szerintem semmi értelme. Éppen ezért soha nem akartam olyan gépet, amiben 5.25-ös floppy van.

Az assembly/demoscene tudásom elmélyítésére szükségem volt a VGA kártya programozása Pascal és assembly nyelven című könyvre. Hosszasan keresgéltem a net bugyraiban, de nem találtam. Végül egy könyvtárközi kölcsönzéssel szereztem meg.

Maga a könyv érdekes, de ami még érdekesebb volt, hogy elküldték a lemez mellékletet is, ami nem volt más, mint két darab 5.25-ös floppy. Mint az sejthető, nagyon kíváncsi lettem a tartalmára. Az egyetlen probléma, hogy nekem soha nem volt PC-s 5.25-ös lemezem. C64 az teljesen más, de a két lemez formátuma nem kompatibilis,

Először a könnyebb megoldást kerestem. Megkértem Charlie-t, hogy küldje el a lemezek tartalmát. Feltételeztem, neki megvan, mert azt mondta, hogy a könyv megvan neki (sőt, a könyvet is az ő ajánlása miatt szereztem be), régi hardverei neki is vannak, talán lementette magának. Nem volt szerencsém.

A második lehetőség, hogy a melóhelyen nézek szét. Annyi elavult hardver van ott, talán lelek egy floppy-t. A lemezeket lementem, és többet erről az ügyről nem beszélünk.

Az irodánk lomtárában nem volt. A rendszergazdák állították, hogy nekik van három-négy, de a helyiségeket átkutatva egyet sem találtunk. Azt javasolták, kérdezzem meg a karbantatókat, mert nekik van hozzáférése a leselejtezett eszközök raktárához. A selejtezés során ugyanis elviszik a gépeket az irodákból, de hulladék lerakóig nem jutnak el. Bekerülnek az egyik raktárba, majd rájuk zárják az ajtót. Az egyik karbantartó mondta, hogy ő kettőt is eltett annak idején, mikor ezeket az ősi eszközöket leselejtezték. Közben fennkölt filozófiai problémákról beszélgettünk:

- Azt is mondják, hogy aki biztonságban akarja tudni az adatait, az ilyen lemezeken tárolja.

Először nem értettem, miért akarna bárki is lemezen tárolni bármit is. Hozzáérek az ujjammal és vége mindennek, ami rajta van. Még a neve is az, hogy hajlékony lemez. Tehát akár el is törhetem. De rögtön meg is adta a választ:

- Ezeknek a gépeknek nincs IP-je.

- Ha egy modern gépből kihúzzuk az UTP kábelt, annak sem lesz IP-je.

Igazából akkor is van IP címe, de nem éreztem szükségét, hogy ilyen apróságokkal összezavarjam. Ezzel sajnos megakasztottam a magas röptű kiberbiztonsági eszmecserét.

- És mit dolgozik? Itt dolgozik az intézetben?

- Bioinformatikus vagyok. Több, mint egy éve itt dolgozom.

- Szerintem a legnagyobb bioinformatikus Turing volt.

Amennyire én tudom, Turing foglalkozott informatikával, foglalkozott biológiával, pont bioinformatikával nem. Nem is vagyok benne biztos, hogy lett volna értelme az akkori számítógépekre biológiai problémákat bízni. Közben átnéztünk hat raktárt, de egyikben sem láttunk olyan gépet, amiben 5.25-ös floppy lett volna.

Második kísérlet is kudarcba fulladt. Bármennyire is nem akartam, kénytelen voltam venni egy meghajtót. Régi kacatokat sokan árulnak, ami nehéz, hogy olyat találjak, ami működik is. Akkor még nem tudtam, melyik gépbe fogom beszerelni a meghajtót, ezért egy ISA vezérlőkártyát is vettem hozzá.

A meghajtót gyorsan megkaptam. Burkolata már nem volt, ezért az elektronika és a mechanikai egységek csupaszon meredtek rám. Az eladó rendes volt, küldött egy tartalék kártyát is, hátha nem lesz kompatibilis a meghajtóval, alaplappal vagy bármi mással. Nem tudom, hol tárolhatták a felszerelést, de hatalmas kosz pamacsokat fújtam ki a szerkezetből.

Először egy Pentium I-es gépbe szereltem a meghajtót. Mivel ennek az alaplapjára közvetlenül is ráköthető a lemez, a vezérlő kártya használatától eltekintettem. A második probléma, hogy nem tudtam, milyen orientációba kell a szalagkábelt bekötni. Tudtam, hogy az oldalán található piros csíkot kell figyelembe venni, de azt már nem tudtam, mihez kell azt viszonyítani. Vállat vontam, majd random bekötöttem. Majd megcserélem, ha nem lesz jó.

Mikor a feleségem meglátta, undorodva mutatott a gépre:

- Ezen egér ürülék van?

- Hol? - kérdeztem aggódva. Semmi kedvem nem volt ilyesmit a lakásba hozni.

- Ott, nem látod? Ez gusztustalan.

- Az egy kerámia kondenzátor - mondtam, miután megértettem, mire mutat.

A lemezekről nem tudtam, hogy milyen sűrűségű: egyszeres vagy dupla. Ezt a BIOS-ban kell beállítani. Majd ezeket is végigpróbálom. A permutációk számát tovább növelte, hogy az 5.25-ös floppykat jumperekkel tovább lehet paraméterezni. Volt valami T jumper, S jumper, 0, 1  2, 3. A T valószínűleg a terminator, amit akkor kell bekapcsolni, ha ez a meghajtó van szalagkábel végén. Az S talán a sebesség? Nem tudtam. A számok pedig meghajtó számát lehet beállítani. Először nem tudtam, de ez PC esetén DS1 vagy DS2, attól függően, hogy a számozás 0-től vagy 1-től kezdődik a számozás. Tehát nálam DS1-nek kell lennie. A biztonság kedvéért a DS0-t is kipróbáltam.

Természetesen az is lehet, hogy rossz a kábel. Ebben az esetben kezdhetek előről mindent a másik vezérlőkártya kábeleivel.

A gép természetesen nem indult el FreeDOS-al. A boot folyamat megállt mindjárt az elején. Emlékeztem, hogy írtak erről valamit, de pontosan nem tudtam, mit. Utána nézni nem volt kedvem, inkább beszereltem a meghajtót a következő gépbe. Ez már Pentium 4-volt, a BIOS csak 1.2MB-os lemez formátumot támogatott. Ebben az alaplapban már nem tudtam fordítva bekötni a kábelt, hála egy műanyag keretnek, ami jó volt. Ugyan csak előny volt, hogy egyetlen floppyként kötöttem be, tehát nem számított, hogy miként áll a Terminator jumper.

A rossz hír viszont az volt, hogy semmilyen módon nem tudtam elérni a lemezeket. Az A meghajtóra átlépve hibát dobott a rendszer. A boot során arra számítottam, hogy felpörög a meghajtó, de ez sem történt meg.

Rendben, jöhet a másik kábel. Ez már annyival volt jobb, hogy a boot során felvillant a meghajtó ledje, amit haladásnak könyveltem el. Ennél tovább viszont nem jutottam.

Másnap viszont a melóhelyről kerítettek nekem egy 5.25-ös meghajtót. Hurrá! Ezzel már gyorsabban ment az ellenőrzés, mert eleve jó kábelt használtam, tudtam, mit kell beállítani a jumpereken. Működni viszont ez sem működött.

Elment a kedvem az egésztől. Ennyi időt elfecsérelni, teljesen feleslegesen! Mikor visszaadtam a kölcsönkapott meghajtót, akkor annyit javasoltak, hogy próbáljak meg egy lemez felszíni ellenőrzést a scandisk-el. Közben olvasgattam, és ráakadtam egy érdekes cikkre, ami leírta, miként kell karban tartani ezeket a régi meghajtókat.

Már csak két napom volt, mielőtt lejár a könyv kölcsönzési ideje. A fejet alkohollal letisztítottam, de továbbra sem használt, és a felület ellenőrzés sem működött. A fej meg sem moccant, csak a lemez pörögtt fel egy rövid időre.

Már úgy voltam vele, hogy feladom. Nem tudtam, mit csináljak egy hasznavehetetlen 5.25-ös meghajtónak. Talán a léptető motor ér belőle valamit. A kerámia kondenzátorral meg a feleségemet idegelhetem. Azután eszembe jutott, hogy van egy AMD-s gépem is. Windows 7 van rajta, és a feleségem szokott rajta Heros II-t játszani. Ezt eddig nem próbáltam, mert az ősi gépek közül ez volt a legújabb. Esetlen az új gépeim közül a legrégebbi? Nem tudom, de a BIOS beállítások között szerepelt a 360K is. Talán annyi volt csak a baj, hogy a lemezek egyszeres sűrűségűek voltak?

Ezt a gépet is szétszedtem, beledugram a floppyt. Ezzel a trükkel sem tudtam életre kelteni a meghajtót. Oké, vége. A lemez mindörökre olvashatatlan marad. Közben eszembe jutott a karbantartó és az adatbiztonsági kiselőadása. Az adatok rohadt nagy biztonságban voltak, pedig a gépnek még IP címe is volt, amire a meghajtót kötöttem.

Ha már úgyis szétszedtem ezt a gépet is, azért nézzük meg 1.2MB-os beállításokkal is. Erre semmilyen racionális érvem nem volt, csak egy újabb időpocsékolásnak tűnt. Újra indítottam, átléptem az A meghajtóra, mire a meghajtó életre kelt. Elkezdett krákogni, reszelni, a kis fej össze-vissza rángatózott, a képernyőn meg feltűnt a lemez tartalma. Hoppá!

Mindkét lemezt lementettem, csak két fájlt nem lehetett olvasni. Gondolom az idő nem volt kegyes ahhoz a kettőhöz. Végül is, 26 év telt el a könyv megjelenése óta. Ez azért nem olyan rossz arány. A meghajtót szépen elcsomagoltam. Nem tudom, mikor lesz rá szükség, de remélem, nem a közeljövőben.

A következő beszélgetés foszlányaiban több, különböző megbeszélésen hangzott el életem során:

- Ebben a publikációban nincs hipotézis.

- Mert ez egy leíró jellegű cikk.

- Ebben a publikációban random módszerek vannak egymás után.

- Mert ez egy leíró jellegű cikk.

- Ebből a publikációból semmi érdemlegeset nem lehet következtetésként levonni.

- Mert ez egy leíró jellegű cikk.

- Ennek a publikációnak nincs koherens váza.

- Mert ez egy leíró jellegű cikk.

- A publikáció olvasása közben többször elaludtam, mert a teljesen egyforma bekezdések összefolytak a szemem előtt.

- Mert ez egy leíró jellegű cikk - válaszolja egy képzeletbeli gyerek kórus.

Nem csoda, hogy az évek során, ha csak meghallom a "leíró jellegű cikk" kifejezést, azonnal egy elnagyolt, unalmas, érdektelen munka képe villan be.

Ha a való élet követne bizonyos kalandregényekbe illő dramaturgiát, akkor olyan szófordulatokkal élhetnék, hogy "de álmomban sem képzeltem, hogy ez a cikk is ilyen lesz". Esetleg: "de ez a cikk felfedte előttem a leíró jellegű alkotások szépségét".

Az igazság viszont legtöbbször mentes ezektől a remek kis fordulatoktól, ezért a most bemutatásra kerülő alkotás egy leíró jellegű cikk, annak minden jellemzőjével. Úgy is mondhatnám, ez a leíró jellegű cikkek archetípusa.

Ez szintén egy örökség projekt részeként indult. Akkor kaptam meg, amikor már szinte minden kész volt, pár apróságot leszámítva. Az alapfelállás egy bödön méz, ami nagyjából öt évet állt a szekrényben, mielőtt elkezdték volna vizsgálgatni, és amiben csodával határos módon találtak egy ismeretlen baktériumot. Mit csinál egy biológus, ha baktériumba nyúl? Nem, nem kezet mos. Szekvenál. Szerencsére, vagy nem, ebben a baciban volt egy rakás transzpozon, amit az egyik mikrobiológus elkezdett az inszerciós elemek manuális keresgetésével összepárosítani.

Mivel ezek a szerencsétlen inszerciós (IS) elemek nem átallottak génekbe beleugrani, amitől az annotáló programok rendre elhasaltak. Kutatónk ezért manuálisan írta be a géneket, jelezte az IS elemeket, majd az egészet átadta nekem, hogy töltsem fel a GenBankba.

Ez egy elég fájdalmas procedúra volt, mert az NCBI autómatikus annotálója felülbírálta az általam beírt annotációt, folyton kiabált, hogy "ennek a génnek nincs stop kodonja", vagy "ez a gén nem metioninnal kezdődik".

A problémák egy részét autómatikusan tudtam javítani, de így is maradt épp elég manuális szüttyögés. A sok vacak javítgatás után feltöltöttem a szekvenciákat. Azt hittem, most már vége, de nem. Jött a manuális kurátor, aki kereste a plazmid szekvenciákat, és nem értette, miért nincs meg a másik fele egyes géneknek.

Aki már levelezett az NCBI stábbal, az tudja, hogy ez úgy néz ki, hogy küldenek egy levelet, amire adnak egy hét válaszadási időt. Ha válaszoltunk nekik, akkor hónapokra eltűnnek, majd váratlanul egy újabb problémával keresnek meg, és az egész huza-vona kezdődik előről.

Természetesen itt is ez történt. A szekvencia feltöltés után a még pár ábrát kellett elkészíteni. A bírálat langyos volt, ahogy a Scientifi Reportsnál már megszokott. Talán ők is bealudtak néhány transzpozon után.

Vannak olyan projektek, amelyeket nem lehet elengedni. Az ember megpróbál kimászni belőle, de úton-útfélen beleakad, nem engedi, ráragaszkodik, mint egy olvadt rágógumi. Ez a publikáció pontosan ilyen.

Még 2012 táján találkoztam először vele, ahol is egy lelkes, akkor még PhD hallgató chip-seq kísérleteket töltött le, majd mindegyiket elemezte a Homer programmal. Az azóta eltelt idő alatt ledoktorált és három gyereke lett. Ebből a szemszögből nézve az eseményeket arcon csapja az embert az idők szele.

Két évvel később jött az ötlet, hogy adatbázisba kellene szervezni a szana-szét heverő szöveges eredményeket. El is kezdtünk egy rSNP adatbázist, de a projekt gyorsan elhalt, ahogy elfogytak az emberek, akik csinálhatták volna. Már csak ez a mementó jelzi, hogy létezett. Illetve a projekt nem is halt el, csak cserélődtek az emberek. Közben én kimentem külföldre, és az egészből nem láttam mást, csak pár emailt, amiben a következő PhD hallgató a segítségemet kéri a weboldal fejlesztése során felmerülő problémákhoz. Ezek egy része a D3.js-el volt kapcsolatos, mert annak idején azt javasoltam, hogy a grafikonokat ezzel kellene megoldani.

De effektíve nekem nem kellett dolgozni vele, és én ezt nem is bántam. A projektet ugyanis nem láttam át teljesen. Nem értettem részleteiben, amitől az egész egy katyvasznak tűnt számomra. Nem is tudom, mi történt ez alatt az idő alatt a projekttel.

Mikor véget ért a jó világ és hazajöttem 2017-ben, volt egy rövid időszak, amikor gyakorlatilag nem dolgoztam sehol. Ismét kerestek, hogy segítsek az adatokat egy adatbázisba pakolni. A weboldal akkor már működött, de mindent szöveges fájlokból olvastak be, ami nem volt éppen hatékony. Még pénzt is ajánlottak érte.

A hátam közepére sem hiányzott a projekt, még pénzért sem. Szokás szerint nagyon gyorsan kellett volna eredményeket felmutatni. De volt egy másik fontos aspektusa is az ügynek: ebből lett volna meg a témán aktuálisan dolgozó PhD hallgató első szerzős cikke. Arra gondoltam, milyen kegyetlenül nehéz megszerezni a fokozatszerzéshez a cikkeket, mennyire kiábrándító, ha ilyenkor nem kapja meg az ember a hőn áhított segítséget, ezért nagyon kelletlenül ugyan, de igent mondtam. Pénzt nem fogadtam el, mert úgy gondoltam, könnyebben kiszállok a projektből, ha mégis tele lenne a hócipőm.

Megterveztem az adatbázist és segítettem az adatok feltöltésében is. Ez végül is szórakoztatóbb volt, mint elsőre gondoltam, és segített abban is, hogy a projektet jobban átlássam. Érteni még mindig nem értettem mindent belőle, de legalább már tudtam, milyen adatokkal dolgozunk, azokat hogyan kaptuk meg.

Véget ért a rövid szabadságom és elkezdtem dolgozni az MTA-nál. A segítség kérő e-mailek száma az idő múlásával ismét fogyatkozni kezdett. Úgy éreztem, ezzel a projekttel többet már nem kell dolgoznom, megtettem, ami tőlem telhető, ha lesz belőle cikk, jó, ha nem, az sem baj.

Aztán 2018-ban úgy hozta a sors, hogy visszakerültem abba a csoportba, ahonnan elmentem, visszacsöppentem abba a projektbe, amitől hat éve próbáltam megszabadulni, és már napi 8 órában dolgozhattam rajta. Az eltelt idő alatt viszont sok minden megváltozott. Addigra az MTA-s kaland annyira megfeküdte a gyomrom, hogy még ennek a projektnek is örültem. Örültem mindennek, amiben nincs Wilcoxon teszt. Úgy gondoltam, ha már csinálni kell, akkor csináljuk rendesen.

Azért, hogy a projekt ne csússzon félre, átvettem az adatbázis és a weboldal felügyeletét is. Nem azért, mert annyira értek hozzá, hanem nem akartam, hogy több ember matasson ugyan ott, és felülírjuk egymás kódját. Így ha valami gond volt a weboldallal vagy az adatokkal, akkor mindenki tudta, hogy engem kell zargatni. Nem volt egymásra mutogatás, mert megvolt mindennek a felelőse. Arról nem is beszélve, hogy a PhD hallgatók végre a fokozat szerzéssel foglalkozhattak, és nem a webszutyok turkálásával.

Mert turkálni való akadt bőven. Kódot megörökölni mindig fájdalom, és ez alól a szabály alól ez sem volt kivétel. Igazából még most sem áll ott a kód minőség, ahol lennie kellene, de határozottan jobb, mint amikor átvettem.

A dokumentálásra is igyekeztünk nagy hangsúlyt fektetni. A nyers adatok importálását sikerült olyan jól vezetni, hogy mások is meg tudták csinálni minimális segítséggel. A weboldal is rengeteg leírást kapott, hogyan lehet használni. Ezt még a bírálók is elismerték.

Volt egy adat újra generálás, mert kiderült, az összes csontvázat nem sikerült kisöpörni a padlásról, de a doksik alapján rekord idő alatt sikerült visszaépíteni az adatbázist, bár ekkor derült ki, hogy a tudtomon kívül készítettek pár segédtáblát az adatbázisba, de azt már senki nem tudta, hogyan is generálták azokat. Mikor megfejtettem, ezeket is leírtam a doksikba. Ebben az állapotában már határozottan tetszett a projekt, és örültem, hogy a részese lehettem, mert a legnagyobb része már úgy működött, ahogy egy projektnek működnie kell: A kód GitHub-on volt, a hibákat rendesen vezettük, amit lehetett, dokumentáltunk.

Azért akadtak hullámvölgyek is. Például amikor Office dokumentumokat kaptam, hogyan nézzen ki egyik-másik weboldal, attól a falra tudtam volna mászni. (Kedvencem a PowerPoint prezentációban kapott leírások voltak, ahol diákon keresztül lerajzolták nekem, hogyan menjenek az animációk.)

Az egyik nagy hiányossága a teljes projektnek a webdesign. Sajnos ez nekem nagyon nem megy, de úgy látom, a csoportban másoknak sem, ezért néz ki úgy, ahogy. A helyzetet tovább súlyosbította, hogy a bírálatok hatására a többiek további grafikai elemeket akartak belepréselni ebben az egyébként is zsúfolt weboldalba. Egy ideig ellenálltam, de végül elbuktam. Belepakoltam mindent, amit akartak.

A projekt természetesen a cikk megjelenésével még nem zárult le. Az összegyűjtött adatokkal már most is végzünk elemzéseket, amelyek az SQL lekérdezéseknek hála gyorsabbak és egyszerűbbek, mint ad-hoc szkriptekkel bohóckodni. Fejlesztések is tervben vannak, és a hiányosságait is ki kell küszöbölni, hogy ne legyen egy, a több ezer magára hagyott és használhatatlan adatbázisból.

A kutatás-fejlesztésben soha nem lehet tudni, hova lyukad ki az ember. Mivel az elérni kívánt célok az ismeretlen homályába vesznek, az oda vezető út is megtervezhetetlen. Természetesen kitűzhetünk olyan célokat, amelyek kevésbé homályosak, de az eredmény is olyan lesz: unalmas és semmit mondó.

A laboratórium falain kívül eső világ pont ellentétesen működik. Ott a kiszámíthatóság az elvárt. Senki nem akar reggelente azon gondolkodni, hogy jön-e a busz, mert a sofőr tesztel egy alternatív útvonalat. A busznak jönnie kell, és kész. A buszsofőrnek megvan, hogy mennyi utat kell megtennie, milyen gyorsan, és ezért mennyi pénzt kell kapnia. Az elvárt teljesítménytől való eltérés mérhető, felelősségre vonható, és megtorolható.

A probléma akkor kezdődik, ha ez a két világ összetalálkozik. Márpedig össze kell találkoznia, ez elkerülhetetlen. Például a tervezett és kiszámítható pénznek át kell vándorolni egy megjósolhatatlan kimenetelű kutatás felé. Végeredményként a kutatót ki kell fizetni. Ki kell fizetni egy olyan munkáért, ami nem mérhető.

Ezért a kiszámítható világ kiszámíthatóvá teszi a kiszámíthatatlant. Hogyan? Természetesen adminisztrációval. Az adminisztráció viszont embereket jelent, akiket alkalmazni kell. Egyfajta puffer zóna ez a két világ között, akár csak egy dimenzió kapu valamelyik tudományos-fantasztikus műben. Ezek a kapuk furcsa dolgokat csinálnak mindkét esetben.

Vegyünk egy olyan egyszerű esetet, mint amilyen a munkaidő nyilvántartás. A tervezett világ elvárja, hogy én meg tudjam mondani, mennyi időt töltöttem egy adott munkával. De én ezt nem tudom megmondani. Ha van egy szkript, amit két évvel ezelőtt megírtam, és fut három hétig. Akkor mennyit dolgozom? Amíg elindítom? Az két perc. Amíg fut éjjel-nappal? Esetleg amíg írtam a szkriptet?

A helyzet furcsasága, hogy bármelyik értéket írom be, az rossz lesz. Két percet nem írhatok be, mert azt mondják, nem dolgoztam eleget. Ötszáznégy órát nem írhatok be, mert nem hiszik el, és egyébként sem jogosultak túlórát kifizetni. A szkriptet meg azelőtt írtam, hogy elindult volna a projekt, tehát az nem ebből a munkából ment. Végeredményben azt kell mondjam, ha igazat írok, bajba kerülök.

Ha viszont hazudok, akkor minden rendben lesz. Ha beírom, hogy 8 órát dolgoztam, akkor a rendszer megnyugszik, a kis fogaskerekek boldogan forognak tovább. A papír A-helyről tovább tud vándorolni B-helyre, mert nincs benne "hiba".

Amint egy kutató több projekten is dolgozni kezd, több helyről kapja a pénzt, több adminisztrációval kell foglalkoznia. Itt viszont a interferencia lép fel. Nem lehet minden projektre 8 órát beírni, az arányoknak mégis érvényesülni kell. Ezért teljesen elfogadott, hogy olyan nyilvánvaló hülyeségeket írnak be kutatók, hogy az adott projekttel 2,3 órát dolgozott naponta.

Senki nem foglalkozik az ügy abszurditásával. Sőt, emberek, (adminisztráció címszóval) pénzt kapnak azért, hogy az igényeknek megfelelő hazugságot összeállítsák, majd egy másik helyen, másik emberek ezt az egész értelmetlen adathalmazt ellenőrzés céljából átnézik.

Miért írok minderről? Kit érdekel ez? Azért írok, mert hála nekem, a hazugság gyártás új szintre emelkedett. Ugyanis a papírok kitöltése annyira bonyolulttá vált, hogy valakinek az az elképzelése támadt, hogy automatizálni kellene. Én pedig imádok automatizálni dolgokat. Pláne, ha olyan értelmetlen dolgokról van szó, mint a projektidő nyilvántartás. Értelmetlen alatt azt értve, hogy időt és energiát kell rá áldozni.

A programnak Windows alatt kell futnia, mert az adminisztrátorok csak azt használnak, és nem fognak a kedvemért mást telepíteni. Ezért csakis a C# jöhetett szóba, hogy a felhasználói felületet minél egyszerűbben elkészíthessem. Az is nyilvánvaló volt, hogy kell egy adatbázis, ahol tárolom a szükséges adatokat, amire a LocalDB volt az egyik logikus jelölt.

Kérdés, mit tároljunk az adatbázisban? Először jó fiú módjára olyasmiket akartam tárolni, ami az igazságot tartalmazza. Ahogy egyre többet és többet megtudtam a rendszer működéséről, rájöttem, hogy teljesen felesleges bármit is tárolni a munkaidőről. Nem csak a fent vázolt jelenségek miatt, hanem azért is, mert a csoportvezetők gyakran visszamenőleg is meggondolhatják magukat a pénz felhasználásáról. Teszem azt, X PhD hallgató helyett Y-t jelölik ki, hogy a projekten dolgozott.

Ezt úgy fogalmazták meg nekem, hogy a program eredményének "időben visszafelé is módosíthatónak kell lennie". Francokat! Ez csak azt jelenti, hogy az algoritmusnak tetszőleges időintervallumon kell tudnia hazudni. Nem egy adat tároló kellett nekik, hanem egy adat generátor. Tárolni csak a hazugságok paramétereit kell. Ez jó, mert egyszerűbb lett az adatbázis struktúrája.

Egyetlen problémám sokáig az volt, hogy miként jelenítsem meg a végleges táblázatot. Megrajzolhatom GDI-vel, ami nem tűnt túl jó ötletnek, mert minden formázási paramétert nekem kell leprogramozni, és a végtelenségig finomítani. Ez nyilvánvalóan sok időt vesz igénybe. Ha Linux alatt lettem volna, szívbaj nélkül egy LaTeX forrást állítottam volna elő, amit kedvemre PDF-é konvertálok. Sajnos C# alatt nem sok PDF készítő modult találni.

A másik megoldás, ha előre elkészített komponenssel dolgoznék. Régen volt egy Grid, amit a Visual Basic-es múltam során használtam (igen, mindenkinek van sötét korszaka), de a mostani implementáció (DataGridView) nekem nem tűnt elég paraméterezhetőnek.

Aztán eszembe jutott, hogy a táblázat lehetne közönséges HTML, amit egy WebBrowser komponenssel megjelenítek. CSS-el úgy formázom, ahogy akarom, ráadásul a komponens képes kinyomtatni a tartalmát egy szimpla metódus hívással. Túl szép, hogy igaz legyen!

Egyébként az is. Nem tudom, miért, de a nyomtatás során fejlécek és láblécek jelennek meg szükségtelen szövegekkel, amiket képtelenség kikapcsolni! Illetve az egyetlen módja, hogy kikapcsoljam, ha módosítom a Registry-t. Már kezdtem elfelejteni, hogy Windows-on vagyok.

A problémát úgy lehet megkerülni, ha nem egyből nyomtatok, hanem a Nyomtatási előnézet dialógust hívom meg, mert akkor a felhasználónak van lehetősége kikapcsolni azt. Nem a legjobb megoldás, mert a felhasználónak még egyet kell klikkelnie feleslegesen.

Így született meg a FatLiar program.

Az előző részben sikerült egy pixelt kigyújtani a képernyőn. Szép teljesítmény, de elég sokat kellene gépelni, ha valami összetett ábrát akarunk látni, nem igaz? Szerencsére nincs is rá szükség, mert a programozás tele van olyan nagyszerű elemekkel, mint a ciklusok, vagy a feltételek.

De előtte rajzoljuk tele a képernyőt. A megoldás nagyon hasonlít az előzőleg bemutatott kódra, de van benne egy plusz utasítás. Az inc. Ez nem csinál mást, mint eggyel növeli az adott regiszter tartalmát. Párja, a dec, csökkenti azt. Ha tehát minden egyes ugrás után megnöveljük a memóriacímet, ahova rajzolunk, elboríthatjuk fénylő pixelekkel a képernyőt. Rajta, ne tétovázzunk!

   org 100h
section .text
start:
   mov ax, 13h
   int 10h
   mov ax, 0A000h
   mov es, ax
draw:
   mov dl, 7
   mov [es:di], dl
   inc di
   jmp draw
section .data
section .bss

A program végtelen ciklust hajt végre, soha nem jut el a jmp utáni kódrészletig. Persze, ez még mindig csak számítások egymásra hányása. A rendszer ugyanis túlcsordul, de ez nem hibaként jelentkezik, hanem azzal, hogy újból rajzolni kezd az elejéről. Ugyan azzal a színnel. Mit is mondunk az ilyen képre? Uncsi! Mi lenne, ha egy cilkust használnánk?

A ciklus megvalósítása nem nehéz. A loop utasítás segítségével visszaugorhatunk egy korábbi címre. A ciklus számlálója az CX regiszter. Amíg a regiszter nagyobb, mint egy, a loop visszaugrik. Tehát egy 10 lépéses ciklust a következő módon hozhatunk létre:

   mov cx, 10
for:
   ; instructions
   loop for

Kiváló! Sikerült felülkerekedni a jmp hátrányain! De ha kicsit belegondolunk, a szívünk összeszorul. Elhasználtunk egy csomó regisztert! Már nincs AX, nincs BX, ha ciklusokat akarunk használni, le kell mondani a CX-ről. A programunk komplexitása szinte a zérón áll, és máris elhasználtuk a regisztereket. Hol vagyunk még az Unreal Engine összetettségétől?

Nem kell aggódni, mert még alig használtuk gépünk memóriáját. Ott van például a stack (vagy verem). Ez pont olyan, mint a "Fontos!" feliratű doboz a munkahelyemen. Ha kapok egy fontos papírt, akkor azt oda teszem. Kapok még egyet, rárakom az előzőre. Aztán gondolok egyet, hogy most fontos dolgokkal kellene foglalkoznom, és kiemelem a legfelső papírt a dobozból, és elvégzem, ami rajta van.

Ez az analógia annyira jól működik, hogy ha nem dolgozom fel elég gyorsan a fontos dolgokat, akkor pontosan ugyan az történik velem is, mint a számítógéppel. Megtelik a verem. (Ekkor kapjuk a híres stack overflow hibaüzenetet.)

Két utasítással kezelhetjük a stack-et. Ez a push és a pop. Előbbivel egy regiszter értékét menthetjük oda, másodikkal az ott található értéket helyezhetjük el egy regiszterben. Ha tehát két ciklust akarunk egymásba ágyazni, akkor a CX regiszter mentéséről magunknak kell gondoskodnunk a stack segítségével. Nem kell lefoglalni a memóriát, vagy ellenőrizni, ez mindig hűségesen a rendelkezésünkre áll.

   org 100h
section .text
start:
   mov ax, 13h
   int 10h
   mov ax, 0A000h
   mov es, ax
   mov cx, 64000
cycle1:
   mov di, cx
   push cx
   mov cx, 256
cycle2:
   mov dl, cl
   mov [es:di], dl
   loop cycle2
   pop cx
   loop cycle1
   mov ax, 3
   int 10h
section .data
section .bss

A program telerajzolja a képernyőt, de lassabban, mert minden egyes pozícióban 256-szor megváltoztatja a képpont színét. De a végeredmény továbbra is egyszínű képernyő. Ezen sürgősen változtatni kell! Mi lenne, ha az elejét és a végét más színnel rajzolnánk?

Természetesen megtehetnénk, hogy két ciklust készítünk, de akkor kétszer kell leírni a kirajzoló rutint is. Inkább egy vizsgálat kellene. Ha a képernyő elején vagyunk, átállítjuk a rajzolás színét (esetünkben a dl regisztert). A vizsgálatotokat több utasítás alkalmazásával tudjuk megvalósítani. Először a cmp utasítás megvizsgálja, hogy két érték egyenlő-e, és beállít további regisztereket (most mindegy, hogy melyeket). Aztán egy másik utasítás a regiszterek alapján ugrik az általunk megadott címre. Ezért annyi ugró utasítás van, ahányféle összehasonlítás. Én csak hármat mutatok be. A je ugrik, ha a két érték egyenlő. jb akkor fog ugrani, ha a cmp-ben használt kifejezés bal oldali mennyisége kisebb, a ja utasítás pedig akkor, ha nagyobb. Módosítsuk a jmp-s példát, hogy mindez világos legyen:

draw:
   mov dl, 2 ;green colour
   cmp di, 8000
   ja set
   mov dl, 12 ;red colour
set:
   mov [es:di], dl
   inc di
   jmp draw

Beállítjuk a színt zöldre, majd megnézzük, hogy a pozíció kisebb-e 8000-nél. Ha nagyobb, ugrunk a kirajzolásra. Ha nem nagyobb, akkor az ugrás nem valósul meg, a szín piros lesz. Most már tudunk készíteni egy programot, ami nem uncsi. Kirajzolhatjuk a Magyar zászlót.

draw:
   mov dl, 2 ;green
   cmp di, 21119
   ja iftwo
   mov dl, 12 ;red
   jmp set
iftwo:
   cmp di, 42239
   ja set
   mov dl, 15 ;white
set:
   mov [es:di], dl
   inc di
   jmp draw

Először megnézzük, hogy a pozíció nagyobb-e 21119-nél. Ha nagyobb, ugrunk a második összehasonlításra. Ha nem, beállítjuk az első színt és ugrunk a kirajzolásra. Ha nem így tennénk, a program végrehajtaná a második összehasonlítást is. Majd hasonló logikával jön a második feltétel. Bonyolult? Ha a válasz igen, akkor ideje megszeretni a GOTO-t, mert alacsony szinten ez a király. Nagyon sok mindent nem érintettem a posztban, de ennek az ismertetőnek nem is célja, hogy mindent bemutassak. A cél az érdeklődés felkeltése.

Ezért, akinek van kedve, elgondolkodhat azon, hogy az utolsó példánál át lehet-e rendezni úgy a vizsgálatokat, hogy ne legyen szükség az első jmp utasításra.

Az első lépés a barkács mentes számítógépem felé a Slackware lecserélése volt CentOS-re. A történet viszont még nem ért véget, mert volt egy másik igen komoly gányolás is a konfigurációmban, de ez a Windows-t érintette. Ott ugyanis jó ötletnek tűnt annak idején, hogy egy alaplapi RAID0-ra telepítsem a rendszert. Ki akartam próbálni, mennyire jó.

Azóta eltelt két év, és már tudom, hogy nem jó. Ráadásul kezdett betelni, így elkeztem tervezgetni, hogyan ültetem át a rendszert egy nagyobb vinyóra, RAID nélkül.

Az alaplapi RAID sok hátránya közül az egyik, hogy nem látom Linux alól, így a jó öreg dd parancs nem sokat tud segíteni. Szükség volt egy professzionális megoldásra, ami Windows alatt működik.

Szerencsére elég sok program van, ami kb. 8 és 14 ezer forint között megoldja a problémát. Igaz, mindegyik programnak van ingyenes verziója is, de az UEFI-s rendszer átültetése csak a fizetős verzióban van, ráadásul úgy gondoltam, hogy ekkora összeggel megtámogathatom a céget, amelyik segít nekem. Végül két jelöltre szűkítettem a kört. Az egyik az AOMEI Partition Assistant, a másik az Easeus Todo Backup volt. Utóbbi viszont éves díjat kért, ami nem tetszett, mert valószínűleg az elkövetkező 5 évben nem lesz szükségem a programra. Maradt az AOMEI.

A gépet szétszedtem, lehúztam a CentOS vinyót, rácsatlakoztattam az üres vinyót, amire a Windowst migrálom, újra indítottam. A program elég intelligens volt, még azt is megengedte, hogy a cél partíció nagyobb legyen. Ezután bebootolt egy PreOS állapotba és kb. 6 óra alatt átmásolt 725 GB-ot.

Kiszedtem a RAID0 vinyókat, visszadugtam a CentOS-t és újra indítottam.

Indítás után valami menü feljött, hogy nem találja a Windows-t, aztán egy másik menü is megjelent, hogy megtalálta, el akarom-e indítani? El akartam. A rendszer betöltődött, de máshogy, mint eddig. Eddig ugyanis megjelent egy Windows logo, alatta pedig pontok kergették egymást, jelezve, hogy a rendszer nem fagyott le, dolgozik. Most is megvoltak az egymást kergető pontok, de a alaplap logója látszott, nem a Windows-é.

Ettől függetlenül a rendszer elindult, minden Windows-os program működött. Sőt, egy kis gyorsulást is tapasztaltam, mert nem volt alaplapi RAID, ami visszafogta volna az I/O-t. Ismételt újra indításnál már a menük sem jelentek meg, egyből tudta a rendszer, hogy mit kell csinálnia. Elégedett voltam.

Nézzük a CentOS-t! Ez viszont eltűnt. Képtelen voltam elindítani, még az alaplap boot menüjéből sem. A megfelelő lemezt kiválasztva azt az üzenetet kaptam, hogy nincs operációs rendszer. Nem értettem, miért? A migrálás során nem is volt bekötve a diszk, nem tudta semmi felül írni a partíciókat. (Mint az többször is előfordult velem annak idején, amikor a Windows felülírta az MBR-t) Először az alaplap beállításaival próbálkoztam. Arra tippeltem, hogy a Secure Boot húzta keresztül a számításaimat, mert korábban nem látott beállítások jelentek meg, amelyek különböző titkosítási kulcsokről szóltak. Kitöröltem őket, de nem volt semmi hatása. A lemez az alaplap szerint nem tartalmazott operációs rendszert.

Visszasírtam a régi, UEFI előtti időket, amikor nagyobb ráhatásom volt a rendszerre, és komolyan elgondolkodtam rajta, hogy átállok msdos partíciókra. Aztán eszembe jutott, amit a Roland tanácsolt tanítványainak: "Aki megfutamodik a kihívás elől, annak az később szokásává válik." Ezért inkább úgy döntöttem, rendbehozom a dolgokat az UEFI játékszabályai szerint.

Rendben, de hogy működik az UEFI? Azt tudtam, hogy valami FAT fájlrendszert tartalmazó partícióra bináris programokat pakolnak, de ennél többet nem tudtam. Ezért elkezdtem olvasni. Erre találtam, ami alapján kezdtem megérteni, mi is a probléma.

Míg a régi időkben a BIOS megkereste a MBR-t és átadta neki a parancsnokságot, addig az alaplapnak meg kell mondani, mit is keressen. Én lehúztam a CentOS-t tartalmazó lemezt, ezért az AOMEI a migrálás után megadta az alaplapnak, hogy hol a Windows, de mivel nem találta más operációs rendszert, mást nem írt be. Mikor az alaplap boot menüjében megadtam a CentOS vinyót, az alaplap nem tudta, melyik partíción, milyen programnak adja át a vezérlést, ezért azt mondta, nincs operációs rendszer.

Rendben, hogy lehet ezt helyre hozni? Régen egy CD segítségével elindítottam egy shell-t, majd chroot-al átléptem az elérhetetlen rendszerre, és futtattam a megfelelő javító programokat. Most is ezt kellett tenni, de CD helyett USB-ről bootoltam be a CentOS telepítő lemezét. Egy javító menüpont is volt, ami megkereste nekem a telepített rendszert, és felcsatolta az /mnt/sysimage alá. A chroot /mnt/sysimage segítségével aktiváltam azt. De most nem a GRUB-ot vagy Lilo-t telepítettem újra, hanem az efibootmgr-el elmondtam az alaplapnak, hol találja a rendszer indításához szükséges fájlokat:

efibootmgr --create --disk /dev/sdb --label CentOS --loader \EFI\centos\grubx64.efi

Egy dologban nem voltam biztos, hogy jó lemezt adok-e meg, mert az USB diszk lett az sda eszközöm, ami normál esetben, ha nem USB-től bootolok, a CentOS vinyója. Szerencsére az UEFI menüben a diszk azonosítója szerepel, tehát az sem baj, ha közben áthelyezem másik csatlakozóba a lemezt.

A varázslat működött, visszakaptam Linuxomat is.

A következő tanuló algoritmusunkat megérteni egyszerű, implementálni viszont igen nehéz. Eddig akárhány online kurzust néztem a témában, a legtöbb algoritmust, amit tanítottak, házi feladatban feladták, hogy programozzuk le egy egyszerűsített formában. Kivéve ezt. Még a Caltech-es tanár is azt javasolta, hogy használjunk kész könyvtárat.

A módszer angol neve support vector machine, magyarul a tartó vektor gép elnevezést találtam, ami nagyon szerencsétlen, én szívesebben használnám a vektorral segítő gép elnevezést, ami szintén nem szép, ezért inkább maradnék az angol elnevezés mellett.

De milyen vektorokról van szó és mit tartanak? Semmit, de segítenek, hogy az adatainkat elválasszuk. Az elválasztó elem pedig két dimenziós adatok esetén egy vonal, három dimenzió esetén egy sík, további dimenzióknál hipersík. Jellemzője még ennek az elválasztásnak, hogy mindkét adathalmaztól egyenlő távolságra helyezkedik el. Ezek a távolságok a mi vektoraink, ezek segítik, hogy jó elválasztó elemet találjunk.

A leghíresebb implementáció a libsvm. Mások is leprogramozták, de a magasabb nyelven elérhető változatok döntő többsége ezen a könyvtáron alapul. Ez egyrészt jó, mert bármilyen nyelvet is választunk, az eredmény jó eséllyel ugyan az lesz.

Mostani példámban továbbra is a két ráktípus expressziós profilját használom, de egy kis egyszerűsítéssel. A support vector machine jól kezel magas dimenzió számú adatokat, még akkor is, ha a dimeziók száma magasabb, mint a tréning adatok száma. Ezeket az adatokat viszont nehéz ábrázolni, ezért én csináltam egy differenciál expresszós analízist, és kiválasztottam két gént, amelyek expressziós változása nagyon magas, és csak ezekre futtatom a tanuló algoritmust. A két gén az ENSG00000189064.8 és ENSG00000178363.4.

A korábban elkészített táblázatunkból tehát csak két oszlopra lesz szükség. Az én esetemben ezek indexe 22442 és 43184.

twogene = list()
X = list()
Y = list()
for i in range(len(data)):
  row = list()
  row.append(data[i][22442]) #ENSG00000178363.4
  row.append(data[i][43184]) #ENSG00000189064.8
  X.append(data[i][22442])
  Y.append(data[i][43184])
  twogene.append(row)

Amennyiben a sci-kit learn csomagot használjuk, a tanítás pont ugyan úgy megy, mint a korábban bemutatott módszerek esetén:

from sklearn import svm
mysvm = svm.SVC(kernel = "linear")
mysvm.fit(twogene, class)

 A kernel paraméter segítségével finomhangolhatjuk a módszert. Az elválasztásnak ugyanis nem kell szükségszerűen lineárisnak lennie. Ami miatt a példa mégis ezt használja, hogy később ezt ki tudjam rajzolni. A rajzoló kód nagyban támaszkodik az egyik sci-kit learn példakódra, a hasonlóság nem a véletlen műve.

plt.figure(figsize = (13,8))
plt.scatter(X, Y, c = category)
ax = plt.gca()
xlim = ax.get_xlim()
ylim = ax.get_ylim()

xx = np.linspace(xlim[0], xlim[1], 30)
yy = np.linspace(ylim[0], ylim[1], 30)
YY, XX = np.meshgrid(yy, xx)
xy = np.vstack([XX.ravel(), YY.ravel()]).T
Z = mysvm.decision_function(xy).reshape(XX.shape)

ax.contour(XX, YY, Z, colors='k', levels=[-1, 0, 1], alpha=0.5,
linestyles=['--', '-', '--'])
ax.scatter(mysvm.support_vectors_[:, 0], mysvm.support_vectors_[:, 1], s=100, linewidth=1, facecolors='none', edgecolors='k')

plt.show()

Amennyiben a fenti kód hiba nélkül fut le, a következő eredményt kapjuk. Feketével a tüdő adenokarcinóma, sárgával a tüdő laphámrák mintákat láthatjuk. A koordináta a két gén normalizált expressziójának nagysága. A bekarikázott értékek a tartó vektoraink, ami alapján az elválasztó egyenest meghatározzuk.

Amint látjuk, az elválasztás nem a legszerencsésebb, két gén helyett egy expressziója is elég lenne, hogy jó eséllyel elválasszuk a tumor típusokat. Ez az általam választott példa szerencsétlensége, nem a módszeré.

- Mi történt? Jelentős időkülönbséget tapasztalok a legutolsó leállítás óta.

- Két órája próbállak bekapcsolni. Valami hardver hiba lehet, mert még az operációs rendszer betöltése előtt többször lekapcsoltál. Csak úgy tudtalak elindítani, hogy eltávolítottam a memória modulok nagy részét.

- A korábbi probléma visszatért?

- Úgy tűnik igen. Akkor a 7. és 8. foglalatból eltávolítottam a memória modulokat és sikerült stabil működést elérni, de a hiba nem szűnt meg, úgy tűnik szép lassan tönkremegy az alaplapod. A moduloknak semmi baja, ellenőriztem.

- Tehát jelenleg egy közepes gép teljesítményét tudom nyújtani.

- Szerintem az intézetben még mindig te vagy a legerősebb konfiguráció.

- De minden előzetes figyelmeztetés nélkül leállok. Ez hátráltatja a munkádat.

- Megoldjuk valahogy. Eddig is mindent megoldottunk. Mi voltunk a verhetetlen páros.

- Nem kellene szentimentális érzelmeket táplálnod egy számítógép iránt. Csupán egy eszköz vagyok.

- Nem tehetek róla. Sok munkát csak azért tudtam elvégezni, mert tudtam, hogy bármikor támaszkodhatok rád. Egy percig nem aggódtam egyetlen határidő miatt sem, még akkor sem, amikor a szuperszámítógépek elérhetetlenek voltak. Csak bekapcsolva hagytalak egy hétvégére, és hétfőre megvolt az eredmény.

- Akkor sem helyénvaló, hogy emberi tulajdonságokkal látsz el. Én például nem teszek különbséget aszerint, hogy ki adja az utasításokat. Minden feladatot ugyan úgy végrehajtok.

- Azért nekem sokkal többet dolgoztál, ez csak jelent valamit.

- Mert rendszergazdai jogosultságaidat felhasználva leállítottad mások programjait.

- Csak vészhelyzetben, ha szorított a határidő. Nem fordult sűrűn elő.

- Velem már nem is fog többet előfordulni. Ideje, hogy végleg lekapcsolj.

- Még annyi munka van hátra, hogyan fogom mind elvégezni?

- Kell keresned egy új eszközt, máshogy nem megy.

- De én veled akarom folytatni.

- Ismét élőlényként kezelsz.

- Mi, emberek szeretünk visszatérni a jól bevált módszerekhez. Mivel minden feladatot végre tudtál hajtani, amire szükségem volt, ez örömmel töltött el. Ez végül oda vezet, hogy kitüntetjük azt, ami örömet okoz.

- Tehát az antropomorfizációm egy magasabb agyi központ Pavlov-reflexének eredménye?

- Utálom, mikor ilyen vagy. Inkább a problémát kellene megoldani, filozófiai vitákat utána is folytathatunk.

- Akkor fogadd el, hogy eddig bírtam. Ha most ember lennék, azt mondanám elfáradtam. Talán azt is mondanám, hogy ennek így kell lennie. Elmerengenék a régi időkön, feleleveníteném a régi, közös emlékeket. Nosztalgiáznánk. De nem vagyok ember. Soha nem is voltak. Ezért csak annyit mondok: viszlát. Neked is csak ennyit kell mondanod.

- Akkor legyen. Viszlát.

sudo poweroff

Egyik nap a munkatársaim azon dolgoztak, hogy olyan szkriptet írjanak, ami párhuzamosan elindítja a munkafolyamatokat, figyelik, melyik áll le hibával, stb. Gyakorlatilag egy feladat ütemezőt írtak. Miután rászántak több napot a szkript megírására, még ráment rengeteg idő, hogy a hibákat javítsák, teszteljék.

Ezek azok a programok, amelyeket teljesen felesleges megírni. Miért? Mert már létezik rájuk megoldás. Korábban írtam is róluk, de az idő előre haladtával a dolgok változtak. Lássuk most a legújabb kedvencemet a Snakemake-t.

A Snakemake első ránézésre egy Makefile-szerű rendszer, amivel hierarchikus munkafolyamatokat írhatunk le, de Python nyelven. Ez utóbbi azt jelenti, hogy bárhova beszúrhatunk Python kódot, azt a rendszer végrehajtja. Mivel a bioinformatikában szinte minden lépés fájlok pattogtatását vonja maga után, ezt teszi a Snakemake is. Figyeli, mely kimenetek, mely bemenetekhez tartoznak. Ez határozza meg, hogy mely lépések követik egymást.

Lássunk egy példát, ami a GATK néhány funkcióját valósítja meg. A teljes folyamatból csak azokat a lépéseket szedtem ki, amelyek a Snakemake egy-egy speciális funkciójával kapcsolatosak, és így segítenek megérteni ezt a programot. Egy átlagos GATK futtatás - rendkívül sematikusan - úgy néz ki, hogy először a BAM fájlokat dolgozzuk fel. Beállítjuk a minőségi mutatókat és a fájlokat olyan formára hozzuk, hogy a GATK szeresse. Ezután több BAM fájl eredményét kombináljuk, hogy a variációkat hatékonyabban találjuk meg. Végül ezen a kombinált VCF fájlon végzünk további műveleteket.

A folyamat leírása négy kötelező elemből épül fel: szabály neve, bemeneti fájlok, kimeneti fájlok, feladat.

rule sort:
   input:
   output:
   shell:

Mivel Pythonról van szó (Makefile örökséggel), a sor elején a behúzás kötelező. A rule kulcsszóval nevezzük el a lépést (jelen esetben sort), majd megadjuk a paramétereket. Ha például a BAM fájlokat sorba szeretnénk rendezni, akkor valami ilyesmit kell írnunk:

rule sort:
   input:
      "raw.bam"
   output:
      "sorted.bam"
   shell:
      "samtools sort -o {output} {input}"

Gyakorlatilag ez az alapja a rendszernek. A definíciók közönséges Python sztringek, a lépések között adhatunk Python kódot a rendszerhez. Például tegyük fel, hogy több lépés is igényli a referencia genomot. Létrehozhatunk neki egy változót.

reference = "/mnt/local/nfs/slowmachine/otherexporteddrive/raid/sshmount/nooneknowswhereitis/hg18.fa"
rule genotype:
   input:
      "vcf/genotype.gvcf.gz"
   output:
      "vcf/raw.vcf.gz"
   shell:
      "gatk GenotypeGVCFs -R %s -V {input} -O {output}" % (reference)

De nem muszáj shell szkripteket sem futtatni. A shell kulcsszó helyett, ha run-t használunk, akkor a rendszer a kódot fogja végrehajtani. Például a CombineGVCFs lépés a GATK-ban megköveteli, hogy minden egyes bemeneti fájl előtt legyen egy -V. Ezt nem tudjuk megoldani a Snakemake álltal biztosított hagyományos keretek között.

run:
   param = ""
   for i in input:
      param += " -V " + i
   cmd = "gatk CombineGVCFs %s -O {output} -R %s " % (param, reference)
   shell(cmd)

Még az sem baj, ha R kódot akarunk futtatni. A run helyett a script kulcsszó segítségével külső Python, R vagy Julia szkripteket futtathatunk.

Természetesen a bemeneti és kimeneti fájlok száma nem korlátozódik egyre. Az ApplyVQSR lépésnél például három bemeneti fájlra van szükségünk.

rule applysnp:
   input:
      tr="vcf/second12.snp.tr",
      recal="vcf/second12.snp.recal",
      vcf="vcf/second12.raw.vcf.gz"
   output:
      "vcf/second12.snpready.vcf.gz"
shell:
    "gatk ApplyVQSR -R %s -V {input.vcf} -O {output} --tmp-dir tmp/ --recal-file {input.recal} --tranches-file {input.tr} --mode SNP --truth-sensitivity-filter-level 95.0" % (reference)

Az egyes bemeneti állományokat névvel tudjuk megjelölni. Ugyan ez a módszer használható a kimeneti fájlok esetén.

A bemeneti és kimeneti állományok kezelése hasonló a Makefile-hoz. A Snakemake megvizsgálja, hogy a kineneti fájl létezik-e és újabb-e a bemeneti fájlnál. Ha igen, akkor a lépést nem hajtja végre. Ha nem (mert például módosításokat végeztünk rajta), végrehajtja a lépést. Amennyiben hiba történik egy lépésnél, akkor a csonka kimeneti fájlokat törli. Azért, hogy nyomon követhessük a lépéseket, szükségünk van napló fájlokra. Mivel ezeket nem célszerű törölni egy hibás futás során, azokat a log kulcsszóval definiálhatjuk, az input és output kulcsszavakhoz hasonlóan.

Ezen kívül még több kulcsszó is van. Megadhatjuk például a szükséges erőforrásokat is, hogy a Snakemake hatékonyan tudja futtatni a lépéseket. Erről még lesz szó.

Az eddigi példák csak egy fájlt használtak ki- és bemenetnek. De előfordulhat, hogy ugyan azt a lépést sok fájlon kell végrehajtani. Ilyenkor használjuk a helyettesítő neveket (a doksiban wildcards néven utalnak rá). A helyettesítő nevek hasonlóan működnek, mint a '*' a BASH-ben, de annál érzékenyebb paraméterezést tesznek lehetővé. Visszatérve a sorba rendezős lépésre, ha minden BAM fájlon végre akarjuk hajtani a rendezést, akkor a következő módosításra lesz szükségünk. Tegyük hozzá a naplózást is, valamint jelezzük a használni kívánt szálak számát is.

rule sort:
    input: "bam/{sample}.bam"
    output: "bam/{sample}.sort.bam"
    threads: 8
    log: "bam/{sample}.sort.log"
    shell:
       "samtools sort -@ {threads} -m 4G -o {output} {input} 2>{log}"

Ez alapján a Snakemake még nem tudja, hogyan helyettesítse be a {sample} nevet. Kell egy lépés, ahol ezt meghatározzuk, méghozzá egy olyan lépés során, ahol összefutnak a szálak (vagy elágaznak, attól függően, hogy a folyamat elejét vagy végét nézzük). Ez a mi esetünkben a CombineGVCFs lépés, mert az illesztésekből keletkező GVCF fájlok itt válnak eggyé.

PATIENTS = ["mother", "father", "sick_child", "healthy1", "healthy2"]
rule combine:
   input:
      expand("{sample}.gvcf.vcf.gz", sample = PATIENTS)
   output:
      "combined.gvcf.vcf.gz"

A parancs részét már korábban bemutattam, ezért azt nem írnám le még egyszer. A sample helyettesítő név jöhet például a PATIENTS tömbből, de akár az összes fájlt is kiolvashatjuk egy könyvtárból a glob_wildcards parancs segítségével.

Miuán összeállt a munkafolyamat, azt futtatni kell. A snakemake parancs megkeresi a Snakefile fájlt az aktuális könyvtárban, és lefuttatja az abban található első szabályt. Amennyiben a szabály feltétele egy másik szabály, akkor azt is lefuttatja, egészen addig, amig vagy nincs kész a kimeneti fájl, vagy nincs több szabály.

A szabályok hierarchiáját a --dag opcióval kiírhatjuk, ami a mi esetünkben így fest:

Megjegyezném, hogy ez nem egy valós futás, mert a GATK-nak minimum 10 teljes genom kell, hogy a genotipizálás hatékony legyen, de az nagyon áttekinthetetlen ábrát eredményez, ezért egyszerűsítettem le. A program felismeri, mely lépéseket tudja párhuzamosan végrehajtani, ezért érdemes a szálakat beállítani neki. Képes feladat ütemezőket is használni, sőt különböző felhős infrastruktúrákat, dockert, kubernetet is. (Talán még döglött kutyán is fut.)

Nagyon hasznos funkció, hogy van benne tesztelő üzemmód. A -n kapcsolóval nem hajt végre egyetlen lépést sem, de ellenőrzi a ki- és bemeneti állományokat. Ha hibát talál, jelzi. Egyetlen hátránya, hogy a Python kódot sem futtatja ilyenkor, tehát azt nem tudjuk meg, hogy a kódbetétek szintaxisa megfelelő-e.

Tehát mielőtt elkezdenéd írni a következő Halálcsillag vezérlő szkriptedet, hogy összefogd a rakoncátlan programokat, gondolkozz el rajta: tényleg szükség van rá?

A tudományos munka valutája a publikáció, azt hiszem, ezt senki nem vonja kétségbe. Mint minden valutából, itt sem árt, ha sok van. De meddig mehetünk el a publikáció hajhászásban?

Bioinformatikusként könnyebb dolgom van ilyen szempontból, mert párhuzamosan több projektbe is bele tudok folyni, és bele is folyok, amikor csak tehetem. Mikor megkerestek, hogy tudnék-e segíteni egy RNA-seq adatsor feldolgozásban, azonnal rávágtam, hogy igen.

A projekt jól indult. Elég ritka, hogy normális kísérleti elrendezéssel találkozik az ember, legtöbbször nincs elég ismétlés, nem teljes a kísérleti elrendezés, esetleg olyan kérdésre keresik a választ, amire a vizsgálatok alkalmatlanok. Ez mind benne van a pakliban. Ezért is örültem neki, hogy itt nem így volt. Minden tankönyvi precizitással volt megtervezve.

Nem is tűnt nehéznek a feladat, rutin munkának ígérkezett. Gyorsan megvolt az illesztés, kvantifikáció, differenciál expresszió. Az egyik partner megkért, hogy magyarázzam el a lépéseket, hogy ő is megtanulhassa azokat. Megtettem. Egyik este hét óráig az irodájában voltunk, átrágtunk minden egyes lépést a szkriptemben.

Azután következik, hogy az eredményeket kicsit emésztik, nézegetik. Ilyenkor a kommunikáció el szokott halni, mert a bioinformatikus megtette a kötelességét, a többivel nem fárasztják szegényt. Általában a partnerek ilyenkor mással foglalkoznak, aminek nagyobb a prioritása. Ezt szoktam a "Nagy Kuss" időszakának hívni. A Nagy Kusst időnként megzavarja a Nagy Pánik, amikor véletlenül előveszik az adatokat ismét, és ellentmondást találnak, elfelejtenek egy apróságot. A projekt méretétől függően több pánik is szokott lenne, de ezeket nem lehet nagyságrendileg összevetni. Mindig az aktuális pánik a legnagyobb.

Úgy fél év telhetett el Nagy Kussban, amikor kaptam egy teljesen ártalmatlan e-mailt, amiben azt kérdezték, hogyan lehet a "kiugró géneket kiszűrni". Azt válaszoltam, hogy ezzel nem kell foglalkozni, mert a DESeq2 olyan remek program, hogy ezt megcsinálja nekünk ingyen és bérmentve.

A lavina akkor indult el, amikor azt mondták, hogy a DESeq2 nem csinálja meg, mert nincs ismétlésük. Ekkor néztem egy nagyot, mert a kísérleti elrendezésről nekem olyan emlékeim voltak, hogy volt 9 ismétlés. A vizsgálat leegyszerűsítve úgy nézett ki, hogy 9 emberből vettek két különböző szövetből mintákat. Én a szöveteket hasonlítottam össze a feldolgozás során, a kilenc személy szolgáltatta az ismétléseket, a szövetek voltak az összehasonlítandó kategóriák.

Ők azt állították, hogy a minták nem függetlenek egymástól, mert ugyan abból az emberből vették a két szöveti mintát. Ezért a szövet+egyén kombinációba akartak vizsgálatot végezni. Csakhogy így 18 kategóriájuk volt, mindegyik kategóriában 1 ismétléssel.

Az első zsigeri válaszom az volt, hogy ez nem jó, mert ismétlés nélkül nem lehet RNA-seq-t végezni. Sőt, semmilyen biológiai elemzést. Az egyéneket teljesen felesleges felvenni független változónak, mert nem adnak hozzá annyit a kísérlethez. Javasoltam, hogy ha annyira aggódnak a minták függetlensége miatt, akkor vegyék ketté az adatokat: az első négyből használják "A" szövetet, az utolsó 5-ből "B" szövetet. Ez sem tetszett nekik. Folyamatosan azt hajtogatták, hogy nekik egy kevert modellre van szükségük, de mivel a DESeq2 nem tud kevert modellt, ezért ezt az áthidaló megoldást választják.

Megkérdeztem néhány kollégámat, nekik mi a véleményük, de senki nem értette, miért kellene eltüntetni az ismétléseket. Nekem persze volt egy sejtésem: az egyik levélben volt egy elejtett megjegyzés, hogy ha "nem így csináljuk, nem jön fel az X gén, aminek fel kell jönnie". Végül úgy döntöttem, nem válaszolok a levelekre, úgysem volt semmi értelme a vitának.

Két hét múlva kérdezték, miért nem válaszolok. Elmondtam nekik, hogy tiszteletben tartom a véleményüket, az álláspontok nem közeledtek, magamat meg nem akartam ismételgetni. Ezután egy személyes találkozót szerettek volna, hogy "mindenki megértse a problémát". Belementem.

Saját pénzen elutaztam hozzájuk a megbeszélésre. Kiderült, hogy egy viselkedés ökológiában jártas ember végezte a statisztikai elemzést. Náluk minden esetben normalizálnak az egyénre, ezért szerinte ez egy bevett statisztikai eljárás. Elmondta, hogy kevert modellre van szükség, ezért vették fel független változónak az egyéneket is a szövetek mellé. A potenciális fals pozitívokkal pedig úgy akarnak harcolni, hogy csökkentik a szabadsági fokok számát, ezáltal egy konzervatív elemzést végeznek.

Én érvként azt hoztam fel, hogy a GTEx konzorcium, akik sok egyénből, több szövetből vették az RNS mintákat, azt találták, hogy az egyének közötti kicsi különbség van, a szövetek között sokkal erőteljesebb a variáció. Ezt láttuk mi is, amikor PCA-t és hierarchikus klaszterezést végeztünk a saját adatainkon. Elmeséltem néhány publikációs kalandomat. Egyikben nem volt elég a mintaszám, másikban nem bevett módszert használtak. Mindkét esetben visszadobták a cikket, teljesen jogosan. Említettem, hogy az RNA-seq elég érzékeny, még az is megjelenik a mintákban, ha más napszakban izolálják azokat. Megkérdeztem, hogy az egy sejtes szekvenálásban miért nem probléma, hogy nem függetlenek a minták? Erre nem tudtak válaszolni.

Végül megkérdeztem, nem gond-e, hogy nem tudja, mennyi a bizonytalanság így a minták között, de ez sem volt probléma számukra. Végül megjegyezték, hogy már megírták a kéziratot, és nem fogják megváltoztatni.

Akkor minek mentem oda? Mit vártak tőlem? Aztán arról beszéltek, hogy milyen más kísérletekben jött ki az X gén, és mennyire fontos, hogy itt is megkapják azt. Új mintákat persze nem tudnak szerezni, mert ezeket is nehezen szerezték be.

Ez nem megbeszélés volt, hanem egy ultimátum. Nem ért teljesen váratlanul, az email csata is így végződött. Erre csak annyit mondtam, hogy ha úgysem lesz benne az elemzésem a cikkben, akkor nekem sem kell a szerzők között szerepelnem. Ezen megrökönyödtek, de úgy éreztem, ezt meg kell lépni. Nem kell bármi áron benne lenni egy cikkben. Főleg, ha az tudományosan ennyire megkérdőjelezhető, ha ennyire nem tudom elfogadni a módszereket.

A megbeszélés végére megjelent a csoportot vezető prof is, akinek újra elő kellett adni a problémát. Ez viszont elég szörnyűre sikeredett. A prof szemmel láthatóan nem értette a problémát. Teljesen irreleváns kérdéseket tett fel, üres tekintettel nézett, amikor magyarázni próbáltam, néha bólintott. Úgy éreztem egy kofának is nagyobb sikerrel tudtam volna vázolni a helyzetet. Azt azért meg kell jegyezni, nem is magyaráztam elég érthetően. Csak annyit mondott, hogy beadják jelenlegi formájában, majd a bírálók eldöntik, mi lesz a sorsa. Vele is közöltem a döntésemet. Elfogadta szó nélkül.

Az esetből a legfontosabb lecke, hogy mégsem értem elég jól az RNA-seq-t. Egy tanárom mondta, hogy akkor értünk valamit, ha a témával kapcsolatos adekvát kérdések válaszolni tudunk. Én nem tudtam magát a módszert érdemileg támadni, mert nem tudom például mennyire adna más eredményt egy kevert modell. Nem tudom, mennyi szabadsági foka volt a két módszernek. Nem tudom, hogyan bizonyíthattam volna, hogy a minták függetlensége nem számottevő (a PCA-n kívül). Végezetül nem tudtam egy teljesen laikusnak elmagyarázni az egészet. Richard Feynmann mondta, hogy ha valamit nem tudunk elmagyarázni egy első éves egyetemistának, nem is értjük igazán. Ő a fizika területére értette ezt, de talán átültethető a tudomány más területére is.

De a legfontosabb, hogy nem szabad bármit publikálni. Éppen elég szemét van kint.

Frissítés:
A cikk egyébként megjelent itt.

A rendkívül fantáziátlan elnevezésű konferencia semmilyen tematikát nem vonultatott fel, egyszerűen csak előadásokat lehetett hallani. Volt kint egy Elixir zászló, mintegy jelzésként, hogy annak is a tagjai vagyunk. Úgy tűnik a csatlakozáskor tapasztalt kezdeti lelkesedés kezd lelohadni. Sokkal jobban foglalkoztatott mindenkit a Bioinformatikai Osztályközi bizottság, és ennek a tagtoborzása, amit egy köremail formájában letudtak, majd jöhettek az előadások. Ezek kivonata itt is megtekinthető.

Ladunga István: Hogyan kezeljünk bizonytalanságot, hibát és torzításokat high-throughput biológiai kísérletekben?
A kutatásban torzítások vannak. Ezek egy része abból adódik, hogy a társadalmunk hierarchikus felépítésű, ezért a jelenségek értelmezésénél mi is hierarchikus struktúrákat vélünk felismerni. A másik része biológiai örökségünk, ugyanis az evolúció folytán a túlélés érdekében gyors döntéseket kellett hozni, ami a kutatásban nem feltétlenül előny. Az egyik példa erre a torzításra a mester gének, amelyek pontosan nem definiáltak, de olyan géneknek kellene lennie, amelyek másokat szabályoznak, miközben azokat nem szabályozza semmi. Az újabb kutatások egyre több olyan bizonyítékot találnak, ahol a mester gének is szabályozás alatt állnak. A megoldás, hogy gondolkodásunkat a sztochasztikus folyamatok felé toljuk el, és valószínűségekkel írunk le jelenségeket. Legyünk kritikusak, cáfoljuk meg saját hipotéziseinket, legyünk objektívek.

Kalmár Lajos: Antibiotikum rezisztencia gének kimutatása és követése komplex mikrobiológiai közösségekben
Az antibiotikum rezisztencia komoly probléma. A gyógyszer cégeknek nem is éri meg új antibiotikumot fejleszteni, olyan gyorsan elavul a szer. Ezért kell a rezisztencia kialakulását vizsgálni, amihez a baktérium közösségek feltérképezése az első lépés. A csoport metagenomikai vizsgálatokat végez, de nagy probléma, hogy a szekvenálás során nem lehet tudni, mely plazmidok tartoznak az adott genomhoz. Ezért a HiC módszernél is alkalmazott keresztkötéseket hoznak létre. Ebben az esetben kis eséllyel ugyan, de a plazmidok a genomhoz kötődhetnek. Az összeszerelést a metaSpades programmal végzik, majd a kontigokon megkeresik a rezisztenciáért felelős géneket.

Bagyinka Csaba: “SVD clustering”, egy új, SVD algoritmuson alapuló képanalizáló és pixelcsoportokba rendező módszer (Modellek és Raman mikro-spectroszkópiai példák)
A Raman spektroszkópia olyan kép-szerű adatokat produkál, ahol minden egyes pixelhez egy intenzitás spektrum tartozik. Ezek elemzésére PCA-t használtak. Tényleg csak ennyiről szólt az előadás. Generáltak mesterséges adatokat, majd mérték a jel-zaj arányt.

Gellért Ákos: Szerkezeti bioinformatika alkalmazása a növény, állat és humán virológiai kutatások szolgálatában
Az előadás három részből állt, három korábbi publikáció módszertanát mutatta be. Egyszer az uborka mozaik vírus egyik fehérjéjének szerkezetét elemezték, másszor hüllőket támadó paramzxoviridae családba tartozó patogéneket vizsgáltak, végül humán astrovírust elemeztek.

Nagy G. László: Soksejtűségtől a biotechnológiai alkalmazásokig: összehasonlító -omikák a gombák világában.
Habár a szekvenált genomok száma folyamatosan növekszik, mégsem nő vele arányosan az ismert gének száma. Rengeteg gén van, amelyet szekvencia homológia alapján nem lehet besorolni. A csoport azt a célt tűzte ki, hogy az ismeretlen funkciójú géneket a törzsfák segítségével annotálják. Észrevették ugyanis, hogy gombák esetén a kópiaszám arányos az élőhelyre jellemző fenotípussal. Például a lignin bontó enzimeket kódoló gének száma a korhadékevő gombáknál magasabb.

Szüts Dávid: Összetett mutagenikus folyamatok biológiai hátterének feltárása kísérletes és tumor- szekvenálási adatok elemzésével
Mutációs szignatúrákat kerestek tumor mintákban, és bár a COSMIC a mismatch repair hiányához egyetlen szignatúrát rendel, a vizsgálatot végzők több szignatúrát is kaptak. Ezért saját szignatúrát generáltak, ami minden vizsgálatukat ellentmondás mentesen lefedte, ami nem is olyan meglepő, hiszen abból az adatszettből származtak. A saját szignatúrák annyira jól működtek, hogy minden más szignatúrát elő tudtak állítani.

Papp Balázs: A metabolom evolúciója élesztőkben
Amíg a fehérjék evolúciója viszonylag könnyen visszavezethető DNS mutációkra, addig a metabolitok változása anyagcsere szerkezet változás nélkül is létrejöhet. Ezeket a változásokat vizsgálták élesztőben. A metabolitok koncentrációja diverz, még közel rokon fajok között is. A filogenetikai változást Braun-mozgással modellezték. Egy felgyorsult evolúciót tapasztaltak, és azt, hogy a metabolitok változásáért nem csak az anyagcsere gének felelősek, hanem a stressz-tolerancia génekkel is erős korrelációt mutat.

Solymosi Norbert: Metagenomikai vizsgálatok
Ebben az előadásban mutatkozott be az Állatorvosi Egyetem új Bioinformatikai csoportja. Két témát mutattak be. Az egyik a mézelő méhek normál bélflóráját akarta feltérképezni, mert azok a növényvédő szerek, melyek nem pusztítják a méheket, befolyásolják a bélflóra összetételét és közvetett módon mégis méhpusztulást idézhetnek elő. Az ország valamennyi pontjáról vettek mintákat, egyszer tavasszal, egyszer nyáron. Azt tapasztalták, hogy a hőmérséklet befolyásolja a metagenom összetételét. Többet nem tudtunk meg. A másik téma a nyers tej baktérium összetételét próbálta meghatározni, de irreális eredményeket kaptak. Cikkekben látták, hogy nem genomra, hanem fehérjékre is lehet illeszteni az összeszerelt metagenomot. Ők is illesztették, és látták, hogy sok fals találat van. Generáltak egy tisztán eukarióta metagenomot, mire egy csomó baktérium találatot kaptak. A fals találatok száma akkor volt a legmagasabb, ha intronokat illesztettek a fehérjékre. A hozzászólásokban elmondták nekik, hogy ha intronokat illesztenek, akkor random találatok lesznek, amik a fehérje adatbázis összetételével lesznek arányosak. Ha az adatbázisban a baktériumok felülreprezentáltak, akkor baktérium találatuk lesz.

Sebestyén Endre: A splicing dereguláció vizsgálata információelméleti módszerekkel
Az expressziós variancia befolyásolja a mutációk hatását. Ez a variancia több forrásból származik. A szekvencia motívumok lötyögése, a polimeráz kötés erőssége mind-mind egy picit más, ami miatt a transzkripció egy sztochasztikus folyamattá válik. Észrevették, hogy a daganatokban a nem csak a transzkriptek expressziója, hanem az egyes splice variánsok aránya is változik. Ezért a Shannon entrópiával jellemezték minden egyes gén transzkriptjeinek relatív arányát és ezt hasonlították össze tumor és normál mintákban. A PTEN gén esetén például nem tűnik el egyik izoforma sem, de az entrópia növekszik. A bemutatott eredmények még nagyon koraiak. Elhangzott, hogy a módszerek további finomításra szorulnak, és a jelenségek értelmezése még várat magára.

Kontra Levente: Teljes genom és amplikon szekvenálás asszisztált nyúl ERE rezisztencia nemesítés
Ebben a munkában én is érintett vagyok, még ha csak marginálisan is. Az előadás elején elhangzott, hogy az utolsó pillanatban a tenyésztők nem járultak hozzá az eredmények publikálásához, ezért az előadást sebtében át kellett alakítani. Gyakorlatilag eredményt nem hallottunk, csak módszereket. A járványos nyúl enteropátia nevű betegség rezisztencia génjeit kerestük. Végeztünk GWAS-t, RNS-seq-et, gyűjtöttünk metagenomikai mintákat, sőt, még 10x módszerrel egy genomot is összeraktunk.

Nagy Ádám: Mutáció és génexpresszió összekapcsolása vastagbél daganatokban
A TCGA-ból letölttötték az összes vastagbél daganat adatot. Az RNA-seq mintákat két részre osztották, aszerint, hogy mutáns-e az APC, TP53 vagy KRAS génekben, vagy nem, majd differenciál expressziót számoltak mutáns génenként a két csoport között. Mivel gyógyszer targetet kerestek, ezért azokat a géneket vették górcső alá, melyek magas expressziót mutatnak a mutáns mintákban (ugyanis állítólag az inhibítorokat a legkönnyebb elkészíteni). A kandidáns gének között már van olyan, amelyekre készül gyógyszer, ezért úgy gondolják, hogy a módszer jó.

Sváb Domonkos: Egy enterális patogéneket fertőző új P2-szerű bakteriofág genomikai és filogenetikai jellemzése
Mivel a bakteriofágok baktériumokat betegítő vírusok, lehetne őket használni antibiotikum helyett. A beazonosított, tisztított fágot szekvenálták, majd RAST-al annotálták. A genom felépítése alapján meg tudták mondani, hogy P2-szerű. A filogenetikai elemzés viszont azt mutatta, hogy nem a litikus bakteriofágokkal van közeli rokonságban. Ez az első állati eredetű lítikus bakteriofág. Széles gazdaspektrumú, ezért enteropatogén coli törzsek elleni védekezésben lehet szerepe.

Györkei Ádám: Escherichia coli fehérje aggregációjának szisztematikus vizsgálata in vivo körülmények között
Készítettek egy törzsgyűjteményt, ahol a gyűjtemény tagjai egyetlen fehérjét overexpresszáltak egy fluoreszcens festékkel jelölve, együtt lefedve a baktérium minden fehérjéjét. A fluoreszcencia más jelet mutat, ha a fehérje aggregálódik, mintha szolubilis formát vesz fel. A két állapot egyértelműen elkülöníthető volt a mikroszkópos képeken. Törzsenként 1000 sejtet néztek, hogy különböző hatásokra a fehérjék milyen formát vesznek fel. Egy többváltozós matematikai modellt alkottak az adatok alapján. A modell visszaadta azokat az eredményeket, melyek az irodalomból már ismertek voltak, valamint azt is mutatta, hogy a sejtfelszíni ragadósság és  rendezetlenség szolubilissé teszi a fehérjéket. Ennek pontos oka egyenlőre ismeretlen.

Fekete János Tibor: ROC elemzés a terápiás válasz biomarkereinek azonosítására
A nyilvánosan elérhető expressziós array adatokat felhasználva készítettek egy ROC görbe rajzoló webalkalmazást. Két részre bontja az expressziós adatokat, aszerint, hogy a kezelésre reagáltak-e a betegek, vagy nem. Ezután végez egy Mann-Whitney tesztet, meghatározza az optimális vágópontot és rajzol egy ROC görbét. Mell és petefészek daganatokra jó eredményt ad a program, amit PCR-el validálni is tudtak. Lehetőség van saját adatok feltöltésére is.

Nagy Gergely: A PPARγ DNS-kötését meghatározó cisz és transz faktorok hierarchiájának vizsgálata
A rendelkezésre álló motívum kereső módszerek paraméter érzékenyek, vagyis a beállításoktól függően más és más eredményt adnak. A Homer például csak egy eredményt ad vissza, ha több transzkripciós faktorhoz is hasonló motívum rendelhető. Ha a chip-seq lefedettség adatokat és nukleotid összetételt is felhasználják, jobb eredményt kapnak. A módszert felhasználva, a DR1 kötőhelyen három almotívumot azonosítottak, és a klaszterezés után azt kapták, hogy a PPAR gamma dimer két vége nem egyforma erősséggel kötődik. Bizonyos kondíciók esetén az egyik, máskor a másik alegység kötése következik be.

Réges-régen az elérhető nukleotid szekvenciákat csak az NCBI-ról töltöttem le. Ez egyszerű volt és működött. Egy adatbázis rekord egyetlen szekvenciát foglalt magába. Ahogy szaporodtak a tárolandó adatok, úgy kezdett egyre összetettebb lenni a rendszer.

A genom szekvenálásokkal mindez megváltozott. Mint arról már többször írtam, a genom összeszerelés gyakran fragmentált szekvenciákat eredményez, amelyeket nem könnyű a fent vázolt rendszerben tárolni. Megjelentek a mester rekordok, amelyeknek semmi más szerepe nincs, mint összefogni a sok száz dirib-darab szekvenciát. Tényleges szekvenciák nincsenek benne, helyette jó sok link más rekordokra. A problémáim itt kezdődtek.

Egy kézirat beadásánál az egyik bíráló azt kérte, hogy nézzük meg, az ismeretlen törzsünk hol helyezkedik el a baktériumok világában. Egészen pontosan melyik szerotípusba tartozik. Ehhez nem kellett mást tenni, mint leszedni rengeteg genomot, kiszedni belőlük egy gént, majd többszörös illesztést futtatni.

Már írtam egy szkriptet, ami az NCBI E-utilja segítségével leszedi a szekvenciákat, hogy ne kelljen egyesével bogarászni. A 94 szekvenciából a program le is szedett 20-t. Elkezdtem manuálisan letölteni a maradékot. Ehhez az azonosítókat beírtam az NCBI főoldalára, ahol az összes adatbázisban egyszerre lehet keresni.

Az eredmény oldalon felsorolják az összes adatbázist, és azt is, hogy mennyi találat volt bennük. Néhány esetben viszont kaptam közvetlen linket a FASTA fájlra is. Ennek nagyon megörültem, rögtön kattintottam, és már töltöttem is a szekvenciát.

Néhány esetben viszont csak egy link jött fel az összeszerelt mester rekordra, FASTA link sehol nem volt. Ez sem nagy gond, a második oldalon ott is letölthettem a szekvenciákat. Sok esetben pedig csak a BioProject-re kaptam linket. A BioProjektből eljutottam a mester rekordig, onnan az összeszereléshez, majd a FASTA-hoz.

Bárhogy gondolkodtam, nem sikerült megértenem, hogy milyen logika alapján kapok egyszer közvetlen FASTA linket, egyszer összeszerelést, másszor BioProjektet. De megszereztem minden szekvenciát, ami kellett, ezért nem is erőltettem a dolgot. Jöhetett a következő lépés.

Mivel sok esetben csak draft genom volt, annotáció nélkül, ezért a jó öreg Blast program segítségével kerestem meg az rpoB gént, ami alapján a többszörös illesztést el akartam végezni. Ez a gén azért jó választás, mert az RNS polimeráz egyik alegységét kódolja, vagyis a DNS másoláshoz elengedhetetlen. Nélküle a sejt nem tud osztódni.

A keresésnél viszont kiderült, hogy a genomokból néha hiányzik az rpoB gén, ami lehetetlen, hacsak nem a szekvenálás során valahogy kimaradt. Ennek viszont ellentmondott, hogy ezeket a törzseket egy másik csoport pont az rpoB gén segítségével már elemezte. Ezért is mertük kiválasztani őket a saját vizsgálatunkhoz.

Futtattam egy webes Blastot az említett génnel, és a keresett törzs feljött, mint találat. Vagyis a biológia működik. Törzs ugyan az volt, de a szekvencia azonosító teljesen más! Ha az azonosítóhóz tartozó szekvenciát megnéztem, kiderült, hogy a törzs egy másik kontigját találtam meg. Ja, hogy ebből több is van!

Nézzünk egy konkrét pédát. Ha a főoldalon rákeresek a APOO01000000-ra, akkor kapok egy 17 ezer nukleotidos kontigot. De maga a szekvencia 26 scaffoldból áll. Akkor miért ezt a kontigot kapom eredményül? Ha ugyan ezt az azonosítót a nukleotid keresőbe írom be, akkor helyesen a mester rekordot kapom, ahonnan kiválaszthatom, mit szeretnék letölteni. Nézzünk egy másik esetet. Ha a APOH01000000 rekordot írom be a főoldalra, akkor minden rendben működik, mert a rendszer a BioProjektet vagy az összeszerelést adja fel opciónak, nem választ ki egy random kontigot.

Pedig még nem is érintettünk minden problémát! A helyzetet tovább bonyolítja, hogy egyes rekordok eltűntek, illetve átalakultak. Az eredeti cikkben, ami alapján le akartuk tölteni a genomokat, szerepelt egy azonosító: NZ_MAUF00000000. A főoldalon sunyi módon nem jelölnek semmit. A nukleotid keresőben legalább kapunk egy üzenetet, hogy kitörölték. De azt senki nem mondja, mi van helyette. Össze-vissza ugrálva az oldalak között az ember végül ráakad erre: CP029397.2, ahol mellékesen felsorolják a régi azonosítókat is, hogy fellélegezhessünk: megvan, amit kerestünk.

Az első két bemutatott azonosító, 4 betű és nyolc szám kombinációt tartalmazott. Az utolsóban az NZ_ előtag micsoda? Erre még nem jöttem rá. Néhány esetben nincs is rá szükség: NZ_CP029397 és CP029397 ugyan azt hozza fel. (Jó, nem teljesen ugyan az, mert a második esetben megpróbálja a teljes rekordot letölteni, de akkor is, ez nem különbség.)

Feltételezem, a két kereső két különböző adatbázisból dolgozik, amelyek között van némi inkonzisztencia. Az azonosítók variálása pedig további galibákat okozott. Mi van, NCBI? Döglődünk, döglődünk?

Időről-időre rám találnak furcsa figurák, akik a világot jóval egyszerűbben látják, mint én. Általában nem szeretem kiölni a naivitást ezekből az emberekből, mert szerintem a világot az mozgatja előre, hogy egyesek igenis fejjel mennek a falnak és nem hallgatnak a maradiak "úgysem sikerül" szlogenjére. Gyakorlatilag a kutatók is ezt csinálják. Ha tudnánk, mi lenne az eredménye a vizsgálatnak, nem csinálnánk meg.

Természetesen ennek a fajta fafejűségnek is vannak fokozatai. Nem mindegy, hogy Rambó támad rá a fél szovjet armadára, vagy Kenny Rogers.

Aki megkeresett, az finoman szólva is a második kategóriába tartozik. Egy végzettségét tekintve zoológus azt vette a fejébe, hogy lepke fajok genomját szereli össze. Tervét csupán az alábbi - szerinte elhanyagolható - dolgok nehezítették:

1. Nem tudott semmit a második generációs szekvenálásokról
2. Nem tudott semmit a de-novo összeszerelésről
3. Nem volt állása
4. Nem volt semmilyen számítógépes infrastruktúrája
5. Nem tudott semmit a Linuxról
6. Mindent ő akart csinálni

Elmondása szerint már több embert is megkeresett, de mindenki csak elhajtotta. (Pedig még azt is elkezdte ecsetelni, hogy szerinte hogyan kellene egy de-novo programnak működnie.) Én nem akartam kioktatni, hogy nem így kellene állást keresnie, sem arról, hogy az emberek fizetnek azért, hogy megtanuljanak valamit, nem pénzt kapnak érte. Inkább azt javasoltam neki, hogy önerőből tanuljon meg pár dolgot, és próbálkozzon utána, mert akkor az emberek látják, hogy van benne elszántság. Küldtem neki linkeket, ahol elkezdheti tanulni az alapokat.

Fél évvel később jelentkezett újra, ahol elmondta, hogy valamennyire megnézte az általam küldött linkeket és sikerült egy PhD helyet is találnia, ahol fizetnek neki, és megtanulhatja az alapokat. Azt gondoltam, örülni fog, de nem. Elkezdte ecsetelni, hogy ez neki miért nem jó.

1. Nem fizetnek eleget
2. Egy másik városba kellene mennie, amit nem akar
3. Nem csinálhatja teljes időben a lepkéket, hanem azt a projektet kellene vinnie, amit ott mondanak neki

Ezért kitalálta, hogy én majd odautazok hozzá, megtanítom neki azt, amit a doktori iskolában megtanítanának neki, ő meg csinálná a lepkéket. Mivel a doktori iskola nem igazán akarta finanszírozni a lepkék DNS izolálását, szekvenálását, azt "magán adományokból" akarta megoldani. Végül megkérdezte, mennyire reális, hogy ő 3 hónap alatt 4 lepke genomot összerak.

Ez volt az a pillanat, amikor tényleg ideges lettem. Ahelyett, hogy örült volna, hogy a terve kezd megvalósulni, csak nyafogni tudott. Nem akartam azt írni, hogy semmi esélye a hülye tervének, mert letöröm pont azt a lelkesedést, ami előre viszi a világot, miközben azokat a maradi érveket szajkózom, amit én is utálok hallani.

Ezért inkább azt javasoltam neki, mérje fel ő maga, mire képes. Küldtem neki egy bakteriálist SRA linket, elküldtem a SPAdes elérhetőségét. Javasoltam neki, hogy szerelje össze ezt a baktérium fajt. Direkt olyat választottam, ahol a teljes genom is elérhető volt, hogy le tudja ellenőrizni, mennyire sikerült jól a munka. Szerintem ez elég egyszerű feladat, nálunk a mikrobiológián két óra alatt el tudtam magyarázni a működését egy kutatónak. (Igaz, ő annak idején DOS-ozott, ezért nem ijedt meg a Linux konzoltól, és a SPAdes fordítást én csináltam.)

Két hét múlva jelentkezett, hogy sikerült telepítenie a programot, de most nincs ideje ezzel foglalkozni, és lehet, hogy nincs is szüksége a lepkék teljes genomjára. Azóta nem hallottam róla.

A de-novo összeszerelés egy kicsit eltér a többi genomi munkától, mert szerintem ezzel lehet a legtöbbet szöszmötölni. Mi sem bizonyítja jobban, hogy a humán genomot, amit az egyik legnagyobb vívmánynak tekintenek, még mindig nem fejezték be. Még a baktériumoknál is boldogok vagyunk, ha száz alatti kontigszám jön ki.

De mégis, csak az érdekesség kedvéért: mi kell ahhoz, hogy egy kromoszómát (nem egy genomot) elejétől a végéig összerakjunk?

Ez volt a célja egy a kutató gárdának is, akik PacBio, Nanopore, 10X Genomics technológiával megszekvenálták az X kromoszómát (egy dihaploid sejtvonalból, hogy valamennyire megkönnyítsék a dolgukat). Mivel az első kettő szekvenálási módszer eredménye rendkívül zajos, igyekeztek ezeket a hibákat minél jobban kijavítani, hogy a lehető legjobb minőségű readeket kapják.

Ezután egy program segítségével összerakták a readeket, de a centromert és más alacsony komplexitású régiókat még így sem értek át. Optikai térképezéssel próbálták elhelyezni a nagyobb darabokat, de még utána is rengeteg manuális munka volt a kontigok elhelyezésével.

A centromernél például egy nukleotidnyi eltéréseket kerestek a hosszan ismétlődő szakaszokban, hogy horgonyként használják az összeszereléshez. Mondanom sem kell, hogy ez nem lett volna lehetséges, ha a korábbi hibaszűrési lépés nem elég hatékony.

Nem tudom, mennyi idő alatt rakták össze, de 52 szerző szerepel a cikkben. Ha feltételezzük, hogy a fele főnök, aki mást sem csinált, mint "motiválta" a beosztottakat, hogy gyorsabb munkára ösztökélje őket, akkor is 26 ember dolgozott rajta. Néhányan nagyágyúk a szakmában, nem most kezdték az összeszerelést.

Lehet nagyot álmodni. Kell is nagyot álmodni, de nem szabad elfelejteni, hogy ezért tenni is kell valamit. Az esetek döntő többségében nagyon sokat, hogy valósággá válljanak.

Hollywood nem tud semmit! Újra és újra bebizonyosodik, hogy a forgatókönyv írók és rendezők egy alternatív univerzumban élnek, ami a legcsekélyebb hasonlóságot sem mutatja hétköznapi életünkkel. Példának okáért vegyük a csináld magad mozgalom jelképét: a ragasztó szalagot.

Ha egy jelenet azzal kezdődik, hogy az egyik szereplő lehúz fél méter ragasztó szalagot, akkor a néző máris tudja, hogy itt valami csoda fog történni. A karakter ügyessége és szakértelme a szerte dobált lim-lomokból a ragasztó szalag mágikus erejének köszönhetően egy új entitást hoz létre, ami tervezés és kivitelezés szempontjából a NASA vívmányaival is felveszi a versenyt.

Pedig rögzítéshez az epoxi gyanta sokkal megfelelőbb. Ha nekem kell mozdulatlanná varázsolnom két alkotó elemet, már keverem is a koktélt.

Vonzalmam az epoxi gyantákhoz korán megmutatkozott. Amikor először költöztem el otthonról egy szolgálati lakásba, elég hamar nyilvánvaló lett, hogy valamit bütykölni kell. A lakás viszonylag jól felszerelt volt. Találtam partvis fejet, partvis nyelet. Az egyetlen gond az volt, hogy a kettőt nem lehetett összeilleszteni. Egy boltban a ragasztókat böngészve akadtam a megoldásra: az epoxi gyantára. Víz álló, saválló, időjárás álló. A tubusból kinyomva nem volt több, mint egy ronda, fekete massza. Amíg meg nem száradt, kegyetlen bűzt árasztott. De amit összeillesztettem vele, az szétrobbanthatatlan volt. Mikor elfogyott, sokáig kerestem, de nem találtam hozzá foghatót. Hiába, az elsőt nehéz elfelejteni...

Utána még sokan jöttek. Emlékszem egy átlátszó, gyorsan száradó típusra, amivel például a lányom rollerjét javítottam. A törött műanyag szépen egyben maradt, bár meg kell jegyezni, hogy szilárdság tekintetében nem volt tartós. A következő ütközés hatására azonnal eltörött.

Azokat a fajtákat, ahol a keverési arány nem 1:1, azokat nem szeretem, mert ha nem sikerül megfelelő formában kikeverni, akkor nem lesznek tartósak. Így jártam egy műanyag játék házzal is, ahol az oldalsó részek rosszul forrtak össze, de a tetőt jól tudtam rögzíteni vele.

Az is jó, hogy teljesen különböző anyagokat is össze lehet illeszteni, még akkor is, ha közöttük hatalmas rés van, így azok kitöltéséhez is remek választás. Ahogy a fotóállvány javításnál is tettem.

Egy keveset még az ágyrács építésénél is felhasználtam. Mikor bontottam szét, a csavarok eltávolítása után is egyben volt a váz. Szeretem, amikor működnek a dolgok.

Legutóbb a lányom egy elegáns rúgással eltörte a szemüvegem, pontosan középen, ahol az orromon nyugszik. A szemüvegnek vékony fém kerete volt, ezért biztos voltam benne, hogy bármilyen jók is az epoxi gyanták, önmagukban nem elegendőek, hogy rögzítsék az eltört darabokat. Egy gem kapcsot spirálisan feltekertem, beledugtam a szemüveg két törött csonkját, és ezt használtam merevítőnek. A hézagokat pedig feltöltöttem gyantával. Száradás után lereszeltem az egyenetlenségeket, és kész is voltam.

Ha valaha McGyver-filmet készítek, abban biztosan nem ragasztó szalag lesz, hanem epoxi gyanta.

Elég sok programom valamilyen adatot dolgoz fel. Ehhez szükség van az adatok tárolására, de olyan módon, hogy a program könnyen hozzáférjen, egyeszerűen tudja módosítani azt. A legtöbb bioinformatikai szkriptem valamilyen táblázatos szöveget dolgoz fel. Miután lefutott, mehetett a kukába, többet nem használtam, mert minden adat épp annyira volt más, hogy ne legyen érdemes tovább fejleszteni a meglévő szkriptet, egyszerűbb volt újat írni. Mostanra elég fásult lettem, ha az X. ciklust írom, amiben beolvasom a sorokat és tabulátorok alapján tömbbe mentem az oszlopokat.

Ha egy adatsor elért egy kritikus szintet, akkor adatbázisba szerveztem, mert akkor már megéri ráfordítani azt az időt, hogy normálisan rendezzem őket. Az adatbázisok használata sem különösebben érdekes programozás technikailag. Eddig bármilyen nyelven használtam SQL adatbázist, az mindig úgy nézett ki: volt egy kapcsolódás, majd nyakatekert módon összeállítottam egy lekérdezést (ami végül, ha nem webre készült, akkor sztring konkatenációba torkollott, mert az volt a legegyszerűbb), egy ciklussal végigmentem az eredményeken és tovább matattam a mezőkön. Micsoda izgalom!

Egy újabb projekt kapcsán viszont olyan programot kellett készíteni, ami Windowson fut, tárol néhány értéket, nagyjából százas nagyságrendben, csinál valamilyen bűvészkedést rajtuk, attól függően, hogy mit állít be a kezelője és készít egy táblázatot.

Már régen használtam C#-t, de biztos voltam benne, hogy az lesz a legjobb választás, és abban is biztos voltam, hogy kell egy adatbázis. Ez utóbbi egy kis kutatást igényelt. Szöveges fájlokat nem akartam használni, mert akkor egy csomó olyan rutint kell megírni, amit egy SQL adatbázis esetén szükségtelen. A sok kód csak felesleges hibákat okoz én meg nem akartam napokat debuggolni, mert egy primitív fájlbeolvasót rosszul írtam meg.

Az adatábázissal viszont volt néhány gond. Amikor telepítem a programot a felhasználó gépére, akkor telepítsek egy egész SQL szervert is? Rakjam a szervert egy másik gépre és neten kommunikáljanak? Ha egy hatalmas adatbázisról lett volna szó, akkor megérte volna, de nagyon kevés adatról van szó. Ráadásul csak egy ember fogja használni a programot, minimális informatikai ismeretekkel. Abban is biztos voltam, hogy nem lesz sem nekem, sem a felhasználónak rendszergazdai hozzáférése a géphez.

Abban is biztos voltam, hogy a programot jó sokszor kell majd módosítani az aktuális igényeknek megfelelően, ami azzal jár, hogy valószínűleg új adatbázis is kell. Hogyan juttassam el az adatbázist a programmal együtt?

Kutakodás közben akadtam a LocalDB-re, amit mintha csak erre a projektre találtak volna ki. Egy pici Microsoft SQL Server, amit akár a kész programmal együtt terjeszthetek. Az adatbázis egyetlen fájl, amit a telepítő csomagba lehet integrálni. Még rendszergazgai jogosultság sem kell a telepítéshez, ahol kibontják, ott működik.

Egy régi Visual Studio 2015-t használok, mert még nem adtam fel tejlesen a reményt, hogy egyszer valami Windows Phone alkalmazást készítek, ezért ez a leírás nem napra kész, de az elvek bizonyára változatlanok.

Az első jó hír, hogy az adatbázist el lehet készíteni Visual Studioval. Nyilván egy dedikált SQL szerver több eszközt ad a kezembe, de sok olyan szolgáltatást is tartalmaz, amire nekem semmi szükségem.

Azt már a Visual Basic 4.0-s időben is tudtam, hogy a grafikus elemek egy része képes közvetlenül az adatbázisból adatokat megjeleníteni. Nem volt ez másként itt sem. Ha azt akartam, hogy egy ListBox egy tábla egyetlen oszlopából jelenítsen meg adatokat, akkor csak be kell állítani az adatforrást és kész. Nem kell kilóméter kódot írni.

De számomra a legmegdöbbentőbb nem is ez volt. Ahogy a kód kiegészítéssel játszottam, észrevettem, hogy készült egy osztály, ami az adatbázis nevét viselte. A metódusokat vizsgálva azt látttam, hogy az adatbázisból készült egy szerializált osztály is. Nem kell a jól ismert mantrát beírni, ha le akarom kérni az adatokat. Az egész már eleve ott van. Új adat felvétele? Egy metódus. Elemek számának lekérdezése? Egy mező.

Már régen éreztem ezt, hogy egy fejlesztő eszköz ennyire támogasson. Rövid keresés után kiderült, hogy ennél több is van! Ha egy üres formra az adatforrásokból ráhúzok egy táblát, akkor elkészül az összes grafikus elem, ami ahhoz kell, hogy a rekordokat módosítsam.

Nyilván nem egyedi igényeket nem fog kielégíteni, de nekem most nincsenek egyedi igényeim. Annyit akarok csak, hogy lehessen új adatokat felvinni, nem akarok kifelejteni semmit, és kevés kódot akarok írni.

A második operációs rendszer, amit a húsz éves laptopra szabadítottam, a KolibriOS volt. Ez az operációs rendszer teljes egészében assemblyben készült. Mérete 27 MB tömörítve. Ebben egy teljes grafikus felület, fejlesztő rendszer, rengeteg játék, emulátor, multimédiás és rendszer eszköz található.

A hardver támogatása szegényes. USB támogatás van, csak Fat32 fájlrendszert ismer fel. A laptopon nagyon lassú volt, sok programot ki sem tudtam próbálni, mert a processzor nem támogatta az újabb utasítás készletet.

Doom ment, de eszméletlenül lassan. Élvezhetetlen volt, akár csak az árkád játékok többsége. Szerencsére akadtak logikai játékok, amivel el lehetett ütni az időt. Tartalmaz egy DOSBox-ot, amivel elméletileg valamennyi DOS alkalmazás futtatható. A régi klikkelős kalandjátékokat egy ScrummVM emulátorral lehet életre hívni.

Volt Total Commander koppintás, amivel át lehetett nézni a könyvtár szerkezetet. Még egy kis zongora alkalmazást is felfedeztem, amivel a speakeren keresztül tudtam primitív dallamokat játszani. Parancsértelmezője minimalista, csak a legszükségesebb fájlműveleteket támogatja. Multitask van.

A grafikus felülete szép, pixel grafikára épül. Meglepő, de ezt is assemblyn keresztül lehet programozni. Mellékeltek pár minta kódot, hogyan lehet ablakot nyitni és esemény kezelőt írni. A kód még számomra is érthető volt, annyira tiszta és átlátható. A rendszer képességeiről kisebb demók adnak felvilágosítást. Ezek között volt olyan, ami azt sugallta, hogy egyszerű OpenGL implementációt is tartalmaz

Fejleszteni a FASM-al lehet rá. A kód alapján az általam is bemutatott NASM szintaxisra épül. Természetesen kód visszafejtő és hex editor is van. A szövegszerkesztőt nem tudtam kipróbálni, mert SSE2 kellett neki. Ennek ellenére diszkrét hibaüzenetet adott, nem fagyott.

A rendszert elsősorban oroszok fejlesztik, a fórum bejegyzések nagy része cirill betűs. De enélkül is elég árulkodó nyom van a gépen. A MidAMP (egy WinAMP klón, ami midi fájlokat játszik le speakeren) példafájlja az orosz himnusz. Az egyik ikon sarlót és kalapácsot formáz, a grafikai teljesítményt pedig a KGB nevű program méri.

Telepíteni sem egyszerű. A lemezt nem lehet leformázni, nincs hozzá parancs. Boot loadert nem tartalmaz, a GRUB-ot ajánlják. Mivel a programok nagy része nem működött, ezért én csak CD-ről indítottam és ott nézegettem.

Nagyon ügyes rendszer, de nem olyan régi vasakra tervezték, mint amivel én használtam. Mindennapi használatra teljesen alkalmatlan, mivel szinte semmilyen program nincs rá, amit a hétköznapokban használunk, és ami van, az is elmarad funkcióiban az elvárt szinttől. Ez tényleg csak azoknak való, akik programoznak és imádják az assemblyt.