HTML

Az élet kódjai

Csináld maga. Senki nem csinálja meg helyetted.

Friss topikok

  • sdani: Oh... néha eszembe jut, hogy az EBI után esetleg vissza kellene menni valamennyire az akadémiai vo... (2025.03.18. 16:58) Pontos, jól behatárolt célok
  • legyen úgy: Szia, Értem és köszönöm a válaszodat! T. (2025.02.24. 18:23) Expose CTF
  • sdani: Sajnos nekem is hasonló érzéseim vannak az R kiszorulásával kapcsolatban. Remélem jobban fogja tar... (2024.04.29. 10:48) R meetup
  • sdani: Nagyon jók ezek a bejegyzések! Feszültséggel teli, fordulatos, mint egy jobb krimi. :D Abba ne hag... (2024.04.29. 10:35) Wgel CTF
  • sdani: @Travis.CG: Egy kis szerencse sosem árt. :D (2024.03.01. 13:19) A bioinformatika helyzete 2024-ben

Mentsük, ami menthető

2011.11.17. 13:52 Travis.CG

Az egyik szkriptemet elindítottam, majd egy másik munkamenetben véletlenül kitöröltem. Nem volt bonyolult program, de hosszú fájlnevek és elérési utak voltak beledrótozva, amit nem szívesen írtam volna újra.

Mivel még futott, egy munkatársam javasolta, hogy próbáljuk megmenteni. Ext3 fájlrendszert használtam. Az első szóba jöhető program az ext3undel. Az Amazonos Linux csomagjai között nem szerepelt. Ugyan így nem szerepelt az icat sem. Két lehetőség volt, vagy forrásból installálom, vagy másik lehetőséget keresek.

Az lsof parancs megadta az inode számot is, ezért olyan eszközt kerestünk, ami ez alapján fér hozzá a fájlhoz. A find -inum nem segített. Végül megtaláltuk a megoldást.

A /proc könyvtárban megkerestük a process azonosítóját (ezt is kiírja az lsof), beléptünk, majd az fd könyvtárba mentünk. Itt kiválasztottuk azt a fájlt, aminek a száma megegyezett az lsof FD mezőjében leírtakkal. Ez a mi fájlunk. Ezt utána nyugodtan másolhatjuk.

A módszer csak olyan állományok esetén működik, amelyekhez van olvasási jogosultságunk.

Szólj hozzá!

Címkék: rendszergazda

Mese a projektvezetőről, aki elvesztette humorérzékét

2011.11.16. 10:33 Travis.CG

Egyszer volt, hol nem volt, volt egyszer egy projektvezető, aki a Kerek Erdő közepén a törpék életét irányította. Egyik csoportmegbeszélés alkalmával a törpék elé tett egy javaslatot, hogy a munka hatékonyabb végzése érdekében készítsenek egy "protokol templétet" ami kitöltve fokozatosan nyomon következő a törpék munkamenete. Leírhatták volna, hogy milyen csákánnyal bányásznak, mennyire pakolják tele a csillét, hányszor fordulnak meg a csillével a nap folyamán. A nap végén azt is felírhatták volna, hogy mennyi aranyat bányásztak.

A törpék először csak kuncogva hallgatták ezt a töménytelen mennyiségű hülyeséget, de mikor meglátták, hogy a megbeszélés végére a projektvezető már el is készítette a dokumentumot KicsiBanya Word programjával, akkor hangosan hahotázni kezdtek.

- Nagyon szép dokumentumot készítettél - mondta a Bölcs Bagoly, aki szintén részt vett a csoportmegbeszélésen. - De egy ilyen dokumentum csak akkor lesz hasznos a törpéknek, ha már meglelték a lelőhelyet és feltérképezték azt. Most még nem tudják, milyen csillét fognak használni. Előbb ki kell próbálniuk valamennyit. Ha majd megindul a tömegtermelés, akkor nagyon hasznos lesz ez a dokumentum.

A projektvezető elszomorodott, hiszen háromféle betűtípust és színeket is használt, de az észérvek előtt meghajolt. Elmentette a dokumentumot. A megbeszélés hátralévő részében egy szót sem szólt.

Mikor végeztek, néhány törpe megsajnálta és megpróbálta megvigasztalni.

- Nem rajtad vagy az értelmetlen dokumentum mániád miatt nevettünk. De a helyzet olyan vicces volt.

- Én nem tudok nevetni - sóhajtott a projektvezető.

- Miért? - csodálkoztak a törpék.

- A sok projektvezetés hatására úgy érzem elvesztettem a humorérzékemet.

- Ne mond már! Bizonyára nagyon jó humorérzéked van.

-Nem, nincs. Tudjátok én adattárházakkal is foglalkozom egy másik erdőben. Az ottani kollégáim megkértek, hogy meséljek nekik egy viccet.

- Melyik viccet mesélted?

- Egyiket sem. Mutattam nekik egy adatbázis sémát.

Szólj hozzá!

Címkék: irodalom

Megszereztem

2011.11.15. 23:31 Travis.CG

Egy hosszú idő óta húzódó folyamat végére került pont a múlt héten. Végre sikeresen megvédtem doktori címemet. Hosszú vargabetűket írtam le, mire elértem idáig, de megérte. Röviden összefoglalom a főbb állomásokat.

A diákok legtöbbje az egyetemen olyan doktori iskolába megy, ahol már szakdolgozóként is megfordult. Én növényélettannal foglalkoztam és különböző programokat írtam ökológusoknak. Ezért teljesen logikátlan volt, hogy mégis a genetika tanszék doktori programjába kapcsolódtam be. Az ok, hogy ezt tettem nem volt más, mint egy előadás, ahol bioinformatikáról beszéltek. Ekkor éreztem, hogy nekem ezt kell csinálnom. Nem volt genetikai laboratóriumi munkában semmi gyakorlatom. Talán ez is volt az oka, hogy nem haladtam olyan ütemben a vizsgálatokkal, ahogy egy igazi PhD hallgatónak haladnia kellett volna. Cserében viszont műveltem magam. A számítástechnika szakos hallgatók óráira is bejártam, hogy képezzem magam és minél jobb bioinformatikus legyek.

A három év ösztöndíj eltelt, publikációm nem volt, és lehetőségem sem, hogy folytassam a tanszéken a munkát. Gondoltam egy merészet és jelentkeztem egy bioinformatikai kutatócsoportba. Szerencsére felvettek, ezért a PhD-t gyakorlatilag újrakezdtem egy teljesen más témával.

Szerencsére itt jobban haladtam, mint a laboratóriumban. Született egy társszerzős cikkem és úgy tűnt talán lesz egy első szerzős is. Ekkor átszervezték a kutatócsoportot. Először az alacsony rangú munkatársak szerződését nem hosszabbították meg, később már a magas rangúak sem voltak biztonságban.

A munkának nem értem a végére, első szerzős cikkem nem volt. Egy nagy semmi voltam. Néhány ügyetlen próbálkozásom volt, hogy bioinformatikai jellegű területen maradjak, végül sokkal egyszerűbbnek bizonyult elmenni programozónak, annak ellenére is, hogy nem volt szakirányú végzettségem. Esténként és hétvégenként visszajártam a kutatóintézetbe, hogy befejezzem a munkákat, amelyek a publikációhoz szükségesek.

Ez az időszak elég megterhelő volt. A programozói munka után nekilátni egy teljesen más területnek, mindezt fáradtan, sok energiát kívánt. Gyakran öt percig csak néztem a képernyőt és próbáltam kitalálni, hogy miért van szükség arra a lépésre, amit a jegyzőkönyvemben felírtam egy évvel azelőtt. Keservesen lassan haladtam. Néhány hónap után abba is hagytam. Ameddig eljutottam, addig eljutottam.

Közben megjelent egy újabb publikációm is. Egy újabb követelménynek tettem eleget. Gondoltam itt az ideje, hogy elkezdjem írni a doktori disszertációt. A legnagyobb kihívást az okozta, hogy úgy mutassam be a munkámat, mintha az egy kerek egész lenne annak ellenére, hogy ilyen szerencsétlen körülmények között készült. A témavezetőm is máson dolgozott eközben, neki is csak plusz terhet jelentettem.

Programozó karrierem sem tartott olyan sokáig. Két év után a cég leépítette a teljes fejlesztői gárdáját és egy fejlesztőcégnek adták a munkát. Megint ott álltam, ahol a part szakad. Szerencsére ismerőseim felhívták a figyelmemet egy frissen induló bioinformatikai cégre. Jelentkeztem és felvettek. Kicsit olyan volt, mint egy visszatérés.

Végül született egy igen gyenge disszertáció, ami elsőre át sem ment a házi védésen. Ugyanis azt gondoltam, hogy a házi védés csak egy informális, baráti beszélgetés. Nem, nem az. Mikor elmondták, hogy pontozzák az előadásomat, akkor tudtam, hogy végem. Szerencsére megúsztam annyival, hogy meg kellett ismételni az előadást. Ez már jobban sikerült, de a dolgozat is erős átírásra szorult. A tömegközlekedésen és otthon is ezt írtam. Azok, akik vállalták, hogy átnézik a dolgozatot megismerhették diktatórikus oldalamat. Az idő fogyott és noszogatni voltam kénytelen az embereket, hogy időben átnézzék a szöveget.

A dolgozat elkészült. Az opponensek átnézték és úgy találták, ez már megüti egy doktori disszertáció színvonalát. Készülhettem a védésre.

Az időpont egyeztetés a bizottság tagjaival nem volt vészes. Mindenki azzal riogatott, hogy milyen nehéz, de sikerült ebben a hónapban olyan időpontot találni, ami mindenkinek megfelelt. Az előadás elkészítése nem volt bonyolult, mert a jól sikerült házi védést vettem alapul. Igyekeztem kiegészíteni, hogy ne csak azok értsék meg, akik a szűk tudományterület bennfentesei. Ezért egyes helyeken kényszerű egyszerűsítéseket vezettem be.

A védéshez kapcsolódó reprezentatív események megszervezése volt egyedül gond. Rendeltem szendvicseket, vettem kávét, üdítőt, műanyag tányérokat és evőeszközöket. Mindezt bevittem az egyetemre. Egyeztettem az előadás és a fogadás helyét, idejét. Este még egyszer átnéztem az előadást, majd aludni tértem.

Másnap jöttek a problémát. Először is a terem kulcsa máshol volt, mint ahogy mondták. Ezt még elég könnyen lehetett orvosolni. Az étel időben megérkezett, de a kávéfőző elromlott, másikat kellett szerezni. Nekiláttam utoljára elpróbálni az előadást. Ekkor vettem észre, hogy egy nyers opponensi válasz van a gépemen, nem a legfrissebb. Elrohantam az egyetem számítógéptermébe, hogy a levelezésemből kimentsem a legfrissebb verziót. Még szerencse, hogy a hallgatóként használt internetes azonosítóm működött. A projektoron nem látszott az egyik ábrám, mert kicsi volt a kontraszt. Erről el is feledkeztem! Igazából csak egy diát érintett, ezért úgy döntöttem, hagyom, ahogy van. Miután kipakoltunk minden ételt, közölték velünk, hogy a fogadás mégsem ott lesz. Már csak negyed óra volt az előadás kezdéséig, ezért aki élt és mozgott, kaját pakolt, köztük én is. Végül a segítőket kénytelen voltam magukra hagyni, mert előadást kellett tartanom.

Megtartottam az előadást, válaszoltam a feltett kérdésekre. Legnagyobb hibámnak azt tartották, hogy sok biológiai fogalmat rosszul használtam. Ez kellemetlen volt. Ezt leszámítva senkinek nem volt más problémája. A vendégek száma kevesebb volt, mint amire számítottunk, ezért töménytelen mennyiségű szendvics maradt. Két napig azt ette a család és még így is tudtam adni hajléktalanoknak.

Végiggondolva, ez volt eddigi életem legnagyobb kihívása. Az érettségi és az államvizsga is bizonyos szempontból nehéz volt, de szükségszerű következménye volt az adott oktatási intézményben eltöltött időnek. A tanuláson kívül nem kellett semmilyen energiát befektetni. Kis túlzással azt is mondhatnám, hogy determinálva volt, hogy megszerezzem a végzettséget. Azért túlzás, mert volt lemorzsolódás. Itt viszont a hétköznapokat kellett legyőzni.

Köszönöm mindenkinek, aki segített a harcban.

Szólj hozzá!

Címkék: életmód

Régi jó dolgok

2011.11.06. 22:52 Travis.CG

Az idősebb emberek gyakran lenézik a fiatalokat, mert más ismeretekkel rendelkeznek. Az ő szempontjukból ez csak a tudás hiányával magyarázható. Vannak esetek, amikor kiderül, nincs miért lenézni a fiatalokat.

Vonaton utaztunk Nagykanizsára egy barátommal. Mellettünk egy idős úr valamelyik országos terjesztésű napilapot olvasta. Amikor végzett az újsággal, beszélgetni támadt kedve, ami nem szokatlan ilyen helyzetben.

Nem voltam túl közlékeny vele, ezért inkább a barátomnak intézte szavait. Megkérdezte, ismerjük-e azt a fiatalembert, akiről az újságban olvasott. Mivel egyikünk sem olvasta a szóban forgó újságot, ezért nem tudtuk, hogy kire is gondol. Nekem mégis a feltételezés volt furcsa.

- Miből gondolja, hogy ismerjük? - kérdeztem.

- Mert nagykanizsai.

Meglepett a válasz. Azért, mert egy olyan vonaton ülünk, ami Nagykanizsára megy, azt következtette ki utitársunk, hogy ismerjük.

- Nem ismerünk mindenkit a városban - jegyeztem meg, hogy rávilágítsak, mennyire abszurdnak tartom a gondolatmenetét.

- De magukkal egy korú lehet - védekezett az úr.

Mintha minden korosztály egy városban ismerné a másikat. Gyakorlatilag ő csodálkozott azon, hogy miért feltételezem, hogy nem ismerem. Ki is nyitotta az újságot. Egy egy oldalas cikk foglalkozott a fiatalemberrel. Volt is egy kép róla és a családjáról. Természetesen én nem ismertem.

- Az osztálytársam volt! - mondta barátom, aki viszont ismerte.

- Látja? - felelte győzelemtől ittasan az úr.

Barátom a cikk segítségével sok mindent megtudott osztálytársáról, amikor a hideg idő ellenére egy katicabogár szállt a vonat ablakára. Mivel kívül volt, nem látszottak a pettyei, de a jellegzetes alakja nem hagyott kétséget a rendszertani besorolása felől.

Az úr meglátta.

- Egy kullancs! Még szerencse, hogy kint van.

Barátommal megpróbáltuk megmagyarázni, hogy egy katicabogárról van szó.

- Kicsi a feje és nagy a potroha, ez egy kullancs - hajtogatta az úr.

Felhívtam a figyelmét, hogy a kullancsnak nyolc lába van, ennek meg csak hat. Ráadásul egy kullacs csak akkor lehet ilyen nagy, ha már teleszívta vérrel magát, de akkor nem tud felmászni a vonat ablakára.

- Teleszívta magát a tehénen, ami ott legelt a mezőn - hangzott az ellenvélemény. - Maga biológus?

Történetesen olyasmi vagyok, de ha meg tudok különböztetni egy kullancsot egy katicabogártól, akkor csak is biológus lehetek?

Szólj hozzá!

Címkék: filozofálás

Mélységi puffer

2011.10.21. 10:48 Travis.CG

Screen-space ambient occlusion, deferred rendering, shadow mapping. Mi a közös ezekben a fogalmakban? Mindegyik alapja a mélységi pufferben (depth buffer, z-buffer) tárolt információ.

