Az élet kódjai

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 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.

A kutatók is szoktak flamelni, jóllehet ők nem webes fórumok mögül puffogtatnak, hanem Nature cikkek hasábjain. Ahogy a Linux vs Windows vagy Konzol vs PC viták sem jutnak dűlőre, valószínűleg itt is sokára lesz konszenzus.

De miről is van szó? Természetesen arról, hogy mellőzzük-e a p-értéket a statisztikai eredmények közlésénél vagy ne? Mert mi a p-érték? Egy szám, semmi több. Felejtsük el a definíciót egy picit, hiszen a kutatók legtöbbje szintén elfelejti azt. Ők csak egy számot látnak belőle, amiről be kell mutatni (szándékosan nem írtam, hogy bizonyítani), hogy kisebb 0.05-nél. Ha valami miatt ez 0.0500001, akkor mindenki depressziós, de ha átcsap 0.0499999-be, akkor az Univerzum értelmet nyer. Ha pedig az egészből csak ennyit látunk, akkor ennek a számnak tényleg semmi értelme.

Például egy korábbi munkám során növényi hormonszintek és a hideg tolerancia közötti kapcsolatot kerestük. A vezető kutató a cikkekből tudta, hogy a prolinnak ebben pozitív szerepe van. A statisztikai tesztek viszont nem adták vissza ezt. A p-érték valami 0.6 volt. Volt is vita, hogy a létező asszociáció miért nem "szignifikáns". Nos, azért nem volt, mert minden hormon esetén megvolt a három ismétlés, de egy malőr miatt prolin esetén csak két ismétlés volt. Ebben az esetben a magas p-érték nem azt jelentette, hogy nincs meg a hőn áhított kapcsolat, csak azt, hogy pocsék volt a kísérleti elrendezés. A p-érték nem jós, nem "látja" az igazságot.

Vegyünk egy másik példát. Ritka betegségeket vizsgáltam és mivel kevés minta volt, nem is bajlódtam statisztikai tesztekkel. Leszűrtek a genotípusokat különböző szempontok szerint, és végül kb. 21 maradt, amiből a klinikusok megtalálták azt, amit a legvalószínűbb oknak gondoltak. Ezek után, puszta kíváncsiságból lefuttattam a plink asszociáció keresőjét. A kézi szűréssel kapott variációt nem találtam sehol, de cserébe kaptam egy nagyon szignifikáns, de teljesen más eredményt. Tüzetesen megvizsgálva kiderült, hogy az eredmény egy hülyeség. Egy olyan variációról volt szó, ami két betegben is homozigóta volt, miközben az összes többi rokonból hiányzott az allél!

Nyilván a statisztikai teszt kihozta, mert betegekben feldúsul, egészségesekből hiányzik. Csakhogy a genetika nem így működik. Arról sem szabad megfeledkezni, hogy igazából egy hibát is elkövettem: Az asszociáció teszt akkor működik, ha a minták függetlenek. Márpedig családtagok nem függetlenek. (Hacsak a postás nem csenget kétszer, de ebbe ne menjünk bele.) A p-érték nem bíró, nem dönti el, hogy volt-e értelme a tesztnek.

A harmadik esetről már írtam korábban. Ebben az esetben jók voltak az adatok, jó volt a teszt, csak nem azt mértem, amit szerettem volna. A p-érték nem gondolat olvasó.

Most joggal gondolhatja valaki, hogy a p-érték teljesen felesleges, írmagját is ki kellene gyomlálni a tudományos közéletből. Igaza van annak a rengeteg kutatónak, aki kardoskodnak ellene.

Nos, nem, és a fenti cikk sem állítja ezt.

A p-érték előnye, hogy segítségével könnyen összegezhető az eredmény. Egy szám azért mégis könnyebben értelmezhető, mint egy több dimenziós mátrix. Csak azért, mert összegzi az eredményt, nem jelenti azt, hogy helyettesíti az egész analízis áttekintését és megértését. A fenti példákban sem a p-értékkel volt a gond, hanem a kísérletekkel. Ha hülyeséget csinálunk, attól nem ment meg minket sem a Bayes-statisztika, sem a konfidencia intervallum, sem Ronald Fisher dohánytól bűzlő, megigézett szelleme.

A p-értéket szerintem úgy lehet a legjobban szemléltetni, mint a futóversenynél a célszalagot. A versenynek sem az a célja, hogy átszakítsuk a szalagot. Az a célja, hogy megtegyük a távolságot, megelőzzünk mindenkit és átszakítsuk a szalagot.

Idén sem unatkozott, aki ellátogatott Németországba és a nyuszi helyett a demókat választotta.

Tracked music

Annak ellenére, hogy nem vagyok egy tracker függő, szívesen hallgattam az indulókat. Ritmusos és energikus volt a legtöbb. Legjobban a vadnyugati stílusú Due Diligence tetszett.

Fast music

Ettől telítődtem. Az újra és újra felhangzó ritmus, amit az indulók igyekeztek átalakítani a végére annyira idegesítő lett, hogy nem bírtam figyelni magukra az alkotásokra.

Fast/modern/oldschool graphics

Bizonyára bennem volt a hiba, de nem ragadott magával egyik compó sem. Voltak jobb alkotások, de nem éreztem a döbbenetet.

Animáció

Ez az a kategória, aminél a legkevésbé kell aggódni a számítógép teljesítménye miatt. Letöltöd, lejátszod. Most mintha a készítők sem erőltették volna meg magukat. Kicsit furcsa, hogy annyi eszköz áll rendelkezésére az embereknek - gondolok itt a különböző gimballokra, 360 fokos kamerákra, drónokra, szerkesztő programokra - mégis a fürdőkádban lefolyó színes habról készítettek filmet. A győztes egy jó minőségű animáció volt, szerintem egy moddolt játék lehetett. Volt még egy film, ami erősen emlékeztetett az Inferno című könyv egyik jelenetére, ahol a gonosz kutató előadja ördögi tervét egy pestis álarcban. A mozi filmes implementáció finoman szólva nevetséges volt, de ebben a releaseben sokkal autentikusabban oldották meg. Mondanom sem kell, hogy minimális pénzösszegből.

