HTML

Az élet kódjai

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

Friss topikok

Intézeti felhőcske

2013.10.22. 18:51 Travis.CG

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

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

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

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

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

A tudás összegyűjtése

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

Fájlok tárolása

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

Szekvencia homológia

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

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

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

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

A genom vizualizálása

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

Kód verziókövetés

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

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

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

4 komment

Címkék: cloud computing bioinformatika

A bejegyzés trackback címe:

https://cybernetic.blog.hu/api/trackback/id/tr825554524

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Kalle 2013.10.22. 20:00:46

Respekt és tisztelet. Ilyesmit tervezünk mi is, ha egyszer végre a szerverünket nem 6 Mbit/s lehet majd elérni, bár én szkeptikus vagyok. Nálatok használja is valaki a fejlesztéseket, vagy csak úgy l'art pour l'art?

Travis.CG 2013.10.23. 22:34:06

A Wikit és a Blast szervert igen. A genom böngészőt az elején használták, de manapság nem. Az FTP-t mérsékelten. Kicsit erőltetni kell, és akkor használják.

Kalle 2013.10.24. 13:33:09

Én eléggé megszenvedek vele, hogy a biológusokkal egyszerűen lehetetlen bármit is elérni, pl ragaszkodnak százéves lasergenekhez, ami még fastát sem képes megnyitni, ha az egynél több szekvenciát tartalmaz. Sam/bam fájlt egyszerűen nem tudok velük megnézetni, mert ha az említett lasergene/másik régi és inkompatibilis programocskájuk nem tudja megnyitni, nem hajlandók tudomást venni róla. Könyörgöm nekik a Tabletért, de nem hajlandóak használni, és itt nem öreg rókákra gondolok.

Én is egy ilyen saját felhőben látnám a megoldást, csak attól félek, hogy annak sem lenne értelme, mert arra sem vennék a fáradságot.

Travis.CG 2013.10.27. 22:47:58

Igen, ez egy nehéz probléma. Fontos hangsúlyozni az eszköz előnyét és minél többször demonstrálni. Ha riportot írsz/előadást tartasz, tegyél bele Tabletes képet. Az átszoktatás lassú folyamat, nem is érdemes siettetni.

Nekem könnyű dolgom van, mert egyrészt támogatnak, másrészt sok igény eleve a biológusoktól jön.
süti beállítások módosítása