Ha nem akarjuk, hogy a pouet.net-en olyan kritikát kapjunk, mint: "Ez '94-es színvonal", "2000 előtt láttam ilyen demókat", (márpedig én nem akarok :-) többet). Akkor mindenképp meg kell ismerkedni ezekkel a technikákkal. A most következő leírás OpenGL 4.1 alatt fog működni.

Áttekintés

A módszer lényege, hogy először a geometriát (3D objektumokat) rajzoljuk ki egy shaderrel (nevezzük depth shadernek), az eredményt lementjük egy vagy több textúrába. A második fázisban egy, az egész képernyőt betöltő négyzetre kirajzoljuk a textúrát.

A bevezetőben említett technikák csak abban térnek el, hogy miként használjuk pufferünket. Ha egy fényforrás felől állapítjuk meg a távolságot, akkor árnyékokat hozunk létre, ha az egymás közelében elhelyezkedő mélységeket hasonlítjuk össze, akkor SSAO-t alkalmazunk.

Inicializálás

Hozzunk létre egy framebuffert, és csatoljunk hozzá két textúrát. Más források arról írnak, hogy kell egy renderbuffer is, ami szintén tartalmazza a mélységi adatokat, de ez nem igaz. Az viszont igaz, hogy engedélyezni kell a mélységi vizsgálatot.

glEnable(GL_DEPTH_TEST);
glGenFramebuffers(1, &fb);
glBindFramebuffer(GL_FRAMEBUFFER, fb);
glGenTextures(2, textures);

/* Depth information */
glBindTexture(GL_TEXTURE_2D, textures[0]);
glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT, width, height, 0, GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE, NULL);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
/* Add more texture parameters if You would like */
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_TEXTURE_2D, textures[0]);

/* Color information */
glBindTexture(GL_TEXTURE_2D, textures[1]);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
/* Add more texture parameters if You would like */
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, texture[1], 0);

if(glCheckFramebufferStatus(GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE){
  printf("Error\n");
}

glBindFramebuffer(0);
Már az elején létre kell hozni a "négyzetet" ami megkapja a textúrákat. A koordináták szokás szerint egy vertex arrayben lesznek.

void createSquare(){
   GLfloat v[] = {-1.0, -1.0, 1.0, -1.0, 1.0, 1.0, -1.0, 1.0};

   glGenVertexArrays(1, &square);
   glBindVertexArray(square);
   glGenBuffers(1, &squarevbo);
   glBindBuffer(GL_ARRAY_BUFFER, squarevbo);
   glBufferData(GL_ARRAY_BUFFER, 8 * sizeof(GLfloat), v, GL_STATIC_DRAW);

   glBindVertexArray(0);
}
Szükségünk lesz még két shaderre. Az egyik a textúrákat fogja feltölteni. Mivel nem fog tartalmazni semmi különleges műveletet, ezért csak base_shaderkét hivatkozom rá. A másik a textúrákat fogja kirajzolni a képernyő méretű négyzetre. Ez a shader fog a mélységi pufferrel dolgozni, ezért ennek a depth_shader nevet adtam.

#version 410

/* base_shader vertex part */

in vec3 vertex;
in vec3 normal;

uniform mat4 pmatrix;
uniform mat4 mmatrix;

out float factor;
out float depth;

void main(void){
   vec4 pos = pmatrix * mmatrix * vec4(vertex, 1.0);
   gl_Position = pos;
   factor = max(0.0, dot(normal, vec3(0.0, 2.0, -15.0)));
   depth = pos.z / 15.0;
}
A base_shader rajzolja ki a modelleket, ezért itt alkalmazni kell a mátrix műveleteket, hogy a modelleket eltoljuk, forgassuk. A mélységi adatokat a vertex Z koordinátájából vesszük, miután alkalmaztuk rá az összes mátrix műveletet. A mélységi puffer 0.0-1.0 közötti értékeket vehet fel. Most az egyszerűség kedvéért vegyünk egy olyan jelenetet, ami 0 - 15 közötti koordináták között mozog. A csúcspont Z koordinátáját ezért 15-el elosztjuk. Megjegyzem, ez egy nagyon egyszerű, lineáris mélységi számítás. Realisztikusabb eredményt kapunk, ha a messzebb elhelyezkedő tárgyaknál kisebb felbontást használunk, mint a közelebb elhelyezkedőeknél.

#version 410

/* base_shader fragment part */

in float factor;
in float depth;
out vec4 gl_FragColor;

void main(void){
   gl_FragColor = vec4(1.0) * factor;
   gl_FragDepth = depth;
}
A gl_FragDepth a mélységi pufferünk, míg a gl_FragColor a színeket tartalmazza. A factor változó egy kis változatosságot csempész a színek egyhangúságába.

#version 410

/* depth_shader vertex part */

in vec2 vertex;
out vec2 texcoord;

void main(void){
   gl_Position = vec4(vertex, 0.0, 1.0);
   texcoord = (vertex + 1.0) / 2.0;
}
A négyzetünket nem forgatjuk sehova, csak kirajzoljuk. A textúra koordinátákat a shader számolja ki a csúcspontokat felhasználva.

#version 410

/* depth_shader fragment part */

out vec4 gl_FragColor;
in vec2 texcoord;

uniform sampler2D renderedtex;

void main(void){
   gl_FragColor = vec4(texture(renderedtex, texcoord).r);
}
Most csak egy textúrát kezel a shader. Később, ha majd több pufferünk is lesz, majd kiegészítjük ezt a kódot.

 Rajzolás

A rajzolás két menetben történik. Először a modelleket rajzoljuk ki, letároljuk a textúrákba, majd a második menetben a textúrákat a négyzetre rajzoljuk.

   glBindFramebuffer(GL_FRAMEBUFFER, fb);
   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

   glUseProgram(base_shader);
   uni = glGetUniformLocation(base_shader, "pmatrix");
   glUniformMatrix4fv(uni, 1, GL_FALSE, pmatrix);

   uni = glGetUniformLocation(base_shader, "mmatrix");
   glUniformMatrix4fv(uni, 1, GL_FALSE, locM);

   /* Draw the mesh */
   drawMesh3D(tree);
A kódból hiányoznak a mátrix műveletek, csak a kirajzolás váza van itt. A mátrixokról írtam egy korábbi cikkben.

   glUseProgram(depth_shader);
   glBindFramebuffer(GL_FRAMEBUFFER, 0);
   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
   glActiveTexture(GL_TEXTURE0);
   /* Color attachment use as texture for a quad */
   glBindTexture(GL_TEXTURE_2D, textures[0]);
   uni = glGetUniformLocation(depth_shader, "renderedtex");
   glUniform1i(uni, 0);

   /* Draw a quad */
   glBindVertexArray(square);
   glBindBuffer(GL_ARRAY_BUFFER, squarevbo);
   glDrawArrays(GL_TRIANGLE_FAN, 0, 4);
Most lebuktam! Nem is négyzetet rajzoltunk ki, hanem két háromszóget! A mélységi puffer használatra készen áll. Ne felejtsük el felszabadítani az erőforrásokat kilépésnél!

Szólj hozzá!

Címkék: programozás demoscene opengl

Nagy fájlok mozgatása

2011.10.19. 14:18 Travis.CG

Amikor készülünk egy release-t kiadni, gyakran kell nagy fájlokat cserélgetni a csapat tagjai között. A félig kész produkciót videóba szoktam elmenteni és úgy küldöm el a grafikusnak, hogy ő is megnézze, hol tartok. A modellek, textúrák is ritkán férnek el egy levél csatolmányként.

Szerencsére van óriáslevél küldés egyes levelező szolgáltatóknál, van webes nagy fájl küldési lehetőség és ingyenes tárhelyek. Mindegyiknél van bizonyos korlátozás, amit természetesen pénzért fel lehet oldani.

Eddig jól megvoltunk egy 500MB-os korláttal ellátott webes fájlküldő szolgáltatással. Egészen addig, míg az ingyenes, regisztrációtól mentes szolgáltatás korlátozását le nem csökkentették 250MB-ra. Szóba jöhetett volna, hogy másik szolgáltatót keresünk, de bennem van egy félsz, hogy az ingyenességnek ára van, amit spamban mérnek. (Meg felugró reklám ablakokban, amit szintén utálok)

Tehát továbbra is ott a kérdés, hogyan küldjünk egymásnak nagy fájlokat ingyen, miközben e-mail címünket sem terjesztjük net-szerte.

A megoldás az, ha közvetlenül össze tudnánk kötni a gépeinket. Ez sok szolgáltatónál gond lehet, ahol a szerződés kimondja, hogy nem lehet szervert üzemeltetni. Én nem is bátorítok senkit erre. De kb. 10 percre meg lehet nyitni egy SSH portot, hogy kicseréljük egymás között az adatokat.

Először is kell egy számítógép, amin elindítjuk az SSH démont. Létre kell hozni egy új felhasználót, annak jelszót vagy kulcsot adni, amivel eléri a gépünket. A tűzfalon nyitni kell egy portot, amin fogadjuk a kapcsolatot. Ha bátrak vagyunk, ez lehet a 22-es port, ami az alapértelmezett SSH port, de választhatunk magasabbat is.

Az ismerősünknek elküldjük az ip címünket, a felhasználói nevet és jelszót. Ő belép, feltölt, letölt, majd kilép. A módszer hátránya, hogy ugyan abban a pillanatban mindkettőnknek ott kell ülni a gép előtt, vagy legalábbis bekapcsolva kell lennie a gépnek.

Mivel nekem több gépem is a netre van kötve, van egy routerem, ami kicsit több munkát ígér, de cserébe nagyobb kényelmet is biztosít.

Először is van benne egy olyan lehetőség, hogy a mindenkori dinamikus ip címet fel tudja tölteni a dyndns-re. Ezzel elérhetjük, hogy a mindenkori ip cím helyett egy könnyen megjegyezhető url-t adhatunk meg, ami nem fog változni. Ingyenes regisztrációval egy ip címhez rendelhetünk nevet, ami magánfelhasználónak bőségesen elegendő. A router adminisztrációs felületén meg kell adni a regisztrált nevet, a felhasználói nevet, valamint a jelszót.

A routernek ezután be kell állítani, hogy a bejövő kapcsolatot melyik géphez, annak melyik portjára irányítsa (port forwarding). Ezért a gépeim mind statikus IP-vel vannak ellátva.

Így ha fájlokat kell cserélni, csak megbeszélünk egy időpontot. A gép bekapcsolása után a router fellövi az ip-t a dyndns-re. Az ismerősünk becsatlakozik és míg a fájlok róják hosszú útjukat, addig egy csevegőprogrammal megbeszélhetjük a részleteket. Nincs spam, nincs felugró reklám. A sebesség a szolgáltatóktól függ.

A másolás végén én lezárom a portot, ezzel is csökkentve a támadható felületet és kikapcsolom a gépet.

Szólj hozzá!

Címkék: biztonság rendszergazda

Villanybojler szerelés

2011.10.09. 21:44 Travis.CG

Vannak alkalmak, amikor minden összejön. A sürgős munka, ami miatt hétvégén is dolgozni kell, az igéret, hogy weboldalt fejlesztek és a bojler elromlása. A teendők gyors prioritizálása után a bojler javítása mellett döntöttem.

A jelenség az volt, hogy a bojler alján folyt ki a víz. Az áramot gyorsan lekapcsoltam, majd elkezdtem leereszteni a vizet a kis szelepen keresztül. Naívan azt gondoltam, ha már úgyis le kell ereszteni a vizet, akkor a kifolyó vízben mindjárt megfürdök, nehogy kárba vesszen az a sok meleg víz. A leeresztés hatására nagyjából 20 liter folyt ki, ami még ahhoz is kevés volt, hogy a lábamat rendesen megmossam. De hol van a többi 100 liter?

Mivel még soha nem szereltem bojlert, elérkezettnek láttam az időt, hogy ebbe is belekóstoljak. A netes forrásokat gyorsan átnézve azt láttam, hogy valószínűleg túl sok a vízkő, ami felforrósodva tönkretette a tömítést a bojler alján. Mivel már két éve nem tisztítottam ki, ennek igen nagy volt az esélye. A javítása nem foghat ki rajtam, gondoltam szombat este.

Az elektronika eltávolítása előtt fényképeket készítettem a még összeszerelt állapotról, hogy lássam a fekete drótok merre mennek. Ez a későbbi összeszerelésnél nagyon hasznosnak bizonyult.

A szétcsavarozás könnyen ment. A fenéklemez eltávolításánál viszont hiába lazítottam a csavarokat, a lemez úgy tapadt, hogy ellenállt a vízkő súlyának, és még kb. 100 liter víznyomásnak. Visszacsavartam a csavarokat, majd szépen óvatosan elkezdtem lefeszegetni a fenéklemezt. A víz végre elkezdett távozni a rendszerből, a folyás mértékét pedig szabályozhattam a csavarokkal.

Mivel elég lassan eresztett a bojler, ezért addig elmentem befejezni a munkahelyi munkákat és csak néha néztem rá, hogy a víz távozása megfelelő-e. Egy óra múlva le is vehettem a fenéklemezt. Ezt láttam:

A kép címe a régi vicc is lehetne: "Kapard fiam, ott lesz valahol a póló is!".

Az anód eltörött, annyira el volt vékonyodva. A helyzet nem volt jobb a tartály belsejében sem. Összesen ennyi vízkövet kapartam ki belőle:

Mivel nem volt tartalék alkatrészem, ezért abba is hagytam itt a szerelést. Vasárnap reggel korán felkeltem és elindultam egy másik városba, ahol biztos voltam, hogy egy nagy áruház nyitva van. Abban már kevésbé voltam biztos, hogy alkatrészeket is fogok kapni. A félelmem alaptalan volt. Vettem egy új fenéklemezt, fűtőszálat, tömítést és anódot. A kincsekkel hazatérve nekiláttam az összeszerelésnek.

A fenéklemez visszahelyezése volt a legmacerásabb. A csavarok ugyanis egy kis fülön lógnak. Mikor hozzájuk ért a fenéklemez, néha leugrottak a fülről és nagyot csattanva a kádban landoltak. Ha a csavarokat először a fenéklemezbe raktam, akkor meg nem tudtam a fülekre rakni őket. Végül nagy ügyességgel mégis valahogy felhelyeztem és átlósan elkezdtem megszorítani az anyákat, hogy egyenletesen legyenek terhelve. Mikor minden a helyén volt, egy kicsit megnyitottam, hogy megnézzem, mindenhol jó-e a szigetelés.

Nem volt. A fűtőszálnál folyt a víz. Számba vettem, mit raktam be és mit nem. Lehet, hogy oda is kell valami tömítés? A neten rákeresve kiderült, igen, oda is kell tömítés. Akkor ismét felkerekedtem, hogy másodszor is elmenjek egy másik városba alkatrészért. A vonaton már törzsutas leszek. A nagy áruháznál viszont pont a fűtőszál tömítésből készlethiány volt. Abban reménykedtem, hogy vasárnap este már lesz melegvíz, de csalódnom kellett. Az este hátralevő részében befejeztem a melóhelyi feladatokat és a weboldallal is játszottam kicsit.

Másnap reggel elmentem egy kb. 200 méterre lévő szerelvény üzletbe és megvettem a tömítést. Az ára harmad annyi volt, mintha egy nagy barkácsáruházban vettem volna. Nem akartam felhúzni magam, ezért nem kérdeztem meg, hogy a többi alkatrész mennyibe került volna. Otthon összeszereltem mindent. Megpróbáltam visszahelyezni a fenéklemezt, de a fűtőszál nem fért be a bojlerbe. Sikerült fordítva összeraknom! Ismét szétbontottam, majd összeszereltem. Megfogadtam, hogy szerzek egy villáskulcs készletet, mert a Multitoolból kialakítható fogó jó, de nehezebb jól megszorítani az anyákat vele. Összeszereltem. Tartottam egy nyomáspróbát. A víz sehol nem szökött, aminek nagyon örültem.

A korábban készített fotók alapján visszakötöttem az elektronikát, majd lélegzet visszafojtva vártam, hogy életre kelljen. Mikor a piros lámpa világítani kezdett, akkor tudtam, hogy győztem.

Szólj hozzá!

Címkék: barkácsolás

NewTech meetup

2011.10.07. 23:33 Travis.CG

Megnéztem egy NewTech meetupot. Mint bioinformatikust elsősorban a biohacking érdekelt. Az előadó arról beszélt, hogy az olcsó vegyszereknek és az OpenPCR-nek, ingyenes bioinformatikai programoknak hála bárki megvizsgálhatja környezetét. Úgy is mondhatnám egy biológus szemével nézheti a világot. Példaként említette, hogy egyes emberek az étteremben felszolgált hal genetikai markereit keresték, hogy megtudják, tényleg azt adtak-e nekik, amit ők megrendeltek.

Mint olyan ember, aki már dolgozott laborban, azt tudom mondani, hogy sajnos ez nem ilyen egyszerű. Ha már van tiszta DNS, akkor tényleg lehet vele "játszani", de a DNS tisztítása, kinyerése egyáltalán nem olcsó. Ember esetében lehet venni DNS izoláló kiteket, amelyek bárkit bűnügyi helyszínelővé változtatnak, de ezek egyáltalán nem az olcsó kategóriába esnek. Ha pedig olyan fajokat akarunk megszekvenálni, ahol bejáratott protokol sincs, akkor több, erősen mérgező vagy rákkeltő anyaggal kell dolgozni. (Egy ismerősöm például egy gyógynövényből igyekszik DNS-t izolálni. Mesélte, hogy nem könnyű a dolga, pedig ő egy jól felszerelt laborban próbálja mindezt)

Egy másik előadás már valódi hackerekről szólt, akik tudásukat biztonságos környezetben gyakorolhatják. Olyan weboldalak ezek, amik rejtvény formájában egyre nehezebb feladat elé állítják a potenciális hackert. A több, különböző oldalon elért pontszámok összegyűjtésére szintén született egy weboldal, ahol mindenki megtudhatja, mennyit is ér.

Ami még tetszett nekem, az egy olyan videó volt, ahol történészek egy játék motort felhasználva a Mohácsi csatáról készítettek filmet. Azon gondolkodtam, mennyire lenne nehéz olyat csinálni, hogy "élőben" kövesség az eseményeket? Úgy képzelném el a dolgot, mintha szellemek lennénk, akik repülve oda mennénk a csata közben, ahova akarunk. A játékmotor elvileg lehetővé tenné ezt is.

A többi előadás nem volt érdekes.

Szólj hozzá!

Címkék: életmód

Geneious: Szép vagy okos?

2011.10.02. 15:46 Travis.CG

Nem szívesen dolgozom CLC-vel. Csak akkor indítom el, ha kiosszák feladatban, hogy az adott problémát ezzel kell megoldanom. Azért nem szeretem, mert nem képes vizualizálni az információt. Amit vizualizál, az pedig ronda, nehezen kezelhető.

Nemrég viszont megkértek, hogy nézzem meg a Geneious programcsomagot, ami egyfajta CLC Workbench rivális. Megpróbálom bemutatni, hogy egy újgenerációs szekvenciákkal foglalkozó bioinformatikus munkáját miként tudja segíteni. Teljesítményre és pontosságra nem fogok kitérni ebben az összehasonlításban. Esetleg ha érdekel valakit, akkor szentelek ennek is egy posztot. (Az olvasók számát elnézve erre nem sok esély van :-)

Először is, a Geneious megpróbálja csak azokat az eszközöket a kezünk ügyébe helyezni, amire éppen abban a pillanatban szükségünk lehet. Ez nagyon szimpatikus tulajdonság. Ha megnyitunk egy szekvenciát, a felső sorban megjelennek a primer tervezés és az annotáció hozzáadása gombok. A kezelőfelület ezért zsúfoltnak hat, amit én személy szerint nem tartok hátránynak.

Az információk is szépen vannak megjelenítve. Egyszerűen jó ránézni például az alternatív transzlációt megjelenítő ablakra. A fejlesztők nagy hangsúlyt fektettek a legkülönbözőbb adatbázisokhoz való kapcsolódásra. Példának okáért egy nyilvános EnsEMBL adatbázishoz próbáltam meg kapcsolódni a segítségével. Ha az egyéb járulékos elemeket telepítettem volna, minden bizonnyal sikerült volna. Ez nem a program hibája.

A menüsorban is csak azok az elemek aktívak, amelyek relevánsak a kijelölt adattípus feldolgozása szempontjából.

Rengeteg adattípust képes importálni. Sajnos itt komoly hiányosságok vannak. Először is, nincs finomhangolásra lehetőség. Aki dolgozott már FASTQ fájllal, az tudja, hány féle variánsa van. A Geneious ennek ellenére nem kérdez semmit, csak betölti azt. Nem tudja például, hogy színkódolásos adatokat is tartalmazhat, ezért ha ilyet kísérelünk meg betölteni, nem olvas be semmit. Ugyan így nem kérdez rá a paired-end adatokra sem. Ami azt illeti, paired adatok kezelésére emiatt teljesen alkalmatlan. (Színkódolt adatokat csak csfasta formátumban tud betölteni, de én nem tapasztaltam, hogy megkérdezte volna, van-e quality fájl.)

Tegyük fel, sikeresen beolvastuk valahogy a szekvenciánkat. Mit kezdhetünk vele? Ebből a szempontból is elég kiábrándító a program. Csinálhatunk de-novo-t vagy illeszthetjük referencia szekvenciához. Nincs SNP detektálás, nincs RNA-Seq, Chip-Seq. Semmi.

A referenciához illesztés valami furcsa okból kifolyólag nem az Alignment, hanem az Assembly menüpont alatt található. Itt egyetlen dialóguspanelen választhatjuk ki, hogy milyen módon akarjuk illeszteni a szekvenciákat. Ha viszont referenciához akarunk illeszteni, akkor a referencia szekvenciát itt nem választatjuk ki! Azt azelőtt kell kijelölni, hogy a dialógusablakot megnyitnánk. Itt egy újabb probléma van. A két fájlnak ugyan abban a könyvtárban kell lennie. Én személy szerint szeretem külön tárolni a readeket és a referencia szekvenciákat. (Esetleg a referenciákat is tovább bontom olyan naív gondolatok szerint, hogy prokariótáról vagy eukariótáról van-e szó) Hiszen egy referencia fájl több különböző analízis során is felhasználásra kerülhet. A Geneious esetén el kell felejteni ezt a fajta felosztást. Ott célszerű az egy feladathoz szükséges fájlokat egy könyvtárba helyezni. Sőt nem célszerű, egyenesen kötelező.

Miután végeztünk az illesztéssel, könnyen tudjuk nagyítani és kicsinyíteni a látható képet. Görgethetünk jobbra és balra. De nem ugorhatunk referencia pozícióra. Miért? Ez egy nyilvánvaló igénynek tűnik. Tablet, IGV mind biztosít lehetőséget, hogy egy adott pozícióhoz tekerjek. A másik nagy szívfájdalmam a nem mappelt readek hiánya. Hogyan határozzam meg, hogy mennyire sikeres a mappelés, ha nem tudom, hány readet sikerült mappelni?

Van egy Text View nevű fül is, ahol a grafikus sallangoktól mentesen nézhetjük meg az eredményeket. Egészen jó, kivéve, ha túl sok adatot akarunk látni, mert akkor egyszerűen levágja azt, amit nem tud megjeleníteni. Ez többszörös illesztésnél ez 57 oszlop és 1500 szekvencia. (Én megközelítőleg 10 ezer szekvenciát illesztettem egy 12 ezer bázispár hosszú genomi szakaszhoz.) Tehát ez egy teljesen fölösleges funkció.

A Geneious jól használható lett volna 10 évvel ezelőtt, amikor még csak Sanger szekvenciákkal kellett játszadozni. Laboratóriumi munkámra visszagondolva biztosan nagyon örültem volna egy ilyen programnak. A világ viszont megváltozott. Egy bioinformatikai program nem teheti meg, hogy figyelmen kívül hagyja az újgenerációs szekvenálások igényeit. Az Emboss - az egyik kedvenc programcsomagom - fejlesztői is igyekeznek bekapcsolódni ebbe a folyamatba. Geneious így csak szép lehet, okos nem.

Szólj hozzá!

Címkék: bioinformatika

Vonalat akarok rajzolni

2011.09.29. 11:48 Travis.CG

Nem nehéz vonalat rajzolni. Vagy mégis? Mennyi kódot kell írni, hogy az ember kirakjon a képernyőre egy vonalat?

Mikor még csak C64-em volt, nem okozott gondot, hogy kirajzoljak egy vonalat. Igaz, ehhez a Simon's Basic nevű segédalkalmazás kellett, de gond nélkül meg tudtam jeleníteni, amit szerettem volna. Nem kellett hozzá voodoo mágia:

10 HIRES 0,1
20 LINE 0,0,320,200,1
Ahogy fejlődött a számítástechnika, a vonal rajzolása is egyre bonyolultabb lett. A 486-oson Turbó Pascallal már nem volt olyan egyszerű, de még belefért a keretbe. Be kellett tölteni valami meghajtót és már rajzolhatott is az ember.

Uses graph;
var grDriver: Integer;
    grMode: Integer;

Begin
  grDrive := Detect;
  InitGraph(grDriver, grMode, 'C:\BP\BGI');
  MoveTo(0,0);
  LineTo(320,200);
End.
De aki lemondott az önállóan futtatható állományok kiváltságáról, az még QBasicben is rajzolhatott.

SCREEN 13
LINE (0,0) - (320,200), 1
Utána történt valami. Megjelentek a grafikus felhasználói felületek. Ez a megállapítás természetesen történelmileg cáfolható, de az én személyes életemben így történt. Nem tudtam még akkor semmit Mac-ről, Amigáról, sem Xeroxról. Tehát megjelentek a grafikus felhasználói felületek, én pedig örültem, hogy végre talán egyszerűsödik a grafika használata, hiszen már eleve ott van.

Igaz, már nem kellett az ocsmány karakteres képernyőről átváltani a megváltást hozó grafikára, viszont kellett ablakot nyitni! Az ablak nyitása pedig nem volt olyan egyszerű. Én továbbra is csak vonalat akartam húzni, de ehhez meg kellett érteni az üzenetküldö rendszert, callback függvényeket, Windows osztályokat. Ha ezen átverekedtük magunkat, akkor lehetett vonalat rajzolni.

#include <windows.h>

LRESULT CALLBACK WindowProc(HWND, UINT, WPARAM, LPARAM);

int PASCAL WinMain(HANDLE hInstance, HANDLE hPrevInstance, LPSTR lpCmdLine, int nCmdShow){

   static char szNev[]="Proba";
   HWND      hwnd;
   MSG       msg;
   WNDCLASS  wndclass;

   if (!hPrevInstance) {
       wndclass.style=CS_HREDRAW | CS_VREDRAW;
       wndclass.cbClsExtra=0;
       wndclass.cbWndExtra=0;
       wndclass.hInstance=hInstance;
       wndclass.hIcon=0;
       wndclass.hCursor= LoadCursor(0,IDC_ARROW);
       wndclass.hbrBackground=GetStockObject(LTGRAY_BRUSH);
       wndclass.lpszMenuName=0;
       wndclass.lpszClassName=szNev;
       wndclass.lpfnWndProc=WindowProc;
       RegisterClass(&wndclass);
   };

   hwnd=CreateWindow(szNev,
    "Proba Ablak",
    WS_OVERLAPPEDWINDOW,
    CW_USEDEFAULT,
    CW_USEDEFAULT,
    CW_USEDEFAULT,
    CW_USEDEFAULT,
    0,
    0,
    hInstance,
    NULL);

   ShowWindow(hwnd,nCmdShow);
   UpdateWindow(hwnd);

   while (GetMessage(&msg,0,0,0)){
      TranslateMessage(&msg);
      DispatchMessage(&msg);
   }

   return msg.wParam;
}

LRESULT CALLBACK WindowProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam){
   HDC hdc;
   PAINTSTRUCT ps;

   switch (message){
      case WM_PAINT:
        hdc=BeginPaint(hwnd, &ps);
        MoveTo(hdc, 0, 0);
        LineTo(hdc, 320, 200);
        EndPaint(hwnd, &ps);
      return 0;
      case WM_DESTROY:
        PostQuitMessage(0);
      return 0;
   }
   return DefWindowProc(hwnd, message, wParam, lParam);
}
Mikor először használtam Visual Basicet (4.0), akkor egy pillanatra hatalmas kő esett le a szívemről. Először tudtam úgy rajzolni, hogy nem kellett a Windows lelki világával foglalkozni. Csak húztam egy ablakot és még a print üzenetek is megjelentek rajta! Felemelő érzést volt, még akkor is, ha a végleges futtatható fájlok mellé vb40016.dll-t kellett csomagolni (A példaprogram csak az ablak aktiválásánál használt szubrutint tartalmazza, valójában kicsit több sorból áll a forráskód).

