Itt az ideje, hogy kicsit jobban nekiugorjunk és létrehozzuk első saját bővítményünket. Először egy kis elméleti tudnivaló következik, majd kódolhatunk is.

Könyvtárszerkezet

A bővítményünknek a Cinema 4D plugins könyvtárában kell lennie egy új alkönyvtárban. Itt fog majd elhelyezkedni a lefordított bővítmény. Rajta kívül egy res könyvtárra van még szükség, ami nevéből következően az erőforrásokat tartalmazza. Mik is ezek az erőforrások? Ikonok, többnyelvű szövegek, dialógus ablakok. Az ikonok, mint ahogy a példa kódnál is megfigyelhető, egyszerűen a res könyvtárban vannak. A fejléc állományok a descriptions alkönyvtárban vannak. A dialógus ablakok megjelenítéséhez a dialogs könyvtárba kell elhelyezni az erőforrásokat. A többnyelvű szövegek a strings_nyelv-ben kapnak helyet, ahol a nyelv a következő lehet: us, de, jp, fr, it, es.

Bővítmény típusok

A Cinema 4D bővítményei hurok típusúak, ami annyit tesz, hogy a kódunk a program futásának bizonyos eseményei során futnak le. Ilyen esemény lehet egy menüelem kiválasztása, egy jelenet renderelése vagy az exportálás. Lássuk, mik lehetnek ezek:

• Parancs plugin: Egy menüelem kiválasztásakor aktiválódik.
• Jelenet export: Új formátumba menthetjük a jelenetet
• Jelenet import: Eddig ismeretlen fájlt építhetünk a jelenetbe
• Kép export: Bitkép mentése
• Két import: Bitkép betöltő
• Tulajdonság plugin: Az objektumok új tulajdonságot kaphatnak segítségével
• Eszköz plugin: Új eszközt adthatunk a Cinema 4D-hez
• Modellező plugin: Új objektum módosító eszközt hozhatunk létre vele
• Animációs plugin: Egyedi idősávot hozhatunk létre
• Shader plugin: A megjelenítést módosíthatjuk vele
• Jelenet plugin: A jelenet újrarajzolásánál aktiválódik
• Video render plugin: A renderelésnél hozhatunk létre különböző effekteket
• Üzenet plugin: Más bővítmények üzeneteit dolgozhatjuk fel vele
• Csomópont plugin: Új csomópontot vehetünk fel vele
• Egyedi GUI elem: Új grafikus elemet hozhatunk létre
• Egyedi adattípus: A beépített adattípusokat egészíthetjük ki

Regisztráció

Minden bővítmény egy egyedi számmal rendelkezik. Egyedi számunkat a Maxontól kell igényelni. Az itt bemutatott bővítmények csak egy hasraütött számot tartalmaznak, tehát előfordulhat, hogy már regisztrálva vannak. Ha nem használunk más bővítményeket, akkor nem kell aggódnunk, hogy esetleg konfliktusba kerülünk más bővítményekkel, de ha az a tervünk, hogy kereskedelmi forgalomba értékesítjük, mindenképp egyedi azonosítóra lesz szükségünk.

Forráskód

Bizonyára ez a rész érdekel mindenkit. Minden bővítmény három függvényt tartalmaz: PluginStart, PluginEnd, PluginMessage.

#include "c4d.h"

Bool RegisterCGMenu();

Bool PluginStart(void){
        if(RegisterCGMenu() == FALSE) return FALSE;
        return TRUE;
}

void PluginEnd(){
}

Bool PluginMessage(LONG id, void *data){
        return FALSE;
}


A regisztrációt a PluginStart függvényben végezzük. Ha a regisztrációs sikeres, a bővítmény működni fog, ellenkező esetben kilép.

#include "c4d.h"

class CGMenu : public CommandData{
public:
        virtual Bool Execute(BaseDocument *doc);
};

Bool CGMenu::Execute(BaseDocument *doc){
        MessageDialog("My First Plugin");
        return true;
}

Bool RegisterCGMenu(){
        return RegisterCommandPlugin(1001999,"Hello World",0,AutoBitmap("cg.tiff"),String("hello"),gNew CGMenu);
}



Ez egy parancs plugin, amit a szülő osztály típusából állapíthatunk meg (CommandData). Egyetlen virtuális metódust tartalmaz, a parancs végrehatjását. Jelen pillanatban csupán egy üzenet ablakot jelenítünk meg egy egyszerű szöveggel. Végezetül a regisztráció mechanizmusát látjuk. Megadjuk az azonosítót, a menüben látható nevet, a bővítmény néhány tulajdonságát,  az ikont, a tooltip nevet, legvégül az osztályt, amit regisztrálni kívánunk.

Ha elkészítettük első bővítményünket, kísérletezzünk bátran a paraméterekkel. Nézzük meg a dokumentációban, mit jelentenek, majd tapasztaljuk ki hatásukat.

Bármilyen gondosan is fejlesztenek egy eszközt, mindig lesznek olyan funkciók, amelyeket a program nem fog támogatni. Halmozottan igaz ez olyan igények esetén, amire csak kevés embernek van szüksége. A demoscene pont ilyen. Kevés ember mozog benne, és nagyon speciális igényeik vannak.

