Amiga Klubba azért jó járni, mert ott is programozókkal beszélhet az ember, de sokkal kötetlenebb módon. Itt nem kell félni a vezető programozó haragjától, ha egy technológiáról más a véleményünk. Elszidhatunk bármilyen számítógépet, bármilyen programozási nyelvet, még akkor is, ha napi szinten dolgozunk vele.

Ezek a kifakadások nem jelentik, hogy az adott technológia ellenségei lennénk. Nyilván nem azért fejlesztették ki őket, mert teljesen feleslegesek, de ott vannak a technológia függők. Ők először ingyen kapnak egy keveset az anyagból. Ízlelgetik, nem tetszik nekik, de látják, hogy a többiek szívnak belőle, ezért ők is megkóstolják. Ekkor megváltozik valami a fejükben. Már nem úgy látják a világot, mint azelőtt. Hirtelen egyre többet és többet akarnak, majd a beosztottak azt veszik észre, hogy főnökük már minden projektbe belecsempészik az anyagból. Már nem szívja, hanem lövi magának. Nem tud lejönni róla. A technológia lesz az új szerelme. Csak róla beszél.

A kirohanások ezek ellen szólnak.

Furcsa, de az Amiga Klubban az Amigák eléggé háttérbe vannak szorítva. Szinte nem múlik el alkalom, hogy valaki ne hozna valami hardvert, hogy megszereljék, beállítsák, vagy csak kipróbálják, de sokkal többször látom, hogy inkább egymás telefonjait vizslatják. Hiába, egy telefont könnyebb elhozni, mint egy Amigát és hozzá a tápegységet. Bizalmasan már egyik tag megemlítette, hogy elővenni az Amigát elég macerás, hiszen kevés embernek van annyi helye, hogy mindegyik alkatrész elől lehessen.

A legjobb mégis az volt, amikor az egyik Amigo elmesélte, hogyan készített demot. Már Functionon is láttam, hogy a demókészítési stratégiája teljesen egyedi. Egyesek mindent maguk állítanak elő, mások demotoolokat használnak, ő viszont demoprogramozókat használ. A stratégia egyszerű: Tölts le egy forráskódot, hekkeld szét annyira, amennyire csak lehet. Mikor már teljesen működésképtelen, csináltasd meg valakivel. Ha az illetőnek elfogy a türelme, keress másik embert.

Mostani akciója tovább megy egy fokkal. Azt, hogy melyik irányba, nehéz megmondani. Letöltött egy nyílt forrású demót, majd elkezdte kicserélni a tartalmakat. Lecserélte a képet, a zenét, természetesen olyanra, amit szintén a gugli köpött ki. Valahogy nem nyűgözött le a teljesítménye, ezért megpróbált meggyőzni a munka komolyságáról. A netről letöltött képeket Gimppel át kellett konvertálnia, hogy normálisan jelenjenek meg. Így már mindjárt más! Javasoltam neki, hogy írok egy programot, amivel random módon kicserélheti a tartalmakat. A véletlenszám kezdőértékét az szóköz billentyű lenyomásának hosszával fogom beállítani. Én csak segíteni akartam, de nem kért belőle.

Kezdő bioinformatikai ismeretterjesztő posztjaimat ott hagytam abba, hogy bemutattam az Emboss programcsomagot. A programok viszont nem érnek semmit, ha nincs adat, amin fussanak, ezért most az adatbázisokról tartok egy rövid ismertetőt.

A klasszikus felosztást (elsődleges és másodlagos adatbázisok) meghagynám másoknak. Ezekről az unalomig ismételve lehet információt találni. Én inkább egy másik, gyakorlat orientált felosztást javasolok:

Nem struktúrált adatbázisok

Nem struktúrált adatbázisoknak hívom azokat, ahol minden információ megvan valamilyen formában, ami érdekelheti a felhasználót, de ennek megtalálása, kiválogatása plusz időt és energiát igényel. Alapvetően két okra vezethető ez vissza:

Ömlesztett adatbázisok

Ömlesztett adatbázisoknál a legfontosabb cél, hogy az adat megtalálható legyen az adatbázisban, nem számít milyen módon. Legtöbbször nincs sem kurátor, sem kontroll, az emberek gyakorlatilag bármit feltölthetnek. Ilyen például az NCBI. Minden megvan, de ember legyen a talpán, aki el tudja választani a hasznos információt az értéktelentől. Az ilyen jellegű adatbázisok nem mentesek a redundanciától. Itt az adatok letöltése nem okoz problémát, inkább a releváns információ kiszűrése a nagy feladat.

Rendezetlen adatbázisok

A rendezetlen adatbázisok struktúrált adatbázisként kezdték életüket. Megpróbálnak értelmes és hasznos segítséget nyújtani, de struktúrájuk az idő folyamán elavul, és a kompatibilitás megőrzése érdekében vagy más okból az adatbázis szerkezetén nem változtatnak. Ennek az lesz a következménye, hogy megjelennek a több értelmű mezők (pl. a 2007 előtti adatoknál az első oszlop exont jelöl, egyébként meg intron), vagy olyan toldozott rekordok, amelyek már nem tudják követni a névkonvenciót (már ha volt névkonvenció a korai verziókban). Erre a legjobb példa a BIC. Ha ezt a fajta adatbázist használjuk, legyünk nagyon körültekintőek, mert csapda les ránk minden rekordból.

Struktúrált adatbázisok

A struktúrált adatbázisokban könnyedén megtalálhatunk mindent, és akár egyszerűbb elemzéseket is végezhetünk a honlapjukon. A struktúrált adatbázisok legtöbbször specializáltak, de szerencsére akadnak átfogó jellegűek is.

Gyűjtemények

A gyújtemények azért tudják megőrizni struktúrált jellegüket, mert nagyon kevés járulékos adatot tartalmaznak. Szinte csak a legfontosabb információkat gyűjtik össze. Jó példa erre az IMGT, ami szinte csak a HLA allélok szekvenciáit sorolja fel, vagy a miRBase, ahol minimális annotáció mellett az ismert kisRNS-ek szekvenciái láthatóak. A rekordok könnyen átláthatóak, de legtöbbször további feldolgozást igényelnek. Sokszor a megtalált információt más forrásból kell kiegészíteni. A struktúrák puritánok, kereszthivatkozás csak elvétve akad.

Portálok

A portálokon nem csak az adatok találhatóak meg, hanem webes eszközök garmadája is, hogy kényünk-kedvünk szerint feldolgozzuk őket. Nem ritkán API is tartozik hozzájuk, hogy megkönnyítsék a felhasználók életét. A portálok nyújtják a legtöbb kényelmi funkciót. Hátrányuk, hogy az adatbázis integritásának megőrzése érdekében változtatják az API-t és az adatbázis szerkezetét. (Ha nem így tesznek, rövid időn belül rendezetlen adatbázisokká válnak.) Ezért egy rekord elérésének módja a verziószám függvényében változhat. A leghíresebb példa az EnsEMBL.

Egyéb tudnivaló az adatbázisokról

Az első és legfontosabb tudnivaló, hogy az információ lehet téves. Csak azért, mert egy rekord állít valamit, nem biztos, hogy az a valóságot tükrözi. Mindig olvassuk el az adatbázishoz tartozó cikket vagy dokumentációt, hogy jobban megértsük, mivel is dolgozunk. Sok esetben a rekordok tartalmaznak olyan mezőket, amelyek leírják, az adat mennyire tekinthető megbízhatónak.

Ha ismeretlen adatbázissal kezdünk el dolgozni, nézzünk utána, mikor frissítették utoljára, milyen gyakran tartják karban. Ha azt látjuk, hogy egy adatbázist csak egy cikk kedvéért készítettek, majd sorsára hagytak, azt nyugodtan felejtsük el.

Egy adatbázis annyira jó, amennyire a forrása. Például ha látunk egy nagyon tetszetős portált, de kiderül, hogy a bemenete egy ömlesztett adatbázis, amiből egy bugos program segítségével szűrnek, akkor hiába a tucatnyi kényelmi funkció.

Sok szerencsét az adatbázisokkal! Szükség lesz rá.

Ha jó demót akarunk készíteni, akkor először egy jó motor kell. Motor alatt azt értem, hogy az alacsony szintű kép/hang megjelenítést (OpenGL) el akarom választani a jelenetektől. Eddig ha jeleneteket készítettem, akkor írtam egy függvényt, ami rengeteg OpenGL utasítást tartalmazott, majd azok paramétereit változtattam. Mostantól viszont a paraméterek külső fájlból fognak érkezni, tehát olyan kódhalmaz kell, ami a lekezeli az összes felmerülő képi hatást.

Ez viszont véget nem érő munka lenne, hiszen mindig van mit hozzáadni a kódhoz, hogy szebb legyen a látvány, ezért az "összes felmerülő" képi hatások számát 1-re redukálom. A fájlból beolvasott paramétereket is kihagyom, valamint FreeGLUT-ot használok a Windows API helyett. Ezek a végleges demó motorban természetesen ki lesznek cserélve.

Miért dolgozok kétszer? Miért nem írom meg elsőre a végleges verziót? Ez pusztán pszichológia. Ha elkezdek mindent leprogramozni, sokára fogom meglátni, mi az eredménye a munkának. Ráadásul ismeretlen operációs rendszeren, kvázi ismeretlen programozási nyelvvel dolgozok. Biztos rengeteg hibát és illogikus lépést fogok kódolni, amit egy végleges rendszerben nehezebb kijavítani. Ha már most látom, hogy a munkámnak van eredménye (valami villog a képernyőn), akkor szívesebben ülök le másnap is a gép elé. Tehát tekintsünk úgy ezekre a megkötésekre, mint az építkezésen az állványzatra. Ha kész a ház, az állványokat elbontják.

GLEW

Nem mehetek el szó nélkül amellett, hogy Linux alatt mennyire könnyű OpenGL-t programozni. Gyakorlatilag egy #define segítségével használhatom a legújabb jellemzőket. Windows alatt természetesen kézzel definiálhatom magamnak az összes függvényt, amit használni akarok, vagy használhatom a GLEW-et. Alapvetően nem szeretem a burkoló osztályokat, de a franc fogja begépelni azt a sok ostoba sort. Helyette:

glewInit();


Utána már használhatom a jól ismert OpenGL 4.x utasításokat.

FreeGLUT

Azért C++-ból használni a FreeGLUT-ot nem olyan egyszerű. Van egy demo osztályom, Show() metódussal. A terv az volt, hogy ez a metódus választja ki melyik jelenetet kell lejátszani, ezért naivan a glutWindowFunc-nak át akartam adni ezt a metódust. Sajnos ez nem megy, csak függvényt fogad el. Ez sajnos azt eredményezi, hogy kell egy burkoló függvény. A demo osztályból eltávolítottam mindent, ami az ablak nyitásáért felelős. Röviden így néz ki a main függvény:

glutInit(&argc, argv);
glutCreateWindow("demo");
// More glut related functions

demo = new cybernetic::Demo(width, height);
demo->setMusic("data/music/test.mp3");
// More demo related settings

glutDisplayFunc(show);
glutMainLoop();


Örültem volna, ha ezt a sok glut függvényt berakhatom a demo osztályba, de ez van. A másik probléma, hogy a glutMainLoop után kellene beilleszteni a destruktorokat. A dokumentáció szerint a FreeGLUT-ban van egy glutLeaveMainLoop(), feladata pedig az, hogy a glutMainLoop-ból kilépjen, hogy utána én felszabadíthassam az erőforrásokat. Csakhogy azt sem az internet, sem a dokumentáció nem mondja, hogy ehhez be kell tölteni a freeglut_ext.h fejlécet. Linux alatt persze van grep, másodpercek alatt megtaláltam volna.

void keyboard(unsigned char key, int x, int y){
    if(key == 27){
        // Exit in a nice way
        glutLeaveMainLoop();
    }
}


Ha a glutKeyboardFunc megkapja ezen függvény címét, akkor Esc-re kilépünk, felszabadítjuk az erőforrásokat és mindenki boldog.

cybernetic::Demo

Úgy döntöttem, minden demoval kapcsolatos osztályt a cybernetic névtérbe helyezek. Ebből is a legfontosabb a Demo osztály. Ez inicializálja az OpenGL-t, GLEW-et, betölti a zenét, a jeleneteket, majd lejátssza őket. Az implementálást most még nem osztom meg, de a végleges demóval szállítani fogom a forráskódot is, ahogy eddig is tettem. Majd akkor röhöghet rajtam mindenki.

Már a fenti részleten is lehet látni, hogyan kell használni. Ami ott nem látszik, az a jelenetek hozzáadása:

FirstScene scene1 = new FirstScene(0, 1000);
demo->addScene(scene1);


De mi az a FirstScene?

cybernetic::Scene

Ez az ősosztálya minden jelenetnek. Két állandó tagja van, két időpont, ami a lejátszás kezdetét és végét adja meg. Ezek egyébként a konstruktor paraméterezésében is helyet kapnak. Van egy virtuális display() metódus, ami megjeleníti a tartalmat. Most még minden Scene osztály kézzel készül, a jövőben ezt kell kiváltani valami DSL-el. A FirsScene az előző példából nem más, mint egy teszt osztály, amivel azt nézem, a demo osztály jól vált-e a jelenetek között. Természetesen még nem vált, de ennek oka egy másik osztályban keresendő.

cybernetic::Music

Annak ellenére, hogy nem szívlelem a burkoló osztályokat, az nem volt kérdéses számomra, hogy a zene lejátszásához valami külső eszközt fogok használni. Kiválasztani nem volt nehéz. Letöltöttem 5 demót, amit technológiailag előremutatónak tartok és megnéztem, mit használnak. Két választás bontakozott ki előttem: bass.dll vagy fmod.dll. A mennyiség (és a C++-os API) az fmod javára döntött. Ingyenesek ingyenes programokhoz, könnyű használni mindkettőt. Ha kellően tapasztalt leszek az fmod használatában, talán arról is írok egy bejegyzést. Most viszont csak annyit kell tudni róla:

FMOD::System *system;
FMOD::Sound *sound;
FMOD::Channel *channel;

FMOD::System_Create(&system);
system->init(1, FMOD_INIT_NORMAL, 0);
system->createStream(filename, FMOD_DEFAULT, 0, &sound);
system->playSound(FMOD_CHANNEL_FREE, sound, 0, &channel);

Készítettem egy osztályt, ami elindítja a lejátszást, és lekérdezhető a zene aktuális pozíciója. Ez utóbbi valami miatt hibás, ezért nem működik a jelenet választás. Most a hugi04-ből kiszedett zenét játszik le.

cybernetic::Shader

Már csak erről az osztályról nem beszéltem. Alapvetően eddig ugyan az, mint a régi kódom shader betöltője, csak osztályba csomagolva. A hibás shadernél már kiabál, ami jó.

Összegzés

Még sok tennivaló van vissza, míg ez a kódhalmaz valami értelmeset fog produkálni, de már látszik, hogy az eddig befektetett munka kezd megtérülni. Arról nem is beszélve, mennyi új ismeretre tettem szert C++-al kapcsolatban. Búcsúzóul itt egy kép, amit már az új motor generált.

A piros háttérszínnek különleges jelentése van. Így szoktam ellenőrizni, hogy működik-e az OpenGL inicializálás. Ha ugyanis a jelenettel van probléma, akkor piros az egész képernyő, de ha már az OpenGL inicializálása sem megy, akkor fekete.

Figyelem! Következő reklámunk virtuális blogbejegyzést tartalmazhat.

Sok könyvünk van, a falon pedig sok hely. A megoldás nyilvánvaló, a megvalósítás kevésbé. Első körben a nagyobb áruházakat néztük meg, mint amilyen az Ikea, BricoStore, Parktiker, Obi. Az Ikeával az a bajom, hogy az ott található termékeknél a funkcionalitás másodrendű. Az elsődleges az ár vagy a kinézet. Példának okáért láttunk gyönyörű polcokat, amelyeknek a terhelhetősége 2kg. A másik bajom, hogy úgy néz ki minden kiállítási tárgy, mintha egy lakás része lenne, és sok vevő úgy is viselkedik, mintha otthon lenne.