Private Sub Form_Activate()
Line (0,0) - (320,200), 1
End Sub
A Delphi már normális exe-t készített. Adott Canvas objektumot. Azzal is lehetett rajzolni, de már nem volt az az egyszerű eset, mint a Visual Basic (a kód itt is csak egy részletet tartalmaz).

procedure TForm1.FormActivate(Sender: TObject);
begin
  Canvas.MoveTo(0,0);
  Canvas.LineTo(320, 200);
end;
Utána ismerkedtem meg a Linux-szal. Mintha visszafordult volna az idő! Az svgalib segítségével konzolból tudtam vonalakat feszíteni két pont közé, akár csak Turbo Pascalban. Cserébe root-nak kellett lennem, ami tudjuk mit jelent Linux alatt. A későbbi svgalib helper modul igyekezett javítani a helyzeten.

#include <vga.h>
int main(int argc, char **argv){
  vga_init();
  vga_setmode(G320x200x16);
  vga_setcolor(4);
  vga_drawline(0,0,320,200);
  vga_setmode(TEXT);
}

Pusztán az X-et használni rajzolásra, őrültség. Ha a Windows 3.1 modelljét feleslegesnek ítéltem, akkor a puszta X használata maga a tömény mazochizmus. Ha pedig GTK-t vagy QT-t használ az ember, akkor csökkenti a hordozhatóságot.

Néha az is megesett velem, hogy nem is a képernyőre kellett rajzolni, hanem egy képállományba (mondjuk mert egy weboldalhoz dinamikusan generáltam a képet). Ilyenkor a GD nevű könyvtárat használtam. A változatosság kedvéért PHP-ból:

<?php
   $p = imagecreatetruecolor(320,200);
   imagecolorallocate($p, 0, 0, 0);
   $c = imagecolorallocate($p, 255, 255, 255);
   imageline($p, 0, 0, 320, 200, $c);
   header("Content-type: image/png");
   imagepng($p);
   imagedestroy($p);
?>
Általában viszont a képernyőn akarjuk látni az eredményt, nem egy fájlban.

Az OpenGL Gluttal már egészen jó alternatíva. Legalábbis a régi glBegin-glEnd páros. Hangsúlyozom, vonal rajzolásról beszélek. Amikor a több millió poligon megjelenítésének oltárán feláldozták a gyors prototipizálás lehetőségét, ismét új alternatíva után kellett néznem.