Szerencsére a komolyabb alkalmazások támogatják, hogy a programozástól nem idegenkedő emberek az igényeiknek megfelelő bővítményekkel lássák el azt. Mai célunk a Cinema 4D demofejlesztő eszközzé alakítása lesz. (Folytatásos teleregény formájában). Az itt leírtak a 13-as verzióval való ismerkedésem folyamán születtek.

A program telepítése során a plugins könyvtárban van egy példa könyvtár (cinema4dsdk). Ha nem akarunk órák hosszat konfigurálni, akkor ezt a könyvtárat használjuk alapnak és más néven hozzuk létre a másolatát ugyan ide. (Tehát a CINEMA 4D R13\plugins könyvtárba.) Ha nem így teszünk, akkor a számtalan relatív elérési út miatt órákon át konfigurálhatjuk a projektet. (És jó eséllyel kudarcot is vallunk. Én megpróbáltam)

A cinema4dsdk könyvtárban van egy Visual Studio (továbbiakban VS) solution fájl, 2005-ös verzióhoz. Valószínűleg nekünk újabb verziójú lesz (nekem 2010 van). Ha el akarjuk kerülni, hogy a fejlesztőeszközünk működését szabotálja a Windows jogosultságok címén, akkor indítsuk adminisztrátorként. A Visual Studio ezek után szépen át is konvertálja nekünk.

A neten olyan információkkal találkozni, hogy a 2008-as VS nem végzi tökéletesen a konvertálást. Ha valaki ilyet tapasztal, kövesse ezt a forrást.

A konvertált solution fájlt ezután szépen le tudjuk fordítani, eredményül kapunk egy dll-t. Ahhoz, hogy ezt a Cinema 4D elfogadja, .cdl vagy .cdl64 kiterjesztésre kell változtatni, attól függően, hogy 32 vagy 64 bites bővítményt készítünk-e. Ebben a leírásban a 32 bites rendszerrel foglalkozom csak. Ha idegenkedünk az átnevezéstől, akkor a projektünk Properties->Confoguration Properties->General->Target Extension résznél beállíthatjuk ezt a kiterjesztést.

Amint ezzel megvagyunk, a program Plugins->könyvtárnév alatt megtaláljuk a bővítményeket, amelyek most még csak a lefordított példákat tartalmazzák. Nézegessük őket!

Elkészült a textura beolvasó osztály is. Azt gondoltam, hogy ezt egyszerűen átmásolom és használom, de a rendszerek közötti különbség ismét közbeszólt. ( Egy életre megjegyeztem, hogy Windows alatt fopen(file, "rb")-vel olvasunk be bináris fájlokat. )

Először is le kellett fordítani a libpng-t Windows alá. Szerencsére csak a zlib az egyetlen függősége, és olyan jó minőségű Visual Studio projekt fájlt sikerült készíteniük, hogy a folyamat teljesen fájdalom mentes volt. Már így is eléggé elszaporodtak a release-hez csatolt DLL-ek, ezért statikusan linkeltem mindkettőt.

Ezzel a lépéssel a régi Linuxos keretrendszer teljes funkcionalitása rendelkezésemre áll C++-ban és Windows alatt. A teszteléshez a Biopunk című demónkból kivettem a patkányt és megjelenítettem. A textúra szépen feszült, a mátrixok megfelelő módon forgatták be a modellt.

Amiről nem írtam, hogy Grass is dolgozik. Elkészített két modellt. Az egyik egy környezeti elem lesz, a másik egy karakter. Nem közlök róluk képet, de higgyétek el, nagyon vagányan néznek ki. Most egy nagyobb jelenet környezetén dolgozik. Ez kicsit olyan, mintha valami mese díszlete lenne. Kiforratlan, de nekem jó lesz, hogy a következő projekten, a Cinema 4D exporteren dolgozzak vele.

Pihenni nincs idő, még rengeteg munka vár és az idő fogy.

Egyik korábbi posztom kicsit félrevezető lehet. Ott azt sugalltam, hogy de-novo szekvencia összeszerelés esetén elég egyetlen programnak megadni a szekvencia darabokat, és az megcsinál mindent, végezetül megkapjuk az összes kromoszóma teljes nukleotid sorrendjét.

A helyzet az, hogy ilyen a legritkább esetben fordul elő. Úgy is mondhatnám, én még nem találkoztam ilyennel. A legtöbb esetben több ezer hosszabb-rövidebb szekvenciát kapunk, nem ritkán N-ekkel tarkítva. Szerencsére vannak programok, melyek segítenek a további feldolgozásban.

GAPFiller

A GAPFiller, mint neve is mutatja, nem csinál mást, mint a scaffoldokban található N-eket tünteti el. A program több lépésben readeket pakol a szekvenciákra és próbálja befoltozni a lyukakat. A párosított readek távolság információit felhasználva olyan lyukakat is be tud foltozni, amelyek a readeknél hosszabbak. Megadhatjuk neki, mennyi read illesztése esetén fogadjuk el a foltozást. A scaffoldok sorrendjét nem próbálja meg meghatározni.