Oldschool music

"Nyugodtan átnevezhették volna Commodore music compónak is, mert csak Amiga és C64 zenék voltak. Ez persze nem hátrány, csak olyan egysíkú volt minden." Ezt írtam volna, ha nincs a hard(re)start. Ez a zene ugyanis sztereó C64-re készült és nagyon jól szólt. Igazi kuriózum.

8K intró

Sokáig nem tudtam, hova tegyem a 8K intrókat, de úgy tűnt a készítők sem tudták, mit kezdjenek a plusz hellyel, amit még kóddal tölthetnek meg? Idén úgy tűnik, megtalálták a helyüket. Legalábbis az első négy helyezett valami történetet igyekezett elmondani, ami 4K-ban nehézkesebb lenne. Nekem még az Extralife is tetszett a maga egyszerű módján, de a Haunted tökéletesen kihasználta a kategória kereteit.

64k intro

Ha egy szóval kellene jellemeznem, mit láttam, akkor a vegetáció lenne az. Az idei intrók nem a történet meséléssel hódítottak, hanem a környezet részletes bemutatásával. És micsoda környezetek voltak! A The Jaderoom részecske gyorsítója, a Secret Service Agency erdeje (bár ez utóbbi nem a fotorealisztikus mivolta miatt), mind nagyon szépek voltak. Számomra még az Aten Hotep piramisai is jól néztek ki. Akit viszont a design demók fognak meg, a Brainworm kockáiban gyönyörködhettek.

Oldschool demo

A kompó majdnem átment remix versenybe, ugyanis két csapat is megpróbálta az STNICCC2000 demót más platformokra átültetni. Érdekes módon a Nintendo port, bár Super FX chipet is használt, kevésbé volt gyors, mint a Sega Megadrive verzió. A veterán C64 programozók összefogtak és csináltak egy közös produkciót. Nagyon dinamikus és könnyed volt. Hiába, ennyi profi egy csapatban nem tud hibázni.

PC demó

Kevin visszatért és eltérítette a compót. Nem tudom, ezt a mérhetetlen mennyiségű hülyeséget honnan szedik a készítők, de nagyon jót lehet nevetni rajta. Ja, meg volt egy Notch-al készült Cocoon demó, akit az érdekel, hogy mennyit bír a grafikus kártyája. (És láttunk a jó öreg magyar scenerektől egy jó öreg demót, amiben meghívtak egy jó öreg partira.)

Wild

Ez a kategória lassan átalakul LED compóvá. Meg PICO-8 compóvá. Szerencsére a Transidio szakít ezzel a hagyománnyal. Ők valami elektroncsöves szörnyeteget csináltak és még zenét is játszottak rajta.

Amiga demó

Revision Amigás demókra eddig sem volt panasz, de amit idén láttunk, az egyszerűen döbbenet volt. A compó felét kiváló demók adták, abból a hatból bármelyik megérdemelte volna a dobogót. A De Profundis-al volt csak egy kis bajom, mert magát sztori demónak akarta eladni (amit én nagyon szeretek), csak épp a sztori veszett el. Kiírták, hogy "original story by", de az eltűnt gyerekek és az elátkozott ház, mint eredeti történet... Aztán előkerül valami fickó és bemegy - gondolom a házba, bár ez nem derül ki - és valami időtlen helyre kerül. Tehát a gyerekek egy olyan helyre kerülnek, mint Sohaország? De a grafikák szépek, a demó kiváló.

Mert lehet jó történetet mesélni Amigával. Az első helyezett The Black Lotus meg is mutatta. Minden részlet tökéletes volt, de nekem az tetszett a legjobban, hogy az egészet olyan könnyedén adták elő, mintha egy Amiga 500-asnak ez lenne a természetes élettere. Hogy jobban meg lehessen ezt érteni, csak meg kell nézni egy Elude demót. Szép, jó, de szinte a képernyőn keresztül is érezni lehet az olvadó műanyag szagát, ahogy a bővítőkártyával megrakott 1200-es burkolata megadja magát a processzor hőjének. Charlie egyszer mesélte is, hogy nem minden bővítő kártya tud 66MHz-en ketyegni, és Kiero mennyire boldog volt, hogy a demót pár MHz-el gyorsabb gépen tudták lejátszani. A TBL is biztos szénné optimalizált, de ezt nézőként mégsem érezzük:

Elég sok régi számítógép alkatrész hever szerte-szét nálam. Érdekes módon, a legtöbbet valamilyen technológia váltás idején szereztem, ezért mai szemmel furcsa hibrid megoldások. Például a mostani történet főhőse, egy Mercury alaplap, amin PCI és ISA aljzat is van. Mikor a birtokomba került egy Gravis Ultrasounds hangkártya, elhatároztam, hogy beüzemelem.

Mivel ez a hangkártya elsősorban a demoscene hőskorában volt divatos, nem volt kérdés számomra, hogy régi DOS demókat akarok nézni. De ugyanakkor az is motoszkált a fejemben, vajon a mai világban mire használhatunk egy ilyen gépet?

Először egy FreeDOS-t kellett telepíteni. Elsőre nem jártam sikerrel, mert a vinyó, amire telepíteni akartam, nem akarta, hogy leformázzam. Még nem tudom, hogy mágnes donor lesz-e belőle (a használhatatlan vinyókból ki szoktam szedni a mágnest, hátha jó lesz még valamire), de az biztos, hogy nem tudtam telepíteni rá semmit.

A második vinyóra zokszó nélkül felment a FreeDOS. Telepítés során a "Full" opciót választottam, mégsem mentek fel a fejlesztői eszközök, amire pedig egy magam fajta buherátornak feltétlenül szüksége van. Mint kiderült, telepítés után az FDIMPLES paranccsal lehet további programokat felpakolni. Ekkor a CD-ről telepíthető minden.

