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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Van kérdésed?

- Igen. Miért engem?

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

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

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

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

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

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

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

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

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

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

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

CNVer 0.8.1

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

Mr. Canavar 0.41

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

Contra 2.0.3

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

FREEC 5.7

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

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

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

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

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

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

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

setenv server-ip 192.168.1.10
setenv client-ip 192.168.1.12


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

boot eth:morphos.img

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

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

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

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

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

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

A modul nevén alapuló konvenció

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

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

Asszociatív tömbök

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

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

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

  return $item;
}


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

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

Formok

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

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

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


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

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

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

  return $form;
}


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

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

A cél

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

A terv

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

Fejlesztés

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

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

A használata így néz ki:

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

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

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


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

freeRenderer();

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

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

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

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

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

Coefficients:
(Intercept)          num  
     70.314        1.739

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

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

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

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

Problémák:

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

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

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

float aspect = 16.0 / 9.0;
float newheight;

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

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

glViewport(0, 0, width, newheight);


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

import net.sf.samtools.*;


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

SAMFileReader.setDefaultValidationStringency(
         SAMFileReader.ValidationStringency.SILENT);

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Még tegnap este megnéztem kedvenc marketingesünk laptopját, mert állítólag elromlott. Az elromlott azt szokta jelenteni, hogy nem azt csinálja, amit a tulaj szeretne, ezért erős fenntartásokkal fogadtam a tüneteket. Végül sikerült megállapítani, hogy tele van a merevlemez hibás blokkokkal, ami lelassította a rendszerindítást. Egy éjszakán keresztül igyekezett a kis gép kijavítani a hibás szektorokat, de végül alul maradt.

Reggel a laptop tulaja úgy nézett ki a kávéja nélkül, mint egy zombi. Fel is ajánlottam neki egy szerepet még el nem készült poszt-apokaliptikus filmemben. De természetesen a legfontosabbak az előadások, így térjünk át ezekre.

A klinikai SNP keresés nagyban eltér a hagyományos kutatásban megismert módszerektől. Erről szólt az első előadás is. Az exome szekvenálás költséghatékony módja a variációk felderítésének, de felmerül a kérdés, vajon a szekvenálások mennyire befolyásolják a végeredményt? A vizsgálatok során a Complete Genomics és az Illumina szekvenálásokból kerestek variációkat. BWA-t, SOAP-Alignert használtak illesztésekhez és SOAPsnp-t, SOAPindelt, GATK-t, Samtoolst, SNPvert, GNUMAP-SNP-t SNPk és indelek azonosítására. A jó hír, hogy a variációk legtöbbjét mindegyik módszerrel meg lehet találni, de a gond azok a variációk, amelyek csak egyik vagy másik módszerrel találhatóak csak meg. A szekvenálás lefedettségének növelése sem megoldás, mert ezzel csökkennek ugyan a csak Illuminával megtalálható variációk (ez fals pozitívok jelenlétére utal), de a grafikonokból én azt láttam, hogy a Complete Genomics szekvenálásainál viszont növekedtek a variációk (ami viszont azt jelenti szerintem, hogy a valódi pozitívok száma alacsony). A részletek ebben a cikkben olvashatóak.

Ez után a depressziós előadás után egy kicsit vidámabb következett. Az előadó elmondta, hogy náluk azért működik az exome szekvenálás, az előzőekben hallott problémák ellenében. Erre hozott példákat is. Az egyik egy hibásan diagnosztizált egyén jó diagnosztizálása, a másik egy régi eset megoldása volt. Ennek ellenére nem tudja, hogy mennyire hatékony az exome szekvenálás, mert ők nagyon speciális eseteket dolgoztak fel. A norvég törvények nagyon szigorúak a humán klinikai minták biztonságával szemben, ezért náluk szóba sem jöhet semmilyen felhő alapú szolgáltatás. Előadás után megkérdzték tőle, hogy mi a véleménye a PacBio szekvenátorról. Azt válaszolta, hogy nagyon alacsony az áteresztő képessége, ami manapság már nem elegendő. A jövőre vonatkozóan annyit mondott, hogy kíváncsian várja a MinION USB-re csatlakoztatható szekvenálót.

Meghallgattam az IBM előadását is, így már képben vagyok, mire is van szüksége egy bioinformatikusnak. Az IBM hihetetlen mennyiségű számítási kapacitást és performanciát igyekszik a kutatók rendelkezésére bocsátani. Mit is jelent ez? 7,5 terabájt memóriát, Intel csúcsprocesszorokat (Sandy Bridge külön kihangsúlyozva). Ha valaki azt kifogásolná, hogy korunk bioinformatikai kihívásai I/O érzékenyek, azok megkapják a GPFS fájlrendszert. A ScaleMP már csak hab a tortán. Természetesen a bioinformatikust nem érdeklik a technológiai részletek, ezért a CLC-vel karöltve előre telepített vackok... izé bioinformatikus alkalmazások vannak. Személy szerint nem tetszett az erőforrások teljesen felesleges felhalmozása. 47 másodperc humán de-novo? Mire jó ez?

Hallgattam még egy klinikai sikertörténetet is, ahol az életkorfüggő fibropoliferatív repair genetikai okait keresték. Ez ugyanis az életkor előrehaladásával csökkenti egyes szervek működőképességét. Modellorganizmusnak transzgenikus egereket használtak, ahol genetikai targeteket igyekeztek keresni. Embereken észrevették, hogy a közös fenotípus mögött eltérő okok húzódnak. Egyes típust könnyebb azonosítani DNS típizálással, míg másokat mRNS mintázatuk alapján egyszerűbb meghatározni.

Egy másik klinikai diagnosztikai előadás arról beszélt, hogy ők még mindig Sangert használnak, mert náluk a cél, hogy minél kevesebb hibát ejtsenek a vizsgálatok során. Így is 10% körüli az emberi tényező okozta hiba. Ezt úgy igyekeznek csökkenteni, hogy két, egymástól független szakértő is elvégzi az elemzést. (Ezt egyébként a riportjukban is feltűntetik). A genetikai variációk feltételezett hatását a következő programokkal igyekeznek felderíteni: snps3d, sift, polyphen, pmut, panther. Természetesen mozdulni akarnak az újgenerációs szekvenálások irányába. Jelenleg egy CGC LIMS programot használnak, de KIWI néven egy új programot fejlesztenek GWT alapokon, Java EE szerverrel és MySQL liquibase adatbázissal. A forráskódot Mavennel rázzák gatyába.

