Az élet kódjai

Remélem kijut a poszt, mielőtt elkezdődik az idei Experience. Ugyanis demo készül nagy erőkkel.

Mint arról már korábban írtam, Betasector a csapatunk legújabb tagja és rögtön aktivizálta magát. Blenderben rittyentett két jelenetet, ami már önmagában is tök jól nézett ki. A feladat elég egyszerűen indult: ezt kell valós időben elkészíteni.

Most, hogy Pythonban is viszonylag otthon vagyok és korábban is használtam a programot tartalmak előállítására, azt gondoltam, nem lesz nehéz a feladat. Ez a túlzott optimizmus. Még ennyi év után is. Ráadásul úgy gondoltam, jó volt ez a Unity, de ideje tovább lépni.

A modellek még gond nélkül bemásztak a demóba. A problémák a kamera animációnál kezdődtek. Eddig fel sem tűnt, hogy a Blender másik koordináta rendszert használ, mint az OpenGL. Persze azért nem tűnt fel, mert az OBJ exporter lehetőségként megadja az "Y up" és "-Z forward" opciókat, ezért az exportált modell az OpenGL környezetben pontosan úgy jelenik meg, mint a szerkesztő programban. A kameránál mindez nem működik.

A pozíció esetén még nincs is gond, két koordinátát kell felcserélni, de a forgatás esetén valami miatt remeg a kép, mintha két forgatási szög között váltakozna. A megoldásra egy Babylon.js fórumban bukkantam. Az itt leírt módszer nem működött, de kellő alapot adott, hogy próbálgatással megtaláljam azt a kombinációt, ami pont ugyan azt az eredményt adja, mint amit a Blender mutatott. Mikor láttam a megoldást, akkor már értettem, miért ezt kell csinálni, de addig nem esett le a tantusz.

Ennyi bevezető után jöjjön a módszer:
import bpy
f = open("/tmp/pos.txt", "w")
camera = bpy.data.objects['Camera.003']
for i in range(bpy.context.scene.frame_end):
        bpy.context.scene.frame_set(i)
        for j in range(4):
                f.write(str(camera.location[j]))
                f.write(" ")
        for j in range(4):
                f.write(str(camera.rotation[j]))
                f.write(" ")
        f.write("\n")
f.close()

A fenti kóddal Blenderből ki tudjuk menteni a kamera pozícióját és forgás szögeit. Természetesen ez még nem megfelelő nekünk. Tegyük fel, minden egyes sor elemeit a pos nevű tömb tárolja. Ebben az esetben a következő kóddal fordíthatjuk őket OpenGL "kompatibilissé":

translate(tr, -pos[0], -pos[2], pos[1]);
rotate(rot, -pos[3] + 1.570796326794897, -pos[5], pos[4]);
matrixMultiply4x4(tr, rot, camera);

Viszont rengeteg időt vesztegettem el a kiderítésével. A másik érdekes kihívás a demó elején három kamera között váltogat a kép, de átmenettel. Ez igazából nem bonyolult, csak én még nem programoztam ilyet. Annyi történt, hogy a jelenetet három kameraállásból textúrába rendereltem, majd a második lépésben, mikor jött a post-processing, a két textúrát mixeltem. Mivel itt a shader mindig két textúrát várt, ezért készült egy nagyon ronda boiler-plate kód, hogy amikor csak egy képet kell mutatni, akkor is van mix, csak 100%-ban a második textúra látszik. Nem szép, de ekkor a sok éjszakázás és gyereksírás között már nagyon nem tudott érdekelni, hogy a kód elegáns legyen.

Az utolsó nap Shamen is meglepett egy stílusos befelyezéssel. Addig a zene egyszerűen csak abbamaradt. Nem volt valami szép, de annyira örültem, hogy nem jártunk úgy, mint Function-ön, hogy nem szóltam miatta. Most pedig még a zene is tökéletes lett!

Szombaton vendégek is jöttek, de csak a gyerkőc érdkelte őket, ezért én észrevétlenül kódolni kezdtem, hogy be tudjam fejezni a demót. Chaten Betasector is bejelentkezett, és az utolsó egy órában adta az instrukciókat, hogyan nézzen ki a demó. Sajnos a második jelenetet így sem tudtam rendesen befejezni. Az alagútas jelenet nagyon lapos lett, ezért Betasector tett bele mintákat és kiadtuk.

Negyedikek lettünk a hét indulóból. Nem lettünk utolsók! A második jelenet hiányosságait majd egy végső változatban utólag kiadjuk.

Az egyik baktérium szekvenálásból van egy nyers genomunk. Mivel végre abból is cikk lesz, fel kell tölteni a szekvenciát az NCBI adatbázisába, hogy a cikkel egy időben az is eljusson a közösséghez.

Annak idején hallottam olyan pletykákat, hogy valaki feltöltötte a Jurassic Park regényben talált szekvenciát, vagy Karácsony közeledtével a Mennyből az angyal szövegét fehérje szekvenciaként. Nem tudom, mennyi igaz belőle, de egyiket sem találtam meg.

Az biztos, hogy mára igen erősen ellenőrzik, hogy mi kerülhet bele az adatbázisokba. Mára már nagyon sok féle adatot fel lehet tölteni. A mi esetünkben a WGS volt a legmegfelelőbb szekció, mert ide nem szükséges kész genomot küldeni. A nyers fasta fájlok fejlécét először formázni kell. Már itt szerepelnie kell az organizmusnak, a törzsnek. Ezután egy letölthető program segítségével (tbl2asn) konvertálni kell. Már ez a program is sok hasznos üzenettel lát el. A dokumentációval ellentétben a figyelmeztetéseket is ki kell javítani, mert a későbbi lépéseknél fog elakadni a feltöltés.

A webes form kitöltése egyszerű, de ha mégis valami hibát vétünk, akkor kapunk róla e-mailt, hogy mit fognak kijavítani. Módosításra ugyanis nincs lehetőség. Ha valamit elírtunk, csak levelezés útján kérhetjük az adminisztrátorokat, hogy változtassák meg.

A manuális munka miatt a feltöltés három napot is igénybe vehet, ha minden jól megy. Ha hibázunk, akkor minden egyes felfedezett hiba további napokkal hosszabbítja a műveletet.

A szekvenciákat is alaposan ellenőrzik. Már csak ezért is kételkedem a fenti két anekdota hitelességében. A mi esetünkben is kaptam egy levelet, ahol kértek, hogy néhány kontigot távolítsak el a feltölteni kívánt szekvenciából, mert azok gorillából, orángutánból és mitokondriumból származnak. Gorilla? Mi folyhatott abban a laborban? Biztos valami nagy buli.

Számtalan neve van: egyensugarú user, Vér Pistike, A szomszéd gyerek. Mind ugyan azt takarja. Van számítógépe, rettenetes mennyiségű önbizalma és egy picivel többet ért a számítástechnikához, mint a körülötte élők. Láthatatlan, de mindenütt ott van. Még soha nem hallottam róla, hogy bárki személyesen találkozott volna egyel is, de internet szerte óva intenek tőle.

Eljött a nagy leleplezés ideje. Most csak Önök, csak itt megismerhetik a mumus igazi arcát. Találkozhatnak a félelmetes buherátorral, a bukott rendszergazdával, a klikkelők szégyenével: Én vagyok Vér Pistike.

Meglepődtek? Miért? Van számítógépem, de csak Chip-magazin szintű tudásom. Segítek a szomszédnak/ismerősnek beállítani a gépét. Nincs sem OKJ-s papírom, se felsőfokú szakirányú végzettségem. Hatalmas önbizalommal vetem bele magam minden olyan feladatba, amit még hivatásos rendszergazdák is visszautasítanak. Az összes bélyeg illik rám. A következtetés tehát egyértelmű: én vagyok, akitől a profi informatikusok óva intenek.

Miért nem tűntem el? Miként vagyok képes a billentyűzet közelében maradni? A válasz egyszerű: szükség van rám. Szükség van a korlátozott tudásomra, amit ingyen bocsátok a rászorulók rendelkezésére. És sajnos a hivatásosok között is van olyan, akinek inkább követ kéne törnie, mint programokat telepítenie.

Nem akarom azt sugallni, hogy minden informatikus ostoba. Rengeteg jó szakember van, de következő történetem szereplőinek egy Vér Pistike volt az utolsó mentsvár...

Az egyik rokonom falun él. Volt egy kis béna számítógépe, amivel valamilyen szinten elboldogult. Skype-on tartottuk a kapcsolatot, de sem a sávszélesség, sem a hardver nem tette egyszerűvé a kommunikációt. Még a YouTube is akadozott.

Ez az ember gondolt egyet és megkérte a munkahelyi rendszergazdáját, hogy állítson össze egy konfigurációt, ami "jó". Mikor kérdeztem, milyen gépet fog venni, csak annyit tudott mondani, hogy "az van ráírva: XXL Gamer Pro". Vagy valami hasonló. Több információt nem sikerült megtudnom.

A régi gépről szeretett volna átmásolni adatokat az újra, de a panelgyári biztonsági őr (akitől kérdezte) megnyugtatták, hogy ez rendkívül bonyolult művelet, ne is próbálkozzon vele. Az operációs rendszer telepítése szintén nagyon bonyolult, mert "fel kell törni a kódot" hozzá. Mintha csak a Hacktion valamelyik epizódját hallanám.

A Skype beszélgetések ezután elmaradtak. (Bizonyára nem sikerült feltörni a kódot.) Telefonon viszont megtudtam, hogy jött a következő probléma: össze kell dugni a csatlakozókat. Mivel ismerősöm mérnök, mondtam neki, hogy próbálja meg ő összedugni. Úgysem tudja rosszul csinálni. Minden csatlakozó csak egy helyre mehet. Ennek ellenére nem merte megpróbálni, hanem rábízta az ex alkoholista nevelt fiára. A fiú, az elbeszélések alapján nem boldogult a feladattal. Felbosszantotta magát és otthagyta a gépet.

Megkértek, hogy telefonon vezényeljem le az összeszerelést. Ezt nem akartam elvállalni, mert én nem látom, hogy ő mit csinál és ő nem érti, hogy én mit akarok.  Azt kértem, hogy először fényképezzék le a gép csatlakozóit és küldjék el nekem. Beszámozom őket, visszaküldöm és az alapján már beszélhetünk.

Vártam, hogy jöjjenek a fotók, de nem jöttek. Végül telefonon felhívtam őket:

- Azért nem küldtem a képeket, mert jött egy hivatásos informatikus. Azt mondja, rossz ez a gép. Nem ad képet.
- Nem biztos, lehet, hogy csak kilazult a videokártya...
- Hú, odaadom az informatikust, beszélj vele...Halló, XY vagyok, informatikus és HelpDeskes. Megnéztem, ez a számítógép hibás.
- Lehet, hogy csak kilazult a videokártya a szállítás során. Meg kellene igazítani...
- Nem lehet, a burkolat eltávolítása garanciavesztéssel jár. Higgye el kérem, hogy ez a számítógép rossz. Kipróbáltam három különböző kábellel, nem ad képet.

Mivel én csak egy Vér Pistike vagyok, meghajoltam a szaktekintély előtt, aki természetesen elkérte a kiszállási díjat, és a fizetséget. Ismerősöm közben átkozódott, hogy csak egy számítógépet szeretett volna, mégis ennyire nehéz szerezni egyet és milyen bonyolult a beüzemelés. Visszaviszi a gépet és talán minden megoldódik.