SSPACE

A GAPFiller alkotóinak másik programja, ami a párosított readeket használja fel arra, hogy összekösse a scaffoldokat. Segítségével kevesebb szétdarabolt szekvenciánk lesz.

Mauve

Ha van egy rokon szekvenciánk, a Mauve segítségével megnézhetjük, a scaffoldok milyen sorrendben követik egymást. Arra is kiválóan alkalmas, hogy ellenőrizzük, mennyire jó az eddigi összeszerelés. Ha ugyanis azt tapasztaljuk, hogy a scaffoldok nagy része a genom különböző pontjairól származik, jó eséllyel valamit elszúrt a de-novo program. A Mauve Java-s fejlesztés, fut minden platformon.

 Blast

Ne feledkezzünk meg a jó öreg Blastról sem. Ha csak ellenőrizni kívánunjuk egy genomi struktúra jelenlétét nincs jobb és megbízhatóbb ennél a programnál.

Bambus 2

Ezt a programot nem tudtam használni. Már a telepítése is elég bonyolult volt. Az AMOS programcsomag része. A feladata elméletileg az SSPACE-ra hasonlít. Ha csak tehetjük használjuk inkább azt. És ha csak tehetjük, ne használjuk az AMOS-t sem.

Startup cégeknél, mikor befektetőkre vadásznak, előfordul, hogy nagyobbat mondanak az emberek, mint amit kellene. Ez egyeseknek be is jön. De a művész világról nem gondoltam volna, hogy ilyen kicsinyes módszereket használna. (Bár, mint látni fogjuk, a művész megnevezése nem is állja meg a helyét.)

Miről is van szó? Adva van egy művész, aki összeszedi az utcáról az eldobott rágógumit és egyéb szemetet, amin feltételezhetően emberi DNS van, megszekvenálja, megállapítja a fenotípust, megalkotja az illető arcát, majd egy 3D nyomtatóval kinyomtatja azt. A nyomtatott maszkokból pedig kiállítást szervez.

Első olvasatra - mondjuk ki - baromság az egész. Már csak abból a tényből kiindulva, hogy nem tudjuk senki arcszerkezetét megállapítani a DNS-ének birtokában. Amire képesek vagyunk, néhány kitüntetett távolság meghatározása, vagy ha tudjuk, hogy egy genetikai betegség arcdeformációval is jár, akkor a betegségre utaló jelek esetén feltételezhetjük, hogy rendelkezik a rá jellemző arcszerkezettel.

Sajnos vagy nem, a DNS önmagában kevés a fenotípus kialakításához. Van valami, amit nagy általánosságban úgy hívnak, környezet, és ez hatással van ránk. Ha Einsteinnek pálinkás kenyeret adnak gyerekkorában minden vacsorára és mákos teával altatják, hogy ne kérdezzen annyit, akkor hülye lesz, függetlenül a génjeitől.

Azért, hogy ne legyek igazságtalan a "művésszel" szemben, elolvastam a blogján található információtöredékeket. Ezek alapján a következő kép alakult ki bennem:

1. Összeszedi a mintákat. Megjegyzem a DNS nem egy darab műanyag pohár, az bizony bomlik. Laboratóriumi munkám során volt olyan, hogy "elvesztettem" a DNS-t. (A témavezetőm nagyon örült ilyenkor.) Az történt, hogy a DNS lebomlott vagy széttöredezett.

2. Valami labormunkát végez a mintákkal. Erről nem sok mindent sikerült megtudnom. Vagy SNP chipet használ, mert egy posztban linkel egy SNP Wikit. Vagy satellitákat néz (utal rá, hogy úgy érzi magát, mint a CSI-ben). Mivel kevés a minta, a második eset a valószínűbb. Amit biztosan nem csinál: teljes genom szekvenálás. Tehát eddig nem sok értelme van a labormunkájának.

3. Futtat egy csodaprogramot. Azt állítja, hogy írt valami tanuló algoritmust MATLAB-ban (bár a program nevét következetesen kisbetűvel írja) és BioPythonban (ha nem használna valami bio vackot, el sem hinném, hogy szekvenciákkal dolgozik).

4. Kinyomtat egy arcot az ingyenesen elérhető arc adatbázisból. Persze azt állítja, hogy az adatbázist csak tréning adatnak használja, de miféle tréning adat az, ahol hiányzik a genotípus?

Már csak azt nem értem, hol a művészet? A BioPython kódban? A szabvány kitekkel végzett laboratóriumi munkában? Talán abban, hogy ezt a sok hülyeséget el tudja adni.

Sajnos nem úgy haladok a produkcióval, mint terveztem. Elkészült a mátrix kezelő osztály és az OBJ betöltő. Nem hangzik soknak? Azért nem nem sok.

Mivel nem csak átmásoltam a C kódot, hanem felül is vizsgáltam, érdekes jelenségekre lettem figyelmes:

1. A Windows nem programozó barát