Szerencsére olyan különleges igények merültek fel a polcokkal kapcsolatban, hogy egyetlen lakberendezési áruház sem volt képes kiszolgálni azokat. Ilyen volt többek között, hogy lehessen rájuk pakolni és szépen nézzenek ki. Ez utóbbi igény szinte napról napra változott. Egyszer a Z alak, másszor a doboz forma tűnt a nyerőnek, de számomra ez csak részletkérdés volt, mert már tudtam, hogy én fogom elkészíteni.

Végezetül a doboz forma lett a nyerő. A tervek alapján egy lapszabászatban megrendeltük az MDF lapokat, az élfóliát és a tartóelemeket. A lapok elkészültével az eladó megkérdezte, hova pakolják azokat. Fogtam egy hatalmas sporttáskát és mutattam, hogy ebbe bele. A fickó nem hitte el, hogy elbírom őket, de megnyugtattam, ha így lesz, akkor kettőt fordulok. Végül megsajnált és felajánlotta, hogy munka után elhozza, úgyis útba esik neki. Egy kihívással kevesebb lett arra a napra.

Otthon a Tesco gazdaságos kínai fúrógépemmel nekiláttam összeszerelni a kockákat. A lapokat először 4-es fúróval megfúrtam, majd 4x50-os facsavarokkal összecsavaroztam. Ez egyszerűen hangzik, de gyakorlatilag az volt a problémám, hogy nem tudtam merőlegesen rögzíteni a lapokat a fúrás és csavarozás idejére, mert nem volt semmi felszerelésem. Végül a még össze nem szerelt lapokat használtam támasztéknak.

Lefektettem egy lapot, ez volt a munkaasztal. Erre a lapvastagsággal elcsúsztatva ráhelyeztem az egyik lapot. Támasztéknak erre a lapra tettem még 2 másik lapot, majd ennek a három lap vastag falnak támasztottam a merőleges lapot. Ez elég tartást biztosított az összeszerelés idejére. A csavarozáson felül ragasztót is nyomtam a felületek közé, hogy növeljem a kötés erejét.

A módszer segítségével hatékonyan illesztettem össze a dobozokat, egészen addig, míg a fúrógép el nem kezdett furcsán viselkedni. Ha elfordítottam a gépet, abbahagyta a fúrást. Ha visszaállítottam eredeti helyzetébe, ismét működött. Valószínűleg elkoptak a motor szénkeféi. Még két lyukat ki tudtam fúrni, majd a berendezés többet nem indult el. Az ST/D13-320 felmondta a szolgálatot.

A polcszerelés csúszott a következő napra. Elmentem a BricoStore-ba és megszereztem a méltó utódját egy Bosch PSB 650 RCE képében. Most legalább a spórolt pénzre sincs gond. A gép ereje nagyon meglepett. Az első csavart sikerült úgy becsavarozni, hogy a fej lerobbantotta a lap sarkát.

Apró illesztési hibáktól eltekintve egészen jól néz ki. Az összeszerelés után következett az élfólia. Egy vasaló segítségével vittem fel, ügyelve rá, hogy egy irányból haladjak, szép lassan. Pamut fokozatra állítottam a vasalót, mert ha túl meleg, akkor nem fog rendesen odaragadni.

A tartófülek felcsavarozása csak hosszú és unalmas volt. Először egy kicsi, pár milliméter mély lyukat fúrtam, azért, hogy a füleket rögzítő csavar ne mozduljon el, majd csavaroztam. A Bosch teljesítményszabályozója nagyon hasznosnak bizonyult, amikor a csavarozás és a fúrás között váltogattam.

A falra történő felhelyezés bizonyult a legnehezebb feladatnak. Szerettem volna, ha vízszintesen állnak, ezért a kész polcokat a falnak szorítottam és a fülek mentén megjelöltem, hova kell majd a lyukakat fúrni. Sajnos az egyik fal csak 5-6 cm vastag, ezért nem mertem nagyon mély lyukakat fúrni, nehogy a túloldalon krátereket hagyjak hátra. Sajnos nem akasztós füleket vettem, hanem olyanokat, amelyeken csak egy lyuk van, ezért a polcokat úgy lehetett csak felcsavarozni, hogy valakinek tartani kellett a polcokat, míg én behajtottam a csavart a falba, amivel rögzítettem azokat. Csakhogy nem volt senki, aki segített volna tartani. A kisebb polcokkal nem is volt gond, mert egy kézzel meg tudtam tartani őket, de az egyik nagyjából 15 kg lehetett, amit ugyan meg tudok tartani, de hajszálnyit pozicionálni már nem. Jött a B terv. A még fel nem szerelt egyéb polcokkal és a kezem ügyébe eső könyvek segítségével rögtönzött alátámasztást eszközöltem. Úgy ingott, mint valami keljfeljancsi. Máig nem értem, miért nem omlott össze a tákolmány, de végül sikerült felrakni a nehezebb darabokat is.

A hálószobába kész polcokat vettem és derékszögű tartókkal rögzítettem. Ezeket csak csavarozni kellett. Csekély súlyuk miatt nem volt gond a felszerelésükkel.

Az írók blogjukban igyekeznek mindig a legjobb tulajdonságaikat hangsúlyozni. Főleg a szakmai blogok hemzsegnek a "hú, de király vagyok" típusú bejegyzésektől, amire rátesznek egy lapáttak, hogy kamu felhasználói nevekkel bejelentkeznek és az egekig magasztalják magukat. Mai bejegyzésemmel ezzel a szokással fogok szembe menni és leírom, hogyan döntöttem meg az egymás után hozható rossz döntések rekordját.

A történet két héttel ezelőtt kezdődik, amikor is egy munkaállomásra Kubuntut telepítettem, majd beállítottam rajta az összes teljesen felesleges csicsát. Volt zseléablak, task lapozás 3D-ben, stb. Azért, hogy egyszerűbbé tegyem az életem, mindent egyetlen partícióra raktam. A dolgok akkor kezdtek rosszra fordulni, amikor megkértek, hogy több háziállat poolozott Solid szekvenálásait futtassam egy olyan illesztőprogrammal, amit már nagyon jól ismerek... Ezt ugyanis az előző munkahelyem fejlesztette. Mondtam, hogy szerintem ez rossz ötlet, de állították, hogy nagyon jó eredményeket produkál, használjam. Ez volt az első rossz döntés.

A programot 711 referencia fájlon kellene futtatni, de ez a nyomorult program nem kezeli a multifasta szekvenciát. Emlékszem, annak idején többször is említették a fejlesztők, hogy ezt a problémát megoldották, de valami miatt még mindig nem olvassa be az adatokat, csak dobálja a kivételeket. Maradt a hekkelés. Lefuttattam külön-külön a referenciákon és a végén egyesítettem a fájlokat.

A második hiba az volt, hogy nem foglalkoztam az átmeneti állományokkal, amiket az illesztőprogram hátrahagy, mint kutya a piszkát. Elindítottam a szép Kubuntumon és vártam a csodát. Közben jöttek a frissítések és a rendszer jelentette, hogy szeretné újraindítani a gépet. Mivel futott az illesztés, csendre intettem.

A mai napon elszaporodtak a parajelenségek. A SceneSat rádiót nem tudtam hallgatni valami rejtélyes okból kifolyólag és a nyomtatási feladatok is szőrén-szálán eltűntek. A zenehallgatást megoldottam YouTube-val, de a kutatási tervek miatt mindenképp nyomtatnom kellett. Azt gondoltam, biztos a frissítések igénylik az újraindítást, amiatt van ez a sok megmagyarázhatatlan. Leállítottam az illesztést és elkövettem a harmadik hibát, újraindítottam.

Attól a pillanattól fogva nem volt zseléablak, nem volt pörgő kocka, nem volt semmi, mert nem tudtam elérni a /tmp-t. Nem kaptam semmit, csak egy BusyBox konzolt. Nesze, javítsad ki a hibát. Persze nem estem kétségbe, sejtettem, hogy a felhalmozódott nagy számú, illesztésből visszamaradt átmeneti állomány okozza a galibát. Beléptem a /tmp-be, majd elkövettem egy újabb hibát, kiadtam az ls parancsot. Onnantól konzol sem volt. Nyomtam Ctrl+C-t, Ctrl+D-t, semmi nem segített, csak az újraindítás.

Másodszor már óvatos voltam, nem adtam ki ls parancsot, helyette rm *-t adtam ki. Csak később tudatosodott bennem, hogy ez ugyan úgy leterheli a rendszert, mint egy ls, hiszen végig kell szaladnia a fájlneveken. Már nem is tudom, hányadik hülyeséget csinálom, de még nincs vége. Gyors számolást végeztem. Ha van 63 minta, 711 referencia, a program szétdobálja a bemeneti állományokat 8 szálnak, minden szál készít minimum 1 eredmény fájlt, könnyen elérjük a 3,5 millió fájlszámot.

Végül BusyBox-ban a /tmp/ize alá felcsatoltam a problematikus partíciót, majd kiadtam a find /tmp/ -print -exec rm -r {} \; parancsot. Az olvasóim bizonyára látják, hogy mit szúrtam el, de én csak akkor láttam, mikor feltűntek a /tmp/ize/usr/share bejegyzések. Elkezdtem a rendszer könyvtárakat legyalulni! Először ordítottam egy nagyot, majd megpróbáltam megszakítani a folyamatot. Végül a gép kikapcsolása lett a dologból. Persze 5mp-ig kell nyomva tartani azt a nyomorult gombot, és ez alatt elvesztettem még ki tudja, mit.

Kernelem nem volt, /etc nem volt, csak a /home állt még szerencsére. Akár mennyire is nem akartam, újratelepítés lett a dologból. Már csak az volt a kérdés, hogyan telepítsem újra a rendszert anélkül, hogy felül ne írnám az adataimat. Mert hiába van 4 Tb tárhelyem, nincs annyi szabad hely, hogy biztonsági másolatot csináljak. Ezért elindítottam a Kubuntut Live DVD módban, felcsatoltam a rendszer partíciót. Ezzel megakadályoztam, hogy nekiálljon a partíciókat állítgatni. Manuális partícionálást állítottam be, és beállítottam, hogy hova csatolja a partíciókat. A formázást nem engedélyeztem. A telepítő figyelmeztetett, hogy nem letörli a rendszer könyvtárakat. Ezen csak nevettem, hiszen én már előtte letöröltem mindent.

A csomaginformációk valami csoda folytán megmaradtak, ezt a telepítő felismerte és elkezdte kijavítani őket. Újraindítottam, és ugyan úgy semmit nem működött. A /tmp továbbra is elérhetetlen volt a gép számára. Az fsck -f szerint minden a legnagyobb rendben volt. De akkor miért nem tudom elindítani a gépet?

Végül leredukáltam az adatok számát, egy USB-s tárhelyen kerestem annyit helyet, hogy megcsináljam a /home biztonsági mentéseit. A mentést cp -p-vel hajtottam végre, hogy a jogosultságok és idők megmaradjanak, majd teljesen legyalultam a gépet. Újratelepítettem minden nulláról. USB 2.0 vs 110Gb rulez.

Újratelepítés után ugyan azt a user id-t adtam meg, mint régen (bár alapból 1000-el kezd, tehát nincs jelentősége), ezért a jogosultásokkal nem volt gond. Visszamásoltam a 110Gb-ot, majd úgy döntöttem, a nap hátralevő részében nem akarok számítógépet látni.

Grassal elhatároztuk, hogy idén valami nagy durranással fogjuk meglepni a közönséget. Az ötlet már jó ideje érlelődik bennünk. Vázlatosan már a Wayang után megfogalmazódtak bennünk, de azt is tudtuk, hogy a programozói tudásom még nincs azon a szinten, hogy bele merjünk vágni.

Az azóta eltelt évek során annyi magabiztosságot szereztem, hogy úgy érzem, elég időráfordítással meg tudjuk csinálni, és ami a legfontosabb, úgy tudjuk megcsinálni, hogy azt a demoscene közösség is díjazni fogja. Legalábbis most még így gondoljuk.

A nagyszabású ötletekhez jó tervezés kell. Először az időpontot tűztük ki. A tervek szerint a 2013-as Assemblyre adjuk be, ami valamikor augusztusban lesz. Ez elég idő ad nekünk, hogy a felmerülő nehézségek esetén is tartani tudjuk az ütemtervet. (Nehézségek pedig adódtak, például új munkahelyet kellett keresni). Ennek ellenére úgy döntöttünk, hogy a minőségből nem engedünk, ezért ha nem készülünk el, akkor nem adunk ki valami félig kész művet, hogy utána Pouet.net-en csak hümmögjenek rá.

A második fontos lépés, hogy meghatározzuk, milyen eszközökkel tudunk hatékonyan dolgozni. Olyan eszközökre van szükség, amivel Grass gyorsan meg tudja tervezni a jeleneteket. Én látom, hogy miként képzeli el azokat, és hogyan kell megjeleníteni. Harmadrészt szakítani kell azzal a hagyománnyal, hogy az én tudásom limitálja a grafikát.

1. 3D szerkesztő

Kellett keresni egy olyan 3D szerkesztőt, amit tetszés szerint tudunk bővíteni saját egységekkel, Grass könnyen tudja használni, stabil. A saját szerkesztő írását rögtön elvetettük, mert nem akarjuk az életünket arra áldozni, hogy a saját fejlesztésű szerkesztőnket debuggoljuk. Épp elég lesz a demóban megkeresni a hibákat.

Próbáltam a Blender mellett kardoskodni, mert fut Linux alatt, ingyenes és Pythonnal könnyen lehet szkriptelni. A Biopunk című demónkban is használtuk, ennek ellenére Grass megvétózta. Mivel ő fogja használni, ezért nem tehettem semmit. 3D Studio volt a másik javaslatom, mert igaz, hogy Windowsos, de azt még én is tudom használni. Grass viszont a Cinema4D-t használta szinte mindenhez, tehát nekem kellett alkalmazkodni. De ha már Ciname4D-t használunk, akkor a verziószámot rögzítettem 13-ban, ugyanis már ezt is lehet Pythonban szkriptelni.

Ez viszont egy újabb akadályt gördített elém. A fejlesztést át kellett tennem Windowsra.

2. Demo motor

Ha már Windows alatt készül a tartalom, célszerű a demó motort is az alá fejleszteni, mert az elkészült tartalmakat anélkül lehet megnézni a demóban, hogy újra kellene indítani a gépet. (Virtuális gépben az OpenGL támogatásról ne beszéljünk) A másik ok, hogy Windowst használunk, hogy azt szeretnénk, ha sok emberhez eljutna az üzenet. Ezért töltjük fel YouTube-ra is a demókat.

A Cinema4D-ből tehát a jeleneteket be kell juttatni a demóba. Erre négy stratégiát gondoltam ki:

1. Metaprogramozás

Legeneráljuk a C forrásfájlt, majd lefordítjuk. Ez nekem egyszerű lenne, mert eddig is forrásfájlba voltak bedrótozva a jelenetek, csak shadereket, textúrákat, modelleket, zenét töltöttem be. Az időzítés kódból ment. Hátránya, hogy Grass gépére is fejlesztőkörnyezetet kell telepíteni. A fordítás hosszú, ha hiba van a rendszerben, akkor a felderítés és javítás hosszadalmas. (Grass ír e-mailt, én két nap múlva elolvasom, nem értem, mi a hiba, visszaírok)

2. Szkript nyelv

