Az élet kódjai

Az előző részben létrehozott alkotás két okból sem számít demónak. Először is, nincs benne animáció, másrészt Esc gombra nem lép ki. Ezért ebben a részben kódolni fogunk és animálni.

Hozzunk létre egy új projektet. Nem kell semmilyen csomagot hozzáadnunk. Egy kameránk lesz mindössze. Adjunk hozzá a jelenethez egy csomó kockát. GameObject -> Create Other -> Cube. Ha már három kocka kész, jelöljük ki mindegyiket, majd az Edit -> Duplicate segítségével duplázzuk meg a számukat. Az új kockák a régiekkel megegyező pozícióban lesznek, ezért forgassuk/mozgassuk őket tetszőleges helyre. Rövid idő alatt nagy mennyiségű kockánk lesz, ha ezt a pár lépés ismételgetjük. A kockák mindhárom koordinátája legyen a -2, +2 tartományban.

Adjunk hozzá három fényforrást. GameObject -> Create Other -> Point Light. Nevezzük el őket Red, Green, Blue-nak. Mivel ebben a fejezetben kódolni fogunk, coder color sémát használunk :-) Állítsuk be mindhárom fényforrás pozícióját: Red: X=0, Y=0, Z=3. Green: X=3, Y=0, Z=0. Blue: X=0, Y=3, Z=0.

A kamerának a korábban megismert módon adjunk egy Audio Source komponenst, és adjunk hozzá zenét.

Adjunk egy másik komponenst is a kamerához: Add Component -> New Script. A név legyen Esc, a nyelv CSharp. Ebben a tutorialban C# szkriptek lesznek, de emellett JavaScript és Boo nyelven is kódolhatunk. Aki jártas a JavaScriptben, annak nem lesz nehéz az itt látottakat átírnia.

Az Assets ablakban megjelent egy Esc nevű elem, klikkeljünk rá kettőt. Elindul a MonoDevelop nevű ingyenes eszköz (amennyiben telepítettük). Az én gépemen nem volt túl stabil, ezért a sűrű mentés javasolt. Profibbak beállíthatják a Visual Studiot is: Edit -> Preferences -> External Tools -> External Script Editor. Professional verzió esetén nincs sok gond, de Express esetén a kódkiegészítés, objektum hierarchia és egyéb fejlesztést könnyítő megoldások már sokkal több munkát igényelnek, ezért ez a leírás a MonoDevelopot tartalmazza.

Minden egyes szkript egy GameObject-hez tartozik és annak viselkedését szabályozza, illetve az objektum bizonyos eseményeinél fut le. Az egyik ilyen esemény az inicializálás, ami egy Start metódusban ölt testet. A másik pedig az objektum periodikus frissítése (Update). Ezt a vázat a MonoDevelop létre is hozza.

Módosítsuk az Update metódust a kövezkezők szerint:

void Update(){
  if(Input.GetKeyDown(KeyCode.Escape)){
    Application.Quit();
    Debug.Log("Pressed");
   }
}

A kód hatására, ha lenyomjuk az Esc gombot, a program kilép! Valamint kiírunk egy hibakeresési üzenetet. Amint elmentjük a szöveget, azonnal frissül Unityben is. Az üzenetet a Unity konzolján találjuk. A Window -> Console menüponttal válthatunk rá át (4. ábra 3-al jelölt rész).

Adjunk animációt a fényforrásokhoz. Válasszuk ki az egyik fényforrást, majd klikkeljünk a Window -> Animation menüpontra. Megjelenik az animáció szerkesztő. Az Add Curve gomb hatására először meg kell adni az animáció nevét, majd kiválaszthatjuk, melyik tulajdonságot szeretnénk animálni. Jelen esetben a Transform -> Positiont válasszuk ki. A más programokból jól ismert kulcs alapú animációval dolgozhatunk.

A vörös fényforrás esetén állítsuk be az időt 1 másodpercre, majd adjuk meg a következő pozíciót: X = 3, Y = 0, Z = 0. A második másodpercnél már kulcsot is hozzá kell adnunk. (Add keyframe, a képen az 1-el jelölt ikon.) A pozíció legyen 0, 0, 3. A harmadik másodpercnél pedig: -3, 0, 0. Végül a negyedik másodpercben a fény helyzete egyezzen meg a kiindulási állapottal.

A zöld fényforrást kiválasztva, ugyan ezekkel az időpontokkal dolgozva a következő pozíciókat adjuk meg: 1: 0, 3, 0. 2: -3, 0, 0. 3: 0, -3, 0. 4: 3, 0, 0. A kék fény: 1: 0, 0, -3. 2: 0, -3, 0. 3: 0, 0, 3. 4: 0, 3, 0.

A fényforrásaink helyét kis villanykörte piktogramok jelölik. A lejátszás gomb segítségével megnézhetjük, hogyan mozognak az egyes objektumok. A mozgás elég szögletes, aki érez magában elég kitartást, további kulcsok beállításával tovább finomíthatja a pályaíveket, illetve egyéb tulajdonságokat is animálhat.

Adjunk egy újabb szkriptet a kamerához. A neve legyen MainController.

using UnityEngine;
using System.Collections;
public class MainController : MonoBehaviour {
   public GameObject redanim;
   public GameObject blueanim;
   public GameObject greenanim; // Use this for initialization
   void Start () { } // Update is called once per frame
   void Update () {
      if (camera.audio.time > 8 && !redanim.animation.isPlaying) {
         redanim.animation.Play ();
      } else if (camera.audio.time > 16 && !greenanim.animation.isPlaying) {
         greenanim.animation.Play ();
      } else if (camera.audio.time > 24 && !blueanim.animation.isPlaying) {
         blueanim.animation.Play();
      }
   }
} 

A kód még nem teljes, az egyes GameObjecteknek meg kell feleltetni a projektben található objektumokat. Ha visszamegyünk a Unitybe, a MainController szkript mezőjében megtaláljuk a változóinkat. Most még valamennyi mellett None szerepel. Ha a kis körökre klikkelünk a beviteli mező mellett, akkor egy listából választhatjuk ki az objektumot, amit hozzá szeretnénk rendelni a változónkhoz. A kód hatására az animációk megadott időben fognak elindulni.

Egy másik animációs lehetőség, ha kódból változtatjuk meg az objektumok tulajdonságait. Lássunk erre is egy példát. Az Update() metódushoz adjuk hozzá a következő kódot:

camera.transform.position = new Vector3 (Mathf.Cos (camera.audio.time / 10.0f) * 4.0f, 0.0f, Mathf.Sin (camera.audio.time / 10.0f) * 4.0f);
camera.transform.LookAt(Vector3.zero);

A kód hatására a kamera forogni fog a kockák körül. A végleges kód valahogy így fest:

A harmadik lehetőség, ha az animációba egy pozícióra kulcs helyett eseményt szúrunk be (Add Event, 2. ábra 2-vel jelölt ikon). Ekkor tetszőleges kódot futtathatunk az animáció adott pillanatában. Ehhez nem kell mást tennünk, mint egy függvényt létrehozni az objektumhoz rendelt kódban. A mi esetünkben a kamera Esc nevű szkriptjében hozzunk létre egy Beat() függvényt:

void Beat(){
   camera.backgroundColor = Color.white;
   Debug.Log("Event activated");
}

Ezután válasszuk ki a Window -> Animation menüpontot. Jelöljük ki a kameránkat a Hierarchy ablakban. Add curve gombbal adjunk hozzá egy sávot. Teljesen mindegy, melyik tulajdonságot válasszuk, mert nem fogunk kulcsokat elhelyezni. Az idővonalat állítsuk a 30. másodpercre, de az Add Keyframe helyett az Add Event gombra kattintsunk. Megjelenik egy ablak, ahol beállíthatjuk, melyik függvény fusson le abban az időpillanatban. Válasszuk ki a Beat-et. A végleges eredmény akár így is kinézhet:

Röviden áttekintettük az animációs eszközöket. A következő részben a shadereket tekintjük át.

Az előző rész tartalmából: Megláttam, hogy van remote entry, csináljunk demót! Összehalásztunk egy csomó modellt, Grass ló halálában textúrákat gyárt. Kinecttel a motion capture befuccsol. Fogy az idő.

Mint azt néhányan már bizonyára észrevették, nem készültünk el időre, nem küldtünk be semmit. Szerencsére mások viszont igen. Nézzük meg, milyen alkotások születtek:

Procedurális 4k

Archee újabb fejlesztést hajtott végre ray tracer algoritmusán. A Lego kockák teljesen műanyag hatásúak, a fény törik, ahogy kell. Második lett, innen is gratulálunk neki.

Az első helyezett viszont a technikai bravúr mellett nagyon hangulatos is. Arachnofóbiásoknak nem ajánlott.

Android demo

Mindössze két induló volt. A Fairlight folyadék szimulációval kápráztat el bennünket, amit mindenképp impozáns egy kézi kütyün látni, de összességében a dobozokon átmászó fényforrások és golyók kicsit furcsa hatást keltenek. A macskás demó fonalát nem sikerült felvennem. A koncepció érdekes. Látszik, hogy valami újjal próbálkoznak, de a mozgás érzékeltetése olyan, mint amikor egy lassú gépen képrészletet mozgatok.

Demo

Az a helyzet, hogy a legtöbb demót nem értettem. Egyszerűen nem tudtam értelmezni a látottakat, ezért kezdjük azzal, amit fel tudtam fogni. A Conspiracy Supermode egy jelzés értékű alkotás. Kicsit visszafogottan ugyan, de megmutatták, hogy léteznek, van új demó készítő eszközük, és nem félnek használni. Valószínűnek tartom, hogy az évben még kijönnek valami ütős alkotással, ez csak a bemelegítés volt. Nekik is gratulálunk!

A másik magyar induló ebben a kategóriában a Rebels volt. Részecske rendszerüket tovább csiszolták és az elnevezés is illeszkedik abba a körbe, ahol az alkotások neve a részecske fizikából vett fogalmakat takar. (Lásd: Bozon, Fermion)

A Min egy klasszikus elemekkel építkező alkotás. Szép, látványos. Ha a sok avangard alkotás mellett vágynánk valami régi jó dologra, a Min jusson eszünkbe.

A Still nagyon meglepett. Eddig sötét tónusú és hangulatú alkotásaik voltak. Nem ritkán minimalista eszközökkel operáltak. Most viszont egy színes kavalkádot kapunk és mintha az ingyen letölthető modellek teljes választékát beépítették volna demójukba. Nem riadtak meg a helyenként elnagyolt poligonoktól, az ész nélkül repkedő modellektől. Úgy tűnt, mindegy mit mutatnak, csak sok legyen és színes. Helyenként metafizikus látványvilágot idéz.

Míg az Eternal dream of beauty csak egy kicsit volt érthetetlen számomra, addig a Secret Rooms maga a talány. Komolyan nem tudom, mit is láttam. Bizonyára Dänikent telenyomták nyugtatóval és megkérték, mesélje el, mit lát. A nézők valamit biztosan láttak ebben, ami miatt megszavazták nyertesnek, de én csak az őskáoszt érzem. Technikailag nincs semmi kifogásolható, de biztos, hogy valami történést is vittek bele, amit nem értek.

Talán nincs még egy ilyen parti, ami annyira megosztaná a scenereket, mint az NVision. Röviden arról van szó, hogy az NVidia tart egy mi-vagyunk-a-csúcs konferenciát, aminek keretében rendeznek egy demopartit is. Természetesen valamilyen NVidiás platformon kell futniuk a releaseknek.