Gyakran hallani, hogy egyes alkalmazások felhasználó barátok, mások nem. De létezik a számítógép felhasználóknak egy másik faja, akik programokat alkotnak. Azt gondoltam, egy programozónak nem kell igényeket támasztania az operációs rendszer felé, csak adni neki egy szövegszerkesztőt, egy fordítót, és időt, hogy dolgozzon. De most, hogy Windows alatt szerencsétlenkedem, rájöttem, hogy igen is van igényem az operációs rendszer felé. Először is, legyenek a fejléc állományok egy helyen. Ahány SDK-t telepítek, az annyi helyre szórja szét a fejléc állományokat és könyvtárakat. Az elérési utak hosszúak, hülye karakterek vannak bennük, amiket más hülye karakterekkel semlegesítek. Hiányoznak a szkriptek és egyéb automatizáló eljárások.

Vicces, mert míg Linux alatt dolgoztam, soha nem gondoltam arra, hogy nekem szükségem lenne egy nagy IDE-re. Windows alatt Visual Studio nélkül halott lennék. Ennek a hatalmas böszme koloncnak nincs más dolga, minthogy az ellenséges operációs rendszer elé egy függönyt húzzon és megadjon nekem mindent, amire szükségem van.

2. A GNU lustává tesz

Ez az igazság. Annyi kóder nyalóka függvény van a glibc-ben, hogy teljesen a hatásuk alá kerültem. Azokra a függvényekre gondolok, amelyek egyáltalán nem bonyolultak, de valami unalmas, rutinjellegű feladatot megoldanak. Például getline, strsep. Windows alatt ezeknek írmagjuk sincs, mert nem részei semmilyen standardnak. De ahelyett, hogy fél óra alatt leprogramoznám őket, két órán keresztül a guglit nyúzom és olvasom a többi, hozzám hasonló lusta ember nyavajgását, hogy miért nincs ilyen Windows alatt.

3. A változatosság jótékony hatású

Itt arra gondolok, hogy akár mennyi szenvedéssel is jár most még a kódolás Windows alatt, jó, hogy látok mást is a parancssor mellett. Tágítja a látóteremet. Ez persze igaz az egész demoscenére. Hiszen egy cégnél a főnök megmondja, mit kell csinálni, a projekt vezető előírja, mikorra legyen kész. A vezető fejlesztő meghatározza, milyen eszközöket kell használni, végül a tesztelő rámutat, hogy mit kell kijavítani. Egy demó készítésénél viszont senki nem ír elő semmit. A cégnél akkor jó az ember, ha minél gyorsabban, minél kevesebb időráfordítással old meg valamit. A partikon ellenben értékelik, ha valaki egy nehéz kihívást vállal. (Ezzel nem akarom azt sugallni, hogy a Visual Studio kihívás. Egyáltalán nem az.)

4. Platform függetlenség nem létezik

A math.h-ból akartam az M_PI konstanst. Windows alatt még be kell írni, hogy #define _USE_MATH_DEFINES. Több szót nem is érdemes fecsérelni erre.

Baráti beszélgetések alkalmával gyakran terelődik a filmekre a szó. Ilyenkor megkérdezik, hogy láttam-e X filmet.

- Nem láttam - felelem a legtöbbször.

- Pedig az nagyon jó, neked is biztosan tetszene. Nézd meg feltétlenül.

Nem fogom megnézni a filmet. Egyrészt sajnálom rá azt a két órát, az utazásról nem is beszélve, amíg eljutok a moziig. Még a DVD kölcsönző felkeresése is plusz idő, amit akár demók kódolásával, cikkek olvasásával is tölthetek, ráadásul utóbbiak sokkal szórakoztatóbbak.

De nem volt ez mindig így. Régen én is faltam a filmeket, olvastam a fórumokat és listát vezettem a várható premierekről. Azután azt vettem észre, hogy egyre kevesebb feljegyzést készítek, alig olvasom a fórumokat, ha meg megnézek egy filmet, azt is unom. Mi történhetett?

Végül is mit kapunk egy tipikus hollywoodi filmtől? A valóság egy szűkített, eltúlzott képét. Képtelen történeteket, végleteket, az események sarkosítását. De ugyan ezt kapom, ha a rokonaimmal/ismerőseimmel beszélgetek! Annyi furcsa, szürreális történetet mesélnek, hogy néha nem tudom, én vagyok nagyon naív a világgal kapcsolatban, vagy tényleg a káosz uralkodik az életünkön.

Ezeket a történeteket is kategóriákba lehet sorolni, akár csak a filmeket:

Akció: "Ezek már az egész IV. kerületet megvásárolták. A géppisztolyos őrök nem engednek be senkit, aki nem közéjük tartozik."

Krimi: "A kínai áruházban elaltatták a nőt. Már majdnem kivették a veséjét, de az volt a szerencséje, hogy a férje bement az áruházba." (úgy tűnik, ezt mások is ismerik)

Sci-fi: "Ha egy terhes nőnek csúcsos hasa van, fiút fog szülni."

Horror: "Az anyuka egyszer megkívánta a szőlőt és az arcához kapott. Mikor megszületett a lánya, az arcán szőlőfürt-szerű anyajegy volt. Mi mind tudtuk, hogy miért."

