Az élet kódjai

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.

A demó változó sebességgel halad. Két hete még úgy láttam, hogy nem lesz különösebb akadálya annak, hogy befejezzem az alkotást, de valami közbeszólt. Úgy hívják valóság. Rengeteg olyasmit kellett csinálnom, aminek semmi köze számítógépekhez, ettől a demóra fordítható idő nagyon lecsökkent. Még továbbra is úgy gondolom, hogy el fogok készülni, de szűkös a határidő.

A másik probléma, hogy úgy tűnik nem Linuxon fog futni. Az egész úgy kezdődött, hogy biztosítottak egy gépet, amiben egy Ati Radeon HD4850 teljesít szolgálatot. A hivatalos papír szerint a kártya ismeri az OpenGL 3.2-t. Már jó ideje 4-es verzióval foglalkozom csak, ezért nagy morogva átírtam a shadereket és a kódot 3.2-re. Igazából a nagy munka a layout-ok kiszedése volt, amivel meghatároztam, melyik vertex buffer tartalmazza a poligonok csúcsait, melyek a normálokat, illetve a textúrát. Én ugyanis szeretek minél több irányítást átadni a shadereknek, hogy a kód egyszerűbb legyen.

Ráadásul 32 bites Debiánt akarnak használni, ezért az egyszerűség kedvéért én is telepítettem egyet és azon fordítottam. Küldtem is egy félig kész mintadarabot a szervezőknek, hogy lássák, megy-e a compó gépen. Természetesen nem ment. Újabb levélváltások után a program hibaüzeneteit is megkaptam: nincs renderbuffer, nincs geometry shader, nincs semmi, ami egy kicsit is emlékeztetne arra, hogy már 2.1-nél magasabb OpenGL verziószámmal van dolgunk. A lehetőségek: odaadom nekik az én videokártyámat, de akkor azt party végéig nem látom. Elviszem az egész gépet, vagy fordítok Windowsra. Nincs kedvem cipelni semmi feleslegeset, ezért fordítok Windowsra.

A másik meglepetés az volt, hogy Grass készített egy pár modellt, de a textúrák egyes helyeken rosszul álltak. Mivel OBJ formátumot használunk (szöveges állomány), egy grep segítségével azonnal láttam, hogy a gond az, hogy több textúra koordináta van, mint csúcspont. Az OBJ betöltőm viszont úgy működött, hogy betöltötte a csúcspontokat, ezeket tekintette alapnak, és a textúra koordináták számát úgy állította be, hogy megegyezzen a csúcspontok számával. Itt viszont pont ellentétes volt a helyzet. A csúcspontok számát kellett megnövelni. A kód kijavítása után minden szépen jelent meg.

Még egy fontos adalék: a demóban lesz fraktál is.

A munka halad, még rengeteg tennivaló van és a valóság minden mesterkedése ellenére be fogom fejezni. (Vagy nem)

Bármennyire is jó egy alternatív platform, a rá való fejlesztés gyakran könnyebb egy PC-n, amit az ember gyakran használ. Ha a PC teljesítménye esetleg sokszorosa a másik gépnek, akkor érdemes elgondolkodni a keresztplatformos fejlesztésen.

Az Efika nem egy teljesítmény bajnok, de nem is ezért szeretjük. A rajta futó MorphOS fejlesztőkörnyezete GCC-t tartalmaz, amit hibái ellenére azért is szeretünk, mert szabadon elérhető a forrása és így ideális eszköz egy keresztplatformos fejlesztéshez.

Sajnos a helyzet nem ilyen egyszerű, ezt mindenki megmondhatja, aki próbált már kézzel fordítani GCC-t, binutils-t és a többi hozzá tartozó eszközt. Szerencsére a MorphOS fejlesztőcsapat adott ki egy szkriptet, amivel ezek a lépések nagyban leegyszerűsíthetőek. Sajnos dokumentáció nincs hozzá, ezért leírom, mit kell tenni, hogy ez a szkript lefusson. A teszteket Debian Wheezy 32 bites verzióján végeztem.

Valószínű 64 bites Linuxon is meg lehet oldani a feladatot, de sokkal bonyolultabban, ezért én 32 bites rendszert javaslok. Lássuk a hozzávalókat:

1db szkript: http://bigfoot.morphos-team.net/files/setup-cross-sdk.sh

4db utility: flex, bison, texinfo, lhasa

1db fordító: gcc 4.6

1db könyvtár a PATHban: /gg/bin (a könyvtárat nem kell létrehozni, csak a bejegyzést)

1db könyvtár: /gg

1 db MorphOS SDK és annak forrása: http://morphos-team.net/files/sdk-20130129.lha és http://morphos-team.net/files/src/sdk/sdk-source-20130129.tar.xz