Mivel Amerikában tartják, esélyem sincs, hogy eljussak, de feliratkoztam a hírlevelükre, kitöltöttem a kérdőíveket, ahol jeleztem is, hogy bizony, én csak lélekben leszek ott, de szívesen készítek valamit. Bizonyára többen lehettünk így, mert kaptam egy automatikusan generált levelet, hogy hogyan haladok a produkcióval? Természetesen neki sem álltam, mert feltételeztem, hogy nem lesz remote entry.

Tévedtem. Ezen felbuzdulva el is kezdtem gondolkodni, hogy mit is lehetne csinálni. Először is, csak már kész tartalommal dolgozhatunk, mert Grass is elég elfoglalt, nem biztos, hogy lesz kedve modelleket készíteni. Van egy release, amit életünk fő művének tekintünk és ehhez készítettünk pár modellt, amit végül félretettünk, mert vagy nem illik a koncepcióba, vagy minőségileg kifogásoltunk. Ezek közül az egyik egy falu, amit én csak Aprajafalvának neveztem el, mert olyan, mintha gomba házakból állna. (Ezen Grass meg is sértődött)

Kellene valami meseszerű történet...Azután eszembe jutott, hogy Grass, mikor tanulta a ZBrush-t, készített egy kis gnómot. Eredetileg persze az sem gnómnak készült, de így sikerült. Mivel találkozhat egy gnóm? Természetesen egy sárkánnyal. Az Aeronautism című alkotásunkban is szerepel egy sárkány, felhasználjuk újra.

Az első probléma, hogy Grass teljesen elfelejtette, hogy ő valaha is készített ilyen modellt. Átnéztük a levelezésünket, de nem találtuk még említés szintjén sem. Emlékeztem, hogy valamikor 2010 tájékán került szóba egy SceneCon alkalmával, de ez sem vitt közelebb a megoldáshoz. Végül Grass talált egy általa feltöltött videót, amiben pont ez a modell szerepel. Mint kiderült, rosszul emlékeztem, mert 2009-ben készítette. Utólag kiderült, 2010-ben nem is volt SceneCon.

Textúra a falut leszámítva egyikhez sem volt, de Grass tényleg rekord idő alatt legyártotta őket. Én megcsináltam a csontozást és bőrözést, hogy a modelleket mozgatni tudjuk. (Ezt a tutorialt felhasználva.) A mozgást pedig Kinecttel terveztem megoldani, a NI-Mate plugin felhasználásával.

Egy hétvégébe került, hogy a házi motion capture rendszert beüzemeljem. A dokumentáció szerint le kellett volna törölni a Microsoft-féle SDK-t, telepiteni az OpenNI meghajtóprogramokat és más egyéb fekete mágiát végrehajtani, de én erre nem voltam hajlandó. Az SDK nekem kell, ha nem megy a NI-Mate, majd keresek másik megoldást. Nos, a letöltött rendszer gond nélkül megy. Szerintem csak elfelejtették aktualizálni a doksit.

A Cinema4D pluginjük létrehoz egy null objektumot és az alá beilleszti a Kinect által felismert ízületeket, majd ezeket a térben mozgatja. Az nem működik, hogy ezekhez az ízületekhez Cinema4D-ben létrehozott objektumot rendeljünk (teszem azt, egy kockát), de ha kitörlöm a plugin által létrehozott ízületet és a helyébe ugyan olyan névvel egy kockát rakok, akkor a kocka úgy fog mozogni, ahogy én a Kinect előtt.

Ezen felbuzdulva nekiláttam, hogy a gnómot mozgással keltsem életre. Ekkor jött a fekete leves. Mikor becsontozunk egy karaktert, akkor a csontok, akár csak a való életben, kapcsolódnak egymáshoz. A váll a felkarhoz, a felkar az alkarhoz. Nos, a NI-Mate ezzel nem tud mit kezdeni. Szét kell szedni a csontokat, hogy mozgatni tudjam őket. Ha viszont szétszedem, akkor az ízületek távolsága felveszi az én ízületeim távolságát és a modell olyan testarányokkal fog rendelkezni, mint én. Magyarán a tömzsi gnóm hirtelen egy nyurga lett.

Most hogy fogom ezt megoldani? A kézi animálás sok idő. Vajon be tudom fejezni? Lesz release NVisionre, vagy nem?

Rájöttem, hogy rasszista vagyok. Előítélettel viseltetek a marketingesekkel (és salesesekkel) szemben. Kaptam ugyanis egy felkérést, hogy készítsek weboldalt egy cégnek. Meg akarták mutatni, hogy mennyire értik a fejlesztés csinját-binját, ezért még specifikációt is mellékeltek, amivel ki is vívtak egy meglepett hümmögést.

Először is híreket akartak megjeleníteni, mindegyiket kommentelhető formában. Ez rendben is van. Videókat akartak beágyazni. Ez is teljesen értelmes kérés. Azt is szerették volna, hogy Facebook kommentek jelenjenek meg a cikkek alatt. Mondhatnánk, hogy mindennapos igény. Kezdett is körvonalazódni bennem, hogy valami PHP-s keretrendszert kapnak, amelyhez a fenti igényeknek megfelelő bővítmények léteznek. A problémák ez után kezdődtek.

A weboldal kinézetét a következő mondat definiálta: "Látványos, de minimalista design." Egy pillanat, nem tudják, hogy nézzen ki az oldaluk? Ezt a részét nem szoktam szeretni. Először csak azt mondják, hogy mindegy, hogyan néz ki. Megtekintenek egy-két tervet, kiválasztják, amelyik tetszik és utána hetekig megy a "nem lehetne mégis X elem másmilyen?" De ezen nem lehet változtatni. Azon lepődnék meg, ha egy megrendelő nem ilyen lenne. Grass már máskor is segített webdesignban, majd most is megoldjuk valahogy.

A következő mondatot kétszer is el kellett olvasnom, hogy biztos legyek benne, jól értem-e: "Legyen elég tárhely a videóknak." Mi? Üzemeltessem a szervert is? Kapjam a telefonokat este, hogy nem megy a szerver, csináljam meg, de lehetőleg azonnal? Ekkor kezdtem gyanítani, hogy a specifikáció írójának fogalma sincs, hogyan is működik a web. Arról nem is beszélve, hogy a YouTube-on van elég hely a videóknak, minek azokat a webszerveren tárolni?

A specifikáció további részei már a homály zónába vezettek. Feltétel volt, hogy olyan programozási nyelvben készüljön, amit egy laikus is bővíteni, módosítani tud. Miben írjam, Logo-ban? Arról nem is beszélve, hogy egy többszintű jogosultság rendszerrel ellátott site-ot (ez is követelmény) semmilyen laikus nem fog módosítani kód szinten (vagy ha igen, akkor csak akkor hívjanak, ha röhögni kell). Valószínűleg itt arra gondoltak inkább, hogy legyen egy admin felület, ahol összeklikkelhetik a híreket, de annak semmi köze a programozási nyelvhez.

Még nem értem a végére, de az jutott az eszembe, hogy ezt egy marketinges írta. Szavak voltak összehányva, amit egy felületes szemlélő még szakszövegnek is hihet. Logikátlan elvárások, a hiányos ismeret elfedése szakzsargonnal, amit természetesen rossz szövegkörnyezetben használtak. A végére lapoztam, ahol a sejtésem beigazolódott.

Kellene valami ellenpéldát látnom, hogy meggyőzhessem magam, ez csak egy egyedi eset. Akár csak a korábbi munkahelyeimen tapasztaltak. Meg az összes ismerősöm munkahelyén tapasztaltak. Meg az ő ismerőseiknek a munkahelyén tapasztaltak.

Az SNP-k és kis indelek megtalálása újgenerációs szekvenálásokban nem egy egyszerű feladat, de számtalan megoldás létezik rá. Van viszont egy olyan rendszer, ahol a hagymányos variació detektaló algoritmusok csődöt mondanak, nevezetesen poolozott minták esetén.

De miért is jut eszébe valakinek ekvimolárisan összeönteni több DNS mintát, hogy azt szekvenálja meg? A válasz egyszerű: nem kívancsi az egyes mintákban található variációkra, hanem populáció szintű változásokra kíváncsi. Mondhatnánk, hogy már van bárkódolás, ahol az összeöntött minták eredete is azonositható a szekvenálás után, de ennek van egy viszonylag komoly limitációja: maximum 96 mintát lehet bárkódolni.

Poolozott minták kiértékelésére több program is létezik. A teljesség igénye nélkül most három kerül bemutatásra: Crisp, vipR, SNVer.

Crisp

Ez a program viszonylag régi motoros, de egyes cikkek szerint ez a csúcs. Folyamatosan fejlesztik. A legfrissebb verzió már C-ben készült és a forráskódja nem elérhető. Az illesztett BAM fájlokat olvassa elképesztő sebességgel. Az SNP-k mellett megtalálja az indeleket is.

vipR

Annak ellenére, hogy ez a program újabb, mint a Crisp, már hekkelés nélkül nem használható. Először is a program alapját képező skellam R modul nem érhető el a 3-as verziószám felett. Ha használni akarjuk, tegyük a következőt: Töltsük le a skellam csomagot, majd módosítsuk a vipR.R szkriptet:

#require(skellam)
source("pskellam.r")
source("pskellam.sp.r")

Természetesen legyenek egy könyvtárban az R programok. Így már használhatjuk...Illetve mégsem. Sajnos a saját káromon kellett megtanulnom, hogy ez a szkript nem szereti, ha _ karakter van a referencia szekvencia azonosítójában. A BAM fájlokat először mpileup formátumra hozzuk a samtools-al, majd egy másik programmal egyszerűsített mpileup formátumra konvertáljuk, és csak ez után etetjük meg az R szkripttel. Habár a leírás szerint képes indeleket azonosítani, az én mintámon nem találta egyet sem. A sebességével nem volt különösebb problémám.

SNVer

Ez a program Java-van készült. Folyamatosan fejlesztik. A működése viszonylag egyszerű, viszont annyira lassú, hogy a poszt írásának idején még nem futott le. Most már nagyon kíváncsi vagyok, mire is képes ez az algoritmus.

Összegzés

Annak ellenére, hogy még nem láttam az SNVer eredményeit, a CRISP-et tekintem a leghasználhatóbban, még akkor is, ha nem talál meg minden SNP-t. A vipR elavult csomagjaival és az SNVer lassúságával nem nyerte el a tetszésemet.

További olvasnivalók

http://www.ncbi.nlm.nih.gov/pubmed/20529923

http://www.ncbi.nlm.nih.gov/pubmed/21685105

http://www.ncbi.nlm.nih.gov/pubmed/21813454

A korábbi erőnléti felmérés sikerén felbuzdulva elhatároztam, hogy kipróbálom, képes vagyok-e egy TEK erőnléti felmérés minimum szintjét megütni. A követelmények átböngészése után láttam, hogy minden pontot nem tudok kipróbálni, mert nincs medence a közelemben, sem pedig kötél, amire mászhatok. A másik egyszerűsítés, amit bevezettem, hogy nem egyetlen napon csinálom az összes gyakorlatot.

Megbuktam. Azt már korábban is észrevettem, hogy az állóképességem már nem a régi. Új edzéstervet kell készítenem, amiben nagyobb hangsúlyt fektetek a kitartás fejlesztésére.

Nagyon leegyszerűsítve a jelenlegi kisRNS azonosító módszerek első lépése, hogy a szekvenciákat egy referencia genomhoz illesztik és a szekvenciák lefedettségéből következtetnek az expresszióra. A módszer remekül működik, van rá kipróbált program.

