Ú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.