Generálunk egy szkript nyelvet, amit nem csak az erőforrásokat írja le, hanem programlogikát is. A demó egy általános megjelenítő alkalmazás lenne, csak egyszer kellene lefordítani, utána akár az én segítségem nélkül is mehetne a demógyártás. De azért a szkript értelmező fejlesztése idő. Habár ez lenne a legoptimálisabb megoldás, most valami egyszerűbb megoldás kellene, mert egy jó szkript nyelvet tervezni nem könnyű. Ráadásul még Windows alatt is meg kell tanulnom fejleszteni, ott is lehetnek nem várt problémák.

3. DSL

Igazából a szkript is DSL lenne, de én itt most csak leírónyelvet készítenék, nagyon szigorú szintaktikával. Az ötlet azért merült fel bennem, mert ha megnézzük a demóim forráskódját, akkor azt látjuk, hogy minden jelenetnek van egy kezdete, vége és egy paraméter (vagy több), ami ez idő alatt változik. A változás is általában lineáris. Nincs szükség komoly kalkulációkra, ráadásul a megjelenítés nagy részét shaderek végzik. Vagyis kisszámú rögzített paraméter van a CPU kódban (milyen modellt rajzoljunk ki, hogyan álljon a kamera), a GPU-ba az idő, textúrák és a vertexek mennek át, a többi kalkuláció ezeket használja fel. Erre egy leírónyelv elég. XML-t csak azért nem akarok használni, mert egyszerűbb szintaktikát szeretnék.

3. Bővítmények

A fejlesztések száma nagyobb lesz, mint a korábbi demóink esetén, mert nem csak a demó kódját kell lefejleszteni, hanem a Cinema4D-hez is kell bővítményeket írni. Első lépésben egy export plug-in kell, amivel az jelenetet DSL-é alakítjuk, de valószínű kelleni fog néhány render plug-in, ha valami egyéni látványvilágot akarunk létrehozni, és fontos, hogy ugyan az jelenjen meg a szerkesztőben, mint a demóban.

4. Kihívás faktor

Az összes demónkban volt valami, ami nekem kihívást jelentett fejlesztési oldalról. Már eddig is jó sok újítás lesz. Új operációs rendszer, támogató szoftverek, de ez még nem kimondottan kihívás. A for ciklust nem kell máshogy megírni Windows alatt sem, támogató szoftverek eddig is mindig kellettek. Már a legelső demómhoz is kellett SVG konvertáló. Valami olyan kihívás kellene, amiből később profitálhatok. Ezért úgy döntöttem C++-ban fogom megírni.

Jó, tudom, C++ a Gonosz, nincs jövője, felesleges, stb. De elég sokan használják, nem tehetem meg, hogy teljesen ignoráljam az életemből. Már eddig is kódoltam kisebb dolgokat C++-ban, de nincs elég tapasztalatom benne és nem profihoz méltó hozzáállás, hogy ignoráljunk valamit, csak azért, mert egy bizonyos programozási nyelven íródott.

Végszó

Tehát a nagy mű készítése elkezdődött, a folyamatról és a közben felmerülő problémákról és azok megoldásáról írni fogok

A cégnél az utolsó napokat töltöm. Eddig bármilyen okból is kényszerültem munkahelyet váltani, az utolsó napokat igyekeztem kellemessé tenni. Ezt nem nehéz megtenni, hiszen feladatot alig kap az ember, szabadon járhat-kelhet, mint egy szellem. A munkatársak már átnéznek rajta, de azért résztvesz a megbeszéléseken, elmondja a véleményét.

Az utolsó napokon ezért olyasmiket szoktam csinálni, ami valamennyire a munkához kötődik, de normális körülmények között eszembe sem jutna megcsinálni.

Ilyen volt például a szárazjeges durrogatás a laborban. Egy prof hazatért külföldről, és még a családja az új házat tekintette meg, amit vettek, ő a biológiai mintáit féltve a laborba jött. Segítettem neki a mintákat betenni a fagyasztóba, amiért cserébe kaptam több kiló szárazjeget (abban szállították a mintákat), hogy dobjam ki. Kidobni? Nem. Durrantani? Oh igen! Megtöltöttem velük pár Eppendrof csövet, majd ahogy gázzá vált a jégdarab, lerepítette a cső kupakját. Nagyon tetszett. Kerestem valami nagyobbat. Egy filmtekercs műanyag dobozát. Ez elég jó folytást biztosított. Telepakoltam szárazjéggel, majd kitettem a folyosóra, hogy mások is jól szórakozzanak.

Közben megjött egy barátom, akivel beszélgetni kezdtem. El is felejtettem a meglepetést, ezért mikor a gáz lerepítette a doboz kupakját, rettenetesen megijedtem.

Egy másik alkalommal egyszerűen csak hálózatban játszottunk. Akkoriban nem volt otthon internetem, ezért ez élmény számban ment. Akkor még a Nexuiz is ingyenes volt...

Most is komoly fejtörést okozott, mivel üssem el az utols napokat, egészen addig, amíg rá nem találtam a BackTrack Linuxra. Gondoltam jó ötlet lesz letesztelni, mennyire biztonságos a Wi-Fi router. Az airmon-ng-t használtam a tutorialok alapján. Feleslegesnek tartom leírni ugyan azt, amit a YouTube videókon is látni lehet, inkább a tapasztalataimat közlöm.

Amikor elkezdtem lementeni a hálózati forgalmat, fontos, hogy legyen valaki, aki kapcsolódik ez idő alatt, különben nem lesz mi után kutatni, ezért egy olyan napot választottam, amikor mindenki megbeszélésre jött. Volt elég gép a neten. A lementett forgalmon lefuttattam mindkét kulcsszó adatbázist, de a program nem találta meg a jelszót. Egyébként a teljes futási idő kb. 3 óra volt egy laptopon (Core i5 proci, 8Gb memória).

Kicsit elcsüggedtem az ereményt látva. Azért, hogy legyen egy kis sikerélményem, készítettem egy saját kulcsszó adatbázist, amibe elrejtettem a jó jelszót is. Itt vettem észre, hogy a program csak akkor fogad el közönséges szöveges állományt, ha txt-re végződik. A saját adatbázissal futtatva rögtön megtalálta a jó jelszót.

Az egyik kolléga, mikor meséltem neki, hogy mit is csinálok, a router adminisztrációs felületén utánam kezdett kutatni, természetesen hiába, hiszen nem kapcsolódtam a hálózatra, csak füleltem.

Később megnéztem, mit árulnak el magukról a kollégák gépei. Az Autoscan a Windowsos gépeket messziről felismeri. A legtöbb Linuxos géppel viszont problémái voltak, pedig csak alap Ubuntu volt rajtuk. Megtalálta a hálózati nyomtatót is.

Szkriptkiddiként búcsúztam ettől a munkahelytől.

Régen a bioinformatikai programok nagy részét kézzel fordítottam és természetesnek vettem, hogy meg kell küzdeni a forráskóddal. Amióta Ubuntut használok és a csomagkezelőből az általam használt programok nagy többsége elérhető, leszoktam a fordításokról.

A napokban viszont a cufflinks nevű program használata során a főnököm belefutott abba, hogy csak bizonyos számú bejegyzés fér el a SAM fejlécébe. Természetesen olyan referenciát használunk, ahol a kontigok száma ennél a limitnél magasabb. A forráskód birtokában nem olyan bonyolult ezt a limitet megemelni, de lefordítani annál inkább.

A cufflinks a boost API-ra épül, tehát evidens volt, hogy ezt is le kell fordítani. A samtools is alap, ha SAM fájlokat írunk. Ezen felül kell az Eigen API is. Ha ezek megvannak, akkor jön a konfigurálás. Kb. 1,5 óra alatt jöttem rá, hogy a következő kombinációval jutok a legmesszebb:

./configure --with-bam=samtools-dir --with-eigen=eigen-dir --enable-intel64 --with-boost=boost-dir  --with-boost-libdir=/usr/local/lib


Bizony, külön kell megadni a boost könyvtárat és a boost library-t. Az eigen-dir esetén a névhez hozzáfűzi az include és lib könyvtárneveket, tehát ezeket ne adjuk meg.

