HTML

Az élet kódjai

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

Friss topikok

Rossz beidegződések a bionformatikában

2018.10.30. 23:10 Travis.CG

Úgy általában a kutatásról elmondható, hogy nem jellemzi egységes megoldási rendszer, még olyan alapvető problémákra sem, amire egy céges környezetben esetleg évek óta van bejáratott protokol. Ezért van az, hogy míg egy dolgozó egyik cégtől átmegy egy másikba, ismerős szoftverekkel, környezettel fog találkozni. (Vagy legalábbis hasonlóakkal.) Ellenben minden kutatólabor kialakítja a saját megoldásait minden élethelyzetre, amit ráerőltet tapasztalatlan szakdolgozókra, PhD hallgatókra és ezek alternatív ismeretek híján terjednek, mint a ragály.

Most összeszedek pár olyan rossz beidegződést, amivel az utóbbi időben találkoztam és mutatok példákat, hogyan lehet elkerülni (vagy kijavítani) azokat. A célom nem az, hogy a saját rossz beidegződéseimet terjesszem (mert ezek is biztos vannak), csupán az, hogy választási lehetőséget az olvasóknak.

Kísérletezés a programkóddal

Elég ritka, hogy valaki egyből leírja a tökéletesen működő szkriptet. Általában készítünk egy próba függvényt/rutint és megnézzük, működik-e. Általában nem működik, de ez részlet kérdés. Esetleg másik, hasonló problémára megpróbáljuk egy létező kódunkat használni, de egy kis módosítással.

Szimptómák

Megjelennek a .1 és .2 kiterjesztésű állományok. Esetleg orig, bak és egyéb szörnyűségek (a végső csapás, mikor már a dátumot kénytelenek beleírni). Furcsa függvények maradnak a kódban, amit semmi nem hív meg. Élettelen változók tömegei hevernek szerteszét. A legrosszabb példa, mivel jelenleg dolgozok itt van. Egyik fájlból több, mint 600 sort töröltem ki, funkcióvesztés nélkül! Döbbenet, amit ott találni!

Megoldás

Verzió követő rendszer. Mindegy, melyik, de ha publikálni akarjuk a kódot, akkor GitHub/GitLab/Bitbucket elkerülhetetlen (és miért ne akarnánk publikálni a kódot? A tudományban beszélnek valami reprodukálhatóságról, vagy miről.). Csinálhatunk millió verziót és nem kell félni, hogy bármi is elveszik. Alternatív lehetőségeket próbálhatunk ki anélkül, hogy veszélyeztetnénk kódunk struktúráját.

Kommunikáció

Tartani kell a kapcsolatot a csoport tagjai között, még akkor is, ha valaki konferenciára megy, otthonról dolgozik, átugrik-a-másik-laborba-de-öt-perc-múlva-itt-lesz-és-nem-láttuk-már-két-napja. Erre ugye ott van az intézeti/egyetemi email, ami legtöbbször funkcionalitásában elmarad a GMailtől.

Szimptómák

Elkezdik használni mindkét levelező rendszert és elszaporodnak az olyan jellegű levelek, hogy "ezt most a másikra küldtem", meg "küldd el még egyszer". De olyannal is találkoztam, hogy Facebookon ment minden közlés, mondván "úgyis azt nézi mindenki". Aztán két macskás videó és egy torta recept közé beékelődött egy genom szekvenálási eredmény.

Megoldás

Erre igazából nincs mindenre jó megoldás (vagy legalábbis még nem találkoztam vele). De az biztos, hogy a szabadidős és munkahelyi szolgáltatásokat el kell különíteni, mást nem, szeparált regisztrációval. A másik fontos, hogy egy csatornán menjen a kommunikáció! A JIRA, bár fizetős, mindent tud, ami egy projekt nyomon követéséhez kell. A Slack lebutított verziója ingyen is elérhető. De aki ingyen cuccot szeretne, installálhat fórum motort is saját szerverre.

Programnyelvek

A régi mondás, mely szerint minden programozási nyelven lehet BASIC programot írni, igaz. Elméletileg bármelyik Turing-teljes nyelven megoldhatóak a problémák, azért mégis érdemes olyan nyelvet használni, amivel kevesebb problémánk van.

Szimptómák

Túlbonyolított, Halálcsillag-jellegű programok, ahol a funkciók nagy része nem a problémát kezeli, hanem nyelvi hiányosságokat pótol. Példának okáért nézzük meg ezt. Egy Visual Basic program. A klikkelős alkalmazásoknak megvan a maga helye, de nem ott, ahol nagy mennyiségű adatot kell feldolgozni. A program diszkréten csipog, amikor készen van és az eredményt a vágólapra másolja. Ha elmúlasztjuk a csipogást? Nos, akkor gondolkodhatunk, hogy a vágólapon található eredmény a mostani, vagy a korábbi futásból származik. Nem véletlen, hogy a Galaxy sem egy elterjedt alkalmazás a bioinformatikában.

Sajnos néha a nyelv fejlesztői is hibásak, amikor olyan feladatok elvégzését is lehetővé teszik, amit nem kéne. Azért, mert R-ben lehet XML-t feldolgozni, még nem jelenti, hogy abban kell csinálni. Láttam ilyet. Szörnyű volt.

