Az élet kódjai

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.

Az előző részben arra próbáltam megoldásokat találni, mit tegyen az, aki nem ért a zenéhez, de nem szeretné, ha a demója néma csöndre lenne kényszerítve. Most nézzük meg a grafika esetét.

A grafika kérdése nehezebb, mert egy demó több grafikai elemet vonultat fel: 3d modelleket, logókat, szövegeket, textúrákat. Ezeknek egységes design kell, márpedig ha különböző forrásból szerezzük be őket, erre nem sok esély van.

Ha nagyon nehezen jön össze a grafika, akkor a legegyszerűbb, ha olyan platformot választunk, ahol a grafika szerepe másodlagos. A legtöbb Wild ilyen. Keresnek valami elvetemült platformot (lustábbak készítenek egy LED kockát Arduinóval vagy Raspberry Pi-al), majd implmentálják rá a klasszikus demoscene effekteket. Az értéket úgyis a kiválasztott platform adja, nem a grafika vagy zene.

A másik megoldás, ha méretkorlátos alkotást csinálunk. Itt szintén nem a grafika a fontos, mint design elem, hanem a mögötte húzódó kód. De még bonyolult kód sem szükséges, ha van egy nagyon jó ötletünk. A "True story from the life of a lonley cell" például 256 byte méretben, ZX Spectrumon alkotott valami elképesztőt. A grafika szinte nulla, mégis mindenki érti, miről is van szó:

Ha mégis grafikával akarjuk eladni a produkciót, akkor alaposan utána kell nézni a lehetőségeknek. A 3d modellek esete a legegyszerűbb. Elég sok ingyenes 3d modell van, ezek minősége, részletessége igen változó. Tapasztalatom szerint főleg az alacsony poligon számú, egyszerű textúrával rendelkező modelleket lehet ingyen megszerezni. Az ASD demócsapat is rendszeresen használ ingyenes modelleket. Ők legtöbbször egy egységes és minimalista shaderrel érik el a közös design-t. Erre nagyon jó példa a Rupture.

Azt azért hozzá kell tenni, hogy az ingyenes modellekkel is kellett dolgozniuk, ezért nem árt megnézni, hogy a jogok ezt lehetővé teszik-e. Nem minden Creative Common módosítható szabadon!

Az ASD egyébként mesteri abból a szempontból is, hogyan kell nyilvánosan beszerzett elemeket felhasználni egy produkcióhoz és azokat közös design-al ellátni. A The Evolution of Vison például egy casting videót használt fel. (Ne örüljetek, csak a ruhás rész látható).

A Spin például a Second Lifeból szerzett animációt:

Ha nem akarunk mások munkájától függeni, akkor sincs baj. Az absztrakt formák mindig segítenek nekünk. Ebben a Still az éllovas. Az Intrinsic Gravity például szerintem felülmúlhatatlan ebben.

Nem véletlen, hogy ez volt az inspirációm a Plasma című alkotásnál.

Van egy kategória, ahol a tartalom szándékosan alacsony minőségű. Ezek pedig a lamer demók. Itt a poénon van a hangsúly, nem a felhasznált elemek minőségén. Elég csak megnézni Kevin debütálását, az elmond mindent:

Ha viszont igényes grafikát akarunk, akkor rengeteget kell dolgozni. Viszont arra is rengeteg módszer létezik, hogyan könnyítsük meg a munkát. A legegyszerűbb megoldás talán rotoszkóp, ahol körberajzolunk egy referenciát, például egy fényképet. Sok Amigás és korai PC-s produkcióban láthatunk ilyet, például a State of the Art-ban, hogy egyet említsek:

Én négy demóban is használtam ezt a technikát, de elég csak a Livin' in a boxot említeni.

A rotoszkóp továbbfejlesztett változatának is felfoghatjuk a fotogrammetriát. Tudtommal még egy demót sem készítettek ezzel az eljárással. A lényege, hogy a referenciáról (jelen esetben egy tárgyról) több fotót is készítenek, majd egy program segítségével textúrázott modellt nyernek belőlük. Ha majd kicsit jobban megismerem a technikát, részletesebben is írok róla.

Ennek a technikának az egyik előfutára, ha Kinectet használunk. Erre több példa is van, most csak poén kedvéért mutatom a Breath demót, ahol állítólag ezzel az eszközzel rögzítették a robot mozgását.

Végezetül ott van a HMM módszer. Ez a Használj Mindent Magad körül rövidítése. Használhatod a gyerekeid rajzát, fényképeket, bármit. Ezek egy lépéssel vannak a lamer demók fölött, a közönség ritkán díjazza, de persze nem is az a cél.

Az X86 assembly programozás is olyan volt számomra, hogy többször belekezdtem és valahol megszakadt a tanulási folyamat. Többségében azért, mert nem tudtam átverekedni magam az unalmas bevezetőkön. Szerettem volna mindjárt valami látványosat alkotni, de a könyvek csak a processzorok történetével, memória felépéítéssel és minden mással foglalkoztak.

Természetesen ez érthető, mivel  az assembly programozáshoz ismerni kell a gép felépítését. Nincs lehetőségünk magas szintű eljárásokat használni, ezért még az olyan egyszerű feladatok is, mint amilyen a képernyőre történő írás, komoly kódolást igényel.

A könyvek tehát logikusan vannak felépítve, de oktatás metodikailag nem megfelelőek. Nem adnak siker élményt, nem sarkallják az embert arra, hogy megismerjék a nyelvet. Hiszen ki akarna assemblyben szenvedni és több oldalon keresztül arról olvasni, hogyan kell két számot osztani? (Különösen, hogy a matematikai társprocesszor jó ideje ott csücsül a gépekben) Hol marad az öröm, hogy valamit sikerült elérni?

Ezért én megpróbálok írni egy tutorialt, aminek nem az a célja, hogy mindent megismertessek, ami az assembly programozáshoz nélkülözhetetlen, sokkal inkább kedvcsináló legyen, hogy olyan hangosan énekeljünk, mint Tom Hanks, amiért sikerült tüzet gyújtania.

Ami kelleni fog, az egy FreeDOS. Miért? Először is, megvan benne minden, ami nekünk kell: szöveg szerkesztő, assembly fordító, és könnyű hozzáférés a grafikus képernyőhöz. Igen, ez a másik előny. Míg egy modern operációs rendszeren eszetlenül sok dolog kell, hogy egy egyszerű pontot kitegyünk a képernyőre, addig FreeDOS alatt pár sor assembly kódból ez megvan. Más szavakkal: rajzoláson keresztül fogjuk megismerni az assemblyt, ami szerintem király. Gyakorlatilag ezt csinálják 256b intrókban is, ezért nyugodtan mondhatjuk, hogy ez egy intró tutorial is egyben.

A NASM fordítót fogjuk használni. Először is, mert szerintem tisztább a kód, mint amit a GNU Assemblernek kell adni, másrészt a legtöbb 256 byte intró is ezt használja.

vi gyorstalpaló

Ebben a cikkben a vi szövegszerkesztőt használjuk. A vi nagyon egyszerű, de szépen kiszínezi a forrás fájlunkat, ami elég látványos. Ha nem ismersz semmilyen szövegszerkesztőt FreeDOS alatt, akkor itt egy rövid leírás, ami elég arra, hogy nagyon alapszinten használni tudd.

Elindítani az c:\elvis\vi paranccsal lehet. Mivel nincs menü rendszere, ezért a parancsokat be kell gépelni a vi-nek. Amikor parancsokat gépelünk, az meglepő módon a parancs mód. Amikor elindul a szövegszerkesztő, akkor parancs módban van. Ha lenyomjuk az i billentyűt, akkor szerkesztő módban kerül, szerkeszthetjük a fájlokat. Ha vissza akarunk térni parancs módba, akkor az esc billentyűt kell lenyomni. Ha nem tudod, milyen módban vagy, nyomd le az esc-t. Ha szerkesztő módban vagy, átvált parancs módba, ha parancs módban vagy, nem történik semmi.

Szerkesztés közben egyedül a backspace nem működik. Törléshez sajnos csak a del gombot tudjuk használni. Ezt természetesen lehet módosítani, de mivel ez egy gyorstalpaló, ezzel nem foglalkozunk. Csak jegyezd meg, hogy a del a törlés. Minden más úgy működik, ahogy a többi szövegszerkesztőnél.

Ha végeztél a szerkesztéssel és ki akarsz lépni, akkor a következő gombokat kell lenyomni. Ebben a sorrendben: esc : w q enter. Szóközök nélkül. Ezzel belépsz parancs módba, elmented a munkádat és kilépsz a programból. Gyakorlatilag ez a minimális tudás, ami a program használatához kell. Ha többet akarsz megtudni, akkor a neten rengeteg leírás található.

De ha ez túl bonyolult, az edit paranccsal is lehet szöveget szerkeszteni. Ekkor vannak menük, de nincs kód színezés.

Beállítások

Ha telepítettük a FreeDOS-t, akkor két beállítást javaslok. Két könyvtárat rakunk az elérési útba, hogy használhassuk onnan a programokat. A c:\autoexec.bat fájlban a SET PATH sor végére írjunk két könyvtárat:

SET PATH=%dosdir%\BIN;c:\elvis;c:\devel\nasm

Ezzel két legfontosabb programunkat, a szövegszerkesztőt és a fordító programot bárhonnan el tudjuk érni.

Váz

Azért, hogy minél egyszerűbb legyen a dolgunk, COM fájlokat fogunk készíteni. Ez a legegyszerűbb bináris futtatható fájl, amit csak el lehet képzelni. Minden fájl a következő módon épül fel:

org 100h
section .text
start:
section .data
section .bss

Négy részből épül fel, amit a section kulcsszóval definiálunk. A text a forrás állomány lesz. A data, ami olyan, mintha konstansok lennének egy magasabb programozási nyelvekben. A bss pedig a nem inicializált memória terület, vagyis változók. Ez csak váz, ha lefordítjuk, nem kapunk semmi értelmeset. Lépjünk is tovább.

org 100h
section .text
start:
    ; Set video mode
    mov ax, 13h
    int 10h
    ; Set base address
    mov ax, 0A000h
    mov es, ax
    ; Set screen coordinate and colour
    mov di, 150
    mov dl, 7
    mov [es:di], dl
    ; Back to DOS
    mov ax, 3
    int 10h
section .data
section .bss

A programot a következő módon fordíthatjuk, feltéve, hogy minisc.asm a fájl neve:

nasm -fbin minisc.asm -o minisc.com

Ha futtatjuk, a gép sebességétől függően nem történik semmi látható. Ha olyan tetü lassú gépet használunk, mint amilyet én, akkor egy pillanatra látszik, ahogy átvált grafikus módba.

Mi is történik? Két utasítást látunk: mov és int. Az int az egyszerűbb, azzal kezdem. Egy megszakítást generál. A megszakítás olyan, mint egy API hívás. A BIOS vagy a DOS megcsinál helyettünk valamit. Nem kell bonyolult dologra gondolni, mert csak egyszerű dolgokat kérhetünk (lévén, hogy egy egyszerű operációs rendszert használunk). Pl. billentyűzet lenyomást, képernyő felbontás váltás, stb. A 10h egy BIOS megszakítás, ami a képernyőt kezeli. Beállíthatjuk a képernyő módot, karaktereket írhatunk, de akár a fényceruza pozícióját is megtudhatjuk. Aki nem tudja, hogy ez utóbbi micsoda, ne is akarja tudni. Örüljetek, hogy van érintő képernyő.

Hogyan lehet ennyi különböző funkciót rendelni egyetlen megszakításhoz? Kell, hogy legyen valami paraméterezés. Van is, amit a regisztereken keresztül érhetünk el. A regiszterek olyanok, mint a globális változók. És ezzel el is érkeztünk oda, miért nem szeretik sokan az assemblyt. Míg a magasabb programozási nyelveknél nem szabad globális változókat használni, kerülni kell a goto utasítást, addig a gép processzorának legmélyén ezeket az elveket hírből sem ismerik. A káoszt csak erősíti, hogy az assembly utasítások folyton ezeket a regisztereket figyelik és ide irkálnak mindenfélét. Aki ezeket mind megtanulja, ki fogja ismerni magát az asm kódokban.

A programozás nagy részében ezekbe a regiszterekbe fogunk pakolni értékeket mi is, ezért a második utasítás, amivel megismerkedünk, a mov. Az első parancsnál is, az AX regiszterbe 13h-t rakunk, amitől a megszakítás után a BIOS tudni fogja, hogy a képernyőt 320x200-as felbontásba akarjuk kapcsolni. Ez azért jó, mert ha a memória egy dedikált helyére adatokat pakolunk, akkor az megjelenik a képernyőn. Ezért a programunkban, amíg vissza nem kapcsolunk karakteres módba, csak mov utasítást használunk.

Ez a dedikált memória hely az 0A000h. Erre kell beállítani az ES regisztert. Mivel az ES regisztert közvetlenül nem állíthatjuk be (ne kérdezzétek, miért), ezért először az AX regiszterbe pakoljuk az értéket és onnan az ES-be. Ez a memória terület folytonos, vagyis a képernyőn a sor végét elérve a következő sor elejére ugrunk. Sőt, mivel ez a terület egyetlen szegmens, ha elértük a képernyő alját, a tetején jelenünk meg újra. Ezt az intrók előszeretettel ki is használják.