Fantasy: "Én megálmodtam a halálát. Azt álmodtam, hogy egy tóban fürdött és integetett nekem. Azonnal felébredtem és rögtön tudtam, hogy meghalt."

De a legdurvább történeteket egy olyan volt munkatársam mesélte, aki szerintem skizofrén volt. Az első két története még érdekes volt. A második kettő meghökkentő, de mivel mindig készségesen meghallgattam, rámszabadította a fél Alkonyzónát. Élettörténete röviden:

Tíz évesen segített az apjának házakat tervezni, némelyik olyan jól sikerült, hogy tényleg megépítették. Tizenkét éves korába freskókat festett, mert olyan jól rajzolt, hogy a helyi lelkész megkérte, fessen a templom falára. Harmadikos szakközépiskolás korában a negyedikeseket tanította elektrotechnikából, mert a tanár épp nem ért rá. Még egyetem előtt ipari robotokat programozott, amivel az üzem hatékonyságát sikerült 20%-al növelnie. Annyi pénzt kapott, hogy egy földet vett, de ezzel kivívta a helyi maffia-kapcsolatokkal rendelkező ügyvéd haragját, aki be is perelte. Egyetlen ügyvéd sem vállalta el az ügyét, ezért úgy döntött, majd ő védi magát a tárgyaláson. Természetesen megnyerte a pert. Az egyetemen orosz fegyverfejlesztési kutatók oktatták, és hívták őt is csillagháborús projektekbe, de pacifizmusa nem engedte, hogy ilyen tevékenységbe vegyen részt.

Egyetem után besorozták, de megtagadta a szolgálatot és szökevény lett. Később a New York-i metró irányítórendszerét programozta egy kis csapatban, majd bankokban dolgozott, mint programozó. Szabadidejében pénzügyi könyveket olvasott, aminek hatására két hónappal előre tudta jelezni a gazdasági válságot és meghozta a szükséges óvintézkedéseket.

Elmondta, hogyan tehetünk szert paramépességekre és azt is elmagyarázta nekem, mi az epigenetika, mert én biztos nem hallottam róla, annyira új felfedezés ( a New York Times tudományos mellékletében olvasta, az sokkal megbízhatóbb forrás, mint a Nature vagy Science).

Ezek után kinek kellenek filmek?

A minap ismét a Trinityvel dolgoztam, és egy olyan szkriptnevet kellett beírnom, aminek a neve 54 karakterből állt. Rövid keresgélés után kiderült, hogy ez még nem is a csúcstartó. A gmap_gff3_to_percent_length_stats.count_mapped_transcripts.pl (61 karakter) volt a leghosszabb. Ha bárki tud olyan széles körben elterjedt alkalmazásról, ahol ennél hosszabb a szkript neve, azonnal tudassa a hozzászólások között.

A megmérettetésben csak olyan alkalmazások szerepelhetnek, amelyeket publikáltak vagy kereskedelmi forgalomba hoztak. Ha egy olvasó suttyomban készít valamit és felrakja a GitHubra, az nem számít.

Nemrég egy olyan fajjal dolgoztam, ahol még nincs referencia genom. Az eredmények érdekében több de-novo metódussal dolgoztunk, többek között a Trinityvel, hogy összeállíthassuk a faj transzkriptómját. Eredményül kaptunk is egy csomó szekvenciát, ami önmagában nem sok segítség a kísérletes biológusoknak. Ezért elkezdtem dolgozni a szekvenciák annotálásán.

Mikor végeztem, furcsa érzés fogott el. Én már tudtam, mi a szerepük az egyes szekvenciáknak, de rajtam kívül még senki. Legjobb tudásom szerint senki a világon. Kicsit hazug elképzelés, mert bizonyára több kutatócsoport is dolgozik ezen a témán, talán már épp a cikket gépelik, vagy arra várnak, hogy elfogadják azt. De erre akkor nem gondoltam. Örömömben elmondtam ezt az egyik asszisztensnek, aki megvonta a vállát és csak annyit mondott:

- Lefuttattál egy programot? Ezt bárki meg tudja csinálni.

Ez elég kijózanítóan hatott. Nézzük is meg, mi az, amit bárki meg tud csinálni.

A Trinityhez tartozik egy annotációs rendszer, a Trinotate. A program futásához további programok kellenek: Blast, HMMER, signalIP, tmHMM. Adatbázisok: SwissProt, PFam.

A gondot a signalIP és tmHMM okozta. Elvileg ingyen megkaphatja őket minden akadémiai kutató, de ennek a kutatóintézet domain nevének szerepelnie kell egy listán. Ha nincs fent, nem tudja letölteni. (GMail, Hotmail nem használható). Mondanom sem kell, mi nem voltunk a listán. Írtam nekik, hogy vegyenek fel, de nem válaszoltak semmit. Öt nap múlva újra írtam nekik, de most sem válaszoltak. Szerencsére felsorolták, hogy mely domainek vannak náluk bejegyezve. Elkezdtem nyomozni, hogy kinek az ismerősének az ismerőse dolgozik az adott helyeken. Kb. fél óra múlva megvolt a kapcsolat, aki letöltötte és elküldte nekem. Közben, hogy legyen tartalék terv is, összeszedtem az oldalról az összes e-mail címet, amit csak találtam. Webmestertől kezdve a portásig mindent és mindenkinek elküldtem a levelem, hogy bocs, de kell a program.