Megoldás

Több programozási nyelv ismerete. A leggyakoribb kifogás, hogy nincs rá idő. De több száz soros, érthetetlen vackot írni van? Nem kell profinak lenni benne, de addig érdemes eljutni, hogy megértsük a nyelv mögött rejlő filozófiát. Azután eldönthetjük, hogy ezt el akarjuk-e sajátítani.

Adat tárolás

A nagy áteresztő képességű eljárások (szekvenálás, microarray, mikroszkópia) iszonyú mennyiségű adatot adnak a kutatók kezébe. Ezek tárolása a kutatás szempontjából létfontosságú.

Szimptómák

Az adatok szanaszét vannak, több gépen, elszórt könyvtár szerkezetben. A kommunikációs csatornák ilyen párbeszédekkel vannak tele:
- Hol vannak a februári adatok?
- A 3-as gépen, a data mappában.
- Ott nincs data mappa.
- Ja, tényleg. Ott az adatok3-ban lesz.
- Mi van az adatok2-ben.
- Semmi.
A fájlnevek metainformációkkal vannak tele, mint például human_skincancer_youngAndOld_test. Természetesen egységes konvenció nélkül, mert szakdolgozók, PhD hallgatók jönnek-mennek.

Megoldás

Az adatok legyenek egy helyen, de rendelkezzenek biztonsági másolattal. Legjobb, ha van egy dedikált gép vagy NAS szerver. Személy szerint az USB-s tárolásnak nem vagyok híve, mert igaz, hogy könnyű cipelni, de elhagyni és leejteni is. A fájloknevek legyenek rövidek és minden egyéb információt róluk adatbázisban tárolni. Ezt most nehéz leírnom, de a fájlnevekbe kódolt metainformációknál még egy Excel táblázat is jobb.

Végszó

Természetesen ezeknek csak akkor van értelme, ha több ember is el akarja kerülni a fenti problémákat. Vannak, akik annyira hozzászoktak a rossz szokásokhoz, hogy nem tudnak nélkülük élni. Hiába mondják nekik, hogy húzzák fel a redőnyt, kint süt a nap, ők továbbra is dinamós zseblámpával közlekednek a lákásban. Az ilyen hozzáállás miatt könnyű ilyen cinikusan hozzáállni a problémákhoz, de amíg tehetjük, álljunk ellen.

3 komment

Címkék: bioinformatika

A bejegyzés trackback címe:

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

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.

sdani 2018.10.31. 10:45:48

Egyfajta "best practices" gyűjtemény bioinformatikusoknak nagyon hasznos lehet...

Ami most hirtelen eszembe jut: amikor elkezdtem dolgozni a Sangerben totál zöldfülűként, attól kaptam agybajt, amikor variánsok annotációját kellett megismételni kb. fél év elteltével, és jöttek, hogy miért nem pont ugyanaz az output ugyanarra a variánsra... Persze eltelt fél év az Ensembl közben frissítette a dbSNP és a GENCODE adatszettet, jóhogy egyes dolgok megváltoztak közben. Azóta, ha bármilyen file-t generálok, a headerbe odateszem a felhasznált adatbázisok verzióját.

A verziókövetés király dolog, sajnos nagyon kevesen használják és akik használják azok is főleg forráskód követésére. Pedig akármi lehet egy repo-ban: az egyik utóbbi cikknél létrehoztam egy repot a cikk ábráknak. Így ha a főnök aktuális zseniális ötletéről kiderül, hogy nem is olyan zseniális, simán vissza lehetett térni bármelyik korábbi verzióra (kóddal és ábrával együtt).

Ó és annyi, meg annyi ilyesmi van még. :D

Travis.CG 2018.10.31. 12:14:06

Sőt, GitHubban már projekt management funkciók is vannak. A Sangerben például a Cosmic használja őket az adatbázisuk fejlesztési irányvonalának meghatározására.

sdani 2018.11.01. 10:14:04

@Travis.CG: Nohát, nem is tudtam, hogy ilyen van... bár ahogy elnézem ezek a komponensek fizetősek, mondjuk nem valami egetrengető összegekről van szó.

Ha csoportvezető lennék, egy próbát mindenképpen tennék. Nyilván kicsit nagyobb az overhead (ez hogy van magyarul?), de valószínűleg az átláthatósággal többet nyer a csoport. (néha rettentően nehéz rekonstruálni pár éves (vagy akár hónapos) döntések körülményeit) Itt vissza lehet keresni a megvelelő ticket-et, miért gondoltuk, hogy x paramétert megváltoztatunk, egyből ott a branch, össze lehet hasonlítani a kódot.... erre talán korlátozottan a github-os issue tracker is alkalmas.

A Sanger-ben (érzésem szerint) elég profin nyomtuk: scriptek verziókövetése, közösen fejlesztett jupyter notebook-ok bash/R/Pyton kóddal és dokumentációval. De utólag visszatekintve még ezen is lehetett volna mit javítani.
süti beállítások módosítása