Az offsetet, vagyis az alap memóricímtől való eltérést, és ezen keresztül a pozíciót a DI regiszterben állítjuk be. Amit ezen a memóriacímen beállítunk, az színként jelenik meg a képernyőn. (Kicsit zavaró lehet, hogy a DL regisztert használjuk, ami igazából a DX regiszter, csak az egyik fele. Az alsó fele, hogy pontosak legyünk.)

Oké, de még mindig nem látjuk a pontot a képernyőn. Ha már úgyis a GOTO-t emlegettük, mi lenne, ha visszaugranánk a rajzolás előtti részre?

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

Szuper, látszik a pont. Igaz, ha eleget gyönyörködtünk benne, akkor újra kell indítani a gépet, de akkor is látszik. Az új parancs a jmp, amivel egy címre tudunk ugrani. A DOS-ba való visszatérés igazából itt felesleges, mert egy végtelen ciklust készítettünk.

Elég sok mindent nem érintettünk, de 16 sorból rajzoltunk valamit. A részleteket meghagyom a könyveknek. Viszont van egy keretrendszerünk, amit fejleszhetünk és nem kell a debuggerben nézni, hogyan változnak a regiszterek.

Samuel L. Jackson szerint az új XXX-nek még veszélyesebbnek, halálosabbnak, keményebbnek kell lennie, és a Function szervezői ezt alkalmazták a partyra is. Már az odaúton láttam, hogy ez nem lesz a szokványos demóparty. Ahogy a hármas villamos egyre lepusztultabb környékre ért, éreztem, hogy a laptop helyett talán egy vipera vagy boxer lenne a megfelelő társ.

A villamosról leszállva jobbra egy áruház volt, balra a rosszlányok mutogatták bájaikat. A kettő között vezetett az utam elhagyatott ipari létesítmények között, amelyeket egyszerűbb volt otthagyni, elpusztulni, mint lebontani és valami újat építeni a helyükre.

Az is megfordult a fejemben, hogy talán egy összeesküvés keretében csalták ide a demoscene tagjait, hogy aztán egy épület omlásnak álcázott gyilkossággal kivonjanak mindenkit a forgalomból. Persze, ki akarna régi számítógépeket éltető kockákat megölni? Amikor elég elvenni tőlük az áramot.

Bent, az épületben, a 6000kg teherbírású lift mellett, már barátságosabb volt a hangulat. Két terem volt, ahol a compókat nézhette az ember, ezen kívül konyha, büfé, ahol éjfélig lehetett kajálni. Nem volt olcsó, de közel volt.

Érkezés után már csak a releasek feltöltése volt hátra. Ebben elég rutinos vagyok, a videót már eleve pendrive-on hoztam, mert a parti weboldalán 256MB a feltöltési limit. Miután elkészültem, nem tudtam mit kezdeni magammal. Dél volt, éhes voltam és alig volt ismerős.

Ebéd után két előadást hallgattam meg. Az első egy 256 byte intró születéséről szólt. Én csak most ismerkedem az assembly nyelvvel, de úgy tűnt, még egy olyan rutinos vén róka, mint TomCat is tanul újat. Például a release beadása után jöttek rá, hogyan tudnának 8 byte-ot spórolni egy trükk segítségével. Tanúság: az assembly nem egy nyelv, amit használunk, hanem egy út, amin csak elindulunk.

A második előadás egy detektív játék bemutatása volt, amiben állat fejű lények voltak, fekete-fehér noire-ban. A dialógusok nekem kicsit erőltetettnek tűntek, hiányzott az a spontaneitás, ami a Tango és Cash-t is jellemezte, és amelyiket felsorolták, mint inspirációt. Nem, mintha olyan sok időm és kedvem lenne játszani.

Majd jött a Kolmogorov Toolbox Live Music Coding. Ezt én imádom. Nagyon jó ambientes hatása van. Munka közben is tudnám hallgatni.

Beszélgettem, akivel csak tudtam, ez szerintem jobban sikerült, mint tavaly, akkor kevésbé találtam a helyemet. Közben lestem, hogy ki, mit ad be, számolgattam az esélyeimet. Azt hiszem, idén nem leszek dobogós semmiben.

A töcs nevű madár idén nagyon népszerű lett. Nagz meglepődött, hogy ilyen van, kis is posztolta Twitteren. De annyira meglepődött, hogy Netpoet erről dalt készített, amit a zene compón le is adtak. Én pedig azon lepődtem meg, hogy egyik hülyeségből hogyan születik a másik.

A releasek nagyon jók. Szép grafikák, szép rajzok vannak nagy számban. Bár lehet, csak a partitól vagyok feldobva, szépnek látok mindent.

Mint említettem korábban, két terem van, ahol az eseményeket nyomon követhetjük. Egy nagyobb, amit székekkel töltöttek meg, és egy kisebb, ahol vannak asztalok is. Sokan, akikkel beszélgettem, fanyalogtak emiatt, de szerintem jó az ötlet, mert a kisebb teremben halkabban szól a hangszóró, aki nem akar üvöltő zenét, csak bemegy a kisterembe.

Én azt hittem, kevés lesz az asztal ennyi emberre, de úgy látom ez is alaptalan félelem. A legtöbben már telefonról szavaznak, csak a hozzám hasonló öregek rohangálnak még laptopokkal. Tényleg, csak kb. 20 laptopot látok.

A 256b intrók félelmetesek voltak. Többen is 64 byte, vagy az alá csökkentették a kód méretét. Volt 64 byte zenével! Ahol felhasználták mind a 256 byte-ot, ott meg volt zene és különböző részek, mint egy igazi demóban. Hihetetlen. A 64k intróban a kedvencem a csillagok háborúja témájú volt, ahol két droid szerelmét ismerhettük meg, mielőtt kivezényelték őket a jedik ellen a Klónok támadása című filmben. Charlie meg is jegyezte, hogy jobb volt, mint az Utolsó Jedik. Nehéz vitázni ezzel.

A demók is jók voltak. Jimmy tovább ügyesedik. Gargaj pedig bedühödött. A tavalyi demójának viszhangja nem volt épp poztív. Illetve ez így nem pontos. Rengeteg pozitív visszajelzés volt, ha csak a Pouet-t nézem, de néhányak kifogásolták, hogy nagyon statikus, nem mozog benne semmi a kis robot porszívón és a macskán kívül. Erre megalkotta nekünk ezt az egyszemélyes agybombát, ahol megismételte több, már-már legendás demó elemeit. Kommentnek pedig csak annyit írt: Kuss. Elmondta nekem, hogy ebben a demóban semmi új nem volt, mégis tetszik az embereknek, meg a mennyiség fontosabb számukra, mint a minőség. A mennyiségre szerintem sem lehetett panasz. Annyi tartalmat pakolt a demóba, amennyi másik háromnak is elég lett volna.

Éjjel volt az eredmény hirdetés. Jól sejtettem, sehol, még csak a dobogó közelében sem jártam, de utolsó sem lettem. Adtam be egy fotót, de arról még én is láttam, hogy gyenge. Elkészítettem életem első 256 byte intróját, amit igazából csak 55 byte volt, és egy profi mindjárt 20 byte-ot spórolt rajta. Csak, hogy érezzétek, milyen erős a konkurencia. A harmadik release egy videó volt.

Összességében nekem tetszett a parti. Jó volt a hangulat és rengeteg kiváló release született.

Hedvig, Tamás és ötéves lányuk Janka, meglátogatták a nagyszülőket, Karcsi bácsit és Mari nénit. A Húsvét nem számított nagy ünnepnek, ezért csak a szűk család ünnepelt. A tervek szerint vasárnap délelőtt csak Hedvig öccse, Andor jönne át, feleségével Nórával és a három éves Bellával. Délután mindannyian elmennek a nagypapa testvéréhez, Miklóshoz, akinek szintén két gyereke van, mindketten házasok és mindkettőnek gyereke is van már. Ez 16 ember. De akkor már átjön a szomszéd faluból a dédmama, Karcsi bácsi és Miklós édesanyja is, aki szeretné látni az unokákat.

Természetesen ott volt még Jack kutya is. Jack igazi munka kutya volt. Állandóan munkában volt. Hol a virágokat ásta ki, hol használati tárgyakat rágott szét. Szegény a lelkét is kidolgozta, gazdái mégis mérgesek voltak rá, különösen Mari néni, aki még egy söprűt is igénybe vett, ha kutya nevelésről volt szó. Jack úgy próbált jó pontokat szerezni, hogy még keményebben dolgozott.

- Jack! Mész a helyedre! - üvöltötte Mari néni a konyhából, csukott ablak mellett.

- A mama rám mérges? - kérdezte Janka megszeppenve.

- Nem, a mama Jackre mérges - mondta Hedvig.

- Nem, a mama nem mérges rád. De egyszer úgyis agyon verem ezt a kutyát - erősítette meg Mari néni, miközben készült a húsvéti reggelihez. Tojást pucolt és sonkát vágott.

Karcsi bácsi közben titkos küldetésen volt. Átment a szomszédhoz, aki nyulakat tenyésztett és kért kölcsön egy kisnyulat, amit a teraszon akart elhelyezni a nyuszi fészekben, hogy játssza el a Húsvéti nyúl földi helytartóját. A sikeres együttműködést egy kis pálinkával is megerősítették. Mari néni még mindig dohogott, az ablaktáblák ütemesen rezegtek hangjára. Karcsi bácsi, kihasználva a helyzetet, észrevétlenül leült és bennfentes biccentéssel jelezte a szülőknek, hogy a nyúl-akció a következő fázisba lépett.

Mari néni végzett a terítéssel, ezért mindenki az asztalhoz ült.

- Mit szoktunk mondani? - fordult Jankához. - Aki ételt, italt adott... - a kislány értetlenül nézett rá.

- Hagyd ezt a hülyeséget - vágott közbe Karcsi bácsi. - Soha nem szoktuk mondani.

- De most Húsvét van - védekezett Mari néni.

A teríték ünnepi volt. Fehér abrosz, amin tányérok sorakoztak. A szeletelt kenyeret is kosárba tették. Mindenki evett a sonkából és a tojásból. Kétféle torma is volt, egy csemege és egy tejszínes.

- Hogy ízlik? - kérdezte Mari néni.

- Nem valami finom - jegyezte meg Karcsi bácsi.

- Mert nem ezt a fajta sonkát szoktuk venni. Éreztem én, mikor főztem, hogy alig van íze. Annyi fűszert beletettem, de mégis, semmi íze. Többet ilyet nem fogunk venni. A házi sonka sokkal jobb. Ez a gyors érlelésű sonka nem jó.

Karcsi bácsi felállt és szó nélkül kiment, hogy ellenőrizze a nyulat.

- Köszönöm, nem kérek többet - mondta Janka is.

- De még egyél, alig ettél.

- Köszönöm, nem kérek.

- Akkor egyél még tojást.

- Nem kérek.

- Ennyi reggeli nem elég. Akkor egyél egy kis kalácsot.

- Nem kérek.

- Nézd, teszek rá sonkát is. Kapd be!

- De nem kérek!

- Na, edd meg szépen.

Janka sikítani kezdett és berohant a szobájába.

- Nem evett semmit! Ez a ti hibátok! - fordult Janka szülei felé. Teljesen leszoktattátok az evésről.

- Anya, ne szekálj már!

Mari néni hangja fokozatosan emelkedett, mint egy repülőgép.

- Én nem szekállak. Mindent ráhagytok, nem foglalkoztok vele eleget. Így kell viselkednie egy hat évesnek? Így?

Karcsi bácsi érkezése vetett véget a vitának. Szemével megkereste Jankát, mikor látta, hogy a szobájában van, halkan megjegyezte.

- Jack megfojtotta a kisnyulat.

- Miért nem zártad le a teraszt? - kérdezte Mari néni.

- Lezártam. Valahogy mégis feljutott.

- Jaj, ez szörnyű! - mondta Hedvig.

Karcsi bácsi ismét kiment, hogy eltüntesse a nyomokat. Janka közben megnyugodott és elment fogat mosni az apjával, Mari néni pedig leszedte az asztalt, közben folyamatosan düdörgött Hedvignek.

- Apád hibát hibára halmoz az idén, de ha mondom neki, akkor meg van sértődve. Miért nem viszi vissza azt az átkozott kutyát a menhelyre? Csak kárt okoz nekünk.

Kintről közben kutya nyüszítést lehetett hallani. Karcsi bácsi seprű nyéllel igyekezett móresre tanítani Jacket. Az oktatás után a nyúlmentes fészekbe kirakta az ajándékokat Mari nénivel és várták, hogy Janka végezzen a reggeli rutinnal.

A kislány futva érkezett. Csak kétféle sebességet ismert: a futást és a rohanást.

- Janka, megjött a Nyuszi!

- Hol van? - nézett körbe.

- Nincs itt, csak az ajándékokat rakta le.

- Ezek is az enyémek? - mutatott egy másik fészekre, ahol szintén rengeteg ajándék feküdt.

- Nem, azokat Bellának hagyta itt. Majd ők is átjönnek nem sokára.

Ez volt a varázsszó. Janka már nem is figyelt a saját ajándékaira, csak azt nézte, mi az, amit nem ő kap.

- Janka, nézd, te is ugyan azt kaptad, csak más a színe.

A kislányt ez nem győzte meg. Továbbra is meredten bámulta a "nem a tiéd" kosarat.

- Szeretnéd inkább azt? - kérdezte Mari néni. Janka bólintott, mire nagymamája heves pakolásba kezdett. A kislány ekkor észrevette, hogy az egyik ajándék egy főző készlet. Olcsó, fröccsöntött étel utánzatok voltak benne. A színek még csak köszönő viszonyban sem voltak azzal, amit utánozni akartak. Mindez mégsem számított. Janka magához ölelte.