De mi van akkor, ha nem modell organizmussal dolgozunk? A referencia genomok minősége változó, nem ritka, hogy csak a kontigok vannak meg, azok is ismeretlen szakaszokkal tarkítva. Arra gondoltam, ki kellene dolgozni egy módszert, hogy a referencia genomot mellőzni lehessen.

Az irodalom áttekintése után úgy láttam, hogy nincs még kész megoldás, bár egyes publikációk tesznek említést a dologról. Ha viszont átnézzük a hivatkozásokat, arra jutunk, hogy ott is referencia genomra illesztenek.

Az első lépés, hogy el tudjuk különíteni a jelet a zajtól. A kisRNS szekvenálás sok esetben totál RNS kivonással kezdődik, majd méret alapján választják ki a szekvenálandó tartományt. Ennek az a következménye, hogy a szekvenálás eredményeként kaphatunk heterokromatikus RNS-eket, riboszómális RNS-eket, tRNS-eket. Ezeket egy mohó összeszereléssel akartam megtalálni és kiszűrni. Ha egy szekvencia átlépi a bűvös 23 nukleotid hosszúságot, akkor eltávolítom. Ha pedig egy szekvencia sokszor előfordul, akkor az potenciális kisRNS.

A második lépés, hogy olyan paramétereket találjunk, ami segíthet a további elkülönítésben. Mivel alapvetően csak a szekvenciát ismerjük, ezért a szekvencia tulajdonságaira támaszkodhatunk egyedül. Ez pedig a méret és a GC tartalom. Ezen két tulajdonság segítségével viszont nem lehet elkülöníteni a kisRNS-eket a szeméttől.

Több módszert is kipróbáltam, de a lényeghez nem jutottam közelebb. Végül segítséget kértem az egyik szaktekintélytől, aki átadott egy frissebb cikket, ahol support vector machine segítségével megoldották ezt a feladatot. Nekik is hasonló ötletük volt, de az elkülönítésnél nem foglalkoztak a GC tartalommal, hanem a minimális szabad energiát és duplex képződést vették alapul.

Igaz, a módszerük csak annyira jó, amennyire a mirBase, ahonnan a tréning adatszettet származtatják és még a cikk szövegéből is az jön le, hogy rettenetes mennyiségű fals pozitív találat van. Ennek ellenére a módszer már most jobbnak tűnik, mint amit én csináltam, ezért a további munkát felfüggesztettem a témában.

A kutatók sorban bevonultak a konferencia terembe, hogy meghallgassák az év első lelkesítő beszédét és megtudják, hogy idén miből lesz az impakt faktor. Az emelvényen már készen állt a rózsaszín inget viselő miniszteriumi ember, aki az alkalomhoz illő piros krumpliorrt és göndör parókát viselt. Mikor elcsendesedett a hallgatóság, hozzá is látott beszédéhez.

- Jajj, de jó látni a sok cuki tudóst! Ezért is vontuk össze valamennyi kutatóintézetet, hogy csináljunk nektek egy nagy játszóteret, hogy az összes hozzátok hasonló kutatósdit játszó pajtásotok szem előtt legyen. Eddig külön-külön azt csináltatok az intézetetekben, amit akartatok és nem törődtetek másokkal. Ennek most vége! Teljesen belebolondultatok a témákba, témaszámokba. Másra nem is tudtatok gondolni. De mostantól feladat alapú lesz minden és projekt módszer szerint dolgoztok. Mondjátok utánam: próóójekt móóccer. Oh, valaki kérdezni akar!

- Bocsánat, de nekünk tervezhető keretekre van szükségünk. A témáknál képesek voltunk előre tervezni, mert tisztában voltunk a rendelkezésre álló pénzkerettel.

- Pénz, pénz, pénz. Mást sem hallani tőletek! Ti tudósok vagytok, butuskáim! Ti nem értetek a pénzhez. De mi igen. Kaptok pénzt. Ha pedig elfogyott a pénzecskétek, kaptok még pénzt. Ha pedig túl sok pénzetek van, akkor elvesszük, mert nem kell nektek. Ilyen egyszerű! És ne törjétek a buksitokat olyan butaságon, hogy majd jó sok pénzt kértek és bespájzoltok. Nem nem nem nem nem. Akkor rátok koppintunk. Lesz egy csini kis program, ami nézi, mennyit költötök, mire költitek. Ha valami huncut mókán kapunk benneteket, akkor nem lesz többet pénzecske.

- Ki fogja eldönteni, hogy szakmailag indokolt az igényelt pénz?

- Ti, ti fogjátok eldönteni. Tudósok vagytok, mi csak a pénz részével foglalkozunk. Kaptok segítséget is. Van egy belső ellenőrzés, de ez olyan titkos szolgálatosan hangzik, ezért hívjátok csak controllingnak.

- Hogyan illeszkedik ebbe a rendszerbe a pályázatokból kapott pénz?

- Figyeltek, egyáltalán? Mi adunk nektek pénzt, nem kell bajlódni mindenféle pályázattal.

- A kapott pénzt mire költhetjük?

- Van egy csini kis Excell táblázat, annak a négyes mezője tételesen felsorolja ezt.

- Mi az az Excell?

- Te biztosan valami bioinformatikus vagy. A megbeszélés után lerajzolom neked.

- Van bármilyen működési szabályzat? Mert eddig nem találtam.

- Istenkém, még csak most indul ez az egész játszóház. Nincs semmiféle szabályzat. Majd a főigazgatók utasításokban fogják irányítani a kis munkátokat. Ha nincs több kérdés, akkor menjetek hamikázni.

A rokonok imádnak bolhapiacon vásárolni és az ott található kincsekből minket is megjutalmaznak. Legújabb szerzeményük egy járóka volt. Sajnos csak a vásárlás után vették észre, hogy az egyik szegecs eltörött. Megnyugtattak, hogy csak egy popszegecs húzóra van szükség és pikk-pakk készen lesz.

Sajnálatos módon a mindennapi felszereléseink között nem sok popszegecs húzó van, de elejét akartam venni a további kioktatásnak, ezért csak annyit mondtam, hogy meg fogom oldani. Akkor már tudtam, hogy én bizony ezt egyszerűen összecsavarozom. Később a rokon is rájöhetett valami hasonlóra, mert ő is ezt javasolta.

A szegecs, mint a képen is látható, két darabban volt. Egyik darab sem akart fogó hatására eltávozni, ezért arra gondoltam, majd a fúró szépen megoldja a dolgot. Az elgondolás szép volt, de a gyakorlat azt mutatta, hogy az aluminium szegecs inkább deformálódik, mint, hogy engedne a fúró erejének. Sőt, amikor a fúró megakadt a szegecsben, körbe forgatta azt és nem távolította el.

Csak akkor jöttem rá, hogy felesleges tovább próbálkozni, mikor a szegecs megunta, hogy a fúró pörgeti és beszorult a furatba, a fúrószál pedig eltörött.

Ekkor fogtam egy reszelőt és nekiestem. Reszeltem egy ideig, majd fogóval nagy darabokban törögettem a szegecs darabjait. Végül a fém engedelmeskedett az ember akaratának és sikerült eltávolítani.

A törött szegecset egy csavarral helyettesítettem és a járóka működő képessé vált:

Már a Function idején is szemeztem a Unity3d játékmotorral. Sokszor mondják, hogy a demoscene és a játékfejlesztés szoros kapcsolatban van, de ezt a kapcsolatot kicsit egyoldalúnak találtam. Habár nem vagyok bennfentes a játékiparban, kívülállóként azt látom, hogy a játékipar többet profitál a demoscenéből, mint fordítva.

A jövőben elképzelhető, hogy ez a trend meg fog fordulni, hiszen egyre több grafikai motor válik hozzáférhetővé és ez biztosan kihatással lesz a demoscenere is. Az egyik ilyen motor a Unity. Elsősorban játékfejlesztésre van kihegyezve, de ismerünk egy csapatot, akik - legjobb tudomásom szerint - kizárólag ezzel a motorral készítenek release-eket. Nézzük, mi a Poo-brain csapat titka!

Letöltés és installálás után regisztrálnunk kell, ki kell tölteni egy kérdőívet, csak ez után használhatjuk a rendszert. Az itt leírtak az ingyenes verzióra vonatkoznak. A fizetős változat természetesen többet tud, szebb, de a céljainknak talán előbbi is megfelel.

Tartalmak (Assets)

Miután létrehoztunk egy projektet, fel kell tölteni az tartalommal. Tartalom lehet bármi: zene, modell, textúra, kód. Ebben a leírásban a Small worlds című méltán elfeledett demó elemeit fogom felhasználni. Három dologra lesz szükség: a mantra.ogg, ant.obj, hangya_textura.png. Importáljuk be mindhármat. Ha más fájlokkal dolgozunk, nézzük meg, hogy a Unity képes-e fogadni az adott fájltípust!

A motor tartalmaz kész objektumokat is, ezeket a GameObject -> Create Other menüpont alatt találjuk. Adjunk hozzá projektünkhöz egy Terrain-t. A kamerát pedig eleve tartalmazza a jelenetünk. Helyezzük el a talajt és a hangyát a jelenetben. Ehhez egyszerűen csak húzzuk át az Assetből a jelenetünkbe (Scene). A forgatás, mozgatás és átméretezés pontosan ugyan úgy működik, mint az összes 3D szerkesztőben, de ha gondjaink vannak, nyugodtan megnézhetjük valamelyik oktató videót is.

Jelenet összeállítása

Adjunk a hangyához textúrát: A hierarchiában nyissuk ki a hangyát (1.) és a Materials alatt válasszuk ki a textúrát (2.) Most adjunk zenét a jelenethez: Jelöljük ki a kamerát. Az Add Component gomb segítségével adjunk hozzá egy Audio Source elemet. (A kamera már eleve tartalmaz egy Audio Listenert). Ez a két elem szükséges, hogy halljuk a zenét. Az audio clip-nél válasszuk ki a mantra.ogg-t.

A jelenet még elég gyér, adjunk hozzá árnyékot. Ehhez be kell állítani a modellnél, hogy vessen árnyékot. Mesh Renderer -> Cast Shadows. Ha azt akarjuk, hogy más modell árnyéka megjelenjen a hangyán, akkor a Receive Shadows-t is pipáljuk ki. Természetesen ez még nem elég. Kell egy fényforrás is. Többféle fényforrás típus közül választhatunk, de az ingyenes verzió esetén csak a Directional Light képes árnyékot képezni. Adjunk egyet a jelenetünkhöz és állítsuk be a kívánt irányba.

Végeredmény

A kész jelenetet a DVD lejátszók lejátszó gombjára emlékeztető ikonra klikkelve nézhetjük meg. A File -> Build Settings segítségével pedig futtatható alkalmazást készíthetünk belőle. Bátran játszunk a beállításokkal és nézzük meg a hatását a kész művünkre! Élvezzük ki, amíg lehet, mert a következő részekben senki nem menekül meg a kódolástól!

Van egy szélmalom harcom. Ez pedig az Excel kiűzése az életemből. De ez a program, olyan, mint egy zombi horda. Már azt hiszed, hogy biztonságban vagy tőlük, de kiderül, hogy a környezetedben valakit már megharaptak és csak idő kérdése, mikor alakul át.

Ebben a posztban megpróbálom összeszedni a legborzasztóbb Excel táblázatok jelöltjeit. Olvasóim is beszállhatnak a játékba. A feltétel, hogy publikusan elérhető legyen és ne csak ennek a versenynek a kedvéért készüljön. A lista folyamatosan fog frissülni.

1. Többszörös illesztés a cellákban.
2. Adatbázis helyett
3. Léggömb rajzolás adatokból (Technikailag ez nem táblázat, de elég borzasztó)