Az utolsó klinikai diagnosztikával foglalkozó előadást azzal kezdték, hogy elég ritka, hogy egy genetikai eredetű betegség esetén, ha meg is szekvenálják a beteget, kiterjesztik a vizsgálatot más génekre, vagy rokonokra. XworX platformon fejlesztenek munkafolyamatot MutAid néven. Ez az eszköz inkább csak a funkcionális annotációban és a riport készítésében segít, mint a konkrét genetikai okok felderítésében.

Az IBM másik előadásán a hibrid architektúrájú felhőkről beszéltek. Valós időben akarnak elemzéseket végezni, vezeték nélküli nanoszenzorokból érkező adatokon. A beérkező adatokat pedig az örökkévalóságig tárolni. A hibrid architektúra azt jelenti, hogy vannak feldolgozás központú csomópontok, erős GPU-val, kis merevlemezzel, és I/O-ban erős csomópontok, de gyengébb processzorral. A csomópontok Hadoop-al, Oozival, Zookeeperrel vannak felhővé varázsolva.

A nap utolsó előtti előadása egy álomról szólt. Az EMIF projekt olyan új, hogy még weboldala sincs. Pontosan nem is értem mi lesz a lényege, de szeretnének egy platformot, ahol összegyűjtik a klinikai információkat és megosztják azokat, majd levonják a nagy következtetéseket.

A farmakogenomikáról szólt az utolsó előadás, illetve arról, hogy milyen eszközöket fejlesztettek, ami még farmakogenomikához is használható. Az egyik a FindBase, ami demoeffekt-szerűen vizualizálja a keresési eredményeket. Mutációs függőségi gráfokat is tartalmaz. A másik termék a Goldenhelix.

A kiállítok között feltűnt a Virtalis. Kiraktak egy 3D projektort, aktív szemüveggel egy PyMol segítségével megjelenítettek egy modellt és megpróbálták elmagyarázni, hogy ez a jövő. Azért, mert a filmeket már nem tudják eladni 3D nélkül, az nem jelenti azt, hogy ettől jobban fog menni a tudomány. Beszélgettem egy kémikussal, aki szintén a kiállítók között volt. Szerinte, például a fehérje szerkezeti vizsgálatnál teljesen felesleges a 3D vizualizálás, mert nem az a lényeg. Egyetértettem vele.

A vonat sebesen szeli át az országot, hogy elérjen Bécsbe, a BioIT World konferencia színhelyére. A cég, amelynek alkalmazásában állok, itt akarja népszerűsíteni legújabb termékét, nekem meg sikerült kiharcolnom, hogy eljöhessek én is. Az eljövetel egyik feltétele az volt, hogy végighallgassak egy értékesítési fejtágítót, amit egy igazi "értékesítő zseni" tartott.

A modern időknek megfelelően az előadó és a hallgatók egyike sem tartózkodott 20km-nél közelebb egymáshoz, ezért ahogy közeledett az idő, egyre biztosabb voltam benne, hogy ez valami távoktatás jellegű dolog lesz. Habár szinte mindenki, aki nálunk dolgozik, Linuxot használ, nagyjából 5 perccel az előadás előtt derült ki, hogy GotoMeetingre lesz szüksége annak, aki meg akarja hallgatni azt. Mondanom sem kell, ez az a fajta Java alapú program, ami nem támogatja a Linuxot. Negyed óra szerencsétlenkedés után Skype-ra tértünk.

Az előadás abból állt, hogy az értékesítő zseni hangja percenként elhalkult, amit rögtön a marketingesünk ordítása követett: Nem hallak, nem hallak! Talán attól félt, hogy ő is elhalkul, ezért ordított. Ennél a pontnál kikapcsoltam a mikrofonomat, hogy ne hallják a nevetésemet.

Nem előadás az előadás, ha nincs prezentáció. Ezt e-mailen kaptuk meg, hogy nézzük, miközben hallgatjuk a marketinges kétségbeesett kapcsolat-fenntartó kiáltásait. Ez egy PowerPoint fájlt volt, amit egyedül mi, Linuxosok tudtunk megnyitni. Talán nem okozok nagy meglepetést azzal, hogy elárulom, a marketingesünk Windowst futtat. Habár korlátozott képességekkel a GMail is meg tudja nyitni ezt a fajta állományt, újabb tíz perc úszott el azzal, hogy DropBoxon keresztül újra elküldték neki a fájlt, amit csodák csodája, így sem tudott megnyitni. Hiába, a fájl megyithatósága nem az elküldés módjától függ.

Ezt leszámítva elég eseménytelen volt az előadás. A legfontosabb üzenet: kérdezzünk, hagyjuk a potenciális vevőt beszélni, tudjuk meg, mire van szüksége.

Mivel ez egy tudományos konferencia is, ezért vittünk egy nagyon tudományos posztert is. A többi bioinformatikussal beszélgetve számomra kiderült, hogy ezt a posztert egyetlen tudománnyal foglalkozó ember sem látta. De látták a menedzserek, marketingesek, igazgatók, sőt ők készítették. Remélem a konferencián legalább én is megnézhetem. Holott homályosan emlékszem, hogy voltam egy megbeszélésen, ahol ezt a posztert akartuk megvitatni. De csak addig jutottunk, hogy milyen betűtípussal legyen elkészítve a táblázat. Azért a nyers adatok feldogozásában benne volt a kezem.

Azért nem lehet okom panaszra. A csapatból nekem engedték meg egyedül, hogy meghallgassam az előadásokat. Igyekszem beszámolni az új trendekről, érdekes vizsgálatokról és minden egyébről, mi valamilyen okból felkeltette az érdeklődésemet.

Ennyi bevezető után lássuk, mit is tartogatott az első nap, ami valójában a második, mert az első napon nem voltam. Az előadások két szekcióban folytak. Az első a klinikai szekció volt, míg a második az IT témájú előadásokat foglalta magába.

Az első előadás az epigenetikus biomarkerekről szólt. Az epigenom változásai a hiszton modifikáción keresztül komplex betegségeket okozhatnak. Mindezt akár egészséges genotípus mellett is. Az epigenetikus regulátorok (pl. TET2, EZH2) mutációja különböző rákos megbetegedésekhez vezetnek, de hatásuk reverzibilisen visszafordítható különböző gyógyszeres kezelésekkel. Az epigenom vizsgálata az előadás tanúsága szerint olyan metasztatikus karcinómáknál is hasznos lehet, ahol az elsődleges gócpont nem ismert. Az előadás azt is taglalta, milyen szerepe lehet az epigenomnak a személyre szabott gyógyászatban.

Az OpenBEL megoldja a szervezeteken belüli tudás megszerzését, megosztását. Az előadást nem hallottam, csak az utolsó diát láttam meg, és leírtam a címüket.