- Apa, főzök neked levest - majd pillanatok alatt szétpakolta az egész készletet. A kis lábosba beletette a krumplit, répát, hagymát, húst, kenyeret, gyümölcsöket, tojást, tésztát, és minden egyebet, ami a keze ügyébe került. Úgy gondolta, minél több alapanyag van benne, annál finomabb.

- Nem nézed meg a többi ajándékodat? - kérdezte Mari néni.

Janka nem hallotta. Épp szalámit, uborkát és sajtot pakolt a képzeletbeli levesbe.

- A nyuszi nagyon szomorú lesz, ha nem nézed meg a többi ajándékodat.

A levesbe, de inkább annak tetejére egy kék gömb került, amit a család egyik fele zsemlének, másik fele narancsnak azonosított. Megkérdezték Janka véleményét is.

- Olívabogyó - vágta rá gondolkodás nélkül, figyelmen kívül hagyva a tényt, hogy ez volt a legnagyobb méretű összetevő.

- Kibontom neked ezt a buborék fújót - próbálkozott Mari néni.

Közben a kapu kinyílt. Megérkezett Bella, Nóra és Andor. Bár csak ötszáz méterre laktak, egy Toyota terepjáróval jöttek.

Mindenki üdvözölt mindenkit.

Bella meglátta, hogy Janka valami érdekes dologgal játszik, amit ő még korábban nem látott. Kinyújtotta kicsi kezét, úgy kérte.

- Ez az enyééém! - visította Janka, válaszul Bella sírni kezdett.

- Add egy kicsit oda neki - kiabálta túl a hangzavart Mari néni.

- De elvesziii!

- Majd visszaadja.

A hangzavart kihasználva Karcsi bácsi és Andor váltottak néhány szót.

- A kutya megfojtotta a kisnyulat - kezdte Karcsi bácsi.

- Várható volt, én ezért nem vettem Bellának. A kutyák nem bírtak volna magukkal.

- Akkor sem kellett volna megölnie. Ez a kutya nem normális.

- Mit vártál? Végül is egy ragadozó.

Közben Nóra Mari nénivel konzultált.

- Anyumat is elhívtam, nem baj? Itt találkoznánk. Eljön Réka és az új barátja is. Elviszik Bellát az állatsimogatóba.

Mari néni mit felelhetett volna? Természetesen azt, hogy nem baj. A gyerekek közben otthagyták a félig kibontott ajándékokat és inkább a kertben felállított trambulinba mentek. A korábbi veszekedést felváltotta az öröm hangja. A hangmagasság és hangerő mit sem változott. Továbbra is csengett mindenki füle.

A megbeszélteknek megfelelően megérkezett Nóra édesanyja, testvére Réka és Roland, akivel Réka randizik. Roland még nem ismert senkit, ezért neki minden egyes köszönés alkalmával random kérdésekre is válaszolnia kellett: Mit dolgozol, ki vagy, hányas cipőt viselsz. Roland előző életében politikus vagy szakkommentátor lehetett, mert mosolyogva vette az akadályt.

Bella és Janka újabb ajándékokat kaptak az újonan érkezőktől. Egy kiszínezhető párnát, rajta népszerű mentő állatkákkal, akik piszlicsáré problémákat úgy oldanak meg, hogy kivonul az egész bagázs. Földön, vízen, levegőben. Janka magához szorította a párnát és ugrált tovább. Hiába magyarázták neki, hogy színezze ki olyanra, amilyenre szeretné. Számára a hófehér párna a rózsaszín kontúr vonalakkal maga volt a megtestesült tökéletesség. Ebből is látszik, a felnőttek csak sémákban tudnak gondolkodni.

Mari néni, ahogy felszabadult a gyerekek felügyelete alól, berohant a konyhába és roham léptekben elkezdett ebédet főzni. Nóra és Hedvig is bement. Andor kint beszélgetett Rékával és Rolanddal. Karcsi bácsi elkezdte locsolni a veteményest. Tamás a gyerekekre figyelt.

Kis idő múlva Andor is belépett a konyhába.

- Elviszik Bellát? - kérdezte Nóra.

- Nem viszik sehova - jelentette ki Andor.

- Miért?

- Nem hoztak gyerekülést, nincs náluk pelenka és Bella délutáni alvásának idején akarnak ott lenni - közben Réka is belépett.

- Miért gond ez? Majd alszik a kocsiban.

- Nagyon nyűgös lesz, nem fogja érdekelni semmi - válaszolta Nóra. Visszahozzátok és nekünk fog hisztizni.

- Túl problémások vagytok - jegyezte meg Réka.

- Majd ha neked lesz gyereked, még visszakapod.

- De akkor sincs gyerekülés - vágott közbe Andor. Anélkül nem fogjátok elvinni Bellát sehova.

- Addig ellesz anyu ölében - legyintett Réka.

Andor és Nóra nem tágított. Rékáék lassan elbúcsúztak és elmentek. Bella szülei még mondták a magukét.

- Ezt még visszakapja tesóm, ha majd neki is gyereke lesz! - ígérte Nóra. Nekem mondja, hogy problémás vagyok!

Lassan eljött az ebéd idő. Mindenki asztalhoz ült és ebédelni kezdett. Mari néni újból kötelességének érezte, hogy megtömje sovány, alultáplált unokáját, aki egy tányér leves és rántott hús után nem akart enni sem sült tarját, sem szalonnába göngyölt csirkemájat, sem gyümölcs kenyeret, sem kakaós piskótát.

Az ebéd végeztével Mari néni elkezdte a tányérokat leszedni az asztalról. Hedvig segített neki.

- Jaj, a cipő! - kiáltott Mari néni fél úton a mosogató és az asztalok között állva, megrakva tányérokkal. Gyorsan letette, ami a kezében volt, és elviharzott az egyik szobába.

- Janka, gyere, ezt még elfelejtette odaadni a nyuszi! - mondta mindezt olyan hangerővel, hogy attól sem kellett volna tartania, ha Janka történetesen műtéti altatásban van. Akkor is hallotta volna.

Janka meg is jelent. Meglátta a világítós cipőt. A világítós cipő története múlt évben kezdődött, amikor az óvodában egyre több gyerek kapott olyan lábbelit, aminek az oldalán apró ledek világítottak minden egyes lépésnél. Nemsokára ez lett az elválasztó, hogy ki számít embernek és ki alsóbb kasztból valónak. A család szabályos hajtóvadászatba kezdett. Három város boltjait kutatták, de mindenhol azt mondtak, hogy elfogyott.

Nem sokkal Húsvét előtt akadt Mari néni egy párra, amit rögtön meg is vett. Majd a rumlikkal telezsúfolt szobában felejtett. Most, hogy eszébe jutott, félbe hagyott minden tevékenységet, Jankának is félbe kellett hagynia, amit addig csinált, sőt egy rejtélyes okból kifolyólag Hedvignek is. Mari néni a rumli szobába invitált mindenkit.

- Gyorsan vegyed fel! Nézzük meg, jó-e - mondta Mari néni, közben arra gondolt, hogy lassan indulni kellene, de még az edények sincsenek a mosogató gépben. Viszont azt is tudni akarta, hogy jó-e a cipő, és nem kell-e visszacserélni a jövő héten.

Janka viszont lenyűgözve bámulta a ledeket. A valóság számára leredukálódott néhány diódára, amit egy kínai üzemben egy cipő talpába ragasztottak és ami az első esőzés után valószínűleg be is fog ázni.

Mari néni végül nem bírta tovább, elkezdte felhúzni a lányra a cipőt. Talán a sietség lehetett az oka, hogy Janka zoknija felgyűrődött, és a csodálatos cipő költemény hirtelen spanyol csizma lett. Janka visított egyet, lerúgta a cipőt és nem akarta visszahúzni. Mari néni ismét bevetette kiképző őrmestereket megszégyenítő hangerejét, hogy finoman megkérje unokáját, próbálja meg újra felvenni a cipőt. De csak további visítás volt a válasz.

- Miért nem adtad rá a cipőt? - fordult Hedvighez. - Tudod, mennyi dolgom van. Mindjárt indulni kell. Nem tudok mindent én csinálni. A tányérok még mindig az asztalon vannak, még össze sem pakoltunk Miklóséknak. Egyáltalán ivott ez a kicsi?

Szerencsére ivott, ezért a támadás sorozat megszakadt. Mari néni koncentrálhatott többi dolgára.

A rendrakás és pakolás után kocsiba szálltak és indultak a közeli faluba, Karcsi bácsi testvéréhez, Miklóshoz. Janka ötszáz méter után elaludt. A többiek szótlanul ültek, nehogy felébresszék. Ez volt a nap legbékésebb része. Az autó motorja melankolikus monotonitással duruzsolt, az ablakon keresztül békés táj képe látszott. A forgalom is gyér volt, mindenki otthon ünnepelt.

A ház előtt parkoltak. Janka a hirtelen beállt csendre felébredt. Nyűgösen nézett körbe, szívesen aludt volna még. Az utastér megtelt az éles gyerek sírással. Mivel az autó két ajtós volt, nehéz volt megszökni a dobhártya szaggató hangoktól. Érezhetően felment a pumpa mindenkiben. A gyerekben azért, mert felébresztették, a felnőttekben azért, mert visított a gyerek. Mivel a gyereken senki nem akarta levezetni mérgét, az autó többi utasában kellett céltáblát találni.

- Ha csak én vagyok vele, soha nem csinálja ezt - jegyezte meg Mari néni. - Csak, ha ti is itt vagytok - vetette oda Janka szüleinek. - Rossz hatással vagytok a gyerekre.

A szülők pontosan tudták, mi van rájuk rossz hatással, de inkább hallgattak.

Beléptek a kapun, és a ház mögötti kertbe mentek. Andor családja már itt volt. Miklós a fiával (akit szintén Miklósnak hívtak) és lánya férjével, valamint Andorral egy mobil telefon kijelzőjét nézték. A hangszóróból foci meccs hangja hallatszott. Felesége, Eszter a lányával (akit szintén Eszternek hívtak) és a fia feleségével, valamint Nórával, egy alig pár hónapos csecsemő fölé hajoltak. Ő volt a legújabb jövevény. A nagyobb gyerekek, akikre már nem fordítottak akkora figyelmet, egy trambulinban ugráltak.

Karcsi bácsiék köszöntöttek mindenkit, majd a csoport felbomlott, és mindenki csatlakozott a kasztjához. Kivéve Tamást, akit a foci nem érdekelt, és a babát nem akarta fogdosni. Őt a gyerekek rángatták magukkal, hogy ugráljon velük a trambulinban.

- Tamást mennyire szeretik a gyerekek - jegyezte meg Nóra, de hirtelen új fejlemény történt. A kisbaba használatba vette a pelenkát és a női osztag egy emberként követte az anyukát, hogy a ház belsejében tanúi legyenek a pelenkacsere-rituálénak.

Fél óra múlva átjött a gyerekek dédanyja. Botra támaszkodva lépkedett, minden lépésre nyögött egyet. Amikor figyeltek rá, hangosabban tette. Hoztak neki egy széket, amin kényelmesen elhelyezkedett. Az egyik gyerek azonnal lecsapott a botjára és boldogan futkosott vele a kertben. Először puskát imitálva lelőtt mindenkit, majd rakéta lett és röpdösött vele.

- Ne vedd el a dédi botját - mondta Miklós első unokájának, de olyan lágyan, mintha megdicsérné.

Amikor a nap a látóhatár felé közelített, mindenki búcsúzkodni kezdett. Mentek a puszik jobbra-balra. Autóba ültek és hazamentek, hogy a két nap múlva visszatérjen egy megszokott, pihentető hétköznap.

A nagyobb genomok összeszerelésénél sajnos a hosszú readek még nem állnak olyan szinten, hogy rutinszerűen alkalmazzuk őket. Lehet még vegyes hosszúságú inszert mérettel hibrid összeszerelést csinálni, hosszú és rövid readeket kombinálni. De jelenleg bármelyik módszert is alkalmazzuk, a homológ kromoszóma szakaszok kifognak rajtuk. Egyszerűen túl nagy a távolság hasonló genomi szakaszok között, hogy bármivel is átérjünk őket, vagy a sorrendjüket megtudjuk.

Ezért a 10X Genomics egy bárkódolási eljárással megjelöli a nagyobb fragmenteket. Szekvenálásnál ezért tudjuk, mely readek tartoznak össze. Egy plusz hozadéka is van a jelölésnek: ismerjük az anyai és apai kromoszómákat is!

Természetesen a módszer mit sem ér, ha nincs hozzá szoftver. Szerencsére a cég ezt is elkészítette, és Supernova néven teszi elérhetővé. (Természetesen miután regisztráltunk, elfogadjuk a sok spamet, stb.)

A Supernova egy, sok processzoros rendszeren  fut, minimum 32 maggal és 256 vagy 512 MB RAM memóriát használnak (genom mérettől, repetitív szakaszok hosszától függően), klaszterek szóba sem jöhetnek. Saját feladat ütemezővel rendelkezik, amit a cég fejleszt Go nyelven. A neve Martian.

A Supernova másik érdekessége, hogy képes közvetlenül az Illuminás BCL fájlokon futni, ezért függőségként kell neki a bcl2fastq.