Előre bocsátom, nem voltam Experience-n. Elkezdtünk készíteni egy demót, de olyan korai fázisában akadt el a munka, hogy nem láttuk értelmét tartalék terv készítésének sem. Videót még tudtunk volna készíteni, de a szervezők kijelentették, hogy csak futtatható nevezések lehetnek. Release nélkül meg nem megyek.

Viszont átélhetjük az Experience hangulatát, mert itt a levetített demók listája. Már terveztem, hogy írok más partikról, de addig húztam-halasztottam a dolgot, míg érvényüket vesztették. Ebben a leírásban ezt is pótolom.

A lista

izotop by fresh!mindworkz Mivel is kezdődhetett volna az Experience, mint a szervezők saját alkotásával?
Small Beginnings by VRTX Nagyon szép effektek, a zene is jó, de nekem nem lesz a kedvencem.
refleXion by Adapt Ez egy érdekes demo, még akkor is, ha néha nem is lehet tudni, mit is lát az ember.
Primitive beings by Dead Roman A Functionon látott alkotás. Letisztult, szép demó, de semmi meglepő.
Muoto by Traction & Brainstorm Ez az alkotás is bizonyítja, hogy nem kell feltétlenül kipaszírozni a GPU-t, hogy kellemes, élvezhető demót kapjunk. A néző még a kóder színeket is megbocsátja.
Turtles all the way down by Brain Control Ezt az intrót akár mi is csinálhattuk volna. Na, nem a technikai bravúrok miatt, hanem mert van benne DNS.
905509 by Stroboholics Verjük szét kalapáccsal. Ez lehetne a jelmondata ennek a 64k intrónak. Egyébként nagyon bravúros.
Astral Flux by Inque Ez az alkotás nekem személy szerint nem tetszik. Főleg a zenéje idegesítő.
Neuron by TBC & Loonies Nem ez a TBC legjobb 4k-ja, de jól összerakott és ötletes.
Nothing is safe by Cocoon Francia durvulás. Ez a demó nagy vihart kavart, mert bár a készítők kaptak engedélyt a zeneszerzőtől, hogy felhasználják a zenéjét, a demóban mégis valami miatt a digitális vízjeles változat szerepel. Ezért sokan azt gondolták, hogy lopott a zene.
Mo’saik by Focus Design Ezt az Amigás alkotást elsősorban a zene viszi el a hátán, de az nagyon. Az ipari létesítményeken pörgő alakzatok csak ráadás.
Norwegian Pillow by Dekadence A másnaposság demóba kifejezve.
Thrice by Dekadence 64k Amiga vadulás, klasszikus alapokon. Kár, hogy a legütősebb részeket mindjárt az elején elsütik.
Stealth Ranger by Moods Plateau Az egyik magyar scener, Charlie - teljesen jogos - tömjénezése ez az alkotás. Ha megnézzük, azt is megértjük, miért.
fracture by Focus Design [web] & In-Sect & Danish Underpants Brigade
Machinist by Elude Az Amiga mesterei ismét nagyot dobbantottak. Most épp pixel shadert implementáltak.
Smoke & Mirrors by Ghostown & Loonies Steampunk stílusú Amiga demó dallamos zenével.
5 faces by Fairlight & Cloudkicker Valós idejű sugárkövetés, törés effekt. Akinek nincs brutál videókártyája, annak csak a YouTube-on élvezhető alkotás.
Calcifer by Still A Still stílusára jellemző pszichedelikus 4k. Nagyon szépek a fények benne.
RedShift by TLM & Gloom Erről az alkotásról már írtam a Function kapcsán. Nem ismételném.
Exoframe by Cocoon A franciák remek demo motorja tartogat még meglepetéseket. Például ezt, ami második lett Revision-ön.
Kohlenstoffeinheit by Akronyme Analogiker Nagyon hangulatos 4k. Mikroszkópikus lényeket utánzó alakzatokkal.
Wishful Twisting by Fnuque & Loonies Érdekes koncepció. Ez ugrik be, akár hányszor megnézem ezt a 4k-t. Remekül szinkronizált, színes képkavalkád.
Artifacts by illogictree Pszichedelikus utazás neonfényben. A Tokyo Demofest első helyezettje.
Project:ion by Nuance & Vantage Ha más neonfény, legyen teljes. A Nuance és a Vantage közös produkciója mentes az unalomtól.
Apocalypse when by Fairlight A Function egyik nagy meglepetése. Sokat kritizálták, hogy az autó olyan, mint egy játék, a lovak elnagyoltak, de nagyon hangulatos kis demó.
Return by pyrotech Ennek a demónak megvolt minden esélye, hogy halhatatlanná váljon. Remek keretbe fogott történet, mégis a látvány elhanyagolása és a nehezen érthető kapcsolat a jelenetek visszaütött. Pedig több ilyen stílusú demóra lenne szükség.

A demok

Két demó és két intro volt összeömlesztve. Sarkiróka a jó öreg 256b kategóriát választotta. Ügyesen alkalmazott egy spirál rajzoló függvényt és még a DOS mód egyik jellegzetességét is felhasználta a látvány fokozására. Feryx is egy egyszerű effektet vitt képernyőre, mindezt a leírások alapján nagyon gyorsan. A Bruteforce demóban egy részecske rendszer dobozba zárt kalandjait láthatjuk. A produkció sebessége alapján azt is gondolhatjuk, hogy a cím a megjelenítő algoritmust jellemzi. Egyébként nagyon ötletes, a jövőbeni produkciókat zenei oldalon lenne érdemes fejleszteni. A nyertes demót nem tudtam megnézni, mert valami miatt nem fut a gépemen. A 64k korlát miatt a diagnosztikai hibaüzenetekre nem is számíthatok. A leírások alapján egy dinamikus demó, amiről terveztem írni egy kis szösszenetet.

Gratulálok a nevezőknek, remélem jövőre én is megmérkőzhetek velük.

Az IGV-t mindenki úgy ismeri, mint egy rendes háziasszonyt. Nappal elvégzi a napi teendőket: megjeleníti a BAM fájlokat, mutatja a géneket. De éjjel latex ruhát húz, és nem kérhetsz tőle olyat, amit ne teljesítene. Lássuk, mit is van a palettán:

1. Több genomi pozíciót akarok látni egyszerre: Semmi gond, vesszővel elválasztva írd a koordináta mezőbe. A navigálás lehetetlenné válik, de függőlegesen elválasztva láthatunk több régiót.

2. Túl sok read-em van, túl kicsi a gépem memóriája, mégis böngészni akarok: Állítsd be a maximális read mélységet kisebbre. View -> Preferences -> Alignment menü.

3. Több illesztést akarok látni egy sávban: Ez egy kis extra munkát igényel, még az IGV elindítása előtt. A BAM-oknál be kell állítani a read groupot. Ezt megtehetjük még az illesztéskor, pl BWA-nál a SAM kimenet készítésénél az -r kapcsolóval, vagy az AddReadGroup Picard paranccsal. Ezután fűzzük össze a különböző read group-ot tartalmazó BAM fájlokat (a kötelező érvényű sorba rendezés és indexelés ne maradjon el). Ha ez megvan, az IGV elindítása és a BAM betöltése után jobb egérgomb a readekre és Color by -> Read group.

4. Találtam egy érdekes régiót, el akarom menteni. Ezt több módszerrel is elérhetjük. Az egyik a session-ök használata. A másik, ha kijelöljük a régiót és elmentjük BAM fájlként.

5. Nincs PhD hallgatóm/szakdolgozóm/rabszolgám és több száz genomi régióról akarok képet. Még ez sem probléma. Az IGV távvezérelhető JAVA programokból, vagy saját scriptből. Az IGV saját script nyelve nem ismeri a változókat, ciklusokat, feltételeket, csak a parancsokat, de egy kis metaprobramozással bármit meg tudunk oldani. A parancsok listája itt található. A következő szkripttel IGV vezérlő programot írhatunk:

#!/usr/bin/python3
import sys
for bam in sys.argv[4:]:
   print("load", bam)
print("snapshotDirectory", sys.argv[3])
print("genome",sys.argv[2])
positions = open(sys.argv[1])
for line in positions:
   fields = line.rstrip().split("\t")
   pos = fields[0].split()[0] + ":" + str(int(fields[1])-500) + "-" + str(int(fields[2])+500)
   print("goto", pos)
   print("collapse")
   print("snapshot", pos + ".png")
positions.close()

A szkript első paraméterként egy BED fájlt vár, ami a számunkra fontos genomi pozíciókat tartalmazza. Második paramétere a genom fájl, amit célszerű abszolút elérési úttal megadni. Harmadik paraméter a képek könyvtára, szintén legyen abszolút elérési út. Negyedik paramétertől kezdődően a BAM fájlok listáját lehet megadni.

6. Van egy elvetemült annotációs fájlom, amit nem támogat az IGV. Az elvetemült fájlformátumodat konvertáld át nem elvetemült formátumra. Ha ez mégsem járható út, az IGV-nek el lehet magyarázni, hogy hol találja az értékes információt. Erre egy direktívát kell hozzáadni a fájl elejéhez, ahol kulcs=érték formátumban adhatjuk meg, melyik oszlop mit jelent. Például:

#columns chr=1 start=2 end=3

Ez azt jelenti, hogy az első oszlop a kromoszóma nevét, a második oszlop a kezdőpontot, a harmadik oszlop a végpontot jelöli.

7. Rengeteg beállítást eszközöltem. Hogyan mentsem el ezeket? A munkafolyamat elmentése a megoldás. (File -> Save session) Ez egy XML fájl, akár mi magunk is szerkeszthetjük, vagy programból is létrehozhatjuk. A szerkezetére nem térnék ki.

Rengeteg ingyenes genom nézegető van. Vannak szebbek, vannak könnyebben kezelhetőek, de az IGV egyediségével kitűnik mind közül.

A Magyar Bioinformatikai Társaság újabb ülésének célja a proteomika bioinformatika sokszínűségének bemutatása. Az előadások családias hangulatban zajlottak. Számomra meglepő volt, mennyi új arcot láttam.

Pongor Sándor: Amiről a baktériumok beszélnek: Kommunikáció és kooperáció mikrobiális közösségekben

Bakteriális szinten is megfigyelhető bizonyos kooperáció. Hátterében az áll, hogy egy egysejtű a szerves anyag lebontásához az enzim helyett szignál fehérjét bocsát ki, majd ezzel készteti a többi egysejtűt az enzim kibocsátására. Együttesen könnyebben lebontják a szerves anyagot. Az egyik legegyszerűbb ilyen kommunikáció az AHL szignal, két gént tartalmaz. A különböző törzsekben nem taxonómia alapján, hanem életstílus alapján konzerválódnak a gének. Ezután mutánsokat izoláltak, amelyeket két csoportra bontottak: nem kooperáló, illetve nem kommunikáló. A nem kooperálók gyakorlatilag halálra vannak ítélve, de a nem kommunikálók közé, ha kis számú vad típusú baktériumot helyeztek, azok egyfajta vezetőként viselkedtek. Hatásukra a mutánsok is kooperálni kezdtek. A laboratóriumi vizsgálatok után számítógépes modelleket készítettek, amelyek segítségével az interakciókat próbálták megérteni.

Cserző Miklós: Pontmutációk következményei az emberi genom spanion régióiban