Hozzunk létre egy tetszőleges könyvtárat, másoljuk bele a setup-cross-sdk.sh szkriptet, az sdk-t és az sdk forrását. Készítsünk egy gg könyvtárat a gyökérben, a chmod-al legyünk mi a tulajdonosai. Ne felejtsünk el írási jogot adni a könyvtárra.

Adjunk futási jogokat a setup-cross-sdk.sh szkriptnek, és indítsuk el. Hagyjuk fordítani negyed órán keresztül és végül elkészül a friss, ropogós keresztplatformos fordító. Tálaljuk a saját kényelmünket megkönnyítő symlinkekkel.

Idén is összegyűltek a számítógépek szerelmese, hogy összemérjék erejüket különböző viadalokon. Volt robot párbaj, számítógépes játékok és természetesen demoparti is. Jelen poszt erről az utolsó mérkőzésről fog szólni.

Nekem a legnagyobb öröm, hogy látom visszatérni Maxont a HBC-ből, aki korábbi tevékenységéhez képest csak egy képpel jelentkezett, de nem kell elégedetlennek lenni. Most egy kép, később egy egész wild. Az erős mezőny miatt 13-ik lett. Nem csoda, hiszen igen komoly ellenfelekkel kellett megkűzdenie.

A zenék eddig nagyon tetszettek. A lejátszási listámban is túlnyomó többségében Assemblyről származó zenék vannak. Idén gyengébb volt a felhozatal, nem is fog bővülni a gyűjteményem. Számítottam valami kellemesre Aikapallotól, de csalódnom kellett. Maga a zene nem volt rossz, de hiányzott belőle a tűz.

A Tekotuotanto csapatról két dolgot kell tudni. Ez az egyetlen csapat, akinek csak másolni tudom a nevét, leírni nem. Kimondani pedig soha nem is próbáltam. A másik, hogy szinte csak wildot készítenek. Idén megpróbáltak egy 4k-t is, ami olyan jól sikerült, hogy elvitték vele az első helyet. Filmük ismét poénos volt, még ha nem is nevettem magam könnyesre. A robotos film is érdekes volt, talán lehetett volna ez az első.

Demók terén már nem láttuk azt a színvonalat, amit az előző években megtapasztalhattunk. Néhány demó annyira gyenge volt, hogy akár én is programozhattam volna. A nyertes Return nem volt rossz alkotás, de hiányzott belőle az összhang. A jelenetek valahogy nem alkottak egészet számomra. Fórumokon kifogásolták a nagy fájlméretet, mások az árnyékok hiányát. Szerintem ezeken az apróságokon túl lehet jutni, ha a bemutatott történet egészet alkot.

Természetesen agyatlan hardverekre tervezett demókból sem volt hiány. Az Androidra írt releasek szóra sem érdemesek, hiszen van rá SDK, fejlesztőkörnyezet, meg oktatási anyagok netszerte. Egy metró kijelzőn viszont még nem láttunk demót. Eddig.

Összességében az idei Assembly nem volt eget rengető. Volt néhány érdekes produkció, de nem tartom valószínűnek, hogy bármelyiket is megnézem másodszor.

Az alkotások megtekinthetőek itt és itt.

Mi, férfiak nem sírunk. Legfeljebb akkor engedhetünk meg magunknak könnyeket, ha a szellemchilis szendvicsünket véletlenül wasabival öblítjük le, de ilyenkor is inkább azt mondjuk, hogy homok ment a szemünkbe. Nők esetében ez teljesen másképp van.

Nemrég három síró nőt is vígasztalhattam egy nap. Az első a kislányom volt, ennek megfelelően ez ment a legkönnyebben. Felvettem, simiztem egy kicsit és már meg is nyugodott. A második a feleségem volt, aki azért sírt, mert a gyerek sírt. Ölelés, simizés. Megmutattam, hogy már nem sír a gyerek, nincs semmi problémája. Nem, én sem tudom, mi volt a baja, de most már jól van.

Bár szabadságon voltam, azért bementem a melóhelyre, nehogy újabb 10000x10000-es képeket hozzanak létre, vagy más módon omlasszák össze az infrastruktúrát. Észrevettem, hogy az asszisztens nagyon szótlan. Mikor végeztem az adminisztrációval, megkérdezte, tudnék-e neki segíteni. Azt válaszoltam: igen.

Megbízták egy egyszerű feladattal, az UEA Small RNA Workbench különböző táblázatos eredményeit kellett volna összefésülnie. A feladat annyiból nem volt triviális, hogy a két táblázat közös metszete a kisRNS-ek szekvenciái voltak.

Mondtam neki, hogy vannak patman futásból eredményeim, amiket felhasználhat. A patman produkálja a legprimitívebb illesztési eredményt, amit valaha láttam: kereső szekvencia azonosíója, találat, orientáció, illesztés kezdete, illesztés vége, eltérések száma. Mindezt tabulátorral elválasztva.

- Azokat nem tudom használni. Hogyan dolgozzam fel a fájlokat? - itt kezdtek folyni a könnyei.