Mint később kiderült, a gépen van egy alaplapi videokártya is. Két darab monitor kimenet volt, de csak egyet tesztelt le és mivel az nem adott jelet, megállapította, hogy a gép nem működik. Gratulálok neki, innen is.

A következő lépcsőfok a Skype telepítése volt. Annak ellenére, hogy ezt az ismerősöm a korábbi gépen sikeresen megoldotta, most valami miatt nem sikerült neki. Elmondása szerint a Skype letöltéséhez meg kellene adnia az ismerőseinek az e-mail címét, de ő ezt nem akarja. Mi van?

Ez már kezdett bűzleni nekem. Közben jött egy másik informatikus is, aki sikeresen abszolválta a Skype telepítését. De jött a következő probléma: reklámok jelentek meg. Nem lehetett megnézni egyetlen weboldalt sem, mert folyton reklámok jelentek meg.

- Küldtem e-mailt. Olvastad? - kérdeztem tőle.
- Nem, nem tudok belépni a levelezésembe.
- Miért nem tudsz?
- Korábban a Gmail-t mindig a Startlapon találtam, ott írtam be a jelszavamat...
- Mit csináltál? Miért nem a Gmail oldalán?
- Mert nem találom.
- A böngésző címsorába írd be: gmail.com
- Nem tudom, nekem olyan nincs websearch van helyette.
- Mi a fene az a websearch?

Természetesen tőle hiába kérdeztem. A gugli viszont megmondta. A gépre valaki telepített néhány malware-t. Nem állítom, hogy a második informatikus telepítette őket, de az tény, hogy utána akár hányszor hívták, nem vette fel a telefont. Természetesen ő sem ingyen dolgozott.

Ez volt az a pont, hogy már nem bírtam tovább. Elutaztam hozzájuk, úgyis érett már egy találkozó, mert fél éve nem láttuk egymást.

A gépen 13 olyan programot számoltam össze, aminek a nevében shop, clean vagy  password volt. Még csak meg sem próbálták elrejteni valódi szándékukat.

Mivel nem volt kényes adat a gépen, megpróbálkoztam egy rendszer visszaállítással. A művelethez kell a telepítő DVD. Mint kiderült, ez hiányzik. A boltban ugyanis az operációs rendszer nélkül árult géphez az eladó adott tört programot!

Először a naiv megoldással próbálkoztam: A Windows Programok Eltávolítása opciójával. Természetesen nem működött minden progi esetén. Gondoltam, majd akkor a nyers erő módszerével a program könyvtárát fogom törölni. Mivel futó folyamatok voltak, ezért a rendszer nem engedte, hogy letöröljem őket.

Elindítottam az msconfigot, de a rendszerindításnál nem láttam egyetlen gyanús program nevét sem. A CCleaner segítségével kiderült, hogy az ütemezett feladatok között bújnak meg. Ugyan ezzel a programmal szépen eltávolítottam őket onnan, de előtte az elérési út ismeretében felkerestem a könyvtárat és szépen kézzel letöröltem mindent. A CClean eltávolította a hátramaradt Registry bejegyzéseket.

Újraindítás után megnézem, mennyi szemét maradt, majd a lépéseket megismételtem, amíg egyetlen egy sem maradt. A böngészők reklám mentesítéséhez az itt leírtakat használtam.

Csak egy kis kellemetlenség maradt, amit nem sikerült megoldanom: Az aukciós portálokon, online piactereken továbbra is megmaradtak a reklámok. Ez legközelebbre maradt. Linux kellett volna neki, de az igazi gyógyírt elutasította. Fizetségnek akart adni egy bontott csirkét, de nem fogadtam el.

Az intézetünkben van két rendszergazdának látszó ember és egy igazi rendszergazda. Utóbbi, ha épp nem a bögyös titkárnőknek csapja a szelet, akkor igen segítőkész. Ez már a két krampuszáról nem mondható el. Ahogy egy volt kollégám megfogalmazta: olyanok, mint akiken lobotómiát végeztek. Mintha egyiküknek csak a jobb, másiknak a bal agyféltekéjét távolították volna el.

Az egyikük ugyanis "szoftveres", ami annyit jelent, hogy tud nyomtató meghajtót telepíteni. A másikuk "hardveres", ami nem is tudom, mit jelent az ő nyelvükön.

Habár ők is, én is számítógépekkel foglalkozunk, csak ritkán keresztezzük egymás útjait, és ez nagyon is jól van. Viszont történt valami, ami felborította a kényes egyensúlyt.

Azt gondolom, nem árulok el titkot, ha azt mondom, a magyar kutatás számítógép éhségben szenved. Akár kivel beszélek, az első problémája, hogy nem tud számítógépet rendelni. Ez nálunk is így van, de ügyes kutatók megoldották, hogy a semmiből gépek landoljanak nálunk. Annyi gépet nem tudtak szerezni, hogy mindenkinek jusson, ezért a javaslatomra vettek egy Windows szervert is, hogy a régi XP-ket vékony kliensként használjáhassák és az erőforrás igényes műveleteket (pl. e-mail megtekintés) futtassák a szerveren.

Azt is jeleztem, hogy szükség lesz 5 darab licencre. A gépek megérkeztek. Mindenki boldog volt.

Illetve majdnem. Akiktől rendelték a gépeket, hogy mutassák, mennyire értenek hozzá, telepítették a Windowsokat. Valami okból kifolyólag egy licenct használtak ehhez, ezért mikor két gépet kapcsoltak a hálózatra, akkor nem működtek.

A másik ügyes akciójuk az volt, hogy nem annyi memóriával rendelték a gépeket, ahogy kértük tőlük, hanem kevesebbel, rendeltek külön memóriát, majd szétszedték a gépeket és belerakták őket. A garanciának ezzel lőttek.

A rendszergazgáink rárepültek és rögtön telepítették rájuk a Sophos programokat, mert hát az ISO szabvány előírja. Mikor kértük tőlük, hogy állítsák be a szerveren a távoli hozzáférést, a "szoftveres angyfélteke" csak annyit mondot: nem értek hozzá. Nagy barna szemeivel nézett, és mintha ez lenne a legtökéletesebb válasz, amit adhatott volna, megismételte: nem értek hozzá. Már elsőre is világos volt számunka, de valami miatt fontosnak tartotta megismételni.

Elképzeltem, hogy élete első randiján is valami hasonlót alkotott:

- Csókolj meg!

- Nem lehet, nem értek hozzá.

És ülnek tovább a holdfényben.

Végül elvállaltam, mert láttam, hogy különben nem lesz semmi. Utoljára a Windows Server 2003-hoz volt szerencsém. Mikor letölthető volt a nyilvános béta verzió, akkor felraktam a gépemre. Hatalmas magabiztossággal és Stackoverflow-al a hátam mögött nekivágtam, hogy konfiguráljam a rendszert.

A folyamat egyszerűbb volt, mint gondoltam. Bejelentkezés után azonnal egy olyan ablak fogadott, ami arra buzdított, hogy vegyek fel új szolgáltatásokat. A szolgáltatások tematikus rendbe voltak szedve, nem okozott kiválasztani a távoli hozzáférést. Amikor kiválasztottam a nekem kellő elemeket, a rendszer figyelmeztetett, hogy milyen egyéb szolgáltatásokra lesz szükség a hibátlan működéshez.

Az egyedüli kivételt a licence szerver képezte, aminek hiányára egy újraindítás után figyelmeztetett a Windows. A gondok itt kezdődtek. A távoli hozzáféréshez kell egy úgynevezett kliens hozzáférési licence (client access license, CAL). A rendelésnél jeleztem is, hogy erre szükség lesz. Kérdeztem is, hogy merre találom, de mindenki azt állította, hogy ők a gépek közeléből semmit nem vittek el. A dobozokat tényleg nem vitték el.

Neki is álltam átnézni őket, de csak a rendszer visszaállító DVD-ket találtam meg. A CAL hiányzott. A szerver szerint még volt 120 napom, hogy előkeressem a licenceket, ezért a továbbiakban a kliensekre koncentráltam.

A Windows XP esetén egy kis regisztrációs adatbázis turkálásra van szükség, de a nagyobb probléma az volt, hogy nem bírtam kivárni, hogy betöltődjenek. Tucatnyi ikon jelent meg a tálcán, ablakok ugráltak fel jelezve, hogy még egy újabb szükségtelen program van telepítve a gépre. A HP egyik meghajtója ráadásul megjelenített egy ablakot, amit nem lehetett bezárni. A gép előző felhasználója is csak annyit mondott: "Azt a Feladat kezelőből lehet csak eltűntetni."

Megnézem, milyen programok vannak telepítve a gépre: Iphone connectivity ("Kinek van Iphone-ja?" Válasz: senkinek), iTunes ("Ki használt iTunest?" Válasz: "mi az az iTunes?"), Java JDK ("Ki fejlesztett Javaban ezen a gépen?" Válasz: senki), Samsung mobil alkalmazás, Nokia mobil alkalmazás, Google Earth, stb. Csupa olyan program, ami nélkül nem lehet genetikát művelni. Leszedtem, amit tudtam, és láss csodát, a gép használható lett.

A távoli hozzáférés gyönyörűen ment. Már csak a licenceket kell előkeríteni, mielőtt lejár a 120 nap.

A party nagyon jol alakult. Charlie-tól megtudtam egy kisebb demoscene krízis háttértörténetét. Az történt ugyanis, hogy mivel kevés ember foglalkozik a scene.hu weboldallal, ezért Murphy, az egyetlen, aki posztol, be szokott venni olyan híreket is, amelyeknek szinte semmi köze nincs a demoscenéhez. Ami viszont köthető a demoscenéhez, az késve jelenik meg. Emiatt egy csomó kritikát kap.

Egy volt munkatársam is eljött, akinek ez volt az első demoscene rendezvénye, amin részt vett. Jó volt vele is találkozni.

A 256b intrók nagyon tetszettek. Szerintem hatalmas előre lépés, hogy egyre több intrónak van hangja. Azt is jó látni, hogy próbálkoznak alternatív megoldásokkal. Például láttunk egy Processing szkriptet is!

A 4k compó is tartogatott meglepetéseket. Először is az Astroidea release. A csapat ugyanis sok éve nem adott ki semmit. Az indoklast itt hallhatjátok. Szóval így kell megfiatalodni.

A 64k kompó hozta a papírformát, a Conspiracy magasan a mezőny fölött szárnyalt, de azért a Dilemmának sincs oka a panaszra. Agoston 64k-ja pedig semmi újat nem mutatott.

A demók elég változatosak voltak. A Unityben összedobott vacaktól egészen a művészi kompozícióig volt minden. A projektoron nagyon bénán nézett ki a Trabant, mint utólag megtudtam, a VGA-splittereken elveszett a jel egy része. Utolsó elöttiek lettünk, de szerintem volt rosszabb alkotás is a miénknél. A közönség viszont így döntött, nincs mit tenni.