A spanionok lehetséges szerepét igyekeztek meghatározni több módszerrel. Először az UTR és ncRNS régiókban nézték, hogy mennyire dúsul fel a spanoin klaszterek száma. ncRNS esetén szépen együtt mozogtak az eloszlások. Végül megnézték, hogy mennyi SNP esik spanionokra, de viszonylag kevés (2700), és ezek közül 1600-hoz rendelt valamilyen betegséget a dbSNP. A nukleotid eloszlások azt mutatták, hogy sok CG dinukleotid fordul elő. Az előadás végén a következő kérdés hangzott el: - Nem lehet, hogy a spanoin csak egy új név a nem kódoló RNS-eknek? Válasz: Ha így is van, nem volt szándékos.

Kalmár Lajos: A rendezetlen fehérjék funkcionális evolúciója

A rendezetlen fehérjék vizsgálata nehézkes: Rendellenes a PAGE futásuk, nem kristályosíthatóak, többféle harmadlagos szerkezetet vehetnek fel, és a bioinformatikai eszközök száma is kevés. Többnyire szabályozó folyamatokban vesznek részt. Elmondható, hogy itt sem az aminosav sorrend, ami konzerválódott, hanem a funkcionális szereppel bíró aminosav kompozíciók. Erre egyik példa a processzív enzimekben található linker régió.

Barta Endre: Regulációs SNP-k genomszintű elemzése ChIP-seq adatok alapján

Az SRA-ból leszedtek nagy mennyiségű, transzkripciós faktor kötőhely kísérletekhez tartozó ember és egér Chip-seq adatokat. A szekvenciákból de-novo motívum kereséssel meghatározták a lehetséges TFBS-ek pozíció specifikus súlymátrixait. A mátrixokat visszatérképezték a Chip-seq régiókra és összevetették a dbSNP adatbázissal. Létrehoztak egy hátteret is. Ebben olyan szekvenciák kerültek, amelyekre nem estek chip-seq csúcsok. Az adatokat különböző csoportokra osztották, aszerint, hogy az snp-k csak emberekben mutatnak eltérést, vagy más emlős fajokban is.

Melegh Béla: Array adatok populációgenetikai hasznosíthatósága

SNP chippel különböző etnikumokat vizsgáltak, az eredményeket főkomponens analízisnek vetették alá, majd a látottakat értelmezni próbálták. Az első vizsgálatok során az európai országok adták össze adataikat, amiből megállapították, hogy mi, Magyarok igen kis mértékben különbözünk az Osztrákoktól. A romákat is vizsgálták, és azt az eredményt kapták, hogy inkább a Közel-Keleten kell keresni az eredetüket India helyett. Ezután három elég ellentmondásos eredményt mutattak be, ahol magyar, roma és török mintákat vetettek össze. Az első esetben még a magyar minták teljesen elkülönültek a törököktől, de ahogy újabb és újabb népcsoportokat adtak az analízishez, úgy változott a három eredeti népcsoport viszonya. Ennek ellenére mindegyikre kaptunk magyarázatot. Végül egy olyan vizsgálatot is láthattunk, ahol a magyarok és az Orkney-szigeteken élő skótok álltak a legközelebbi kapcsolatban.

Gáspári Zoltán: Dinamikus szerkezeti bioinformatika a fehérjeműködés vizsgálatában

A fehérje szerkezeti modellek a fehérjék nem minden állapotát írják le precízen. Az NMR szerkezet meghatározás segítségével leírt jellemzőket a fehérjék csak bizonyos kényszerfeltételek között veszik fel. A klasszikus molekula dinamika képes leírni a konformációs átmeneteket, de nehezen feleltethető meg a mért szerkezeti jellemzőkkel. Az előadásban a két módszer egyesítésére tett erőfeszítéseket mutatták be. Ez egy sokaság alapú reprezentáció, aminek az az alapja, hogy egy oldatban a többféle konformer fordul elő, ezért a mérések csak ezek átlagát mutathatják. Az új modell megfelelően írja le a kísérletek során kapott 

Farkas Illés: Átfedő fehérje csoportok és biológiai funkciók az egysejtű-többsejtű átalakulás során

Az egysejtű-többsejtű átalakulás többször lezajlott az evolúció során. A folyamat jobb megértése érdekében olyan modell organizmusokat vizsgáltak, amelyek az egyedfejlődésük során lépik át ezt a határvonalat. Ezen élőlények fehérje doménjeit mátrixokba rendezték és statisztikailag elemezték őket, hogy melyek lehetnek fontosak az átalakulás során.

Szilágyi András: Fehérjék funkcionális energiafelszíne: szimulációk és elemzések

Megjelent egy cikk, ami a fehérjékben a torziós szögeket főkomponens analízissel elemezte. Az előadásban bemutatott kutatás célja az volt, hogy megtudják, a cikkben leírtak más, hatékonyabb módszerekkel reprodukálhatóak-e. Az egyik ilyen módszer a durva szemcsés módszer, ami virtuális atomokat vezet be, hogy egyszerűsítse a térbeli szerkezeteket. A másik hatékonyabb módszer a MARTINI modell, ami egy erőteret is tartalmazó modell, eredetileg membrán szimulációra kifejlesztve. Az eredményeket csak részben sikerült visszakapni. Azt vették észre, hogy a modell érzékeny a szimulációs időre. Rosszul megválasztva ezt a paramétert, közönséges Gauss eloszlásokat kaptak. Ami még érdekesebb volt, hogy véletlen bolyongással is megkapták a cikkben leközölt eredményeket. Konklúzió: a cikk eredményei hibásak és könnyen más is ebbe a hibába eshet, ha egy sokdimenziós elemzésnél a mintavételezést elszúrja. Ahogy az előadásban is elhangzott: "Sokdimenziós térben olyan sok lehetőség van"

- Milyen Windows van ezek a laptopon?

- Windows 7.

- Windows 97?

- Nem, Windows 7.

- Windows 2007?

- Nem, Windows 7, ami a Windows 8 előtt volt.

- Van már Windows 8?

Trevor minden nap azza kezdte munkáját, hogy megnyitotta a munkahelyi levelezést. Tucatnyi, a munkájához elengedhetetlen levél került a szeme elé. Első helyen a tésztarendelés szerepelt. Az egyik laborban volt valaki, akinek a hugának a barátjának a szobatársa tésztákkal seftelt és rajta keresztül töménytelen mennyiségű tésztához lehetett hozzájutni.

A következő levélben egy másik munkatárs mézet árult. Trevor már kezdte úgy ézerni, hogy a piacra tévedt, de akkor meglátta a következő levelet, ami jelezte, hogy még mindig egy akadémiai kutatóhelyen dolgozi: Eltűnt a 10 forint értékű műanyag pöcök az egyik több millióba kerülő berendezésből, amitől az használhatatlanná vált. A kutató kétségbeesetten írta, hogy aki elvitte a pöcköt, azonnal hozza vissza.

Trevor látta, hogy a munkaügyről is írtak neki levelet. Megnyitotta, és legnagyobb meglepetésére nem utazási ajánlatot küldtek neki, mint általában, hanem kutatási tervet kellett írnia az XJ 234-es pályázathoz. Trevornak fogalma sem volt róla, mi lehet az XJ 234-es pályázat.

Trevor többször elborzadt az adminisztrátor nyilvántartási számokhoz fűződő perverz vonzalmán. Titkon gyanította, hogy a nő a gyerekeit sem néven nevezi, hanem a TAJ szám alapján szólítja őket. Szerencsére a levél tartalmazott egy mellékletet is, amiben szerepelt a kutatási terv rendes neve: Fásszárú gyömölcsfajták.... Trevor eddig jutott. Még egyszer elkezdte: Fásszárú gyömölcs.... Érezte, hogy túl gyorsan akarja megfejteni a talányt, ezért jó kutatóhoz méltóan részekre szedte a szöveget, és kezdte azzal, amit ért: Fásszárú.

Azért, hogy megértsük Trevor zavarát, nézzük, min is dolgozik: csirke genomban keres a tojás hozamának növeléséért felelős géneket. Búza antivirális kisRNS-ek pontenciális célpontjait keresi. Baktérium rezisztencia faktorokat keres. Ezek a fő projektjei, de emellett minden olyan apró munkát is megcsinál, amivel felkeresik. Ezeket nézve, egyik sem fásszárú. Trevor zavarát tovább növelte, hogy a kiírás szerint már fél éve ezen a munkán dolgozik, és ha már ennyi időt elszöszmötölt a fásszárú növényekkel, akkor igazán illene egy rendes kutatási tervet összehoznia.

Az e-mail alján diszkrét ösztönzés csücsült: "Kérem a kérést kiemelten kezelni." Trevor reménykedve nézett a naptárra, de nem volt április 1. Végül megnézte, ki kapta meg a levelet rajta kívül, felkereste őket, így tudta meg, hogy berakták egy pályázatba, mert aki ténylegesen dolgozik a projekten, az másik forrásból kapja a fizetését. Valakit mindenképp bele kellett írni, így esett a választás Trevorra, aki ugyan nem fog semmit dolgozni a munkán, de ebből rendezik a bérét.

Én ahhoz a korosztályhoz tartozom, akik nem látták Öveges József kísérleteit a TV-ben. Gyerekkoromban viszont jelentek meg olyan könyvek, amelyek a híres kísérletek leírásait tartalmazták a kornak megfelelő eszközökkel. Apámmal meg is csináltuk a legtöbbet. Ma már valószínűleg gyermek veszélyeztetésnek minősülne a legtöbb kísérlet, ennek ellenére élveztem őket.

Mikor először láttam az Állítólag című műsort (Mythbusters), kicsit Öveges szellemét véltem benne felfedezni. Mikor még volt időm TV-t nézni, szerettem ezt a műsort, annak ellenére, hogy sokan vádolták azzal, hogy semmi köze a tudományhoz. Tagadhatatlan, hogy megmozgatta a néző agyát. A műsor kérdéseket tett fel és lehetséges válaszokat adott rá. A tudományban is valami hasonlót csinálunk.

Mikor megtudtam, hogy van egy hazai műsor, ahol fizikai kísérleteket mutatnak be popularista eszközökkel, gondoltam, adok neki egy esélyt. Ez volt a Brutális fizika.

Az aktuális epizódban az erőkarokat mutatták be. Három műsorvezető volt. Az első egy fizika professzor, aki a kísérletek hátterét magyarázta el. A második az ő segédje volt, akin ostoba poénok csattantak és ezt szó nélkül tűrte. A harmadik műsorvezető szerepére viszont nem tudtam rájönni. A bemutatkozás alkalmával újságíróként jellemezték, elmondása szerint a robbanások érdeklik. Ez az attitűd inkább a Brutális kémia című műsorba lenne hasznos.

Bemelegítés gyanánt libikókán hintáztak, majd az erőkar segítségével egy nő felemelte a teljes magyar szumó szövetséget és stáb egy részét. Közben amerikai mintára egyszerű animációkkal szemléltették mondandójukat. Mindez nagyon jó volt. Elöljáróban utaltak rá, hogy egy hajítógépet is ki fognak próbálni. Ez izgalmasan hangzott, mert már láttam, hogyan képes eldobni egy ilyen gép egy autóroncsot 50 méterre.

Közben, hogy a történelemórának helyet adjanak, újságírónk elment a Hadtudományi Múzeumba, ahol igazából semmi relevánsat nem tudtak mutatni. Nem volt a birtokukban egyetlen hajítógép sem, de arról sem volt információjuk, hogy Magyarországon bevetettek-e ilyet. Végül nem tudták tovább húzni az időt, kénytelenek voltak bemutatni saját készítésű ostromgépüket.

Először arról beszéltek, hogy a gépet két hétig csinálta 11 ember. Bevallom, kicsit soknak találom, de mivel nekem egy bojler szerelése is három napig tartott, nem lehet egyetlen szavam sem. Később viszont már két évet emlegettek, de ebből 1,9 év szerintem az engedélyeztetéssel telhetett el. Biztos attól féltek a bürokraták, hogy le akarnak bontani vele egy plázát.