#include <GL/glut.h>

void Display(){
   glBegin(GL_LINES);
   glVertex2f(0,0);
   glVertex2f(320,200);
   glEnd();
   glutSwapBuffers();
}

void keyfunc(unsigned char key, int x, int y){
   switch(key){
      case 27: exit(0);
   }
}

int main(int argc, char *argv[]){
   glutInit(&argc, argv);
   glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB);
   glutInitWindowSize(1024,768);
   glutCreateWindow("Vonal");

   glutDisplayFunc(Display);
   glutKeyboardFunc(keyfunc);
   glutIdleFunc(Display);
   glutMainLoop();

   return(0);
}
Az egyik lehetőség a Java volt. Ez a nyelv azt ígérte, hogy az egy vonalas rajzprogramom platformfüggetlen lesz. Sajnos a grafika kifejezetten platformfüggő. A példaprogram egy vonal rajzoló applet, hogy minél kevesebbet kelljen írni:

import java.awt.*;
import java.applet.*;

public class Line extends Applet {
  public void init(){
  }

  public void stop(){
  }

  public void paint(Graphics g){
    g.drawLine(0,0,320,200);
  }
}
A másik lehetőség, hogy maradok Windows alatt és áttérek a C#-ra. Amit azt illeti, az Etch-a-sketch című demónkhoz C#-ban kezdtem el írni egy szerkesztőprogramot, ami a demó grafikáit készítette volna el. Érdekes módon ez a demó is főleg vonalakból áll.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace drawing
{
    public partial class Form1 : Form
    {
        Graphics Canvas;
        Pen drawpen;

        public Form1()
        {
           InitializeComponent();
           Canvas = this.CreateGraphics();
           drawpen = new Pen(Color.Black);
        }

        private void Form1_Activated(object sender, System.EventArgs e)
        {
           Canvas.DrawLine(drawpen, 0,0, 320, 200);
        }
    }
}

A példa itt is csak egy részletet mutat be abból, ami a vonal rajzoláshoz kell. Lehet látni, hogy a példák legtöbbje nem is a grafikáról szól, hanem egyéb járulékos elemekről, amelyek nélkül a grafikus felületen nem tudunk pixeleket színezni.

Mit is akarok? Vonalat húzni, gyorsan, eszközfüggetlenül. Ahogyan Perl alatt villám sebességgel feldolgozom a szöveges állományokat, úgy akarom egy ablakban megjeleníteni a vonalaimat. Szeretném, ha ez platform független lenne. Van remény? Igen van. Úgy hívják Processing. Végre tudok vonalat rajzolni.

void setup(){
   size(320,200);
}

void draw(){
   line(0,0,320,200);

Frissítés:

Persze a Python is tartalmaz ügyes modulokat:

import Image
import ImageDraw

image = Image.new('RGB', (1024, 768)) # width and height
draw  = ImageDraw.Draw(image)
draw.line((0,0,1024,768), fill = (0,255,0)) # coordinates and color

 

Szólj hozzá!

Címkék: programozás filozofálás

CLC parancssorból

2011.09.28. 10:07 Travis.CG

A klikkelős programokkal az egyik alapvető problémám, hogy csak nagyon ritka esetben nyújtanak segítséget az ismétlődő feladatok leeegyszerűsítésére. Emlékszem, még a win 3.1-ben voltak makrók, amelyekkel több-kevesebb sikerrel lehetett felvételeket készíteni tevékenységünkről, majd visszajátszani. A módszer sikertelenségét jól mutatja, hogy ez az eszköz már nem része az újabb rendszereknek.

A különböző makronyelvek és azok programba/szkriptbe szervezése ellenben virágzik, gondoljunk csak a Blenderre, amiről már röviden írtam. A bioinformatikában különösen fontos, hogy több adattal dolgozzunk. Ritkán van olyan szerencsénk, hogy egy mintát kell elemeznünk. A folyamatok automatizálása ezért létkérdés.

A CLC is felismerte, hogy hiába a könnyű kezelhetőség, a szupergyors algoritmusok, ha egyszer a felhasználó klikkelési sebessége limitálja az adatfeldolgozás hosszát. Ezért a CLC Server kapott egy parancssoros, jelenleg béta állapotú felületet. Mivel bétáról van szó, lehetnek eltérések az itt leírtakhoz képest.

Használat

A parancssor egyetlen Java alapú program, ami a clcserver nevet kapta. Az összes programozói eszközt az operációs rendszer parancsértelmezője adja, ami az itt bemutatott példáknál egy Linuxos Bash lesz. Érdemes megemlíteni egy másik programot is, a clcresultparser-t, ami a program által visszaadott szöveges eredményt dolgozza fel. Ha elég erőt érzünk magunkban, helyettesíthetjük egy grep-el.

A program működéséhez indítsuk el a CLC Servert:

>CLCGenomicsServer start

Most már nyugodtan használhatjuk a szkriptjeinket.

Kötelező argumentumok

Az első kényelmetlenség, hogy minden egyes parancs kiadásához négy állandó paraméter kell. Mivel szerverről van szó, ez a szerver URL-je (-S), a port (-P), felhasználó név (-U), jelszó (-W).

>clcserver -S localhost -P 1234 -U user -W secretpassword

Ennek nyugodtan csinálhattak volna egy konfigurációs állományt. Mivel nem csináltak, hozzunk létre egy Bash változót és nevezzük el CMD-nek. A továbbiakban csak a CMD változóra fogok hivatkozni:

CMD="/opt/CLCServer/CLI/clcserver -S localhost -P 1234 -U user -W secretpassword"

Elérési utak

Mivel szerverről van szó, és a parancssoros programnak nem kell feltétlenül azon a gépen futnia, a fájlok elérése URL-en keresztül történik. A protokol a clc. Ha olyan fájlra akarunk használni, ami már a CLC Server "látókörében" van, akkor a clc://server kezdetű URL-el tudunk rá hivatkozni. (Ezek clc kiterjesztésű fájlok. Szerializált Java objektumok.) Ha egy külső fájlt akarunk megadni, akkor a clc://serverfile előtaggal érhetjük el azt.

Parancsok

A parancsokat a -A argumentummal adhatjuk meg, majd ezt követik a parancs-specifikus egyéb paraméterek. Például listázzuk ki azokat a fájlokat, melyek a CLC Serveren vannak:

$CMD -A ls -t clc://server/CLC -O res.txt

A -t argumentummal adjuk meg, hogy mit szeretnénk kilistázni. A -O pedig a res.txt állományba menti az eredményt. Ha megnézzük a res.txt-t, azt tapasztaljuk, hogy minden kilistázott objektumhoz tartozik két URL (egy egyszerűsített és egy teljes), egy név és dátum. Ezt a fájlt lehet feldolgozni a clcresultparser-el. Ez a teljes URL-t visszaadja. Például tegyük fel, van 23 darab "read" karaktereket tartalmazó fájlunk, amelyeket szeretnénk egy referenciához illeszteni.

for READ in `clcresultparser -f res.txt -c read`
do
  $CMD -A read_mapping --short-read-alignment-mode ALIGNMENT_LOCAL -i $READ --references clc://server/CLC/chrX -d clc://server/CLC/results
done
A -d adja meg az eredmény helyét, a --references a referencia objektum elérési útja, a -i pedig a short read adat. Figyeljük meg, hogy a clcresultparser -c opcióját, amivel kiszűrjük azokat a neveket, amelyek tartalmazzák a "read" szót.

Összegzés

A CLC jó irányba indult el a parancssoros interfésszel. Az is jó ötlet, hogy egy ismerős közegbe (Bash) beilleszhető a szervert vezérlő parancs. A használhatóságán viszont lehet még javítani. A parancsok alapértelmezett tulajdonságai is meglepően vannak beállítva, gyakran nem tükrözik a grafikus felület beállításait. (Például alapértelmezetten a short readek importjánál eldobja a read azonosítókat). Néhány esetben logikátlan opciókat is meg kell adni. (Ha nem paired adatokat töltünk be, akkor is meg kell adni a readek távolságát) Reméljük, a végleges változatban kijavítják ezeket a hibákat.

Szólj hozzá!

Címkék: programozás rendszergazda bioinformatika

Function 2011 - második nap

2011.09.17. 21:59 Travis.CG

Második nap. Reggel eszembe jutott egy jelenet, amit érdemes lenne belerakni a demóba, ezért nekiláttam kódolni. Sajnos a kódolás annyi időt felemésztett, hogy rendesen össze sem készültem. Normális esetben szoktam enni- és innivalót vinni magammal. Most csak azt ellenőriztem, hogy nálam legyen a pendrive, azon rajta legyen a release és már rohantam is a tömegközlekedésre.

Mondanom sem kell, hogy a reggeli jó ötletet nem sikerült megvalósítani. A kód ezért aktiválás nélkül csücsül a demóban.

Fotó

A fotók nem okoztak nagy katarzist, amibe az is bejátszhatott, hogy az agyam még a demó körül járt.

Előadások

FabLab: Egy enyhén marketingszagú előadást hallottunk egy nagyszerű kezdeményezésről, ahol a lelkes emberek megvalósíthatják álmaikat olyan eszközök segítségével, amelyekre normális esetben nem lenne pénzük. A marketingszag mellett az előadó nagyon fiatalos és laza volt. Minden második szava az volt, hogy ez vagy az "mekkora fles". Egyszer csak ADT beordította: Amiga! Ez kizökkentette az előadót a mondandójából. Meg is jegyezte, hogy ezt nem érti. A közösség bemutatása is hosszúra sikeredett. Nem azért, mert olyan sokan voltak, hanem mert mindenki annyi mindenhez értett. A normális szakmájukon kívül ilyen képességekre derült fény, mint blogger és vizuális marketing.

4k szintetizátorok: Az intrók által használt zene generáló eszközökről esett szó. Az előadó bemutatta röviden saját eszközeit, majd általános tippeket adott, hogyan írjunk saját eszközt. Az előadásnak egy hibája volt: rövid volt. Szívesen halgattam volna még műhelytitkokat, mint amilyen az, hogy a textúra generátor függvényt hogyan használjuk dallamok készítésére.

Zene

A zenék nem voltak rosszak. A zenei stílus is elég változatos volt, nem korlátozódott a drumm and bass-ra. Személyes kedvencem a Take Me volt, ahol a patikon oly ritkán hallható vokál is megjelent. Természetesen voltak kevésbé jólsikerült alkotások is.

Kézi rajz

Csak hat induló volt. Úgy látszik nem túl népszerű a számítógépek világában a kézi rajz. Rajzokról Grass biztosan fog írni a Scene.hu-n, majd belinkelem.

Freestyle

A szabad stílusú rajzok gyengék voltak. Sokan gondolták úgy, hogy a fotón alkalmazott Photoshop elég a freestyle grafikához. Nincs igazuk. De sajnos még ennél is volt rosszabb. Kimerítő cikket szintén Grass fog írni.

Wild

Mivel ide mindent be lehet adni, mindent be is szoktak. Volt egy zenekészítő kütyü, egy LEGO platformra épülő alkotás, amiről megmondom őszintén, hogy nem tudom, mi lehetett és egy remek stop-motion film. A Los Angeles Lamers hozta a tőlük elvárt formát és poénokat.

Intrók

Az intrók érdekesek voltak. Nem mutattak be egyetlen korszakalkotó, világmegváltó release-t, de nekem tetszettek.

Demo

Tíz induló volt, ami ritkaság magyar partin. Sok új csapat indult. Naívan azt hittem, hogy a középmezőnyben fogunk végezni, de nem így történt. A Biopunk utolsó előtti lett. Igaz, hogy sok hibája volt, mint a nem túl részletes textúra, az alacsony poligonszám, realisztikus effektek hiánya, de én jobbra számítottam. De ilyen a parti. Majd meglátjuk, milyen kommenteket kap pouet.net-en.

A programok között megtekintettem egy MorphOS-t, ami egy laptopon futott. Charlie bemutatta az oprendszer minden darabját. Én meg sikeresen szétfagyasztottam. Sajnos ismert bug volt, pedig jó lett volna egy újat felfedezni.

Blalával is beszéltem, aki - talán az elfogyasztott alkohol hatása alatt - váltig állította, hogy van egy másik Travis is a partin. Felkerekedtünk, hogy megkeressük. Egy ideig erősködtem, hogy nincs másik rajtam kívül, majd feladtam. Nagyjából tíz percig kerestünk engem, amikor Blala rám néz és azt mondja: Nem is Travisnek hívják. Ezzel helyre is állt az univerzum rendje.

Spenot Amigás demót készített, aminek külön érdekessége, hogy a forráskód gond nélkül portolható 64 bites Apple gépre. Győzködtem, hogy adja be, de nem tette.

Történt némi dráma is. D-lee, aki egy ideje többet foglalkozik a Forma1-el, mint a demoscenevel, készíttetett a barátnőjével egy videót, amibe mások zenéjét tette bele, azok előzetes megkérdezése nélkül. Nem mutatták be az alkotást, mert több utalás is volt a szerző céges érdekeltségére. Ezt D-lee személyes sértésnek vette.

Összességében jó parti volt, nagyon tetszett. Volt sírás-nevetés egyaránt.

Szólj hozzá!

Címkék: demoscene parti riport

Function 2011 - első nap

2011.09.17. 13:50 Travis.CG

Az első nap nem alakult jól. Nagyon nem. Arra számítottam, hogy szép, nyugodt pénteki napom lesz, ahol senkit nem fog zavarni, ha a munkaidő egy kis szeletét nem munkával, hanem mondjuk egy hiányzó jelenet elkészítésére fordítok. Nem így történt.

Befutott egy sürgő munka, ami miatt úgy tűnt, még túlórázhatok is. Ez meghiusította azt a tervemet, hogy már pénteken kinézek a partira. A munka végeztével aztán úgy gondoltam, talán már a demómmal foglalkozhatom. Nem így történt. A mosógép furcsán viselkedett, amit szintén nem hagyhattam figyelmen kívül. Este még beléptem a munkahelyi szerverre, hogy megnézzem, kell-e valamit segíteni.

Nem kellett. A nap elcsendesedett és végre koncentrálhattam a demóra. Pár jelenet nem volt tökéletes, azokat állítgattam, hogy minden tökéletes legyen. Természetesen találtam új hibákat, amik nem programozási, inkább látványbeli hibák. A poligonok nem úgy álltak, ahogy szerettem volna. A modellek poligonjainak súlyozását kellett volna állítani, amire nem volt idő, ezért kódban gyorsan korrigáltam ezt. Nem szép, de gyors megoldás.

Éjfél után úgy feküdtem le, hogy így már be lehet adni. Nem lesz egy győztes, de vállalható.

Szólj hozzá!

Címkék: demoscene parti riport

De novo assembly

2011.09.05. 14:50 Travis.CG

A mai nap a de-novo szekvencia összeszerelésről írok egy rövid ismertetőt, nagyon alap szinten, gyakorlati tudnivalókkal.

Mért kell?

Amikor a tudományos-fantasztikus filmeket nézzük, akkor olyan képet festenek a szekvenálásról, mintha az egy könyv olvasása lenne. Elindulunk az elején, eljutunk a végére. Ez elég szemléletes analógia, ezért a továbbiakban is ezzel a hasonlattal fogok élni.

Ez a világon, sehol nincs így. Sajnos egyszerre csak a teljes genomokhoz képest igen rövid szakaszokat tudunk megszekvenálni. Mikor még laborban dolgoztam, akkor ez a hosszúság kb. 400 bázispár volt, utána a szekvenálás minősége folyamatosan romlott. (Témavezetőm előszeretetttel nyomta a kezembe a szekvenciákat, hogy kézzel javítsam ki őket a leolvasott színkódok alapján. Hiába, a PhD-s munkaerő olcsóbb, mint még egyszer szekvenálni :-) ) Ezt Sanger típusú szekvenálásnak hívják. Nagy pontosságú, de lassú.