A Blazar erős volt, megérdemelten nyert. A Háromnegyed tíz lett a második. Fültanúja voltam, amint Gargaj és Immortal Rat a demóról beszélt korábban és ettől nagyon nagy elvárásaim voltak. Talán kicsit irreálisak is. Ennek ellenére a stílusa jobban tetszik, mint a Blazarnak. Mu6knak bejött a szöveges mód. Harmadik helyezést ért el. A Hollow Spaces-t pedig nem értem.

A party remek volt, köszönjük a szervezőknek, hogy időt és energiát áldoztak ránk.

Ez a demó készítés kezd olyan lenni, mint egy szappan opera. Emberek beszélnek, kavarnak össze-vissza és keresztbe tesznek egymásnak. Én pedig mindig a fordulat előtt megszakítom a blog írását.

Pénteken az egyetlen jó döntés, amit hoztam, a korai lefekvés volt. Az első előnye, hogy korán fel tudtam kelni. A másik előnye, nem voltam fáradt. Reggel négykor ébredtem és első dolgom az volt, hogy megnézzem, milyen zenét kaptam.

Semmilyet. Az alibi release nem állt olyan szinten, hogy érdemes legyen vele tovább foglalkozni, ezért a korábban említett DVD-ről szedtem két másik zenét és 5 óra alatt beleoperáltam a készülő művekbe. A wildunkra illő zene nem volt, ezért a kezdetleges eszközeimmel levágtam egy zene elejét és végét. A módszer egyetlen előnye, hogy nem lesz néma a prod. Azért többet érdemelt volna, de úgy érzem, azért annyira nem jó, hogy egy következő partira halasszuk.

A demóhoz választott zenével már többet kellett bíbelődni, de cserébe az eredmény is elfogadhatóbb lett. Az időzítés sok időt vett el, de 9 órára készen voltam. Mindent ment a felhőbe, egy pendrivére és már indultam is.

A délelőtt nagyon csendes volt. A helyszín nagyon kultúrált és modern. Elkezdtem beszélgetni az emberekkel. Megtudtam, hogy a Conspiracy minden tagja készített egy demót (persze más csapat néven, hogy maximalizálják a nyerési esélyt). Mu6k csinált valami text mode demót. Talán arra számít, hogy megismételheti a Revision sikerét? Blueghost a partin kezdett el kódolni, de nem sok esélyt látok, hogy befejezi.

Gargajjal az új demótooljáról beszélgettünk. Megtudtam, hogy DirectX-ben van egy debug mód, amivel könnyen ki lehet szűrni az olyan hibákat, amik a hibás állapot beállításból fakadnak. Ilyet OpenGL-ben is el tudnék viselni. Azt is megtudtam, hogy az új eszköz folyamat ábra szerkesztővel programozható. Azon lepődtem meg a legjobban, hogy értem, mit mond. Általában, amikor magas szintű demoscene eszmefuttatásokat hallok, a legtöbb szót nem tudom hova tenni.

Slyspy azt mondta, jövőre már nem fog demókat csinálni, mert öreg. Így hullnak el legjobbjaink a hosszú harc alatt...

Betasector viszont nagyon lelkes. Fejlődik is, ezért úgy döntöttem, jó helyen lesz a csapatunkban.

A Kürt Kft két előadása a deep learningről és az adat visszanyerésről szólt. Meglepő, mire képes a technika. A hatalmas számítógépes kapacitásnak hála ugyanis óriási méretű neurális hálókat tudnak építeni, ami például a képfelismerés terén az emberi teljesítmény határát súrolja. De ha azt nézzük, egy ember mennyi képet tud átnézni egy nap, akkor nyugodtan állíthatjuk, hogy az algoritmusok lepipálnak minket.

Az adatmentős előadás lényege, hogy cégen kívül ne reménykedjünk semmiben, ha adat visszanyerésről van szó és az SSD mindenre jó, csak biztonságos adattárolásra nem. Már csak ezért érdemes volt eljönni. Ja, és a repi pendrivéért. :-)

Annyit beszéltem emberekkel, hogy lemaradtam a zene és grafikai kompókról. Most kezdődik a SIDrip Alliance koncert.

Vajon utolsók, vagy utolsó előttiek leszünk? Milyen lesz a demónk fogadtatása? Megtudhatják a folytatásból!

Eljött a nagy nap. A releaset elkészítettem már kedden és eljuttattam Shamennek, hogy próbáljon meg zenét szerezni rá. Elég kevés időt hagytam rá, de Grass megnyugtatott, hogy "Shamen rövid határidővel is tud dolgozni". Nekem ennyi elég is volt.

Azért csütörtökön már elkezdtem dolgozni a vész forgatókönyvön. Ami annyit jelent, hogy előkotortam a fel nem használt zenéket tartalmazó DVD-t, kiválasztottam a legrövidebb zenét és vadul kalapáltam a billentyűzetet Unityben. Persze nem volt sem textúrám, sem modellem, semmim, de legalább sokáig fenn voltam.

Reggel háromnegyed hatkor kedélyes csevegésnek induló e-mailt írtam, amiben azt tudakoltam Shamentől, hogy jön-e partira és csak úgy mellékesen megkérdeztem, hogy mi hír a zenével. A válaszban kifejtette, hogy egész héten 12 órázik, hétvégén fellépése van, este küldi a zenét.

A melóhelyen az egyetlen pozitívum az volt, hogy sikerült kapcsolatot találni a DNS metiláltság és a MinION készülék nukleotid leolvasása között. De már jöttek, hogy nézzem meg a szekvenciáik minőségét, nem tudják indexelni a BAM fájlokat, nem tudják elindítani az IGV-t, stb. stb.

Hamarabb le is léptem a melóhelyről, úgyis van egy csomó plusz órám. Elkezdtem heggeszteni az alibi release-t, hogy mégsem menjek üres kézzel és fél óránként néztem a leveleimet, hogy megjött-e a zene. Jelen poszt írásának pillanatában még nincs zene. A határidő közeleg. A legjobb az lesz, ha lefekszem, akkor legalább nem úgy fogok kinézni, mint egy zombi.

Egyszerűen nem értem, mások hogyan képesek 1,5 nappal a leadás előtt elkezdeni a demót.

Ismét eltelt egy év és ismét közeleg a Function. Evoke-on kiadták az invitációt, ami azt ígéri, hogy most minden más lesz.

Természetesen ez nem véletlen. Gargaj, aki eddig szervezni szokta, belefáradt az idegtépő munkába és átadta a stafétabotot Pasyéknak. Örömet szerezni az embereknek elég nehéz, főleg a demoscene-n belül, ahol az emberek harsányan adnak hangot véleményüknek.

Az új gárda szemmel láthatóan belead anyait-apait, hogy méltóak legyenek a bizalomra. Egy valami mégsem fog változni: ugyan úgy sereghajtók leszünk.

Már egy ideje készítjük a demót, de nem látom, mi az, ami megfogná a nézőket. Nem találok semmi érdekeset benne. A másik dolog, ami talán nagyképűen fog hangzani, de úgy érzem, kezdjük elérni az ingyenes Unity határait. Nem vitás, hogy rengeteg időt spórolunk a használatával. Az sem kérdéses, hogy sok olyan funkciója van, amit még nem tudok ilyen minőségben implementálni (vagy egyáltalán implementálni). De akad olyan része is, ami sokkal egyszerűbben működik saját kódból.

Például a shaderek. Egy szimpla fehér zajt ráültetni a végső képre nagyon egyszerű OpenGL-ben. Unityben elég macerás. Egy csomó körítést kell hozzáadni, hogy befogadja a keretrendszer. Igaz, utána már könnyű paraméterezni, de míg addig eljutunk...

A másik a részecskék. Nem emlékszem, hogy ennyire körülményes lett volna animálni őket, pedig minden paramétert kódból állítgatok. Még az is lehet, hogy ez a baj :-)

Ami biztosan készül még, az egy wild. Megpróbálkozunk egy vicces, de figyelemfelkeltő videóval. Ennek a fogadtatására nagyon kíváncsi leszek, mert olyan témát feszegetünk, ami vita egy ideje demoscene körökben.

Végezetül annyit mondanék, aki tud, jöjjön el. Mi biztosan ott leszünk.

Nemrég statisztikai számításokkal kellett kisegítenem egy projektet. A probléma az volt, hogy aki eredetileg végezte a számításokat egy warez SPSS-el, elment babázni, a cikk bírálói viszont további összehasonlításokat szerettek volna látni. Így kerültem én a képbe.

SPSS-el nem tudtam szolgálni, de teljesen legális R-el igen. Össze is gyűjtötték nekem az áhított összehasonlításokat én meg írtam egy szkriptet, ami elvégezte a nem kevesebb, mint 150 ezer t-próbát és a hozzá tartozó többszörös teszt-korrekciót. Nagy boldogan átnyújtottam az eredményeket, de nem volt váll veregetés.

A probléma az volt, hogy a kísérlet vezetője már "látta" az eredményt és ezt a statisztika nem támasztotta alá. Először csak arra kértek, hogy hagyjam el a Benjamini-Hochberg korrekciót, hogy több szignifikáns eredmény legyen (hahaha), majd miután így sem lehetett igazolni az elvárásokat, másik tesztet kértek. Sajnos én nem ismerem "Látszik" tesztet, ami pont ugyan azokat az eredményeket hozza ki, amiket elvárnak emberek.

A probléma ugyanis a szórás volt. A kísérletet 3 évben végezték el, három ismétléssel, és az évek között akkora szórás volt, hogy a kontroll és a kezelés átfedett. Ezt mindenki értette és senki sem vitatta. Cikkek alapján viszont elvártak bizonyos trendeket, amik elő is jöttek, ha hunyorítva néztek a grafikonokra. De csak nekik. Nekem valahogy nem megy a hunyorítás. Szerettek volna egy olyan tesztet, ami "nem érzékeny a szórásra". Valószínűleg az én műveletlenségem, hogy nem ismerek ilyet.

Miután itt holtpontra jutottunk, arra kértek, hogy legalább ismételjem meg R-el az SPSS-s manova analízist. Ez egyszerűnek tűnt, de kiderült, hogy sokkal nehezebb, mint gondoltam. Kaptam két Excel táblázatot, egy PowerPoint diát, ahol lépésről lépésre leírták, mit csinált az előző kutató. A menüpontokat R parancsokká változtattam, majd összehasonlítottam az eredményt. Egyes eredmények megegyeztek, de néhány változónál olyan mértékű eltérés volt, hogy még a szórás négyzetek nagyságrendje is különbözött.

Első gondolatom az volt, hogy az SPSS-el rosszul klikkeltek. A második, hogy valami paramétert rosszul állítok be R-ben. Mindkét feltevés hibásnak bizonyult. Pontosabban részben hibásnak.

Az internetet bújva először az vált világossá számomra, hogy a különbség igenis létezik. A szórás négyzetet ugyanis többféle módon is ki lehet számolni, ami kiegyenlítetlen adatoknál egészen más eredményt adhat. Természetesen nekünk egyes esetekben ez volt a helyzet. Ezek alapján nem csoda, hogy a statisztikában kevésbé jártas emberek bűvészkedésnek fogják fel a módszert, hiszen látszólag ugyan azzal a teszttel eltérő eredményeket kaphatunk.