A második előadás a nagy adat kihívásáról szólt, és miként fogjuk (vagy inkább unokáink fogják) megoldani a felmerülő problémákat. Egy rendszer működésének megértése és a belőle nyerhető információk feldolgozása két különböző folyamat. Ha egy rendszer bonyolult, nem feltétlenül ismételhetőek meg a hozzá kapcsolódó kísérletek. Az agy például folyam-szerű elven működik. Ha ezt akarjuk utánozni, akkor a hagyományos Turing-elven működő számítógépek helyett valami mást kell létrehozni. Nagyjából ennél a pontnál vesztettem el a fonalat. Ezután a kvantum fizikáról, kozmológiáról folyt a szó, majd az önmagukat másoló makormolekulákat egyszerűen univerzális Xerox gépekké redukálta az előadó. Mikor az egyik dián egy Naprendszer méretű holografikus memória térképe jelent meg, ami már most is jelen van (és erre a "bizonyíték" az autizmus, az epigenetikus öröklődés és a deja vu), akkor adtam fel a reményt, hogy ebből bármi értelmes lesz. Az előadást tovább rontotta, hogy valami angol-orosz-francia keverék nyelven szólt. Még egy maradandó "tudományos" információ is elhangzott: A hosszú életű emberek ősszel születnek.

De szerencsére értelmes előadás is volt. A pool-seq módszerről is hallgattam egy előadást. Ennek a célja, hogy egy populáció DNS-t ekvimoláris mennyiségben összekeverik, majd megszekvenálják. A felgydúsuló SNP-k nem egyén, hanem populáció szinten lesznek jellemzőek. A módszer hátránya, hogy a strukturális variációk és mappelési hibák nagyban megnehezítik a kiértékelést. Az így keletkezett adatokat a PoPoolation nevű szoftverrel érdemes feldolgozni. Az is elhangzott, hogy az SNP analízis után nem érdemes GO vizsgálatot végezni, mert a GO analízis microarray módszerekre lett kihegyezve, nem SNP analízisre.

Izlandon sem ülnek a babérjaikon a bioinformatikusok. Készítettek egy olyan klinikai szekvencia elemző programot, ahol a megszekvenált egyénről megállapítja, hogy hány százalék esélye van a különböző karcinómákra. A rendszer alapja egy GOR (genomic ordered relations) nevű rendszer. Ez egy Java nyelven implementált program, ami Unix-szerű csővezetékeket utánoz, mindezt egy klaszteres környezetben, tehát a lekérdezés és elemzés szinte valós időben folyik. A deCODEhealth nevét még biztosan fogjuk hallani.

A Panasas cég is bemutatta párhuzamos adattároló eszközét. Előnye, hogy egy doobzban redundánsan ott egy csomó tárhely és a hozzá tartozó blade szerverek. Van egy objective RAID architektúrájuk, ami dinamikusan változtatja a RAID konfigurációt, attól függően, hogy mennyi és milyen típusú adatom van. Természetesen van benne SSD is, a kis adatoknak. Mindez egy saját fejlesztésű pNFS fájlrendszeren keresztül érhető el.

Megismertem a DARIO nevű programot is. Ez a nem kódoló RNS-ek (ncRNA) osztályozását végzi. Egy tanulóalgoritmusnak beadták a különböző RNS-ek mappalési mintázatát, majd a program megállapítja egy BAM fájlból, hogy milyen típusú RNS-eket sikerült megszekvenálni.

Egy olasz prof elmagyarázta, hogyan lehet a nagy adatmennyiséget tudássá váltani. Rögtön úgy kezdte, hogy nem is ért a biológiához, de ha a folyamatokat formális állapotváltozásokra írta át, akkor már mindjárt tud vele dolgozni. Szerinte a nagy adatmennyiséget nem a flopok számának növelésével kell megoldani, hanem új programozási modellek bevezetésével. Ez alatt nem új programnyelveket és új könyvtárakat ért, mert ezek nem programozási modellek. Ennek ellenére ő és munkatársai készítettek egy C++-os könyvtárat, ami jó az összes felvetett problémára. Lehet, hogy még ő sem kész új programozási modellek kifejlesztésére?

A Sztakiból is volt egy előadó. Ők egy olyan felhő alapú megoldást mutattak be, ami elrejti a különböző felhő alapú szolgáltatások közötti különbségeket, sőt egy újabb absztrakciós réteggel még a munkafolyam programozást is egyszerűsítették. Ők három féle felhasználót különböztettek meg. Vannak, akik a sci-bus rendszert fejlesztik. Ez a legalsó réteg, ők fejlesztik a kapcsolódást a különböző felhő-alapú rendszerekhez. Vannak a munkafolyamat fejlesztők, akiket nem érdekel a felhő, csak az, hogy működjön a programjuk, végül vannak a végfelhasználók, akik csak a programot akarják paraméterezni, de nem érdekli őket az infrastruktúra. A rendszerük CloudeBrokert használ, amivel megvalósítja a különböző felhő rendszerek közötti átjárást és LifeRay-t a folyamatok programozásának egyszerűsítésére.

A poszterek közül a GENALICE ragadta meg a figyelmemet. Ez egy új illesztőprogram, ami természetesen gyorsabb és érzékenyebb, mint bármi más a Földön.

A kiállításunkat elég sokan megtekintették a kávészünetekben. Este hétig fogadtuk az embereket. Mikor már elkezdtek fogyni az emberek, a céges projektoron, ahol eddig a marketing filmünk ment végtelenítve, véletlenül két CG demó is lefutott, csak a miheztartás végett.

Röviden prezentálom a HIV fertőzés emberekre gyakorolt hatását: Íme egy ember, aki HIV pozitív volt:

Íme egy ember, aki nem volt HIV pozitív:

Vannak, akik megfertőződnek, de nem alakul ki náluk a tünetegyüttes, és vannak olyanok, akiknél igen.

Ennyi a beszámoló. Az olvasó, biztos vagyok benne, hogy nem tudott meg többet a HIV fertőzésről, és bizonyára úgy érzi, hogy kihagyok valamit. Pedig egy ehhez hasonló bioinformatikai elemzést olvastam. A szerző összehasonlított két illesztőprogramot. Talált több, mint 11 ezer variációt, majd készített 4 képet az illesztésekről, ahol prezentálta, hogy egyik program illesztésében megtalálható egy bizonyos variáció, a másik illesztésben pedig nem.