- Írsz egy Perl szkriptet. A split paranccsal kinyered az oszlopokat...

- Én nem tudok Perl-ben programozni, csak Bash-ban.

- Semmi gond, awk-al kinyered az oszlopokat és grep-el megkeresed a másik táblázatban a hozzá tartozó értéket. Kicsit lassabb lesz, mintha Perl-ben csinálnád, de működni fog.

Ezután nagy sírás közepette elmondta, hogy úgysem lesz jó, mert őt mindig csak bántják, mert elront dolgokat. Ráadásul ideje sincs rá, mert még két másik dolgot kellene csinálnia.

Amennyire tőlem telt, elmondtam, hogy a hibák felderítése az akadémia világában nem személyes ügy, hanem a megismerést szolgálja. Mindannyian hibázunk, de ha mások rámutatnak erre, akkor igyekezzünk tanulni belőle, és ne személyeskedésnek vegyük.

Úgy tűnik, a mondandóm nem segített. Másnap írt a főnökének, hogy a feladatot nem tudja megcsinálni, és csinálja meg vagy ő, vagy valaki más.

Gondos tervezés, precíz időbeosztás, megfeszített munka. Ezek szükségesek, hogy időben elkészüljön egy demo a kitűzött partira. Amennyiben bármelyik is hiányzik, jön a tartalék terv. Esetleg a tartalék terv B változata. Az ütemtervet figyelve és Grassal beszélve úgy láttuk, hogy nem fog Function-re elkészülni a várva várt produkció. Üres kézzel mégsem mehetünk, ezért nekiláttunk ötletelni, mi az, amit meg is tudunk valósítani és nem is tűnik összecsapottnak.

Első lépésben kiválasztottam a zenét Shamen DVD-jéről. Már korábban összeírtam azokat a zenéket, amelyek elindítottak bennem valamilyen képzettársítást, most csak meg kellett keresnem, mert a címére nem emlékeztem. Egyhuzamban meghallgattam 4-5 ször, hogy teljesen átérezzem és kialakuljanak valami homályos képek arról, mit is akarok látni.

Az új produkcióhoz az Antagonism motorját fogom felhasználni, mert jelenleg ez a legfejlettebb kódom. Továbbra is hiányzik belőle egy csomó funkció, de mi nem is vagyunk főállású játékengine fejlesztők. A kódból kipucoltam az ottmaradt teszt kódokat, majd áttekinthető formára hoztam. A GTK és egyéb könyvtárak fejlődtek egy keveset az elmúlt időszakban, ezért eltűntettem a sok fordítás során keletkező figyelmeztetést. Beépítettem a zenét, és élveztem, hogy a fekete képernyő ellenére van "valami".

Cinema4D-vel modelleztem egy hangyát, amit Grass feltextúrázott. Ő további modelleket is készített. A demómotor OBJ formátumot használ, így ebbe exportáltam a modelleket. Itt jött az első hidegzuhany. A teljes jelenet egyetlen modellbe került, a modelleket összemosta. Sajnos ez nem jó nekem, mert az egyes modellekre különböző effekteket akarok pakolni.

A kísérleti állapotban lévő és a nagyratörő Cybernetic Export Plugin nevet viselő bővítményt elkezdtem kiegészíteni egy olyan funcióval, hogy minden modellt külön fájlba írjon ki. Ez részben sikerült is, de egy számomra ismeretlen erő hatására bináris szutykot ír minden string elejére. Ezt majd meg kell oldani.

Közben rájöttem valamire. A demoscene 30-on túl már elsősorban nem is arról szól, hogy csináljunk valami eget rengetőt. Inkább arról, hogyan tudjuk úgy szervezni az életünket, hogy jusson idő erre a hobbira. Talán ez sokkal nagyobb művészet, mint megírni a világ legjobb demomotorját.

Ajánlottak nekünk egy egyetemi hallgatót, akinek a "második nyelve a programozás", hogy a nyári gyakorlatát nálunk töltse. Segítene nekünk a mindennapi feladatok megoldásában. A beszélgetések során értelmes ember benyomását keltette, aki dolgozott többek között a Mol-nál is. Volt néhány megvalósítandó ötletem, ezért elvállaltam a felügyeletét és azt, hogy készítek neki egy munkatervet, de a mindennapi ügyek mellett ennek jó része elmaradt.

Még két hét volt vissza az érkezéséig, amikor szóltak nekem, hogy vegyem fel vele a kapcsolatot, mert ha mi nem csapunk le erre a zsenire, akkor máshova megy dolgozni és akkor mi egész életünkre sajnálhatjuk az elszalasztott lehetőséget. Ráaásul a bérezését is meg kell beszélni. Állj! Pénzt kap? Javasoltam, hogy ez esetben teszteljük le, mire is képes. Természetesen a napi robot mellett a tesztelés elmaradt. (Woops)