Meglepő módon a rendszer nem tűnt nagyon stabilnak. A SUDOKU86 program rövid időn belül fagyasztotta a gépet, de rejtélyes módon néha újra indul a gép. Tápegység problémára nem gyanakodtam, mert az elég jó minőségű és egy jóval erősebb gépet hajtott meg minden gond nélkül. A memóriákban viszont nem voltam ilyen biztos. A régi, kiírt Linux CD-k között böngészve (elképesztő, ebből is mennyi van a birtokomban. Még néhány 6 CD-s Red Hat is előkerült) kerestem valamit, amin van egy memtest, de egyet sem találtam. Sajna Ubuntuból csak 64 biteseim vannak.

Végül egy Knoppixot próbáltam ki. A jelenség ismétlődött, a rendszert nem tudtam teljesen elindítani, valamelyik állapotban mindig újraindult. Kiszedtem az összes perifériát, másik tápot is kipróbáltam, a rendszer vinyó és az alaplap kivételével mindent kicseréltem tartalék alkatrészre, de nem jártam sikerrel. Még a kábeleket is átnéztem. Az összes fellelhető SD memóriamodulomat kipróbáltam, és a gép mégis újraindult. Úgy látszik, kénytelen vagyok ezzel együtt élni.

Visszatértem a FreeDOS-ba. Egy nosztalgia CD-ről (akkor készült, mikor még a CD írók egy gép árával vetekedtek és cégeknek ebből volt extra bevétele. Egy CD annak idején számomra hatalmas tárhelyet jelentett, mert alig bírtam összekaparni 650 MB-ot, hogy megtöltsem) felmásoltam a Doom2-t is, ami viszont gond nélkül futott.

A kislányom csak "vicces robotnak" hívta, mert a pisztolyra azt hiszi, hogy egy robot feje, a torkolattűz pedig a haja. Azért vicces, mert a robot haja hol eltűnik, hol megjelenik. Én pedig mély hallgatásba burkolóztam a játék valódi természetével kapcsolatban.

De a GUS-t még mindig nem próbáltam ki. Egy CD-re kiírtam pár demót, amelyeket a Pouet szerint érdemes megnézni. Írtam még ki néhány C64 képfájlt, egy Star Commandert (erről még lesz szó) és egy GUS telepítő készletet. Elolvastam a tudnivalókat, és reménykedtem, hogy nem a telepítés közben fog újraindulni a gép.

A telepítő feltett egy csomó kérdést, amire nem tudtam válaszolni. Például fogalmam sem volt róla, hogy a DVD olvasó melyik címet használja, milyen megszakításra helyezhetem a hangkártyát, ezért megbíztam a telepítő előre látásában, és minden esetben ráklikkeltem a "Test" gombra, amivel ellenőrizni lehetett, hogy az adott cím szabad-e.

A telepítés végeztével újraindítottam a rendszert és mély lélegzetet véve kiválasztottam a Dope-t. És elindítottam. És futott! És nem fagyott! És fogalmam sem volt, hol kell hangerőt beállítani. És majd kiszakadt a dobhártyám. És nem érdekelt (mármint a dobhártyám, a demóvan nem volt gondom).

A 303 is ment, de csak ha EMM opcióval indítottam a rendszert. Kellett neki a DOS4GW is, amit első körben nem tudtam, honnan szerezzek be. Végül eszembe jutott, hogy a Watcom C++ mintha használta volna. A FreeDOS része az OpenWatcom és szerencsémre volt hozzá ez a vacak. A demó mellé pakoltam és már élvezhettem is. Bár a recsegő effektek nem szóltak olyan szépen, mint a MindCandy verzió. De hát ez a valódi vas varázsa. Akár csak egy étteremben. Valami mindig más, mint egy szakácskönyvben. (A YouTube meg a McDonalds, mindenhol ugyan azt kapod.) Kipróbáltam pár 256byte intrót is, azokkal sem volt gond. A Ninja2 is futott szépen.

Tehát a GUS telepítés sikerült. Egyetlen gond az volt, hogy ha ment a hangkártya, akkor nem működött a DVD meghajtó. Valami ostoba IRQ ütközés lesz, de a cikk írásának pillanatában még nem volt rá megoldásom.

Következett a Star Commander. Annak idején Grass segítségével szereztem egy XM1541 kábelt, amivel az volt a tervem, hogy C64 képfájlokat másolok 5 1/4-es floppyra. Grass akkor adott egy X1541-t is, és én nem emlékeztem rá, melyik melyik. Szerencsére volt egy teszt program, ami képes volt ezt megállapítani.

Összekötöttem a C64 floppy meghajtót a PC-vel, bekapcsoltam őket és kezdődött a kísérletezés. A Star Commandernek először be kellett állítani, hogy milyen kábelem van, melyik párhuzamos portot akarom használni, és még egy csomó paramétert, amit inkább alapértelmezetten hagytam, mert nem tudtam, mit jelentenek. Mindjárt adott is egy hibaüzenetet, hogy az X1541 nem megy SPP módban. Akkor ne menjen, de hol lehet ezt kikapcsolni? Mint kiderült, a BIOS-ban. Ismét tanultam valamit.

Kibontottam egy original floppy csomagot, amit szintén Grass adott, és évekig porosodott a fiókban, majd megpróbáltam az Edge of Disgrace-t kiírni. Nem ment, megszámlálhatatlan paramétert állítottam át, kábeleket cseréltem, de folyton a rejtélyes 21, Read Error, 18, 00 hibaüzenetet kaptam.

A Star Commander dokumentációja semmi használhatót nem mondott. Feladtam. Pár nap múlva megnéztem a Guglit, hátha ad valami értelmes eredményt, mire azt dobta fel, hogy formázni kéne a lemezeket.

Egyik hétvégén kipakoltam a C64-t is a szekrényből. Bekapcsoltam és végignéztem néhány régi játékot. Elővettem a formázatlan lemezeket is, egy ollóval a második oldalukat is aktiváltam és leformáztam őket. De sokáig tartott. Már el is felejtettem, hogy a hajlékony lemez nem türelmetlen embereknek való.

Az 1541 meghajtót azután a PC-re kötöttem és indult újra a móka. Most szépen másolt, de egyes esetekben bizonyos szektorokat nem tudott írni. Már nagyon látni akartam pár C64 demót, ezért kihagytam őket, talán nem fagynak a demók teljesen szét.