Udvariasan arra kértem, hogy legyen szíves valami statisztikát mellékelni. Semmi bonyolultat nem akartam, csak pár százalékot, hogy egyik program mennyit talál meg, és a másik mennyit talál meg. Esetleg egy PPV-t számolhatna, hogy a megtalált variációk hány százaléka valódi, és mennyi fals pozitív.

Természetesen ilyet nem kaptam, mert a riportot készítő főnöke elmagyarázta nekem, hogy ezek a statisztikák csak arra jók, hogy elfedjék a lényeget, ezért nem szereti őket. Tehát a fenti példa "beszámolóm" teljes, mert nem fedi el a lényeget. De az olvasó mégsem tudja, hogy mennyire veszélyes ez a vírus. Tehát ez a főnök ezzel a kijelentéssel a hozzá nem értését bizonyította.

A kegyelemdöfést az adta meg, hogy a riport készítője is írt. Mint leírta, ő sem szereti a statisztikát, mert neki kell kiszámolnia. Tehát van egy dilettáns főnök és annak egy lusta beosztottja. Készítenek valamit, ami teljesen használhatatlan, és megmagyarázzák, hogy az minden igényt kielégít.

A statisztika rossz alkalmazása valóban elfedhet egyes jellemzőket. Ilyen például, mikor csak az átlagot prezentálják, a szórás nélkül. De a statisztika nem gonosz. Nem azért van, hogy megkeserítse az emberek életét, hanem azért, hogy felfedje az összefüggéseket. Egyedi esetek felsorolása nem megoldás. A másik, hogy a statisztikát nem szeretni vagy utálni kell. Szeretni lehet süteményt, filmet vagy háziállatokat. Metódusokat viszont használni kell, nem szeretni.

Második nap az előadásokra értem vissza. Főleg a játékipart megcélzó fejlesztésekről beszéltek. A People Can Fly nevű cégtől megtudhattam, mit is csinálnak egy első osztályú játékfejlesztő cégnél a programozók. Ez az a szint, amit személyesen soha nem fogok megtapasztalni. A második előadás a Havoc fizikai motorról szólt. Szárazabb volt az előzőeknél, számomra csak a fizikai modellezésnél kezdett érdekes lenni. A middleware fejlesztés létjogosultságát alátámasztó gazdasági kimutatások sajnos nem érdekeltek.

Isti, akit az Amiga Klubból ismertem, hatalmas release készítésben volt. Ez abból állt, hogy embereket keresett, akik demót írnak helyette. A plazmakockájának textúráját Charlie írta, a kocka kódját egy OpenGL példaalkalmazásból lopta. Egy kicsit segítettem neki én is, még egy hónappal a parti előtt (bár meg kell jegyeznem, sok hasznomat nem vette.) Itt Blala pakolta össze a különböző helyről származó kódokat, míg zenét Ferris adott, akit elvitt valami elektronikai boltba. Mondtam is Istinek, hogy demotoolt használ. Humán demotoolokat.

Segítséget kértem én is a profiktól. Egy ideje gondolkodom rajta, milyen design patternt érdemes használni, hogy ne kelljen foglalkozni az OpenGL kód és a shader kód közötti függőségekkel. Értem ez alatt, hogy a vertex bufferek, uniform változók nevei olyan függőségeket kényszerítenek a programozóra, ami miatt megnő a hibalehetőségek száma.

Azt a megoldást kaptam, hogy először a shadereket készítsem el egy eszköz segítségével, majd ehhez igazítsam a program kódját. Érdekes koncepció, én eddig fordítva csináltam. Volt egy stabil rendszer kód, és a shadereket heggesztettem, amíg nem lettek jó. Ez azért volt jó számomra, mert fordítás nélkül tudtam változtatni a demón.

A SidRip Alliance koncertjét a termen kívül élveztem, és nem voltam egyedül. Nem a zene mindősége üldözött ki, hanem a hangerő, amit a vén csontok fülei már nehezebben bírnak. De cserébe Ratmantól megtudtam, milyen napjai vannak manapság egy rendszergazdának. A beszélgetés megvilágította, hogy nem vagyok egyedül, amikor a hozzá nem értéssel kell harcolnom. Csak mások még rosszabb helyzetben vannak, mert őket éjszaka is zargathatják. Kedvenc történetem a következő volt:

- Este hívnak, hogy nem megy a szerver. Mikor megkérdeztem, mi a hibajelenség, a kagylót letették. Kiküldtem egy embert, nyomozza ki, mi a hiba. Egy óra múlva hívott, hogy a problémát elhárította. A nyomtató begyűrt egy papírt.

Ebből is látszik, vannak problémák.

A zenék között most nem volt olyan, ami mélyen megfogott volna. A grafikák között volt néhány igazán érdekes, de erről Grass majd részletesen ír a scene.hu-n. Amit nagyon vártam, az a wild demók, hiszen érdekeltek voltunk benne. Az első pár release a szokásos, "gyorsan dobjunk össze valamit" szellemében készült. Majd jöttek az igazi nagyágyúk. Meglepően jó releaseket láttam. Volt technikai jellegű, de igazán ötletes darabok is. Azt hiszem, a dobogóról lecsúsztunk.

A 256b intrók száma is magas volt. Itt is akadt olyan, amire érdemes emlékezni. A nagyobb méretkorlátú intrók már nem voltak annyira emlékezetesek, de a Dilemma nevű csapat rendesen kitett magáért, szerintem nyerni fognak. Platformok terén sem lehet ok panaszra. A PC-s indulók mellett volt Amiga is. A magyar Amiga scene (vagyis Charlie) ismét képviseltette magát.

Gargaj figyelmeztetett minket, hogy nagy számú demó várható. Nem is hazudott. Több, mint 10 induló volt. Egy részük lelkes scenerek örömmunkái voltak. Azonban voltak igazán figyelemre méltó alkotások is. A Brainstorm nem adta ki a demóját valami bug miatt. Tehát amit a legjobban vártam, elmaradt.

Az eredményhirdetésen kiderült, hogy 5. lett a Cubes.

Topy, a német demoscene egyik nagy egyénisége, elmondása szerint igyekszik minél több partira eljutni. Eddig ez nem okozott neki különösebb problémát, de idén egy autóbaleset következtében eltörött a lába. Talán mások az ő helyében igyekeztek volna kíméletesebb életmódot élni, és inkább a gyógyulásra koncentrálni, ő mégis úgy döntött, a demopartikat nem fogja kihagyni.

El is jutott a WeCan nevű lengyel partira, és úgy döntött, ha már itt van Kelet-Európában, a Function-t is meglátogatja. Egyetlen akadály volt csupán, megközelítőleg 10 nap a két esemény között. A szállodák nem olcsóak, még a német pénztárcákhoz képest sem, ezért Topy a scene közösség segítségét kérte.