Levélben megkérdeztem tőle, hogy milyen programozási nyelven szeretne dolgozni, milyen statisztikákat és algoritmusokat ismer. Azt írta, hogy C-ben szeretne kódolni, statisztikát alig ismer és például a hashekről még nem is hallott. Ez már kicsit gyanús volt, de gondoltam, majd itt megtanulja, amit kell.

Mivel eddig Windows alatt ügyködött, kapott egy gyorstalpalót Linux fejlesztésből. Mikor láttam, hogy ez nehéz lesz neki, kapott Midnight Commandert, KDevelopot, hogy ne érezze annyira egyedül magát a "Déli Sarkon", a pingvinek között.

Az első meglepetés akkor ért, amikor nem tudta, micsodák azok az include részek a C program elején.

- De megkérdeztem tőled, miben akarsz programozni? Azt mondtad, hogy C-ben.

- Én azt úgy értettem, milyen programozási nyelvekről hallottam. Pascalban programoztam (Woops), meg PLC-ben.

- Mi az a PLC? Még nem hallottam róla.

- Folyamatábrákon keresztül lehet programot írni. Össze kell kötni négyzeteket és abból lesz a program.

- Mint a Lego Mindstore-ban?

Végül is gyorsan belerázódott, a végén már a pointereket is értette, de valami megmagyarázhatatlan okból kifolyólag csak és kizárólag hátul tesztelős ciklusokat írt. Azt gondoltam, talán nem ismeri a for ciklust, de nem erről volt szó. Tulajdonképpen a maga nyakatekert, függvények nélküli, beégetett sztingekkel operáló kódjaival minden rá bízott feladatot megoldott, csak rossz volt nézni (meg debuggolni, mert azt többnyire én csináltam).

Nyár lévén én is szabadságra akartam menni, és sokat gondolkodtam azon, milyen feladatot adjak neki, amit a jelenlétem nélkül is tud végezni. Vagy legalábbis meg tudja keresni a választ a felmerülő kérdésekre. Ekkor gondoltam először a Java-ra. Nincsenek furcsa pointerek, nem kell a memóriaszivárgás miatt aggódni, ráadásul a net tele van a legtipikusabb Java hibák megoldásával. Az Eclipse pedig olyan, mint egy pelenka. Bármi kerül bele, megbírkózik vele. És itt nem csak a kék tintára gondolok.

A másik ok, ami miatt a Java mellett döntöttem, hogy egy olyan alkalmazásra volt szükség, ami képet generál, lehetőleg keresztplatformos módon. Már volt Java kódom, ami png-t generált, ezért azt is odaadtam, amolyan súgónak.

Fél nap elteltével szólt, hogy nem jelenik meg semmi, pedig ő mindent leírt, amit a kódomban talált. A rutin ránézésre tényleg jól volt megírva.

- Meghívod ezt a metódust? - mutattam a az egész program lelkét képező rajzoló rutinra.

- Persze, itt van. - ott viszont egy másik osztály metódusa volt, ugyan ilyen névvel. Kiderült, mikor valami hibát talált az Eclipse, az első javítási opcióra klikkelt annak elolvasása nélkül, ami a hiányzó metódus elkészítése volt. Nemsokára üres metódusokkal volt tele minden osztálya. Miután kigyomláltam a szemetet, már futott a program, készített png fájlt. De mikor meg akartuk nézni a végeredményt, a gép váratlanul lelassult, nekiállt swappelni. A halálán volt.

- Mekkora ez a kép? - kérdeztem, miután az egérmutató ismét mozgott a képernyőn.

- 10000 x 10000. Az nagynak számít?

- Nem szoktál letölteni képeket a netről? A nyolc megapixeles képek 3264 x 2448 felbontásúak. A képernyő, amin dolgozol, 1024 x 768-as.

Rámnézett, mint akinek ezek a számok továbbra sem mondanak semmit és csak ennyit mondott:

- Woops.

Az egyik nagy előnye, hogy az ember akadémiai kutatócsoport tagja, hogy hozzáférhet a NIIF szuperszámítógépeihez. A papíron leírt impozáns teljesítmény mutatók azonnal megdobogtatják egy magamfajta felhasználó szívét. Sajnos az örömbe sok üröm is keveredik, ha a tényleges felhasználásra kerül sor.

Regisztráció

A regisztrációs procedúra sokat egyszerűsödött, de márciusban, mikor a saját kérvényemet intéztem, ez kétfordulós meccs volt. Először projektszámot kellett igényelnem. Kitöltöttem egy papírt, aláírattam minden főnökömmel, akik igazolták, hogy én tényleg létezem, és tényleg kutató vagyok. Ezután még egyszer kitöltöttem egy nagyon hasonló papírt, ahol témaszámot igényeltem. A procedura nagyon hasonló volt. Kellett generálni egy ssh kulcsot és már kész is voltam.

Programok