Elsőnek az Edge of Disgrace volt terítéken, mert ez a demó igazi mérföldkő a C64 demók történetében. Ment is simán, csak ez a rész nézett ki furcsán. Valahogy szétesett a grafika. A Natural Wonders 2 simán ment, a Wonderland XII első lemeze viszont nem. Érdekes módon a második és harmadik lemezt külön is be tudtam tölteni.

Tehát a régi időket fel lehet eleveníteni. Még retro ökoszisztémát is létrehozhatunk, ahol a gépek fordított időrendbe történő alkalmazásával adatokat tudunk továbbítani az öregebb masinák felé. Az aktuális gépem letölti a demókat, mert hozzáfér az internethez. Onnan át lehet vinni a fájlokat egy FreeDOS-os gépre, amiben nincs hálókártya, de van egy párhuzamos port. A portot használva pedig a C64 megkapja a demót. Még leírni is szörnyű! Persze egy kis extra pénzért lehet mindenféle ketyerét beszerezni, de a kábel csak 1500 Ft volt, az ósdi gépet pedig szinte ingyen lehet szerezni. (Egyet a kuka mellől szereztem, majd talán arról is írok)

Rendben, de valami értelmes munkára használható-e? Igazából semmi olyat nem tud, amit egy mai PC-n ne tudnánk végrehajtani. Hozzáteszem jóval kényelmesebb módon. Ha sikerülne a hálózatot beüzemelni rajta, elméletileg SSH kliens lehetne. Talán még a demókat is letölthetném vele, hogy az adat áramlást felgyorsítsam.

Egy minimális, konzolos Linux-al LaTeX dokumentumokat lehetne csinálni rajta, amivel akár a Word-öt is ki lehetne váltani. Lehet programozni. Az oprendszer hardver közeli, jobban meg lehet érteni a gépek működését, nincs túlkomplikált IDE, de cserébe autocomplite sem. Kénytelenek vagyunk mindent begépelni. Ha pedig lefagy, akkor az egész rendszer lefagy, nem csak az alkalmazás.

Mint mondottam, mindezt egy modern PC-n is megtehetjük egy virtuális gépen, miközben a YouTube-ról sem kell lemondani. Mi értelme ennyi időt rászánni egy ósdi gépre? Különösen, hogy én soha nem rajongtam a DOS-os PC-ért. A C64-t szerettem, mert színes volt, szépen zenélt, amint bekapcsoltam, azonnal lehetett programozni. A PC-t visszalépésként éltem meg. Utáltam az expanded memóriát, a 640K-s korlátot. A PC-t akkor kezdtem megkedvelni, amikor telepítettem egy Minixet és láttam, hogy máshogy is lehet használni a gépeket.

A kérdés inkább nem is az, hogy használjunk-e régi gépet vagy ne, hanem konformisták legyünk-e. Erre pedig határozottan az a válaszom, hogy ne. Nem kell mindig a kitaposott ösvényen menni, mert a dolgokat úgy fogjuk látni, ahogy a többiek. Ha egy problémát nem szokványos eszközökkel oldunk meg, akkor végig kell gondolnunk, a probléma hátterét, jobban megértjük az összefüggéseit. Alternatív megoldásokat találhatunk, kiterjeszthetjük kreatív potenciálunkat. Ez az, amiben igazán segíthet egy régi hardver.

A második Carpentries-t a Semmelweis Egyetemen szerveztük. Felszínesen én is résztvettem a szervezésben, de csak a weboldalt birizgáltam még a kezdetekben, és segítőként voltam jelen. Mivel az egyetem nem adott elég pénzt, kénytelenek voltunk egy szponzort is bevonni, ami az egyik régi melóhelyem volt. (Most, hogy nem ott dolgozom, már ennyire jól megy nekik.)

A kurzus célja az volt, hogy a hallgatók megismerkedjenek az adatok hatékony táblázatba rendezésével és azok feldolgozásával. A téma fontosságát a résztvevők is érezték, mert a regisztráció megnyitása után, mikor még nem is kezdtük hirdetni az eseményt, négyen regisztráltak. Egy hét alatt elfogyott az összes szabad hely. Először csak négy várólistát állítottunk be, de még azért is harcoltak emberek, hogy felkerüljenek. Végül 19-en oda is felvetették magukat.

Ennek ellenére voltak, akik bármiféle visszajelzés nélkül nem jöttek el. Ezutón szeretném üzenni nekik, hogy ha van egy ingyenes rendezvény, amit oktatók ingyen tartanak. A szervezők fizetés nélkül, az adminisztrációval és egyéb bürokratákkal harcolva lehetővé teszik a létrejöttét, akkor legalább annyit tegyetek meg, hogy jelzitek, ha a kisujjatokon kibújó pörsenés miatt nincs kedvetek eljönni. Csak azért, mert mások szívesen elfoglalnák a helyeteket.

Vicces módon 2005-től valamennyi munkahelyemről voltak ismerőseim a kurzuson, ha programozós és Sangeres időket nem számítjuk. Azért ilyenkor látszik, milyen öreg is vagyok.

Akik mégis eljöttek, először egy táblázat kezelő segítségével megtanulták az adat rendezés alapjait. Mivel mindenki a saját gépét hozta, segítőként meggyűlt a bajunk ezzel. Valahol Excel volt, de máshol LibreOffice, egyik gépen magyarul, másikon angolul. Valamint ezek kombinációi. De persze a legnagyobb baj az volt, hogy senki nem értett az Excelhez. Ha nem jelent meg valami, csak vakartuk a fejünket, hogy miként lehet elővarázsolni azt a menükből.

Sajnos nem én voltam, aki a legkevésbé értett az Excelhez, amitől az a kényelmetlen érzésem támadt, hogy álszent vagyok. (Vagy csak túlságosan jól ismerem az ellenséget.)

Bitmumus is tiszteletét tette. Az egyik esetben egy szóköz volt a könyvtár név végén, ami láthatatlanul megült és megakadályozott minden olvasási műveletet, egy másik esetben pedig a Windows döntött úgy, hogy megvonja a jogosultágokat az R Studiótól, amitől nem lehetett írni a felhasználó egyetlen könyvtárába sem, még akkor sem, ha rendszergazdai módban indítottuk el!