A fórumon leírta, hogy mi a problémája, mit szeretne és várta, hogy milyen ajánlatokat kap. Az átlagos scener 30 év körüli, tehát jó eséllyel van családja. Náluk egy törött lábú ember befogadása szóba sem jöhet. Gondoltam egyet, és írtam neki. Igaz, nem élek Budapesten, ami a közlekedést megnehezíti, de nem tartottam valószínűnek, hogy leküzdhetetlen akadályokkal kellene szembenézni.

Rajtam kívü egy ember tett még felajánlást, de később ő is visszakozott. Topynak nem volt más választása rajtam kívül. Bevallom, én is meginogtam, de úgy döntöttem, ha már egyszer tettem egy ígéretet, akkor nem változtatok rajta. Így történt, hogy szeptember 19-én a repülőtéren vártam, hogy megérkezzen Topy.

A kocsi, amivel közlekedett, nagyobb volt, mint gondoltam. A buszra alig tudtunk felszállni, de szerencsére segített a sofőr. Topy elmondta, hogy már nincs akkora szüksége a kocsira, de mégis kénytelen cipelni, nem hagyhatja ott valamelyik parti helyszínén. A lépcsőkkel sok esetben akadtak problémáink. Ez az utazás ahhoz is nagy segítséget nyújtott, hogy másik szemmel lássam a közlekedést kerekes székkel.

Majdnem három órát vett igénybe az út, de végül eljutottunk a lakásomig. Beszélgetésünk során kiderült, hogy dolgozott hangmérnökként, belekóstolt a filmgyártásba, ahol a világító, villogó, de valódi funkció nélküli elektromos ketyeréket készített (tudjátok: a piros vagy a kék drótot vágjam el?) és független játékokhoz készített zenéket. Ha viszont úgy hozza a sors, pólókat árul Atari, Amiga feliratokkal.

Elmesélte, hogy üzemeltet egy repaidcafe-t Kölnben. A kezdeményezés lényege, hogy csere alapon ki-ki megjavítja a másik elromlott, ősrégi eszközeit. Ha valaki visz oda egy egyközt, legközelebb neki is meg kell javítani valamit. Ezt én is egy szimpatikus hozzáállásnak tartom. Szerintem sem kell kidobni egy eszközt és újat venni, csak azért, mert egyszerűbb.

Amíg nálunk tartózkodott, bár nem sokszor mozdult ki a lakásból, (pontosabban még a laptopját sem hagyta el), mégis élénk társasági életet élt. Virtuálisan még a barátnőjével is randizott. Mindketten letöltötték ugyan azt a filmet, majd chaten megbeszélték, mit látnak.

Topy félig ír, ezért főzött nekünk egy igazi ír különlegességet. Sajnos a nevét nem tudom. Birkahús volt megsütve hagymával, párolt zöldségekkel. Leveles tésztával letakarta és úgy is megsütötte. A hús olyan volt ízre, mint a vadas.

Topy feladata a Function idején a SceneSat élő közvetítése volt. Tehát annak, hogy a világ más tájain hallani lehetett a Functionon elhangzottakat, egy kicsit nekem is köszömhető.

Idén is eljött a Function. Pénteken Topyval elindultunk a parti helyszínére. Kerekes székkel és felszerelésekkel együtt ez egyáltalán nem egyszerű feladat. Felszállni a villamosra volt a legnehezebb feladat, mert középen ott volt az a hülye korlát. Rajtam volt a saját hátizsákom, Topy hátizsákja, jobb kezemben a ruhás táskája, a ballal pedig az összecsukott kerekes széket vittem. Ő mankóval ment.

Mikor megérkeztünk, mondtam, el sem hiszem, hogy itt vagyunk. Ő meglepetten rám nézett: Miért, nehéz volt idejönni?

Lepakoltunk, majd elkezdtünk beszélgetni az emberekkel. Mellém egy japán scener telepedett, aki rögtön ellátott Mangás nápolyival. A megnyitó nem volt túl ünnepélyes, de nem is voltunk olyan sokan, hogy fontos legyen.

Láttam Arcee játékát. Autóversenyt készített a Tricky Truck motorjával. Mu6k mtatott 5 másodpercet a készülő demójukból, ami el is vette a kedvemet attól, hogy beadjak bármit is. Ennek ellenére javítottam egy kicsit az egyik demómon. Velem szemben egy akkora laptop került, mint egy TV. A tulaj megnézte a szánalmas release csökevényemet, majd elképeve mondta, hogy ez fantasztikus, ő ilyet soha nem tudna csinálni. Akkor mire jó az a nagy laptop? A game compó elött hazamentem.

Nyers kép

Ha birtokunkban vannak a feldolgozandó képi információk, az első lépés, hogy ezt a programunk számára elérhetővé kell tenni. Három különböző módon olvashatunk be képeket:

Webkameráról a cvCaptureFromCAM, videóról a cvCaptureFromFile használható. Mindkét parancs egy CvCapture struktúrát ad vissza, ahonnan a cvQueryFrame segítségével kinyerhetjük az egyes képkockákat. Ha csak egyetlen képpel dolgozunk, akkor a cvLoadImage betölti nekünk azt.

Amennyiben egy köztes állapotot tárolására nekünk kell létrehozni egy képet, a cvCreateImage-t használhatjuk.

Bármelyik módszert is használjuk, eredményül egy IplImage-t kapunk. Ez a nyers képünk. Attól függően, hogy mi a célunk, a képet különböző előfeldolgozásnak kell alávetni. Sok parancs hatása hasonló, mintha Photoshop szűrőket használnánk, tehát gondolhatunk úgy is az OpenCV-re ezek alapján, mint egy programozható grafikus alkalmazásra.

Photoshop imitálás

Az egyik legfontosabb feladat, hogy különböző színterek között át tudjuk alakítani a kapott képet. Erre szolgál a cvCvtColor függvény. Három paramétere közül az első kettő a kép, amiről konvertálunk, a kép, amire konvertálunk. Az utolsó paraméterrel adjuk meg a konvertálás módját. A módokat konstansokkal adhatjuk meg. Ha szürkeárnyalatos képet akarunk kapni egy RGB színterű képből, a következő konstanst használhatjuk: CV_RGB2GRAY.

Szintén alapvető fontosságú feladat a képek átméretezése. A cvResize segítségével könnyedén átméretezhetjük képünket. A forrás és célképek megadása után már csak az átméretezés módját kell megadni egy konstans segítségével.