A szuperszámítógépek használata hasonlít egy batyus lakodalomra: Étel-ital lesz elég, ha hoztok magatokkal. Szoftver lesz elég, ha fordítasz magadnak. Ez nem olyan problémás, egészen addig, amíg nem a függőségek függőségeit kell fordítani. Utána kicsit unalmassá válik. Én a Mira-t akartam futtatni, ezert felmásoltam egy statikusan linkelt binárist és azt használtam. Illetve próbáltam használni.

Üzemidő

Memória gondjaim voltak, ezért akartam a pécsi szuperszámítógépen dolgozni, de csak a kínlódás volt vele, ugyanis lépten-nyomon elérhetetlen volt a gép és a futó programok pedig elszálltak. Visszanéztem az ezzel kapcsolatos e-mailjeimet és az alapján készítettem ezt a grafikont:

Egy hetet nem tudott folyamatosan menni a pécsi gép. Szerintem annak idején a Windows 95 jobban teljesített, nem? Áttértem a szegedire, ahol viszont nem jutottam sorra. (Illetve az egyik kiesés alkalmával csak a futó jobok szálltak el, a várakozási sor nem ürült, amitől az élre tudtam törni). A másik igencsak frusztráló dolog a jobütemező, ahol az idő folyamán egyre több korlátozást vezettek be. Egyik alkalommal nem voltam elég figyelmes és a job futásának hosszabb időt adtam meg, mint amennyi a felső határ volt. Nem kaptam hibaüzenetet, nem kaptam figyelmeztetést, semmit. Annyi tűnt fel, hogy van üres node, de én továbbra is a várakozási sorban dekkolok.

Mikor végre sorra kerültem, gyanúsan lassan futott a Mira. Rövid nyomozás után kiderítettem, hogy a félelmetes memória, CPU és sávszélesség mellett az IO műveletek röhejesen lassúak. (Emlékeztetőül: A bioinformatikai programok nagy fájlokat olvasnak és írnak). Álljon itt egy cseppet sem mélyreható, gyors tesz, mire is képesek a szuperszámítógépek:

A tesztet a jó öreg dd-vel csináltam:

dd if=/dev/urandom of=fajl # iras teszt
dd if=/dev/sda of=/dev/null # olvasas teszt


A teszt nem túl szofisztikált, de a célnak megfelel (meg nem ártott volna néhány ismétlés, de annyit nem ér az egész). A deb egy nagyteljesítményű számítógép, ami nem a NIIF tulajdonában van.

Végszó

Sajnos semmi hasznosat nem tudtam kezdeni a hazai szuperszámítógépekkel. Végül úgy végeztem el a munkát, hogy lecsökkentettem a readek számát, hogy beleférjen 70GB memóriába, majd lefuttattam egy erre alkalmas gépen.

Amigát régen nem csak játékra használták, hanem munkára is. Annak ellenére, hogy mára ez a gép főleg hobbi célokat szolgál, akadnak fanatikusok, akik munkájukhoz is valamilyen Amigát, vagy újgenerációs leszármazottjainak egyikét használják.

Ilyen például LaySoft, aki PHP programozóként dolgozik, de a kódot MorphOS-en gépeli be, vagy Lázi, aki OS4 alatt Hollywooddal állít elő multimédiás tartalmakat. Ha nem is napi szinten, de nemrég én is munkára fogtam az Efikát.

Beszámolót kellett tartanom és a nagy nyári szabadságolás miatt nem tudtam szerezni laptopot. (Az igazsághoz hozzátartozik, hogy ha nagyon akartam volna, tudtam volna szerezni, de abból nem születik blogposzt.) Végül úgy döntöttem, az Efikára átmásolom az anyagot (néhány R-ben készült két volt az egész), majd bemutatom.

Az adatátvitel gond nélkül ment, mert MorphOS alatt van OpenSSH kliens, és bár van grafikus program hozzá, közönséges parancssorból is megy. A rendszergazda, aki a projektorért is felel, hitetlenkedve nézte, amint a VGA kábelt egy kis, fekete dobozhoz kötöm.

- Mi ez? - kérdezte. Csak egyet felelhettem rá.

- Számítógép.

A csoportvezető belépett a gyéren megvilágított irodába. A bútoroknak pont olyan áporodott szaga volt, mint hallgató korában. El gondolkodott rajta, bizonyára az az anyag, ami ilyen szagot bocsát ki, egyben tartósítja Don Emeritust is. Ez teszi lehetővé, hogy míg lediplomázott, elvégezte a PhD-t, csoportvezető lett az intézetben, addig Don Emeritus ugyan úgy ül itt, túl a nyugdíj korhatáron és kíméletlenül ontja a cikkeket, dönt pályázatok és kutatócsoportok sorsáról.

- Beszélni szerettél volna velem! - kezdte Don Emeritus. Kevés ideje volt, nem vesztegette udvarias fecsegésre.