A program paraméterezése elég egyszerű, igazából a legtöbb magához a bcl2fastq-hoz kapcsolódik. Futás közben rengeteg fájlt és könyvtárat dobál szét, teljesen átláthatatlan, hol is tart. A logok semmit mondóak. A folyamat nyomon követésére a projekt helyén található ASSEMBLER_CS/_ASSEMBLER könyvtárban található alkönyvtárak adják a legjobb támpontot, mert ezek a nevek megegyeznek a dokumentációban található lépésekkel.

A végén rengeteg bináris fájl lesz az eredmény, amiből egy újabb lépéssel lesz FASTA fájl. Négy lehetséges kimenet van. Az első, amikor minden darabkát visszaad. A második a kisebb eltéréseket összevonja (a gráfban ezek kis buborékokként jelennek meg), a harmadik egy haplotípust ad vissza, végül kérhetjük, hogy mindkét haplotípust adja vissza.

Mi nyúl genom összeszerelésre használtuk. A cég szerint elsősorban humán genomra fejlesztették, de annál nagyobb, vagy erősen repetitív genomokra nem javasolják. A mi esetünkben ez nem áll fenn, ezért nyugodtan használhattuk. Ismét csak az a kérdés, hogy a valóság mennyire adja vissza a brosúrák marketing szagú eredményeit, ezért az egyik könyvtárat összeraktam Discovar-denovóval is.

A scaffoldok száma Discovar-denovóval 240 ezer volt, ez lecsökkent 173 ezerre, ha Supernovat használtunk. Az N50 drámai különbségeket mutatott. A bárkódot nem használó módszer csak 1500 körüli hosszúságot adott, míg a másikkal ez az érték 50 ezer lett. Amikor visszaillesztettem a scaffoldokat a genomra, lefedték annak 91%-t!

Viszont észrevettem egy másik érdekes dolgot is. A legtöbb scaffold egymáshoz közel illeszkedett a genomra, kevesebb, mint egy read távolságra. Arra gondoltam, ezeket még közönséges paired-end szekvenálással is össze lehetne rakni.

Az egyik hipotézisem az, hogy ezek a nagy fragmentek, amelyek határán már más bárkód van, ezért a program itt megáll. A másik hipotézis, hogy kópiaszám változások vannak ezeken a helyeken, amelyek eltérnek az anyai és apai kromoszómákon.

Ez utóbbinak kicsit ellenmond, hogy a fenti eloszlás akkor is megmarad, ha csak azokra a scaffoldokra rajzolom ki, amelyek méretbeli eltérést mutatnak az anyai és apai kromoszómákon.

Végül a RaGOO-val könnyedén összeraktam őket. A nem-kromoszómális darabok itt sem illeszkedtek a kromoszómákra, viszont kaptunk új régiókat. Ebben az is közrejátszott, hogy másik nyúlfajtát raktunk össze.

A 10x módszere valószínűleg a legjobb megoldás eukarióta draft genomok összerakására. A szoftver nem éri el egy céges termék színvonalát, de az akadémiai bioinformatikai programok közül nem lóg ki. Az eredmény megbízható, de mindenképp szükség van további munkára, A rendszerben még van potenciál, lehet fejleszteni.

A variációk azonosítása a kutatásban nem bonyolult feladat. Elég régóta fejlesztenek megoldásokat és javítják a meglévőket. Bár a mutációk detektálási pontossága nem 100%, a mintaszám növelésével meg lehet találni azokat a mutációkat, amelyek egy jó publikációhoz elegendőek.

A klinikai diagnosztika viszont teljesen más tészta. A kutatásban megengedett pontosság itt már nem elég. Arra sincs lehetőség, hogy több mintát szekvenáljanak, elvgére csak egy beteg van, akinek megfelelő kezelés kell.

A pontatlanság egyik forrása, hogy a DNS átírás során a polimeráz hibázhat. Ha ez a hiba a PCR sokszorozás előtt (vagy egy korai ciklusban) történik, akkor a hibát több readben is látjuk. Hibásan leolvasott mutáció más okból is keletkezhet, de azokkal most nem foglalkozunk. Koncentráljunk csak a PCR hibákra.

Erre a problémára fejlesztettéki az UMI-t (unique molecular identifier). A lényege, hogy megjelölnek minden egyes eredeti, az izolálásból származó molekulát egy egyedi szekvenciával, aminek segítségével aztán a read nyomon követhető. Ha a mutáció több, de csak egyféle kóddal jelölt readekben fordul elő, akkor az jó eséllyel egy hiba.

A jelölés random primerekkel történik, de arról nem találtam információt, hogy mennyi az esélye, hogy rosszul azonosítják a szekvenciát. Elméletileg ugyanis ha pont egy UMI-ban van egy hibás leolvasás, akkor másik UMI-ként azonosíthatják azt, holott a két szekvencia ugyan olyan eredetű.

Természetesen, ha az UMI ligálás előtt történik egy hiba, az szintén fals pozitív mutációként jelentkezik.

De lássunk inkább egy példát, mit is jelent mindez a gyakorlatban.

A jelölt szekvenciák mutáció keresésére az smCounter2-t ajánlja a gyártó. A programot megpróbáltam telepíteni, de végül feladtam. Felváltva használja a Python2-t és Python3-t, ugyan azok a csomagok kellenek mindkét rendszerhez, de erre is csak próba-szerencse alapon jöttem rá. Szüksége van még néhány, szinte beszerezhetetlen programra.

Végül Dockerből futtattam, azzal nem volt gond. A futáshoz szükség van a targetált régiókra BED formátumban és egy primer fájlra. Ezt a fájlt a gyártó oldaláról tudjuk leszedni.

Volt egy kisebb kaland, aminek során megpróbáltam magam elkészíteni a primer fájlokat (mert a bioinformatikusok és a laborosok nem tudták érthetően elmondani egymásnak, milyen fájlokra van szükség) a BED és a genom alapján, de a program nem volt hajlandó futni vele. Rendszeresen azt a hibaüzenetet adta, hogy nincs elég szekvencia. Ez egyébként jellemző hibaüzenet, ami a hibás primer fájlra utal (amennyiben tényleg rendben vannak a szekvenciák)

A program futásához a paramétereket egy fájlban kell összegyűjteni. A felépítése a régi INI fájlokra hasonlít. Ha több szekvenálás eredményét is fel akarjuk dolgozni, az összes adat elérési újtját betehetjük egy paraméter fájlba, és a program parancssorában egy cimke megadásával mondhatjuk meg, melyik rész kerüljön feldolgozásra, de erről a dokumentáció részletesen ír.

Rengeteg végeredmény lesz. Kezdve a különböző illesztésektől, a kibontott FASTQ fájlokig. De még egy minden nukleotidot tartalmazó táblázatunk is lesz! Ez utóbbi segítségével vissza lehet nézni, miért nem talált meg egyes variációkat a program. Viszont ezek együttesen rengeteg helyet foglalnak el.

Kapunk viszont annotációt az eredményekhez, ami nagy pluszt jelent. Nem éri el a VEP teljességét, de elég részletes.

Még egy fontos megjegyzésem van. A program csak hg19-re működik, mivel a cég targetáló kitjeit is erre a genomra tervezték.

A pontosságról nem sokat tudok mondani, de álljon itt egy táblázat, ahol a "hagyományos", nem UMI alapú variáció kereső programmal hasonlítottam össze. Minden sor egy minta. Ez csak tájékoztató jellegű adat, nem igazi mérés. Az indeleket nem is vettem bele, mert azok pozícióját az egyes programok máshogy adhatják vissza. A hagyományos keresőt nem is én futtattam, túl sokat nem tudok róla mondani.

Számomra elég megdöbbentő az eredmény. Azt vártam volna, hogy a "hagyományos" keresés megtalál mindent, amit az smCounter2, de több fals pozitívval. Ennek ellenére hiányoznak variációk. A lefedettség elég jó volt, egyes helyeken 2000 feletti, mert erősen targetált szekvenálás volt (80 körüli génszámmal), ezért azzal nem lehetett probléma. A hibás térképezést is minimálisnak gondolom, az előbbi okból kifolyólag.

Szúrópróba szerűen kiválasztottam pár variációt, amit a hagyományos szekvenálás megtalál, de az smCounter2 nem. Ezek közül némelyik 0 lefedettséggel fordult elő az smCounter2-es analízisben, ami feltehetően visszamaradt adaptor szennyezés lehetett a read végeken (talán épp egy UMI szekvencia?), de ennek jobban utána kellene menni. Másokat pedig csak egy irányból érkező readek tartalmazták, ami miatt az smCounter2 kiszűrte őket.

Úgy látszik, mégsem olyan egyszerű a mutációk detektálása, mint azt korábban gondoltam. Két különböző technológia elég eltérő eredményt ad. Személy szerint sokkal kisebb különbségeket vártam volna. Milyen eltérések lehetnek egy teljes genom szekvenálásnál?

Eljött a második nap. Most lesznek a futtatható cuccok.

Tuplain compo

Ez egy olyan kompó volt, ahol egy YouTube videóra egy másik videó hangját keverték egy online eszközzel. A cuccok nem voltak emlékezetesek, mert a programon nem sok beállítási lehetőség van. Egy volt érdekes. SlySpy zenéjére egy time laps autó vezetést raktak. A kocsira kb. 6 kamera volt szerelve (egyes kamerák a kamerákat vették). Erre nagyon jól illeszkedett a zene. A többinél mindig érezhető volt, hogy a zene nem ide tartozik.

1k intro

Az első mindjárt egy Windows Power shell melódia. A képernyőn nem sok történik, csak egy ellipszis növekszik. A második egy plazma, némi zajjal. Aztá egy JS, amivel kirajzolták a zenét, mármint annak hisztogrammját, de több távolságban, mintha egy erdő lenne. Zeneerdő! Még egy böngésző intró: színes ajtók, de zene nélkül. Utána jöttek a mozgó téglatestek, de már zenével. A következő böngésző demóban valami mozgott a kamera felé. Á, ezek halak akarnak lenni. Ügyes! Újabb JS demó. Egy félbetört valami, ami a zenére mozog. Kezd összeforrni. Mi a csuda? Oh, a zene meggyógyította a szívet. Micsoda művészet! Ezeket szeretem, amiben van egy kis történet. Nagyon jó volt. Még egy böngésző: valami cellulár autómata, de a "zene" bántja a fülem. Metaball hadsereg halad a barna folyosón a fény felé. A címe mindent megmagyaráz: A reggel, amikor a mexikói étel keresi a kijáratot. Még egy raymarching, de pixelek helyett emoji karakterekkel kirajzolva. Nevezzük akkor inkább emoji marchingnak? A HBC 1k-t csinált, ők a következők. Folyadék szimuláció, de közben felolvassa a shader forráskódot egy beszéd szimulátor. Ügyes, nagyon ügyes. Az újabb intróban fekete golyók masíroznak. Lepottyannak, összeállnak. Digimind-al véget ért a böngészők demója, mostantól csak C++ lesz. Ők egy raymarching folyosót készítettek. Érezhető a minőségi ugrás a böngésző demók után, Végül egy felhős raymarching. Tetszett.

4k intro

Egy tron-szerű demó, ahol egy mountain bike mássza a dombokat. Aztán shadert vált, de továbbra is dombon mászik. Oké, megjött az első fraktál demó, a második release formájában. Közben dubstep. Az End of Iceland, a harmadik intró egy tájképpel indít. Majd jön a lárva. Nos, technikailag nem lárva, mert már szárnya van, tehát kifejlett lény. Aztán a tájkép tűzbe borul. A következő is hasonló, csak itt nem rajzfilm-szerű shader van, az élek például feketék, és nem lárva jön, hanem egy repülő kígyó. Terrarium: ez fotorealisztikus üvegek között mászkál a fény. Ezt meg kell néznem valódi vason is. Ez biztos nagyon érdekes. Az utolsó ismét egy felhős raymarching, csak úgy, mint 1k-ban. De a felhők közül egyszer csak kijön egy kétfedelű felhő-repülő. Nem semmi, nem semmi. Mikor azt hinnénk, már mindjárt vége, akkor jön a felhő-vonat!

64k intro

A chaten azt olvasom, nem lesz Conspiracy, de azért én nem félek attól, hogy nem lesznek jó cuccok. Egy Linuxos 64k-val kezdünk, LA1984 néven, ami a Terminator első részét eleveníti fel. Nem, nem az akciót, hanem a szöveges bevezetőt. Majd jön az 1989, zaj, non figuratív elemek, mintha egy Paintttel készült volna. Browser demo egy piramissal, majd jöttek a tükröződő golyók. Oké, oké, mostantól biztosan jön a komoly szakasz. Eddig csak a bemelegítés volt. Ah, vége az egész kompónak. Ennyi volt. Valaki a chaten azt mondta, hogy olyan magas a léc 64k-ban, hogy sokan inkább visszatartják az intrókat, mintsem kiadják. Én is ezt látom. Két szint van: a vállalhatatlanok és az über jók. Nincs középmezőny.

Demo