Tehát a szekvenálás kis darabokat eredményez, a könyves hasonlathoz visszatérve, a könyv lapjait. Az új típusú szekvenálások meggyorsították a szekvenálás menetét, de rövidebb szekvenciákat eredményeztek. (Nem oldalakat kapunk, csak mondatokat). Az egyik szerencsénk, hogy a szekvenciák átfednek. Ez alapján tudjuk őket összerakni. De ahogy egy regényben is előfordulhatnak ismétlődő mondatok, úgy a genomban is. Tehát eldönteni, hogy egy mondat a 100. oldalra, vagy a 231-re illik, nehéz feladat.

Metódusok

A megoldást különféle algoritmusok nyújtják. Az első és legegyszerűbb, keressünk egyező, kisebb darabokat, összeillesztjük és kiterjesztjük a szekvenciát. Ezek a mohó (greedy) algoritmusok. Mohók, mert nem nézik meg, hogy más helyre érdemesebb-e beépíteni a szekvenciát, csak kiválasszák azt, amivel a legnagyobb hosszúságot elérhetik.

A népszerűbbek a de-bruijn gráfon alapulnak. A csomópontok az egyes szekvenciák, az élek pedig a lehetséges kapcsolódások más szekvenciákkal. Az ismétlődő szakaszok (repeatek) esetén a gráf bonyolult formát vehet fel. ( Egyes algoritmusok az ismétlődések mennyiségét az oda helyezhető szekvenciák számából megpróbálja becsülni. Szakszóval a coverage-ből. )

Napjainkban a hibrid összeszerelők adják a legjobb eredményt. Két vagy több technológián alapuló szekvencia készletből szerelik össze a végső genomot. Például egy hosszabb, de pontatlanabb (szakzsargonnal 454) és egy rövidebb, de pontosabb (Illumina) szekvenálás eredményét ötvözik.

Alkalmazások

Az utóbbi időben kipróbáltam pár de-novo programot, ezek eredményéről fogok beszámolni. Egy bakteriális genomot kellett összeszerelnem, a szekvenciák 454-ből származtak.

1. SOAPDenovo: A kínai intézet szuperfegyvere. Elvileg ezzel rakták össze az óriáspanda genomját. Azért elvileg, mert nekem nem sikerült működésre bírni. A bináris állomány floating point exception-t adott, de még azt sem sikerült kitalálnom, hogy melyik modulban. Nagy csalódás volt.

2. Velvet: A Velvet szimpatikus kis program. Forrásból pillanatok alatt fordítható. Kevés paramétert lehet állítani benne, abból is a legfontosabb a k-mer, ami azt mondja meg, hogy milyen hosszú átfedő darabokat keressen a szekvenciákban. Ha 31-nél nagyobb k-mert szeretnénk használni, akkor újra kell forgatni a programot. Kezeli a color-space szekvenciákat (van egy szekvenálási típus, ahol nem a gimiben megismert ATGC bázisokat kapjuk vissza, hanem egy színkódolt szekvenciát. A kódolásnak gyakorlati haszna van, de néha megkeseríti a bioinformatikusok sorsát) Ismeri a paired-end és mate-pair szekvenciákat is. Két programból áll. Az első készít egy keresőtáblát (velveth), a második pedig megpróbálja megoldani a gráfot (velvetg). A színkódolt szekvenciák esetén szükség van a szekvenciák elő- és utókezelésére. 263 contigot rakott össze nekem.

3. CLC Genomic Workbench: Aki utálja a parancsok gépelgetését, annak itt a klikkelős mindenes. Pénzes program, de 14 napig élvezhetjük a használatát. Van benne egy de-novo modul, ami szerintem egy mohó algoritmuson alapul, legalábbis a paraméterek alapján erre következtetek. Gyakorlatilag bármit beadhatunk neki. Nekem 89 contigot eredményezett a fenti adatsorra. De azt is csináltam, hogy különböző szekvenálásokból a contigokat egybe ömlesztettem, és azzal is tudott mit kezdeni (kevesebbet csinált belőlük). Ezt persze nem javaslom, mert az egyik paramétere, hogy mekkora átfedő szakaszokat vizsgáljon, és itt az átfedő és a teljes szekvencia hosszának arányát várja. Ha tehát különböző hosszúságú szekvenciákat akarunk összerakni vele, akkor a beállításokkal kizárhatjuk egyik vagy másik szekvencia típust. A CLC kezeli az összes szekvenálási technológiát.

3. Mira: Ez a program a legbonyolultabb az összes közül. Rengeteg paramétere van, a bemeneti és kimeneti fájlokra névkonvenció. Viszont ha beállítottuk, akkor elindul és megcsinál mindent. Számol statisztikát, többféle kimenetet produkál, képes hibrid üzemmódra. Alapértelmezett beállításokkal is 36 contigot rakott össze. Cserébe sokáig fut. Nem kezeli a színkódolt szekvenciákat.

Melyik a legjobb

Annak eldöntésére, hogy melyik eredményt hihetjük el, sok paraméter dönt. Az első, hogy hány darabot tud a szekvenciákból összeilleszteni. Értelemszerűen minél többet épít össze minél kevesebb kontigba, annál jobb. A kontigok átlagos hossza is hasznos mérőszám. Van egy N50 (egyes esetekben N25 is) nevű jelzőszám is, ami azon kontigok közül, amelyek az összes kontig teljes hosszának a felét teszik ki, mekkora a legkisebb mérete. Más szóval a legkisebb hosszú kontignak a mérete.

Szólj hozzá!

Címkék: bioinformatika

Nem értek a Linuxhoz

2011.09.03. 16:46 Travis.CG

Az idei Functionon a kiírás szerint a Linuxos compogép egy 64bites Ubuntu 11.04 lesz. Én elsősorban Slacware 11 alatt fejlesztek, amit jó ideje nem frissítettem. Tavalyról maradt egy 32 bites Ubuntu 10.04 az egyik partíciómon ezért egy hirtelen ötlettől vezérelve feltelepítettem rá egy Ubuntu 11.04-t.

Nem számítottam semmi problémára, és itt követtem el az első hibát. Az új rendszer felajánlotta a frissítés lehetőségét, de arra gondoltam, jobb lesz, ha egy teljesen szűz rendszeren tesztelem le a demót, ezért a telepítőnek azt mondtam, törölje a régi Ubuntut.

A telepítő engedelmeskedett a parancsnak, és szó nélkül felülírta az első merevlemez MBR-jét is, amit nem akartam. Csak hogy érzékeltessem a káoszt: Van két vinyóm szoftveres RAID-be kötve, ezen van a Slackware és a munkám nagy része. Egy külön vinyón az Ubuntu és még egy vinyó a Windowsnak. A Windowsos MBR-ben van egy LILO, ami be tudja tölteni a Slackware-t és a Windowst, de az Ubuntut nem (sokat próbálkoztam vele, de nem sikerült megoldani). Ezért az Ubuntu MBR-jében vagy egy GRUB, ami szintén be tudja tölteni a Windows-t és az Ubuntut. A Slackware-t nem, pedig ezen is próbálkoztam öt percig, azután nem sikerült és meg nem erőltettem tovább.

Az új Ubuntu minden kérdés nélkül felülírta a Windows-os MBR-t és elvágta a lehetőséget, hogy betöltsem a Slackware-t. Nem baj, úgyis időszerű volt, hogy ne a Bios-ból állítsam be az operációs rendszereket. Gondoltam, majd beírom a megfelelő bejegyzéseket a menu.lst-ba és máris minden rendszert el fogok tudni érni.

Először is, nem találtam meg a start menüt! Az új Unity teljesen idegen volt számomra. A startmenüben csak nehezen találtam meg a terminált. Úgy éreztem magam, mint aki most kapcsolja be először a számítógépet. A terminál már ismerős volt. Csak az ablak menüit nem találtam. Á, hogy a képernyő tetején van, mint a Mac-eknél? Ott sem szeretem ezt a megoldást.

Szerencsére a könyvtár struktúra változatlan maradt. A /boot/grub még mindig a régi. Illetve nem egészen. A grub könyvtár tele van fájlokkal. Azt észrevettem, hogy ezek modulok különböző fájlrendszerekhez. Ez még nem is tűnt rossz ötletnek, hiszen korábban bele kellett pakolni az fstab-ba azokat a partíciókat, is, amelyeket be akarta tölteni az ember, de használni nem akarta. Talán most ennek vége. Kerestem egy menu.lst-t, de nem találtam. Viszont volt grub.cfg. Az is jó nekem. Átírom és minden jó lesz.

Mikor megláttam a felépítését, akkor már tudtam, ezt én bizony át nem írom. Ennél már csak egy XML lehetett volna bonyolultabb. Kénytelen vagyok elhasználni egy segítséget. A közönség szóba sem jöhetett, ha megfelezek valamit, akkor az a számítógép lesz, de baltával, ezért maradt a gugli.

Az okos grub2 zsenik a neten szintén azt javasolták, hogy ne szerkesszem a grub.cfg-t, hanem helyette shell scripteket írogassak, amelyek majd szerkesztik helyettem az állományt, és azt is el kell felejtenem, hogy csak szerkesztem a fájlokat és újraindítok, hanem a LILO-hoz hasonlóan egy paranccsal kell frissíteni a grub-ot. Már csak egy kérdés maradt, mit kezdjek a raid-el?

Abban biztos voltam, hogy kell egy raid modul: insmod raid Ez egyszerű. De mi lesz az eszköz neve? A set root= után mit írjak. A neten csak úgy pongyolán az egyenlőség jel után beírták az eszköz nevét, de az én állományomban egyszeres idézőjelek között szerepeltek az eszköznevek. Úgy döntöttem, ezt használom. A net szerint csak simán md0-val hivatkozhatok az eszközre, de ez sem igaz, legalábbis nálam. No such disk hibaüzenetet kaptam.

Most mit csináljak? Ráadásul utáltam a sok újraindítást is. Szerencsére a grub konzolját megtartották, ezért úgy döntöttem a konzolból próbálgatom az eszközneveket a jó öreg TAB-os kiegészítésekkel. Talán lesz valami.

Ez bejött. Az eszköz valami csoda folytán hd2, msdos1 Igazából nem meglepő, mert annak idején a raid boot partícióját úgy állítottam be, hogy csak tükrözve legyen és az adattároló partíciót állítottam raid1-be. Működött! De mennyi idő elment rá! Ebből is látszik, hogy nem értek a Linuxhoz.

Ui: Kipróbáltam a demót. Szaggatott, mint a fene. Ezért be kellett kapcsolni a driverben a Sync to VBlank opciót, és onnantól szép simán ment. De nem kell neki egyetlen más letöltés sem. Ennek azért örültem.

Szólj hozzá!

Címkék: filozofálás rendszergazda

Ismétlődő mozgások vertex shaderrel

2011.08.15. 22:54 Travis.CG


Organikus térhálókat élethűbbé tehetünk apró, periodikus mozgásokkal. Ilyen
volt például az Aeronautism című demónkban a repülő szörny, aminek a csápjai
és a farokúszója ritmikusan lengett.

A vertex shaderek elsősorban a térhálók csúcsponti koordinátáit és a normál
vektorokat kapják bemenetnek, de a programozó bizonyos számú saját attribútumot
is megadhat. Ezt fogjuk mi is használni, hogy kijelöljük azokat a csúcspontokat,
amelyeket mozgatni akarunk.

A csúcspontok kijelöléséhez kezdetben azt a trükköt használtam, hogy a betöltöttem a modellt egy szerkesztő programba és azokat a csúcsokat, amelyeket nem kívántam mozgatni, kitöröltem. Exportáltam OBJ formátumba a csonka modellt, majd a Linux parancssor és Perl scriptek segítségével összehasonlítottam az eredeti modellel. Végül a különbségükből készítettem egy fájlt, ami minden egyes csúcspontra tartalmazott egy 0 vagy 1 értéket, attól függően, hogy akartam-e mozgatni az adott csúcsot vagy nem. Az Aeronautism-ban volt egy 0.5 is, mert a csápokat máshogy mozgattam, mint a farokúszót.

Szerencsére Blender segítségével egyszerűsíthető a folyamat. Ezt fogom részletezni.

Indítsuk el a Blendert, töltsük be a modellünket. Váltsunk Vertex Paint módba, majd fessük be a kívánt színűre a csúcspontokat. A be nem festett részek fehérek lesznek. Ha többféle mozgást akarunk, akkor használjunk különböző színeket. Ebben a példában pirosat használtam. A mozgások finomhangolására használhatjuk a színek intenzitását is, amit a Paint fülön állíthatunk be.



Ha elküszültünk, akkor egy Python script segítségével könnyedén exportálhatjuk a csúcspontok színeit. A szkript forráskódja a következő:

#!BPY
"""
Name: 'Vertex Color Extract'
Blender: 243
Group: 'Export'
"""
import bpy
import Blender
from Blender import *

scene = bpy.data.scenes.active
for o in scene.objects:
        if o.type == 'Mesh':
                mesh = o
bf = open("vertexcolor.txt", "w")

for face in mesh.data.faces:
        for i, vert in enumerate(face):
                bf.write("%f %f %f %d\n" % (face.col[i].r, face.col[i].g, face.col[i].b, vert.index))
bf.close()
A szkriptet másoljuk a .blender/scripts könyvtárba. Ha már fut a Blender, a Script -> Update Menu menüponttal frissítsünk. Ez a szkript egy nyers adatot ad vissza egy előre definiált fájlba. Minden egyes poligon csúcspontjának a színét és a csúcspont sorszámát adja vissza. Mivel a poligonok közös csúcspontot adnak vissza, ezért az eredmény fájl redundáns. Még mindig nem értek eléggé a Python nyelvhez, ezért az ismétlődő szakaszokat a parancssor segítségével távolítom el:
sort -nk 4 vertexcolor.txt | uniq >eredmeny.txtMinden egyes csúcspont színe megvan. A demónkba töltsük be ezt a fájlt és tároljuk le egy tömbbe. A példában ez a tömb az attrib nevet kapja.
   GLfloat attrib[4432]; /* Tudom, mennyi csúcspontom van a térhálóban */

   file = fopen("vertexcolor.txt", "r");
   while(fgets(line, 200, file) != NULL){
      r = atof(strtok(line, " "));
      g = atof(strtok(NULL, " "));
      b = atof(strtok(NULL, " "));
      index = atoi(strtok(NULL, " \n"));
      if(g == 0.0 && b == 0.0){
         attrib[index] = 1.0;
      }
      else{
         attrib[index] = 0.0;
      }
   }
   fclose(file);
A példaprogram elég egyszerű. Mivel egy demóban a programozó tudja, hogy az adott modell mennyi csúcspontból áll, ezért bocsánatos bűn, ha ezt beégetem a kódba. Ha újra akarjuk használni a kódot, akkor természetesen át kell tervezni azt.

Miután beolvastuk a fájlból az adatokat, készítünk egy vertex buffert a tárolására:
   glGenBuffers(1, &vbo);
   glBindBuffer(GL_ARRAY_BUFFER, vbo);
   glBufferData(GL_ARRAY_BUFFER, sizeof(GLfloat) * vertexcount, attrib, GL_STATIC_DRAW);
Majd a shader megfelelő változójához kötjük a vertex buffert. Ez a lépés nagyban hasonlít a korábban bemutatott csúcspont és normál vektornál használt módszerhez.
  glBindVertexArray(vao);
  uni = glGetAttribLocation(shader, "sniff");
  glBindBuffer(GL_ARRAY_BUFFER, vbo);
  glVertexAttribPointer(uni, 1, GL_FLOAT, GL_FALSE, 0, 0);
  glEnableVertexAttribArray(uni);