Erre már felfigyeltek. Végül két forrásból is meglettek a programok. De sajnos nem úgy működtek, mint a dokumentációban. Pontosabban sehogy nem működtek. Ekkor megnéztem a forráskódot. Kiderült, hogy a két program nem más, mint Perl szkriptek. (Na jó, a tmHMM-ben van valami C kód is). Belemásztam a kódba, hogy mégis miért nem futnak. A programokba beépített elérési útvonalak voltak kódolva, amitől kizárt dolog, hogy azonnal működjenek.

A doksi ugyancsak nem említette, hogy a signalIP-ből melyik eredményt kell felhasználni, a tmHMM eredményéből pedig el kell távolítani a fejlécet. Mikor ezekkel megvoltam, már kaptam is eredményt.

Ez még csak az én részem volt a folyamatból. Arról se feledkezzünk meg, hogy a szekvenciákhoz is rengeteg munka kellett. Fel kellett nevelni az élőlényeket, mintát kellett venni és meg kellett azokat szekvenálni. Talán nem árulok el nagy titkot, ha azt mondom, hogy ehhez az intézetben négy csoport adta a pénzt. Talán joggal gondolom azt, hogy ezt nem tudja bárki megcsinálni. (Az említett asszisztens eddigi hőstettei alapján biztosan nem képes rá.)

Bevallom, van valami hipnotikus a körbe rendezett genomi adatok látványában. A genomi átrendeződések kivételével nem hordoznak plusz információt, mégis, ha körbe rendezett kromoszómákat nézek, úgy érzem, sokkal tudományosabb munkát látok.

A program, amivel mindezt elő lehet állítani, a Circos. Ez a Perl nyelven írt program olyan naggyá nőtte ki magát, hogy a Nature talán nem is fogad el olyan cikket, amiben nem ezzel készültek az ábrák.

A program beolvas egy konfigurációs állományt és az ott található paraméterek alapján elkészíti az ábrát. Ha úgy döntünk, hogy magunk írjuk meg ezt az állományt, akkor nem árt, ha odatesszük magunk mellé a dokumentációt, mert szinte nincsenek benne alapértelmezett értékek. Ha egy tulajdonság csoportot létrehozunk, akkor az osszes paramétert be kell állítani, különben nem az jelenik meg, amit mi szeretnénk. Lássuk, hogyan is kezdjük.

A konfigurációs állományban alapvetően kulcs-érték párokat kell beállítani. Ha a tulajdonságokat több, azonos grafikai objektumon is be kell állítani, akkor XML szerű elválasztó tageket használunk.

Az első és legfontosabb paraméter a kariotípus (karyotype) beállítására szolgál. Mivel elsősorban genomi információk megjelentítésére szolgál, ez nem meglepő. Az, hogy mit tekinthetünk kariotípusnak, annál inkább. A programot ugyanis előszeretettel használják nem-genomi adatok megjelenítésére is. (Bizonyára másokat is hipnotizál, ha körbe rendezik adataikat)

A kariotípus egy szóközzel elválasztott táblázat. Első két oszlopa chr és '-'. Utána következik egy egyedi azonsító, majd a szöveg, ami megjelenik a képünkön. A kromoszóma méretét két koordinátával adhatjuk meg., végül egy szín azonosító.

A kariotípus megadása után következik az ideogram (<ideogram>) tulajdonságainak megadása. Ez kromoszómák megjelenítésének egyfajta globális beállítása. Megadhatjuk, mekkora kört képezzünk kromoszómáinkból, mekkora távolság legyen közöttük, legyenek-e kitöltve, stb.

A másik lényeges tulajdonságcsoport a kép (<image>). Itt a fájllal kapcsolatos tulajdonságokat állíthatjuk be. Például mekkora legyen a kész kép és mi legyen a fájl neve.

Sajnos a nagy számú paraméter miatt kezdeti lelkesedésünk a körbe rendezett kromoszómák iránt gyorsan lelankad. Ezt a program szerzője is felismerte, ezért a <<include >> paranccsal ajándékozott meg minket (valamint rengeteg konfigurációs állománnyal, hogy mégis legyen valami segítség, hamár alapértelmezett beállítások nincsenek.)

A színeket, betűtípusokat és egyéb apróságokat ezért egyszerűen csak beillesztjük. Ha a programot Ubuntu csomagkezelőjével telepítjük, az /etc/circos könyvtárban találjuk a segítséget.

Természetesen azok számára is van segítség, akik nem akarnak konfigurációs fájlokkal bajlódni. A program rengeteg szkripttel érkezik, amelyek gyorsan és fájdalommentesen készítik a köröket.

A cufflinks egy remek program, hogy a szekvenálásokból megállapítsuk, melyek lehetnek a kódoló régiók. Sajnos a program több, egymással összefüggő táblázatot generál, aminek a feldolgozása nem egyszerű feladat. Szerencsére az R programcsomag ismét a segítségünkre siet.