De a statisztika nem bűvészkedés. Ez is ugyan olyan eszköz, mint a labor centrifuga. Ha nem centrifugálsz elég ideig, a felül úszóban lesz a mintád és kiöntöd. Ugyan így, ha rossz statisztikát használsz, nem lesz eredmény. A másik dolog, amit nem szabad elfelejteni, hogy ha rossz bemeneti adatokat használunk, akkor az eredmény is rossz lesz. Egy befertőzött táptalajról senki nem akar baktériumot tisztítani, de két ismétlés alapján már ki merik jelenteni, hogy a különbség szignifikáns.

Talán egy hasonlattal rá tudok világítani a lényegre. Gondoljunk úgy a statisztikára, mint az étkezésre. Mást eszünk vasárnap egy családi ebédnél és mást a moziban. Nyilván lehet pattogatott kukoricát is felszolgálni a rántott hús helyett, de a végeredmény nem lesz ugyan az. Pontosan így van a statisztikában is. Többféle teszt van gyakran ugyan arra a feladatkörre is, de azért, mert mindegyiket csak bizonyos körülmények között érdemes használni.

Ahogy pörköltet sem szokás magában enni, hanem valami körettel, úgy bizonyos statisztikai teszteket is együtt használunk.

Most játszunk egy kicsit. Én leszek a kibic, aki nem érti a táplálkozás lényegét: Minek kell három fogás? Csak tele lesz a gyomrunk tőle. Inkább együnk csak dobos tortát, amikor éhesek leszünk. Mi? Attól nem lehet jóllakni? Biztosan rosszul készítették el. Nem kell villa sem hozzá, mert olvastam, hogy valaki a szájpadlásába szúrt egyet. Inkább kézzel kanyarítok a közös tálról, ha kell. Egyéb tápanyagok bevitele csak bűvészkedés, a szervezet mindent elő tud állítani szénhidrátból.

Ugye milyen fájdalmas hallgatni?

Minden nemzetnek megvan a maga totemállata. A genom programok korában nem meglepő, hogy ezen állatok szekvenálása különösen fontos az adott nemzetnek, így pénzt, energiát nem kímélve végzik a feldolgozást.

A kínaiaknak ott az óriás panda, az amcsiknak a "négyszázas" ló, nekünk magyaroknak pedig a mangalica.

A projektbe viszonylag későn kapcsolódtam be, ezért csak marginális szerepem volt, de ahhoz mindenképp elég volt, hogy a cikkbe kerüljek. Sőt, egyes pillanatokban úgy éreztem én hátráltatom a csoportot.

Először a projekt vezetői között volt egy kisebb vita arról, hogy csináljunk-e további vizsgálatokat, vagy ne. Én úgy láttam, hogy sokan belefáradtak a disznó genom boncolgatásába, ezért ők a mielőbbi publikálást preferálták. Az is gond volt, hogy ketten elhagyták a kutató csoportot és új helyen igyekeztek helyt állni. Végül mindenki beadta a derekát és megkezdődött a cikk írás.

Már tavaly elkészült a kézirat, de a bírálók kifogásoltak rajta több vizsgálatot, ezért a decemberben igyekeztünk a hiányosságokat bepótolni, hogy még az ünnepek előtt vissza tudjuk küldeni azt. Az egyik ilyen kifogás az volt, hogy miért a Samtools-t használtuk a variációk detektálására, miért nem a GATK-t. Szerencsére korábbról volt már tapasztalatom az eszközzel, így enyém lett a megtisztelő feladat, hogy lefuttassam azt.

Szerencsére idő előtt végeztem is vele, így abban a megnyugtató tudatban mentem szabadságra, hogy mindent megtettem a siker érdekében. Azért fél szemmel figyeltem a levelezést, így derült ki, hogy bizony SNP-k vannak, de az indelek valahogy hiányoznak. Természetesen kifelejtettem egy kapcsolót.

Rögtön meg is kaptam a magamét. Jóvá akartam tenni a dolgot, ezért az összes elérhető számítógépen GATK futott. A rokonok vacak internetén egy mini laptoppal gyűrtem a bájtokat, miközben hallgattam, hogy milyen jó nekem, mert távolról is tudok dolgozni.

Szerencsére nem kellett az egész Karácsonyt végig dolgozni és a felállított határidőket is tudtuk tartani. Csakhogy a bírálók újabb problémát találtak...

Ekkor kezdődött egy furcsa ping-pong játszma köztünk és a bírálók között, ahol ők kifogásoltak valamit és rendkívül rövid határidőket szabtak nekünk, mi megcsináltuk, és utána hetekig nem válaszoltak semmit. Ez ismétlődött hónapokon keresztül. Szerzőtársaim már különböző összeesküvés elméleteket gyártottak a gonosz disznó kutatókról, akik direkt hátráltatnak minket, mert nem ismerjük a titkos kézfogást.

Közben az újságnál főszerkesztő váltás is történt és az új ember végül megkegyelmezett nekünk és elfogadta a cikket. Mindenki megkönnyebbülhetett. Hurrá!

Különböző fórumokon rendszeresen felbukkan az algoritmusok GPU-ra történő átírása. Ez alól a bioinformatika sem kivétel. A GPU-t amolyan isteni megváltásnak tekintik minden problémára. Még olyan emberrel is találkoztam, aki azt gondolta, attól, hogy erős videókártyát tesz a gépébe, máris hatalmas teljesítmény növekedést fog tapasztalni. Ezért is merült fel bennem:  tényleg szükség van rá? Egyfelől ott van az igény a gyors eredményekre, másrészt a szűk keresztmetszet sok esetben a lemez műveletek sebessége. Ebben a posztban megpróbálom kideríteni mekkora a GPU alapú bioinformatikai algoritmusok létjogosultsága. Kiválasztottam néhány programot, amelynek ismert a CPUs válatozata és összehasonlítottam őket. Habár nagy GPU rajongó vagyok, igyekszem objektív lenni.

Tesztkörnyezet

A teszteket egy AMD FX-8350 processzort tartalmazó gépen végeztem 32GB memóriával. A videokártya egy GeForce GTX 460 volt 1GB memóriával. A meghajtóprogram verziószáma 319.60. A tesztgépen egy 64bites Slackware 14.1 futott. A Cuda meghajtóprogram a 6.0 verziószámot viselte.

Programok

NVBio: A csomag része az nvBowtie, de más érdekes program is található rajta kívül. A fordítása gond nélkül sikerült a cmake/make párossal. Ellenfele a a bowtie2-2.2.2, szintén forráskódból fordítva, probléma nélkül.

 GPU-Blast: Az NCBI-Blast GPU-val erősített változata. Telepítés előtt szerkeszteni kellett az install szkriptet, mert letölti a CPU-s változatot az NCBI FTP tárhelyéről és a fájlnévben a verziószám elavult volt. A G-Blastn is ide kívánkozik. Érdekes lesz összehasonlítani nem csak a GPU/CPU teljesítmény különbséget, de az egyes implementációs különbségeket is. (Bár a két README fájl gyanúsan sok egyezést mutat.)

A gBlastn fordítása elég nehezen ment. Az install szkript először vagy letölti az 2.2.28 Blast-ot, vagy kéri a forráskód elérési útját, belemásolja a GPU függő kódot, felül ír más fájlokat és megpróbálja fordítani ezt a katyvaszt. Az 1.1 verzió semmilyen módon nem akart lefordulni. Igaz, a 2.2.28 Blast fordítása is csak úgy ment, ha a ncbi_gnutls.c-ből kitöröltem egy sort. Ebből adódóan, ha az install szkript töltötte le a Blastot, akkor az nem fordult le, mert benne volt a fordítást akadályozó sor. Ha én adtam be az elérési utat, akkor nem volt képes belerakni a saját vackait. Már majdnem úgy nézett ki, nem lesz semmi ebből a bejegyzésből, amikor ráakadtam a GitHubon fejlesztett verzióra. Az öröm korainak bizonyult, mert így a fordítás későbbi szakaszán jelentkezett hiba. Végül úgy döntöttem, nem kísérletezem tovább és kihagyom a tesztből.

 cuda-meme: A program a népszerű motivum kereső GPU-s változata. A fordítás itt sem okozott gondot. A CPU megfelelője a leírások alapján a MEME 4.4, de én az egyszerűség kedvéért a gépemre már korábban telepített 4.9.1 verziót használtam (szintén forráskódból és már sikeresen használtam is).

mummergpu: Ismét egy illesztő program, de ez genomi szinten pakolja egybe a szekvenciákat. Ebben az esetben az eredeti program fejlesztői készítették el a GPU-s változatot. Ezért is lepődtem meg, amikor a fordítás során hiányzó fejléc állományokra és linkelési hibákra utaló hibaüzeneteket kaptam. Egy ideig szenvedtem a kóddal, de végül ez a program is kiesett a rostán.

SOAP3: A kínaiak csodafegyvere a bioinformatika frontján. A de novo programjukkal már szenvedtem, ezért semmi jóra nem számítottam az illesztőjükkel kapcsolatban. Szerencsére ezt nem kellett fordítani, mert csak binárisan terjesztik.

Teszt futtatások

A MEME összehasonlításhoz a Doop adatbázis 85067420 klaszterét használtam. A klaszter 3000-es promótereit töltöttem le (All promoters, 3000bp, Download clusters). Hiába fordult le gond nélkül a program, nálam segmentation fault-al elszállt, még alapértelmezett beállításokkal is. Összehasonlításra így nincs mód.

A Bowtie illesztéshez egy C. elegans genom szekvenálást választottam. A genomot innen szedtem. Már az index építése is eltér a CPU és GPU verziókban. A bowtie2-build helyett az nvBWT program állítja elő azt. Sajnos a folyamat itt el is akadt, mert minden indítás alkalmával más történt. Először úgy tűnt végtelen cikusba került a program, mert fájokat nem hozott létre, de folyamatosan írt a konzolra. Második indításra segmentation fault-ot adott. Nem álltam neki hibát keresni.

Minden reményem a SOAP3-ban volt. A leírás szerint 3GB videomemória kell neki, ennek ellenére belevágtam. Fordítani nem kellett, mert csak binárisan terjesztik a programot. Itt is az index készítésénél akadt el a teszt, mert hiányzott neki a libcudart.3.so.

Összegzés

Bevallom, nagyon meglepett, hogy egyetlen programot sem tudtam használni. Való igaz, hogy sok ponton elbukhat egy Linuxos program telepítése, de ne feledjük, hogy a CPU változatot sikeresen tudtam fordítani és a kész programot használni ezen a rendszeren. Személy szerint azt gondolom, hogy a GPU verziós programok nem érik el kódinőségben azt a szintet, amit a CPU-s változat. A fejlesztők valahogy összerakják a rendszert, ami a saját gépükön elfut és írnak belőle egy cikket, majd nem fejlesztik tovább azt. Ez alól látszólag a gBlastn kivételt képez, mert a GitHub szerint rendszeresen érkeznek javítások a kódbázishoz. Talán a jövőben újra megpróbálkozom a telepítésével, de aki használni akarja ezeket a programokat, inkább támaszkodjon a CPU-ra. Az eredmény biztosabb.

Idén az Assembly csalódás volt. Nagyon kevés alkotás fogott meg. Ezeket röviden bemutatnám:

Korábban szívesen mazsoláztam ezen parti zenei kínálatából. Három zenei compó is volt (fast, dance, listen) és tényleg a demoscene krémje indult rajta, mégis csupán King Thrill Guru Meditationja fogott meg. Meglepetés volt számomra, hogy nem volt egyetlen dubstep sem.