Az első nap egyébként az oktató ügyesen bevonta a hallgatókat, amiben nem kis szerepe volt az édességnek, amit az emberek közé dobált, ha valami okosat mondtak.

Utána volt egy kis OpenRefine, aminek csak annyi szerepe volt, mint a bennfoglalásnak az általános iskolában. Segített, hogy a következő lépcsőfokra, az R-re érjünk. Ez már sétagalopp volt a segítőknek, de a hallgatóknak itt kezdődött az igazi gyötrelem.

A data frame megértése például nagyon sokáig tartott. Szerintem az volt a probléma, hogy mindjárt az elején nem tisztázták, hogy ez egy táblázat, ezért a hallgatók nem értették, hogyan épül fel, miért kell azonos hosszúságú vektorokat egy adatstruktúrába pakolni. A kavart csak tovább növelte, hogy az oszlopneveket a, b, c betűkkel jelölték, de az egyik oszlopban is voltak a, b, c karakterek.

Mindkét nap végére alaposan lefáradt az egész társaság. Remélem mindenki tanult valami hasznosat, amit alkalmazni fog a következő projektje során.

Fehér ember azt hiszi mindent tud adatelemzésről. Fehér ember téved. Sápadtarcú még mindig használ Excel. Először hoz villámló bot, aztán tüzes víz, és most Excel. Még a Nagy Manitu is kevés, hogy eltűntesse Excelt.

Ülő Bika nem érti, fehér ember miért használ Excel. Ezért Ülő Bika azt mondja, olvass cikket. Olvass cikket, hogyan használd jól Excel. Cikk írja igazság.

Ülő Bika arra kéri többi törzsfőnököt, hogy terjesszék cikket. Sok sápadtarcú tanuljon. Tanuljon és használja Excel jól. Ha lesz sok jó Excel, talán elszívhatjuk békepipát.

Uff, én beszéltem.

Egyre többet gondolkodom azon, hogy a jelenlegi felállásban (értsd: egyedül) miként tudnék alkotásokat készíteni. Ebben a részben a zene problémájával foglalkozom. Azt gondolom, mások is küszködnek hasonló problémával, ezért talán nekik is érdekes lesz, mire jutottam, illetve milyen lehetséges utak vannak.

Keresni kell egy zenészt

Ez igazából a legkézenfekvőbb megoldás. Akár a scene.hu-t, akár a Demoscene's most wanted oldalt nézzük, kereshetünk új tagokat. Ha pedig Slyspy, Teo vagy Vincenzo ráér, akkor lesz zenénk :-) Én most nem akarok új tagokat felvenni, mert még nem látom, hogy jómagam bele tudok-e annyi energiát tenni, hogy abból rendes produkció legyen. Előny, hogy a zene saját lesz, maximálisan illeszkedve a demó hangulatához.

Szerezni kell egy zenét

Igazából ez is járható út. Az OpenGameArt-on vannak zenék. A SoundCloud tele van jobbnál-jobb zenékkel, különböző liszenszelési lehetőségekkel. De indie zenészeket is meg lehet keresni és megkérdezni tőlük, hogy használhatjuk-e a zenéjüket. Ezt már mások is csinálták, például a Ceasefire-nál, ahol a Hunz együttes egyik számát használták fel.

De említhetném - ugyan csak a Fairlight részecske érájából - az Agenda Circling Forth-ot is, akik egy Socrates számot dolgoztak fel (illetve a DJ, akinek a zenéjét felhasználták, egy Socrates számot használt fel).

Ez persze nem szokott tetszeni mindenkinek (főleg a régi vágású scenereknek) és a jogok biztos sok utánajárást igényelnek. De akár a party szervezői is megtagadhatják a demó lejátszását, ha valami - általunk nem ismert - törvénybe ütközünk. Például a Revision-ön nagyon ugranak, ha a jogok nincsenek rendesen letisztázva. Előny viszont, hogy a zene minősége jobb lesz, mint a legtöbb scener produkció. Vérfrissítésnek sem utolsó, mert nem kell az X+1. dubstepet végighallgatnia a közönségnek. Ezzel együtt kevesebb ráhatásunk van a zenére. Vangelis biztos nem készít "kicsit ütősebb" verziót még a mi kedvünkért sem.

Zene nélkül is megy

A demók része a zene. De igazából nem kötelező része. Készíthetünk zene nélkül is demókat. Például, ahogy a Dead Roman is csinálta a Spheres on plane című alkotásukkal. Csupán hangeffektek vannak.

De még 4K intróban is lehet élni a lehetőséggel, ahogy az Oscar's chair-ben is láttuk:

Ez persze nagyobb koncentrációt igényel a rendezés terén, mert a nézők a látványra fognak koncentrálni. Nem lehet a figyelmüket elaltatni egy jó zenével.

Rendhagyó módon, április elseje alkalmából nem egy álhírt készítek, hanem valódi hülyeségeket mutatok be a bioinformatika világából. Nevezetesen a hülye programokat. Mitől lesz egy program hülye? Három okból is:

Az első ok, hogy használhatatlan az adott feladatra, amire megalkották. Nem azért, mert hibás az implementáció, hanem azért mert hibásan tervezték meg. A másik ok, hogy értelmetlen feladatot hajt végre, amire senkinek semmi szüksége. Végezetük olyan programot készítettek, ami ugyan azt tudja, mint egy másik (esetleg híres) program, csak rosszabbul.

Erről a programról már írtam. Visual Basic program, ami a feladat befejezését egy csipogással jelzi, eredményét a vágólapra másolja. Ha lemaradunk a hangjelzésről? Akkor törhetjük a fejünket, hogy a vágólap tartalma az aktuális vagy előző futtatás eredménye (áramszünetről nem is szólva).

A következő programnak a fejlesztőjét ismerem. Remek fickó, tényleg, de ez a programja totál felesleges. Nem is tudták leközölni. Bár a dokumentációból nem derül ki, a célja, hogy az illesztőprogram által eldobált readeket visszaerőltesse a genomra, "megmentse" azokat. A program azért felesleges, mert az illesztőprogram paraméterezésével elkerülhetjük a használatát. Tudom, hogy sokan csak az alapértelmezett beállításokkal futtatnak mindent, de két programot futtatni alapértelmezetten, mert lusták vagyunk?