Már nem merek semmit mondani. Jöjjön, aminek jönnie kell. Az első szó szerint egy ürülék. Még jó, hogy úgy harangozták be ezt a kompót, mint amire a mai számítógépek képesek. A streamen meg a "where the magic happens" van. A második Python demó, de csak egy scroller. A harmadikban már effekt is volt. Olyan, mintha valakinek az első produkciója lenne. Kellemes volt a zene is, kicsit hosszúak voltak az egyes részek. A következőkben egy absztrakt valamit kapunk, amiben a számítógépek elpusztítják az emberiséget? Talan erről szólhat, de ezt is csak a szövegből tudom, mert a képi világ teljesen elvont. Majd jön egy egy emberes produkció Gambler néven. Majd Ozymandias C# demó. Egyszerű, de nagyszerű. A csapat láthatóan grafikus gondokkal küzd. Utána egy böngésző demó a 90-es évekből, amiben egy PC képernyőjén a nagy nevű csapatok láthatóak különböző hibaüzenetek társaságában. Végül a monitor elsűlyed, a Pc demoscene meghalt. Másoknak is ez a véleménye a chaten. Aztán valami party invitáció következik. Demók voltak a demókban, mármint a demóban számítógépek voltak, amelyek demókat játszottak le. Előnye, hogy állítólag Linuxon is fut. Folytatódott a tavalyi kenyér űrhajó utazása. A cél állomásig még nem jutottak el. Ígéretük szerint lesz egy harmadik rész is. Majd az Ate Bit csinált egy elvont demót, nem is tudom mi volt benne. De láttunk várost, embereket egy szobában, tunnelt. Valamiről biztosan szólt, csak nem értettem. Aztán jött a Hypertension zajdemó. Valaki azt írta róla, hogy a migrén vizuális reprezentációja. Tökéletesebben ki sem fejezhettem volna magam. Jugz Unity demója Forgott valami bigyó egy parkolóházban és megjelentek-eltűntek kockák. Aztán Pyrotech demó. Végre! Bár nem volt túl sok kapcsolat a részek között, nagyon szép jelenetek voltak. Az óramű belsejét mutató jelenet nagyon tetszett. Azt élőben is megnézem, ha majd jó lesz a gépem. Aztán Adapt! Kicsit zavart az elfolyó effekt, de azért nem volt rossz. Szóval itt a középmezőny. Kellett nekem elkiabálni. Ennek a kompónak is vége.

Összefoglalás

Az idei Assembly gyengébb volt, mint a korábbiak. Nem mondom, hogy katasztrofális, mert azért minden kategóriában láttunk valami érdekeset (64k intrót kivéve). Ez most megint egy hullámvölgy, mint amilyen három éve is volt. Akkor sem voltak 64k-k, demóban pedig hiányzott az első vonal. Most ugyan ezt történt.

Annyi, de annyi időm van, hogy még az idei Assemblyt is ráérek streamről nézni. Ezért kicsit részletesebb leírást adok az egyes compókról. A kivetítő valami hatalmas. Ránézésre három fullHD képernyő, egyben. Ezt látni kellene élőben is. Az írási stílusom biztosan szokatlan lesz, mert egyszerre nézem és írok. Később viszont csak keveset szerkesztem.

Game

Az első bemutató valami FPS. A játék menetet nem is látjuk, csak ironikusan ecsetelik, milyen összecsapott munkát látunk. Látunk egy szöveges kalandjátékot, ahol régi számítógépeket cipelő emberek vannak egy utópisztikus világban. Végre egy érdekes játék: Buster a pókember. Mármint egy törésteszt bábu (akit a Mythbuster sorozatban csak Buster néven emlegettek) rugalmas kötél segítségével ugrál egyik helyről a másikra. Még ránézésre is nehéz. Van egy pék, aki kenyeret gyűjt. Lángszóróval felégeti a búzametőt, lapáttal csapkod szőrös teremtményeket (kenyérpusztítókat?). Horror játék egy régi házban. Alone in the dark koppintás. Horror játék egy iskolában. Igen, ez már hihetőbb :-) Horror játék egy temetőben, azt hiszem. Túl sötét, hogy megállapíthassam. Egy aranyos ugrálós játék következik, amiben nem szabad túl magasra sem ugrani. Van egy AC-130 szimulátor. Vezetheted a gépet és lőhetsz a Horowitz ágyúval, vagy egy haverral is játszhatsz, egyik lő, másik vezet. Roncs eszközök rakétával lövik egymást. Ránézésre ennek a legjobb a játszahatósága, legszebb a grafikája.

Fast graphics

A téma a kolbászok voltak. Nukleáris kolbászok. Low poly modellekkel indult a kompó, meglepő, hogy egy óra alatt ilyen modelleket készítettek, és még képszerkesztővel is fel tudták javítani. Azt hiszem, ez az igazi rutin. A szókincsem is bővül: A nakki lehet finnül a kolbász. Az Also a vegan options nagyon jó volt. Tableten rajzolták, majd egy Mac-en végezték az utómunkát.

Pixel graphics

Az első Pac-Man szellemek CGA színekben. A második egy nagy szemű emberke. A Lunar Hope volt az első, ami mondani is akart valamit. Témája a hold kolonizálása. A következő egy macsak Amiga labdán. Ez egy olcsó trükk a szavazatok megszerzésére. Majd jön egy nagy polip. Utána egy óriás rák, ami elpusztít egy falut. Az Orientalist Cat nagyon részletesen kidolgozott kép. Most még egy szörny-kép van, egy víz alatti óriást polip. Úgy látszik a szörnyek túlreprezentáltak idén.

Fast music

Ez tényleg gyors volt. Az első két szerzemény BeepBox-ot használt, amiről még nem is hallottam, de ha ez a program képessége, akkor nem is fogom kipróbálni. A Gas station rossz volt. Még a bot fülemmel is hallottam, hogy nem találja el az akkordokat. Utána sem javult sokat a helyzet. Valami kakofón ének összevágás is volt. Az első, ami már tetszett, a számomra kimondhatatlan taantuma os-tos-reissulla volt. Utána már nem voltak szörnyű zenék, de nem is tetszettek. Ez nem igaz, a Rainbow Route to Unicord Dragonland tetszett. Mintha tavaly is lett volna egy ilyen ömlesztett nevű zene, nem? Majd utána nézek.

Tracked music

Erről a compóról nem tudom, mit írjak. Valami miatt összefolynak számomra az alkotások. Nem volt se kiugróan rossz, se kiugróan jó alkotás. Változatos PC és Amiga trackekket is hallhattunk.

Themed photo

A témának a fény és árnyék volt megadva. Az első kép semmi. A második egy villanykörte. Technikailag jó, de semmi újdonság. A New Hope szerencsére nem Star Wars volt, de a kép nem volt elég kontrasztos, nem volt kiemelve a téma. Gyöngyök, absztrakt fotón. Következőt! Á, szép ellenfény és egy szúnyog, vagy lepke. Játékok harcolnak füstös terepen. Érdekes, érdekes. Szép gyöngyök, mint egy valódi raytrace. Ez már sokkal jobb. Még egy ellenfény, de ez kevésbé sikerült. A munkagép alig látszik, túl sok sötét van a kép tetején. Szétszedett, törött repcsi. Nagyon érdekes. Érdekelne, hogy ki aggat ilyet a mennyezetre. Még egy vizes-fényes raytrace-szerűség. A vízcsepp lebeg a sakkbábuk felett. Határozottan profi. Ellenfényes akt. A lila megvilágítás határozottan szokatlan, de nem rossz. Fényfestéses fénykép elő modellel. Biztos sokat szenvedtek, mire összejött. Olyan, mintha varázsolna a hölgy. Hmm, tetszettek a fotók.

Graphics

Űrállomás. Többször láttam ez az Eevee-t, mint felhasznált eszközt, mi lehet ez? Szeletelt halak. Éjszakai riutálé. Az öreg halász és a tenger hollywood-i feltúrbózása. Templom, lovag, tűz. Troll, aki a neten trollkodik. Milyen avantgard! Nem írták ki, de a következő kép, biztos, hogy Maxxon műve. Felismerem. Széllel szemben. A Marvell hősök már a spájzban vannak. Babyfood. Morbid, ha belegondolunk, de vicces felütése van. Szörny a mélyből. Nahát! Ez a madár kalitkás nagyon jó lett. Túl sötét kép egy Disney művészről, aki valami csatornában ül, és munkásnak van öltözve. Értem, értem, de valami mégis hiányzik. Nem tudom megfogalmazni, hogy mi, pedig tudatosan komponált.

Listening music

Ez már döfi! Mindjárt a legelején ütős dalok szerepeltek. Tetszett, hogy egyesek a stílusokkal is kísérleteztek, például westernnel. A zene compón nem jellemzőek a vicces alkotások, de most mégis belefutottam egybe. A kávé iránti olthatatlan vágy ihlette eposzban még a zene stílusa is megváltozik, amikor a költői én nem kapja meg koffein adagját.

Real wild

Lássuk, milyen agyatlan hardverre programoztak. Az első egy iOS demó volt. Nos, ez sem lenne jó platform reklámnak. Még akkor sem, ha csak UIKittel készült. A második az Assembly kivetítőjére írt demó volt, Linuxon futott. Az effektív pixel szám a kommentek szerint 7501x1500 volt. Ez egy kihagyhatatlan ziccer, okos döntés volt egy teljes képernyőt befedő demót készíteni. Volt egy Logitech G810 billenytyűzet is, ami három színű leddel volt felszerelve. Azt nem tudom, hogy a program a billentyűzeten futott, vagy a számítógép vezérelte. A zenét sem tudom, honnan jöhetett. de ez is valami Linuxon hajtott dolog volt. Az iOS-re válaszul volt egy Android demó is. Nem valami nagy, de látványos és jól összerakott alkotás volt, A végére maradt az igazi vad demó. Négy Raspberry Pi képernyő feküdt egy-egy LEGO Mindstorm vezérelt lánctalpon, ami mozgott a demó ritmusára. Igazi kütyü-katyvasz volt. Tényleg nem tudom, mit lehetett volna még belepakolni. Talán egy Arduinót?

Short film

Az első egy galaktikus utazás volt, kellemes zenével. De nem igazán történt benne semmi, csak valami kék csillagközi ködben repült a kamera, egyenes vonalban. Volt egy rablásos videó, ahol a részek kicsit lazán kapcsolódtak egymáshoz. Pistoke valami barokk részecske gyorsítóba vezetett minket. Hol építették ezt fel? Hé, ez render! Sokára esett le. Na végre, fraktál videó! Ez sem tiszta, hogy miről szól, de több benne a retró szeretet, mint a Los Angeles Lamers videóiban. Volt egy Minecraftba ágyazott Trump kritika is, amit elsőre nem is értettem, mert annyira követem az aktuál politikát, szerencsére a stream kommentelői elég szószátyárak, abból felfogtam, mi az ábra. Aztán egy újabb retró egyveleg. Ezúttal sokkal elvontabban. HBC! Már az első kockán láttam, hogy HBC. Szokásos humoros alkotás, ötletes jelenetekkel. A végén kiírták, mennyien készítették. Jó sokan! Újabb humoros alkotás, Jézusról, aki inni akar egyet, de leejti az üveget, mire egy hobó megtalálja, és szétlocsolja azt.

Oldskool compo

Itt az első scroller. Mi is lenne az oldskool kompóval scroller nélkül? Amiga comp filler. Ez is egy scroller, csak spirálisan megy. Assum egy nagyon jó kis Atari Falcon demó. Úgy kezdődött, mint egy film, a zenéje is nagyon hatásos. Adapt egy retró hangulatú demót hozott a 90-es évekből. A Pyu Pyu viszont ellenkezőleg. Nagy felbontású, 60 Hz frissítésű, full frame demót hozott. Szerintük a régi gépekből is lehet modern dolgokat kihozni. Igazukat ezzel a demóval bizonyítják.

Dance music

Lehet, hogy már fáradt vagyok a táncoláshoz, de ez a kompó is teljesen összefolyt.  Kár, mert ez az egyik kedvenc zeneforrásom. Talán máskor.

Szokták mondani, hogy mindenki jó valamire, mást nem elrettentő példának. De azt is hozzá kell tenni, hogy mindenki fejlődő képes. Mindenki jobb lesz, ha sokat csinál valamit.

Úgy hozta a sors, hogy megint láttam akció közben Stant és Pant, az intézet két legendás rendszergazdáját. Igen bonyolult, és körmönfont feladatot kaptak: Nyomtatót kellett telepíteni. Linuxra!

Előzményként annyit érdemes megjegyezni, hogy a PhD hallgató, aki még mindig két hete várja a számítógépét, kapott egy cserekészüléket, hogy amíg megjön az igazi vas, tudjon min játszani. Erre a gépre az IT telepített Linuxot, Sophost, és nem adtak rendszergazdai jelszót, mert ennyire utánozzuk a nagyvállalati környezetet.

Ha viszont nincs sudo/root jelszó, akkor a gép konfigurálását a rendszergazdáknak kell megtenni. Eljött Stan és nekilátott a munkának. Én levettem a fülhallgatót, mert tudtam, hogy sokkal jobb előadás következik. Csak reménykedtem benne, hogy a gép működő képes marad. Illetve nem, biztosra vettem, hogy használhatatlan lesz.

Stan először nem találta a nyomtatót. Mármint nem az asztalon, mert az látótávolságban volt, hanem a hálózaton. Azután arra panaszkodott, hogy két nyomtatót is lát ugyan azon a címen. Majd, miután kigyógyult kettős látásából, csönd lett. Egy órán keresztül nem mondott semmit, csak az enter billentyű egyre erőteljesebb leütése árulta el, hogy valami nem sikerül.

Bár ő volt az egyik rendszergazda, elég sűrűn kérte a felhasználót, hogy írja be a jelszavát. Bevallom, ezt nem tudtam hova tenni, gondoltam, ki fog derülni a végére. Másfél óra múlva kifakadt:

- Nem engedi!

- Mit nem enged? - kérdeztük.

- Nem engedi feltenni a csomagot.

- Miért nem engedi? - kérdeztük, ahogy az általános iskolába a tanár próbálja kiszedni azt a kevéske tudást a felelő fejéből.