A grafikai mezőny erős volt. Sok, különböző technikával készült kép készült és üdítő volt látni, hogy nem csak 3D rendert készített minden induló. A nyertes kép azért így is kemény:

Tekotuotanto nem készített vicces videót, de készített vicces játékot. Egy teljes irodát kell leszanálni 20mp alatt. Nagyon tetszett.

Az 1k introk valahogy lelketlenek voltak. 256byteban annyira igyekeznek az emberek ötleteset alkotni, de itt a legtöbben megakadtak a "csapjunk össze valamit ShaderToy-ban és adjuk ki" szinten, hogy unalmasnak hatott mindegyik. Kivéve persze a nyertes Superstructure, akik megmutatták, hogy van még potenciál ebben a kategóriában is.

Idén csak egy vicces film készült 4 féle technika felvonultatásával, a Business trip. A Kitchen lehet, hogy vicces volt, én viszont nem nevettem rajta.

Demó kategóriában az első három helyezett elég erős volt. A Fairlight nem hazudtolta meg önmagát, nyert, de csupa hazugsággal. Még a csapat nevét is letagadták és one studio off néven kiadták a Black and White Lies-t. Csupa fekete-fehér vonallal bemutatott átlátszó hazugság. Alapvetően tetszett az egymásra rétegezett szó és jelentéstartalom. A látványról inkább filozófiai síkra terelték ezzel mondandójukat.

A Nuclei is ötletes volt. Látszik, hogy a fiúk sokat gyúrtak a kódra. Kicsit zagyva volt, hogy mit is csinál a kis robot, de a látványra nem lehet panasz. A demó motorjuk látszólag fel van vértezve minden jóval, kíváncsi vagyok, mit hoznak ki belőle legközelebb.

Farbrausch is kitett magáért vonatos demójával. Ők a hiper-realitás ábrázolástól eltérő módszert választottak, amitől kevésbé látszik, mennyi munka is van ebben az alkotásban. Nekem legjobban ez tetszett.

Call for paper. Open Journal. Ezekkel a szavakkal kezdődik minden levélszemét a munkahelyi levelezésemben. Sehol egy viagra, sem dús gazdag afrikai diktátorok, akik az én segítségemmel akarják vagyonukat kimenteni háború súlytotta országukból.

Tudományos körökben nyílt titoknak számít, hogy egyes szervezetek újságnak álcázva akarnak pénzt szipolyozni csóró kutatóktól. Ezt kapargatta meg ez a tanulmány is.

Eddig megpróbálták legalább a tudományosság látszatát kelteni ezek az e-mailek. De amit most kaptam, az ezzel is szakít. Csak néhány cím kedvcsinálónak:

Special Issue - Adam Exists in the Mind of Man: the Existential Phenomenological Ontology of Human Predicament

Parallels between Confucian Philosophy and Quantum Physics

The Meta Energy of Dark Energy

Már az irodalomjegyzék is mosolyt csal az ember arcára:

DNA and the genetic code Egy 1998-as PDF Ebben benne van minden, amit egy filozófusnak tudnia kell a DNS-ről. Talán még több is.

Aki már nem bírja kivárni, hogy lerántsam a leplet erről a remek híranyagról, annak itt a link.

Ti melyik cikket citálnátok a legszívesebben?

Nekünk embereknek elég korlátolt érzékszerveink vannak. Amennyiben olyan jelenségeket tanulmányozunk, amihez érzékszerveink kevésnek bizonyulnak, különböző eljárásokkal érzékelhetővé tesszük azt. Ez viszont együtt jár azzal, hogy az alkalmazott eljárások torzító hatását - amennyiben nem ismerjük azt - a tanulmányozott jelenség részének tekintsük.

Sokáig naívan azt gondoltam, ezzel a problémával csak az elméleti fizikusok találkoznak. Az elnevezést is ők vezették be. A biológiában mi élőlényekkel foglalkozunk és bármilyen kicsi alkotóelemet is vizsgálunk, a végén szó szerint élet-halál kérdés dönti el, hogy a hipotézisünk igaz-e.

Az első sokk egy előadáson ért. Ezen az előadáson arról beszéltek, hogy mikroRNSek második generációs szekvenálási eljárással történő meghatározása során a könyvtár készítés alatt a mikroRNS másodlagos szerkezetet alakít ki az adaptor szekvenciával. Ennek eredményeként egyes szekvenciák könnyebben amplifikálódnak. Eredményül azt kapjuk, hogy az egyes mikroRNS abundancia értékek nincsenek arányban a tényleges koncentrációkkal. Röviden: a szekvenálással nem a mikroRNS expressziót mérjük, hanem azt, hogy a mikroRNS mennyire szeret párosodni az adapterrel. A jelenséget itt közölték le.

A második sokk már kisebb volt, de épp elég lehangoló az is. Egy cikket olvastam, ahol különböző növényi mikroRNS target prediktáló programot hasonlítottak össze. Már eddig is tudtam, hogy legyen bármilyen fifikás is egy algoritmus, az csupán jóslás, nem a valóság. De a növényi mikroRNS-ek az eddigi publikációk alapján hálás témának bizonyultak, mert viszonylag kevés és egyszerű szabály alakalmazásával lehetett meghatározni a célpontjukat. A cikk viszont rávilágított, hogy a programok legtöbbjét Arabidopsis adatokon tesztelték. Azon remekül helyt is állnak, de még a viszonylag közel rokon fajokon is drámaian lecsökken a hatékonyságuk.

Ezek után felteszem a kérdést: mikroRNS elemzés címszó alatt mit is csinálok? Olyan szekvenciákat kapok, amelyek nem a növényt, hanem a könyvtár készítést jellemzik és utána olyan programokat futtatok rajtuk, amelyek hatékonysága az adott fajon kérdéses. Ugyan ezt teszi másik száz vagy ezer kutató. Írják a cikkeket, vitákat folytatnak, miközben pont az az információ veszik el, amit meg akarnak találni.

A kérdés az, hogy az újabb módszerek közelebb visznek-e a valósághoz, vagy csupán újabb délibábokat teremtenek, amelyek kergetésével egy újabb generáció töltheti az idejét?

Több gépünk is van, ami nincs 100%-ban kihasználva, ezért úgy gondoltam, telepítek rájuk Hadoopot. Már csak a HDFS is megérné, hiszen a tárolt adatok így is több gépen vannak össze-vissza, gyakran aszerint, hogy éppen hol van hely. Ha emellett még MapReduce alkalmazásokat is bevethetünk, hogy a feladatokat gyorsabban megcsináljuk, az csak újabb jó pont.

Négy gépet akartam befogni. Mi tagadás, ennél heterogénebb rendszert elég nehéz elképzelni: OpenSUSE 12.0 Java 1.6-al, 3 Kubuntu 14.10, de az egyik 1.7 Oracle Javaval, kettő OpenJDK-val. A teljesítmény is elég ingadozó. Van 4, 8, 48 és 70 GB memória, 3 négy magos és egy 8 magos gép.

Az első és legfontosabb, hogy minél kevesebb gép specifikus elérési út legyen, ezért az /opt/hadoop-2.2.0 könyvtárba kerültek a Hadoop fájljai. A dokumentáció szerint a JAVA_HOME-t és a HADOOP_HOME-ot minden esetben be kell állítani. Ezek a .bashrc-ben kerültek beállításra.

A második legfontosabb, de ezt minden fórum és leírás hangoztatja, a jelszó mentes SSH belépés. Erre tonnányi anyag van a neten, nem térnék ki rá. Egy fontos momentum viszont hiányzik a dokumentációból, és csak a fórumok probléma megoldásai között találhatunk rá: az /etc/hosts-ban a gépek nevéhez ugyan az a bejegyzés legyen! Tehát ha egy gép neve slave12, akkor minden más hadoop gépen a slave12-höz ugyan az az IP cím szerepeljen, és ne 127.0.0.1.  

A dokumentáció szerint a konfigurációs állományok a HADOOP_HOME/conf könyvtárban vannak, de ez nem igaz. A HADOOP_HOME/etc/hadoop könyvtárban vannak. XML-ben vannak a programok paraméterei, míg a programok futásához szükséges környezeti változók .sh kiterjesztésű szkriptekben kerülnek beállításra. Célszerű ezeket úgy módosítani, hogy az egész konfigurációs könyvtárat tudjuk mozgatni az összes gépre. Ez igazából könnyen megoldható, mert a master és slave gépek csak abban különböznek, hogy más démonokat indítanak el rajtuk.

Ha minden démont egy gépen indítunk, akkor kapjuk az úgynevezett pseudo distributive módot. Ez igazából csak a konfiguráció helyességének tesztelésére jó, sok értelme szerintem nincs. Mint már említettem, a gépek két csoportba sorolhatóak: master és slave. A master gépek ha nem működnek, akkor nincs Hadoop. Alapvetően két démon tartozik ide: NameNode és Yarn (ResourceManager/JobTracker). Előbbi az elosztott fájlrendszer adatait tartja nyilván, utóbbi a MapReduce folyamatok működéséért felelős. Nagyobb rendszerek esetén mindegyikből lehet tartalékot is fenntartani (pl. másodlagos NameNode), de nálunk erre nincs sem lehetőség, sem igény.

A slave gépek vannak többen. Meghibásodásuk esetén a feladatot át tudja venni másik gép. Itt a DataNode és NodeManager démonok futnak.

A konfigurációs XML-ek felépítése egyszerű:

<property>
   <name> </name>
   <value> </value>
<property> 

A nevek listáját ne a dokumentációból szedjük, hanem nézzük meg a default tartalmú fájlokat. Ezeket a find HADOOP_HOME -name "*default*xml" paranccsal találhatjuk meg. Az XML fájlokban mindegyik bejegyzéshez van leírás, amiből megtudjuk, mit állíthatunk be. A legfontosabb, hogy a slave gépek tudják, hol találják a master gépeket: A core-site.xml-ben az fs.defaultFS mondja meg, hol van a NameNode. A mapred-site.xml-ben a mapreduce.jobtracker.address azonosítja a JobTrackert, a yarn-site.xml-ben a yarn.resourcemanager.hostname pedig ahogy neve is mutatja a ResourceManager-t tartja nyilván. Természetesen egyéb beállításokat is tehetünk, de ez a minimum.

Ahogy a master gépeket azonosítottuk, ugyan úgy ismerni kell a slave gépek nevét is. A slaves fájlban fel kell sorolni valamennyit, valamint a yarn-site.xml-ben a yarn.nodemanager.xml-t állítsuk localhostra. A hdfs-site.xml-ben állíthatjuk be, hogy az adott gép milyen erőforrásokkal járuljon hozzá az elosztott fájlrendszerhez. Sajnos a mi esetünkben ez a leggyengébb pontja a konfigurációnak, mert minden gépen mást kell beállítani.

Jöhet a démonok indítása! Minden slave gépen el kell indítani a DataNode és NodeManager démonokat. Előbbi a HDFS-ért, utóbbi a MapReduce-ért felelős:

HADOOP_HOME/sbin/hadoop-daemon.sh --script hdfs start datanode
HADOOP_HOME/sbin/yarn-daemon.sh start nodemanager