Ha egy hülye programot webre pakolunk, attól az még hülye program marad, csak mindenki látni fogja. Például lássuk ezt a nagyszerű heatmap rajzoló programot, ami hatalmas adatokat képes megjeleníteni. Ha bátrak vagyunk, még le is tölthetünk egy ilyen hatalmas táblázatot. Igaz, hogy csak 473kb, de akkor is hatalmasnak kell lennie, hiszen a weboldal ezt állítja! Minden esetre R-el gond nélkül el tudtam készíteni a heatmappet. Még egy 2012-es laptopon is. Innentől nem tudom, kinek lenne erre szüksége?

Megnéztem, hogy egy régen látott hülye program, az EuGene mennyit okosodott. Jelentem, az annotáló program, ami még egy E. coli genomot sem képes kezelni, továbbra is létezik, csak a dokumentációja veszett el a webes rengetegben. Annak idején még dokumentációval is egy kínszenvedés volt használni.

Végezetül nézzük a legértelmetlenebb feladatot: A fastq minőségi mutatókat emoji alkaban. Biztos bennem van a hiba, de nem értem, mi ez a felhajtás az emojik körül. Filmet kapnak, YouTube posztok szólnak róla. Én még emlékszem az ugyancsak felesleges WingDings betűtípusra, ez nem más, mint annak a platform független változata.

A kommentekben várom, milyen más hülye bioinformatikai programok léteznek.

Terveztem egy MariaDB adatbázist, aminél megpróbáltam ügyelni, hogy a táblák minél konzisztensebbek legyenek. Szerencsére az Oracle adatbázis modellezője jó társam volt ebben. Magas szinten lehet vele tervezni, de megengedi, hogy a fizikai táblák generálása után is módosítsuk az eredményt.

Elkészítettem a terveket, beimportáltam a nagy halom szöveges állományt, még dokumentációt is írtam. Tényleg mindent úgy csináltam, ahogy ebben a könyvben írták.

Azután magára hagytam...

Kicsivel több, mint egy év után az adatbázist frissíteni kellett, és ennek kapcsán újból felvettem a fonalat. Először is érdekes táblák jelentek meg, "new" prefixszel. Semmivel nem tudtak többet, mint a régiek, csak egy új oszlop volt bennük. De a legtöbb fejtörést egy kriptikus tábla okozta. A szerepe az volt, hogy gyorsítson egy lekérdezést, ami a sok tábla join miatt lassú volt. Volt benne egy azonosító mező, de az nem derült ki, hogy mit azonosít. Legalábbis egyetlen másik táblának az azonosítójának sem lehetett megfeleltetni. Volt még egy furcsa összeg is benne, ami viszont különbözött a "lassú" lekérdezésből származó összegtől, jóllehet igen erős korrelációt mutatott azzal. Természetesen ez sehol nem volt leírva és senki nem emlékezett, hogyan is készült.

Az adatbázishoz tartozó weboldal kódjából jöttem rá, hogy egyáltalán mit tartalmaz. Az azonosító két másik tábla elsődleges kulcsának a konkatenálása volt. A kódból viszont egy további furcsaság is kiderült. Nem értettem, miért kellett a konkatenálás előtt az egyik azonosítóhoz 100-t adni. Aztán rájöttem. Mivel az azonosító egytől 270-ig ment, azzal, hogy 100-t adtak hozzá, biztosították, hogy az első három szám minden esetben az első tábla azonosítója legyen.

Okos ötlet, de teljesen felesleges. Megkérdeztem miért volt erre szükség és a válasz az volt, hogy azt olvasták, "egyben kell indexelni, mert az gyorsabb". Ez bizonyos esetekben igaz, de az adatbázis kezelő ezt megcsinálja nekünk, nem kell okosabbnak lennünk:

CREATE INDEX index_name ON table_name (field1, field2)

Ez az "egyben indexelés".

Ugyan így, ha új mezőre van szükségünk, nem kell új táblát készíteni. De ha mégis új táblát készítünk, akkor a régire nincs szükség. Le lehet törölni. De akadtak döglött táblák is, amelyeket egyetlen lekérdezés sem használt.

Összeszedtem az összes adatbázis anekdotát - mert természetesen rendes dokumentáció sem volt - és leírtam. Átterveztem pár táblát, hogy ne legyen szükség a "new" kötőszóra, és ismét beimportáltam mindent. Illetve egy kicsit importáltam, egy kicsit kurkásztam a hibaüzeneteket, mert bár az importálandó adatok formátuma nem változott (legalábbis ezt állították), a gyakorlatban minden második fájl egy kicsit másmilyen volt.

Természetesen sok olyan hibát is észrevettem ami már a korábbi fájlokban is megvolt, nekem akkor mégsem tűntek fel. Ekkor ismét vissza kellett menni a modellező programba és módosítani a mezők típusát.

Végül az adatok viszonylag gyorsan be is jutottak az adatbázisba. Elkezdtem készíteni az indexeket. Az egyik nagyon lassan készült. Másnap már gyanús volt, hogy még nincs kész. A furcsaságok sorát tovább növelte, hogy az adatbázis szerver szinte nem is használt processzor időt.

Szerencsére a futó lekérdezéseket meg lehet nézni:

show full processlist;

A MariaDB sajátsága, hogy a process oszlopban mutatja, hány százaléknál tart a folyamat. Rendkívül hasznos dolog. Kiderült, hogy ez bizony állt! El nem bírtam képzelni, mi lehet a baj. Olyan volt, mint amikor egy konzolos program bemenetre vár. Ebből a megfontolásból megkerestem, hol tárolja az adatbázis a fájlokat. Mint kiderült, egy külön partíción voltak, amin nem volt szabad hely.

Megszámlálhatatlan mysql-bin.xxx fájl volt benne. Mint megtudtam, ezek bináris naplófájlok, jó része tavaly januári volt. Úgy döntöttem, nincs rájuk szükség. Rövid keresgélés után kiderült, hogy ezeket könnyen el lehet távolítani:

PURGE BINARY LOGS BEFORE DATE(NOW());