- Nem tudom, csak azt írja, hogy nem engedi. Szerintem újra kell telepíteni az operációs rendszert.

Egy kollégám finoman megmutatta neki, hogyan nézheti meg a hibaüzenetet. Ebből még Stan is látta, hogy nem az operációs rendszert kell újratelepíteni, csupán egy függőséget felrakni. Egy pythonos D-BUS csomagot.

Stannal vigyázni kell. Nagyon ideges lesz, nem csak az operációs rendszert fogja újra telepíteni, hanem létrehoz egy másik processzor architektúrát, és akkor jajj a számítástechnikának.

De a pythonos D-BUS telepítése sem ment zökkenő mentesen, mert kiderült, hogy mindent user space-be akart telepíteni. Ezért kellett neki a felhasználó jelszava! Azért, hogy a nem szakmabeliek is értsék, ez olyan, mintha egy autószerelő az utastérbe akarná tenni a motort, de az a fránya anyós ülés ezt megakadályozná.

Egyik pillanatban felpattant, és azt mondta, elmegy a telefonjáért. Mikor visszajött, Pan volt vele. Lehet, hogy a beceneve Telefon, nem tudom. Már ketten akarták a felhasználó könyvtárába pakolni a rendszer fájlokat. Egy ponton Pan megállapította, hogy miért nem sikerül erőfeszítésük:

- A nyomtató jelszóval védett.

- Akkor én hogyan tudom jelszó nélkül használni? - kérdeztem csodálkozva.

Ezután új hipotézis után kellett nézniük. Sajnos ekkor ott kellett hagynom őket, mert egy megbeszélésre kellett mennem. Ekkor már két órája próbálták a nyomtatót telepíteni.

Az igazán meglepő, hogy végül sikerült nekik. Sikerült feltelepíteni és még gép is működőképes maradt! Több, mint két órát vett igénybe, két ember kellett hozzá, de megoldották. Fejlődnek. Nagyon lassan, de fejlődnek.

Szakdolgozóimtól meg szoktam kérdezni, miért akarnak bioinformatikával foglalkozni. Legtöbbjüknek nincs előzetes tapasztalata a témában, ezért színtiszta prekoncepció, amit mondanak. Legtöbbször az hallom, hogy "ez fontos", "nagy szükség van rá", stb.

Ez egy baromság. Ha csak emiatt akar valaki bioinformatikus lenni, legjobb, ha tűzoltó lesz, mert akkor tényleg érezheti, hogy fontos munkát végez.

Természetesen fontos a bioinformatikai munka, mint ahogy a gumicsizma is fontos munkát végez, ha tehén istállóban dolgozunk. De a munka végeztével nem a kandalló párkányra helyezzük, a családi fényképek mellé. Nem mutogatjuk a vendégeknek: Látod azt a gumicsizmát? Az igazán derék munkát végez. Nélküle még most is bűzlene a lábom.

A bioinformatikában sincs másként. A laborosok fejéből kipattan valami, amit sürgősen meg kell csinálni, ha pedig megkapják, a bioinformatikust elfelejtik. Ha megkérdezik tőlük:
- Hogyan készült ez az ábra?
- Nem tudom - válaszolják. - Valami kócos ember csinálta, aki itt őgyelgett.
- Nem egy kollégád?
- De, csak nem emlékszem a nevére. Tudod, ő egy bioinformatikus.

Nem véletlen, hogy sokan a bioinformatikai csoportokat csak "adat parazitáknak" tekintik, akik semmi mást nem csinálnak, csak lefuttatnak egy programot olyan adatokon, amit mások véres verejtékkel állítottak elő. Miért van az, hogy egy vegyes (tehát ahol laboros munkát is végeznek) kutatócsoportban csak a bioinformatikusnak nincs első szerzős cikke? Ha olyan fontos a bioinformatika, miért nem kérik ki a véleményüket a kísérlet tervezése során? Utána meg megy a sírás, ha az újság nem fogadja el a két ismétlésen alapuló Wilcoxon tesztet. Miért kell harapófogóval kihúzni az elemzéshez nélkülözhetetlen részleteket a laborosokból?

A válasz egyszerű:

Mindezt az hozta elő belőlem, hogy a Sangerből ismét kijöttek egy cikkel. Nagyon jó cikk, emlékszem mennyi RNA-seq elemzést csináltam az első szerzőnek ezzel kapcsolatban. Aláírom, a legtöbbnek tényleg nem volt semmi értelme, ez már akkor is látszott. De valahogy megfeledkeztek erről és még a köszönet nyilvánításba sem tettek be. Meg is kérdeztem tőlük, hogy miért hagytak ki, de még csak válaszra sem méltattak.

A csoportnak van egy új bioinformatikusa, akiknek az idéjét valószínúleg azzal pazarolták, hogy megismételtettek vele mindent, amit én csináltam. Egy paraszt lekerült a sakktábláról, de van helyette másik. Érdekes, a labor vizsgálatokat valahogy soha nem ismételtetik meg. Hiszen az pénzbe kerül. Az elemző programok meg "ingyen" dolgoznak.

Ennyire fontos a bioinformatika és ennyire fontos a bioinformatikus. Mit lehet tenni ellene? Több csoportnak is dolgozni, több projektbe is befolyni. Mert ha három témán dolgozunk, akkor egy elhal féluton, egynél amnézia lép fel a szerzőknél, egy pedig eljut a publikálásig.

Az egyik nap, amikor a lányomat vittem az óvodába, az egyik csoporttársa képregényén megakadt a szemem. A főszereplők ugyanis nem mutánsok vagy a fizikai törvényeknek figgyet hányó lények voltak, hanem részecskék. Amit olvasott, nem volt más, mint egy részecske fizikai képregény!

Ez egy érdekes emléket idézett fel bennem. Gyerekkoromban a városi könyvtárban láttam egy képregényt, ami a relativitás elméletet magyarázta. Sajnos a címére nem emlékszem, csak azt tudom, hogy egy francia fizikus írta és rajzolta, és az egyik női főszereplője szinte kizárólag fürdőruhában szerepelt...

Némi hasonlóságot itt is tapasztaltam, amikor a top és bottom kvarkokat igyekeztek elmagyarázni. Szerintem szavak helyett sokkal többet mondanak a képek:

Ilyesmi is csak a 80-as években készülhetett, amikor a Magyar Népmesékben az igazságos Mátyás király hülye feladatok elé állított szép fiatal lányokat, és Szaffi meztelenül fürdött.

Annyit papoltam a régi hardverekről, hogy most utólért a végzet. Az asztali gépem bedöglött (valószínűleg tápegység gond), a DOS-os gép továbbra is fagyogat, ráadásul menrég a feleségem laptopja is elutasította, hogy bekapcsoljuk.

Ez röviden annyit tesz, hogy a család x86-os architektúrára épülő gépparkja 50%-os veszteséget könyvelhet el. Ami maradt egy 14 éves AMD Athlon, egy Dell Inspiron, ami hét évvel ezelőtt sem volt túl erős, és egy Compaq Armada 100S.

Ez utóbbit egy melóhelyi takarítás után szereztem, sok más kinccsel együtt, amikről még írok. Volt több gép is, de ez nézett ki a legrégibbnek, mert ebben még beépített floppy meghajtó is volt. Még LAN kábelt sem lehet beledugni, gondoltam érdekes dolgokat fogok csinálni vele.

Az akkumulátora természetesen halott volt, de a Windows XP szépen működött és még az infra portot is látta. A tapipad bal gombját nem lehetett lenyomni, a burkolat egy-két helyen repedezett, a BIOS beállításokat nem tudta megjegyezni, de ezt leszámítva nem volt vele probléma.

Telepítettem erre is egy FreeDOS-t, de a StarCommander valami miatt nem reagált sem a billentyűzetre, sem a tapipadra. Ekkor szereltem szét először, amikor kiderült, hogy a jobb egérgomb beszorult a burkolat alá, amitől folyamatosan le volt nyomva. A hiba korrigálása után minden program az elvárásoknak megfelelően működött.

De továbbra sem használtam semmire. A DOS-os demókat a GUS-al szerelt gépen néztem, rezignáltan tűrve a random bootokat. Majd az elsődlegesen használt gépek szépen bedöglöttek, és ahogy a maffiánál is lenni szokott, a hátul kullogók előre törtek.

Ezért úgy döntöttem, hogy ezen a gépen kipróbálok egy csomó operációs rendszert, mindegyiken végezve valami "hasznos" munkát. Jöjjön ismét a FreeDOS! Kicsit alaposabban bemutatva.

A doksi szerint FreeDOS alatt is lehet használni USB meghajtót, ami nagy könnyebbséget jelentene a fájlok továbbításában, mert floppy csak ezen a gépen van, infra driver nincs DOS-ra (ez nem pontos, COM portként működik, azt meg lehet DOS-ből használni), CD lemezeket meg nem akarok írni.

Az USB csak UHCI kontroller esetén működik és csak FAT fájlrendszert olvas. Ha ezek a feltételek adottak, akkor csatlakoztassuk a meghajtót és adjuk ki az usbdevice parancsot. Ez kilistázza az elérhető USB hubokat. Ha látjuk a pendrive márkáját, az már félsiker. A következő lépés a meghajtó elindítása. Ez az usbhci.com. Ez beül a memóriába és várja a parancsokat. Minden típusú USB eszközhöz van egy program. Találunk usbkey.com-ot, usbdrive.com-ot, de még usbprint.com-ot is. Én csak a pendrive-ot akartam használni, ezért a második meghajtó program az usbdrive lesz. Ez hozza létre a meghajtó betűjelet, amit már FreeDOSból is használni tudunk.

Ha sok USB csatlakozónk van, akkor kell egy kicsit játszani, hogy megtaláljuk, melyik meghajtó melyik csatlakozóhoz tartozik, de nekem könnyű dolgom volt, mert csak egy USB 1.0 van a gépen, tehát az E: betűt foglalta le.

Parancssorból nekem nem működött, de DOS Navigatorból ment. Nagyon nagyon lassan, de ment. Volt 40 MB adatom (egy Python interpreter, két grafikai alkalmazás és egy animáció készítő program), amit cirka 61 óra alatt akart átmásolni.

Nem tudom, mi okozta a gondot, de azt láttam, hogy kb. 2 percre teljesen megfagyott a gép, majd feléledt 3 másodpercre, ekkor frissítette a képernyőt, majd ismét két perc csend. Hatvanegy óra az elég rossz hatásfok. Ha lefekszem aludni, másnap elmegyek a boltba egy CD-t venni, hazajövök, kiírom, még akkor is gyorsabb, mint USB-n átmásolni.

Végül egy Knoppix segített a dolgokat megoldani. (Egy nagyon friss, 2006-os CD lévő Linux disztribúció.) Knoppix alatt felcsatoltam a DOS lemezt, a pendrive-ot és átmásoltam mindent. Kevesebb, mint egy perc alatt.

A DOS-os Pythont az ibiblio oldalán találtam meg. Sajna hosszú fájlneveket tartalmaz a zip, ezért kibontásnál kérdezte, mit csináljon az azonos nevű fájlokkal. Azt mondtam neki, írja felül a régieket. Úgy néz ki, a program működik, de igazából egy időzített bomba. Nem tudom, mikor fogja lefagyasztani az egész rendszert. Ráadásul elég régi Python, csak 2.4-es.

QuickView Pro-val még a fényképeimet is meg tudtam nézni. Persze csak 3 megapixelig, nagyobb felbontásnál a gép újra indult. Rajzolni a VGA Paint programmal próbálkoztam, de ez még a Windows-os Paintnél is egyszerűbb. Még vonal vastagságot sem lehet beállítani.

A hangkártyát viszont nem tudtam működésre bírni. Ebben a gépben egy VIA hangkártya van, ami elméletileg Sound Blaster kompatíbilis, de csak ha a BIOS-ban beállítjuk. Sajna ott nem volt egyetlen hangkártyára vonatkozó beállítás sem. Ha pedig mindenre fittyet hányva beállítom az alapértelmezett értékeket a BLASTER környezeti változóba, semmi nem történik.

Demók közül egyedül a 256 byte intrókat nézegettem. Azért látszott, hogy az újabb alkotások rendesen megizzasztották az 550 MHz-es processzort. Néhánynak még a forráskódja is megvolt. Nasm van alapból FreeDOS-ban, ezért gyorsan megpróbáltam lefordítani őket. Gond nélkül ment.

Ekkor jutott eszembe, mi lenne, ha megtanulnék assemblyben programozni és írnék egy 256b intrót Function-re. Már érlelgetem egy ideje, hogy érdemes lenne alacsony szinten is programozni, de a lustaság nem vitt rá, hogy pár könyv megvásárlásán kívül konkrét lépéseket is tegyek.

Most viszont, ha szabad ezt mondanom, nincs más választásom. Az elmúlt időben egy csomót DOS-oztam, és nem akarom senki nosztalgikus érzését megbántani, de ez egy annyira primitív rendszer. Látszik, mennyit dolgoztak a FreeDOS-on, mert sokkal kevésbé gáz, mint amire a DOS 6.22-ből emlékszem, de még így is nagyon nehézkes. Nem is értem, hogyan születhettek olyan nagyszerű programok erre a platformra. Mintha az egész operációs rendszer azért lenne, hogy nekem rossz legyen.

De talán ebből az egyszerűségből következően könnyebb lesz megtanulni assemblyben programozni és az egyetlen compó, aminek ez a preferált platformja, a 256 byte intró. Majd meglátjuk mi sül ki belőle.