A mi esetünkben csak egy master gép van, minden azzal kapcsolatos démont azon indítunk el. Még akkor is, ha a dokumentáció ezt nem javasolja.

HADOOP_HOME/sbin/hadoop-daemon.sh --script hdfs start namenode
HADOOP_HOME/sbin/yarn-daemon.sh start resourcemanager

 A rendszert a böngészőből lehet ellenőrizni, a 9000-es porton. Ha nem látjuk a weboldalt, akkor nem megy a NameNode. Ha a slave gépek közül hiányzik valamelyik, akkor nézzük át annak a gépnek a log fájljait. Ezeket a HADOOP_HOME/logs könyvtárban találjuk.

Korábban már próbáltam játszani a SOAPdenovoval, de a bináris kivételt dobott még a legegyszerűbb esetben is, a forrást pedig képtelen voltam lefordítani. Ez sokáig frusztrált, mert sorra jelentek meg a publikációk, ahol mindenki vígan használta a programot. Mivel ezeknek a cikkeknek a szerzői között kivétel nélkül volt legalább egy kínai, furcsa összeesküvés elmélet fogalmazódott meg bennem: van egy nyilvános forráskód, ami lefordíthatatlan a fehér emberek számára és van egy titkos forráskód, amit csak a kiválasztottak kaphatnak meg.

Sajnos a másik lehetőség, hogy én bénázok valamit.

Legutóbb megint a kezem ügyébe került a SOAPdenovo és ismét farkasszemet néztünk. Ismét kiadtam a mágikus make parancsot és rezignáltan vettem tudomásul a hibaüzenetek özönét. Átolvastam őket és világossá vált, hogy konzekvensen hiányzik az unistd.h-ra történő hivatkozás. Kiegészítettem a kódokat vele és máris lefordult. Lelkesedésemben odáig mentem, hogy elindítottam az első kezem ügyébe kerülő baktérium szekvencián és lefutott!

Ez két dolgot jelent: mégsem vagyok olyan béna, vagy kínai vagyok.

Demó készítési törekvésünk megtörni látszik. Először nagy lendülettel elkezdtem demo motort fejleszteni, ami megállt egy közepes szinten. Legnagyobb problémája, hogy nincsenek árnyékok implementálva (meg sok egyéb más sem). Utána Cinema4D plugint kezdtem el fejleszteni Grassnak, hogy könnyebb legyen a tartalom előállítás. Jelenleg ez is szünetel.

Grass közben szívesebben teker 200km-eket bringán, minthogy textúrákat gyártson és én is rengeteg időt töltöttem Coursera kurzusok elvégzésével, később meg babázni kezdtem. Tavaly kín keservesen összehoztunk egy demót Function-re, aminek eredményeként rájöttem, hogy át kell szervezni az időbeosztásomat. Ennek első lépése, hogy le kell szokni a Courseráról. Tényleg olyan, mint a drog. Mindig találtam valami ürügyet arra, miért akarom elvégezni az adott kurzust és utána csináltam a házikat dögivel. A problémák akkor kezdődtek, amikor több kurzust is felvettem egyszerre, mondván, hátha később nem indítják. Erre egyébként volt már példa és nagyon sajnáltam, hogy lemaradtam róla.

A másik megoldás, ha a demó készítésre fordított időt rövidítem le különböző eszközök bevetésével. Eddig a legjobb eszköznek a Unity tűnt. El is kezdtünk demót készíteni vele, először NVision-re, majd Revision-re, később @Partyra. Pár nap éjszakázás után úgy láttam, hogy nem érdemes összecsapni a release-t, mert tényleg kevés volt vissza. Ezért új partit kerestem, ahová elfogadnak nevezést interneten is. Így akadtam rá Sundownra, ahová sikeresen el is küldtem a kész demót.

Habár wild és oldschool kategóriákban elég sok nevezés érkezett, PC-s demóból kettőt mutattak be. Szerencsére a neten nyomon tudtam követni az eseményeket. Itt láttam meg, hogy bizony egyes mozgások nem úgy néztek ki Angliában, mint az én gépemen. Nevezetesen a sárkány nem gyalogolt el addig, amíg nálam tette.

Meglepődtem, de nem sokáig. Azt ugyanis a tesztelésnél észrevettem, hogy ha alacsony minőségi beállításokkal futtatom a demót, akkor tovább megy a sárkány. Ha a beállítások magasak, akkor addig megy, ameddig kell. Ezt úgy oldottam meg, hogy kikapcsoltam az alacsony beállítási lehetőségeket, mert azt feltételeztem, hogy Unity bug. A közvetítés után viszont úgy gondoltam, a két eset összefügghet.

Mint kiderült, a jó öreg frissítési hibát követtem el, amikor nem vettem figyelembe, hogy két rajzolási ciklus között nem feltétlenül telik el ugyan annyi idő, pláne nem különböző teljesítményű processzorokon. A hibát gyorsan javítottam, nehogy a Pouet-en emiatt szavazzák le.

Az eredményről csak annyit, hogy akár csak a régi viccben: mi a dicső második helyezést értük el, míg a dashw csapat csak az utolsó előtti lett.

A családtól kimenőt kaptam, amit úgy próbáltam eltölteni, hogy elmentem egy Unity3D Meetupra. Már csak azért is érdemes volt elmenni, mert az eseménynek a Prezi biztosította a helyszínt és valószínűleg nem lesz még egy olyan alkalom, hogy eljussak oda. Olvastam róla, hogy egyes fejlesztő cégek (többnyire külföldön) úgy rendezik be a munkahelyet, mint egy játszóteret, de más erről olvasni és más megtapasztalni.

A tömegközlekedésnek hála korán érkeztem, az előadók még csak akkor szinkronizálták előadásukat a Google Drive-ról. A csarnok végén a munkában megfáradt fejlesztők vezették le a napi feszültséget egy ping-pong mérkőzéssel. Én meg leültem a nézőtérre, a nagy színes párnák közé. Teljesen beleolvadtam a közegbe. A legtöbben térdnadrágot, pólót és hátizsákot viseltünk.

Érdekes módon a Unity3D motor úgy híresült el, mint játékfejlesztő eszköz, ennek ellenére csak két előadás szólt játékokról, azok is nagyon marginálisan. A fő téma a kiterjesztett valóság volt. Ne gondoljunk azokra az unalmas alkalmazásokra, hogy levegőben lebegő nyilak jelzik, hol a legolcsóbb a tej. Hanem olyanokra, amik az ejtőernyősök és pilóták életét könnyíti meg azzal, hogy piros falakként jelzik a tiltott zónákat, nyilakkal mutatják merre vannak a termikek, sőt még a repülőgép kezelőpaneljén is jelzik a gombok bekapcsolásának sorrendjét.

Miért kapcsolódik ez a Unity3D-hez? A válasz egyszerű: az információk interaktív megjelenítését ez a motor végzi. Egy okostelefon vagy okos szemüveg (ez a kifejezés létezik?) giroszkópját használják fel, hogy érzékeljék a fej orientációját, a GPS-t, hogy megállapítsák a felhasználó helyzetét és ezek felhasználásával renderelik a látványt.

Személy szerint úgy sejtem, ez egy elég marginális szelete lehet a kiterjesztett valóság piacnak, de mindenképp hasznosabb, mint a közösségi zombi vadászat.

Visszakanyarodva a játékokhoz, kaptunk egy rövid bemutatót, hogyan lehet gyorsan 2D játékokat készíteni sprite-okkal. Az előadó (akivel már találkoztam egy Function-on), egy rövid teszt keretében bemutatta, mennyi sprite-ot tud kezelni a Unity különböző platformokon 23 fps-el. Engem személy szerint meglepett, hogy egy mai okostelefonon ez a szám 480. Pár éve, mikor még követtem a telefonok teljesítmény mutatóit, akkor a poligonszám elérte a százezres nagyságrendet (jelenleg pedig a milliósat). Ehhez képest a 480 nagyon kevésnek tűnik (bár az igaz, egy játéknak elég). Valószínűleg ez a Unity hibája, mert ugyan azon a készüléken a régi és az új motor között drámai különbség volt. Megnyugtató, hogy a natív alkalmazások fejlesztőinek azért még van esélye :-)

Az utolsó előadás a piszkos kis marketing trükkökről szólt, hogyan csikarjunk ki pénzt egy erősen túlzsúfolt piacon. Nem vagyok mobil játékos, a telefonom is 7 éves (ezt leírva látni elég szörnyű), ezért nem tudtam arról, milyen kényszeredett megoldások vannak. Az egyik, hogy a játékok már más játékokat reklámoznak és a másik játék letöltése esetén különböző bónuszokat kapnak a játékosok. A közösségi portálok, mint reklámfelületek, nem működnek, mert a legtöbb játékos alkalmi, nem olvassa a "szakcikkeke". Az alkalmazás boltok gonoszak lettek, mert nem mutatják már az új játékokat a listák elején. Egy szóval nem könnyű az indie játék fejlesztők élete.

A meetup legizgalmasabb része a kütyük kipróbálása volt. Az előadók hoztak egy csomó eszközt. Az egyik egy ejtőernyős sisak volt. A bemutató cég hekkelt rá egy okostelefon foglalatot, kamerát a bal oldalra és ennek segítségével jelenítette meg az információkat. Kérdeztem, mennyire strapabíró ez a megoldás, mert voltak kétségeim, de mint kiderült, nem a telefon a gyenge pont, inkább a csatlakozók. Akik kipróbálták, arról panaszkodtam, hogy zavaró, hogy csak az egyik szemre jön az információ, míg a másikon csak a környezet látszik. Itt ki is bukott, hogy az eszköz tesztelője egy ejtőernyős operatőr volt, akinek ez a természetes.

A másik kütyü egy okostelefon szemüveg volt. A telefon sztereografikus képét kis lencsékkel a szemre fókuszálják és így érik el a virtuális valóság élményt. Olcsó, egyszerű, mint a szög. A tesztalkalmazás egy 360 fokos kamerával felvett ejtőernyős ugrásról készült videó volt. Mikor megfordultam, még az operatőrt is láttam. Egyébként ez volt az egyetlen eszköz, amit szemüvegesek is tudtak használni, mert a lencséket kézzel kellett a felhasználóhoz igazítani.

Hoztak egy Epson Moverio szemüveget is, aminek az előadók szerint a legnagyobb hibája, hogy ronda. Ezt is kipróbáltam, de sok mindent nem láttam. Kellett volna még egy szemüveg...

Mint minden ilyen meetupnál, nem is az előadások a legérdekesebbek, hanem utánuk a kötetlen beszélgetések. Itt sem volt másként. Sok szó esett az Oculusról, habár egyetlen előadáson sem beszéltek róla. Érdekes volt hallani olyanok véleményét, akik napi szinten dolgoznak vele és kapcsolatban állnak a fejlesztőkkel. A készülék legnagyobb hibája, hogy rosszul lesz tőle az ember. A szemből és a középfülből érkező információkat az agy nem tudja összeegyeztetni, ezért a fogékony emberek tengeri betegek lesznek. A sisakhoz kell egy számítógép. ami folyamatosan generálja a képet, ettől beszűkül a használhatósága. Végezetül pixel számban az előbb bemutatott okostelefon/minilencse kombináció - állítólag - lenyomja.