Végül néhány finomhangolás után jött a nagy kilövés. Mit lőttek ki? Egy plüss macskát. Ez nagyon brutális. Nem is értem, miért nem az éjszakai sávban sugározták ezt a műsort. A játékot ráadásul sikerült eldobni talán 10 méterre. De ők ennél is tovább mentek. Eldobtak egy kitömött fácánt, egy dinnyét és egy rongybabát. Minden egyes kilövés előtt az újságíró ostoba monológokat mondott, aminek értelme nem volt, viccesnek nem nevezném, de legalább sokáig mondta. A legtöbb lövés ráadásul hátrafelé ment. Ha ezt egy valódi támadásban vetették volna be, több ostromló halt volna meg, mint várvédő. De ki tudja? Talán a varvédők a röhögésben pusztultak volna el, ha azt látják, hogy plüss macskával jönnek ellenük.

Nyilván drága mulatság egy személyautót elhajítani, de miért nem próbálkoztak valami nehézzel? Például egy tele bevásárló szatyorral? Ennek súlyát mindenki átérezné, aki intézett már hétvégi bevásárlást. Esetleg egy megrakott utazóbőröndöt? Medicinlabdát? Természetesen ehhez az kell, hogy működjön a szerkezet.

Miközben hallgattam a bárgyú monológokat és reménykedtem, hogy valami látványos következik, arra gondoltam, megint sikerült teljesen haszontalanul eltölteni egy órát. Aki teheti, inkább vegye meg DVD-n Öveges professzor kísérleteit. Sokkal tanúságosabb. De akit a pusztítás akarja látni, a YouTube-on keményebbeket talál. (És a "vicces" monológokat sem kell végigszenvedni)

Nemrég megkértek, hogy a UEA kimenetét formázzam be Excellel, de úgy, hogy a rekordok ne egymás alatt legyenek, hanem külön munkafüzeteken. A probléma az volt, hogy körülbelül 2500 rekord volt. Rögtön a régi vicc jutott eszembe:

- Az micsoda?
- Cukorborsó.
- Kérek egy kilót. Külön-külön becsomagolva. Selyempapírba.

Már majdnem elküldtem a fenébe a kérelmezőt, hogy nekem nincs is Excellem, csak LibreOffice-m, amikor eszembe jutott, hogy ez nem is hátrány. A beépített makrók segítségével biztosan meg lehet oldani a feladatot. Elkezdtem utána olvasni a LibreOffice programozásának, és még jobbat találtam. A program ugyanis vezérelhető egy másik alkalmazásból! A Java-t választottam a lehetséges nyelvek közül.

Először is telepíteni kell a LibreOffice SDK-t, ami Ubuntu alatt fájdalom mentes. Ha Eclipse-el dolgozunk, meg kell adni négy jar-t a projektnek: juh.jar, jurt.jar, ridl.jar, unoil.jar. A táblázatkezelő vezérléséhez a következő osztályokra lesz szükség:

import com.sun.star.beans.PropertyVetoException;
import com.sun.star.beans.UnknownPropertyException;
import com.sun.star.beans.XPropertySet;
import com.sun.star.comp.helper.BootstrapException;
import com.sun.star.container.NoSuchElementException;
import com.sun.star.frame.XComponentLoader;
import com.sun.star.lang.IllegalArgumentException;
import com.sun.star.lang.IndexOutOfBoundsException;
import com.sun.star.lang.WrappedTargetException;
import com.sun.star.lang.XComponent;
import com.sun.star.lang.XMultiComponentFactory;
import com.sun.star.table.XCell;
import com.sun.star.table.XCellRange;
import com.sun.star.uno.Exception;
import com.sun.star.uno.UnoRuntime;
import com.sun.star.uno.XComponentContext;
import com.sun.star.sheet.XSpreadsheet;


A legfontosabb osztály, amit én csak excel-nek neveztem el:

private com.sun.star.sheet.XSpreadsheetDocument excel = null;


A távvezérlés egyfajta szerializálással történik, ezért tűnik bonyolultnak az inicializálás. Általában itt is elmondhatjuk, hogy a dokumentáció elég hiányos. A hivatalos javadoc pont a lényeget nem tartalmazza. A példaprogramok viszont első rangúak, azon belül is a Helper végződésű osztályokat érdemes nézni.

XComponentContext comp = com.sun.star.comp.helper.Bootstrap.bootstrap();
            System.err.println("Connecting...");
            XMultiComponentFactory multi = comp.getServiceManager();
            XComponentLoader loader = UnoRuntime.queryInterface(XComponentLoader.class, multi.createInstanceWithContext("com.sun.star.frame.Desktop", comp));
            XComponent xc = loader.loadComponentFromURL("private:factory/scalc", "_blank", 0, new com.sun.star.beans.PropertyValue[0]);
            excel = UnoRuntime.queryInterface(com.sun.star.sheet.XSpreadsheetDocument.class, xc);


A cellák feltöltése ezek után már gyerekjáték: Ha számot akarunk beírni, a setValue metódust használhatjuk, minden más esetben a setFormula a nyerő:

excel.getSheets().insertNewByName(name, limit);
            XSpreadsheet page = UnoRuntime.queryInterface(XSpreadsheet.class, excel.getSheets().getByName(name));
XCell cell = page.getCellByPosition(0, 2);
double value = 5.0;
cell.setFormula("Chromosome");
cell = page.getCellByPosition(1, 4);
cell.setValue(value);


Ha formázni is szeretnénk a cellákat, először ki kell jelölni a cellákat, majd a setPropertyValue segítségével beállítjuk azt, amit szeretnénk.

XCellRange cells = page.getCellRangeByPosition(0, 0, 20, 40);
XPropertySet prop = UnoRuntime.queryInterface(XPropertySet.class, cells);
prop.setPropertyValue("CharFontName", "Courier");


Egy kis segítség az elérhető jellemzők listájához:

Property[] p = prop.getPropertySetInfo().getProperties();
for(Property i:p){
   System.out.println(i.Name + " " + i.Type.toString());
}

Ennek segítségével már tudtam írni egy programot, ami elkészítette a kívánt táblázatot. Mikor a megrendelő meglátta, már ő is látta, mennyire áttekinthetetlen.

Perlben előszeretettel használok hash of hash, hash of array és más adatstruktúrát. Javaban is sokszor látni generikusokat a kódomban. Egyetlen probléma velük, hogy csak a rendelkezésre álló memória határain belül lehet élni lehetőségeikkel.

A nagyományos SQL alapú adatbázis kezelőkben hasonló struktúrák elkészítése nem egyszerű feladat, de szerencsére nincs is rá szükség, mert van egy adatbázis, ami pont a fent említett struktúrákat támogatja. A neve Redis.

A lényege, hogy nem táblázatban kell gondolkodni, hanem kulcs-érték párokban. A kulcs minden esetben egy szöveg, de az érték többféle típus is lehet. Nyilván a legegyszerűbb, ha az érték maga is egy szöveg. Szöveg alatt bármilyen bináris adatot kell érteni. Ez önmagában még nem lenne túl érdekes, de ha az érték egy lista, akkor a hash of array struktúrának megfelelő adatbázis szerkezetet kapunk. A lista sorrendje kötött, az elemek beillesztésének sorrendje határozza meg.

Használhatunk hasítótáblát az értékek között is. Itt csak egy szint engedélyezett, ami annyit tesz, hogy nem tudunk "hash of hash of hash" struktúráknak megfelelő szerkezetet létrehozni a beépített eszközök segítségével. De ha nem írtózunk a barkács megoldásoktól, akkor bevezethetünk különböző prefixeket a kulcsok esetén és máris tetszőleges mélységig vihetjük a hasheket (és az átláthatatlanságot is).

Szerencsére további struktúrák is vannak a Redis tarsolyában. Az egyik a halmazok (set). Ha nem érdekel minket az értékek sorrendje, ez az ideális választás. Ennek egy speciális változata a rendezett halmaz (sorted set).

Telepítése roppant egyszerű. Ubuntu és Fedora alatt is gond nélkül telepítettem, de be kell vallani, a Fedorás telepítés nem hoz létre központi adatbázist, hanem a felhasználó könyvtárába elhelyez egy redis.db állományt. A kliens programját a redis-cli paranccsal indíthatjuk.

Ha saját alkalmazásból szeretnénk meghívni, különböző API-k állnak a rendelkezésünkre. Én eddig a C, R és Python API-kat próbáltam ki, komolyabb problémák nélkül. (Az R verzió kiforratlannak tűnik) Amennyire jó és részletes a parancsok dokumentációja, annyira hiányos az API-k leírása, ezért röviden ezekről is írnék.

C API

A hivatalos C API a hiredis, ami egy magas szintű API, gyakorlatilag a konzolos parancsokat írhatjuk be a redisCommand második paraméterébe szövegként. Az első parameter az adatbázis kapcsolatot leíró változó. Az utasítás visszatérési értéke egy redisReply struktúra, ami az összes lehetséges visszatérési típushoz tartalmaz mezőket. Ez feltételezi, hogy a programozó tudja, milyen típust kell visszakapni. A defenzív kódolást a type mező támogatja. Ha szöveg a visszatérési érték, akkor az str, egész esetén az integer mező tartalmazza az adatot. Több eredményt is várunk az adatbázisból, az elements tömböt kell bejárni.

Mint említettem, a dokumentáció hiányos, de bőséges mennyiségű példaprogramot mellékelnek, amit akár a dokumentáció helyett is olvashatunk.

R API

Az rredis a CRAN-on megtalálható, tehát telepítése probléma mentes. A C API-hoz képest itt minden egyes utasításnak egy parancs felel meg. A parancsok neve megegyezik a konzolos parancs nevével, redis prefixel ellátva.

Python API

Python esetén is több API létezik, én a redis-py-t használtam. Az adatbázis kapcsolat létrejötte után kapunk egy osztályt. Ennek az osztálynak a metódusai az egyes műveletek. A nyelv erősen típusos jellege miatt minden esetben pontosan tudnunk kell, milyen típusú értékeket kaphatunk vissza az adatbázisból. A hibakeresésnél érdemes ezt ellenőrizni.

Mire használható ez az adatbázis? Ezt is be fogom mutatni.

Eddig elég sok negatív dolgot írtam a cégekről, pedig egy területen nagyon is az akadémiai szféra előtt járnak, ez pedig az információ rendszerezése. Gondolok itt arra, hogy a futó projektek hol tartanak, kinek, mi van vissza egy feladatból. Az újonan belépőknek dokumentációk állnak a rendelkezésére, amelyek segítségével felveheti a fonalat és rövid időn belül hatékonyan tud dolgozni.

Most sokan bizonyára felhördülnek, és sztorikat mesélnek arról, hogy bezzeg XY cégnél milyen trehány/hibás/elavult a dokumentáció vagy mennyi hiba is található bennük, de erre csak azt tudom mondani, még nem látták, hogyan megy ez a legtöbb kutatóintézetben. A jobb helyeken van egy könyvtár, amiben általában nincsenek további könyvtárak és oda van beömlesztve egymillió azonos nevű Excel/Word dokumentum. A rosszabb helyeken papírfecnikre írják a fontos dolgokat és rossz szemmel néznek rád, ha ki akarod nyitni az ablakot.

A munkatársaknak e-mailen küldik el a részeredményeket, amiket vagy megtalálnak, vagy elvesznek a "Call for paper" kezdetű levelek között. A dokumentum verziók kezelése felér egy elme-trükkel, mert először számozzák a verziókat, majd később áttérnek az abc betüire, esetleg mégis visszatérnek a számokra.