Androidon a nem úgy megy a fejlesztés, mint asztali környezetben, ezt kezdem megszokni. Az egyik ilyen probléma, a szálak kezelése. Ez elég egyszerű a közönséges Java programoknál. Ott az sem gond, ha a fő szál sokáig vár, például mert várja, hogy egy másik gép csatlakozzon hozzá.

Androidon ez probléma. Ott nem lehet a felhasználói felületet lebénítani, csak azért, mert egy esemény bekövetkezésére várunk. Ezért ezeket a problémás lépéseket egy új szálra helyezzük, ami kedvére várhat, miközben a tapicskolás is megmarad.

De mi a helyzet, ha több párhuzamos szálat akarok? Néhány próba kódot mutatok be, aminek nem is az a lényege, hogy hatalmas műhelytitkokat áruljak el, mert gondolom a profiknak ezek triviális megállapítások. Én viszont nem vagyok profi Android programozó, ezért rácsodálkozhatok ezekre a jelenségekre. Kipróbálok pár módszert, még akkor is, ha azok rossz programozói gyakorlatok.

Tehát a célom, hogy egy gomb megnyomására két párhuzamos szál induljon. Az egyiket nevezzük Bunak, a másikat Funak, mint a kínai emigránsokat a viccből.

AsynchTask

A doksi szerint ez a legegyszerűbb és legtisztább megoldás:

public class ParaThread extends AsyncTask<String, Integer, Long> {

    @Override
    protected Long doInBackground(String... names) {
        for(int i = 0; i < 15; i++) {
            Log.d("ParaThread", "Thread: " + names[0] + " is running" + i);
            try {
                Thread.sleep(500);
            } catch(InterruptedException e){
                e.printStackTrace();
            }
        }
        return null;
    }
}

Tegyük is bele egy gomb onClick metódusába:

public void onClick(View view) {
    new ParaThread().execute("Fu");
    new ParaThread().execute("Bu");
}

Ez alapján arra számítok, hogy a gomb megnyomása esetén Bu és Fu felváltva hagy üzenetet a logban. De nem ez történik. Először Fu üzeneteit látom, utána Bu üzeneteit. Ha rövid időn belül többször is megnyomom a gombot, akkor az eseményeket szépen puffereli. Tehát ez a megoldás nagyon jó, ha nem akarom millió szállal szétfagyasztani a rendszeremet. Tökéletesen biztonságos, annyiszor használom, ahányszor csak akarom.

De én ennél többet akarok, mert egy cowboy vagyok, aki szeret veszélyesen élni.

Thread

Készíthetünk saját osztályt, ami kiegészíti a Thread osztályt.

public class ParaThread extends Thread {

    private String name;

    public ParaThread(String myname){
        name = myname;
    }

    public void run() {
        for(int i = 0; i < 15; i++) {
            Log.d("ParaThread", "Thread: " + name + " is running" + i);
            try {
                Thread.sleep(500);
            } catch(InterruptedException e){
                e.printStackTrace();
            }
        }
    }
}

Sok változás nincs. Példányosítjuk a két osztályt.

private ParaThread pt1 = new ParaThread("Fu");
private ParaThread pt2 = new ParaThread("Bu");

Meghívjuk a szálakat a gomb lenyomásánál.

public void onClick(View view) {
    pt1.start();
    pt2.start();
}

Ez már jó! Bu és Fu felváltva írnak a logba. Ha többször akarjuk indítani, akkor is csak 2 szál fog futni. De ilyet nem szabad csinálni, azt mondják. Akkor csináljuk Runnable implementációval, hogy javasolják.

Runnable

Az osztályunk implementációja csak egy sorban tér el, ezért az nem írom le újból, de a használatához új szálat kell létrehozni.

public void onClick(View view) {
    new Thread(new ParaThread("Fu")).start();
    new Thread(new ParaThread("Bu")).start();
}

Ez már igen! Ha többször klikkelünk a gombra, akkor még két szálat létrehoz minden egyes klikkre! Ezzel már gond nélkül írhatjuk a veszélyes programokat.

Szerepjátékos koromban a legnagyobb kihívást a jó karakter nevek kitalálása okozta. Rendszeresen valami nyögve nyelős, erőltetett nevet találtam ki, ami általános derültséget váltott ki a csapatban. Ha akkor ismertem volna a Markov láncokat, mindez nem jelentett volna problémát.

A Markov láncok nagyon egyszerűek: Semmi más, mint egymást követő elemek. Azt, hogy miként követik egymást az elemek, valószínűségekkel adjuk meg, amit átmeneteknek nevezünk. Vegyünk például egy tornasort. A magasabbak elől állnak, az alacsonyabbak hátul. Annak a valószínűsége, hogy a legmagasabb valaki után következzen, nulla. Tegyük fel, több, azonos magasságú ikerpár is van ezen a tornaórán. Az ő átmenetét 0.5-el jellemezhetjük, mert hol az egyik van előrébb, hol a másik.

A Markov láncok általában csak az egymást közvetlenül követő elemekre adják meg az átmeneteket, vagyis a korábbi elemek nem számítanak. Ez akkor érdekes, ha nem egy tornasorra gondolunk, hanem más hosszú láncokra, amelyek viszonylag kevés elemből állnak. Mint amilyen a DNS is.

A Markov láncok segítségével bármilyen hosszú DNS-t jellemezhetek, hiszen csak azt kell megadnom, hogy egyik nukleotid milyen valószínűséggel követi a másikat. Ha a nukleotidok teljesen random követnék egymást, akkor ez nem lenne túl érdekes, mert az átmenetek csak 0.25-t tartalmaznának. De tudjuk, hogy a kódoló és nem kódoló szakaszoknál ez más, sőt fajokban is eltérhet!

Tehát ha az átmeneteket egy mátrixba gyűjtöm, akkor bármilyen hosszú DNS szekvenciát jellemezni tudok. A mátrix mérete nem változik.

Sőt, a szabály ismeretében bármilyen hosszú DNS szekvenciát is tudok generálni. Ennek persze nem sok értelme van, és nem is segíti a megértést, ha szekvenciákkal szemetelem tele a képernyőt, ezért inkább Gyűrük Ura neveket fogok generálni demonstrálásként, amiket fantasy játékokban lehet használni.

Először is szükségünk van az átmenetekre. Ezeket már létező nevekből kapjuk meg. A Wikipédiaból kimásoljuk az összes nevet. Én eltávolítottam az összes ékezetet, kötőjelet és angol kötőszót, majd a szöveget kisbetűssé változtattam. Minden név egy sorban van.

import sys
import random

transition = dict()
letters = set()

for i in open(sys.argv[1]):
   name = i.rstrip()
   for j in range(1,len(name)):
      pch = name[j-1]
      ch = name[j]
      if pch not in transition:
         transition[pch] = dict()
      if ch not in transition[pch]:
         transition[pch][ch] = 0
      transition[pch][ch] += 1
      letters.add(pch)

A transition nevű változó fogja tárolni az átmeneteinket. Most még csak az átmenetek számát tartalmazza. Ebből nekünk valószínűségeket kell kapnunk.

for ch1 in transition:
    s = 0
    for ch2 in transition[ch1]:
       s += transition[ch1][ch2]
    for ch2 in transition[ch1]:
       transition[ch1][ch2] = float(transition[ch1][ch2]) / s

Gyakorlatilag ez egy normalizálás, hogy 0 és 1 közötti értékeket kapjunk. Már csak a generálás van hátra. Ebben a programban csak 5 betűs neveket készítünk, de lehet kísérletezni más hosszúsággal is.

letters = list(letters)
ch1 = letters[random.randint(0, len(letters)-1)]
name = ch1
for i in range(5): # Length of the name
   r = random.random()
   s = 0.0
   if ch1 not in transition:
      break
   for ch2 in transition[ch1]:
      s += transition[ch1][ch2]
      if r < s:
         ch1 = ch2
         name = name + ch2
         break
print(name)

Néhány példa, hogy mi jött ki: Marwor, Frindo, Halanb, Brisen. Persze vannak teljesen használhatatlan nevek is: Hbelfr, Rgoron, Wirorf, Ndunha.

A bemeneti adatok most az összes karakter nevét tartalmazzák. Biztos érdekes lehet csak tünde, vagy csak hobbit neveken lefuttatni. Esetleg ha elég nagy listánk lenne, akkor nemek szerint is bonthatnánk. A következő posztban kicsit fejlesztjük a koncepciót és bemutatom a rejtett Markov láncokat.

Másokat hibáztatni egyszerű. Másokat hibáztatni könnyű, mert ezzek kifejezhetjük saját felsőbbrendűségünket. Rámutathatunk a gyarló alakra, miközben mi, a hiba felfedezői tökéletességünk teljes tudatában emelkedünk az égig, ahol vár a glória. Még több alantas emberre mutatunk, tovább emelkedünk. Egészen addig...amíg rá nem jövünk, hogy mások ócsárlása közben mennyi hibát követtünk el.

Megkértek, hogy telepítsek egy rakás bioinformatikai programot egy olyan gépre, amin alig van használható program, a rendszergazdák nem válaszolnak a levelekre, furcsán van konfigurálva és szinte semmihez nincs jogosultságunk. Egyszóval a szokásos felállás.

El is kezdtem telepíteni a programokat a progs könyvtárba. Mindegyik program saját alkönyvtárat kapott. A munka során a szerverre néha nem lehetett belépni, néha teljesen le volt terhelve, egyszóval semmi rendkívüli nem történt.

Egészen a Fusioncatcher telepítéséig.

A program igyekszik megkönnyíteni a függőségek telepítését, ezért egy kérdés-felelet formájában feltelepíti a neki szükséges összes adatot, programot, mindent, a saját könyvtárába, másoktól rejtve. Legalábbi ez az alapértelmezett beállítása. Bitmumus viszont javasolta, hogy ne a fusioncatcher könyvtárába tegyem a programokat, hanem a progs könyvtárba, mert akkor mindenki tudja használni. Ezt remek ötletnek tartottam. Telepítés során meg is kérdezte hova telepítse a blat, STAR, liftover, stb. programokat. Én pedig minden egyes alkalommal kértem, hogy a progs könyvtárba tegye.

A végén gondoltam megnézem, mit is alkottam. A progs könyvtárban csak a seqtk program ült nyugalomban. De miért nem a saját alkönyvtárában? Hol van a többi program, amit már felraktam? Biztos megint valami fájlrendszer hiba, ami múlt héten is volt. Miért nem lehet rendesen megcsinálni egy szervert?

Elpanaszoltam mindenkinek, micsoda trehány munkát végeztek a rendszergazdák, mennyire hátráltatják a munkánkat és még csak nem is válaszolnak a levelekre, amit küldünk nekik.

Este lefekvésnél is csak ezen rágódtam, amikor megértettem, mit is csináltam. A fusioncatcher megkérdezte, hova tegye a programokat, én meg az összes program szülő könyvtárát adtam meg! Amit létrehozott (ergo törölt minden tartalmával) és beletette a kérdéses programot. A következő program telepítésénél ugyan így jártam el, és természetesen a Fusioncatcher teljesítette is a kérést. A végén ezért csak az utoljára telepített programot, a seqtk-t láttam.

Nem volt semmiféle fájlrendszer hiba, sem tehetetlen rendszergazdák, csak egy ostoba bioinformatikus, akinek könnyebb volt másokat hibáztatni, mint felismerni saját tehetetlenségét. Másnap töredelmesen be is vallottam bűnömet.

Az otthoni gépemet állandóan buherálom. A buherálás olyan mértéket öltött, hogy buherálás nélkül már nem is megy. Két rendszer van rajta. Egy Windows, hogy tudjak demókat nézni és videókat szerkeszteni és egy Linux, gyakorlatilag minden másra.

A Windows két vinyón terpeszkedik, alaplapi RAID 0-ban, mert a sebesség a mindenem. Az adatbiztonság másodlagos. A Linux is RAID 0-n van, de szoftveresen. Ezzel el is értem, hogy egyik oprendszer sem látja a másikat. Ha valamit mégis mozgatni kell, akkor valamit buherálni kell.

A Linux egy Slackware, amihez nem érkeznek automatikus frissítések. A böngésző, a könyvtárak az évek során szép lassan elavultak, egyre többször találkozom olyan weboldallal, amit nem tudok rendesen megjeleniteni. Ezért telepítettem egy új böngészőt, ami képes frissíteni magát. A beállításokkal valami gubanc akadt, az előzmények az egyik böngészőben megjelennek, másikban nem. Én pedig rendszeresen azt indítom el, amelyikben nincsenek.

Telepítettem rá Hadoopot, új CUDA-t, Torcs-t, Tensorflow-t. Mindegyiket forrásból, függőségekkel, egyedi beállításokkal. Minden hekkelve, átmeneti megoldásokkal, amelyek végül megkövültek és lustaság hiányába véglegessé változtak.

Aztán még nem is írtam olyan problémákról, amikor néha a gép ATA hibára panaszkodva nem hajlandó elindulni. Mindez belepréselve egy pici házba, ahol ha túlságosan megnyomom az oldalát, akkor az alaplapról lecsúszik az előlapi USB csatlakozó. De már olyan is volt, hogy a processzor hütőventillátora kezdte kóstolgatni az egyik kábelt, amelyik túl közel merészkedett hozzá. Linux alatt nem megy a két monitor és még sorolhatnám.

Úgy döntöttem, elég volt. Pöccre működő rendszert akarok. Ehhez viszont rendes Linux kell. Olyan, amelyiket támogatják a cégek, mégis tartogat egy kis újdonságot. Mivel Kubuntu van a munkahelyemen, az egyik otthoni laptopon, a CentOS mellett döntöttem.