A cummeRbund csomag segítségével könnyen felderíthetjük a hatalmas adat mögött megbúvó összefüggéseket. Első lépésként töltsük be az adatokat:

library(cummeRbund)
adat = readCufflinks(dir="directory", genome="genom.fasta", gtfFile="annotacio", rebuild=T)


A parancs hatására adatainkat az adat változóval érhetjük el. A directory a cufflinks eredményeink kimeneti könyvtára. A genome.fasta az elemzéshez felhasznált genom, míg a gtfFile paraméterrel adhatjuk meg azt ismert transzkriptek annotációját. Amit nem látunk, az egy adatbázis generálás a háttérben. A szöveges állományok a gyorsabb kereshetőség érdekében egy SQLite adatbázisba lesznek elmentve. Ennek helye a directory-ban lesz.

Használata annyira egyszerű, hogy nem is kell érteni az R-hez, ha szép képeket és táblázatokat akarunk készíteni. Például ha normalizált expressziós értékek eloszlására vagyunk kíváncsiak, nem kell mást tenni, csak kiadni a

dens <- csDenstity(genes(adat))
dens


parancsot. A legtöbb parancs egyből rajzolja is az ábrákat. Annyira egyszerű használni, hogy csak a dokumentációt tudom ismételni. De hogy valami olyasmit is mutassak, ami nincs leírva a dokumentációba, nézzük, hogyan lehet az unalmas cufflinks azonosítókat gén szimbólumokra cserélni.

Az eredményül kapott szignifikáns gének neve ilyen furcsa karakterekkel kezdődik: XLOC_. Ha ezt egy biológus kezébe nyomjuk, az sikítani fog. Az annotáció segítségével viszont kicserélhetjük gén nevekre.

annot <- annotation(genes(adat))
sig.data <- as.data.frame(getSigTable(adat, alpha=0.05, level="genes"))
sig.data$gene_id <- row.names(sig.data)
sig.with.annot <- merge(annot, sig.data, all.y=T)


Mit csinál ez a kód? Először is létrehoz két data.frame típusú változót. Az egyik neve annot, a másiké sig.data. Az annot-nak van egy gene_id nevű oszlopa, ezt létrehozzuk a sig.data-ban is. Ezután a merge paranccsal összefűzzük őket. Az all.y segít, hogy ne veszítsünk adatot a sig.data-ból. Alapértelmezetten ugyanis a merge a két halmaz metszetét adja vissza.

Egy másik trükkel azt mutatom be, miként lehet GO analízist végezni. Ha olyan fajjal dolgozunk, amelynek megtalálható az annotációja a Bioconductorban, nincs nehéz dolgunk (ha nem található meg, az gáz):

go <- toTable(org.Hs.egGO)           # get GO ids
go$term <- Term(go$go_id)            # get GO terms
lipid <- go[grep("lipid", go$term),] # get GO ids by keyword
sym <- toTable(org.Hs.egSYMBOL)      # get all the gene symbols
lipidsym <- merge(lipid, sym)        # now the table contains
                                       genesymbols, GO terms and GO IDs
x <- merge(lipidsym, annot, by.x = "symbol", by.y = "gene_short_name") #
                                       put XLOC names into the mess
lipidgenes <- x$gene_id.y
lipidgenes <- getGenes(adat, lipidgenes) # select genes from
                                           expression data
x <- expressionPlot(lipidgenes)


A kód működéséhez be kell tölteni a GO.db és az org.Hs.eg könyvtárakat. Ha más fajjal dolgozunk, akkor természetesen az adott fajnak megfelelő annotációs könyvtárra van szükségünk. Először táblázattá alakítjuk a GO annotációt, és hozzáfűzzük a táblázathoz a leírásokat. A grep parancs segítségével kiválasztjuk a minket érdeklő GO kategóriákat. Az annotációból kiszedjük a gén szimbólumokat. Erre a lépésre azért van szükség, mert ez az adat képez kapcsolatot a cummeRbund-os eredmények és a GO annotáció között. A két merge segítségével összefűzűnk minden adatot, kiválasztjuk a cummeRbund-os azonosítókat és máris van egy génlistánk GO alapján. Végül megnézzük az expressziós profilját a listánknak.

Remélem mindenki kedvet kapott a cummeRbundhoz.

Ha Húsvét, akkor Revision. Ez nem is lehet kérdés. Jelen összeállításomban kiragadok néhány számomra kedves példát a release-k közül és röviden leírom, miért is tetszettek.

Amiga

Mivel is lehetne kezdeni, mint az Amigás releasekkel? Számomra az Elude vitte a pálmát. Ez a csapat ugyanis mindig olyan effektet hoz létre, ami megdöbbentő. Most például depth-of-field-el és karakter animációval örvendeztettek meg minket. Sokat kritizálják őket, hogy demóik nem koherensek, de szerencsére ez nem tántorítja el őket attól, hogy továbbra is fantasztikus demókkal árasszanak el minket. Bevallom, tavaly a Kakao után megijedtem, hogy beszüntetik tevékenységüket, de szerencsére a félelmem alaptalan volt. Akinek nincs szénné tuningolt 1200-ese vagy MorphOS-e, annak álljon itt a videó:

A másik kedvenc Moods Plateau Stealth Ranger-e. Nem sűrűn fordul elő, hogy egy egész demót dedikálnak valakinek, pláne olyan embernek, akit személyesen is ismerek. Charlie a Skoda és az Amigák nagy fanatikusa, (sorrendet nehezen tudnék megállapítani) aki minden évben komoly munkát végez azért, hogy az Amigás releasek zökkenőmentesen lemenjenek. Rójuk le mi is tiszteletünket azzal, hogy megnézzük ezt a demót:

Animációk

Az animációk közül csak egyet emelnék ki, a "Turtles all the way down"-t. Csak annyit mondok, fraktálokból soha nem elég:

64k

Az introk közül szintén a "Turtles all the way down" című tetszett, de ezt a Brain Control követte el. Mint biológiához közeli embernek, csak két kifogásom van: a vörösvértesteknek nincs DNS-ük, a fejlábúaknak pedig vörösvérteste.

Demók

Azt kell, hogy mondjam, Smash idén állva hagyta a mezőnyt, már ami a kódot illeti. Valós idejű raytracing, törésmodell és fénytörés szerepel a Fairlight demójában. Raytracing? Nagy cucc, már több, mint 10 éve láttunk ilyet demókban. Szeretném felhívni a figyelmet, hogy itt a fény színekre bomlik, mint a prizmáknál. A fénytörést nem gömbökre számolták, hanem egy összetett modellre. Engem nagyon zavart, hogy várost nehezen láttam, mert minden tükröződött. Néha nem értettem, a piramis olvad, vagy üreg képződik benne, de a látvány bőven kárpótol minket minden ilyen furcsa jelenségért.

Cocoon ismét egy futurisztikus gyárba kalauzol minket, de most embereket raknak össze furcsa forgó golyók. Tetszik a demó dinamizmusa. Ez egyébként a csapatra jellemző. Ami hiányzott, Willbe fantasztikus zenéje. Nem mintha H0ffman kompozíciója rossz lenne, de mintha már hallottam volna a SceneSat-on.

Nuance mindig az élmezőnyben végez, de nyerni szinte csak az Ultimate Meetingen tudnak. Figyelni szoktam az alkotásaikat, mert bár az egész demójuk nem szokott teljesen magával ragadni, mindig akad egy momentum, egy jelenet, amit élvezettel nézek. Itt például az tetszett, mikor a rovarfejű ember démonná alakul.

Panda Cube híres a monumentális alkotásokról, ami hasonló a Cocoon demókban látottakhoz, de kevesebb dinamika van bennük. Meg is kapják érte a magukét a fórumokon, ahol azzal vádolják őket, hogy csak flyby demókat készítenek. Én szeretem ezt a stílust is, de idén elég vérszegényre sikeredett mindez. Büntetésül nem kapnak linket :-)

Előadások

A demók csak egy részét képezik a partinak. A másik fontos rész az előadások. Ha az ember figyel, még talán tanul is valamit. Mivel én elég gyatra szépérzékkel vagyok megáldva, érdeklődöm minden olyan iránt, amit segít a vizuális tartalom összeállításában. Ezért is érdekes ez a kameráról és színösszeállításról is szóló előadás:

A másik témakör, amiben fejlesztenem kell magam, a kódolás. Ezért is érdekes ez az OpenGL fényeivel foglalkozó előadás:

Egy bébi-projektemről szeretném lerántani a leplet. Észrevételeim alapján a biológusok még mindig a Microsoft Word programot használják a szekvenciák feldolgozásra. Sajnos a programnak van pár olyan hiányossága, ami megnehezíti a bioinformatikai munkát, ezért pár hónapja elkezdtem írni egy makrót, ami megpróbálja növelni a munka hatékonyságát.

Az első probléma, hogy a szöveg keresés nem működik sortörés esetén. Miután ezt kiküszöböltem, gondoltam jó ötlet lenne Perl kompatibilis reguláris kifejezéseket is használni. Ezt elég nehéz volt implementálni, de nagyrészt sikerült. Ebben sokat támaszkodtam a következő VBScriptre.

A fehérjére fordítás és restrikciós enzim térképezés könnyed ujjgyakorlat volt. BAM beolvasás kicsit bonyolultabb, azt későbbre halasztom, de SAM importot építettem bele. Amit szeretnék még, egy Burrows-Wheeler illesztő. Az egyik dokumentumban lenne a referencia, a másikban a readek. Performanciában nyilván elmaradna a BWA-tól, de kisebb adatszettekre, gyors ellenőrzésre szerintem használható lenne.

Még sok fejleszteni való van vissza, hibák is akadnak szép számmal. Például ha az oldalbeállítás nem megfelelő, és emiatt a Fasta fejléc két sorba kerül, akkor lefagy a makró, és magával rántja a Wordöt is. Ezért a biztonság kedvéért fekvő A4 oldalt használjunk. Aki kíváncsi, letöltheti a sablont innen.

Ezt a képet az intézet ablakából készítettem. A nyúl megpróbál bekommandózni.

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.