Ezután már csak töménytelen mennyiségű linker hibát kapunk (pl:undefined reference to `boost::system::system_category() ). Egy csomó ideig kutattam a konfig állományokban, de végül győzött a lustaság. A konzol üzeneteit visszagörgettem a a g++-os részig, ahonnan a hibák elkezdtek gyűlni, ami nálam így nézett ki:

g++  -Wall -Wno-strict-aliasing -g -gdwarf-2 -Wunused -Wuninitialized -m64 -march=nocona -O3  -DNDEBUG  -pthread -I/usr/local/boost/include -I/usr/local/include -I/home/travis/cufflinks-2.0.2/eigen-eigen-5097c01bcdc4/include   -o cufflinks  -L/usr/local/lib -L/usr/local/boost/lib  cufflinks.o libcufflinks.a libgc.a -lboost_thread -lbam  -lz


Beléptem az src könyvtárba, és bemásoltam a fenti sort, és hozzáadtam a következőt: -lboost_system. Ekkor lefordult. Ha a programcsomag részét képező többi alkalmazást is fordítani szeretnénk, akkor kézzel linkeljük a többi programot is.

A blogposzt nem tükrözi a heroikus küzdelmemet, ugyanis szerettem volna egy olyan könyvtárba telepíteni boost-ot, amire volt írási jogom. Ez sikerült is, de folyton összetűzésbe keveredtem a rendszerre telepített verzióval, és olyan hihetetlen üzeneteket kaptam, hogy csak néztem. Mikor ezt felismertem, már egyszerű volt a megoldás.

Mi az UEA?

A mikroRNS-ek feldolgozásához a Kelet Angliai Egyetem néhány munkatársa készített egy programot UEA Small RNA Workbench néven. Az ötlet maga igen egyszerű. Fogták a jól ismert parancssoros feldolgozó programokat és összegyúrták egy klikkelős alkalmazássá. Nézzük, hogyan teljesít!

A posztban a 2.5.0 verziót vesézem ki. Mivel keresztplatformos alkalmazásról van szó, Java-ban programozták. Alapvetően négy műveletet hajthatunk végre: előfeldolgozás, kis RNS profil felállítása mirBase alapján, potenciális új kis RNS-ek felderítése, kis RNS szekvencia illesztés genomra, ta-si előrejelzés, degradom analízis. Ha valaki továbbra is a parancssort részesíti előnybe, meghívhatja az eszközöket közvetlenül is.

Előfeldolgozás

A kis RNS-ek szekvenálásánál az egyik probléma, hogy maguk a szekvenciák rövidebbek, mint a readek. Ebből adódóan az adaptorok szinte minden szekvenciában megtalálhatóak, eltávolításuk létfontosságú. Az UEA képes eltávolítani ezeket a szekvenciákat, de csak akkor, ha a szekvencia végén helyezkednek el. Szemben a parancssoros cutadapt programmal, ami akkor is sikeresen eltávolítja az adaptor szekvenciákat, ha nem pontosan a végeken helyezkednek el. Ebből adódóan több próbálkozás után végül elvetettem a használatát.

Az előfeldolgozási lépések egy menetben elérhetőek például a mirCat eszközben is. Sajnos egy hiba miatt ezek nem érhetőek el, mert meg nem változtatható módon egy ablakba beírja a trimmelés utáni fájl nevét, miközben a további lépések csak egy könyvtár nevét várják azon a helyen. Az előfeldolgozást ezért a cutadaptra bíztam.

Ismert kis RNS profilozás

A program automatikusan letölti a kis RNS adatbázist, ami kényelmes megoldás. Ha a vizsgálatok során adott verziószámmal szeretnénk csak dolgozni, azt is megtehetjük, mert külön könyvtárban tárolja az egyes verziókat, mi csak a verziószámra kell, hogy hivatkozzunk.

A program több szekvenálást is beolvas. Megszámolja melyik kis RNS-re illik a legtöbb szekvencia, ellenőrzi, hogy az adott szekvencia megtalálható-e a genomon, normalizál, majd csoportosítja a találatokat a felhasználói beállításoknak megfelelően. Ez egy elég kényelmes funkció. Sajnos a megvalósítása már kevésbé az. Az eszköz képernyője és a beállítások két külön ablakban vannak és a kapcsolat közöttük elég kényes. A paraméterek frissítése és az eszköz beállításának sorrendje ha megváltozik, furcsa hibaüzeneteket kapunk.

Az eredmény CSV, de a csoportosítástól függően eltér a szabványtól. Ha R-be vagy egyéb programba akarjuk beolvasni, nem árt, ha írunk egy scriptet, ami szabványos formátumra hozza. (Excel formátumba is lehet exportálni adatokat, de értelem szerűen az nem próbáltam) Ettől függetlenül teszi a dolgát.

A GUI-ban apró kényelmetlenségek vannak, mint például a mismatch értéket csak úgy tudjuk átírni, ha kijelöljük a szöveget és átírjuk. A del és backspace gombok nem működnek. (Ez okozott némi fejfájást, mire rájöttem). Másik kellemetlen probléma, hogy ha elmentjük a paramétereket, az RNS csoport beállítást "elfelejti" elmenteni.

Új kis RNS felfedezés

Ehhez a területhez nem értek kellőképp, ezért nem tudom megítélni, hogy az algoritmus megfelelően teljesít-e. A használata viszont rendkívül egyszerű. A szekvenciák és a genom alapján felderíti a potenciális kis RNS pozíciókat, majd különböző modellek alapján megállapítja, hogy létezhet-e kis RNS. Ha igen, visszaadja az eredményeket.

A programot nem sikerült úgy futtatnom, hogy ne dobált volna kivételeket, de az eredményeket leellenőrizve nem találtam hibát. A készítők beledrótozták, hogy egyből levágja az adaptorokat és szűrjön, de a gyakorlatban az egyik paraméter hibásan kerül tárolásra, majd felszólít a program, hogy változtassak meg egy nem szerkeszthető szövegbeviteli mezőt. Mivel az adaptor eltávolítás egyéblént sem működik valami jól, ez nem nagy probléma.

Elméletileg a prediktált új kis RNS-ekket képes térben is megjeleníteni, de a gyakorlatban ez soha nem működött nálam. A stem-loop szerkezeteket sem sikerült minden alkalommal kirajzolnia, de ezzel nem időztem annyit, hogy meg tudjam mondani, mi lehet a hiba.

Parancssor

Szerencsére parancssorból is meg lehet hívni, ezért több adaton is lefuttathatjuk shell szkriptek segítségével. A paramétereket egy fájlban várja, de annak tartalma nincs sehol ledokumentálva. Az olvasóim bizonyára kitalálták már, hogy a grafikus felületen elmentett paraméter fájlt lehet felhasználni. Ha ezzel tisztában vagyunk, máris futtathatjuk éjszakánként a programot.

Összegzés

A programcsomag hiánypótló a maga nemében. Igyekszik összeszedni minden lényeges kis RNS-ekkel kapcsolatos feladatot, hogy egyszerű, áttekinthető formában hajthassuk végre az elemzésünket. Sajnos a program még nem áll abban a fázisban, hogy a számítógépektől idegenkedő, Word-ön és Excellen nevelkedett emberek is használják, de jó úton van felé. Ha a forráskódot megnyitnák a nagyközönség előtt, én biztosan segítenék eltűntetni néhány kivételt. Hibajelentést amatőr módon a honlapjukon a hozzászólások közé lehet beszúrni.

Ha az ember kicsit jobban ért a számítástechnikához, mint a környezete, akkor a sajnos olyan műveleteket is végre kell hajtani, mint a vírusok, malwarek és egyéb állatfajták eltávolítása Windowsról. Már olyan régóta dolgozom GNU/Linux rendszeren, hogy komolyan meglepődöm, milyen furmányos dolgokat találnak ki.

Egy nőismerősöm panaszkodott, hogy nem érti, de mostanában a gépét ellepték a ledér öltözetű hölgyek. Megkért, hogy tüntessem el őket, mert elég kellemetlen, hogy minden egyes böngészés alkalmával megjelennek.

- Csak azt nem értem, hogy kerültek a gépemre.
- Biztosan valami olyan oldalt látogattál meg.
- Én nem néztem semmi olyat. Csak levelezek, Facebookozok.
Nem szóltam. Türelmesen bólogattam, mint a pap a gyónás előtt.
- Meg néha megnézek egy kötözős pornót.
- Nem gondolod, hogy ott fertőződhetett meg a gép?
- Nem, teljesen megbízhatónak tűnik az oldal.

Bele sem akarok gondolni, milyen lehet a megbízható ebben a kategóriában. A feladat ellenben adott, csak annyi nehezítést kaptam, hogy mindezt távoli eléréssel oldjam meg. A Windows saját tűzfalán kívül nem volt semmi a két gép között, valami miatt mégsem tudtam kapcsolódni. Mindkét gép Windows 7-es volt, mégis teljesen máshogy nézett ki a távelérés dialógusablakja. Végül a TeamViewer volt a megoldás kulcsa, amivel már gond nélkül tudtam irányítani a gépet.

A probléma az volt, hogy a Google kereső találatait eltérítette valami mechanizmus, amitől a ledér hölgyek jöttek fe. Az is feltűnt, hogy a böngésző gyorsítótárában van néhány elem, amit nem tudok törölni. Sajnos csökkentett módba nem tudtam belépni a távoli használat miatt, de a frissítéseket felpakoltam, amivel azt értem el, hogy az eltérített oldalakat a böngésző blokkolta.

Kellett találni valami irtóprogramot, ami ingyenes, de elég hatásos. Egyet sem ismertem, de azt tudtam, hogy ha csak keresek egyet a neten, akkor jó eséllyel egy másik vírusbányát szabadítok a gépre. Az jutott eszembe, hogy ezekről a hamis vírusírtókról biztosan nincs összehasonlító cikk. Találtam is egy ilyet, ráadásul egy híresebb PC újság on-line felületén. A leírások és kommentek alapján kiválasztottam a Spybot Search and Destroyt, ami fizetős, de az ingyenes változata is csinál valamit.

A segítségével eltűntettem a gyanús fájlokat a lomtárból és egyéb helyekről, amitől a hölgyek is eltűntek.

Ebben a posztban röviden összefoglalom, milyen lehetőségei vannak egy bioinformatikusnak Magyarországon. Először 2007 végén kerestem állást, és meg kell mondanom, nem volt túl sok. Egyszerűbb volt elmennem programozónak, annak ellenére, hogy nem volt szakirányú végzettségem.

Tavaly kezdtem el megint nézegetni az álláshirdetéseket, mert a feleségem munkanélküli lett, és bár nincs okunk panaszra, úgy gondoltam a biztonság kedvéért szerzek egy másodállást.

Az eltelt négy évben sok minden változott. Először is megjelentek a mini szekvenátorok, amiből kutatóintézetek és diagnosztikai laborok bevásároltak, másrészt a hazai bioinformatikusok egy része kivándorolt. Most, aki keres talál. A kérdés, mit várnak el a jelentkezőktől?

Az első hírdetésre beadott jelentkezésemre be sem hívtak. Itt elsősorban laborban dolgozó embert akartak, aki mellesleg majd megoldja a bioinformatikai problémákat is. A vicces az, hogy a feleségem is jelentkezett a hirdetésre és be is hívták, bár neki semmilyen bioinformatikai tapasztalata nincs. Az egyik ott dolgozó ismerősöm elmondta, hogy végül egy nőt vettek fel, aki kijelentette, hogy ő aztán nem fog semmi számítógépes munkát elvégezni. Mikor afelől érdeklődtem, hogy akkor miért vették fel, csak annyi választ kaptam, hogy nagyon dekoratív és...hogy is mondjam...olyan Anita Ekbertes.

A második hírdetést egy labordiagnosztikai cég adta fel. Nekik elsősorban elemezni kellett volna. Vettek egy Ion Torrentet és mielőtt az megérkezett volna, akartak valakit, aki már a kicsomagolás pillanatában ott bábáskodik felette. Ide már behívtak, de mégsem rám esett a választás, mert a másik jelentkező ügyesen meggyőzte őket, hogy ne fél állásra vegyenek fel valakit, hanem egészre. Így én automatikusan kiestem. (Persze erről is úgy értesültem, hogy a Torrent Communityben feltűnt egy új személy, aki nagyon sokat kérdezgetett a gépről, majd később azzal a céggel is felvette a kapcsolatot, ahol dolgozom, így személyesen is tudtam vele beszélni)

A harmadik helyre gond nélkül felvettek, mert ismertem szinte mindenkit. Nem volt elbeszélgetés, nem volt semmi. Ez egy akadémiai kutatóhely, ahol azzal kell szembenéznie a jelentkezőnek, hogy minden bizonytalan, kivéve a munka mennyisége. A kutatók pályázati pénzekkel játszanak tili-tolit, hogy mindenkinek legyen fizetése és nem ritka, hogy valakinek a bére két vagy több pályázatból áll össze. A pénzhiány máshol is probléma, nem véletlen, hogy a hirdetések nagy részében pályakezdőket keresnek, mert rájuk kedvezményeket kapnak, vagy csak egyszerűen kevesebbet kell nekik fizetni.

Itt abba is hagyhatnám a posztot, ha nem jártam volna úgy, mint Trevor, a teljesen kitalált, a valóság írmagját sem tartalmazó történetemben. Így jelentkeztem még egy akadémiai kutatócsoport hirdetésére. Az itt tapasztaltak elég ilyesztőek voltak. Itt ugyanis azután kerestek bioinformatikust, hogy megvették a gépet. Bekapcsolták az Ion Torrentet, klikkelgettek a hozzá adott szerver webes felületén, majd kaptak egy nagy halom szekvenciát. Az interjún számomra az jött le, hogy ezután elküldték valakinek elemzésre ezeket, akik azt mondták, hogy egy hónap múlva küldik az eredményeket. Ezután adták fel a hírdetést.

A feladat az lett volna, hogy az erősen kontaminált mintákból valahogy kihalászni egy olyan vírus genomját, amit a tudomány még nem ismer, és pusztán a szekvencia alapján megmondani, hogy mitől dögleszti meg a gazdaszervezetet. Kiderült továbbá, hogy semmilyen bioinformatikai infrastruktúrájuk nincs. Van egy Windowsos gépük CLC Workbenchel és kifújt. Kérdezték, hajlandó lennék-e a rendszergazda munkáját is ellátni, ha éppen nincs itt. Persze, adjatok egy motoros fókát és fel is mosok.

Nem arról van szó, hogy megalázónak tartanám a rendszergazdai munkát. Egyáltalán nem. Ez a blog is tanúskodik róla, hogy ha kell, megcsinálom. Sőt, meg is csináltam, mert nem volt rendszergazda. De egy bioinformatikai labor felépítése nulláról, nagyon nagy szaktudást igényel és sok segítséget. Ha a rendszergazda inkább akadály ebben a folyamatban, mint segítség, akkor el kell küldeni. Szeretem a kihívásokat a munkámban, de hogy a munka végrehajtása legyen a kihívás...

Úgy gondolom, a fenti eset nem egyedi probléma. Amikor olyan kiírást látok, hogy a "jelöltnek lehetősége van a csoport irányvonalát meghatározni", akkor óhatatlanul is az jut eszembe, hogy lövésük sincs arról, mit is kellene csinálni.

Minden szakmának megvan a maga nyelvezete. Nincs ez másként a számítástechnikában sem. Ha viszont egy kívülálló megpróbálja úgy használni az adott nyelvet, hogy nem érti azt, furcsa dolgokat hallhatunk.

Az egyik értékesítőnek "nem ment a laptopja", ami azt jelenti, hogy valami apró gond miatt egyetlen funkció nem működött. Szólt a rendszergazdának kikiáltott programozónknak, hogy nézze meg, mi lehet a gond. Mutatni akarta, hogy mennyire járatos az informatika útvesztőjében, ezért előtte biztonsági másolatot akart készíteni az adatairól. Ekkor hagyta el a száját a következő mondtat:

- Feltöltöm DropBox-ba, hogy ne legyek gépi memóriához kötve.

Az már csak hab a tortán, hogy ha van Amazonos tárhelyünk, akkor miért kell DropBox?

Ha másnak is van hasonló története, ossza meg.

Az új év nagy változásokat hozott a Nyomicson számára is. Sikerült eladniuk egyetlen programot. A befektetői csoport, akik anya madárként figyelték a szárnypróbálgatást, nem voltak elragadtatva ettől a teljesítménytől. Tudták, hogy segítő kezük nélkül a Nyomicson-fióka megdöglene, de az eddig befektetett pénzt sem akarták veszni hagyni. Úgy döntöttek, nem adnak meg minden támogatást a cégnek. A cég vezetői, mikor értesültek erről, azonnal behívta Tervort egy kis elbeszélgetésre.

Trevor volt az egyetlen bioinformatikus-szerű lény a cégnél. Tudott egy kicsit programozni, ismert néhány bioinformatikai alkalmazást, amitől azt hitte, hogy ő valami ász. Felületes genetikai ismeretei miatt a többiek kikérték a tanácsát biológiai kérdésekben, mert ők még ennyit sem tudtak. Ez csak tovább erősítette benne felsőbbrendűségének tudatát. Előszeretettel keresett hibákat mások ötleteiben, munkájában, bizonygatva ezzel saját fontosságát.

Trevor belépett az irodába, kicsit kényelmetlenül érezte magát, mert mindenki a legdrágább öltönyét viselte, míg ő csak egy metál együttes fekete pólóját. Mikor meghallotta, hogy az ügyvezető igazgató, a főigazgató átszervezésekről és nehéz gazdasági helyzetről kezd beszélni, már tudta, hogy valakit el fognak küldeni, aki nem visel öltönyt. A hírt póker arccal hallgatta. Erősnek mutatta magát, mert már nem úgy gondolt magára, mint egy profira, aki mind a tíz ujjára találna állást, de kifelé ezt sugározta. Hiszen a profikat nem rúgják ki. A profikra szükség van. Tehát ha lapátra teszik, az csak azért lehet, mert mégsem elég profi.

- Az értékesítők közül is elküldünk egy embert - modta a főigazgató, hogy Trevor ne érezze úgy, ez valami személyes bosszúhadjárat, amiért többször kioktatta őt. De azt nem tette hozzá, hogy az értékesítők így is négyen maradnak, míg a bioinformatikusok közül csak egy viszi tovább a munkát.

- Mit fog csinálni Sly? - kérdezte Trevor. Sly volt a "tudományos" csapat megmaradt tagja.

- Ő szakértői értékesítést fog csinálni. Most erre a területre kell koncentrálnunk. A másik terület, ami nagyon fontos, a fejlesztés.

- Én tudok programozni is - mondta reménykedve Trevor. - Ha emlékeztek rá, az első feladatköröm a cégnél fejlesztés volt. Szabadidőmben meg Game Jam-eken veszek részt.

- Ez igaz, de a mostani fejlesztőink, sokkal hatékonyabban dolgoznak, mint te. Először azt a modellt alkalmaztuk, ahol a bioinformatikusok fejlesztettek, most viszont a bioinformatikusok elmondják az igényeiket a fejlesztőknek, akik leprogramozzák azt. Ez egy jobb megközelítés.

Trevor szerette volna megkérdezni, hogy ezzel az új modellel milyen bioinformatikai igényeket elégítettek ki, de nem látta értelmét, hogy tovább győzködje őket. Főnökei már eldöntötték, hogy ő menni fog.

- Van kérdésed?

- Igen. Miért engem?

- Te egy nagyon zárkózott ember van, ami nem baj. Ezen már nem tudsz változtatni. Megcsinálod a rádosztott feladatokat, de ennél a cégnél sokkal proaktívabban kell lenni. Nálunk az alkalmazottak kitalálják, hogy mit szeretnének csinálni és teljes erőbedobással azt csinálják. Nézd meg például Edwardot - Edward az egyik fejlesztő volt. - Kijelentette, hogy nem hajlandó webet fejleszteni, helyette elkezdett írni egy RNA-seq elemző programot.

Úgy, hogy azt sem tudja, mi az a transzkripció - tette hozzá gondolatban Trevor. Néhányszor mondta Edwardnak, hogy legalább ne ugyan azon az adatsoron validálja a programját, mint amit a fejlesztéshez használ, de nem volt foganatja.

- Én is elkezdtem írni egy GPU gyorsított de-novo összeszerelő algoritmust, de leállítottátok, hogy erre most nincs kapacitás.

- Igen, ha valakinek sok ötlete van, akkor számítania kell rá, hogy néhányat elkaszálnak.

- Ezek szerint, ha nem veszem figyelembe, hogy mit mondtok, csak megyek a saját fejem után, akkor most meglenne az állásom?

- Nem, a céljaidnak meg kell egyeznie a cég céljaival.

Trevor emlékezett arra a megbeszélésre, ahol a cég céljait akarták meghatározni. Negyven perc hiábavaló fecsegés után szétszéledt a társaság, mert a vita leragadt ott, hogy a cég céljai és küldetése ugyan az, vagy két különböző dolog.

A túlsúlyos Nyomicson-fóka nem tud repülni. Szülei kevesebb ételt adtak neki, hogy leadjon egy kis zsírt, de a fióka ehelyett lerágta a lábát, hogy könnyebb legyen. Trevor épp távozni készült, amikor utána szóltak.

- Ez egy nehéz időszak nekünk is. Nagyon spórolnunk kell. A honlapon szerepelni fog ugyan, hogy keresünk bioinformatikusokat, de nem fogunk felvenni senkit. Most erősnek kell mutatnunk magunkat.

A CNV (copy number variation) olyan variációk, ahol az egyének közötti különbséget az adja, hogy egy szekvencia régióból hány darab található a genomjában. Az újgenerációs szekvenálások segítségével ezen ismétlődések számát nehéz meghatározni, mert a megszekvenált régiók viszonlag kicsik, az illesztő programok több helyre is be tudják illeszteni a readeket. Emiatt az illesztés sok esetben dombokat és völgyeket tartalmazhat. Az illesztőprogramok több stratégia segítségével igyekeznek ezt megoldani. Az egyik ilyen stratégia, hogy az azonos valószínűségű helyek között véletlenszerűen dönt a program.

Jelen bejegyzésemben megvizsgálok néhány programot, amivel felderíthetőek ezek az ismétlődő helyek és bemutatom, mit tapasztaltam használatuk közben. Sajnos nem volt korrekt adatom, amivel az eredményeket is összehasonlíthattam volna, ezért csak a használatukra helyeztem a hangsúlyt.

CNVer 0.8.1

A szoftver fordítása egyszerű, használata már kevésbé. Ahelyett, hogy beépülne az operációs rendszerbe, meg kell neki adni egy CNVER_FOLDER környezeti változót, ahonnan megtalálja a program a különböző szkripteket, amiket használ. Szükség van még a referencia fájlból készített annotációra. Ezt a hg18 és hg19-hez elkészítették a program fejlesztői, de ha saját referenciával dolgozunk, kénytelenek vagyunk magunk előállítani azt. Nekünk csak a bemeneti BAM állományról kell gondoskodnunk, ami elméletileg bármilyen programmal készülhet és egy abszolút elérési utat tartalmazó konfigurációs állományba kell megadni a helyét. Ez a tulajdonsága is elég furcsa. Az eredmény egy BED fájl-szerű struktúra, ahol az eltérések a "gain" illetve a "loss" szavakkal vannak jelölve.

Mr. Canavar 0.41

Ez a program egy kis ökoszisztémára hasonlít. A fordítása egyszerű. Nem kér semmilyen extra állományt, cserébe az illesztőprogramra finnyás. Csak a Mr. Fast vagy a felesége használható. Igen, a másik illesztőprogram Mrs. Fast. A logok alapján a programot fejlesztik, de nekem túl egyszerűnek tűnnek. Úgy értem, a program összesen 3200 sor. Vagy valami hatalmas zsenialitás van ebbe a minimális kódban, vagy sokminden hiányzik. Én ez utóbbira tippelek.

Contra 2.0.3

A nicaraguai lázadókhoz semmi köze a programnak. Függőségei a SAMTools, R és a Python. Ez a program képes többféle targetált illesztést is feldolgozni, de ez esetben kell neki egy kontroll adatsor. A súgó remek, az alkalmazás teljesen bolond biztos. (Ezt onnan tudom, hogy szánt szándékkal ki akartam játszani az ellenőrzéseket. Nehezen ment.) A kimenete VCF is lehet, ami megkönnyíti, hogy más alkalmazásokkal összevessük. Az R segítségével ábrákat is képes készíteni, ami hasznos, ha publikációba akarjuk bemutatni eredményeinket.

FREEC 5.7

Ez a program volt számomra a legmegyőzőbb, habár hangsúlyozom, az eredményeket nem tudtam ellenőrizni. A C++ alkalmazás a legteljesebb körű CNV analízist kínálja. Lehet vele teljes genom, exome, targetált szekvenciákat is feldolgozni, de megbírkózik a rákos adatsorokkal is. Bemenetnek az illesztésen kívül igényli a referenciából készített annotációkat is, mint a CNVer, de igény szerint felülírhatjuk az itt tárolt jellemzőket. A parancssori kapcsolók helyett konfigurációs állományt kell megadni neki. Ennek összeállítása bonyolult, de a honlapon kapunk segítséget. Többféle kimeneti állományt is készít, valamint kapunk R scripteket az eredmények vizualizálásához. Aki ellenben igényli az IGV nyújtotta gyönyöröket, annak a BEDGraph kimenet lehet kedves. A fórumok is dícsérik, szerintem nem véletlenül.

Idén is volt Amicon, amire elmentem. Azért, hogy ne csak álljak, és nézzem mások Amigázását, elvittem az Efikát és kértem segítséget, hogy telepítsünk rá MorphOS-t.

Mint korábban már írtam róla, a rendszer USB képességeit feláldozták az alacsony fogyasztás oltárán. Ennek megfelelően egy közönséges pendrive nem mindig olvasható, ha pedig egeret és billentyűzetet is csatlakoztatunk a géphez, már szabad hely sincs neki.

A fórumon, mikor segítséget kértem, rögtön megkaptam a magamét, hogy milyen ócska felszerelésem van, hiszen még valami sok gombos, gyümölcsről elnevezett telefon/e-mail kliens is képes együttműködni az Efikával. Nekem nincs Blackberry-m, ezért a segítség mellett döntöttem, még akkor is, ha ezért nevetség tárgya leszek. Hiába, a nagy műszaki áruházak termékeire nem tüntetik fel, hogy az eszköz Efika kompatibilis-e.

A találkozó családias volt. A rossz idő és a munkahelyi gondok miatt nem voltunk sokan. Charlie, aki a fórumon leszólt az eszközparkom miatt, azonnal telepíteni kezdte a MorphOS-t. Mint kiderült, nem csak én nem vagyok ellátva "megfelelő USB eszközökkel".

A Blackberry kiesett, mert nem volt miniUSB csatlakozó. A pendrive-ok ugyan azt a jelenséget produkálták, mint az enyémek. Nem látták a fájlokat. Végül a netes telepítés mellett döntöttünk. Az Efika uboot-ja ugyanis képes TFTP szerverekről fájlokat letölteni.

A TFTP a legegyszerűbb, ebből következően a legkevésbé szofisztikált fájl átviteli protokol. Nincs jogosultság kezelés, ami jelen esetben előny. Használatához két környezeti változót kellett beállítani: server-ip és client-ip. (Az uboot ugyanis egy kis parancsértelmező, mint amilyen a Bash)

setenv server-ip 192.168.1.10
setenv client-ip 192.168.1.12


A szerver egy PowerMac volt. Betöltöttük a boot fájlt:

boot eth:morphos.img

Betöltöttük a fájlt, ami egy telepítés nélkül is használható rendszer volt. Ez ugyancsak képes az ISO állományt TFTP-n keresztül felhasználni a telepítésre. Most, hogy visszaolvasom, nem is tűnt olyan szörnyűnek, de míg eddig eljutottunk, addig 3-4 sikertelen telepítési kísérletet jártunk végig, mindegyik legalább félórás időtartammal bírt. Először ugyanis mindenképp USB-n keresztül akartuk másolni az ISO állományt, ami rendkívül lassú volt. Ráadásul a nem regisztrált MorphOS egy óra után leáll és megkér, hogy regisztráld. Mondanom sem kell, hogy a másolás hosszabb volt egy óránál.

Mindjárt telepítettünk egy SDK-t is, mert anélkül nem ér semmit egyetlen operációs rendszer sem. Legalábbis szerintem. A kis gép 1280x1024-es felbontást gond nélkül vitte, a memóriaigénye megközelítőleg 90MB, ami élvezetesebb felhasználói élményt tesz lehetővé a Suse linuxnál.

Lázi, a házigazda eközben Apache szerveren keresztül akart Hollywood segítségével dinamikus webtartalmat előállítani. Igen, a próbálkozás nem csak első hallásra tűnik feleslegesnek. A célja a projektnek, hogy valami Amigás szervert hozzanak létre. A Hollywood pedig az egyetlen interaktív tartalmat előállító program Amigára. (Becsületére legyen mondva, mindegyik újgenerációs Amiga-szerű rendszeren fut)

Annak ellenére, hogy az Amicon elsősorban Amigás találkozó, lehetett játszani Nintendoval, régi Mac gépekkel és még egy Chameleon 64 bemutatót is láttunk.

Kaptam egy megbízást, hogy régi bioinformatikai weboldalakat ültessek át Drupal alá. A Drupal alapvetően szimpatikus kezdeményezés, mivel megkönnyíti a weblapkészítést. Most sajnos nem tudtam összeklikkelni az egész oldalt, kénytelen voltam modulokat fejleszteni, hogy az egyes szolgáltatások beviteli mezőit integrálhassam.

Mint a legtöbb modul rendszernél, itt is callback függvényeket kell használnunk, amit a Drupal terminológia hook-oknak nevez. Szinte minden funkcióhoz megtalálhatjuk a megfelelő hook függvényt. Ezen kívül csak két dolgot érdemes még tudni a modulokról: asszociatív tömböket használnak, a modul nevén alapuló névkonvenció van. Gyakorlatilag ennyit kell tudni a Drupal modulokról. Most nézzük meg kicsit részletesebben:

A modul nevén alapuló konvenció

Ez azt jelenti, hogy a modul nevét nagyon sokszor le kell írni. Először is létre kell hozni egy könyvtárat. A könyvtár neve a modul neve lesz. Minimum két fájl lesz benne, mindkettő a modul nevét tartalmazza, de az egyik .module kiterjesztést, a másik .info kiterjesztést kap. Az .info fájl egyfajta katalógusként szolgál, olyan információk kerülnek bele, mint a névtér, dependencia, minimális Drupal verziószám.

A .module fájlba kerül a kód. A kód a hook függvényeket tartalmazza. Minden hook függvény a modul nevéből, aláhúzásból és a hook típusának nevéből áll. Például ha van egy vacak nevű modulunk, akkor a vacak_menu lesz a függvény neve. Ezzel egy új elemet vehetünk fel a navigációs menübe.

Asszociatív tömbök

Minden függvény, ami a Drupal környezettel akar kommunikálni, egy asszociatív tömböt ad vissza. A kulcsok nevei és az értékek függvényenként eltérnek. Gyakorlatilag a modulfejlesztés ezen kulcs-érték párok bebiflázásából áll. Nem tudom, hogy ez a módszer-e a jobb, vagy a Spring XML konfigurációs megközelítése, de hajlok arra, hogy van valami harmadik út is, ami mindkét módszert veri. A probléma a Drupal megoldásával, hogy nem hibatűrő. Egy string elírása nem feltétlenül okoz hibaüzenetet, legfeljebb csodálkozhatunk, miért nem úgy működik a kód, ahogy elvárjuk. A másik gond, hogy ha már stringeket kell beírogatni, akkor legalább legyen konzekvens névhasználat. Egyszer ugyanis aláhúzással vannak elválasztva a kulcsban a szavak, máshol szóközzel.

Példának okáért nézzünk meg egy menü hook függvényt.

function example_menu(){
  $item['ExampleMenu'] = array(
    'title' => 'Title of the menu',
    'page callback' => 'myexamplefunc',
    'page arguments' => array('first', 'second'),
    'access callback' => TRUE,
  };

  return $item;
}


A modul neve tehát example, a menu neve, amit a felhasználó látni fog: Title of the menu, míg az adminisztrátori oldalon, a Navigation menüben az ExampleMenu név alatt érhetjük el. A menüre kattintva lefut a myexamplefunc függvény, aminek a paraméterei first és second lesz. A menüt minden felhasználó elérheti, erről gondoskodik az access callback rész.

A dokumentáció részletesen ír ezekről a stringekről, de a példaalkalmazások szerintem informatívabbak. Az egyik bajom a Drupal dokumentációjával, hogy bár tartalmaznak mindent, megtalálni a lényeget nagyon nehéz. Ha viszont a példaalkalmazásokban látott dolgokra keresünk rá, hamarabb célt érünk. Hasznos a felhasználói hozzászólások figyelése is, mert az is célorientált.

Formok

Statikus tartalmakat modulként fejleszteni időpazarló, azokat inkább klikkeljük össze az adminisztrációs felületen. Formokat is rakhatunk össze adminisztrációs felületen, de véleményem szerint ezt célszerűbb programkódra bízni.

Form esetén az page callback drupal_get_form lesz. Tehát a megjelenítést a Drupal motorja végzi. Azt, hogy mi jelenjen meg, mi határozhatjuk meg a page arguments részben. Itt soroljuk fel a függvényünket és annak paramétereit.

   'page callback' => 'drupal_get_form',
   'page arguments' => array('myform'),


Ezután három függvényt kell létrehozni. Az első a myform, ami megjeleníti a beviteli mezőket. A myform_validate ellenőrzi a mezők értékeit, végül a myform_submit segítségével feldolgozzuk azokat. Mindhárom függvény két paramétert kap: Az első tartalmazza a beviteli mezőkértékeit egy asszociatív tömbben, a második pedig a form állapotát. Ez utóbbit referencia szerint adjuk át.

A következő példa egy olyan formot készít, ami egy szöveges beviteli mezőt és a checkbox-ot tartalmaz:

function myform($form, &$form_state){
  $form['firstinput'] = array(
    '#title' => 'Put you secret data here',
    '#type'  => 'textfield',
    '#default_value' => 'default',
  );
  $form['secondinput'] = array(
     '#title' => 'It is a secret?',
     '#type'  => 'checkbox',
  );
  $form['submit'] = array(
     '#type' => 'submit',
     '#value' => 'Send to me',
  );

  return $form;
}


A formunk egy tömbökből álló tömb. Minden elem egy beviteli mező, az értékek egy újabb asszociatív tömbben vannak. Elég unalmas leprogramozni. A #type mező minden elemnél kötelező, de a további kombinációk itt találhatóak.

Drupal alá modult írni nem bonyolult feladat, inkább kitartást igényel. A rendszer előnye, hogy a statikus tartalmakat egy kényelmes szerkesztőfelületen készíthetjük el, de összetetteb feladatok esetén használhatjuk programozási ismereteinket is. A honlapkészítés egyik legkönnyebb módja.

A cél

Már Function idején elkezdtem írni egy kisebb release-t, amolyan B-tervnek arra az esetre, ha Grass mégsem készülne el a Cubes-al. Szerencsére az erősen hiányos alkotást nem kellett bemutatni. Ott hallottam először az idei Experience-ről, ahol nem csak demókat nézhetünk, de még egy kisebb compot is szerveznek. Gondoltam ez a kis szösszenet megfelelő lesz rá.

A terv

A zene kiválasztásánál eleve arra törekedtem, hogy minél gyorsabban, minél kevesebb időráfordítással készülhessen el az alkotás, ezért a legrövidebb zenét választottam ki. Miután meghallgattam néhányszor, világossá vált, hogy három nagy egységből áll. Az első egy lágy dallam, ezt követi egy pörgősebb rész, végül visszatér az első téma. Tehát a három rész gyakorlatilag kettő, egy lassabb, és egy gyorsabb. Ez alapján készítettem egy részecske rendszert, meg egy alakváltó kockát. Írtam néhány shadert, hogy ne nézzen ki annyira ocsmányul, majd félretettem. Közben jött Topy, elmúlt a Function. Grassnak megmutattam a demó vázát, ő pedig ellátott hasznos tanácsokkal. A legfontosabb tanácsa, hogy be kell teríteni a képernyőt tartalommal. Az első verziónál a képernyő közepén ott voltak az alakzatok és csak ott mozogtak. Ezután már rengeteg alakzat mozgott minden irányba. Tényleg jobban nézett ki.

Fejlesztés

Nem akartam a már meglévő keret rendszerrel dolgozni, szerettem volna valamit újítani. Mivel a tartalom elég egyszerű, igyekeztem a kódba belevinni valami olyat, amit még nem csináltam. Például egy kis post processinget. Ennek megfelelően ez a demó már két lépésben állítja elő a tartalmat. Az első lépésben a testek és azok színe és mélységi információi bekerülnek egy framebufferbe. Ez a framebuffer több textúrában tartalmazza az információt. Később még ki lehet egészíteni normálokkal, rücskökkel, ambient occlusionnal, stb. Jelenleg csak a mélységet és a színeket tárolom. Miután feltöltöttem a framebuffert, jön a második lépés. Rajzolok egy, az egész képernyőt betöltő négyzetet, majd kirajzolom rá a textúrákat. A shaderek segítségével pedig különböző post processing effekteket rakok rá.

Igyekeztem jövő álló megoldást készíteni, de így is átesett két refaktoráláson, mert időközben rá kellett jönnöm, hogy az elsődleges tervek nagyon merevek. Még most is látok benne néhány limitációt, de már használható.

A használata így néz ki:

renderer = createRenderer(2, 2, width, height, aspect_ration);

Az inicializáló részben készítünk egy renderer változót, beállítjuk hány textúrába akarjuk elhelyezni a tartalmat (a mélységi információkon felül), mennyi shadert akarunk használni, valamint a textúrák szélességét és magasságát. (Az utolsó paraméterrel az oldalarányt állítjuk be, arról később lesz szó)
A rajzoló ciklusban a következő elemek találhatóak:

rendererFirstStage();
/* geometria kirajzolása, paraméter állítgatás */
rendererSecondStage();
/* post processing, shader paraméret állítgatás */
drawQuad();


Végül az erőforrások felszabadítása:

freeRenderer();

Ami nekem nem tetszik, hogy két helyen is kell paramétereket állítgatni. Sokkal jobb lenne, ha csak az első menet után lehetne mindent beállítani. Ezen még dolgozni fogok, de az eredmény már most magáért beszél! Az utómunkával jelentősen javult a látványvilág, már-már megközelíti egy igényesebb csapat gyengébb release-ét.

A másik újítás az ütem számláló, illetve annak egy kreatív elkészítése. Észrevettem, hogy a programozóknak sok manuális munkába kerül az ütemekre szinkronizálás, ezért leírom, hogy miként oldottam meg:

A zenét meg kell nyitni egy zeneszerkesztővel. Én az Audacityt használtam, mert azt ismerem, de biztos vagyok benne, hogy más programmal is meg lehet oldani. A hullámforma nézetet át kell állítani Pitch (EAC) módba, amitől az ismétlődő struktúrák szemmel könnyebben felismerhetőek (1. ábra). Ezután beazonosítjuk az ütemhez tartozó mintázatot, és feljegyezzük minden minta időpontját. A módszer pontossága függ a feljegyzett időpontok számától, de nem szükséges az összes időpont feljegyzése. A demó készítésekor én 10-12 időpontot jegyeztem fel. Egy táblázatkezelő vagy statisztikai program segítségével egy lineáris modellt illesztük a pontokra. Az egyenes egyenlete segítségével a demónkban kiszámolhatjuk az ütemek számát. A lineáris modell miatt a módszer hibatűrő. Ha egy-két pontnál rosszul jegyeztük fel az időpontot, az ütemszámláló attól még lehet pontos. Lássuk hogyan nézett ki nálam ez a gyakorlatban:

Feljegyeztem az időpontokat: 72.053 73.792 75.531 77.270 79.009 80.748 82.487 84.226 85.965 87.704 89.443 91.182
R-ben az egyenes egyenletének kiszámítása a következő módon néz ki:

> num <- c(1:12)
> time <- c(72.053,73.792,75.531,77.270,79.009,80.748,82.487,84.226,85.965,87.704,89.443,91.182)
> line <- lm(time ~ num)
> line
Call:
lm(formula = time ~ num)

Coefficients:
(Intercept)          num  
     70.314        1.739

A num az egyenes meredeksége, az Intercept az X tengely metszéspontja (matematikailag: num*X + Intercept). Ha ellenőrizni akarjuk, hogy mennyire jó a módszer:

> plot(time ~ num)
> abline(line)

A demóba a következő módon lehet beépíteni:

int beatnum;
beatnum = (time - 70.314) / 1.739;

Problémák:

A demó készítése közben a Gimp egy új tulajdonságát is felfedeztem. Grass adott egy png formátumú grafikát. Gimppel megnyitva láttam, hogy Adobe palettával készült, de a program felajánlotta, hogy konvertálja RGB-be. Konvertálás után minden programban jól jelent meg, kivéve a demóban. Ott ugyanis el volt csúszva jelent meg a kép hasonlóan ahhoz, amikor 3 bájtonként akarjuk beolvasni a szín információkat, de a kép kevesebb bájton tárolja azt. Megpróbáltam mindent. Átkonvertáltam jpg-be, majd ismét png-be, minden kombinációban kapcsolgattam az exportáló funkciókat, de a kép csak nem akart megjavulni. Végül az segített, hogy kivágtam a teljes képet, majd beillesztettem új képként és azt elmentettem.

A másik álmatlan éjszakákat okozó hiba egy gömb volt. Nem akartam, hogy a demó háttere homogén legyen, ezért egy gömbbe helyeztem a jeleneteket. A gömböt Blenderben készítettem el, mert lusta voltam procedurálisan előállítani. A normál vektorokat felhasználva színeztem, de a "déli félteke" rendszeresen fekete volt. Sokáig nem is foglalkoztam a dologgal, csak bántotta a szememet. Először azt hittem, a shader kóddal van valami hiba, de miután nem találtam semmi furcsát és az internet szerint is jól számoltam, ismét betöltöttem Blenderbe a gömböt és megjelenítettem a normál vektorokat. A gömb felén a normál vektorok összes-vissza álltak. Két klikkeléssel megoldottam.

Ez az első demónk, ami 16:9-es oldalarányra optimalizált. Mivel nekem az összes monitorom a jó öreg 4:3-os aránnyal rendelkezik, így olyan megoldást akartam, ami minden képernyőn megtartja az oldalarányokat:

float aspect = 16.0 / 9.0;
float newheight;

newheight = (float)width / aspect;
glViewport(0, (height - newheight)/2, width, newheight);

Csakhogy a képernyő alján és tetején megjelenő fekete sáv mérete nekem nagyobbnak tűnt, mint amit megszoktam más szélessávú demóknál. A gyanúm akkor igazolódott be, amikor megjelenítettem a logókat, mert azok rajzoltak a fekete részre is. A hiba csak akkor jelentkezett, amikor nem 16:9 volt az oldalarány. Az a gyanúm, hogy a framebuffer mérete nagyobb, mint amit a glViewport-ban beállítok. Amikor a második lépésben kirajzolom a textúrát, ott már a glViewport és az ablakkeret között fekete részhez hozzáadódik a framebufferben eltárolt fekete rész is, amitől az oldalarány furcsának tűnik. A gyanúmat a logók kirajzolása is alátámasztja. A probléma az volt, hogy elfelejtettem, hogy az első lépésnek más nézet kell, mint a másodiknak. A gyakorlatban egy úgy néz ki, hogy két glViewport kell. A fenti megoldás csak a második lépésnél kell. Az elsőnél a következőre van szükség:

glViewport(0, 0, width, newheight);


Ezt beszúrva a renderFirstStage() függvénybe megoldódott a problémám.

A bioinformatikában az a szép, hogy soha nem lehet abbahagyni a tanulást. Ha a valakinek biológiai háttere van, fel kell zárkózni informatikából, matematikából. Ha másik tudomány területet tanult az egyetemen, akkor a hiányzó kettőből válogathat. A MaBIT-es beszélgetésekből is kiderült, hogy az egyetem önmagában nem elég, hogy valaki mindhárom területen elmélyedjen. Szerencsére az internet korában erre nincs is szükség. Rengeteg helyről beszerezheti az ember a hőn áhított tudást.

Az én személyes kedvencem a Cursera. Már megcsináltam a Machine Learninget, a Computer Visiont, Statistical One-t, Computing for Data-Analysist. Eddig egyedül a Computer Vision nem sikerült. A vizsgán 70%-t kellett volna elérnem, hogy kapjak róla papírt. Ennek ellenére gazdagodtam néhány fogalommal, amit a demók írásánál fogok kamatoztatni. Az OpenCV sok eljárása sem fekete doboz immár.

A Machine Learninggel egyidőben csináltam a Caltech hasonló nevű kurzusát, Ez sokkal matematikai központúbb volt, mint a Courserás. A házi feladatok nagy részét nem is tudtam megcsinálni, de az előadások adtak egy olyan szemléletet, hogy megértettem sok eljárás hátterét is. Ráadásul kénytelen voltam megtanulni a parciális deriváltakat.

Már mások is felfigyeltek az on-line tanulás lehetőségeire. David Searls írt egy remek összefoglalót az ingyenes forrásokról.

Sajnos a tudás olyan, mint a nők. Nem elég megszerezni, meg is kell tartani. Megkért egy dietetikus hallgató, hogy az egyetemi levelező képzésén tanult genetikában segítsek neki, mert nem tudja megcsinálni a házi feladatnak feladott keresztrejtvényt. Nagy fellengzősen arra gondoltam: Ugya, mi olyat tanulhatnak, amire én ne tudnám a választ? Majd azon kaptam magam, hogy Wiki és Gugli felváltva súgnak nekem. Rájöttem, hogy a biológiát sem árt átismételni. Szerencsére a Cursera ebben is segít. Az Experimental Genomics célja, hogy az alapképzésen túl átfogó képet adjon a laboratóriumi vizsgálati módszerekről. A házi feladatok része, hogy tudományos folyóiratok cikkeit kell olvasni és azokról hol rövid ismertetőt, hol kritikát kell megfogalmazni. Ezután a kurzus résztvevői egymás írásait javítják egy megoldókulcs segítségével.

Azt azért nem árt megjegyezni, hogy a Coursera nemrég indult, tehát elképzelhetőek kisebb-nagyobb fennakadások a rendszerben. Ezek egy része külső okokra vezethető vissza: Amikor a GoDaddy szünetelt, a kurzusok nem voltak elérhetőek. Más részüket belső problémák okozzák. A kurzusok videóihoz tartozó feliratok néha hiányoznak, az egyik házi feladat kérdéseit nem lehetett közvetlenül elérni. Mire valaki a kurzus fórumán belinkelte azt, addigra lejárt a határidő. A vizsgajegy 50%-ért ez a házi felelt, tehát itt már buktam a teljesítés feltételét. A Caltech YouStream-en követhető, néha ez sem volt elérhető.

Néhány hete arra lettünk figyelmesek, hogy bizonyos emberek képtelenek csatlakozni a vezeték nélküli hálózathoz. Egészen pontosan, elsőre nem tudnak hozzá csatlakozni. A tünetek a következőek: látnak minden vezeték nélküli hálózatot. A 20km-re lévő sarki kisbolt olcsó routerétől kezdve a szomszéd irodában ideiglenesen megnyitott mobiltelefon internetes megosztásáig bezárólag mindent, de a teljes tartományban működő saját routert, ami fél méterre van a géptől, azt valami csoda folytán nem látja.

Ezt egy router resettel szokták orvosolni, mert csak azt az egy gombot látják a készüléken, tehát megnyomják. A reset meg is oldja a problémát, csupán egyetlen baj van vele: Az összes többi munkatársnak megszűnik a hálózati hozzáférére (igaz, csak rövid időre), akik gond nélkül tudnak csatlakozni. Érdekes módon, a reset nélkül kapcsolódni képtelen gépek mind Mac-ek, míg a kapcsolódni tudóak ócska PC-k Linuxal.

Nem akarom azt sugallni, hogy a Mac-el ne lehetne wi-fi-t használni, és a Linux felsőbbrendű, de azt igenis állítom, hogy a Linux használatával és a vele való folyamatos harccal olyan számítógépes probléma megoldási képeségre tesz szert az ember, ami később más operációs rendszeren is alkalmazható.

Csak a saját ismerősök körében végzett, nem reprezentatív jellegű megfigyelések alapján bátran állíthatom, hogy lényeges különbség van azok között, akik Linuxról váltanak Mac-re és akik Windowsról teszik ugyan ezt. Akik Linuxról térnek át, azok általában belefáradnak a folyamatos szövegfájl buherálásba, és a ronda terminál használatába. Áttérnek egy kényelmes rendszerre, de ha beüt a mennykő, akkor morogva elindítják a terminált és megoldják a problémát.

A korábban Windowst használók ezzel szemben a meg nem értett gépet cserélik le egy olyan rendszerre, ami még jobban eltávolítja őket a számítógép "lelki világától", ezáltal a megértés lehetőségétől. Nem a számítógéppel oldják meg a problémát, hanem a világot akarják a számítógép igényeihez igazítani.

Az eset végül megoldódott. Az egyik alkalmazott javasolta, próbálja meg a gépet újraindítani. Csodák csodájára ez is "megjavította" a Mac-et. Ez a megoldás is elég nevetséges, de legalább nem hátráltatja a többi dolgozót.

Kevin egyszerű kutató volt. Bioinformatikusként dolgozott, de nem értette meg a munka mélységeit, megelégedett egyszerű programok futtatásával és azok felületes kiértékelésével. Ahogy telt-múlt az idő, hiányos ismeretei egyre jobban akadályozták a munkában, ezért, mint minden rendes kutató, segítséget keresett.

A segítséget a Nyomicson nevű cég személyében lelte meg. A cégnek ugyanis divatos honlapja volt (Flash nélkül, ahogy az akkori irányzatok megkövetelték), szép, iStockPhotoról lopott képek díszítették és mentes volt minden eredeti ötlettől. Hangzatos, hatásvadász szövegekbe botlott az idelátogató, mint amilyen: Megtalálunk minden SNP-t, még amiről nem tud a világ, azt is.

Maga a cég is furcsa volt, bár igaz, Kevin erről mit sem tudott. A cég teljes állományában ugyanis nem volt egyetlen épkézláb bioinformatikus sem. Volt olyan, aki azt tartotta magáról, hogy az, de inkább férfi klimaxban, skizofréniában szenvedő programozók, pályát tévesztett vegyészek, zoológusok alkották. A marketinget egy orvos vezette, mert még a tesztbábukat is reanimálni kellett, ha ő hozzájuk nyúlt. Vezetőjük egy álmodozó volt, aki képtelen volt bevételt termelő megoldásokat kitalálni és inkább befektetői pénzekből tartotta fenn kis céget.

Kevin, mivel ő volt az első vevő-szerű lény, azonnal megkapta a cég teljes erőforrását. Ez egy agyondícsért illesztő program és néhány bonyolult kiértékelő szkriptben ki is merült. Ennek annyira megörült Kevin, hogy elhatározta, egy publikáció formájában mond köszönetet a kedveskedésért. Mi másról írhatott volna, mint az illesztőprogramok összehasonlításáról, mint lerágott csontról? Összeszedett minden illesztőprogramot, amit csak talált, majd elkezdett illeszteni. Mit is? Természetesen a cég saját szimulált adatait. Az illesztés után SNP-ket és indeleket keresett a GATK nevű programmal. Gyakran nem boldogult ezeknek az eszközöknek a futtatásával, ilyenkor a cég egy-egy alkalmazottja besegített neki.

Az eredményeket mindenki nagy reményekkel várta. A Nyomicson azt remélte, most végre mindenki megtapasztalja az ő felsöbbrendűségüket, piacvezetővé válnak és elhozzák a fényt a bioinformatika sötét korába. Kevin arra számított, hogy lesz egy cikke, ami talán hozzásegíti, hogy doktorija is legyen. A valóság sokként hatott: Az ingyenes, lesajnált illesztőprogramok állva hagyták a cég üdvöskéjét. Semmit baj! A programozók nekiestek és addig tekerték a kódot, amíg pár százalék javulást el nem értek. Miután a programon nem tudtak többet javítani, a paramétereket állítgatták vadul, mindenféle logika nélkül, és csak a fals pozitív arányt nézték. Miután teljesen a tesztadatokhoz igazították a programot (a többit szigorúan alapértelmezetten hagyták, hiszen objektívek akartak lenni), el is érték, hogy a 3. legjobbak lettek a listán.

Kevin meg is írta a cikket, csak egy kicsit kellett neki segíteni. Aki tüzetesen megnézte a Nyomicson honlapját, kínos egyezéseket talált a cikkel. Azért, hogy elkerüljék az öntömjénezés vádját, a szerzők között csak Kevin szerepelt. Elküldték egy online lapba, mert sem a cégnek, sem Kevinnek nem volt elég pénze, hogy értelmes újságba megjelentesse, és várták a csodát.

A csoda meg is érkezett, méghozzá három bíráló formájában. Kettő elfogadta a cikket, annak ellenére, hogy pár helyen a táblázat fejléce és magyarázó szövege nem volt összhangban. A harmadik, Zalzburg viszont vette a fáradságot és végigolvasta a kéziratot. Nagyjából 1500 szóban össze is foglalta az összes fellelhető hibát, a vizsgálat tervezésétől egészen a programok paraméterezéséig.

A cikk ugyanis a megtalált variációkkal akarta igazolni, hogy melyik a legjobb illesztőprogram. A célkitűzésben a klinikai diagnosztika szerepelt, de szimulált adatokat használtak, minden szimulált adat pontosan 12 indelt és 10 SNP-t tartalmazott, valamint csupán 67 adatot generáltak egy sajnálatos szkript hiba miatt, amit lusták voltak kijavítani. Zalzburg konyított valamicskét a statisztikához is, ezért külön kiemelte, hogy ennyi adat kevés, vélhetően az eloszlások semmilyen kapcsolatban nincsenek azzal, amit Gaussról neveztek el. Írás közben a vérnyomása megemelkedett és az udvariasság határait egy-egy megjegyzésével átlépte. Az már csak hab volt a tortán, hogy az egyik illesztőt, amit valami csoda folytán a Nyomicson megvert, éppen ő írta.

A cég, mikor meglátta, hogy milyen bírálatot kapott Kevin cikke, paprikás hangulatba került. Zalzburg édesanyja, édesapja és kutyája felváltva csuklottak, néha egy időben. A düh hatására meg is született a döntés, hogy Zalzburgot le kell járatni az internetes fórumokon. Be kell mocskolni, hiszen ő is mocskolódó hangvételű kritikát fogalmazott meg. Az senkinek a fejében nem fogalmazódott meg, hogy a kritika akár jogos elemeket is tartalmazhat.

Szerencsére pár nap elteltével némileg józanabbul döntöttek, de Zalzburg kritikáját annak tudták be, hogy féltékeny, mert a programjánál jobbnak bizonyult a Nyomicson illesztő. Sajnos Kevin képességei nem tették lehetővé, hogy a kritikáknak megfelelően kijavítsa a saját cikkét, azt a cég alkalmazottjai voltak kénytelenek megcsinálni. A javítások után a cikk színvonala sokat emelkedett, bár a Nyomicson illesztő nem jutott Olümposzi magasságokba és Kevin sem volt képes megcsinálni a doktoriját.

A történet tanúsága, hogy nehéz objektívnek lenni, különösen, ha szubjektív az ember. Az igazság független a mi személyes vágyainktól és csak azért, mert valakit szubjektív indokok vezérelnek, képes objektív érveket hangoztatni. Ha pedig az objektív igazság a cél - márpedig egy tudományosnak tűnő publikáció esetén ez kellene, hogy legyen - próbáljunk meg a kritikához is objektíven állni.

Kapitány Kristóf: Objektum struktúra nagyfelbontású röntgenfelvételekből

Gyantába ágyazott agymintákat szeleteltek vékony rétegekre. Megfestették a vérereket, majd az egyes rétegekből megpróbálták rekonstruálni az érhálózatot 3D-ben. A kihívás többek között a zaj szűrése, mert az erek denz pöttyökként jelennek meg. Ha a metszés síkja nem merőleges az érre, akkor ellipsziseket kapnak. A fejlesztők Matlabot és ImageJ-t használtak a munkához.

Cserző Miklós: Bioinformatika oktatás a Semmelweis Egyetemen

Az orvostanhallgatók heti két előadás keretében ismerkednek a bioinformatikával. Az oktatás webes forrásokra és szolgáltatásokra támaszkodik, valamint szóbeli vizsgával zárul. Az oktatás filozófiája, hogy a bioinformatikát nem specialisták, hanem a biológusok fogják művelni. Ennek megfelelően az adatbázisokkal és algoritmusokkal csak érintőlegesen foglalkoznak, a cél, hogy a programok által adott eredményeket értelmezni tudják. Nincs programozás, nincs Unix/Linux parancssor. A webes források közül csak azokat ismertetik, amelyek valószínűleg 10 év múlva is létezni fognak, mint például EnsEMBL, BioMart. Eszközök közül Blast, FastA, HMMER, eTBlast használatát tanulják meg. Említés szintjén megismerik a különféle bioinformatikai modelleket, alapvető megközelítési módszereket (neurális háló, rejtett Markov lánc). Hallanak a nagy áteresztőképességű technikákról, rendszerbiológiáról, molekula modellezésről.

Gellért Ákos: Az uborka mozaik vírus 2b fehérje C terminális domén szerkezeti stabilizálásához kétértékű fémion koordináció szükséges

Az uborka mozaik vírus ellen jelenleg nincs védekezés. A fertőzésben a levéltetvek játszanak fontos szerepet. Az előadás arról szólt, hogy különféle fehérje elemző programok segítségével, hogyan lehet megtalálni a megoldást. A modellező programok szerint a fehérje vége rendezetlen lesz. A domén predikció szerint ugyanakkor a vég fémion kötő helynek tűnt. A modellhez ezután kétértékű fémionokat adva a szerkezet stabilizálódott. A legvalószínűbbnek a Mg ion tűnt, de más két értékű ionok is stabilizálnak. A kísérletek azt mutatták, hogy ha mutálják a fehérje végét, a fertőzés lelassul, de a fertőzést nem akadályozza meg.

Szabó Emese: Hazai elit szőlő ültetvények vírusfertőzöttségének felmérése új generációs szekvenálással

A szőlők vírusfertőzése ellen jelenleg nincs hatákony módszer, ezért a megelőzés szerepe fontos. Az előadásban bemutatott módszer kis RNS-ek izolálásán, szekvenálásán és bioinformatikai feldolgozásán alapul. Az RNS szekvenciákat BWA-val illesztik az NCBI-on és DPV-n alapuló adatbázisra. A találatok lefedettségét BEDTools segítségével határozzák meg. Említettek még egy pfor.pl nevű scriptet is, amivel a ciruláris kontigokat szűrik ki. A jelenleg használt módszereknél érzékenysége jobb és metagenomikai elemzésre is alkalmazható lehet.

Molnár János: Mangalica-specifikus molekuláris markerek keresése második generációs genomszekvenálási technológiák és bioinformatikai módszerek alkalmazásával

A mangalica szerepe megnőtt a hazai sertés tenyésztésben. A mangalica tartás költségesebb, húsa drágább, ezért igyeneznek hamisítani. Mangalica specifikus markerek segítségével elő lehet állítani egy olyan eljárást, amellyel megállapítható, hogy egy húskészítmény mangalicából készült-e vagy nem. Először egy biobankot állítottak fel, majd módszeresen elkezték azok szekvenálását. Használtak 454-et, Solidot és Illumina HiSeq 2000-et is. A munkát nehezítette, hogy a sertés referencia genom rosszabb, mint az emberi. A bioinformatikai munkához elterjedt eszközöket használtak, mint BWA, SamTools, Annovar. Ez utóbbi egy annotációs program. A mitokondriális DNS segítségével nem találtak használható markereket. A GO analízis során azt vették észre, hogy a legtöbb variáció a zsíranyagcseréhez és a szagláshoz köthető génekben fordul elő.

Cserző Miklós: Kis, nem kódoló RNS-ek

Miklós második előadásában két oldalról közelített meg valamit. Pontosan nem tudni, hogy mit. Először olyan ritka DNS motívumokat keresett, amelyek két ugyan olyan szekvenciából álltak (fej-farok szerkezet), közöttük változó hosszúságú (0-52 nukleotid) "távtartókkal". Csúszó ablakos módszerrel a genomon végighaladtak, majd a várható értéknél alacsonyabb előfordulási aránnyal rendelkező motivumokat összegyűjtötték. Ezeket a ritka mintázatokat spanionoknak nevezték el. Egér és ember szekvenciákat vizsgálva azt tapasztalták, hogy a spanion klaszterek (nem a szekvenciák!) 75%-ban átfednek. A transzkripciós starthely közelében a spanion klaszterek száma magasabb.

A másik megközelítés a tiRNS-ek laboratóriumi vizsgálata volt. Ezen struktúrák szerepe nem ismert, de a spanionok és a tiRNS-ek között átfedés van, ami nem tűnik túl erősnek, de a véletlennél nagyobb. Az eredmények nem tiszták, annyi biztos, hogy nem a siRNS útvonalon hatnak. Ez az előadás kavarta a legnagyobb vihart a seregszemlén. Miklós szerint valami nagy áttörésre lehet számítani, de mások szerint csak műtermék, amit lát.

Korcsmáros Tamás: Jelátviteli és szabályozási hálózatok – adatbázis és elemzés

A jelátviteli útvonalak rokon fajokban hasonlóak, mégis találunk különbségeket. Kevés útvonal típus van, ezek között úgynevezett keresztbeszélgetések vannak. A  Sigma Link adatbázis 3 élőlény 8 útvonalát tartalmazza. Az útvonalak összevetése során irányított kapcsolatokat kerestek. Az adatbázist a szakirodalom alapján kézzel frissítik, beépítették a kis RNS útvonalakat, transzkripciós és posztranszlációs szabályozásokat. Az adatbázis segítségével megválaszolhatjuk, milyen szabályozás alá esnek bizonyos gének, fehérje interakciós kapcsolatokat deríthetünk fel, keresztbeszélgetéseket azonosíthatunk transzlációs és poszttranszlációs szinten. Talán potenciális gyógyszercélpontokat is lehet találni a szolgáltatás segítségével.

Bruck József: Networks and Kinetics - Approaches to understanding Metabolic Pathways

Ez az előadás félig magyarul, félig angolul hangzott el. Az előadó mikrofon segítségével sem tudott olyan hangosan beszélni, hogy mindent érteni lehessen. Valami gráfokon alapuló modellt állított fel, reakciókinetikát számolt, de mikor egy ábrán a kísérletes, transzkripciós szabályozással kapcsoatos adatokkal próbálta összevetni a modell eredményeit, akkor alig volt átfedés közöttük. Erre az volt az előadó következtetése, hogy a transzkripció zavaros, és egyáltalán nem meglepő, hogy nincs átfedése azzal.

Az utolsó két előadáson nem voltam ott.

Az idei MaBIT szokás szerint családias hangulatban telt. A seregszemle első napján a következő előadások voltak hallhatóak:

Patthy László: A genomkorszak bioinformatikája. Frontvonalak és utóvédek.

A genomok a bioinformatika fejlődésének motorjai. Előtte a bioinformatika annyiból állt, hogy fehérje multidomainek többszörös illesztését dolgozták fel. A genomok megszekvenálásával a kutatók a genotípustól igyekeztek eljutni a fenotípusig. Ebben a folyamatban a legfontosabbak a fehérje kódoló gének voltak. A gyógyszeripar azt várta például, hogy több gyógyszercélpontot tudnak majd azonosítani. A túlzott elvásárok ellenére mind a mai napig nem tudjuk, mennyi gén is van az emberi genomban. A bioinformatika - gyors fejlődésével - megválaszolatlan kérdéseket hagyott hátra, ezért jelentősége visszaszorult. Az annotált gének többsége is hibás. Az előadás ezután átment a MisPred ismertetésébe. Ezt korábban itt hallottam.

Gáspár Zoltán: Random de-novo fehérjék szerkezeti preferenciái.

Ebben az előadásban egy vizsgálat történetét ismerhettük meg. Minden úgy kezdődött, hogy magányos töltött alfa hélixeket vizsgáltak különböző prediktáló programokkal, és azt találták, hogy a programok a hélixek helyére coiled coil és/vagy rendezetlen szakaszokat prediktáltak. Felmerült a kérdés, hogy a coiled coil szakaszokat is rendezetlennek jellemzik-e ezek a programok. Miután ez igaznak bizonyult, az eredmények mellett kialakult egy olyan statisztikai metódusuk, amivel asszociációkat tudtak keresni különböző protein szakaszok között. Egy Nature cikk megjelenése után az édeklődésük a fehérjék aggregáció képzése felé fordult. Kimutatták ugyanis, hogy in vitro minden vizsgált fehérjének van egy aggregációs hajlama. Van egyfajta evolúciós nyomás, ami ez ellen a hajlam ellen hat. Azt vizsgálták, hogy véletlenszerűen képződő random fehérjék képesek-e aggregációra. Random 480 hosszú DNS szakaszokat generáltak, ahol a GC tartalmat szabályozták. Lefordították ezen szakaszokat, majd beadták a algoritmusoknak, amelyek rendezetlenséget, transzmembrán domaint, aggregációs hajlamot prediktáltak. Eredményül azt kapták, hogy a GC tartalom és a szerkezeti preferencia között korreláció mutatható ki. Jelenleg 3 humán fehérje esetén mutatták ki, hogy nem kódoló szakaszból képződött, tehát nem teljesen légből kapott a vizsgálat.

Barta Endre: Informatikai és bioinformatikai kihívások egy újgenerációs szekvenáló központban.

Az előadásban részletes leírást kaptunk a debreceni számítógépes kapacitásról. Megtudtuk, hogy bár Pécs, Szeged és Debrecen is rendelkezik egy-egy szuperszámítógéppel, a hálózati késleltetés miatt ezek nehezebben használhatóak genomikai munkára, mint egy helyi szerver. A feldolgozás ugyanis I/O intenzív, a tárhely nagysága és sebessége a meghatározó, nem a CPU sebessége. Ráadásul a szuperszámítógépeknél feladatütemezőket kell használni és nem lehet tetszőleges programot telepíteni root jogosultsággal, mert a gépek üzemeltetői ezt nem szeretik. Megismerhettük, hogyan kell telepíteni bioinformatikai programokat, hogy minden felhasználó láthassa őket és milyen szimbolikus linkeket kell létrehozni, hogy valamennyi partíció látható legyen bármelyik gépről is jelentkezünk be.

Nagy Gergely: Transzkriptóm meghatározás GRO-Seq alapján.

Sajnos ez az előadás olyan halk volt, hogy a negyedik sorban is alig hallottam. A lényege, hogy RNS-ket szekvenáltak, majd rátérképezték a genomra, kiugró csúcsokat kerestek, mint a hagyományos RNA-Seq-nél. Az eredményeket összevetették más kísérletekből jövő eredményekkel, majd megállapították a transzkripció kezdőpontját, a transzkripteket, enhanszereket, mindent. A diák alapján jól és logikusan felépített előadásnak tűnt, de a szövegből szinte semmit nem lehetett hallani.

Rigó Krisztina: DNS alapú HLA tipizálás

Az MHC régióba eső gének fontos szerepet játszanak az immunológiai folyamatokban. Tipizálás során meghatározzák, hogy a vizsgált egyén génjei melyik alléllel típusnak felelnek meg. Legpontosabb a szekvencia alapú tipizálás. Ahogy a Sanger alapú szekvenálást felváltják az új generációs szekvenálások, úgy nő az igény az ezen alapuló megoldásokra. Sajnos a szekvencia homológiák miatt a referenciára történő illesztéssel nehéz, ezért az összes ismert allélre történő illesztéssel próbálkoznak a különböző laboratóriumok. A közeli allélek esetén a tipizálás tévedésének esélye nagyobb, ezért bevetik az ismert allélgyakoriságokat. Láthattunk néhány képernyőképet tipizáló programokról.

Győrffy Balázs: Világhálón elérhető orvosi bioinformatikai eszközök az onkológiában

Egy általános onkológiai bevezető után megismertünk egy Kaplan-Meyer rajzoló alkalmazást, ami a túlélési időt becsülte meg Cox-Mantel teszt segítségével. Az eszköz a www.kmplot.com címen érhető el. A program a diagnosztikai adatok alapján megrajzolja a túlélési görbét. Emlő és petefészek daganatok esetén működik a program. A tüdőrákra most fejlesztik. A másik bemutatott szolgáltatás egy terápiás döntést segítő rendszer, ahol emlődaganat esetén egy Affymertix CEL fájl feltöltésével megkapjuk, mennyi az esélye, hogy hatni fog a kemoterápia valamint szükség van-e kemoterápiára. A www.recurrenceonline.com-on elérhető szolgáltatás az R statisztikai nyelv köré épül. Végül a NetGOPlotot ismerhettük meg, ahol géntargetek és anyagcsere útvonalak felderítését végezhetjük.

Simon István: Bioinformatika a szerkezeti biológia szolgálatában.

Az előadás a fehérje térszerkezetekről szólt. A térszerkezet az atomi kölcsönhatások alapján kiszámítható, de gyakorlati haszna viszonylag kicsi, mivel kísérletesen könnyebb meghatározni azt. Speciális esetekben viszont jól jöhet, ha például a kísérlet kivitelezése nehéz. Másik módszer, a szekvencia illesztések helyett (ahol gyenge homológia esetén nem is kapunk megfelelő eredményt) domain illesztéseket végzünk. Ha a szekvencia nem is, a domain szerkezet még lehet homológ. Az eredendően rendezetlen fehérjék esetében ez a módszer sem alkalmazható, mert nem vesznek fel egyértelmű szerkezetet. Alakjukat egy másik fehérjéhez kapcsolódva veszik fel.De vajon a szekvenciából meg lehet-e határozni, hogy egy fehérje rendezetlen-e? Az aminosav kölcsönhatások figyelembe vételével igen (IUPred).

Ezután következett egy kerekasztal beszélgetés, ahol a bioinformatika oktatásról és annak jövőjéről volt szó. Túl sok érdemi megállapítás nem történt. A beszélgetés alapján nekem úgy tünk, hogy Magyarországon két helyen folyik komolyabb bioinformatika oktatás: Debrecenben és a Pázmány Péter Katolikus Egyetemen. Az ELTE-n is van valami, de ott inkább visszafejlődés tapasztalható, mert a fiatal bioinformatikusok elvándorolnak külföldre.

Kicsit ambivalens volt a bioinformatika megítélése ezen a beszélgetésen. Egyfelől rengeteg helyre keresnek bioinformatikust. Annyi álláshírdetés van, hogy sokan már kérték a MaBIT levlistáján, hogy már ne küldjenek több álláshírdetést. Másrészről egyre többen gondolják úgy, hogy a bioinformatika nem eltűnik, hanem a bioinformatikus fog eltűnni, beleolvad munkája a mindennapi biológus tevékenységébe. Én személy szerint úgy gondolom, Magyarországon ez be fog következni, mert kevés embert tudnak csak alkalmazni, és a kutatólaboratóriumok igyekeznek majd olyan embereket gyűjtni, akikre több feladatot is rá lehet osztani. Külföldön más a helyzet. Sok szolgáltatás van, ahol a laboratóriumi munkát megcsinálják, viszont kevés olyat látok, ahol az elemzést végzik.

Anélkül, hogy bármilyen preferenciát is felállítanék, felsorolok néhány véleményt, ami elhangzott: "Nem elég Msc-n elkezdeni a bioinformatika oktatást". "Fontos, hogy a biológus tudjon beszélni a matematikussal." "A biológus hallgatót megzavarja a Unix/Linux." "Az érdeklődés nagyon alacsony a bioinformatika iránt"

Antal Péter: Rendszerbiológiai és prediktív modellezés kapcsolata a tudásfúzió és asszociációs elemzések szemszögéből.

Ezt az előadást úgy, ahogy volt, nem értettem. Ilyen kifejezéseket lehetett benne hallani, mint Markov Burkoló Halmaz, relevancia fa, Multiple Kernel Learning, Bayesian hálózatok. Az a képességem meg elveszett, hogy úgy tudjak jegyzetelni, hogy nem értem, amit írok.

A SAM a rövid szekvencia illesztések legelterjedtebb fájltípusa. Egyszerűségét az adja, hogy minden egyes sor egy szekvenciát jelent, valamint tabulátorral elválasztott oszlopai vannak. Akár egy egyszerű awk szkripttel is feldolgozhatjuk őket.

Hátrányuk, hogy szöveges fájlok révén, sok helyet foglalnak. Erre született meg egy hibrid megoldás, a BAM, ami egy tömörített SAM fájl. Annak érdekében, hogy lehetővé tegyék a gyors pozícionálást az állományon belül (teljes kicsomagolás nélkül), rekordonként tömörítenek.

A Picard egy Java nyelven írt SAM/BAM feldolgozó programcsomag. Előnye, hogy rendelkezik egy API-val, aminek segítségével mi is írhatunk olyan programokat, melyek egyszerre képesek SAM és BAM fájlokat is kezelni.

Nem kell mást tennünk, mint felvenni a sam-1.77.jar állományt a classpath-ba és máris használhatjuk azt. Elég részletes dokumentációval rendelkezik, de egyes helyeken hiányosságok vannak benne.

Első lépés, hogy importáljuk a szükséges osztályokat.

import net.sf.samtools.*;


A Picard API-nak van egy olyan előnye is, hogy képes ellenőrizni, mennyire felel meg a feldolgozandó állomány a szabványnak. Ha nem megfelelő értékeket talál, kivételt dob. Sajnos sok program lazán kezeli a formátum megkötéseit, ezért ha ilyen fájlokat használunk, célszerű lehet beállítani, hogy az API hunyjon szemet a hibák felett:

SAMFileReader.setDefaultValidationStringency(
         SAMFileReader.ValidationStringency.SILENT);

A beállítást a konstruktor meghívása előtt kell végrehajtani. A SAMFileReader osztály segítségével olvashatjuk be magát a fájlt. Használata rendkívül egyszerű:

SAMFileReader sam = new SAMFileReader(new File(filename));
for(SAMRecord record : sam){
  // record processing
}
sam.close()


A SAMRecord osztály segítségével érhetjük el a fájl rekordjait. Minden egyes mezőhöz a SAM fájlban tartozik egy getter metódus, aminek segítségével lekérdezhetjük az értékét. A dokumentáció részletesen ír ezekről.

Természetesen setter metódusok is vannak, ha mi magunk akarnánk SAM formátumba menteni. Ekkor a rekordokat a SAMFileWriter segítségével varázsolhatjuk a merevlemezre.

A SAM állományok legbonyolultabb eleme a Cigar. Ez írja le, hogyan illeszkedik a rekord a referenciára. A Cigar egy sorozat, aminek minden eleme egy számból és az egy karakter hosszú műveletből áll. Ezt a felépítést a Java osztályokból is láthatjuk. A Cigar osztály getCigarElements() metódusa egy listát ad vissza az elérhető elemekkel. A getCigarElement() ellenben sorszám szerint ad vissza egyetlen elemet. A következő program megvizsgálja, hogy van-e olyan rekord, ahol inszerció és deléció egymás mellett van. Ez ugyanis szekvencia illesztési hibára utalhat. Ha ilyet talál, kiírja a referencia pozíciót.

        for(SAMRecord record: sam){
            
            Cigar cigar = record.getCigar();
            int pos = record.getAlignmentStart();
            
            for(int i = 1; i < cigar.numCigarElements(); i++){
                
                CigarElement element = cigar.getCigarElement(i);
                CigarElement prevelement = cigar.getCigarElement(i-1);
                pos += prevelement.getLength();
                
                if( (element.getOperator() == CigarOperator.DELETION &&
                     prevelement.getOperator() == CigarOperator.INSERTION) ||
                     (element.getOperator() == CigarOperator.INSERTION &&
                      prevelement.getOperator() == CigarOperator.DELETION)
                  ){
                    System.out.println(pos);
                }
            }
        }


Sajnos normális esetben nem ír ki semmit a program, ezért módosítsuk a feltételben szereplő elemeket, ha csak a működést szeretnénk ellenőrizni.

Az alacsony szintű osztályok mellett megtalálhatóak a Picard programcsomag funkcióit lefedő osztályok is. Ilyen például a ReorderSam, ami a hasonló nevű program tudását varázsolja saját kódunkba. Ezeket az osztályokat könnyű felismerni, mert nevük megegyezik az alkalmazás nevével.

A Picard Java osztályai lehetővé teszik, hogy egyszerűen fejlesszünk SAM/BAM állományt kezelő programokat, alacsony vagy magas szinten. Használjuk bátran!

Nagyon sok érdekes dolgot tudtam meg a konditeremről, ahova járok. Például már az Államalapítás idején is állt. Talán Toldi Miklós is ott kovácsolta acélossá izmait és Mátyás Fekete Seregének kiképzési programjában is szerepelhetett az edzőterem látogatása. Bizonyítékként itt ez a nemrég feltárt lelet az egyik öltözőszekrényről. A kutatók most ellenőrzik hitelességét. Mivel a blogot kiskorúak is látogathatják, ezért a nagyon csúnya szavakat cenzúráztuk.

De nem csak ez az egyetlen érdekesség. Hírességek is járnak oda! Ez fontos, mert ha nem járnának oda, nem tudnám, hogy a világon vannak. Az egyikük Kicsi Nyúl. Mikor a terem tulajdonosa bejelentette, hogy érkezik Kicsi Nyúl, én óvatosan a naptárra sandítottam, mert biztos voltam benne, hogy nem közeleg a Húsvét. Még azt is elképzelhetőnek tartottam, hogy a nagy ünnep főpróbája következik, ahol a rendes nyúl nem ér rá, csak a helyettese fogja képviselni.

A bejelentés hatására csak én maradtam higgadt, mivel nem tudtam, miről van szó. A többieken láthatóan izgalom lett úrrá. A beszédfoszlányokból megértettem, hogy nem egy idő-anomáliával állok szemben, csak egy hírességgel. Mielőtt a rajongók teljesen megkergültek volna, elhagytam az edzőtermet.

Kicsit késve itt a harmadik nap összefoglalója:

A harmadik nap a Tavaxy megismerésével kezdődött. Ha azt mondom, hogy ez is egy munkafolyamat tervező alkalmazás, az olvasónak talán beugranak ilyen nevek, mint Taverna, vagy Galaxy. Ez a két program előnyeit egyesítő harmadik program. Az egyikkel, vagy másikkal elkészített folyamtokat könnyedén importálni lehet, de a felhaszálói felülete inkább a Galaxyra hajaz. Emboss, SAMTools vagy FastX már integrálva van. Lehet használni Amazon EBS instance-k kezelésére is, tehát teljesen felhő alapú, de ha csak egy nagy teljesítményű számítógépünk van, azon is elfut. Ingyenes, opensource.

Meghallgattam az Aspera előadását is, mert bár lépten nyomon az ő nevükbe botlom, nem sokat tudok róluk. Most megtudtam. Elsősorban nagy mennyiségű adat mozgatására specializálódtak. Manapság a TCP alapú hálózati adat átvitel dominál, de ez eldobja az adatcsomagok nagy részét, a sávszélessggel rosszul skálázódik, az áthidalt távolsággal arányosan növekszik a késleltetés és még megannyi probléma van vele. Szerencsére itt van az Aspera, ami biztonságos, gyors, szép, okos. FasP alapon kommunikál, ami valós időben, a fájl típusának megfelelő átviteli stratégiát választ. Ezt egy összehasonlító táblázaton is megcsodálhattam. Az FTP és az Aspera megoldásánál az egyes fájlok letöltési idejét tüntették fel, de 1 GB-nál nagyobb fájlok esetén az "impractical" szó szerepelt az idők helyett. A rendszer gyorsaságáról élő demót is láthattunk. Az előadó belépett a hotel vezeték nélküli hálózatán keresztül egy amerikai szerverre, majd CloudBerryvel elkezdett feltölteni Amazon S3-ra egy 5GB-os állományt. Kb. 5%-nál leállította, pedig ki sem írta, mikor várható a feltöltés vége. Elindította az Asperát, ami egy perc körüli idő alatt feltöltötte a cuccot. Feltöltés közben visszaváltott a prezentációra, ezért a végét nem láthattuk. De 20%-ig azt tapasztaltam, hogy gondolkodik, majd hirtelen megugrik a feltöltés. Biztos ez volt a valós idejű stratégia váltás. Azért remélem, nem egy erősen repetitív állománnyal próbáltak meg kábítani minket.

Meghallgathattunk egy előadást a New York Genomics Center létrejöttéről is. Ez egy nagyon filantróp, nagyon új, nagyon szép intézmény. Sok okos filantróp kutatóval, akik kapcsolatban vannak az összes New York területén található intézménnyel. Minden házon belül van. A szekvenátorok, a nedves és száraz biológusok, és együtt egy vidám, filantróp tudományos közösséget alkotnak. A közelben van a rendőrség, és a kevésbé filantróp Homeland Security, akik vigyázzák a sok csillogó szemű tehetség békességét. Levetítettek egy videót is nekünk, ami nagyon... filantróp volt.

Ezzel szöges ellentétben a következő előadó magát a szekvenálást outsource-olta. A szekvenáló berendezések nagyjából két évente jelennek meg a piacon. A vegyszerek hozzájuk drágák. Gyors a berendezések amortizációja, ezért úgy döntött, hogy csak a minta izolálását és a preparálást végzik el, a munka azon részét, ahol nincs helye a protokolon belül a mozgástérnek, a szekvenáló központokra bízzák. Az előkészítés ugyanis egy olyan lépés, ami a kísérletek szempontjából a legfontosabb. A szekvenáló központok a legritkább esetben vannak felkészülve egyedi igényekre, még ha a brossúrákban azt is írják. (Ezt én is meg tudom erősíteni) A felhasznált protokolokat csak 15 email után tudják elmondani, de így is olyan hibaaránnyal dolgoznak, hogy két különböző cégnek elküldték ugyan azt a mintát és két eltérő eredményt kaptak. A visszaadott FASTQ is szekvenáló központ függő. Valahol a nyers szekvenciákat adják vissza, de valahol már a vektor szekvenciákat levágják, ami lehetetlenné teszi, hogy például a vektor kontaminációt megállapítsák.

Kedden a kávészünetben már beszéltem az előadóval. Azt mondta, a bioinformatikusoknak jobban meg kellene ismerniük az előkészítési lépéseket, mert jobb következtetéseket tudnának levonni az elemzéseikhez. Egyetértettem vele. Ezt a nehéz módon tanultam meg. Nem egyszer kaptunk mi is olyan adatokat, amiket valami miatt nem tudtunk rendesen illeszteni. A nyomozások végén legtöbbször kiderült, hogy az előkészítési lépésnél szúrtak el valamit. Ha több ismeretem lett volna a preparációról, akkor hamarabb kiszúrhattam volna a hibát.

Az ARB és a SILVA volt a témájá a szekció utolsó előadásának. Ez a két eszköz az rRNS-ek elemzésére szolgál. A SILVA az adatbázis, az ARB pedig egy alkalmazás. Az előadó PhD hallgató kora óta fejleszti, de még nem unja. A minőségbiztosítás a legnagyobb probléma, ugyanis vektor szekvenciák, homopolimer hibák és a szekvencia hasonlóságok miatt nehéz egyértelműen beazonosítani a szekvenciákat. Az adatbázis rekordjait ezért manuálisan is ellenőrzik a szakirodalom alapján. Az ARB alkalmazáshoz bővítményekkel további funkciókat lehet hozzáadni, de ezt eddig senki nem tette meg. A szekvenciák egy saját belső adatbázisban kapnak helyet, ahol referencia alapú tömörítés segítségével csökkentik annak tárhely szükségletét.

Délután kicsit késve érkeztem a rendszerbiológia előadásra, mert én voltam egyedül a kiállítóhelyünkön. A többiek valami drága étterembe akartak menni, és nem értek vissza több, mint három órán keresztül. Legalább egy kicsit értékesítősdit játszhattam. A mondanivaló nagy részét így is megértettem. Míg korábban a bioinformatikai alkalmazások elszigetelt, egyedi problémákat oldottak meg, addig manapság az alkalmazások bonyolultsága megnövekedett. Összetett algoritmusokat használnak, amelyek igyekeznek kapcsolati hálókat feltárni. Ennek egyik irányzata a rendszerbiológia. A rendszerbiológia gráfokkal dolgozik. A feldolgozáshoz elengedhetetlenek a nagyteljesítményű gépek. Ezután különböző példákat láthattunk, amelyeknek közös pontja volt, hogy a problémák felderítéséhez holisztikus szemléletre volt szükség.

Összefoglalva elmondhatom, hogy a BioIT World viszonylag kicsi konferencia volt. Megközelítőleg 150 ember volt jelen. Az előadások számomra hasznosak voltak. A pénzhajhász szemlélet viszont egyértelműen érezhető volt. Ebédet nem biztosítottak a konferencia látogatóinak. Még a programfüzetbe is beírták: Enjoy you own lunch. Ezen nálunk többen kiakadtak, én sejtettem, hogy valami ilyesmi lesz. (Bár arra számítottam, hogy lesz ebéd, csak minket nem fizetnek be rá) Fel voltam szerelkezve 3 napra elegendő szendvicskészlettel. Mondjuk kellett is, mert a marketinges az első nap közölte velünk (ő már két napja ott volt), hogy amit ebédre kaptunk pénzt, azt elitta.

A konferencia az Imperial Hotelben volt. Impozáns hely, de egyetlen kuka volt csak a Quantum kiállítóhelyén. Mint megtudtam az egyik kiállítótól, azért, mert azért is fizetni kellett. Internet szintén nem volt, az is pénzdíjas volt. Ezen az IBM-es kollégák is kiakadtak. Biztos nem tudták elérni a 7,2TB memóriával rendelkező gépüket.