A telepites csak úgy ment, ha nem volt az optikai meghajtó bekötve, különben dobálta az ATA hibákat. Ezt is meg kell oldani! Az alaplap kézikönyvét olvasgatva észrevettem egy furcsaságot. Azt írta, ha régi Windowst telepítek CD-ről, akkor csak a SATA5 csatlakozót használjam. Ez a csatlakozó teljesen külön van a többi SATA csatlakozótól. Rádugtam az optikai meghajtót és a hiba megszűnt. Sőt, a rejtélyes Windows fagyások is megszűntek.

A Linux új diszkre került, ezért a régi RAID-et megszűntettem. A kábelek száma is lecsökkent. Felszabadult egy csomó hely a házban.

A telepítés után egy gond volt csak: Először a GPU meghajtót raktam fel, és csak utána a CUDA-t. Ez utóbbit csomagkezelőből, ha már úgyis van. A CUDA pedig volt szíves egy régebbi GPU meghajtót telepíteni. Egy ideig nem is volt gond, csak aztán jött egy kernel frissítés. A KMS pedig kereste az új GPU meghajtót, hogy lefordítsa a szükséges kernel modult. De az már messze járt. A Linux pedig nem indult.

Miközben a GRUB paramétereit maszíroztam, hogy legalább konzolosan el tudjam indítani a gépet, azon kaptam magam, hogy megint buherálok. Ennek már úgy látszik soha nem lesz vége.

Végül visszatelepítettem az új GPU meghajtót. Ment a CUDA is, a két képernyő is, hurrá. Jöjjenek a gépi tanulás csomagok. Ekkor jött a hideg zuhany. A CUDA túl új volt nekik. Nekik a 10.0 kell, nem a 10.1. Először még eljátszottam a gondolattal, hogy néhány symlinkkel átverem a rendszert, de leállítottam magam. Nem fogok tovább buherálni!

Megpróbáltam csomagkezelőből eltávolítani, de az sem ment. A CUDA ugyanis egy meta-csomag volt, telepített egy csomó más csomagot. Mikor el akartam távolítani, csak a meta-csomagot tűntette el, a példa fájlokat, dokumentációt, fejlesztői könyvtárakat mind érintetlenül hagyta.

A régi CUDA-t viszont nem csomagkezelőből tettem fel, mert ott nincs ráhatásom, hogy mit telepítsen. Van egy futtatható telepítő, azt használtam. Mikor megkérdezte, tegye-e fel a GPU meghajtót, a középső ujjammal nyomtam le az N betűt.

A CentOS alapvetően tetszik. Nincs annyira ellátva csomagokkal, mint az Ubuntu. Ha valaki például egy video lejátszó programot akar, külön repot kell keresnie. De ami van, az teszi a dolgát. Fejlesztői szempontból jobb, mint az Ubuntu, ami alapértelmezetten nem tesz fel fordító programokat. Cserébe persze a multimédiás képességek jobbak.

Az alapértelmezett ablakkezelő rendszer a Gnome, amit én kedveltem annak idején, csak amikor a Slackware KDE-re váltott (az Ubuntu meg a Unityre), akkor hanyagoltam el. Most viszont a beállítások hiánya fáj. Talán ha telepíteném a ... Nem! Nem buherálunk!

Érződik, hogy a rendszer elsődleges célja, hogy dolgozzanak vele, ne játszanak. Talán ezért is támogatják szívesen a cégek, ezért van annyi szerver szolgáltatás a csomagkezelőben. Aki meg nem nőtt fel és játszani akar, Ubuntuzhat kedvére.

Pár furcsaság azért akad. Ha telefont kötök rá, csak egy fájlt tud lemásolni. Ha többet jelölök ki, akkor a libmtp kiabál. (Ebben hibás lehet a bekapcsolt USB debugg is, mert Windows alatt sem ment zökkenőmentesen a másolás.) Az SELinux szerintem túl paranoid. Úgy értem, megakadályozza például az indexképek megjelenítését. Ezzel még nem tudom, mit kezdek. Eddig nem láttam kárát, hogy hagyom működni, ahogy van.

Ez a történet alapvetően ellentmond egy korábbinak, nevezetesen a régi hardverek használhatóságának mai világunkban.

Új munkatársunk érkezett, akinek egy támogatásból új gépet is rendeltek. Bár igyekeztek számára a terepet minél hamarabb elrendezni, ahogy várható volt, mikor munkába állt, a gép éppen a következő "két hét múlva itt lesz" periódsuban volt.

Semmi baj, mentora az irodában fellelhető elavult gépekből összerakott neki egy kofigurációt. A megoldás, ahogy várható volt, félig teljesítette az elvárásokat. Megismerni a Linuxot meg lehetett alatta, távoli gépekre be lehetett jelentkezni, de a böngészőt már nyekeregve indította.

Egyik reggel arra mentem be, hogy a gép rejtélyes módon megállt. Egészen pontosan bootolás után random pillanatokban megfagyott. Rögtön elkezdtünk tanakodni, mi lehet a probléma. Én arra gondoltam, a processzor túlmelegszik. Mivel a hűtő fordulatszámával nem volt gond, elképzelhetőnek tartottam, hogy a hővezető paszta száradt be.

Rövid ideig szenvedtünk a CPU hőmérsékletének megjelenítésével, aztán úgy döntöttünk, nem éri meg vesződni vele. Rakjunk össze egy másik gépet abból a temérdek alkatrészből, ami még ott található. Korábban felhoztam a szerver teremből egy sokkal modernebb PC-t (ez már kb. 2008-ből származott). Biztonsági mentések tárolására használtuk, de miután meghibásodott a tápegység, és egy merevlemez benne, már nem tudta ellátni feladatát.

Lementem a rendszergazdákhoz, hátha tudnak adni ideiglenesen egy tápegységet. Nem tudtam, mi a pontos elnevezése, ezért olyat kértem, amin "szélesebb molex van". A rendszergazda értetlenül nézett rám, majd megkérdezte: ATX2? Azt mondtam, igen. Levett egyet a polcról, megsimogatta, de olyan gyengéden, mint apa a lányát, ha egy rockerrel engedi el randizni.

- Vigyázz rá!

Megígértem, hogy vigyázni fogok a nyomorult tápegységre, és gyorsan elfordultam, nehogy véletlenül könnyeket lássak a szemében.

Beszereltem a tápegységet. Mivel a gép azelőtt biztonsági mentéseket tárolt, volt benne hat merevlemez, de arra már nem emlékeztem, melyik romlott el, ezért lehúztam a felét az alaplapról és néztem, elindul-e. Nem indult. Megcseréltem a másik hárommal. Nem indult. Vissza az eredeti hármat, elindult. Mi a fene? Kerestem a hibás vinyót, de a gép néha elindult és panaszkodott a hibás vinyóra, néha nem indult.

Szép lassan kezdtem rájönni, hogy ennek a gépnek több baja is lehet és ebből nem lesz egyhamar használható gép.

Közben mentor munkatársam elkapott egy kollégát a folyosón, akikről tudta, hogy laptopokat vettek "nemrég". Bár kezdtem megérteni, hogy az időt másképp kell mérni. Minden esetre nekik voltak öt éves számítógépeik.

- De a vinyók nem jók benne - mesélte. A renszer vinyó tönkrement, de egy másik is volt benne, tele adatokkal. Már fél éve kérem a rendszergazdákat, hogy mentsék le nekem róla az adatokat.

Megígértük, hogy mi le tudjuk menteni, csak adja nekünk a vinyó nélküli számítógépet. Megkaptuk. Az első roncs gépből áttettük a vinyót bele és volt egy működő gép. Szerelés közben megláttam, milyen kábelt kapcsolt rá a vinyóra és megrökönyödve kérdeztem:

- Ez a gép még IDE-s?

Munkatársam nem értette, mire gondolok, mire röviden elmagyaráztam.

- Azt nem tudtam, hogyan hívják -felelte. Én csak busznak hívom.

Gondoltam elsütök egy tömegközlekedéses poént, de visszafogtam magam. Végül is miért kéne bárkinek is ósdi tehnológiákat ismernie? Az egykori szerverből ezután visszaadtam a "drágaszágot" a rendszergazdának. Közben, akitől kaptuk a gépet, visszatért, kezében egy drótkupaccal. Úgy nézett ki, mint aki slusszkulcs nélkül akar autót indítani.

- Ismét szóltam a rendszergazdáknak, hogy mentsék le az adatokat, erre ezt adták nekem - panaszolta. - Fél év könyörgés után ezt nyomták a kezembe - azzal megrázta a kábel köteget.

- Ne aggódj, működni fog - nyugtatta munkatársam. - Tudom, hogy olyan, mint egy tyúkbél, de azzal lementheted az adatokat.

Otthon elmeséltem a kalandjaimat, mire feleségem felugrott.

- Most jut eszembe, ezeket a munkahelyemen találtuk, gondoltam, te meg tudnád nézni, hogy mi van rajtuk.

Azzal a kezembe nyomott egy zacskó floppy lemezt.

Absztrakt

Vannak tudományos projektek, melyek egy idő után összeomlanak és lehetetlenné válik a további munka. Korábbi kutatások a PhD hallhatók hozzáállását tették felelőssé (Lusta, 1980), de újabb kutatások a csoport vezetőinek felelősségét is firtatják (Szapuló, 2018). Jelen publikáció célja egy olyan mérőszám bevezetése, amely segítségével bárki, aki az adott projektben részt vesz, képes legyen megbecsülni, mikor érdemes a munkából kiszállni.

Bevezetés

Régóta ismert tény, hogy a tudományos kutatások részeredményeinek keletkezése semmilyen összefüggésben sincs a ráfordított idővel. Egyes eredmények gyorsan jönnek, mások viszont kemény munka árán sem akarnak összejönni. Az is régóta ismert tény, hogy egyes projektek végül elhalnak és nem születik belőlük publikáció (Smartass, 2014).

Egy új megközelítés szerint - ami a minta azonosítók bevezetésének számával igyekszik megbecsülni, mikor válik a projekt kezelhetetlenné - lehetővé válik megjósolni, mikor kell beavatkozni, hogy munkánk ne fusson zátonyra.

Anyag és módszer

Három kutatási projekt információit összegyűjtve hoztuk létre a modellt, ahol a mintaelemszámot és a hozzájuk kapcsolódó egyedi azonosítókat gyűjtöttük össze. Minden statisztikai teszt Wilcoxon teszt volt, mert mással nem kaptunk olyan eredményt, ami a vezető kutatónak tetszett volna. Mivel nem támogatjuk a p-érték használatát, következetesen kihagytuk minden számításból. A számításokat Excel 4.0-ban végeztük, egy Windows 3.1-t futtató számítógépen, mert ez volt az egyetlen gép, amin nem futott a Bitcoin bányászó alkalmazás.

Eredmények

A projekt ellehetetlenedése összefüggést mutat a kutatók által bevezetett új azonosítók számával (R=0.98). Minél többen dolgoznak egy munkán, az egyes részfolyamatoknál gyakran ugyan annak a mintának több azonosítója is van. Vegyünk egy hipotetikus esetet, ahol 10 növényi mintából kell mutációkat meghatározni. A növényeket egy speciális üvegházban nevelik, ahol kap egy azonosítót. Ez alapján tudják az üvegház dolgozói, melyik növény hol található és melyik kutatócsoport protokollját kell alkalmazni. A kutatók saját azonosítókat használnak, amibe általában belekódolják a különböző kezeléseket is. A növényekből izolált DNS újabb azonosítót kap, mert az eppendorf csőre nem tudják kiírni azt a hosszú szöveget, amit az Excel tábla vígan kezel. Elküldik egy szekvenáló céghez, aki néha kénytelen új azonosítót rendelni mindegyik mintához, mert az operációs rendszerek legtöbbje képtelen emoji karaktereket használni fájl névként, és még a szóköz is gondot okozhat neki. A bioinformatikusok előszeretettel változtatják meg az azonosítókat, néha csak azért, mert a kutatók arra sem veszik a fáradságot, hogy alapvető információkat közöljenek a projektről. Végül a publikációban teljesen más azonosítók vannak, mert azok néznek ki jól.

Ebben az egyszerűsített példában is egy mintának hat különböző azonosítója volt. A teljes mintaszám pedig 10 volt! A példa nem tért ki olyan esetekre, amikor új kutató érkezik, több éven átívelő munkáról van szó, vagy egyszerűen elvesznek információk (mert valaki alkoholos kézzel matatott az eppendorf csövek körül). Minden egyes új azonosítóval nehezedik a kommunikáció a projekten belül, ami a mintaelem szám növekedésével tovább bonyolódik. Végül senki sem fogja tudni, miről van szó és a projekt elhal.

$I=\frac{a}{n}$

Ahol I az elbaltázósádi index, a az egyedi azonosítók száma egy mintára, n pedig a teljes mintaszám. Könnyű belátni, hogy az index torzít alacsony mintaelem számnál, bár ha csak egy mintánk van, egyetlen azonosítóval, azzal úgysem tudunk tudományos igényű eredményeket elérni.

Összegzés

Egy projekt bonyolultságát nehéz megbecsülni. Ha az összetettség elér egy kritikus értéket, minden további munka lehetetlenné válik. Ebben a cikkben a minták azonosítóinak számát vettük alapul, hogy meghatározzuk, mikor jut el a projekt a teljes káoszig. Az index használatával elkerülhető, hogy egy csomó munka a kukában végezze.