Amint felszabadult a hely, az index készítés azonnal beindult. Érdekes, nem volt semmi hibaüzenet, a rendszer türelmesen várta, hogy a probléma megoldódjon.

A plink az a fajta program, ahol a dokumentáció elméletileg mindent tartalmaz, a gyakorlatban mégis szinte használhatatlan. Mégpedig azért, mert hiányzik az információ, hogy milyen kombinációban használjuk azokat. A dolgot tovább bonyolítja, hogy a program két verzióban létezik. Egy 1.9 jelzésű bétában és egy 2.0 alfában, amit felváltva kell használni, mert még nem jutottak el oda, hogy minden funkció mindkét helyen meglegyen. (Természetesen ott van az eredeti program is, csakhogy az még nem képes közönséges VCF fájlt beolvasni.)

Ráadásul egyes funkciókat eltávolítottak a stabil verzióhoz képest, mert úgy találták, hogy más programok sikeresebben valósítják meg azt. Ilyen például a haplotípus azonosítás.

Ami viszont megmaradt, hogy a plink mindegyik elemzése saját külön eredményfájlt készít, egyedi kiterjesztéssel. Így biztosak lehetünk benne, hogy nem írjuk fellül eredményeinket. A kimenet kevés kivételtől eltekintve szóközzel elválasztott szöveges fájl, de hogy ne legyen egyszerű az életünk, változó hosszúságú szóköz van mindenhol, hogy nézegetve szép, rendezett külsőt mutasson. Ha R-be akarjuk betölteni, én a következő módszert használtam:

data <- read.table("plink.mendel", skip = 1)

Alapértelmezett módon az R szépen be tudja olvasni a fájlt, de a fejléccel gondjai lesznek, mert az oszlopnevek is tartalmazhatnak szóközt. Ha nem olvassuk be, és utólag készítjük el, az sokkal eredményesebb.

Megpróbálok összeszedni itt egy korántsem teljes leírást, hogyan juthatunk el egy közönséges VCF fájlból valami elemzés felé.

plink2 --vcf input.vcf --fam work.fam --out work
plink --vcf input.vcf --out work

Honnan jön a work.fam fájlunk? Nekünk kell elkészíteni. A felépítése itt található. Ügyeljünk rá, hogy a minták sorrendje ugyan az legyen, mint a VCF-ben, mert különben nem fog működni, és azt a hibaüzenetet adja, hogy "Error: Mismatched IDs between --vcf file and work.fam." A vicces az, hogy fam fájl nélkül is működik, akkor készít egy psam fájlt. Ez egy kezdetleges fam fájlnak tűnik, amit kézzel szerkeszthetünk, bővíthetünk.

A másik fontos dolog, hogy ha vissza akarjuk keresni, hogy VCF-ünk melyik rekordja szerepel a plink fájlokban, akkor célszerű az ID mezőt kitölteni. Különben csak pontokat fogunk látni.

plink --bfile work --freq --out freq

Ekkor a minior allélok frekcenciáit írhatjuk ki pozíciónkként.

plink --bfile work --mendel --out problem

A paranccsal azokat az eseteket listázhatjuk ki, ami ellentmond a mendeli öröklésnek. Önmagában nem sok segítség, de ha észben tartjuk, hogy a de-novo mutációk aránya a szakirodalom szerint 10e-8 nukleotidonként, akkor ellenőrizhetjük, mennyire jó a variant call (vagy a szülők tényleg szülők-e).

plink --bfile work --check-sex

A fenti paranccsal ellenőrizhetjük, hogy a fam fájlban a mintáknak beállított nem megfelel-e a valóságnak. Akár elírás, akár minta csere történt, érdemes ellenőrizni.

Adataink ellenőrzése után jöhet a tényleges elemzés. Például asszociáció keresés betegség és genetikai variáció között:

plink --bfile work --tdt

Ekkor a családfát is figyelembe veszi a program. Ha ezt nem kívánjuk használni, akkor a

plink --bfile work --assoc

parancsot is használhatjuk. Mindkét esetben további módosítókat használhatunk a parancssorban.

Természetesen további lehetőségek is vannak, de ha idáig eljutottunk, akkor már képesek vagyunk megérteni a dokumentáció felépítését és nagyobb eséllyel találjuk meg azt, amire szükségünk van.

Korábban azt írtam, hogy a döntési fák nem stabilak és az adat kismértékű változására is gyökeresen más megoldást adhatnak. Ez nem jó hír, de szerencsére van rá megoldás. A megoldás pedig - mint annyi más esetben - a véletlen perturbáció használata nagyon sokszor, végül vesszük az eredmények eredőjét. Ezt hívjuk véletlen erdőnek (random forest).

Tehát generálunk nagyon sok döntési fát, mindegyiket egy kicsit másképp és reménykedünk benne, hogy a sok próbálkozás összegzése egy stabil eredmény. Attól függően, hogy mit változtatunk a fák között, különböző típusú véletlen erdők vannak. Abban is lehet eltérés, miként összesítjük a sok eredményt.

De nézzük meg, hogy történik mindez a gyakorlatban. Mivel a véletlen erdő igen népszerű klasszifikáló eljárás, megpróbálok több implementációt is bemutatni.

Python

Ha a scikit-learn csomagot használjuk, a kód rendkívül hasonló lesz a döntési fánál bemutatott kódhoz. Ez az API tervezési sajátságából is adódik. A különböző tanuló algoritmusok egységes felülettel rendelkeznek, hogy könnyebb legyen elsajátítani azokat.

from sklearn.ensemble import RandomForestClassifier
rf = RandomForestClassifier(n_estimators = 100)
rf = rf.fit(data, category)

Az n_estimators paraméterrel a döntési fák számát adhatjuk meg. Az algoritmus ezek eredményeit fogja összevonni. A data és category változók megegyeznek a döntési fánál leírt változókkal, ugyan úgy két tüdőrák típus expressziós adatait tartalmazzák. Az eredő fát viszont nem tudjuk kirajzolni a korábban bemutatott módon. Ha megpróbáljuk, hibaüzenetet kapunk.

R