- Igen, Don Emeritus - kezdte a csoportvezető, olyan hangon, mintha kollokviumra készülne. Maga is észrevette ezt. Megköszörülte a torkát, és sokkal magabiztosabban folytatta. - Kihagytak a bíráló bizottságból, amelyik dönt az új szuperszámítógép beszerzéséről. Csupa matematikus és agrármérnök alkotja, akik nem tudják, mire van szüksége egy bioinformatikusnak.

- Agrármérnökök? Ismered őket? - Don Emeritus lenézte más tudományterületek képviselőit, de az agrármérnökök számára nem is voltak tudósok.

- Gáspár Tamás, Hornay Béla...

- Hallottam róluk. Gyalázatos, alacsony impaktfaktorú cikkeket közölnek genetika címen. Egyetlen modern metódust sem ismernek. Számukra a genetika kimerül a szatelliták elemzésében.

- Ahogy mondod! Ugyanígy le akarják zülleszteni a bioinformatikát is.

- Mit akarsz, mit tegyek?

- Nyomást kellene gyakorolni rájuk.

- Hmm, Gáspár Tamás közös pályázatban van az egyik volt tanítványommal, aki azóta volt kint Németországban. Béla intézetének meg Toldai Zsolt a vezetője. Ő szinte már családtag, a lányom sógorának az unokatestvére. De ha beszélek velük, tisztában kell lenniük minden részlettel. Tudsz valakit még rajtad kívül, aki ért annyira a témához, hogy a bizottság tagja lehetne?

- Senki más! - gondolta a csoportvezető, de idejében visszafogta magát. - Vannak még egy páran...

- Értem - jegyeztem meg sokat sejtetően Don Emeritus. - Kérlek írd össze pár szóban a javaslataidat. Tudod, sok hasonló szívességnek kell eleget tennem. Van egy külön mappám rá.

Elérkeztünk OpenCV-t bemutató sorozatunk utolsó részéhez. Itt csak példákat szeretnék mutatni, mire is lehet használni ezt a programozói felületet. Sajnálatos módon az OpenCV C és C++-os felületei között jelentős különbségek vannak, ami abban is  megnyilvánul, hogy ha C++-ban programozunk, több algoritmust használhatunk. Ebben a fejezetben ezért csak C++-os példaprogramok lesznek.

Kontúr keresés

Első példánkban igyekszünk meghatározni egy képen a kontúrokat. A kontúr kereséshez a Canny metódust használjuk. Bemenetnek egycsatornás, 8 bites képet kell adnunk. A példaprogramban nem csak a képet jelenítjük meg, hanem két GUI elemet is, amivel az algoritmus paramétereit állítgatjuk. Az élkeresés hatékonyságát Gauss elmosással növeljük.

#include <opencv2/opencv.hpp>

using namespace cv;

int main(int argc, char **argv){
  Mat raw, gray;
  VideoCapture capture(0);
  bool run = true;
  int tb1 = 129, tb2 = 233;

  namedWindow("Edge", 0);
  createTrackbar("Tb1", "Edge", &tb1, 1000,0);
  createTrackbar("Tb2", "Edge", &tb2, 1000,0);

  while(run){
     capture >> raw;
     cvtColor(raw, gray, CV_BGR2GRAY);
     GaussianBlur(gray, gray, Size(7,7), 15, 15);
     Canny(gray, gray, tb1, tb2, 5, true);
     imshow("Edge", gray);
     if(waitKey(30) >= 0) run = 0;
  }

  return(0);
}


A GUI készítésénél vegyük észre, hogy minden elemet stringekkel azonosítunk és ugyancsak stringek segítségével határozzuk meg, melyik ablakon jelenjen meg. Ebben a példában csak egy ablakot hozunk létre "Edge" néven.

Háttér eltávolítás

Míg az előző példát akár C-ben is megírhattuk volna, ez a példa már olyan elemeket használ, amit csak C++-ban érhetünk el. A program megpróbálja a nyers képen elkülöníteni a hátteret az előtértől. Az előteret ezután elmentjük egy maszkba, amit felhasználunk arra, hogy a nyers képből az előteret átmásoljuk egy másik háttér elé. Ez a másik háttér egy időjárás térkép lesz. (Figyeljünk rá, hogy a webkamera képe és az új háttér ugyanolyan méretű legyen, mert a programban nincs méret korrekció.)

A háttér elválasztása nem működik teljesen pontosan, ez a program nem fog olyan minőséget produkálni, mint amit a TV csatornáknál megszokhattunk. Javaslom, hogy miután elindítottuk a programot, várjunk 5-10 másodpercet, mielőtt a kamera elé sétálunk, ennyi kell ugyanis, hogy "megtanulja", mi a háttér. A backgroundRatio mező segítségével állíthatjuk be, mennyire legyen az algoritmus precíz és gyors. Az árnyékok ugyancsak zavarhatják az algoritmust. Elméletileg az árnyékokat is felismeri, gyakorlatban nálam nem működött rendesen. A példaprogram paramétereivel játszunk nyugodtan.