Egy másik, a grafikus programokban gyakran használt művelet az elmosás, amihez a cvSmooth használható. Megadjuk a forrást, célt, valamint az elmosás típusát (pl: CV_GAUSSIAN, CV_MEDIAN). Az utolsó négy paraméterrel szabályozhatjuk magát az algoritmust.

Az utolsó két ismertetésre kerülő függvény közös jellemzője, hogy egy úgynevezett konvolúciós kernelt használ a kép módosítására. A kernel előállítására a cvCreateStructuringElementEx-t használjuk. Ez egy egyszerűsített módszer a kernel létrehozására. Ahelyett, hogy a mátrixot elemek szerint adnánk meg (bár erre is van lehetőség), csak a méretét, alakját és a kernel horgonypontjait (anchor point) állítjuk be. Amennyiben elég profik vagyunk, az utolsó paraméterrel mi magunk is beállíthatunk egy kernelt.

Az így elkészített kernelt azután felhasználhatjuk a cvErode és a cvDilate függvényekhez. Anélkül, hogy a részletekbe merülnék, ez a két függvény egyfajta zajszűrőnek tekinthető. A cvErode segítségével a kisebb hibákat (foltokat, karcolásokat) tüntethetünk el, míg a cvDilate segítségével a struktúrális különbségek jobban kiemelhetőek.

Rajzolás

Új elemeket is felvehetünk a képünkre. A legegyszerűbb alakzat, amit elhelyezhetünk a képünkön, a vonal. A cvLine segítségével nem csak a színt, de a vonal vastagságát és stílusát is beállíthatjuk. Nagyon hasonló a négyzeteket rajzoló függvény (cvRectangle) paraméterezése is.

Bináris képek

Ebben a fejezetben a kép szegmentálásával foglalkozunk. Ezek alacsony szintű műveletek lesznek, nem próbáljuk meg felismerni a képen található elemeket, csupán színek alapján elkülönítjük az egyes területeket. A feltételeknek megfelelő régiók fehér színűek lesznek, míg amelyek nem felelnek meg, feketék. Ha színes képpel dolgozunk, akkor az cvInRangeS függvényt használhatjuk. Segítségével felállíthatunk két színkorlátot és minden, ami azon belülre esik, fehérként jelenik meg a cél képen.

Érdemes megjegyezni, hogy sokkal realisztikusabb eredményt kapunk, ha nem RGB, hanem HSV színtérbe konvertáljuk képünket. Nekem az a tapasztalatom, hogy nagyon nehéz olyan szűrőt készíteni, amelyik egy színt és a hozzá közel eső árnyalatokat is nagy pontossággal kiszűri.

Szürkeárnyalatos kép esetén a cvThreshold vagy cvAdaptiveThreshold függvények használhatók. Előbbi a pixelenként hajtja végre a műveletetet, utóbbi pixel blokkonként. Mindkét függvény elég rugalmasságot biztosít, hogy miként kívánunk szűrni. A következő példaprogram ezt szemlélteti a webkameránk képével:

#include <opencv/cv.h>
#include <opencv/highgui.h>
#include <stdio.h>

int type = CV_THRESH_BINARY;

void processImage(IplImage *raw, IplImage *gray){
  cvCvtColor(raw, gray, CV_RGB2GRAY);
  cvThreshold(gray, gray, 128, 255, type);
}

int main(){
   CvCapture *capture;
   IplImage *frame;
   IplImage *gray;
   int run = 1;

   capture = cvCaptureFromCAM(CV_CAP_ANY);
   cvNamedWindow("win", CV_WINDOW_AUTOSIZE);
   frame = cvQueryFrame(capture);
   gray = cvCreateImage(cvGetSize(frame), IPL_DEPTH_8U, 1);

   while(run){
      frame = cvQueryFrame(capture);
      processImage(frame, gray);
      cvShowImage("win", gray);

      switch(cvWaitKey(10)){
         case 97:
            type = CV_THRESH_BINARY;
            break;
         case 115:
            type = CV_THRESH_BINARY_INV;
            break;
         case 100:
            type = CV_THRESH_TRUNC;
            break;
         case 102:
            type = CV_THRESH_TOZERO;
            break;
         case 103:
            type = CV_THRESH_TOZERO_INV;
            break;
         case 27:
            run = 0;
      }
   }

   cvReleaseCapture(&capture);
   cvDestroyWindow("win");
   cvReleaseImage(&gray);

   return EXIT_SUCCESS;
}


Az a,s,d,f,g billentyűkkel változtathatjuk a cvThreshold paraméterét. ESC-re a program kilép. A következő fejezetben az előfeldolgozott képeken fogunk tovább műveleteket végrehajtani: kontúrvonalakat keresünk, időjárás bemondóvá válunk és kiváltjuk Aha-t egy programmal.

Egyik nap elkövettem azt a hibát, hogy céges emblémával ellátott pólóban mentem dolgozni. A tömegközlekedésen megkérdezte tőlem egy úr, hogy tényleg ott dolgozok-e, amiből rögtön egy bioinformatikával összefüggő beszélgetés alakult ki.

Az úr elmondta, hogy annak idején ő is biotechnológiával foglalkozott, de csak a chip technikákkal van közelebbi ismeretségben. Arra volt kíváncsi, hogy azóta milyen új trendek vannak. Meséltem neki az újgenerációs szekvenálásokról, a bioinformatikai kihívásokról, ő meg arról, hogy szeretné frissíteni tudását a biotechnológia területén.

- Járatok egy újságot is, azt olvasom, hogy szinten tartsam magam.
- Mi a címe?
- Valami Biotech. Nem ismered? - nem ismertem.

Elmesélte, hogy dolgozott rendszergazdaként, ezért ért a számítógépekhez, de szakmáját tekintve élelmiszermérnök. Jelenleg pedig biztosítási ügynök. Bár többször hangsúlyoztam, hogy én "száraz" biológiával foglalkozom, nagy élvezettel mesélte, hogy ők biztosítanak ultracentrifugákat is. Miután a biotechnológiáról áttértünk a biztosítások területére, egy nyugtalanító érzés kezdett elhatalmasodni rajtam. Mikor már az e-mail címem után érdeklődött, megemlítettem neki, hogy ha az a terve, hogy elhalmoz biztosítási ajánlatokkal, akkor felejtse el.

Azt is említette, hogy be kellett vinnie laptopját a Budapesti Műszaki Egyetemre, mert valami hekker feltörte a Linuxát. Ott viszont nem tudtak segíteni rajta. Mindent le kellett törölnie és újratelepíteni.

Kaptam egy névjegykártyát is tőle, ahol felsorolta az összes kompetenciáját: okleveles élelmiszertechnológus mérnök, számítástechnikai szakember, tanácsadó.