A legelterjedtebb véletlen fa csomag R-ben - nem meglepő módon - a randomForest nevet viseli. A használata sem bonyolultabb egy hipotézis tesztnél.

rf <- randomForest(outcome ~ ., data = input, ntree = 500)

A bemenet egy data.frame vagy mátrix, ahol egy oszlop a kimeneti változót jelenti, a többi a független adatokat. Az ntree opcióval adhatju meg, mennyi fát akarunk generálni. Azért, hogy az egész ne csak a levegőben lógjon, bemutatom, hogy miként használható a korábban is bemutatott tüdőrákos adatokon.

Miután letöltöttük az adatokat, először beolvassuk azokat és táblázatot csinálunk belőlük. A könnyebbség kedvéért két táblázatot mindkét tumor típusnak.

library(randomForest)

readData <- function(initdir){
   files <- list.files(initdir, recursive = T, pattern =    "txt.gz",full.names = T)
   data <- read.table(files[1])
   rownames(data) <- data$V1
   data <- data[,2,drop=F]
   for(i in 2:length(files)){
      new <- read.table(files[i])
      data <- cbind(data, new[,2])
   }
   return(data)
}

luad <- readData("luad/")
lusc <- readData("lusc/")

Ebből a két táblázatból készítünk egy harmadikat, ahol minden egyes sor egy minta lesz, az oszlopok a gének expressziói. Ehhez még egy oszlopot rakunk, ami a tumor típusát definiálja. Ez lesz egyébként a függő változónk is.

data <- as.data.frame(rbind(t(lusc),t(luad)))
data <- cbind(data, c(rep("lusc", ncol(lusc)),rep("luad", ncol(luad))))
colnames(data)[60484] <- "cancer"

Végül a tanítási fázis:

rf <- randomForest(cancer ~ ., data = data, ntree = 500)

Legalábbis elméletileg. Nekem a tanítás segfaulttal elszállt, ha az összes génre akartam futtatni. Ha csak 100 génre limitáltam, akkor gond nélkül lefutott.

A ranger csomag szintaxisa is teljesen hasonló. Érdekessége, hogy van C++-os futtatható változata is.

rf <- ranger(cancer ~., data = data)

A teljes génszetten ez sem futott le az R halála nélkül, de száz génre gond nélkül alkalmazható volt.

Szerencsére a következő csomagunk, az Rborist megtöri a fenti hagyományt, és ezzel megakadályozza, hogy telefonkönyv-szerű felsorolássá degradálódjon ez a poszt. Szintaxisa közelebb áll a scikit-learn filozófiájához. Az adatok generálása egy kicsit ezért más lesz:

data <- as.data.frame(rbind(t(lusc),t(luad)))
response <- as.factor(c(rep("lusc", ncol(lusc)),rep("luad", ncol(luad))))
rf3 <- Rborist(data, response)

Ez az egyedüli csomag, ami több szálat is képes használni és ez volt az egyedüli (az általam próbáltak közül), ami képes volt a teljes adatszettet feldolgozni fagyás nélkül!

Összegzés

Habár R és Python nyelven is elérhetőek véletlen erdő implementációk, ha masszív adatmennyiséggel kell számolni, célszerű Pythont használni. Ez igazából nekem is meglepő eredmény, nem tudom, miért nem működtek hatvanezer génre az R implementációk többsége. A memória nem fogyott el, az biztos (6% memóriát használtak egy 32GB memóriával rendelkező gépen). Az Rborist rendesen kihasználta az alatta futó vas erőforrásait. Kb. 20% memóriát használt és 7 magot a nyolcból. Igaz, a példák nem voltak életszerűek (nem csináltunk külön tanuló és teszt adatsort), nem is mértük, mennyire jók az egyes implementációk. Azt sem szabad elfelejteni, hogy R-ben további csomagok érhetőek el, amelyekre nem tértem ki. A Jupyte notebookok elérhetőek itt.

Mi lehet rosszabb egy excel táblázatnál? A válasz nem az, hogy két inkonzisztens excel táblázat, bár az is elég közel van hozzá. A válasz a Word táblázat.

Mikor már azt hiszem, nem tudnak meglepni, kiderül, hogy még van mit tanulnom. Rájöttem, hogy az adat bányászat tényleg bányászás. Nem gyémánt, vagy arany, hanem szénbányászat a 60-as évekből. Tényleg le kell menni az ismeretlenbe, bemocskolni magad az ott található, egészségre káros anyagokkal és reménykedni, hogy élve feljössz. Mindezt miért? Hogy a felszínre hozz egy csomó környezetszennyező anyagot.

Most kaptam egy ilyen szép táblázatot:

Jajj, de aranyos! Megsimogathatom? Eszedbe ne jusson, torokra támad! Mi a fene az a szám a fejléc alatt? Mi az, hogy sok éves átlag? Eltérés? Minek az oda? Miért nem kell minden oszlop alá átlag? És összeg? A "vegetációban összesen" honnan a fenéből jön? Mindez egy olyan programba ágyazva, aminek a legemlékezetesebb funkciója egy flipper.

Persze itt nem áll meg a menet, kaptam még egy táblázatot, ami az oldal szélesség miatt nem fért el, ezért a kilógó oszlopokat új sorba helyezték! A második oszlop ezért mást jelentett a 6. sor után. De kedvesek voltak, mert a fejlécet is bennehagyták. A cellák értékei pedig igen hasznosak voltak: "sok", "kevés", "jó", "igen jó". Ezzel a kódolással csak egyetlen probléma volt: a jó lehetett 1,43. Az igen jó 2,1, de akár 1,07 is. (Ezt onnan tudom, hogy végül megkaptam a numerikus értékeket is.) Legszívesebben lecseréltem volna az összes értéket "igen rosszra". Információ tartalmán mit sem változtatna.

A slussz poén, hogy otthon elpanaszoltam a "sokéves átlaggal" kapcsolatos problémáimat, mire a feleségem megjegyezte, hogy a sokéves átlagtól való eltérés teljesen elfogadott a botanikai lapokban. "Mindenki így csinálja." Egy teljes tudomány terület tartja életben ezeket a táblázatokat! Ha ilyen sokan vannak, csak egyet tehetünk.