#include <opencv2/opencv.hpp>

using namespace cv;

int main(int argc, char **argv){
  Mat raw, mask, background;
  VideoCapture capture(0);
  bool run = true;
  BackgroundSubtractorMOG2 subtract;

  subtract.nmixtures = 3;
  subtract.backgroundRatio = 0.01;
  namedWindow("Forecast", 0);
  // the image should be the same size as the cam image
  background = imread("magyarorszag.jpeg", CV_LOAD_IMAGE_COLOR);

  while(run){
     capture >> raw;

     // Create mask
     subtract.operator ()(raw, mask);
     erode(mask, mask, Mat());
     dilate(mask, mask, Mat());
     threshold(mask, mask, 40, 255, THRESH_BINARY);
     // use mask to substract foreground
     Mat tmp = background.clone();
     raw.copyTo(tmp, mask);
     imshow("Forecast", tmp);

     if(waitKey(30) > 0) run = 0;
  }

  return(0);
}




A példaprogramhoz felhasznált hátteret ide töltöttem:Objektum követés

Legvégére hagytam azt a programot, ami elindította ezt a sorozatot: Aha kiváltását. A feladat tehát az, hogy több képkockán keresztül követni kell két elemet, jelen esetünkben két kezet. Azért, hogy megkönnyítsük a dolgunkat, feltűnő színekkel jelöljük a követendő objektumokat. Ezután kiszűrjük csak ezt a színt és egy k-közép klaszterezéssel megállapítjuk a ponthalmaz közepét. Ha minden feltétel megfelelő, a klaszterek közepe a követni kívánt objektumokkal meg fog egyezni.

Mi ez a k-közép klaszterezés? Ez, mint a neve is mutatja, az adathalmazok csoportosítására használható. Az adathalmazoknak számszerű tulajdonságokkal kell rendelkezniük, ami a mi esetünkben a koordináták lesznek. Hátránya, hogy előre meg kell mondanunk, hány csoportra akarjuk bontani az adatainkat. A mi esetünkben ez nem probléma, mert tudjuk, hogy jó esetben két keze van az embernek. Az algoritmus ezután véletlenszerűen valamelyik csoportba osztja az adatokat, majd a kiszámolja a csoport középpontját (veszi a koordináták átlagát, innen a neve), majd megnézi, hogy más csoportból van-e közelebbi pont. Ha van, ez a pont is része lesz a csoportnak, és kezdődik egy új ciklus. Ha minden jól megy, ciklusról ciklusra egyre közelebbi pontok lesznek egy csoportban. Ha viszont zajos az adatunk, vagy rosszul választjuk meg a klaszterek számát, furcsa eredményeket kaphatunk. (Ahogy a bemutató videón is látni lehet majd)

Az algoritmus része az OpenCV-nek, ezért nem kell leprogramoznunk. Lássuk a kódot:

#include <opencv2/opencv.hpp>

#define CLUSTERNUM 8

using namespace cv;

int main(int argc, char **argv){
  Mat raw;
  Mat labels, centers(CLUSTERNUM, 2, CV_32FC2);
  VideoCapture capture(argv[1]);
  bool run = true;
  int lb1 = 0, lb2 = 100, lb3 = 100;
  int hb1 = 64, hb2 = 255, hb3 = 255;

  // Create windows
  namedWindow("Param", 0);
  namedWindow("Aha", 0);
  namedWindow("Filt", 0);
  createTrackbar("lb1", "Param", &lb1, 255, 0);
  createTrackbar("lb2", "Param", &lb2, 255, 0);
  createTrackbar("lb3", "Param", &lb3, 255, 0);

  createTrackbar("hb1", "Param", &hb1, 255, 0);
  createTrackbar("hb2", "Param", &hb2, 255, 0);
  createTrackbar("hb3", "Param", &hb3, 255, 0);

  while(run){
     capture >> raw;
     Mat filtered(raw.size(),CV_8U);
     inRange(raw, Scalar(lb1, lb2, lb3), Scalar(hb1, hb2, hb3), filtered);
     Mat dummy(filtered.rows * filtered.cols,2,CV_32F);
     int z = 0;
     for(int x = 0; x < filtered.rows; x++){
        for(int y = 0; y < filtered.cols; y++){
           if(filtered.at<uchar>(y,x) == 255){
              dummy.at<float>(z,0) = x;
              dummy.at<float>(z,1) = y;
              z++;
           }
        }
     }

     Mat points = dummy(Rect(0,0,2,z)); /* Reduce the image */

     // If the picture do not contains enough points, we can not make kmeans clustering
     if(z > CLUSTERNUM){
        kmeans(points, CLUSTERNUM, labels, TermCriteria(CV_TERMCRIT_EPS + CV_TERMCRIT_ITER, 10, 1.0), 3, KMEANS_PP_CENTERS, centers);
        for(int i = 0; i < CLUSTERNUM; i++){
           Point ipt = centers.at<Point2f>(i);
           circle(raw, ipt, 20, Scalar(0,0,255), CV_FILLED, CV_AA);
        }
     }

     imshow("Aha", raw);
     imshow("Filt", filtered);
     if(waitKey(30) >= 0) run = 0;
  }

  return(0);
}