Miután megnyugtatott, hogy nem fog elhalmozni biztosítási ajánlatokkal, levelezni kezdtünk. A levelei aláírása további szakmákkal bővült: Élelmiszertechnológus, Sör és szeszipari mérnök, Számítástechnikai szakértő, Specialitás kereskedelem áru forgalmazás (ez nem tudom, mit jelent), Biztosítási és befektetési szakember, Specialitás informatikai beruházások megtérülése, Projekt vezetés IT terület. Azt hiszem, nem hagytam ki semmit.

A leveleit magyar nyelven írta, én mégsem értettem miről szólnak. Kedvenc levelem tőle a következő volt: "Van olyan azonosító ami fel ismeri az RNS sorozatokat. Elektronikus úton." Ez egy kérdés, azt akarta tudni, hogy a DNS chiphez hasonlóan RNS chip van-e...

Mielőtt pálcát törnénk felette, gondolkodjunk el azon, a környezetünkben hányan vannak, akik szegényes tudásukat valami módon álcázzák. Szerintem nem kell szégyellni azt, ha valamit nem tudunk. Azt kell szégyellni, ha a hiányosságunkat nem pótoljuk, esetleg arroganciával, mellébeszéléssel leplezzük.

Merjük azt mondani, hogy nem tudjuk! A nem tudás nem jelenti azt, hogy ostobák vagyunk, csupán azt, hogy nem áll rendelkezésre az információ. Ha viszont elhitetjük, hogy rendelkezünk a szükséges ismeretekkel, azzal másokat csapunk be.

Könnyű dolgom van, mert az idei Function-re egy animációt adunk be, amit többségében Grass fog elkészíteni. Jeleztem, hogy én is szeretnék valami nyúlfarknyi munkát, ezért azt a feladatot kaptam, hogy modellezzek egy boxkesztyűt és egy géppuskát.

Modellezésben nem vagyok profi, de azért össze tudok rakni ezt-azt. Ráadásul ez egy hobbi, ahol az a cél, hogy jól érezzük magunkat.

Modellezéshez 3D Studiot szoktam használni, mert ez egy olyan eszköz, amit a minimális művészi vénával rendelkezőknek találtak ki. Legalábbis nekem az az érzésem. Az én kedvenc modellezési módszerem, hogy választok egy egyszerű alakzatot, majd addig nyújtom, csavarom, amíg olyan nem lesz, amilyet szeretnék. Közben gyakran élek azzal a lehetőséggel, hogy több alakzatot boolean módosítókkal összerakok.

A boxkesztyűnél ezt is csináltam. Vettem egy gömböt, átalakítottam a "Convert to editable Mesh" menüponttal, majd kijelöltem a vertexeket és elnyújtottam a gömböt. A hüvelykujjnak megfelelő részt az Extrude segítségével kiemeltem, majd elforgattam. Végül a vertexek mozgatásával a kívánt formára hoztam a testet.

A gépfegyvert már egy teljesen más megközelítéssel készült. Először is választani kellett egy kellően ikonikus fegyvert. Ez az M60-as lett, mert Rambo nem indul csatába egy ilyen nélkül. Szereztem róla egy referencia fotót és betöltöttem háttérnek és elkezdtem közönséges vonalakkal körberajzolni. A körvonalat azután kiemeltem térbe, amitől olyan lett, mintha egy deszkából vágtam volna ki a körvonalat. Ezután átalakítottam mesh-é a boxkesztyűhöz hasonlóan és egyes elemeket (pl. a gépfegyver csövét) lecseréltem olyan testekre, amelyek jobban illettek a végleges formához. Többnyire az új test és a referencia körvonal unióját használtam.

Nemrég viszont Grass belefutott egy olyan helyzetbe, amit nem tudott egyszerűen megoldani. Nevezetesen egy kockához hasonló formát kellett Menger-szivacs jellegű formává alakítani. Tudom, ez nem egy tiszta leírás, de igyekszem a történet csattanójának lelövését elkerülni. Napokat kísérleteztem a művelettel. A bonyolultságát ugyanis az adta, hogy egy erősen fraktál jellegű test létrehozása sok memóriát igényelt, miközben az eredeti forma is magas poligonszámú volt. Végül azt csináltam, hogy létrehoztam egy Menger szivacs inverzét, vagyis olyan téglatesteket, amelyek szemből a Menger-szivacsba helyezve kitöltik annak lyukait. Ráhúztam az eredeti testre és Boolean módosítóval kivontam a kettőt. Az eredmény nagyon látványos lett. Function-ön mindenki megnézheti.

Otthon az internetet Y szolgáltató biztosította hosszú ideje. Egyik nap jött egy értesítés, hogy X szolgáltató felvásárolja Y-t, de ez engem, egyszerű fogyasztót (vagy politikailag korrekt módon megfogalmazva felhasználót) nem érint. Csupán abból fogom észrevenni, hogy Y-t X váltotta fel, hogy a havi elszámolás más színű borítékban fog érkezni, és néhány TV csatorna megváltozik.

Személy szerint elégedett voltam az internetemmel. Egy 80/25-ös sávszélesség, LAN-os kapcsolat elég volt mindenre. Még arra is futotta belőle, hogy VNC-n keresztül demót sugározzak Grassnak. Négy gép is osztozott ezen, mégsem volt soha semmi probléma.

Természetesen a szolgáltatóváltással mindez veszélybe került. Eltelt néhány hónap, majd hirtelen megjelent két szerelő, hogy Ők X-től jöttek, és átszereli a netet. Először csalásra gyanakodtam, nem is akartam beengedni a lakásba, de bizonyítani tudták, hogy nem kábeltolvajok. A szolgáltató ugyanis úgy döntött, hogy a LAN-os internetet megszünteti és kapok helyette jó kis koaxon keresztül működő szupergyors internetet. Csakhogy a szupergyors internet letöltésben tényleg szuper, de a feltöltés kevésbé az. Névlegesen 120/10. El is magyaráztam neki, hogy ez számomra nem tűnik fejlesztésnek. A szerelők, kezdték elveszíteni a türelmüket. Gondolom szerettek volna gyorsan végezni, de én még a lakásba sem engedtem be őket. Miután láttam, hogy ebből csak vesztesen jöhetek ki, hagytam, hogy dolgozzanak.