Az OpenGL kirajzoló rutin a következő képpen fest:

   glUseProgram(shaderprg);
   time = getTimeInterval();
   uni = glGetUniformLocation(snooze, "time");
   glUniform1f(uni, time);
Végezetül lássuk a shader kódot:

#version 410
in vec3 vertex;
in vec3 normal;
in float sniff;

uniform mat4 pmatrix;
uniform mat4 modelmatrix;
uniform float time;

out vec3 color;

void main(void){
   vec3 pos = vertex;

   if(sniff == 1.0) pos.y = pos.y + sin(time * 40.0) / 300.0;

   gl_Position = pmatrix * modelmatrix * vec4(pos, 1.0);
   color = normal * vec3(1.0);
}
Amely csúcspontnál az attribútum 1.0, ott a pozíció egy kis színusz függvény segítségével oszcillál, amitől élőbbnek tűnik a háló. Még élethűbb lehet a modell, ha zaj segítségével kiszámíthatatlanabbá tesszük a mozgást. A példafájlban a modellt Grass készítette. A Function-os demónkban is látható lesz. (A program teljes forráskódját hamarosan elérhetővé teszem)
 

Szólj hozzá!

Címkék: programozás demoscene

Amikor a másolás-beillesztés visszaüt

2011.08.04. 11:07 Travis.CG

A munkahelyemen sajnos én vagyok az, aki észreveszi azokat a hibákat, amelyek felett mások átsiklanak. Ez azért rossz, mert unalmas tesztelési munkákat is kell végeznem. Így történt, hogy egy bioinformatikai program tesztelése során furcsa anomáliára figyeltem fel. A program több szálon futott, számtalan ideiglenes állományt írt és olvasott. Ezalatt felzabált 100GB helyet, majd eredményül visszaadott 2GB-ot.

A hiba nem hagyott nyugodni, ezért megnéztem a forráskódot is. Mivel bioinformatikus vagyok, a programozók általában úgy tekintenek rám, mint valami Szkript Kölyökre, aki csak Perl-ben tud turkálni. Emberhiány esetén adnak programozós feladatot, de az is elég marginális, mintha félnének, hogy összedöntöm a verzió-követő rendszert. A nyár és a szabadságok ideje viszont megnyitotta az utat előttem, hogy megmutassam, mit tudok.

A hibát sikerült visszavezetnem egy fájl másoló metódusra, ahol NIO-t használtak. Emlékeztem is rá egy megbeszélésből, ahol a programozók bőszen magyarázták az előnyeit. A forráskódban viszont találtam egy tutorial kódot. A változók más néven szerepeltek, de egyébként kínos hasonlóságot mutatott ezze. Az egyetlen probléma, hogy a kód csak 2GB alatti fájloknál működik. Korrekt formája ez lenne:

import java.io.*;
import java.nio.channels.FileChannel;

public class niotest {
   public static void main(String[] args){
      File sfile = new File(args[0]);
      File dfile = new File(args[1]);

      try{
         dfile.createNewFile();
      }
      catch(Exception e){
         e.printStackTrace();
      }

      FileChannel from = null;
      FileChannel to   = null;

      try{
         from = new FileInputStream(sfile).getChannel();
         to   = new FileOutputStream(dfile).getChannel();
         System.out.printf("File size: %d\n", from.size());
         long written = 0;
         while(written < from.size()){
            written += to.transferFrom(from, written, from.size() - written);
         }
         System.out.printf("Written: %d\n", written);

         from.close();
         to.close();
      }
      catch(Exception e){
         e.printStackTrace();
      }
   }
}
Mert el kell olvasni a dokumentációt is, nem csak kimásolni a kódot.

Szólj hozzá!

Címkék: programozás

OpenGL 4.1 mátrixai

2011.07.31. 22:22 Travis.CG

A 3.1-es verzió óta az OpenGL nem tartalmazza a forgatással, eltolással kapcsolatos rutinokat. A profik azt írják, hogy ez egy jó ötlet volt, mert nem zárja korlátok közé a programozót. Egy API-nak viszont az a feladata, hogy megkönnyítse egy programozó életét. Ha egy alapvető funkcionalitás hiányzik az API-ból, akkor programozók tömegét kényszerítjük arra, hogy ugyan azt a feladatot elkészítse.

Aki nem akar saját maga bajlódni a mátrixok számolásával, az használhatja a glm-et, vagy egy korábbi posztomban említett Nopper úr GLUS könyvtárát. Én viszont egy merészet gondoltam, és úgy döntöttem, megírom saját rutinjaimat. Azért nevezem merésznek az ötletet, mert nem sokat konyítok a matematikához. Igyekeztem faék egyszerűségű kódot írni, amitől lehet, hogy a kód használhatósága nehézkes lesz. A megértést viszont biztosan nem fogja gátolni.

Az első és legfontosabb megemlíteni, hogy az OpenGL oszlopfolytonosan várja a mátrixokat, ami a Wikipédiában fellelhető mátrixok transzponáltja. Érthetően fogalmazva:

0 4 8 12
1 5 9 13
2 6 10 14
3 7 11 15

 Legyenen az indexek. Az általam használt kódban minden mátrix egy 16 elemű tömb lesz.

Egységmátrix

A legalapvetőbb mátrix a 3D grafikában. Az átló mentén 1-t tartalmaz. Erre azért van szükség, mert a mátrixok szorzása alkalmával nem fogja egyik mátrix a másikat kinullázni. Minden további mátrix ebből indul ki, külön nem fogom leírni.

Perspektíva

A perspektíva viszonylag egyszerű. A képernyő oldalaránya és a látószög beállítása mellett kiszámítja a mátrix értékeit. Két további paramétere a közeli és távoli vágási távolság.

void perspectiveMatrix(float *m, float fov, float aspect, float near, float far){
  float range;

  range = tan(fov * M_PI/360.0) * near;
  memset(m, 0, sizeof(float) * 16);
  m[0] = (2.0 * near) / ((range * aspect) - (-range * aspect));
  m[5] = (2.0 * near) / (2.0 * range);
  m[10] = -(far + near) / (far - near);
  m[11] = -1.0;
  m[14] = -(2.0 * far * near) / (far - near);
}

Kamera pozíció

Egy demóban, megkockáztatom ez az egyik legfontosabb mátrix. Segítségével megadhatjuk, hogy honnan nézzük a jelenetet. Ennek megfelelően bonyolult, mert több vektorműveletet kell végezni.

void lookAt(float *m, float *eye, float *target, float *up){
   int i;
   float n[3];
   float u[3];
   float v[3];
   float d[3];

   for(i = 0; i < 3; i++) n[i] = eye[i] - target[i];
   crossproduct3v(up, n, u);
   crossproduct3v(n, u, v);
   normalize(u, 3);
   d[0] = dotproduct(eye, u, 3) * -1.0;
   normalize(v, 3);
   d[1] = dotproduct(eye, v, 3) * -1.0;
   normalize(n, 3);
   d[2] = dotproduct(eye, n, 3) * -1.0;

   m[0]  = u[0];
   m[4]  = u[1];
   m[8]  = u[2];
   m[12] = d[0];
   m[1]  = v[0];
   m[5]  = v[1];
   m[9]  = v[2];
   m[13] = d[1];
   m[2]  = n[0];
   m[6]  = n[1];
   m[10] = n[2];
   m[14] = d[2];
   m[3]  = 0.0;
   m[7]  = 0.0;
   m[11] = 0.0;
   m[15] = 1.0;
}

Pozíció

A pozíció mátrix a legegyszerűbb. Gyakorlatilag a mátrix három elemét helyettesítjük a koordinátákkal.

void translate(float *m, float x, float y, float z){
   int i;

   /* Identity matrix */
   for(i = 0; i < 16; i++){
      if( (i % 5) == 0){
         m[i] = 1.0;
      }
      else m[i] = 0.0;
   }

   m[12] = x;
   m[13] = y;
   m[14] = z;
}

Forgatás

A forgatás néz ki a legijesztőbben. A legtöbb példaprogram külön veszi a tengelyek mentén történő forgatásokat, majd mátrix szorzásokkal egy forgatási mátrixot képez. Szerencsére lehet találni olyan leírást, ami leírja, hogyan néz ki az a mátrix, amiben elvégezték a mátrix szorzást. A kód ilyesztő, de csak egyszer kell megírni.

 void rotate(float *m, float rx, float ry, float rz){
   int i;
   /* Identity matrix */
   for(i = 0; i < 16; i++){
      if( (i % 5) == 0){
         m[i] = 1.0;
      }
      else m[i] = 0.0;
   }

   /* General rotation */
   m[0]  =  cosf(ry) * cosf(rz);
   m[4]  = -cosf(rx) * sinf(rz) + sinf(rx) * sinf(ry) * cosf(rz);
   m[8]  =  sinf(rx) * sinf(rz) + cosf(rx) * sinf(ry) * cosf(rz);
   m[12] =  0.0;
   m[1]  =  cosf(ry) * sinf(rz);
   m[5]  =  cosf(rx) * cosf(rz) + sinf(rx) * sinf(ry) * sinf(rz);
   m[9]  = -sinf(rx) * cosf(rz) + cosf(rx) * sinf(ry) * sinf(rz);
   m[13] =  0.0;
   m[2]  = -sinf(ry);
   m[6]  =  sinf(rx) * cosf(ry);
   m[10] =  cosf(rx) * cosf(ry);
   m[14] =  0.0;
   m[3]  =  0.0;
   m[7]  =  0.0;
   m[11] =  0.0;
   m[15] =  1.0;

}

Egyéb mátrix műveletek

Most pedig jöjjenek az egyéb nyalánkságok. A kamera pozíciójánál a kódban ilyen függvények láthatóak, mint crossproduct meg dotproduct. Mik ezek? Az első a vektoriális szorzat, aminek érdekessége, hogy csak 3 dimenzióban értelmezik.

void crossproduct3v(float *a, float *b, float *result){
   result[0] = a[1] * b[2] - a[2] * b[1];
   result[1] = a[2] * b[0] - a[0] * b[2];
   result[2] = a[0] * b[1] - a[1] * b[0];
}

A másik a skaláris szorzat, ami meglepő módon egy számot ad vissza. A hossz arányos a két vektor által bezárt szöggel, ezért a fények programozásánál is sokszor előkerül.
float dotproduct(float *a, float *b, int size){
   int i;
   float result = 0.0;

   for(i = 0; i < size; i++) result += a[i] * b[i];
   return(result);
}
Ha programunkban egy térhálós modellt elhelyezünk, forgatunk, és még a kamerát is mozgatjuk, több mátrixot kapunk, de hogyan készítsünk egy mátrixot? A válasz a mátrix szorzás. A mátrix szorzásnál a tagok sorrendje nem felcserélhető. Ezt mindenki ki is próbálhatja, hogy mi történik, ha a modellnél az eltolási mátrixot szorozza a forgatásival, vagy fordítva.

A szorzás sorrendje a következő: perspektíva * forgatás * eltolás * kamera. A szorzást a következő kód valósítja meg:

void matrixMultiply4x4(float *a, float *b, float *c){
   int i,x,y;

   for(i = 0; i < 16; i++){
      x = i & 12;
      y = i % 4;
      c[i] = a[x + 0] * b[y + 0] +
             a[x + 1] * b[y + 4] +
             a[x + 2] * b[y + 8] +
             a[x + 3] * b[y + 12];
   }
}

Mondtam, hogy egyszerű lesz, mint a faék. Hozzáértők a kommentekben mindenféle optimalizációt küldhetnek.

Mátrix betöltése shaderbe

A shaderben a mátrix uniform mat4 deklarációval szerepel. Kódunkban a glGetUniformLocation(shader, változónév) segítségével megkapjuk az erőforrás leíróját (egy egész szám), majd ezt felhasználva a glUniformMatrix4fv(leíró, 1, GL_FALSE, matrixpointer) segítségével beállítjuk azt.

Források

http://en.wikipedia.org/wiki/Transformation_matrix

http://en.wikipedia.org/wiki/Rotation_matrix#General_rotations

http://www.songho.ca/opengl/gl_transform.html

 

2 komment

Címkék: programozás opengl

Dr. Scenelove avagy hogyan szerettem meg a Blendert

2011.07.30. 18:39 Travis.CG

A Blendert mindig is egy fekete báránynak tekintettem a 3D programok között, amolyan szegény ember modellezőjének. A különböző demó produkciók elkészítésénél ki is próbáltam néhány programot, hogy megismerjem erősségüket, gyengeségüket. Végül az ízlésemnek leginkább a 3D Studio felelt meg. Ebben kezdtem el tanulgatni a modellezés alapelemeit.

Az eltelt két-három évben ha nem is lettem profi, egyszerűbb modelleket össze tudtam rakni. Aki nagyon kíváncsi, miket is alkottam, az megnézheti az Aeronautism-ban a léghajót, a 2010-ben az Amigát és az EVA pod-ot. Ahogy egyre ügyesebb lettem 3D Studioban, annál inkább mellőztem a Blendert, pedig telepítve van a Linuxos gépemre.

Ahogy a demóink is egyre fejlődnek (még ha ezt a nézők el sem hiszik :-) ) újabb és újabb igényeink lettek, amit alapvetően kétféle módon oldhatunk meg:

  1. A speciális igényeinkhez valamilyen demóeszközt írok
  2. Mások demóeszközeit használjuk saját célunkra
  3. Egy meglévő eszközt ruházunk fel bővítmények segítségével

Demóeszközt eddig is írtam, de mind nagyon speciális volt, főleg különböző formátum konverziókat hajtottak végre. Egy interaktív eszköz elkészítésén is gondolkodtam, de egyrészt sok idő, másrészt olyan egyszerű problémákra sem találtam kielégítő megoldást, mint amilyen a keresztplatformos futtatás.

Mások egyközeivel is kísérleteztünk. Ezek sajnos kevéssé dokumentáltak, főleg saját használatra lettek tervezve, amitől a kezelésük egyéni logikán alapul.

A bővítmény készítés sem volt egyszerű. Először is a legtöbb 3D program Windows alatt fut (1. rossz pont), C++-ban kell hozzájuk fejleszteni (2. rossz pont). Ennek ellenére elkezdtem tanulmányozni a bővítmények dokumentációit.

Így jutottam el ismét a Blenderhez. Python. Ezt a nyelvet sem szeretem jobban, mint a C++-t. Ráadásul még kevésbé ismerem. Viszont amikor négy sorból megkaptam a kamera pozícióját, mindezt a Blenderen belül, akkor úgy döntöttem, hogy érdemes foglalkozni a programmal. A nyelv mélyebb ismerete nélkül pár nap alatt hozzáfértem egy csontváz elemeihez és megkaptam mely csúcspontok tartoznak a csonthoz.

De nézzünk néhány példát! A Blender elindítása után az ablak típusát változtassuk Script Window-ra. A Scripts -> System -> Interactive Python Console menüponttal megkapjuk az konzolt, ahol egyből be is írhatjuk a parancsokat. Arra ügyeljünk, hogy csak akkor tudunk beírni ebbe az ablakba, ha az egérmutató fölötte van. Gyorsan gépelők ne lepődjenek meg: A shift + szóköz billentyű teljes képernyőssé varázsolja az ablakot.

Objektumok:

Az objektumok listája a következő módon érhető el:

for object in bpy.data.scenes.active.objects:
  print object.type

Aki más 3D programban ennél egyszerűbben meg tudja ezt csinálni, az azonnal tudassa velem! Az objektumok helyzetét és forgásszögeit a következő metódusokkal, tagváltozókkal lehet lekérdezni:

object.getLocation() # Az objektum helyzete
object.getEuler()    # A forgásszögek radiánban
object.LocX          # Csak az X pozíció
object.RotX          # X tengely körüli forgatás szöge (fok)
A legszebb az egészben, hogy bármikor segítséget kérhetünk magától a rendszertől!

dir(object)          # Kilistázza a metódusokat és tagváltozókat
help(object)         # Rövid segítség

Az objektumokat is azonnal módosíthatjuk scripteken keresztül. Például forgassuk meg az első alakzatot, ami a kezünk ügyébe kerül:

for o in bpy.data.scenes.active.objects:
   if o.type == 'Mesh':
      mesh = o
      break;
for rad in range(0,360):
   mesh.RotX = rad
   Blender.Redraw()
Az egyik alakzat őrült forgásba fog kezdeni. Remélem sikerült felkeltenem az érdeklődést ez iránt a program iránt. Habár modellezni még jó ideig nem fogok benne, a jelenetek összeállításában biztosan ki fogom használni a képességeit.

Szólj hozzá!

Címkék: programozás demoscene

Madárdal tanösvény

2011.07.25. 22:53 Travis.CG

A Velencei-tó mellett töltött nyaralás alkalmából megtekintettük a Madárdal tanösvényt. A túra Dinnyésről indul, de az idegenforgalmi kiadványokkal ellentétben nem egészen onnan kell indulni, ahol a térképek jelzik. A térkép szerint ugyanis azt mutatja, hogy a Gárdonyi Géza utcán kelet felé tartva a Kossuth utca után kell letérni. Ez nem igaz, a Kossuth utcán kell menni, egészen addig, amíg egy kis díszes tábla nem jelzi, hogy hol kell elhagyni a civilizációt.

Maga a tanösvény szépen rendezett, kiépített, ismeretterjesztő táblákkal van ellátva. Elhelyezkedése is igen szerencsés, mert végig egy szegélytársulás mentén halad. A szegélytársulások két eltérő élőhely határán fordulnak elő, és jellemző rájuk az ott élő állatok keveredése. Tehát egyszerre lehet látni a lápi és mezei madarakat.

Az egyetem alatt az ökológia professzorom azt mondta, hogy déli napsütésben épeszű ember nem keres madarat, mert azok elbújnak a hőség elől. (Mondta mindezt egy nyári terepgyakorlaton 12 órakor) Ennek ellenére most is elkövettük ezt a hibát, mert nem volt kedvünk hajnalban felkelni. Még így is meglepően sok madarat sikerült észlelni. (Igaz, némelyiket csak hang alapján tudtuk beazonosítani)

Egy kilátót is építettek a nádas szélére, ahonnan egy jobb távcsővel be lehetett látni a nyílt vízre, ahol a gázló és vízi madarak kolóniáját láthattuk. Az elkészült képekért elnézést kérek, nem támasztottam le eléggé a gépet.

 A gólyáknak nagyon melegük volt.

 

 Repülő nagy kócsag

Nagy kócsag felszállása

 

 Ilyen és ehhez hasonló táblák nyújtottak felvilágosítást

A madarak azt hitték senki nem látja őket

 

Szólj hozzá!

Címkék: életmód

ISMB-ECCB 3. rész

2011.07.20. 09:26 Travis.CG

Daniel Blankenberg: NGS best practices through Galaxy: Cloudbased variant discovery with visual analytics

Ebben az előadásban a Galaxy rendszert ismerhették meg a hallgatók. A program előnye, hogy ingyenes, felhő alapú megoldást nyújt (természetesen az Amazon használatáért fizetni kell). Az egyetlen szűk keresztmetszet az adatok feljuttatása. Az előadó FTP szervert javasol, mert a kézi feltöltés nagyon sok időt vesz igénybe. A program egyébként ismert eljárásokat tartalmaz, például a variációk megtalálására a GATK-t. Személy szerint úgy gondolom, hogy a Pipeline Pilot felhasználóbarátabb. A húzd és vidd módszerrel összeállított munkafolyamat helyett itt egy webes menü-masszából kell kiválasztani a szükséges lépéseket és az sem segít a helyzeten, hogy rendszeresen átugrik egy olyan ablakra, ahol az eddigi lépések szöveges felsorolása szerepel. Az ablakok elrendezése is elég ijesztő, de az előadó gyakorlott mozdulatai miatt ez nem volt feltűnő. Ha viszont elrejti előlem a GATK összes nyűgjét a különböző formátum konverziókkal együtt, akkor egy próbát megér.

Mivel nem tervezem, hogy több előadásra bemegyek, ezért röviden az általam érdekesebbnek ítélt poszterekről írok egy-két sort.

Jalview 2.7: Nyílt forrású, Java alapú genom nézegető.

Mutalyzer 2.0: Improved sequence variant descriptions from next generation sequencing data and locus-specific mutation databases: www.mutalyzer.nl

SNP4Disease: SNP-betegség adatbázis. http://snp4disease.mpi-bn.mpg.de

UCSC Cancer Genome Browser: Az UCSC-ben immár nem csak "átlagos" genomokat böngészhetünk, hanem rákos genomokat is.

SARUMAN - Using GPU programming for short read mapping: GPU alapú short read mapper Cikk, amire hivatkozik: Exact and complete short read alignment to unihal genome using graphics processing unit (Bioinformatics)

Multi-Image Genome Viewer (MIG): mig.molbiol.ox.ac.uk/mig Bevallom, ez csak a neve miatt tetszett meg. A pószter is egy vadászgépet ábrázolt.

SNPeffect 4.0: molecular and structural phenotyping of human SNPs and disease mutations: Adatbázis, ami SNP-hez rendeli a különböző fehérjeváltozásokat.

SNPsyn: detection and exploration of SNP-SNP interactions: Több SNP egymásra hatását próbálja meg szemléltetni és megkeresni.

GARM - Genome assembly, reconciliation and merging: Szekvencia összeszerelő program, ami hibrid módszert használ.

GenomeView: Egy újabb genom böngésző http://genomview.org

Sequence assembly in the clouds: Búza genomot szereltek össze. Míg sokan azt hiszik, hogy az ember a legnagyobb kihívás a maga 3GB-os genomjával, addig a búzánál 15GB-al kell megbírkózni. Ehhez elosztott rendszer kell.

Chipster genome browser: A Chipsterről meghallgattam az előadást is. Igazából meg kell nézni, mert a poszter arról szól, hogy ők a legjobbak.

Earmark graph approach to de-novo genome assembly: Az oroszok megint kitaláltak valamit. A de-Brujin gráf összeszerelő programok helyett ők az Earmark gráfot javasolják, mert kevesebb memória kell neki és jobb eredményt ad repetitív szakaszokon.

The SMALT software for the efficient and accurate alignment of DNA sequence reads: Újabb mappelő program. http://sanger.ac.uk/software/smalt Olyan gyors, mint a BWA, olyan érzékeny, mint a Stampy, de ahol mégsem olyan érzékeny, ott természetesen elhanyagolható a különbség.

KILAPE - Automated scaffolding and finishing of large, highly repetitive genomes: Ez csak nagyobb darabokat illeszt össze, nem csinál teljes de-novot, de bármilyen de-novo programmal összeeresztve sokkal jobb eredményt kapunk, mintha csak egyedül használnánk a programot.

Inproved in silico regulatory SNP detection facilitates large scale SNP scanning: Megállapítja, hogy az SNP szabályozó régióba esik-e és ez kihat-e a fehérje átírására. http://genomics.csse.unideb.edu.au/is-rSNP

Improving SNV calling sensitivity by combining SNVs reported by different calling tools: Ha SNP-ket akar keresni az ember, akkor legjobb, ha több módszert használ, és a közös variációkat szedi ki. De melyik módszer a legjobb? Azt nem tudják. Próbálják megállapítani, hogy mennyire vegyék figyelembe az egyes programok eredményeit. Azt ők is megerősítik, hogy a GATK újraillesztési lépése megnöveli a megtalálható SNP-k számát, de az új SNP felfedezésében a SAMTools programja jár az élen, még akkor is, ha több fals pozitív eredménye van.

Comparison of short read aligners for ABI Solid platform: Több mappelő programot hasonlítottak össze és az jött ki, hogy a BWA a legjobb, a PerM pedig a legrosszabb.

Két pószterben is benne voltam, nem csak egyben, mint ahogy korábban hittem. Ez több feladatot rótt rám, mert én voltam az egyedüli jelenlévő előadó mindkettőben. A kollégáktól próbáltam segítséget kérni, csak annyira, hogy küldjék hozzám az érdeklődőket. Ezt meg is ígérték, de nem tették. Igen, kiérdemeltem a balek négyzet plecsnit. Ezért egyszer itt álltam, egyszer ott. Elég sok embert érdekelt, aminek örülök. Röviden leírom őket:

Az első pószter arról szól, hogy a legtöbb mappelő program illesztését felhasználva a GATK nem képes olyan polimorfizmusokat megtalálni, ahol a két nukleotid változás közvetlenül egymás mellett van. A második pedig arról szólt, hogy egy kodon alapú mappelő algoritmus jobban teljesít exomok esetén, míg a hagyományos, nukleotid alapú jobban boldogul homopolimer szakaszokon.

Rengeteg könyvkiadó cég is képviseltette magát és a konferencia alatt 20%-al olcsóbban lehetett megvenni sok könyvet. Azt hiszem könyvre bármennyi pénzt el tudok költeni, ezért szerencse, hogy nem volt nálam elég pénz, mert romlásba döntöttem volna a családi kasszát.

Összességében elmondható, hogy a legtöbb kiállító a gyorsaságra helyezte a hangsúlyt. Két kiállító FPGA gyorsítást ajánlott. Megtekinthettünk egy PCI foglalatba illeszthető FPGA gyorsító kártyát. Az előadások is arról szóltak, melyik algoritmus gyorsabb. Még tőlem is megkérdezték, hogy milyen a kodonos illesztő sebessége.

Végezetül egy kis poén. Az egyik kiállító ingyen pólókat osztogatott. Az érdekes az egészben az volt, hogy a cég logója nagyon kicsi volt, viszont egy hatalmas "Blast the unknown" és "Altschul et. al 1337" felirat volt az elején és a hátulján. Mondanom sem kell, vitték, mint a cukrot. Ekkor a cégünktől valaki megkérdezte, hogy ez milyen cikkre hivatkozik. (A válasz: Blast) Körülbelül olyan volt, mintha egy Forma 1 nagydíjon valaki megkérdezi, ki is az a Schumacher?

Szólj hozzá!

Címkék: cloud computing bioinformatika

ISMB-ECCB 2. rész

2011.07.19. 00:31 Travis.CG

A második nap először a posztereket néztem át reggel. A poszter szekció is két részre volt osztva, ezért azokról egy külön részben fogok beszámolni. A mai nap nagy dilemmában voltam, mert több előadásra is szívesen mentem (lógtam) volna, amelyek egy időben voltak.

Scott Markel, Ruth Dunn: Analyzing next gen sequencing data with Pipeline Pilot


Ez egy viszonylag hosszabb előadás volt, ahol a Pipeline Pilot nevű keretrendszert mutatták be. A többi bioinformatikai keretrendszertől eltérően ez egy elosztott megközelítést használ, ahol a lokális adatok a feldolozási lépések során egy távoli szerverre kerülnek, majd a további elemzések ott folytatódnak, csökkentve a saját gép terheit. Azért kíváncsi lennék, hogy egy 300GB-os humán short read adat mennyi idő alatt mászik fel a szerverre és hogyan kezelik a feltöltés során fellépő hálózati problémákat. A bemutató során csak pici teszt adatokkal játszottak az előadók, ahol természetesen minden tökéletesen ment.

A másik nagyon szimpatikus megközelítés a munkafolyamatok összeállításának lehetősége. Gyakorlatilag képzeljünk el, hogy a különböző programok be és kimeneteit összekapcsoljuk egy grafikus felületen. Az előadás végén megkérdeztem, hogy segít-e a program a hibás adatok felderítésében, amire azt a választ kaptam, hogy igen. Erről azért a gyakorlatban is szívesen megbizonyosodnék, mert a Bioscope tapasztalatom kétkedésre int.

Az előadásnak volt egy másik érdekes eseménye is. Mellettem egy ember tollal, papírra jegyzetelt!

Susan Gottesman: RNA structure: Bacterial small RNAs in regulatory networks.


Részletes és mélyreható bemutatót láthattunk az E. coli rpoS gén kisRNS-en keresztül történő szabályozásáról. A kisRNS-ek különböző stresszhelyzetben aktíválódnak és bonyolult szabályozási folyamatokon keresztül aktiválják vagy represszálják a géneket. Egy kisRNS több gént is szabályozhat és több kisRNS szabályozhat egy gént.

Peter Rice: EMBOSS: New developments and extended data access


Az EMBOSS egy olyan programcsomag, ami sokszor kihúzott a bioinformatikai slamasztikából. Ennyit megérdemelnek, hogy megnézzem az előadásukat. Az új fejlesztés az adatbázisokhoz való kapcsolódás. Beépített adatbázisok is vannak. Van natív Windows-os verziója is, amit alig tesztelnek, úgyhogy el lehet felejteni a cygwin-t. Az új generációs szekvencia adatok támogatása későbbre tolódott. Szomorú hír, hogy az EMBOSS-nak otthont adó EBI ez év december végétől csak tárhely formájában támogatja a programot. Az előadó még nem tudja, mit fognak tenni.

Eric Tannier: Mapping ancestral genomes with massive gene loss: a matrix sandwich problem


Ősi genomokat próbálnak előállítani a mai leszármazottakból, a gének módosulásait figyelve. A probléma akkor van, amikor a két leszármazott más-más géneket tartalmaz. Nem tudni, hogy melyiket örökölte és melyik keletkezett újonan. Az előadó mátrixokat olvasott fel az előadás nagy részében, amitől nagyon unalmas volt.

Eija Korpelainen: Chipster 2.0: User-friendl NGS data analysis software with interactive genome browser


Egy újabb világmegváltó programcsomag. Elsősorban microarray adatok feldolgozására tervezték, de időközben kapott EMBOSS integrációt, és most a 2.0 verzióban újgenerációs adatokat is képes feldolgozni. Tartalmaz felhő alapú modult is, a Hadoop-BAM-ot, ami egy BAM fájlt darabol, hogy mapreduce-os környezetben fel lehessen dolgozni. Egy genom böngészőt is tartalmaz, ami kevés memória mellett is rendezi a BAM fájl rekordjait a könnyű megjelenítés végett. Az előadás külön érdekesssége volt, hogy a Windows-os laptop nem érte el a Wi-Fi hálózatot, ami miatt egy Machintosnak kellett megmentenie az előadást.

Paul Horton: Next-generation genome alignment with LAST


A Blast a múltté. Az adaptív seed technikának köszönhetően készítettek egy olyan lokális illesztőt, ami gyorsabb és érzékenyebb, minat a BLAST, miközben a repetitív szakaszokon jobban teljesít, mint a nagy előd. Másképp kezeli az indexet, mint a Blast. Egy suffix tömböt használ, ami kevesebb tárhelyet emészt fel, mint egy hash alapú index. Állítólag két gerinces genomot néhány óra alatt illeszt egy átlagos PC-n 2GB memóriával. Egy próbát megér: http://last.cbrc.jp/