A videóról beolvassuk a képkockákat, majd az inRange segítségével kiszűrjük azt a színtartományt, amire szükségünk van. A tartományok beállításához (minden színcsatornához egy tartományt lehet beállítani) a createTrackbar segítségével grafikus elemeket hozunk létre.

A kmeans parancs egy speciális mátrixot vár bemenetnek, ezért a szűrt képünket (filtered) ezekkel az ocsmány egymásba ágyazott ciklusokkal kell átalakítani. Ha erre valaki tud egy szebb módszert, az ne fogja vissza magát. De hogyan is néz ki ez a speciálist mátrix? Mindenképp CV_32F típusúnak kell lennie, és minden egyes sorban az adathalmaz egy elemének kell szerepelnie. (Tehát annyi sorunk lesz, ahány adatunk) Mivel a mi esetünkben két tulajdonsága van az adatoknak (X és Y koordináta), ezért a mátrixnak két oszlopa van.

A kmeans eredménye a centers változóban lesz. Utolsó lépésként megjelenítjük ezeket piros pöttyökkel. A lefordított program működés közben:

Remélem sok szép demó fog születni OpenCV felhasználásával.

Szerettem a tanulmányi versenyeket. A legtöbb meghírdetett versenyre elmentem, bár soha nem jutottam túl az iskolai fordulón. Nemrég megkért az egyik prof, hogy segítsek egy gimis srácnak felkészülni az IBO országos fordulójára.

Én csak az OKTV-ről hallottam, az IBO-ról soha, ezért elkezdtem némi információt gyűjteni róla. El is jutottam a régi feladatlapokhoz, és kíváncsian belelapoztam. A harmadik feladat után rá kellett jönnöm, hogy diploma, doktori ide vagy oda, ezen a versenyen bizony elvéreznék.

A gyakorlati résznél (mert ilyen is van) már határozottan ideges lettem. A versenyzőknek adnak mikroszkópot, tűt, szikét és egyéb kínzóeszközöket, felboncoltatnak velük valami bogarakat, majd papíron rajzolják fel a dögök törzsfáját UPGMA módszerrel. Ez még nem tűnik annyira vészesnek, de nem ártana némi ismétlés. Utána ugyan ezt el kell játszani néhány növénnyel, de a változatosság kedvéért Neighbor-joining módszerrel rajzoljanak törzsfát. Menjetek a fenébe - gondoltam. Mikor a végén valami koevolúciót kellett nézni a dögök és a gazok között, akkor döntöttem úgy, hogy ebből elég.

A felkészítés során a statisztikáról kellett beszélnem, amihez felhasználtam néhány Coursera-s kurzuson hallott példát, mert ott néha nagyon jól megvilágítják az okokat, míg a hazai oktatásban csak rálöncsölik a hallgatókra a képleteket, fogalmakat. Mint kiderült, ez jó ötlet volt.

Gondoltam faggatom kicsit a versenyről. Mint kiderült, ez egy elitista verseny, aki nem jutott tovább az OKTV második fordulóján, azt meghívást sem kap. A srác elmondta, hogy az a stratégiája, hogy olyan gyorsan végigmenni a teszteken, amennyire csak lehet, és csak arra válaszolni, amit gerincvelőből is tud. A gondolkodást a végére hagyja. Ha marad ideje, akkor alszik egy kicsit, de fél, hogy nem jut rá ideje, mert nagyon sok feladatot kapnak.

Kérdeztem tőle, miért kell aludni? Azt mondta, hogy a teszt után (ami három órás), este nyolc órakor lesz a gyakorlati rész, újabb két, két és fél óra hosszan. Este? Miért? Azért, hogy az állóképességet is igénybe vegyék.

Összegezzük: Van egy kegyetlenül nehéz feladatsor, amire egy átlagos középiskolásnak esélye sincs felkészülni. Ennek a srácnak is a fél kutatóintézet segített a felkészülésben. Ezekből a feladatokból adnak sokat, de azért nem kapnak annyi időt, hogy minden beleférjen. Az időpontot pedig úgy állítják be, hogy lehetőleg baromi fáradtak legyenek. Kérdem én, ennek mi értelme?

Az Olimpián sem látunk olyat, hogy az úszókat lovagpáncélba öltöztetik, mert ők már annyira profik. Kíváncsi lennék mit szólnának a 100 méteres síkfutás döntősei, ha rekortán helyett mondjuk folyós homokban küzdhetnének az aranyért.

De az is lehet, hogy én gondolom rosszul és ez a verseny kicsit másmilyen, ehhez hozzátartozik a "megperzselt föld".