Lassan eljutunk oda, hogy a vadászpilóták HMD-ja minden napos eszköz lesz az egymotors kisgépeken is, és a Unity állandó társ lesz ezeken az utazásokon.

Egy projekt kapcsán olyan ismert kisRNS-ek szekvenciájával kellett dolgozni, ami még nincs benne a mirbase-ben. Annyit mondtak, hogy a szekvenciák benne vannak egy cikkben. Tényleg benne voltak. Két oldalon keresztül mentek a táblázat sorai, 90 fokkal elforgatva.

Nem szeretek másolni. Ha kijelöltem és kimásoltam, csak sületlenséget kaptam. Az egyetlen használható információ a cikk online változata, mert ott a táblázat orientációja normális volt. Cserébe képként volt beszúrva. Nincs más hátra, be kell gépelni. Bár csak lenne egy szakdolgozóm! Már épp megnyitottam egy szöveg fájlt, amikor eszembe jutott, talán van valami jó OCR program Linux alá.

Rövid keresgélés után ráakadtam egy összehasonlító cikkre. Elolvastam a jelölteket és röpke tűnődés után adtam egy esélyt a tesseractnak. Parancssoros program, ami szövegfájlt eredményez. Ennél jobb konbinációt el sem tudok képzelni. Még az Ubuntu repoban is megtalálható, ezért csak egy pillanat volt a telepítése.

A dokumentáció elég szűk szavú. Nincs 200 paraméter, nincs kézi állítgatás. Ezen a ponton kicsit szkeptikus lettem, de már fel volt telepítve. Ha nem váltja be a hozzá fűzött reményt, majd eltávolítjuk. Letöltöttem a cikk ábráját a lehető legnagyobb felbontásban és ráeresztettem a programot. Fél másodperc és keletkezett egy fájl.

A tesseract gyönyörű TAB-al elválasztott táblázatot csinált. Összesen három sorban volt hiba, amit kézzel kijavítottam. Mégsem kell szakdolgozó.

A kutatók mindent megtesznek, hogy új ismeretekre tegyenek szert, folyamatosan az emberi tudás határait feszegetik és előremutató gondolatok birtokosai. Legalábbis ez a közvélekedés. Talán igazak is ezek a megállapítások, de mindenképp hozzá kell tenni, hogy csak a saját kutatási területükön belül. Azon kívül sokan neofóbok, egyesek szűk látókörűek és akadnak vaskalaposak is. Szerencsére nem mindannyian, de akire igazak a fenti megállapítások, azok jellemét az eltelt idő még jobban kiemeli.

Az egyik ilyen eset, ami a fenti gondolatot elindította bennem, a hiábavaló küzdelmemhez kapcsolódik. Igen, az Excellel való leszámoláshoz. Gyakran kérik tőlem az elemzések végeredményét Excel táblázatban. Ezt passzív ellenállással szoktam kezelni. Először küldök nekik TAB-al elválasztott szövegfájlt. Ezután szólnak, hogy nem tudják megnyitni, nem lehetne-e Excelben. Erre küldök CSV-t, megjegyezve, hogy ezt az Excel tudja importálni. De ez sem szokott elég lenni. Mivel egy klikk hatására nem nyílik meg a kívánt programban, jön a következő kör, hogy ez használhatatlan, drága az idejük, miért nem lehet megérteni, hogy mit akarnak. Végül megkapják, amit akarnak.

Van egy csoport, akik viszont a saját fegyveremmel győznek le. A számukra megnyithatatlan fájlokat egyszerűen ignorálják. Hetek, hónapok múlva szólnak, hogy nincs meg nekik X eredmény. Biztos még nem csináltam meg. Elküldöm ismét a belső wikipedia linket, majd újabb csend következik.

Teljesen véletlenül derült ki, hogy mi a helyzet. Szociálisan aktív PhD hallgatónk beszélgetett a kérdéses kutatóval, aki panaszkodott, hogy meg kellene csinálni Y vizsgálatot, mert még az hiányzik a korszakalkotó cikkből. Ő rögtön mondta, hogy az elemzés kész, sőt megmutatta, hogyan kell Excelbe tölteni azt. Mikor meglátták a négyzetrácsos papír digitális megfelelőjén ugyan azokat a számokat, máris felderült az arcuk. Újabb fronton vesztettem.

Apropó számok. Expressziós értékeket logaritmikus skálán ábrázolok, mert akkor a kiugró értékek nem nyomják el a táblázat más elemeit. Eredmény: "Nem lehetne inkább normál skálán ábrázolni?" Természetesen lehet, bár mennyire is értelmetlen. Elkészülnek a kívánt ábrák, természetesen nem látszik semmit, csak a kiugró értékek. "Azokat vegyük ki!" Azt már nehéz megmagyarázni nekik, hogy akkor nem a milliós tartomány fogja elnyomni a többi értéket, hanem a százezres.

De az ábrák tengelyével is gondok vannak. Mivel nagy számokat kell megjeleníteni, minden normális program normál alakot használ. Ez ugyan csak problémás, mert nem értik, mit keres E betű egy számban. De nem is az a baj, hogy nem tudják ezeket a dolgokat, hiszen senki sem úgy születik. A probléma az, hogy nem is akarják megérteni.

Ellenben vannak pozitív meglepetések is. Például bemegyek a laborban, és a kutató laptopján nem Windows, hanem Linux van. Igaz, azon LibreOffice fut, ami csak egy kicsit jobb, mint egy Excel, de már ez is elég, hogy jobb kedvre derítsen. Akár csak az, ha megkérdezik, milyen statisztikai próbát használnék valami meghatározásához és kiderül, hogy az illető képes használni az R-t. (Habár az R szkriptet Wordben írja) Ezekből a példákból is látszik: van előrelépés, csak nagyon lassan.

Az idei Revision annyi release-t hozott, hogy jó sokáig tartott feldolgozni őket. Még így sem néztem meg mindent, de egy teljesen szubjektív bejegyzéshez ez is elég.

Grass írt egy remek grafikai összefoglalót, Murphy pedig a magyar indulókat mutatta be.

Lássuk, mi marad nekem:

Animációk

Surfacing: Idén is kaptunk egy hosszú videót fraktálokról. Fraktálokból soha nem lehet elég.

Vicces videók: Better life through demoscene, The classified ads, crusin portabl3: Sajnos a poénok inkább scener beállítottságú embereknek készültek, de egyszer mindenképp érdemes megnézni őket.

Amiga

Tavalyhoz képest kevesebb Amigás induló volt. Nagy meglepetés a The Black Lotus csapat visszatérése volt. Starstruck című alkotásuk után úgy tűnt befejezték az Amiga kódolást, az idei megjelenésük azt bizonyította, hogy ez nem igaz. A Rift kidolgozatlan benyomást kelt, különböző programhibák tarkítják, de amit látunk, az magáért beszél.

Szerencsétlen Elude ismét a második helyre szorult. Idei nevezésük nekem nem tetszett. A zenét sem Chaser szerezte. Nem, mintha H0ffmann rosszul keverné a hangokat, de előbbi nekem jobban bejön.

PC demók

Az első és második helyezett alkotás viszonylag szokásos sémát követ. A Cocoon demója továbbra is robotkarokat nyújtóztat döbbenetes grafikával. A Titan pedig egy invitációt mutatott be sok részecskével. Habár mindkettő megérdemelten jutott a dobogóra, a koncepciót nem találtam egyikben sem elég érdekesnek. Azokat az invitációkat szeretem, amelyek igyekeznek bemutatni a party hangulatot. A szokványos demók egy party dátummal ellátva nekem nem jönnek be.

A poo-brain demó idén sokkal egyszerűbb volt, ez a helyezésen is meglátszik. Azért néztem meg, mert ez is Unityvel készült. A legnagyobb probléma talán az volt vele, hogy kommerszebb demót akartak készíteni, amire a Unity szerintem nem jó választás.

A Still demójához kapcsolódik a legnagyobb meglepetésem. Elöljáróban annyit, hogy a demó maga elég unalmas. Random képek jelentek meg, viszonylag egyszerű effektekkel és ez ismétlődött. Már majdnem megnyomtam az Esc gombot, amikor megjelentek a készítők. Úgy döntöttem, akkor már végignézem. A szemem megakadt a grafikuson: Travis. Mióta vagyok a Still tagja? Biztos egy névrokon. Eddig azt hittem egyedi vagyok. Dalszöveg: Travis. Most már nagyon fúrta az oldalamat, ki lehet az alteregóm. A Pouet.net szerint a készítők között nincs névrokon. Elkezdtem olvasni a leírást és hangosan felnevettem. Az történt ugyanis, hogy a demó a böngésző gyorstárat, illetve a Skype chat logokat felhasználva generál magának tartalmat, a készítők közé pedig kiírja a felhasználó nevét. Ebből is látszik, nem érdemes YouTube-on demót nézni.

Az én személyes kedvencem - minden hibája ellenére - a Scarecrow volt. A mozgások elég ügyetlenül néztek ki, de ne felejtsük el, hogy jó karakter animációt nehéz csinálni. Nem véletlen, hogy a demók legtöbbje meg sem próbálja. A vizuális hatások is rosszabbak, mint a korábbi PlayPsyco demókban, de engem ez sem zavart. Még több sztoris demót!

PC intrók

L'abstraction Dominante: Mintha írtam volna valamit a fraktálokról... De ami leginkább felborzolta a kedélyeket, az a Mercury The Timeless című 64k-ja. A mondanivaló kicsit kusza, de a megvalósítás első rangú. Las raymarching kódja teljesen elfeledteti a nézővel, hogy csak egy intrót néz. A hullámzó tenger egyszerűen fenomenális! Néhány jelenet számomra kicsit erőltetett hatást kelt, de ez nem megbocsáthatatlan hiba.

Idén új kategória a 8k intró. A 4k adta kereteket egyre nehezebb betartani, ezért idén kísérleti jelleggel indították ezt a kategóriát. A Bridge mind mondanivalóban, mind technikai megoldásban első rangú volt. Ezzel a szavazók is egyet értettek. A Regression sajnos egy effektre épített és ez a gépemen elég furcsán jelent meg. A hang is elcsúszott, ami sokat rontott a megítélésén.

Wild

Idén megélhettük, hogy a demók már a világűrt is meghódították. A 10 orbyte ugyanis egy olyan C64 kód, amit az egyik műhold magával vitt a világűrbe.

Az első teszt futás felhő-alapú szekvencia meghatározása nem sikerült. A sablon szerű válaszok, amit a támogató csapat küldött azt akarta bemesélni nekünk, hogy bizonyára a könyvtárak jogosultságával lehetett a probléma. Igaz, hogy nem értek a Windowshoz, de azért ez elég furcsa válasz volt.

Megismételtük a teljes eljárást, kezdve a telepítéstől. Ügyeltünk a jogosultságokra, a lépések sorrendjére, de továbbra is hiba üzenetet kaptunk.

A fájlok tüzetes megfigyelésével viszont egy érdekes dologra lettem figyelmes. A készülék nem generál Fast5 fájlokat, azokat a telepítő varázsolja a megfelelő helyre. A Metrichore feltölti ezeket a fájlokat az Amazonra, majd ugyan olyan névvel letölt egy nagyobb fájlt.