Ma is álltam és vártam, hogy az embereknek elmondhassam cégem profilját. Senkivel nem kellett beszélnem. Arra a pár emberre, aki jött, lecsaptak a főnökök, én meg nem tiltakoztam. A munkatársaim pósztere mellett is ácsorogtam, mert ők nem akartak olyan sokat ácsorogni a saját pószterük mellett, úgyhogy megkaphatom a balek plecsnit. Annak ellenére, hogy a nevem nem szerepel rajta és a nullához közelítő mennyiséget dolgoztam vele, elég jól elmondtam annak a három embernek, akik odatévedtek. Ez igen rossz arány egy több ezres nemzetközi konferencián.

Vicces volt, ahogy a háromból kettő kínai kutató volt, akik minden kérdésre adott válaszomat hatalmas "hoo"-val kísértek. Mikor azt mondtam nekik, hogy a short readek referenciához illesztésére saját fejlesztésű programot használtunk, kitört belőlük egy "AHHHHH" mély torokhangon, mintha puszta kézzel vágtunk volna ki egy fát.

Este részt vehettem egy céges munka vacsorán is. A két cég főnökei jól elvoltak a repülőgépes, szállodás történetekkel. Hiába, egy kozmopolita életben ezek az események. Én egyfolytában arra gondoltam, mennyivel hasznosabban tölthetném ezt az időt.

 

Szólj hozzá!

Címkék: bioinformatika

ISMB-ECCB 1. rész

2011.07.17. 20:22 Travis.CG

A mai poszt egy bécsi bioinformatikai konferenciáról érkezik. A cég, ahol dolgozom kiállít és előadást tart, én személy szerint poszterrel is jelen vagyok. A bécsi konferencia központban van a rendezvény, ami egy hatalmas épület, felszerelve minden technikával, amivel egy konferenciaközpont fel lehet szerelve. A legutóbbi konferencia óta, ahol voltam, sok minden változott. Régen még a regisztrált tagok tollat és jegyzetfüzetet kaptak. Ma már kevésbé trendi bioinformatikusok laptoppal, a trendik tablettel rohangálnak és jegyzik fel az előadáson elhangzott értékes mondatokat.

Apropó előadások. Sajnos csak kiállítói regisztrációm volt, ami nem tette lehetővé, hogy az előadásokat is megtekintsem, legalábbis elméletileg. Gyakorlatilag a kártyámat megfordítottam, hogy ne lássák rajta a nagy vörös betűkkel kiírt "Exhibitor only" feliratot, szépen mosolyogtam az ajtóknál álló emberekre és máris bent voltam.

A következő előadásokat tekintettem meg:

Andre Altman: vipR: Variant identification in pooled DNA using R


Az előadás lényege az volt, hogy a vizsgálatok során, ahelyett, hogy egyenként klón könyvtárakat készítenének a vizsgálat populációkból, ami idő és erőforrás igényes feladat, a mintákat összekeverik, és a kevert mintából készítenek könyvtárat. Elvesztik az egyéni különbségeket, de cserébe a genetikai variációk jobban csoportosíthatóak. Az előadó azt a példát hozta, hogy egy fehérje diszfunkciójához különböző mutációk vezethetnek, amelyek nem feltétlenül egy helyen alakulnak ki. Az előadás többi része arról szólt, hogy az ő megoldásuk természetesen a legjobb, leggyorsabb.

Samuel Flores: A structural and dynamical model of human telomerase


Bevallom, ebből az előadásból nem értettem semmit. Először azt hittem rossz helyen vagyok, mert az előadó az RNS másodlagos szerkezetéről beszélt, majd a fehérjék szerkezetéről. Az előadás egy hatalmas termet kapott, amit nem sikerült halgatósággal megtölteni, akik végigszenvedték, azok kérdés nélkül távoztak. Lehet, hogy nem voltam egyedül az értetlenségemmel?

Benoit Ballester: Five vertebrate ChIP-seq reveals the evolutionary dynamics of transcription factor binding


Szerintem a legjobb előadás volt ezen a napon, az általam látottakból. Öt gerinces faj kromatin immunpercipitációs vizsgálatával figyeltek konzerválódott transzkripciós faktor kötőhelyeket. Megállapították, hogy milyen mutációk vezettek ahhoz, hogy a transzkripciós faktor egyes fajokban működésképtelen legyen. Figyelték azt is, hogyan változnak bizonyos transzkripciós faktorok más fajokban. Eredményeik még publikálatlanok, de biztosan érdekes cikk fog születni belőle.

Attila Bérces: Cloud computing for computational biology


Magyar előadó is volt, már csak ezért is meg kellett nézni. Arról szólt, hogy nincs mese, a felhő jelenti a megoldást a bioinformatika minden problémájára, mert olcsó, nagyobb teljesítményű. Bármikor leakaszthatunk egy 64GB RAM-al ellátott virtuális gépet, ha szükségünk van rá. Egy hallgató megjegyezte, hogy neki páciensek adataival kell dolgozni, a felhő alapú megoldások milyen biztonságot garantálnak neki? A válasz az volt, hogy még semmilyet.

Attila Bérces: Accurate genome variant detection


A második előadást is meghallgattam. Egy olyan programot mutatottak be, ami mindennél jobban illeszti az újgenerációs szekvenciákat referencia genomhoz. Eddig SOLID platformhoz volt használható, de már készül az Illumina platformhoz szánt változat is. Szokásos táblázatok, hogy ez a jó, minden más semmit sem ér.

George Vacek: Efficient graph based assembly of short-read sequences on a hybrid core architecture


Az előadás a felhő alapú szolgáltatásokkal ellentétben a brutális gépi megoldást preferálja. Egy FPGA foglalatos gépről van szó, ami egyesíti egy PC hatalmas memóriáját és egy FPGA sokmagos gyorsaságát. A cég elsősorban ezen gépek értékesítésével foglalkozik, a szekvenciák összeszerelésére Velvetet használnak, amit kiegészítettek egy saját programmal, hogy a Velvet memória éhségét csökkentsék. Implementálnak más algoritmusokat is eme szörnyeteg alá.

Paul Medvedev: Error correction of high-throughput sequencing datasets with non-uniform coverage


Nagyon sokan nézték ezt az előadást. A teremben az állóhelyek is elfogytak. Egy élelmes kutató kinyitotta a szomszédos termet, majd vigyorogva leült, de mikor az ajtót is elállták előle, biztos arcára fagyott a mosoly. Az előadás lényege, hogy a readeket a fedettség függvényében csoportokba rendezik és nézik, hogy az egy csoportba tartozó readek milyen eltéréseket mutatnak és ezeket a többi read (és nem a referencia alapján) korrigálják. Az számomra továbbra sem tiszta, hogy a heterozigóta SNP-ket hogyan nem javítják ki.

Egyéb látnivalók


A regisztrációs kártya nyakba akasztható volt. Az egyéb információkat (valaki előadást tart, csak egy napra váltott jegyet) kis matricákkal oldották meg, amelyek lelógnak a kártya alatt. Erre egy lapáttal rátett az egyik kiállító is, aki pont ilyen matricákat osztogat azoknak, akik náluk publikálták egy cikküket. El lehet képzelni, hogy milyen hosszú élettörténetet viselhetnek egyesek a nyakukban.

Egy kisebb kiállítás is volt, ahol biológiával kapcsolatos művészi alkotásokat lehetett megtekinteni. Az egyik festményen fehérje térszerkezetek körvonalai voltak kiegészítve arra, amire leginkább hasonlítottak. Volt egy BioBlender nevű programmal készített ioncsatorna és sugárkövetéssel előállított fehérje másodlagos szerkezet.

Közben a cég kiállított standján is beszéltem az emberekkel. A nyomulós, mi vagyunk a legjobbak szöveg helyett inkább azt próbáltam mondani, hogy van akadémiai liszensz, a termékünk kipróbálható. Ezzel az emberek saját maguk eldönthetik, hogy a programunk jó-e vagy nem.

Holnap lesz a második nap, és újabb bejegyzés.

 

Szólj hozzá!

Címkék: cloud computing bioinformatika

Fotóállvány javítás

2011.07.01. 23:07 Travis.CG

A filmekben a ragasztószalag amolyan univerzális javító alapanyag. Bármilyen javítási feladatot meg tudnak oldani vele. Nekem is van olyan anyagom, amivel bármit megjavítok. Ez pedig a két komponensű epoxi gyanta.

Előnye, hogy bármilyen külön álló darabokat végérvényesen egybe lehet forrasztani vele, ami azután hő, fagy, sav és még ki tudja mennyi hatásnak ellenáll. A fotós állványom egy éjszakai bevetés során megrongálódott, aminek hatására az egyik teleszkópos lábát nem lehetett semmilyen magasságban rögzíteni.

Az ismerőseim mind azt tanácsolták, hogy vegyek újat, de szükségtelennek tartottam, hiszen még volt két jó lába.

Abban biztos voltam, hogy ha egy csavart bele tudnék operálni, akkor azzal megszoríthatnám a lábat. A terv az volt, hogy fúrok egy lyukat, amibe egy anya csavart rögzítek epoxi gyantával. Így sikerült:

 Arra kellett csak vigyáznom, hogy a gyanta bele ne folyjon az anyába és az állvány lábához, mert akkor örökre fix hosszúságú lesz. Ezt kis papírdarabokkal oldottam meg.

Szólj hozzá!

Címkék: életmód barkácsolás

Bulvár tudomány

2011.06.18. 18:23 Travis.CG

Nem tagadom, hogy a mindennapi világ történései alól kivonom magam. Legalábbis megpróbálom. Ezért én csak utólag hallok vulkánkitörésekről, meteorokról, árvízekről, Amerikában tevékenykedő orosz kémekről vagy esetleg járványokról.

A mostani eset sem azért jutott tudomásomra, mert a napi sajtót olvasom, hanem mert egy igen érdekes jelenség tűnt fel vele kapcsolatban.

Mint az ismeretes, Németországban járvány tört ki, a fertőzést egy Escherichia coli nevű baktérium egyik törzse okozta. A kínai BGI saját állítása szerint három nap alatt megszekvenálta a baktériumot és a Twitteren keresztül azonnal szétkürtölték a világban. Annyira siettek, hogy a szekvenciát nem is a nagy genom adatbázisokba töltötték fel először, ahogy türelmes kutatókhoz illik, hanem saját FTP oldalukra.

Feltételezem nem sokat aludtak, mert mindjárt szekvencia analízisnek vetették alá a nyers szekvenciákat. Június 2-án már fel is rakták oldalukra, mit találtak. Az eredmények alapján elkezdtek kiteket gyártani, hogy megkönnyítsék a baktérium detektálását.

Június 7-én már készen volt az a PCR gyors teszt protokolja, amivel 2-3 óra alatt ki lehet mutatni, hogy a veszélyes kórokozóról van-e szó. Számítógéppel leellenőriztek 4547 törzset, ami nem nagy szám, tekintve, hogy az E. coli genomja igen kicsi, kitömörítve 5MB helyet foglal. Ha le is töltötték az összes genomot, akkor is kb. 22 GB helyet foglalt. Viszont kísérletesen 93 törzset is megnéztek. Egy kisebb PCR készülékben 25 cső fér el, a nagyobbakba, ha mikroplate-ba rakják a mintát, akkor 96. Futtatáskor egy csőbe csak reakcióelegyet is tesznek, minta nélkül, hogy megnézzék, történt-e szennyezés. Akkor is két üres hely maradna egy plate-en. Nem hiszem, hogy üresen hagyták volna. Azt tudom elképzelni, hogy azok a minták nem adtak eredményt, vagy valamit elrontott, aki összemérte az oldatokat :-) (Bár külföldi laborokban nem ritka a pipettázó robot) Természetesen az is lehet, hogy ott egyéb kontroll oldatok voltak. Akár hogy is történt, akkor is csak egy PCR-t használtak, mert azt nem tartom valószínűnek, hogy ne legyen 93-nál több E. coli mintájuk.

Visszatérve a történetünkhöz. Június 16-án elkészült a teljes összeillesztés. Itt valószínűleg már nem rohantak, mert egy baktérium genom összeszerelése nem tart 9 napig egy kellően erős számítógéppel. Itt valószínűleg a minőségre mentek rá.

Ugyanakkor létrehoztak a Githubon egy csomópontot, ahol gyorsan meg lehet osztani a további eredményeket.

 Csak, hogy érezzük, milyen gyorsan jöttek ezek az eredmények. Mikor nekem E. colit kellett szekvenálnom (2004), akkor kb. 500 bázispár távolságra "láttunk el". Ezt kb. egy hét alatt kaptuk meg a szekvenáló cégtől. Mivel spóroltunk, ezért a szekvenálási hibákat kézzel javítottuk (mert a PhD-s olcsóbb, mint újból megszekvenálni a hibás részeket). Akkor már megvolt az E. coli egyik törzsének a genomja, tehát ha az alapján tervezem meg a primereket, akkor kb. 11 ezer szekvenálásra lett volna szükség. (Ebbe nem számítottam bele a palazmidokat) Ha nem is lett volna egy hét minden egyes szekvenálás, hanem csak egy óra, akkor is egy évig kellett volna dolgoznunk rajta.

Egyes hírek azt sugallják, hogy ezt csak a kínaiak tudják megtenni, mert ők sokan vannak, jól felszereltek és nagyon akarnak, de nem erről van szó. A felszerelésük tényleg jó és minden bizonnyal nagyon akartak, de a nagy ember mennyiségről nem vagyok meggyőződve. A szekvenáláshoz használt Ion Torrent készüléket egyetlen embernek kell kezelni. A PCR szintén egy emberes készülék. A de novo szekvencia összeépítést leszámítva az összes bioinformatikai munkát el lehet végezni egy közepes PC-n. Ehhez is csak egy ember kell. De ha az Amazonon bérelnek egy sok memóriás gépet, akkor egy laptop is elég a munkához.

Nyilván azért is siettek, mert sok beteg emberről van szó, de észrevehetjük, hogy nem a szokványos tudományos publikálást választották. Ha Nature cikket írtak volna (mint ahogy egészen biztos vagyok benne, hogy fognak), annak a megjelenése több hónap is lehet. Annyi idő elteltével nem lenne a gyorsaságuknak hírértéke. Gyorsan lecsaptak egy aktuális eseményre és nagyon ügyesen meglovagolták a sikert. Hiszen az már egyik hírcsatorna sem említi, hogy miután kihozták a szekvenciákat június 2-án, azóta párszor még frissítették azokat. A gyorsaság miatt még arra sem jutott idejük, hogy a honlapjukon a legalapvetőbb szóelválasztási hibákat kijavítsák.

Tehát egyfelől ott a tény, hogy gyorsan el kell juttatni az információkat azokhoz, akik dolgozni tudnak vele (az első eredmények megmutatták, hogy felesleges bizonyos antibiotikumok alkalmazása, a kórokozóban található rezisztencia gének jelenléte miatt), valamint jelezni kell, a többi kutatólaboratóriumnak, hogy mi már itt tartunk, ti ne ezzel foglalkozzatok. Másfelől egy Github miként tudja garantálni, hogy BGI csomópontjához csatlakozók mindegyike szakember-e?

Én személy szerint örülök, hogy egy okostelefon segítségével a Twitteren keresztül bárhol értesülhetek egy tudományos eredmény születéséről. Azt is szeretem, hogy bár nem vagyok az akadémiai szféra tagja, mégis közel mehetek az eredményekhez, mintha csak egy látogatóknak felállított üvegfalon keresztül nézném a laboratóriumban dolgozókat. De azon is elgondolkodom, hogy hol jobb kutatni? Egy vásártér kellős közepén, ahol a kofa hangosan ecseteli, hogy mit pipettázik a kutató, vagy egy laboratórium magányában? Ezzel a nagy nyíltsággal nem vesztünk-e el valamit?

Szólj hozzá!

Címkék: filozofálás bioinformatika

süti beállítások módosítása