Hoztak új routert is, mert ugye koaxon jön az áldás. Lefitymálva megjegyezték, hogy az új sokkal gyorsabb lesz, mert, ami nekem van, csak 54Mbit/sec-t bír csak, míg az új 180Mbit/sec-el hasít. Nem mintha ez számítana, mert elég régi gépeim vannak, egyikben sincs gigabites ethernet. Bekapcsolták a szerkezetet, ami alapból DHCP-n ment és a wi-fi is be volt kapcsolva. Beszereltek mindent, majd az aktiválás előtt az egyik szerelő felhívta az irodát és átadta nekem a telefont. A kisasszony a vonal másik végén megkérdezte, mi a bajom a szolgáltatással. Neki is elmagyaráztam, hogy a régi hálózaton a feltöltési sebesség jobb volt.

- Ezt méréssel állapította meg?

- Nem, hanem a specifikációból. A régi 25Mbit/sec-el töltött fel, ez a mostani pedig 10-el.

- Ez a garantált feltöltési sebesség?

- Nem, a maximális.

Ezután számadatokat kezdett el darálni a telefonba, amiket nem tudtam megjegyezni, majd így fejezte be: Tehát az Őn nete gyorsabb lesz.

- Ha Ön mondja, akkor elhiszem.

Ha objektíven nézzük, akkor tényleg nem volt összehasonlítási alapom. Miután mindenbe beleegyeztem, aktiválták a netet.

- Mit mondtak? - kérdezte az idősebb szerelő.

- Azt, hogy ez a net gyorsabb lesz, mint a régi.

- Nevetséges. A LAN-os az egyik legjobb, de nekünk le kell építeni az egészet. De nem is ez a leggusztustalanabb, hanem az, hogy kész tények elé állítják az embereket - mondta. Elgondolkodtam, hogy megemlítsem-e, hogy ennek ő is ugyan úgy részese, elvégre Ő hívta fel a szolgáltatót, miután beszerelt mindent.

De az internet csak nem akart megjelenni semmi. Törték a fejüket nagyon, hogy most mi a hiba, de ötletük sem volt.

- A gépnek statikus az ip címe.

A homlokuk azonnal kisimult. Megpróbálták átállítani DHCP-re, de nem ment, ezért felajánlottam, hogy megcsinálom. Mikor megjelent a scene.hu, akkor mindenki megnyugodott. Megpróbáltam belépni a router adminisztrációs felületére, de nem sikerült. Ekkor a fiatalabb szerelő azt mondta, hogy a wifi SSID-je a jelszó. Megpróbáltam azt is, de nem jártam sikerrel. Még két-három próbálkoztam, majd megkérdeztem a másik szerelőt, hogy miként tudok belépni a routerbe.

- Azt nem lehet.

- Majd, ha elmentek, megnézzük mennyire nem lehet - gondoltam.

A neten keresni kezdtem a router biztonsági jelszava után, de azok egyike sem működött. Resetelni még nem akartam, mert hátha van valami olyan beállítás, amit nem ismerek, és utána nem lesz net. De X honlapján végül megtaláltam a megoldást. Alapból nincs se felhasználói név, se jelszó, csak klikkelni kell a loginre és már bent is vagyunk. Ugyanis van egy szereld magad opció is a cég repertoárjában, ahol megkapod az eszközöket és szenvedj velük, ha neked ez kell. Ez szimpatikus. Szépen be is állítottam mindent, ami nekem kell. Végül is a sebességen nem érzek semmilyen változást.

A Bioconductor egy olyan R csomag gyűjtemény, ami statisztikai oldalról támogatja a bioinformatikai munkát. Validálásnál, az eredmények kiértékelésénél rengeteg olyan eszközt ad a kutatók kezébe, amely nélkül a munkájuk minősége nehezebben állapítható meg.

Amikor erőforrás igényes munkáról van szó, és egy távoli gépen akarjuk kihasználni ezt a hihetetlen potenciált, akkor meg kell bírkózni a feladattal és egy olyan gépre is telepíteni kell a rendszert, amely - mint látni fogjuk - rendszergazdai szempontból több kihívás elé állít, mint egy helyi gép.

Első lépésben le kell tölteni magát az R csomagot. Választhatunk kész, bináris formát, de ezeket úgy fordították, hogy eleve feltételezték, hogy a rendszerünk tartalmaz X-t, Tcl interpretert és még ki tudja mennyi mindent. Ha ezek adva vannak, akkor nincs semmi gond, de ezek az én Amazonos gépemen nincsenek, és szükség sincs rájuk a munkámhoz. Tehát egyetlen lehetőség, a forráskód letöltése és fordítása.

>wget http://cran.cnr.berkeley.edu/src/base/R-2/R-2.15.1.tar.gz

Alapból az Amazonos gépek nem tartalmaznak fordítót, és egyes Linuxos instance-k saját csomagkezelő repositoryval vannak ellátva, de ezek megtalálhatóak a csomagok között. (Szemben az R-el, ami viszont nem) Az R csomagnak kell Fortran fordító is a C/C++ mellett:

>sudo yum install gcc44-gfortran.x86_64

A fortran fordító gfortran44 néven szerepel, ezért - miután kicsomagoltuk az R forráskódját - létre kell hozni egy környezeti változó, hogy a scriptek megtalálják.

>export F77=gfortran44

Ezután már konfigurálhatjuk a fordítást.

>./configure --with-readline=no --with-x=no

Nincs szükségem X-re, ezért kikapcsoltam. A másik opció további forráskódok telepítésétől ment meg.

A libxml2-dev és a libcurl4-openssl-dev csomagok viszont megtalálhatóak az Amazonos gép csomagjai között, ezért telepítsük ezeket is. Az R futtatásához nem szükségesek, de a Bioconductor használatához igen.

Ha a fordítás és a csomagok telepítése sikeres volt, akkor a további csomagokat már az R parancsértelmezőjéből futtathatjuk. Indítsuk el az R-t. Mivel a telepítőnek hozzá kell férnie néhány rendszer-könyvtárhoz, ezért mindezt root jogokkal tesszük.

>sudo R

>>source("http://bioconductor.org/biocLite.R")
>>biocLite("ShortRead")
>>biocLite("edgeR")
>>library("BiocInstaller")
>>biocLite("VariantAnnotation")
>>q()

Telepítés során előfordulhatnak problémák. A leggyakoribb ok, hogy valamilyen csomag hiányzik. Sajnos erről nem kapunk egyértelmű hibaüzenetet, csak annyit, hogy pl: xml-config not found. Ez annyit jelent, hogy nincs telepítve a libxml2-dev. Elképzelhető, hogy további csomagok is kellenek, de én a saját gépemre már annyi fejlesztői könyvtárat felpakoltam (samtools, bwa, stb telepítéséhez), hogy elképzelhető, valamit kifelejtettem.