A gépek állapotáról pedig ne is beszéljünk. Az igényesebbek behozzák a rokonok levedlett "gamer" konfigurációit, amit a számítógép bontók is könnyes nevetés közepette vesznek át, a türelmesek pedig bekapcsolás után vagy megcsinálnak egy kísérlet sorozatot, vagy megisszák a reggeli kávéjukat.

A fent vázolt helyzeten igyekeztem javítani különböző szerver oldali megoldásokkal, amit egy kis nagyképűséggel még felhőnek is hívhatunk. A megoldások bárki számára elérhető eszközökből áll. (A jövöben posztokat fogok írni ezek alternatíváiról ), más részüket viszont én fejlesztettem. Ezek az oldalak bűn rondák funkció központúak.

A tudás összegyűjtése

Az egyes vizsgálatok eredményeit egy közönséges MediaWiki oldalon gyűjtjük. A telepítése rém egyszerű, karbantartást alig igényel. Képek, táblázatok és leíró szövegek tárolására és megosztására ideális. Többé nem jelent gondot, hogy többen is szerkesztenek valamit, nincs Excel kompatibilitási probléma. Beépített verzió kezelő is van, tehát látható, hogy ki szerkesztette az adott bejegyzést és mikor. Hátránya, hogy saját formázási kódokat kell használni, ami elriaszthat sok embert.

Fájlok tárolása

Az e-mail attachmentek, mint fájl tárolási és megosztási módszer szerintem rettenetes. Egy közönséges FTP szerverrel váltottuk ki. Az FTP eléréshez rengeteg eszköz áll rendelkezésre, erre még a legvénebb profot is meg lehet tanítani. Hátránya, hogy alapból nincs semmilyen védelem a felülírás ellen, a közel egyforma nevű fájlok ellen és a káosz egyéb formái elle, amire csak kutató képes lehet.

Szekvencia homológia

Néha szükség lehet saját Blast szerverre. Nálunk előfordulnak olyan szekvenciák, amelyeket még nem publikáltunk, de dolgozni kell velük. A parancssoros megoldások szóba sem jöhetnek, de egy webes megoldás még belefér. Nálunk kétféle Blast szerver van. Az egyik az NCBI-ról letöltött, ami mind funkciójában, mind küllemében arra hasonlít, de saját szekvenciák vannak benne. A másik egy saját klón, ahol egyedi igényeket is ki kellett szolgálni. Jelen esetben a cél az volt, hogy a találatokhoz tartozó short readeket is látni akarták.

Ezért egy egyszerű PHP oldalt készítettem, ami lefuttatja a Blastot. Az eredményt XML-ben kapom vissza, DOM segítségével kinyerem a lényeges információt és készítek belőle egy linket, amit a Blast kimenet végére odaillesztek. Mire mutat a link? Egy genom böngészőre. A hátránya, hogy mivel én állítom elő az eredményt, ezért az nagymértékben különbözik az NCBI-os Blastnál megszokott képtől.

A másik saját fejlesztésű eszköz egy egyszerű kisRNS kereső. Gyakorlatilag egy webes fuzznuc, annyira megbolondítva, hogy több mintában meg kellett jeleníteni a kisRNS abundanciáját. Először a PHP fuzznucot hívott volna, de annyira lassú volt, hogy inkább implementáltam egy rövid C kódot naív szöveg kereséssel a mismatchek miatt. Még ez is 3x gyorsabb volt, mint a fuzznuc.

Kevés PHP kódot akartam írni, és szerettem volna, ha egy szkriptben meg tudom oldani az eredmények szöveges megjelenítését és a grafikont az abundancia értékekkel, ezért a PHP HTML5-öt generál SVG-vel.

A genom vizualizálása

Az IGV remek eszköz, de egy eukarióta genom és a hozzá tartozó readek megjelenítéséhez komoly erőforrások kellenek, amik nem minden laborgépen érhetőek el. Ezért telepítettem egy JBrowsert. Ez egy rendkívül egyszerűen installálható eszköz, kliens oldalon csak egy böngészőre van szükség. Bár a telepítés egyszerű, a szerver oldalon hatalmas index könyvtárakat készít. Egy 10 ezer scaffoldból álló növényre 3 napig futott az indexelés. Hátránya, hogy bár leveszi a terhet a kliensről, szerveroldalon komoly erőforrásokra van szükség.

Kód verziókövetés

A legtöbb bioinformatikus nem használ verziókövető rendszert, mert a kódon csak egyedül dolgozik. De ha több szerveren is használja ugyan azt a kódbázist, és még mindegyiken valamit változtat, könnyen azon kaphatja magát, hogy ugyan olyan néven több szkript is van, és mindegyik mást csinál. Végül a kódban turkálva kell kitalálni, mit is csinál az adott program, mert ugye dokumentációt nem írunk. (Igen, én sem)

Ilyen esetben is hasznos lehet a verziókövető rendszer. Nálam ez kilóg a sorból, mert egészen egyszerűen a GitHub-ot használom, nem saját telepítésű repositoryt. Nincs tárhely probléma, nem igényel karbantartást, bárhonnan elérhető. Hátránya, hogy mindenki látja, milyen béna kódokat írok.

Jelen pillanatban ezekből az elemekből áll a felhőcske. Ami még hiányzik, egy jó projekt követő rendszer, amivel a jegyzőkönyveim is egy helyen lennének. Amint megtalálom a megfelelőt, arról is írni fogok.

Demoscene szempontból a legfontosabb bővítmény típus szerintem az export plugin. Ennek segítségével ültethetjük át munkánkat a demóba. A bővítmény regisztrálását a RegisterSceneSaverPlugin() függvény végzi. A negyedik paraméterrel kell átadni a SceneSaverData osztály egy leszármazottját.

A dokumentáció csak a Save() virtuális tagfüggvényt említi, de kell egy statikus gyártó metódus is konstruktor helyett. Ez a megoldás egyébként általános a Cinema4D-ben.

A Save() függvény egyik paramétere a mentés során megadott fájlnév, míg a BaseDocument osztályon keresztül az összes grafikus objektumot elérhetjük. Gyakorlatilag ez a Cinema 4D felhasználói felületén a jobb oldalon található fa struktúra. Az alábbi kód az egyszerűség kedvéért csak a legfelső szint objektumait járja végig:

BaseObject *obj = doc->GetFirstObject();
do{
  switch(obj->GetType()){
    case Opolygon:
    break;
    case Ocamera:
    break;
  }
}while(obj = obj->GetNext());

Az adatokat a BaseFile osztályon keresztül írhatjuk ki. A következő kódrészlet ezt demonstrálja:

BaseFile *file = BaseFile::AutoAlloc();
Filename *filename = new Filename("test.out");
file->Open(filename, FILEOPEN_WRITE, FILEDIALOG_ANY, BYTEORDER_INTEL, 0, 0);
file->WriteString("Data");
file->Close();

Gyakorlatilag az összes adattípushoz van egy metódus. Ha szöveges állományokat akarunk készíteni, akkor meglepődve tapasztalhatjuk, hogy bináris adatok is kiírásra kerülnek. Fórumokat bújva azt a megoldást találtam, hogy karakterenként kell kiírni a sztringet. Nevetséges, de tényleg ez tűnik az egyetlen járható útnak.

Fontos lehet hibakereső üzeneteket hagyni. A Cinema4D rendelkezik egy saját konzollal, ahová a bővítmények is írhatnak. Az ablak a Script -> Console menüponttal kapcsolható be. A kódban a GePrint() segítségével tudunk írni rá.

Sajnos a fejlesztés egyik hátulütője, hogy nem tudjuk közvetlenül tesztelni a megírt kódot. Lefordítjuk, elindítjuk a Cinema4D-t, lefagyasztjuk az egészet a bővítményünkkel, majd visszatérünk a Visual Studioba és átírunk valamit. Ez egy elég időigényes procedúra, különösen a tanulási fázisban, amikor még a metódusok útvesztőjében is keresgélni kell. Célszerű ezért  - ahogy a dokumentáció is javasolja - defenzíven programozni és a paraméterekhez grafikus felületet fejleszteni, ahol futás időben láthatjuk a hatásaikat. A következő részben erről fogunk beszélni.

Mint minden bioinformatikus, én is Perlel kezdtem megismerni a szkriptek világát. Sokáig ellenálltam a Python csábításának, de be kellett látnom, hogy ha továbbra is naprakész akarok lenni, nem hagyhatom figyelmen kívül a nyelvet.

Korábban is voltak időszakos fellángolásaim, amikor úgy döntöttem, megtanulom a nyelvet, de mindig találtam valami idegesítő tulajdonságot, ami eltántorított attól, hogy teljesen elsajátítsam. Először a megváltoztathatatlan típusok dühítettek fel. Nem értettem, hogy egy dinamikus nyelvben mi keresnivalója van ezeknek? Tuple? Még a név is röhejes. Mentem is vissza Perl alá, ahol nyugodtan összeszorozhattam akár a sztringeket is. Később beszéltek nekem a többszálúságról, ami más megvilágításba helyezte ezeket a típusokat.

Ahogy telt az idő, megint arra gondoltam, meg kéne tanulni Pythonban programozni. Második alkalommal már az osztályokig is eljutottam, ahol azt láttam, hogy a felhasználó moduljai valami eszetlen könyvtárstruktúrában vannak szétosztva. __init__.py Ez valami vicc? Mi ez a beteges vonzódás a kettős alulvonáshoz? Folytattam is a munkát Perlben, ahol írhattam az 1; minden modul végére.

Majd olvastam, hogy a 3-as verzió nem is kompatibilis a 2-essel. Most akkor melyiket tanuljam meg? Egyiket sem.

Bár én folyamatosan csak hibákat láttam a nyelvben, mégis egyre jobban terjedt. Először a telefonomhoz töltöttem le egy értelmezőt, ami végre visszaadta a C64-nél megtapasztalt érzést, milyen is, ha egy gép azonnal programozható (a hangulatot csak az rontotta, hogy a telefon gombjaival elég nehéz programozni). Később a Blenderben tűnt fel, mint szkript nyelv (amit még használtam is). Még az Amigás vonal sem menekült meg tőle, hiszen az OS4 is ezt választotta. De ha már említettük a 3D programokat, meg kell említeni, hogy ott van a Cinema4D-ben is.

Legutóbb egy weboldal karbantartásánál lettem figyelmes arra, hogy a kép galériát valami Djangoban hozták létre. Nem nehéz kitalálni, hogy ez is Pythonon alapszik.

Igazából napestig lehet keresni a kifogásokat, miért nem akarok Pythonban programozni. Ugyan ennyi ideig lehet sorolni azt is, milyen lehetőségektől esek el ezáltal. Ezért pár hete úgy döntöttem, Perl helyett Pythonban írom a munkahelyi szkripteket és megtanulom rendesen ezt a nyelvet.

Az üzletkötők mindig is a szívem csücskei voltak. Talán azért, mert ez egy nehéz szakma és rendkívül sokrétű tudást igényel. Akikkel eddig találkoztam, azoknál sem a sokrétűség, sem a tudás nem volt meg. Mindkettőt hihetetlen magabiztossággal pótolták.

Az intézet vett egy QPCR-t és elmentem meghallgatni, mire is jó ez. Az előadók nagyon felkészültek voltak, ezért kezdtem arra gondolni, hogy a rossz tapasztalataim alapján egy hibás kép alakult ki bennem az üzletkötőkről. Nem törvényszerű, hogy mindegyikük nyomulós tuskó legyen, aki behazudik mindent a potenciális megrendelőnek.

