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.

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.