A próbák során 20 teszt fájl van. A logok alapján 2-t feltölt és 4-t letölt. Azért tölt le kétszer annyit, mert minden egyes Fast5 fájlhoz tartozik egy log fájl is.

Egyre jobban elkezdte furdalni az oldalamat, hogy mi lehet ez a Fast5 fájl? Miféle formátum? Miként tudom használni? Először is megnéztem egy hex editorral, hátha a látok valami érdekeset. Az első négy bájton szerepelt a HDF, a fájl többi részén pedig TREE. Ebből arra következtettem, hogy ez egy általános konténer formátum, ami többféle adat tárolására is alkalmas. Nagyon emlékeztetett engem az avi-ra.

Ráakadtam egy oldalra, ami nem csak a formátumot magyarázta el, de kis segédprogramokat is mellékelt, amivel zökkenő mentesen átnézhettem valamennyi Fast5 fájlt.

A próba futások ennek ellenére problémások voltak, és a hiba üzenetet továbbra sem sikerült megszüntetni. Mivel négy fájl visszatért az Amazonról, az írási jogokkal nem lehetett gond. A kinti program is tette a dolgát valamennyire, egyedül a hálózattal lehetett még probléma.

Pár napra hazahoztam a gépet, hogy kipróbáljam az otthoni hálózaton is a rendszert. Természetesen ment minden, mint a karika csapás. Nincs más hátra, mint  a rendszergazdának látszó embereket kell megkérni, hogy oldják meg a problémát.

Mint már bemutattam, a rokonság a legkülönbözőbb ajándékokat adja a lányunknak és bizony nem ritka, hogy azokat a saját igényeinkhez kell igazítani. Nincs ez másképp Eperkével sem.

Eperke egy baba. Nagy, puha feje van, amit a lányom imád harapdálni. Pislog, ami a szem anatómiájának egy egyszerűsített modelljét tanítja a babának. (Bár amikor mutató ujjal nyomkodja, engem az inkább egy OSS kiképző filmre emlékeztet.) Beszél, énekel, mindezt ékes angol nyelven.

Eperkének viszont van egy rossz tulajdonsága. Olyan hangos, hogy a legtöbb gyerek sírva fakad tőle, ezért elhatároztam, hogy Eperkét lecsendesítem. Nem is tűnt olyan nehéz feladatnak, azt gondoltam, egy ellenállás megoldja.

Van otthon néhány használaton kívüli CD olvasó és némelyiknek még külső jack dugója is van, saját hangerő szabályozóval. (Arról nem is beszélve, hogy három villanymotor is van mindegyikben, de erről egy másik posztban.) Azt gondoltam, a hangerő szabályozó pont jó lesz Eperkének.

A CD szétszerelése nem okozott problémát. Viszont nincs forrasztópákám, ami elengedhetetlen a szerelés további fázisaihoz. Szerencsére egy munkatársam készséggel felajánlotta, hogy megoldja ezt a problémát. A fizetsége a jack dugó volt :-)

Eperke beszélő elektronikáját a hasába varrták, de az elemtartó könnyen elérhető. Nem akartam szétbontani a szöveteket, ezért az elemtartóból távozó két vezeték egyikére helyeztettem a hangerő szabályozót.

A feladat remekül sikerült:

Az eredmény nem teljesen kielégítő. A csökkent áram mennyiség ugyanis nem csak Eperke hangerejére, de artikulálására és beszédsebességére is kihatott. Vidám éneke inkább hasonlít egy Down-kórban szenvedő masszív dohányos reggeli krákogására. A projektet ennek ellenére sikeresnek könyveltem el.

Ha megnézzük a retro számítógépek kedvelőit, akkor azt látjuk, hogy zömében nem mai fiatalok. A másik, ami feltűnhet, hogy már régóta ismerik egymást. Ennek ellenére vannak elszórt diaszpórák, ahol szinték imádják a régi vasakat, de mégsem tudnak más retro fanatikusokról. (Az internet korában ez különösen furcsa)

Mai történetünk hőse is egy ilyen diaszpórából szabadult. Kezdjük az elején. Az egyik PhD hallgatónk laptopján egyszer észrevettem egy hatalmas C64 matricát. Túl nagy jelentőséget nem tulajdonítottam neki, azt gondoltam, valami pózer. Később egy beszélgetés alkalmával azt kezdte mesélni, hogy a barátnőjével elölről elkezdtek játszani a C64-es játékokkal. Még ekkor is azt gondoltam, hogy biztos emulátoron, de kiderült, hogy eredeti vason szoktak játszani.

Nem is tudom, min lepődtem meg jobban: rajta vagy a barátnőjén. Viszont az igazi meglepetés csak ezután jött. A nagy sikerű, kultikus C64 játékok közül egyet sem ismertek. Nem tudták, mi az a Last Ninja, Mission impossible. Nem bombázták Moszkvát, de még az International Karate említése is csak fejcsóválást váltott ki belőlük. Ezt feltétlenül orvosolni kellett. Ez remek alkalom volt arra, hogy én is elővegyem a masinát és adjak nekik némi ízelítőt az aranykor remekeiből. Maverick még mindig remekül tette a dolgát.

A beszélgetés és a játékok másolása elindított benne valamit, mert hirtelen úgy érezte, hogy kell neki még több C64. Mivel a PhD ösztöndíj továbbra sem elég ilyen hobbira, ezért minden ismerősét faggatta. Végül különböző forrásokból 3 C64-re tett szert. Ezek közül a legszerencsétlenebbet mutatnám be.

Ez a gép ugyanis évek óta egy pajtában volt a földön. Minden nyílása tele volt földdel. A szaga alapján egér generációk lakhelyéül is szolgálhatott.

Még a billentyűket is ki kellett szedni a helyükről, hogy a kosz minden maradványa eltűnjön.

Aztán megláttuk a darazsat. El sem tudtuk képzelni, mennyi ideje lehetett a kosz fogságában.

Szerencsére volt még annyi szufla benne, hogy elrepüljön. Azóta még két forrásból kapott gépeket, de az összes közül ez az egyetlen, amelyik hiba nélkül működik. (Az egyik eleve hibásként volt meghírdetve, a másik pedig mintha NTSC szabányú lenne)

Az intézetünkből ketten is csatlakoztak a MinION teszt programhoz. A résztvevők mindegyike kapott egy MinION szekvenáló berendezést tesztelési célból. A kötelező tesztek lefuttatása után a készüléket arra használhatja az ember, amire akarja. Természetesen folyamatos visszajelzéseket és cikkeket várnak el cserébe.

Aki nem hallott a MinION-ról, annak röviden annyit kell tudnia, hogy ez egy USB-re köthető, egy pendrive-nél csak kicsivel nagyobb szekvenáló berendezés. Csak az érzékeltetés kedvéért: egy Illumina HiSeq 2500 akkora, mint egy hűtőszekrény.

Sajnos az IonTorrentnél láthattuk, hogy mire vezet, ha beindul a marketing gépezet és hangzatos szlogenekkel fedik el a hiányosságokat. Ezért a MinION esetében megpróbálok objektív képet festeni a készülékről és feltárni minden előnyét és hátrányát. Azt se felejtsük el, hogy ez még teszt fázisban van, nem termék. A hiányosságokat folyamatosan javítják.

A szerkezet késve érkezett, voltak gondok a számlázás körül, de végül megkaptuk. Az első kihívás a megfelelő számítógép konfiguráció előkerítése volt. A gyártó javaslata szerint egy Core i7-es processzorral, 8GB rammal, minimum 120GB SSD-vel, USB 3.0-val és 64 bites Windows 7-el felszerelt számítógép kell. Rövid időn belül kiderült, hogy ilyen gép nincs az egész intézetben. A helyzetet bonyolította, hogy a számítógép rendeléseket visszadobják a fejesek, mert miért lenne nekünk szükségünk arra. Megoldásként behoztam az otthoni gépemet, ami a processzort leszámítva megfelelt az előírásoknak.

A beüzemelés kisebb helyi látványosság lett. Mindenki ott nyüzsgött és tapizta a készüléket, mint majmok a monolitot. Természetesen én is.

Először a .NET keretrendszert kellett felrakni, mert a programok futásához kellett. Először egy tesztprogramot futtattunk, ahol megvizsgálták, hogy a hardver megfelel-e a minimum követelményeknek. Természetesen megfelelt, mert igaz, hogy AMD-m van, de nem a leglassabb. A tesztprogram már tartalmazott egy hibát, ezért az USB 3.0 meglétét nem tudta ellenőrizni.

Második lépésként az irányító programokat kellett telepíteni. A programcsomag tartalmazott egy Apache webszervert, Python értelmezőt, drivert és még a fene tudja hány komponenst. Telepítésük során a tűzfal majdnem meghalt, mert az összes alkalmazás át akart menni rajta. Ezt egyébként a dokumentáció is írta. A diagnosztikai üzenetek, logok és a szekvenáló egyéb paraméterei az interneten keresztül mennek vissza a gyártóhoz.

A telepítés után csatlakoztatni kellett a szekvenálót a számítógéphez és várni, hogy felismerje azt. Ez nem történt meg, helyette ismeretlen eszközként ott világított az eszközkezelőben Westbridge néven. Hirtelen mindenki tudta, mi ez az eszköz és honnan kell drivert szerezni hozzá, csak én nem, mert én bizony még nem hallottam róla. Az egyik ötlet az volt, hogy hoznak egy Machintos laptopot, és rádugják arra a MinION-t, mert az biztosan felismeri és a Macnek biztosan van drivere hozzá. A másik nagyszerű ötlet az volt, hogy ez biztos az alaplap része és ha telepítjük az alaplapi meghajtóprogramokat, akkor menni fog a MinION is.

Helyette megnéztük a gyártó fórumát (ami persze a nyilvánosság elől el van zárva) és kiderült, hogy a telepítő kicsomagolja a meghajtó programokat, csak valami rejtélyes oknál fogvan nem indítja el azt. Kézzel elindítva az eszközt felismerte az oprendszer. Még Mac sem kellett hozzá.

A második teszt egy olyan betét volt, ami nem tartalmaz minta befecskendező nyílást, de elektronikusan generál szignálokat, amintha szekvenálna a gép. Ezt gond nélkül lefuttattuk, majd jött a Metrichore.

Gyakorlatilag nem tudjuk, mi az a Metrichore. A gyártó annyit közölt, hogy mivel sokan kérdezik, hogy mi is ez, el fogják mondani. Annyit sikerült kihámozni, hogy ez egy program, ami a nyers szignál értékeket elküldi a felhőbe és nukleotidok térnek vissza. Tehát a teljes base calling Amazonos gépeket megy. Nem tudom, mennyire jó ötlet ez.

Az adatok gond nélkül eljutottak a felhőbe, de nem hullott vissza fasta fájlok, csak egy szép nagy exception. Írtunk nekik levelet a hibaüzenettel, amire annyit válaszoltak, hogy mások is tapasztaltak ilyen hibát és dolgoznak rajta.

Összességében elmondható, hogy az összes trendi technológiát bele akarták zsúfolni a termékükbe. Amazon AWS, Node.js, Python, stb. A rendszer még nyögve nyelős, mint minden prototípus. Kicsit sokat akartak markolni. A koncepció viszont jó. Végezetül egy kis videó:

MinION first test run from TravisCG on Vimeo.