A készülék egyébként rendkívül fejlett, még kockás füzet opciós is van benne. Mi az a kockás füzet opció? Réges régen, mikor még egy laborban csak egy PCR jutott három kutatóra és négy PhD hallgatóra, akkor a készülék mellett a kockás füzet biztosította, hogy aki használni akarta, az előre tervezhessen, tudja, mikor lesz szabad a gép.

Manapság ezt a készülék tudja, és neten keresztül küldjük rá a programot. (Nincs az, mint régen, hogy 5 programot tudott tárolni a gép, és mindig a ranglétra alján lévő dolgozó programját törölték, ha helyre volt szükség. Arról nem is beszélve, hogy sok gép nem is tárolta a programot.)

Nyilván fel is merült a kérdés, hogy a géphez adott kezelő alkalmazás milyen platformon fut? A válasz:

- Az ajánlás Windows 7-et ír elő, de én kipróbáltam Windows XP-n is, ami nem támogatott platform, és ott is futott, úgyhogy biztos megy Mac-en és Linuxon is.

Mivel egy ideje nincs hordozható gépem, ezért utólag küldök partiriportot. A kapukat pénteken nyitották meg, de mivel a release elég rosszul állt, ezért a pénteki nap nekem kódolásból állt. Akkor varázsoltam Windows alá a Linuxos kódot. Utólag visszatekintve: nem kellett volna csinálni semmit. Hagyni kellett volna az egészet a fenébe.

Mivel kódoltam, két érdekes felfedezést tettem: Ha Windows alatt ezt csináljuk: glBindTexture(GL_TEXTURE2D, 0) és ezt átadjuk a shadernek, akkor feketeség lesz a textúra helyén. Linux alatt nem lesz textúra. A másik felfedezésem, hogy Windows alatt a geometry shaderben a PointSize nem állítja át a pont méretét.

Másnap, miután kevesebbet aludtam a kelleténél, de volt egy összedobott releasünk, elindultam Functionre. Útközben észrevettem Vickey-t, aki nem ismert engem, mert én elég marginális szereplője vagyok a hazai demoscenének, de megkérdezte tőlem, hogy ez a tömegközlekedési eszköz megy-e XY térre. Azt válaszoltam neki: igen, ezzel kell Functionra menni. Ezzel meg is teremtettem az alapot egy kis beszélgetésre.

A party lagymatagon indult, amin az sem segített, hogy álmos voltam. Az Amigások egy asztalnál ültek, és csak őket ismertem, ezért odacsapódtam hozzájuk. Kölcsönkértem egy gépet, hogy feltöltsem a release-t, majd néztem, mások mit játszanak a géppel. Pista valami freeglut-os vackot akart fordítani Dev-C-vel, de a beépített csomagkezelő ellenére nem sikerült. Megpróbáltam segíteni neki, de nekem sem sikerült. Hiába, na én Linuxhoz szoktam.

Egy arc már teljesen kiütötte magát, pedig csak délután két óra volt. Az előadások előtt úgy gondolta, hogy felmegy a színpadra és ráül az egyik hangszóróra. Miután szépen levezették (és jól körbefényképezték), lefeküdt a székekre és szerintem átaludta a teljes partyt.

Az első előadás az ingyenes játékokról szólt, illetve arról, hogyan lehet mégis pénzt keresni velük. Az előadás minőségén nagyot dobott, hogy nem egy öltönyös-nyakkendős manager osztotta az észt, hanem egy designer, aki szemmel láthatóan közelebb állt a hallgatósághoz. Érdekesség, hogy ő is biológus volt. Szerencsére a pénzkeresést nem a játékos függővé tételével akarják elérni, hanem a hiúkra és lustákra hajtanak. Nevezetesen, akik a játékban másképp akarnak kinézni, illetve, akik nem tudják kivárni, hogy szintet lépjen a karakterük.

A második előadás a JavaScript világába kalaúzolt, ahol a szemünk láttára nőtt ki egy egyszerű demo. Ez nyilván egy kódernek szép, de másnak talán dögunalom.

A fotók néhol rájátszottak egymásra. Voltak a pocsolya-tükörképet-fotózok képek és a ködben-fát-fotózok képek. Ennek ellenére lehetett látni egyedi megnyilvánulásokat is.

A rajzok remekek voltak, még úgy is, hogy nem értek hozzájuk. A kézi rajzok és a Photoshop szerkesztések egyaránt. Nem tervezem, hogy lecserélem a háttérképemet, de ha egyszer rávetemedek, biztos, hogy a mostani felhozatal is benne lesz válogatásban. Grass remekül összefoglalta a rajzokat itt.

A zenékre nem emlékszem. Bocsi minden indulótól, de tényleg semmi nem maradt meg belőlük. Később le is írom, mi oltotta ki emléküket.

Elérkeztünk a 256 byte intróhoz. Megvallo, féltettem ezt a kategóriát, hiszen a modert operációs rendszerek egyre nagyobb erőforrás igénye egyszerűen nem teszi lehetővé, hogy kicsi kódot készítsünk. Már jó ideje csak FreeDosból vagy DosBoxból futtatták őket, ami szerintem mutatja, hogy már csak egy maradvány kategóriának lehet tekinteni. És ekkor fedezték fel a scenerek a JavaScriptet (na jó, eddig is ismerték). A JavaScript segítségével modern eszközökön is lehetővé vált a 256b intró kódolás, akár platformoktól függetlenül is. Ez pedig hatalmas lendületet fog adni ennek a kategóriának. Mi sem bizonyítja ezt jobban, mint a 17 indulóból 3 JavaScript volt.

Másfelől ez a kategória, valljuk be, elég egysíkú volt. Az új platformnak köszönhetően viszont kellően változatos is tud lenni.

Az animációk most gyengébbek voltak, de minden évben nem lehet minden kimagasló. Az introknál meglepetés számomra, hogy Ágoston visszatért. Láthatóan nem erőltette meg magát, de ez is elég volt a győzelméhez. Üdv újra köztünk!

A compók szünetében volt alkalmam megnézni az embereket. A friss házasok, pocakos anyukák és ugráló kisgyerekek száma megemelkedett. Ha a trend folytatódik, jövőre nem árt gyerekmegőrzőt is biztosítani a szervezőknek.

Egy zenét kidobtak az indulók közül, mégis ez lett a kedvence a magyar indulóknak. Mulatós demozene ugyanis tudtommal még nem volt. A szöveg inkább a benfenteseknek vicces, ezért mi nagyon jót szórakoztunk rajta. Ez persze azzal járt, hogy a többi indulóra nem is emlékszem.

Ebből következik, hogy a demókra fordítható idő is csökkenni fog. Néhányan már el is kezdtünk megoldás után kutatni. Spenot a JavaScriptben látja a kiutat, különösen a platformfüggetlenség miatt. Elmondta, hogy a legtöbb ember már csak YouTube-on nézi a releaseket, ezért szerinte a néző szívesebben fog böngésző demókat nézni.

A másik megoldás, ami felé én kacsingatok, a Unity. Beszéltem is egy emberrel, aki Unityben írt játékot. Megkértem, mutassa meg nekem a rendszert és készítsünk valamit, hogy lássam az alkotás folyamatát. Mi más lehetett volna az első dolog, mint egy forgó kocka. Az engine engem a régi Visual Basic-re emlékeztet.

Annak idején Borland Pascallal készítettem Windows 3.1 alkalmazásokat, csak úgy, a magam szórakoztatására. Minél összetettebb lett az alkalmazás, annál könnyebb volt elveszni a call back függvények sűrűjében, és a felület tervezése sem volt egy leányálom. Amikor megismerkedtem a Visual Basicel, mindez megváltozott. A felületet megrajzoltam, a call backeket pedig egyszerűen hozzáfűztem a grafikus objektumokhoz.

Valami hasonló a Unity is. Egy szerkesztő programmal megtervezzük a színteret, beállítjuk annak tulajdonságait, az objektumokhoz pedig kódot rendelünk, ami bizonyos események hatására fut le. Mivel demó készítésre használnám, nem is kell olyan sok eseményt megjegyezni. A kocka nagyjából 5 perc alatt elkészült, egyetlen sor kód megírásával.

Akartam egy kicsit bonyolultabbat példát is látni, ezért kb. 10 perc alatt készítettünk egy kocka falat, amit egy golyóval leromboltunk. Ezt kód megírása nélkül tettük, a beépített fizikai motor segítségével. Impresszív volt. Lehet, hogy a jövőben teszünk egy próbát Unityvel.

Szóbakerült az is, mivel foglalkozom. Megszoktam, hogy többnyire nem is hallottak a tudományterületről, amivel foglalkozom, ezért meglepődtem, mikor azt hallottam, hogy mennyire dinamikusan fejlődik. Gyanakodni is kezdtem, hátha csak azért mondja ezt, mert ezzel akar bevágódni nálam, ezért ártatlanul visszakérdeztem: mégis miért fejlődik olyan dinamikusan?

- A személyre szabott gyógyászat miatt.

Hihetetlen, mikkel találkozom. Közben ment a SIDRip Alliance koncert, amit a túlzott hangerő miatt a termen kívül élveztem. Láttam Vickey átvedlett koncert-szerkóba és úgy táncolt. Majd ha lesznek fotók, mások is megnézhetik.

Kicsit megbomlott az időrend a leírásban, de a drámát akartam a végére hagyni. A demo compot. A demónk elég lassan indult, hála a sebtében portolt kódnak. Egyébként nem tudom, mitől lassú a betöltés, ezt majd egyszer kinyomozom. A hosszú betöltés egyébként a nézőket is megviselte, el is kezdődtek a bekiabálások. Más probléma nem volt, a demó szépen lefutott.

Volt még egy SIDRip Alliance demó is. Készült még egy Experience inivtáció is, valamint a Hardread Ouya-ra készített egy rövid bemutatót. Betasector egy Blender mester, ezért a Blender Game Enginnel készített egy demót. Van benne kocka is. Nagyjából ezután szabadult el a pokol. A sorrendre már nem emlékszem pontosan, de jött egy Brainstorm, egy Nazareth és egy Dead Roman demó. Közben a semmiből TLM, aki állítólag 20 éve scenerkedik 0 alkotással, most hirtelen úgy döntött, demót is készít. Meg kell hagyni, igen impozánsra sikeredett.

Ez a kívülállóknak nem sokat mondhat, ezért megpróbálom érzékeltetni, mi is történt. Képzeljük el, hogy elmegyünk valami családi futóversenyre. Tudjátok, amikor a 60 éves mami is rajthoz áll a kinőtt melegítőben, a kisgyerekek a rajtpisztoly dördülése után visszafelé kezdenek szaladni, stb. Most képzeld el, hogy rajthoz állsz egy ilyen versenyen, óvatosan jobbra nézel, és egy kenyai futó van ott, NASA által fejlesztett futócipőben. Balra nézel, ott van az olimpiai győztes. Elindultok, ezek ketten az élre törnek, majd hátulról előkerül a világcsúcs tartó, és elhúz mellettetek.

Mert ez történt. Ugyanis itt volt a Fairlight is. Mikor megláttam a kiírást, hogy ki következik, felkiáltottam:

- Mi jön még, ASD?

ASD nem jött. Mi utolsó előttiek lettünk, ami teljesen megérdemelt pozíció. Nem is érdemes több szót vesztegetni rá. De ha ezt tudom, biztosan nem heggesztek releaset péntek este. Az eredményhírdetésre felkelt a részeg kolléga, megkérdezte a szervezőket, hogy leadták-e a fotóját, de mire megláthatta volna, milyen helyezést ért el, ismét elaludt.