HTML

Az élet kódjai

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

Friss topikok

  • Travis.CG: @webhauser: Én nem vagyok jó programozó. Nem vennéd sok hasznomat. (2025.09.18. 10:26) T0ad 2025
  • Travis.CG: Annyiban én is hibás vagyok, hogy könnyen előjönnek belőlem negatív posztok, ezt akartam ellensúly... (2025.05.22. 19:34) Ne csak a rosszat halljátok
  • 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

Négy százalék tudomány

2020.09.07. 22:05 Travis.CG

Nagyon érdekel a sötét anyag kutatás, és nem csak azért, mert vagyány neve van. Van egy olyan rossz tulajdonságom, hogy amihez nem értek, azt túlmisztifikálom. Az ismeretterjesztő könyvek viszont segítenek helyre tenni a dolgokat. Ezért is olvastam el Richard Panek, 4% univerzum című könyvét.

A könyv a kozmológia hőskorának bemutatásával kezd, amikor felfedezték a kozmikus háttérsugárzást, később az univerzum tágulását. A könyvben a tudományos rész viszonylag kevés, sokkal többet mutat be az egymással versengő kutatókról, és azok személyiségéről. Ezt az első fejezetekben még átszövi egyfajta pátosz, de ahogy halad előre a könyv, és közelítünk a jelenhez, egyre inkább olyan lesz, mint egy OTKA bírálat kulissza titkai: Tudod, hogy korrupt a rendszer, de még így is arcon csapnak a tények. Csak itt azzal szivatják egymást a kutatók, hogy nem engedik a Hubble űrtávcsövet használni a konkurenciának.

Mindezt talán valami hatalmas tudományos célért teszik? Nem, csupán azért, hogy néhány tizedesjeggyel pontosabban kiszámolják azt a kozmológiai állandót, amit az elméleti fizikusok próbáltak elfelejteni. Ezen a ponton, határozottan gyűlöltem már a könyvet. Mert míg más tudomány területen kifogásolják, ha a kitűzött célok nem elég előre mutatóak, a könyv azt sugallta, hogy az Egyesült Államok csillagászai egyre nagyobb berendezéseket építenek, egyre több pénzt vernek el, miközben igazolják azt, amit egy galamb ürülékkel teleszórt tányérantennával is látni lehet. (A Bell mérnökei ugyanis attól féltek, hogy a galambpiszok okozza azt a zajt, amit később kozmikus háttérsugárzásnak azonosítottak.)

Azért biztos vagyok benne, hogy mást is publikálnak egyetlen számértéknél, hiszen a PhD hallgatókank is kell az első szerzős cikk, de nem éreztem a nagy áttöréseket. Einstein beleírta a kozmológiai állandót az egyenleteibe. Aztán kivette. Mások meg visszatették. Mintha az egész tudományág körbe-körbe menne.

A másik dolog, amin nagyon kiakadtam, hogy ugyan olyan módszertani hibákat követettek el, mint amiket én is megemlítek néha a blogomban. Az egész azért is dühítő, mert két, egymástól független csoport is elkövette őket!

Lecsupaszítva az történt, hogy két konkurens csoport figyelte a szupernovaként felrobbanó csillagokat. Ez azért volt fontos, mert ezek fényerejének változásából nagy pontossággal meg lehet határozni a távolságukat. Gyakorlatilag galaxisok Földtől mért távolságát és sebességét mérték. Ezeket egy grafikonban ábrázolták.

Az SCP csoportot részecske fizikusok alkották, akik az elején semmit nem tudtak a csillagászatról, viszont kitaláltak egy módszert, amivel annyi szupernovát tudtak detektálni, amennyit csak akartak. A másik csoport, amire a könyvben Nagy-z csoportként hivatkoznak, csillagászokból állt. Ők pontosabban megfogalmazott tudományos kérdésekre keresték a választ, viszont nagyon nehezen találtak szupernovákat.

Az SCP csoport a vizsgálatok korai szakaszában, mikor kevés szupernovájuk volt, írtak egy cikket, és felállítottak egy magyarázatot. Ahogy telt-múlt az idő, néhány olyan szupernovát találtak, amelyek nem illettek bele ebbe a magyarázatba. Mit csináltak ezekkel az adatopontokkal? Nem közölték, hanem kihagyták őket! Az volt az indok, hogy a szavahihetőségüket aláássa, ha mindig más eredményt közölnek.

Ahogy telt-múlt az idő, annyi ilyen "kiugró érték" keletkezett, hogy már nem hagyhatták őket figyelmen kívül. Akkor meg azon mesterkedtek, hogy minél előbb leközöljék és rettegtek, hogy a konkurencia beelőzi őket. Ugyanis a Nagy-z csoport kezdett feljönni a szupernovák számában, ráadásul már a kezdetektől pontosabb méréseket hajtottak végre, mert tisztába voltak egyéb csillagászati problémákkal is. Ahogy közeledett a Nobel-díj kihírdetése, úgy kezdett egyre szemetebb módon viselkedni egymással a két csoport. Civakodtak, mint az óvodások. Könyveket írtak, ahol mindenki saját magának tulajdonította a felfedezést, holott egyedül egyikük sem lett volna képes még a megfigyeléseket sem elvégezni.

Az egészhez az egyetemek még PR csapatokat is mozgósítottak, akik olyan komoly tudományos tevékenységet folytattak, hogy Washington Post és New York Times kaliberű újságokban közöltek híreket. Mélységesen megdöbbentett az egész.

Ahogy a látható anyag is csupán töredéke az univerzumunknak, úgy a tudomány is csak nyomokban fedezhető fel a sötét anyag kutatásban. A többi politika, cselszövés, árulás.

Szólj hozzá!

Címkék: filozofálás

Processzor reanimáció

2020.08.31. 22:22 Travis.CG

Az számítógépem szép lassan megdöglött. Nehezen indult, könnyen fagyott. Fagyás után megint nehezen indult. Egy ideig bírtam is a hóbortjait, de a munkát egyre nehezebben lehetett ellátni vele.

Először csak a játékok terhelték meg. Egy óra játék után annyira felforrósodott, hogy a burkolat szinte égetett. Levettem az oldalát, és elfektettem, hogy videókártyától érkező meleg levegő ne a processzort fűtse, de ez sem segített sokáig. Azután a helyzet tovább romlott, egyre rövidebb ideig tudott futni egyhuzamban. Végül 10 percet sem tudtam használni anélkül, hogy le ne fagyott volna. Eljött az idő, hogy megjavítsam.

Először a tápegységre gyanakodtam, de a multiméter és a diagnosztikai programok szerint is stabilan adta le a 12 és 5 voltot is. A memóriára gyanakodtam másodjára, de Windows alatt az Aida64 memória tesztelő modulja semmit hibát nem talált. (Volt egy kis kalandom a CentOS vészmódjával is, de nem akarom annyira részletezni, mennyi mindent sikerült elrontanom. Elég az hozzá, hogy elindítottam emergency módban, és utána csak abban tudtam elindítani.)

Processzor tesztnél viszont 3 perc után fagyott, a következő újraindításnál, ha nem tudott bootolni, az alaplapon a CPU indikátor ledje folyamatosan világított. A dokumentációja csak annyit írt, hogy szüntessük meg a CPU problémát, és akkor menni fog. Oké, de milyen problémája lehet egy CPU-nak? Pontosabban mi olyan problémája lehet, amitől néha megy, néha nem?

A neten találtam egy leírást, mely szerint érintkezési hiba léphetett fel, vagy a nem megfelelő hűtés okozhat galibát. A hűtő ventillátor megfelelően működött, nem értettem, mi baj lehet vele. Az érintkezési hiba pedig olyan misztikus. Nem tudtam elképzelni, hogy lezárt processzor foglalatban miként léphet fel érintkezési hiba, de ez volt az egyetlen nyom, amin elindulhattam. Úgy döntöttem, kiszedem a processzort.

Megpróbáltam leszedni a hűtőt a CPU-ról, de az úgy rá volt ragadva, hogy nem mozdult. Életemben nem láttam még ilyet! A régi, leselejtezett alaplapjaim hővezető pasztái még 20 év távlatából is összemaszatolták a kezem, mitől köthetett be ez a viszonylag fiatal? (Fiatal? Hét évvel ezelőtt raktam össze, azóta csak a grafikus kártyát cseréltem.) Lehet, hogy ez okozta a gondot? Megszáradt és nem volt képes a CPU leadni a hőt?

De akkor is ki kellett szedni valahogy, ha újra akarom pasztázni. Gondoltam, egy kis csavarás talán segít...

Segített is. Kijött a processzor is, hűtő is a lezárt foglalatból! A paszta továbbra is betonként tartotta egybe a két részegységet. A processzor apró réz kivezetései közül néhány elgörbült. Ezt jól elintéztem.

Egy fórum bejegyzés szerint melegítés hatására elválnak. Én próbáltam melegíteni, nem hajszárítóval, ahogy javasolták, hanem egy öngyújtóval a hűtőbordák alját melegítve, de nem használt. Az okos megoldás ha nem működik, majd a nyers erő fog. Fogtam az egyik mindenes bicskámat, és szép lassan elkezdtem szétfeszegetni a hűtőt és a processzort. A művelet során nem sikerült jól megfognom a CPU-t, ezért további lábak deformálódtak el. Végül elváltak egymástól. Egy probléma megoldva, de keletkezett egy újabb.

A bicskával lekapartam a kő kemény pasztát, majd alkohollal letiszítottam a vékony szennyeződéseket (Az ujjlenyomatokról nem is beszélve, mert antisztatikus kesztyűt csak a gyengék használnak). A hűtő alján a rézlemez kicsit karcos lett. Gondolkodtam rajta, hogy esetleg kicsit polírozok rajta, de végül letettem róla. Gondoltam, majd a paszta megoldja. Inkább fogtam egy csipeszt és egy nagyítót és szépen lassan elkezdtem visszaegyenesíteni a processzor lábait.

Ez elég sokáig eltartott. Beletettem a foglalatba, próbáltam a kezemmel érzékelni, hol nem megy a helyére, majd kivettem és állítottam még egy kicsit rajtuk. Szerencsére egy teljes sor nem görbült el, így a szomszédos lábakat referenciának tudtam használni. Végül a helyére került. Jöhet a paszta.

Volt egy doboz pasztám, amit nagyon régen vehettem, mert a rajta lévő árcédula tanúsága szerint 600 forintot fizettem érte. Szerintem 2000. után történhetett, de nem vagyok benne teljesen biztos. Meddig lehet jó egy ilyen paszta? Az állaga jónak tűnt, meg ennél több kárt már nem tudok okozni ennek a gépnek, ezért bekentem vele. Visszaszereltem a hűtőt, és áram alá helyeztem.

Nem szikrázott, amit jó jelnek vettem. Elindítottam. Az első meglepetés az volt, hogy a hűtő sokkal csendesebb lett. Ismét ráeresztettem az Aida64-t. Még teljes terhelés mellett sem volt olyan hangos, a hőmérséklet pedig nem ment 70 °C fölé. Fél óra tesztelés után megnyugodtam. A küldetés sikeres volt.

Szólj hozzá!

Címkék: rendszergazda barkácsolás

Többszörös illesztés

2020.08.25. 22:21 Travis.CG

A többszörös illesztés régen egyszerű volt. Fogtuk a szekvenciákat, bedobtuk a ClustalW-be és illesztettünk. Később jött a Mafft, Muscle és a társai, de a recept nem változott sokat.

A szekvenciák aztán hosszabbodtak és már mindenki genomokat akart illeszteni ezresével. Nem csak az aktuális járvány miatt, hanem egyébként is. A gépek viszont még nem állnak azon a szinten, hogy ezt a régi módszerekkel véghezvigyük, ezért megjelentek az egyszerűsítések és a különféle stratégiák.

Bizony, ami régen rutin feladat volt, manapság művészetté lépett elő, ahogy a DECIPHER dokumentációja is sugallja. Röviden nézzük is át, milyen stratégiák vannak!

Régi iskola

Ezt csináltuk régen, és ezt csináljuk most is, ha egyszerű hipotézisekkel dolgozunk. Veszünk egy gént, régiót, majd illesztünk. Általában olyan gént, ami minden, a kutatásban szereplő élőlényben megvan, mint például a jó öreg 18S alegység. A szekvenciák kollineárisak, közel azonos hosszúságúak, használhatjuk a régi jó dolgokat. Az összes bioinformatikai könyv, cikk, bejegyzés ezzel van tele. Előnye, hogy egyszerű, kicsi a hibázás esélye. Viszont nagyfokú szekvencia homológia esetén teljesen használhatatlan, mert minimális lesz a különbség a vizsgált szekvenciák között. Nem lesz olyan szerencsénk, hogy ezt a módszert kelljen használni.

A ráncfelvarrt

Ez majdnem ugyan az, mint az előző, csak sok homológ szakaszt vesznek, azokat mesterségesen összeragasztja, és egy nagy szekvenciával dolgoznak. Egyesek odaig is elmennek, hogy 1500 gént raknak egymás után. Közelrokon fajoknál növeli a szekvenciák diverzitását, de több gond is van vele. Először is, a gének evolúciós sebessége eltérhet. A végső hasonlóságot a hosszabb gének fogják megszabni, ráadásul a gének illesztésének helyén nagyobb eséllyel lesz gap, amit minden illesztőprogram rosszabbul súlyoz, és a később a fa építésénél a valós evolúciós távolságnál nagyobb távolságot kapunk. Ennek a módszernek semmi biológiai relevanciája nincs, szerintem azért csinálják, mert még mindig vissza tudnak nyúlni a megszokott programjaikhoz. Ezt a módszert lehetőleg soha ne használjuk, nyugodtan vállaljunk be egy összeveszést a főnökünkkel, ha erre akar kényszeríteni.

Vadnak született

A helyzet az, hogy legtöbb esetben nincs teljes genomunk, csak dirib-darab szekvenciáink. Ha van is genom, a kollinearitás nem garantált, nekünk mégis ezzel kell dolgoznunk. A megoldás, hogy több homológ szakaszt veszünk, akár csak az előző módszerben, csak nem ragasztjuk össze őket. Több többszörös illesztést végzünk és több fát készítünk, ha evolúciós kapcsolatokat is látni akarunk. De melyiket illesztést, és azon keresztül melyik fát fogadjuk el végső eredményként? Természetesen az összeset, egy konszenzus fa képében, amit például az Astral nevű program is elkészíthet. Kolinearitás garantált, fragmentált genom esetén is működik, közel rokon fajoknál is lesz elég távolság, mégsem viszünk mesterséges hibát a feldolgozásba. Természetesen ez a mószer a legmacerásabb, de szerencsére akadnak, akik nem riadnak meg tőle.

A kívülálló

Érdekes módon a progressiveMauve az általam ismert egyetlen program, ami elfogad bármilyen genomot, akár draft genomokat is, és tudásához mérten elvégzi az illesztést. Az előbb említettem, hogy több homológ szakaszt kell keresni, de baktériumoknál, ahol a horizontális géntranszfer tovább bonyolítja a helyzetet, néha azzal szembesülünk, hogy a homológ gének nem feltétlenül egy leszármazási egységre jellemzőek.

Ez a program viszont autómatikusan megkeresi a synteny blokkokat, meghatározza azok orientációját, létrehoz egy hierarhikus fát, amit vázként használ a precíz illesztéshez. Ez az úgynevezett "guided tree" meglepően korrekt fát hoz létre. A cikk és dokumentáció szerint nem használható filogenetikai elemzésre, de a kollégáim szerint az eredménye nagyon egybevág a biológiával, legalábbis az eddig vizsgált bakteriális genomok esetén így volt.

A módszer hátránya, hogy régi a  kód, nem használja ki a többmagú processzorokat. Másik hátránya, hogy bakteriális genomoknál hosszabb szekvenciák illesztése rengeteg időt vesz igénybe.

Szólj hozzá!

Címkék: bioinformatika

Szakmák, amikhez mindenki ért: járványtan

2020.08.16. 22:11 Travis.CG

A mai világban nem elég, ha jó szakember valaki, innovátornak kell lennie. A pszichológus is life coach, ha ki akar törni a szürke munkások hadából. Ha pedig rájön valaki, hogy a súlyokat máshogy is lehet emelgetni, akkor azonnal egy többlépcsős tanúsitvány rendszert segítségével biztosítja, hogy csak ő adhassa tovább a tudást. Mindhárom esetben el kell jutni arra a szintre, hogy sok embernek mi, és csakis mi mondjuk meg a tutit, mert csak akkor leszünk valakik. Ez pedig szükségszerűen versenyhelyzethez vezet.

Erre két módszer van, hogy ezt elérjük. Az egyik, hogy hosszú évek munkájával, folyamatos fejlesztéssel eljutunk erre a szintre, miközben szép lassan, ezzel párhuzamosan növekszik a reputációnk is. A másik módszer egyszerűbb: felvesszük a "megmondó ember" attitűdöt, és becserkésszük azokat, akik elhiszik ezt. Vagyis jó hangosan, minél szélesebb közösségnek kell nagyon magabiztosan eladjuk magunkat.

Bárkit megkérdeznénk, biztos vagyok benne, hogy az első csoportba sorolná magát. De ha elolvassuk a Twittert, Facebookot, valahogy mindig a második csoport kerül túlsúlyba. Én ugyanis ennyi hülyeséget még nem hallottam, mint amennyi a COVID-19 kapcsán előkerült.

Az 5G hálózatok, mint a vírus terjesztői, vagy az ellenanyagba rejtett mikrochip kezdetű teóriákon nem akadok fenn. Ezek szerintem teljesen természetes velejárói annak a sokknak, amit egy globális terjedésű vírus az emberiségből kivált. Bármilyen megdöbbentő eseményre jobb válasz az, hogy valaki "csinálta", mint az, hogy ilyesmi spontán megtörténhet. Ennek elemei az életkor korai szakaszaiban is megmutatkoznak. Az emberekben kialakuló világkép fejlődésének is van egy olyan szakasza, amikor azt gondolják a gyerekek, hogy mindent a "bácsik" csinálnak. Miként jön létre egy folyó? Jönnek a bácsik, és kiássák a medret. Később, persze helyére kerülnek a dolgok, de vannak, akiknél szerintem ez megmarad később is. Miként csapódik egy utasszállító egy felhőkarcolónak? Jönnek a gyíkemberek és a CIA segítségével megcsinálják.

Szerintem ezzel nincs is semmi gond, nem lehetünk minden tulajdonságunkban egyformák. Egyesek nem tudják lefutni a Maratont, mások meg nem tudnak elszakadni az összeesküvés elméletektől. A probléma szerintem nem ez.

Még az sem olyan nagy gond, ha olyan összefüggéssel számolják ki a vírus riasztás szintjét, amiről egy általános iskolás is látja, hogy értelmetlen. Bár ez már jelez némi hozzá nem értést, de mivel ezekről minden értelmes ember látja, hogy hülyeség, egy globális nevetésen kívül nagyobb bajt nem okoz.

A probléma ott kezdődik, amikor azok az emberek kezdenek el hülyeségeket mondogatni, akiknek az a feladatuk, hogy gondolkodjanak. Mert jelen pillanatban ez történik. A preprint szervereket például elárasztották a koronavírus szakértők. Hol voltak eddig? Talán a föld alatt, és onnan másztak elő a Necronomicon hívó szavára?

Például tessék megnézni mindenki kedvenc vitaminját, a C vitamint. Időről-időre eszébe jut valakinek, hogy ezzel váltsa meg a világot, ezért nem meglepő, hogy a hülyeségcunami első hullámával azok a híresztelések érkeztek, hogy a C-vitaminnal megálljt lehet parancsolni egy vírusnak. Még az influenzát sem állítja meg, de Pauling szelleme olyan erős, hogy ötven évvel a halála után is hisznek neki.

Ez a "régi jó dógokhoz" való visszanyúlás figyelhető meg a hidroxiklorokin esetén is. Lépten-nyomon bizonyítják, hogy teljesen hatástalan, de még mindig vannak orvosok, kutatók, akik újabb esélyt adnak neki, sőt cikket írnak belőle. Ha egy vadat lelőnek, ott kell hagyni döglötten, nem rugdosni előre, miközben hangosan kiabáljuk, hogy "még mozog, biztosan él".

Ha valaki hülyeséget mond, akkor nem védi meg a hírnév, a szakmai múlt és a számtalan kitüntetés. Ez történt ugyanis John Ioannidissel is. Évtizedeken keresztül, kérlelhetetlen alapossággal kutatta a módszertani buktatókat és leplezett le kutatókat. A felesége ráadásul a fertőző betegségek szakértője. Ketten együtt sikerült akkora batár nagy marhaságot összeírniuk, hogy az már fájt. Persze a szakmai közösség rákapott a cikkre, mint éhes pitbull a csupasz lábszárra és ennek megfelelően szét is cincálták az egészet. Pontosan azt csinálták vele, mint amit ő is csinált éveken át mások munkájával.

Igazából, ha valamiben nem vagyunk teljesen biztosak, jobb csendben maradni. Bevallom, nekem is sok téves elképzelésem volt a vírussal kapcsolatban, de sikerült megállnom, hogy ne csináljak hülyét magamból mindenki szeme láttára (bár más fronton biztosan találni egy-két ellentmondást az írásaimban). Igaz, rajtam nincs is nyomás, hogy követőket szerezzek és belőlük éljek.

Aki viszont kimondja véleményét ország-világ előtt, az óhatatlanul is állíthat hülyeséget. Történt ez Steve Salzberggel is, aki a saját szakterületén szerintem hasonló kaliberű ember, mint Ioannidis. Neki az fájlt, hogy ha 300 ezer embernek be lehet adni egy kísérleti gyógyszert, mert annyira biztonságos, akkor miért nem adhatnák be mindenkinek?

Viszont van egy nagy különbség Ioannidis és Salzberg között. Előbbi szaladt fűhőz-fához, hogy a többiek csúnyát mondtak rá. Lobogtatta a ráaggatott plecsniket, hogy ő márpedig valaki. Még ekkor sem volt képes elfogadni, hogy leszerepelt. Salzberg viszont felül tudta bírálni korábbi álláspontják, és képes volt elismerni, hogy tévedett. Ehhez is erő kell, egy olyan világban, ahol mindenki azt várja el, hogy a szakértők tévedhetetlenek legyenek. Ez legalább olyan fontos, mint "megmondani a frankót".

Szólj hozzá!

Címkék: filozofálás

Szokatlan programozási nyelvek a bioinformatikában

2020.08.02. 22:52 Travis.CG

Először is le kell fektetnünk, mit értünk szokatlan programozási e nyelvnek, hiszen az itt bemutatott nyelvek évek óta léteznek, ismertek. Lehet, hogy a ritka programozási nyelvek megfelelőbb cím lett volna.

Ami miatt mégis ezt a címet választottam, az a tény, hogy a tudományban is vannak divatok. Egy időben mindenki Perlben írta az aktuális okosságot, manapság inkább Python a menő. A C és C++ jelenlét konstansnak tekinthető, mert az elemzések gerincét végző programokat ebben írták, írják. Emellett előfordul az R és a Java. Előbbi a Bioconductor miatt, utóbbi platform függetlensége miatt. (Vagy mert a fejlesztők még abból az időből származnak, amikor a Java még menő volt.)

Azonban a nyelvek skálája szélesedett. Már nem csak olyan nyelvek vannak, amelyek a C-t, vagy a Java-t majmolják. Vannak olyan nyelvek is, amelyek új kihívásokra keresik a megoldást. (Eközben többen a Pythont majmolják, de ez már más kérdés.)

Vegyük például a Rust-ot, ami a biztonságos kódot tűzi zászlajára. Ez egy olyan cél, ami a bioinformatikában - ahol a kódminőség hagy némi kivetnivalót maga után - tényleg hasznos lehet. Az egyik programmal a BaseSpace-ről lehet letölteni adatokat, a másikkal a FastQ fájljainkat ellenőrizhetjük. De a 10x Genomics genom összerakó programjának, a Supernovanak is van egy Rustban írt része. Az egy sejtes genotípizáló eszközüknek a Vartrixnek viszont már sokkal nagyobb részét fejlesztették ebben a nyelvben.

A másik terület, ami a kódbiztonság mellett igen fontos a bioinformatikában, a többszálú feladatvégrehajtás. A Go nyelv pontosan ezt célozza meg. Nem meglepő, hogy létrejött a BioGO. A 10x Genomics ezen a nyelven is fejleszt, például a Lariat illesztőjüket. Rajtuk kívül a Grail nevű, korai tumor diagnosztikával foglalkozó cég használja előszeretettel a nyelvet, elsősorban a felhős infrastruktúra felügyeletére.

A harmadik bemutatott nyelv a Nim, amit Brent Pedersen használ előszeretettel. (Félelmetes programozó, érdemes követni a munkásságát) Ha egy mondattal szeretném bemutatni, akkor azt mondanám, olyan Python, ami natív kódot eredményez. A fordító érdekessége, hogy képes JavaScriptre is fordítani, amivel a webre költözést oldhatja meg egyszerűen a fejlesztő.

Heng Li pedig több nyelvet is összehasonlított, hogy melyik felel meg legjobban a következő projektjéhez. A fenti nyelvek mellett Crystalban is írt programot. Ezen kívül nem tudok más bioinformatikai projektet, amit ezzel a nyelvvel fejlesztettek volna.

Nem muszály és nem is érdemes egy nyelvnél leragadni, ha genomi adatokat akarunk feldolgozni. Itt is van fejlődés, még ha ez nem is olyan látványos, mint egy startup cégnél.

Szólj hozzá!

Címkék: bioinformatika

Összefogás COVID idején

2020.07.19. 23:45 Travis.CG

Bevallom, engem nagyon frusztrált, hogy sok ember vért izzadt, hogy a vírust megállítsák (vagy elviselhetővé tegyék a megújult helyzetet másoknak), miközben nekem a legfontosabb munkahelyi teendőim között az szerepelt, hogy a Dropbox mappámból fájlokat töröljek ki, hogy a megosztott tartalmak ne lépjék túl a mágikus 2GB-os határt.

Arra gondoltam, ha nem is tudok intubálni, talán az évek során összegyűlt annyi bioinformatikai tapasztalatom, hogy azt valamiképp mások rendelkezésére bocsáthassam. Ezért javasoltam a főnökömnek, hogy vegye fel a kapcsolatot a hazai COVID-19 csapat bioinformatikai fejeseivel.

A kapcsolat nagyon gyümölcsöző volt, mindkét fél sokat tanult a másiktól, kemény megfeszített munkával véghezvittük a lehetetlent és a megszerzett tudást az emberíség javára fordítottuk. Eközben egy kis bioinformatikus, akit mindenki lenézett, végül hőssé vált.

Ez a Disney-féle verzió. A valóság egy kicsit más volt, még erről az alsó szintről nézve is, ahol én vagyok.

Először elindult valami kollaboráció-féleség. Azt mondták, hogy szükségük lenne egy szerverre, ami vizuálisan megjeleníti az egyes virus genomok egymáshoz fűződő viszonyát. Valahogy úgy, ahogy a Nextstrain csinálja. Mivel a Nextstrain szerver felépítése teljesen nyitott, még tutorial is van, hogyan építsünk egyet saját magunknak, ezért szépen le is másoltam.

Az egész SSH kapcsolaton keresztül volt elérhető, viszont a vírus törzsek letöltése elég nehézkes volt, ezért nem is álltam neki, amíg nem pontosítjuk a célokat. A másik, ami megállásra bírt, hogy a Nextstrain szerveren saját elemzéseket is lehet definiálni, amiről szintén nem beszéltünk. Az elérhetőségeket elküldtem, és vártam, hogy mi lesz a következő lépés. Szokás szerint jött a Nagy Kuss.

Akkor tudtam meg, hogy a kollaboráció - ami létezett is, meg nem is - véget ért, amikor megláttam a megjelent kéziratot. Vagyis, valaki velem párhuzamosan megcsinálta ugyan azt. Illetve többet is, mert ott megvolt az összes törzs, és a teljes elemzés is.

Valami olyan homályos indoklás jutott vissza hozzám, hogy a magyar vírusoknak nem szabad publikus szerveren lenniük. Nem értem, mit titkolóznak, különösen, hogy az általam készített szerver nem volt publikus, csak az láthatta, akinek hozzáférést adtunk. A fenti kézirat is úgy tudott megszületni, hogy mások évek óta fejlesztik a Nextstraint, mások megosztják a teljes vírus genomokat, erre mi, Magyarok eldugjuk ezt a pár genomot, mert ez aztán az innováció melegágya. Mitől félnek annyira? Valaki megnézi őket, és levonja azt a következtetést, hogy a Magyaroknak még a koronavírusaik is szánalmasak? Emberek személyiségi jogai rendben vannak, de most egy olyan vírusról van szó, amit mindenki ki akar nyírni.

Persze mások is szerettek volna némi bioinformatikai kollaborációt. A Magyar Bioinformatikai Társaság egy körlevélben próbálta feltérképezni (az EBI hatására), ki milyen erőforrást tud felajánlani ehhez az új keresztes háborúhoz. A felmérés kimenetele ismeretlen számomra, de annyit tudok, hogy az ELTE büszkén hívta fel a figyelmet erre a kezdeményezésre, amiben részt vesznek.

Milyen érdekes, ez is az adatok megosztásáról szól, nem arról, hogy egy barlang mélyén kell gyönyörködünk művünkben, miközben azt mormoljuk: "Drágaszágom".

Szólj hozzá!

Címkék: filozofálás

Zsonglőrködés környezeti változókkal

2020.07.14. 17:41 Travis.CG

Szuperszámítógépes környezetben gyakran találkozunk a module load paranccsal, ha egy szoftver komponenst akarunk használni. Mi ez a parancs, mire tudjuk használni és hogyan fordíthatjuk saját hasznunkra?

A program nem csinál mást, csak a kiadott utasításoknak megfelelően kicseréli a környezeti változókat. Ez talán elsőre nem tűnik nagy dolognak, hiszen ott a Docker, Conda, de sok esetben egy virtualizációs megoldások csak elbonyolítják a helyzetet. Például képzeljünk el azt a felállást, amikor két olyan környezetet kell használnunk, ami két különböző Docker képfájlban van. De az is elképzelhető, hogy nem akarunk rendszergazdai jogokkal felruházni futó folyamatokat, mint ami a HPC környezetek esetén is tapasztalható.

A környezetek összevonása nagyon egyszerűen megy modules-al, de rosszul megtervezett modulok esetén továbbra is előfordulhatnak ütközések, míg Docker használatával ennek az esélye minimális.

A rendszer egyik gyengesége a Tcl/Tk környezethez való ragaszkodás, aminek történelmi okai vannak. Ez is csak azoknak jelenthet problémát, akik nem szeretik ezt az archaikus megoldást. Szerencsére létezik több alternatív rendszer, ami ezt lecseréli, például Lua-ra. Ebben a bejegyzésben csak a Tcl/Tk verziós megoldással foglalkozom.

Mivel elég régóta fejlesztett programoról van szó, az összes ismert csomagkezelőben megtalálható environment modules néven. Telepítés ezért gyerekjáték. Minden környezetet egy fájl reprezentál, amit Ubuntu esetén például az /usr/share/modules/modulefiles könyvtárban találunk alapértelmezetten. Általában nem érdemes nulláról kezdve megírni a fájlokat, inkább valamelyik, már létező fájlt kell módosítani, hogy a fájlok váza egységes legyen.

Milyen módon épül fel egy ilyen fájl? Először is kell egy #%Module, ami kínosan emlékeztet egy linuxos szkript fejlécre. Ez nem a véletlen műve. Utána jöhet egy verziószám.

A konvenció szerint ezután kommentek formájában érdemes egy rövid leírást adni magáról a modulról. Mivel csak ritkán olvassuk magukat a modul fájlokat, célszerű egy ModulesHelp függvényt is definiálni, ami szintén kiírja a szükséges információkat. Ezeket a modules help paranccsal jeleníthetjük meg.

Az összes többi bejegyzés szabványos Tcl/Tk utasítás. Készíthetünk ciklusokat, feltételes elágazásokat, bármit. A nyelv bemutatása túlmutat a cikk határain, ezért itt csak a legfontosabb dologra, a környezeti változók kezelésére koncentrálunk.

Bioinformatikai programok esetén az egyik legfontosabb környezeti változó, az elérési út, vagy "PATH". Amennyiben új elemet akarunk hozzáadni, az append-path parancsra lesz szükségünk. Utána a változó nevét kell megadni, amit Bash esetén a PATH, majd a hozzáadandó értéket, ami az elérési út.

append-path PATH "/home/user/mysoftware/bin"

Az adott modul eltávolítása után a bejegyzés is eltűnik. Tehát ha több környezetet használunk, és mindegyiknek saját bejegyzése van a PATH-ban, akkor a modul megszűnése csak az adott környezet bejegyzését törli.

A másik fontos parancs, az új környezeti változó felvétele, hiszen sok program azok alapján találja meg a konfigurációs állományokat vagy adatokat. A setenv parancs segítségével ezt érhetjük el. Szintaxisa nagyon hasonló az append-path-nál megismerthez. Először a parancs, majd a beállítandó környezeti változó neve, végül az értéke. A következő példa a STAR-Fusion számára állítja be az indexelt genom és a hozzátartozó annotációt tartalmazó könyvtár nevét:

setenv CTAT_GENOME_LIB "/usr/share/molbio/rna-seq"

Amennyiben készen vagyunk a fájlokkal, azonnal használhatjuk őket. A module load parancs segítségével betölthetjük az adott környezetet, csak a modul fájl nevét kell megadnunk. Ha már nincs szükségünk az adott környezetre, a module unload segítségével eltávolíthatjuk azt. Az elérhető modulok listáját a module avail mutatja meg.

Végezetül szeretnék pár megjegyzést tenni, amivel én szembesültem, amikor telepítettem és konfiguráltam a rendszert. Bash esetén nem szokott gond lenni, de más parancsértelmezők alkalmazásakor figyelni kell, hogy a modules inicializálása megfelelő legyen. Az /etc/profile.d könyvtárban található fájlok nem minden esetben futnak le, például zsh esetén. Nem megfelelő inicializálás esetén hiába vannak a modul fájlok a megfelelő helyen, azokat mégsem látja a felhasználó.

Ha több környezetet szeretnénk használni, akkor az environment-modules siet a segítségünkre. Segítségével átláthatóvá tehető a környezeti változók kezelése. Telepítése egyszerű, használata szintén. HPC környezetben előszeretettel használják, de saját rendszerünkre is telepíthetjük. Ez a bejegyzés nem érintett mindent, a program sokkal több lehetőséget rejt magában (például akár hierarhikusan is felépíthetjük a modulokat).

Szólj hozzá!

Címkék: rendszergazda

Cseppet sem objektíven: Just for fun 2020

2020.06.28. 22:17 Travis.CG

Az idei karantén világ egyik kellemes hozadéka volt a Just for fun compó, amit tényleg csak a móka kedvéért rendeztek. A releaseket interneten kellett elküldeni, majd egy YouTube streamen végignézni. Mivel az összes alkotásnak 30 másodperc hosszúnak kellett lennie, nem fenyegetett az a veszély, hogy elalszom közben, vagy a compó végére nem tudom, mit is láttam az elején.

Nem is tudom, hogy van-e értelme kritikát írni ilyen kompóról, ezért mindegyikről leírom, miért tetszett.

Az első a Transmission volt a The Bad Sectorstól, amit egy mikrokontollerre írtak. A mikrokontollerekre nehezebb kódot írni, mert sokkal több a limitáció. Mind a hardver felől, mind a létező eszközök részéről. Itt nem lehet azzal vádolni a készítőket. hogy az "OpenGL megcsinál mindent". Az Astroidea egy rég elfelejtett kódot adott be Astrocola néven. Ennek megfelelően 386-oson futott GUS alatt. Szerintem jó, hogy ezek a kódok még akkor sem vesznek el, ha nem adják ki őket, és ilyen ritka alkalmak egyikén láthatjuk mi is. Slyspy jó ötletet használt fel, mert egy régi Amigás demót elevenített fel vicces formában. Szerencsére a bemutatkozó videóból megismerhettük a demó hátterét is. A Dilemma Ocean's Drive azért volt jó, mert remek volt a hangulata és kellemes volt a zene is hozzá. Az Ümlaut Designtől szerintem egy trailert kaptunk, ezért nagyon felcsigázott, mit is akarnak bemutatni Function-ön. (Legalábbis azt gyanítom, hogy Function-ön mutatják be. Belsős információval nem rendelkezem.) A Rebels Function invitációja kihasználta a 30 másodperces limitet. A normál tempójú felvezetés után az összes part fél másodperc volt, és ennek megfelelően kedves kakofóniába torkollott. A The Bad Sectorstól kaptunk még egy demót, ami azért volt jó, mert Blueghost visszatért és új effektet használt, amit még soha azelőtt, ergó fejlődött.

Végül a demo1 tiborsaas-tól, ami azért is jó, mert első demó, rögtön győzelemmel. Az effektek teljesen rendben voltak, a zene passzolt a látványhoz. Reméljük még sok remek alkotást láthatunk tőle.

Szólj hozzá!

Címkék: demoscene

Lehet-e zenélni Linux alatt?

2020.06.17. 00:04 Travis.CG

Rövid válasz: nem igazán.

De miért? Először is, mit értünk zenélés alatt? Itt azt értem, hogy digitális hangszerekkel csak egy program segítségével az ötlettől a kész megvalósításig el tudunk-e jutni. Valahogy úgy, ahogy Windows alatt az FL Studioval, Abletion Live-al zenét készít az ember.

Linux alatt az egyetlen szóba jöhető program az LMMS. A program maga csodálatos. Tényleg hozza azt a minőséget és tudást, amit az ember elvár egy Linuxos programtól, miután megnézte a több éves múltra visszatekintő Windowsos alternatívákat. Ha el tudjuk fogadni a Gimpet Photoshop helyett, ha megbírkózunk a Blenderrel 3D Studio után, akkor az LMMS-el sem lesz gondunk.

A főbb részegységek itt is megvannak, az elérhető funkciók, ha nem is érik el a konkurensek színvonalát, de működnek, a felhasználói felületet pedig meg kell szokni. Ismerős a recept? Nem csoda, hiszen szóról-szóra ugyan ezt lehet elmondani a többi Linuxos tartalom készítő alkalmazásról is.

Akkor mégis mi a probléma? A probléma, a VST bővítményekkel vannak.

Az LMMS beépített zajforrásai hangszerei egyszerűen nem hangzanak jól. Bármit is csinál a felhasználó, úgy szólnak, mint egy bolhapiacon vásárolt gyerek szintetizátor. Még talán a GUS midi hangszerek, amelyek valamennyire elviselhetőek, de ez kevés szerintem.

A megoldás, hogy harmadik féltől származó hangszereket kell importálni a programba, és használni őket orrvérzésig. Ezek a VST pluginok. Gyakorlatilag azok a programok, amelyek nem kezelik a VST pluginokat, közröhej tárgyai. Ezért az LMMS is szépen beolvassa őket. Hurrá, akkor mi a probléma a bővítményekkel?

A probléma ott van, hogy programozói szempontból a VST plugin egy futtatható bináris fájl. Tehát minden oprendszer alá saját verzió kell, ami gyakorlati szempontból azt jelenti, hogy egy Windowsos bináris fájl GUI-val. Persze, van Mac és Linux alá is mutatóba valami, de többségében csak Windows alá van minden. Ezt vicces kedvű fejlesztők ki is használják és szükségtelen elemekkel tűzdelik tele azt. Bár egy profi még ezzel is tud kezdeni valamit:

De még ezzel sem teljesen lehetetlen a Linuxos LMMS használata, mert a Wine segítségével betölthetőek. A folyamat úgy néz ki, hogy az LMMS a VST előtt megpróbálja betölteni a Wine-t, aminek az inicializálása elég sok időt elvesz. A VST plugin időtullépés miatt dob egy hibát, a Wine összeszedi magát, elindul, és megjelenik a VST bővítmény felülete. Mazohisták ezt szokták használni, ha épp nincs a kezük ügyében szöges korbács.

Mindez eszi a memóriát, fogyasztja a processzort, és növeli az ősz hajszálak számát.

Arról nem is beszélve, hogy CentOS alatt csomagkezelőből nem is lehet felrakni. Az extra repoban megvan, de egy függősége nincs rendesen beállítva, ezért nem települ. Ubuntu alatt szépen felmászik a gépre, még a Wine-t is könnyedén lehet konfigurálni. Onnantól viszont nagyon elkeserítő, hogy csak pittyeg az egész.

Sajnos már nem emlékszem ki mondta, de egy demópartin elhangzott, hogy nem is az számmít, hogy milyen programot használunk, hanem milyen sample-ök vannak. Azt hiszem ez nagyon igaz.

Szólj hozzá!

Címkék: filozofálás

Slackware, biztos alapok

2020.06.09. 23:35 Travis.CG

Mivel a Minixel nem sok mindenre voltam képes a 20 éves laptoppal, arra gondoltam, kipróbálhatnék egy olyan rendszert is, ami több sikerrel kecsegtet. Ezért az elfekvő CD-im közül kiválasztottam egy Slackware 10-t. A későbbi verziókat már DVD-re írtam, a laptop pedig csak CD-t olvas, ezért a lehetőség adott volt.

A telepítés olyan volt, ahogy egy ilyen rendszertől megszokhattuk, illetve ahogy már megszoktam az évek során. Bebootol, és odadob minket egy parancssorba, ahol kézzel elvégezhetjük a partícionálást és aktiválhatjuk a swap területet. Utána a telepítő segítségével már beállíthatjuk a billentyűzet kiosztást, hálózatot és a felmásolni kívánt csomagokat.

A teljes rendszer 2.8G tárhelyet emésztett fel, ebben csak a KDE nemzetközi csomagok nem voltak benne. Grafikus felülettel 40MB memóriát evett, ami mérsékelt. A CPU használat 20% körül volt. Elég jól működött.

Végre meghallgathattam a laptop hangkártyáját működés közben. A doksi szerint Sound Blaster kompatibilis a hangkeltő eszköz, de FreeDOS alatt valami miatt mégis némák voltak a hangszórók (azóta találtam egy potenciális megoldást, majd kipróbálom). Már attól féltem, elromlott valami. A korai időkben a hangkártyát a felhasználónak kellett beállítani az Alsa programjait használva. Emlékszem, régen ezzel sok problémám volt, de most nagyon simán ment, magam is meglepődtem, hogy milyen hamar felcsendült a zene. Szóval zenehallgatásra lehet használni, bár a merevlemezen már csak 900MB hely van, ami nem sok demóparti zenei anyagát tárolhatja.

A fejlesztéshez van C, C++, Fortran, Perl, Python (de még csak a 2.2 verzió). Programozási házi feladatokat azért lehet csinálni rajta, az algoritmusok fejlesztését is gyakorolhatja rajta, aki akarja. Sőt, annak idején még a Java-t is szabadon terjeszthette mindenki, ezért találunk még a Sun idejéből való Java 1.4-t is.

Megnézhetjük a PDF állományokat, ami cikkek olvasásához hasznos. Kényelmesebb lehet, mint sok telefon képernyője.

Van egy teljes Tetex rendszer, úgyhogy tudunk írni könyvet, cikket, disszertációt LaTeX-ben. A magyar ékezetek használata kicsit nehézkes lehet, mert nincs teljes unicode támogatás, de a feladat nem lehetetlen.

Kipróbáltam, tudok-e szkennelni vagy nyomtatni az egyetlen 1.0-s USB csatolón keresztül, de nem sikerült. A Postscript nyomtatókat azért több erőfeszítéssel be lehetne állítani, de nem voltam elég kitartó.

Megpróbáltam netet is csiholni egy mobiltelefon segítségével, de az USB-s eszközt nem tudtam megetetni az ifconfiggal. Feltételezem egy kernel modul hiányzik. Mondjuk ha működne is a net, nem sok hasznos funkciót tudnánk elérni. Böngészőnek Netscape van, az SSH kliens teljesen elavult, bátrabbak IRC-hetnének, vagy FTP-ről tudnának letölteni.

LibreOffice teljesen hiányzik. Nem csak azért, mert ebben az időben még OpenOffice (StarOffice) volt a neve, hanem azért is, mert a Slackware-ek Abiword és Gnumeric fanok voltak.

Mivel a Linux játékok szempontjából ez idő tájt elég gyatra volt, ezért csak sakkozni próbáltam vele, de a grafikus felületű sakkprogram képtelen volt csatlakozni a gnuchess-hez. Szerintem a probléma nem teljesen orvosolhatatlan, ezért elméletileg sakkpartnernek is lehetne használni a gépet.

Gimp is van, de a mai digitális gépek felbontását figyelembe véve maximum egy animált GIF compóra elég a gép teljesítménye (Revision-ön szokott lenni).

A rengeteg hátrány ellenére ez volt az első rendszer, amivel potenciálisan alkotni is lehetne valamit. (Bár a FreeDOS-al készítettem az első 256 byte intrómat, ami valódi, kézzelfogható eredmény.)

Szólj hozzá!

Címkék: rendszergazda

Csak a móka kedvéért

2020.05.25. 21:57 Travis.CG

A demoscene egy remek hobbi, de egy idő után nagyon bele lehet bonyolódni, ami alatt azt értem, hogy indokolatlan mennyiségű időt és energiát lehet beleölni, az eredmény láttán mégis sokan csak fanyalognak. Például: ezt az effektet már láttuk X évvel ezelőtt. Esetleg: ezt meg lehet csinálni sokkal kisebb méretben is. De még olyan is előfodrulhatm, hogy azzal vádolnak meg, hogy nem kódolunk semmit, mert Y jatékmotort használtuk. Nem csoda, hogy sokan nem produkálnak semmit, még akkor is, ha megvan a megfelelő tudásuk hozzá.

Időről-időre emlékeztetni kell magunkat, hogy ez az egész mégis csak egy hobbi, amit azért csinálunk, hogy jól érezzük magunkat. De akkor is sok időt kell ráfordítani.

Ezért is jó a most következő Just For Fun compó, ahol összesen 30 másodperc időt kell feltölteni. A release mérete pedig nem lehet 16 MB-nál nagyobb. Tehát nem kell vért izzadni, hogy telenyomjuk a demót részletes tartalommal, mert nincs rá hely. Nem kell több száz effektet kitalálni, mert nincs idő rá, hogy bemutassuk. Optimalizálni sem kell, mert nem muszály beleférni 64k-ba.

Szóval, akinek van kedve, nyugodtan kipróbálhatja magát, a lényeg, hogy jól érezzük magunkat, és alkossunk. Részletes kiírást itt találhatunk.

Szólj hozzá!

Címkék: demoscene

Bioconductor annotáció készítés

2020.05.19. 23:38 Travis.CG

A Bioconductor remek kezdeményezés, a bioinformatikai elemzések egységes platformja, ahol könnyedén új komponensekkel bővíthetjük a rendszert. Nemcsak szoftver, hanem adat oldalon is bővíthető a rendszer, hiszen a különböző annotációk ugyan olyan fontosak a bioinformatikai munka során, mint az algoritmusok. De mi a helyzet, ha a vizsgált faj annotációja nem létezik a Bioconductor égisze alatt? (Tipp: nézzük meg a blog mottóját.)

Bizony, a Bioconductor amilyen hasznos szolgálatot tesz a humán és egér vizsgálatoknál, olyan használhatatlan más fajoknál. Pedig az EnsEMBL, UniProt, KEGG tele van rengeteg fajjal, csupán azt kellene megoldani, hogy ezek az adatok szabványos formátumban legyenek, hogy aztán a programok felhasználhassák azokat.

Szerencsére nem kell nulláról kezdeni a munkát, a Bioconductor ahhoz is segítséget ad, hogy elkészíthessük ezeket a csomagokat. Lássuk, hogyan is kell hozzákezdeni egy ilyen munkához.

A két legfontosabb csomag, amit használni fogunk, az AnnotationHub és az AnnotationForge. Ha szerencsénk van, csupán egyetlen parancsot kell kiadnunk:

makeOrgPackageFromNCBI(version="0.1", author="Travis <travis@fake.com>", maintainer = "Travis <travis@fake.com>", outputDir = ".", tax_id = "60711", genus = "Chlorocebus", species = "sabaeus")

A legfontosabb paraméter a tax_id. Ez alapján fogja ugyanis a rendszer az NCBI-ról letölteni az adott fajhoz tartozó adatokat. Ami még sok fejfájástól kímél meg minket, ha követjük az annotációs csomagok formátumára vonatkozó ajánlásokat. Például a csomag szerzője után <> közé az email címet is meg kell adni. Letöltés után mindent egy SQLite adatbázisba pakol, majd elkészíti a megfelelő csomagot. Ezt telepíthetjük is:

install.packages("./org.Csabaeus.eg.db/", repo = NULL, lib = "/usr/lib64/R/library")

Az utolsó paraméter nem kötelező, és szükség van írási jogra az adott könyvtárra. Sok esetben ennyi elég is. De, mint ahogy a tapasztalatok is mutatják, ritkán van jó napunk, a legtöbb esetben ennél többet kell dolgozni.

Ilyenkor nekünk magunknak kell a megfelelő adattáblát letölteni, majd formázni. Letölthetjük őket a BioMart-ból, UCSC-ből, vagy egyéb forrásból. Először is azt kell eldöntenünk, mi lesz az elsődleges azonosító. Ez lehet az NCBI vagy az EnsEMBL gén azonosító. Ez azért lesz fontos, mert minden adattáblánk ezen azonosító szerint lesz összekötve. Ez minden táblában az első oszlop kell, hogy legyen, és GID legyen az oszlop neve.

A második legfontosabb lépés, hogy mindegyik táblának, amit az adatbázis építéshez használunk, legyen értéke minden oszlopban. Sok esetben ez nem megvalósítható, ilyenkor célszerű a táblát több al-táblára osztani. A fejléc bármi lehet, de az első oszlop mindenképp a GID kell, hogy legyen.

Amennyiben GO adatokat is szeretnénk, úgy annyi megkötés van, hogy a táblánk három kötelező oszlopot kell, hogy tartalmazzon: GID, GO, EVIDENCE. Az első a gén azonosítónk, a második a GO azonosító, a harmadik pedig a bizonyíték, ami alapján a gént az adott ontológiával összekötöttük. Ezen felül bármilyen további mezőt megadhatunk.

Ha készen vannak a tábláink, el kell készíteni a csomagot:

makeOrgPackage(version="0.1", author="Travis <travis@fake.com>", maintainer="Travis <travis@fake.com>", outputDir=".", tax_id="60711", genus="Chlorocebus", species="sabaeus", ensembl=enstable, ucsc=ucsctable)

A paraméterezés megegyezik a makeOrgPackageFromNCBI-al, de kiegészül az egyes táblák nevével, ami a példában enstable és ucsctable néven szerepel. Megkötés nincs. Az elkészült csomagot a korábban bemutatott módon telepíthetjük.

Természetesen egy létező csomagot is vehetünk alapul, ha nem akarunk mindent más forrásból letölteni. Először érdemes megnézni, milyen adatok érhetőek el az AnnotationHub-ban. Ez az annotációs csomagokat kívánja egyesíteni egy kereshető formában. Használata számomra kicsit szokatlan volt, de cserébe egyszerű.

ah <- AnnotationHub()
res <- query(ah, c("go", "sabaeus"))
mydb -> res[[4]]

A query parancsnak bármennyi kulcsszót megadhatunk, ezek ÉS kapcsolatban lesznek. Az eredmény egy lista azokkal az adatbázis azonosítókkal, melyek megfelelnek a keresési kritériumoknak. Az adatbázis elérhető mezőiről az mcol parancs ad felvilágosítást. További részletekért érdemes megnézni az AnnotationHub dokumentációját.

 

Szólj hozzá!

Címkék: bioinformatika

Minix, az őserő

2020.05.10. 22:03 Travis.CG

Egy időben a prog.hu fórumon minden tejfeles szájú operációs rendszert akart írni, amihez csapatot toborzott. Ez alól természetesen én sem voltam kivétel. Utólag visszanézve ezeknek a kezdeményezéseknek a 99%-a elenyészett, a maradék egy százalék pedig egy poros CD tokban hever valahol a warez filmek mellett. De mégis, honnan szerezhet ehhez megfelelő tudást valaki?

A válasz Andrew S. Tanenbaum könyvében keresendő, aki oktatási céllal készített egy operációs rendszert, a Minixet. Az egyetem alatt az akkor még 10 floppy lemezt kitevő rendszert felraktam egy 386-osra, és azon tanultam meg a Unix alapjait.

A rendszer azóta sokat fejlődött, újabb szolgáltatásokkal bővült, ezért itt az ideje, hogy megnézzük, mennyire használható egy 20 éves laptopon.

Bár a floppys telepítés még elérhető, én mégis a CD verziót választottam. A telepítés simán ment, viszont a telepítés utáni teendőket manuálisan kell végrehajtani. Például, ha új felhasználót hozunk létre, akkor a home könyvtár root tulajdonú, nekünk kell beállítani. A támogatott hardverek száma kevés, még magyar billentyűzet kiosztás sincs alapból. Internet támogatás van, de csak minimális számú hálókártyához.

Viszont meglepően sok csomag található a rendszerhez. Sokan, akiknek csak egy minimalista webkiszolgáló kell, Minixet használ, ezért van Apache, Python (igaz, csak 2.7 verzió), PHP. Sőt, X kiszolgáló is van! A programok nagy részét csak neten keresztül lehet telepíteni, de a csomagkezelő erről az FTP szerverről szerzi be a szükséges fájlokat. Elméletileg ezek CD-re írva is telepíthetőek, ezt ki is fogom próbálni.

Pár csomag elérhető a telepítő CD-n is, mint a C fordító, Python, Perl. Ezekkel már lehet kezdeni valamit, aki nagyon elhivatott. Nekem egy hello world szintű program telepítése is gondot okozott. Először, mert nem találtam a magyar billentyűzeten olyan fontos karaktereket, mint a #. Utána az ld-t hiányolta a fordító.

Apropó fordítás! GCC nincs, helyette az LLVM-el kell beérni, és mint említettem, Pythonból is csak az elvault verzió érhető el.

A rendszer nálam stabilan működött, de üresen is elég sok erőforrást vett el. A top szerint az 500 MHz-es CPU 50%-on pörgött. A fórumok tanúsága szerint nem ez a fő prioritás, hiszen egy oktatási céllal készült operációs rendszerről van szó. Ha a gépem netre tudnám kötni, valószínűleg jobban kihasználhattam volna a rendszer lehetőségeit.

Elsősorban azoknak jelenthet alternatívát, akik meg akarják tanulni a Unix környezetet, vagy a rendszer programozást.

Szólj hozzá!

Címkék: rendszergazda

Pan megmenti a világot

2020.05.03. 08:03 Travis.CG

Eddig elég sok negatív dolgot írtam az intézeti rendszergazdákról. Álmomban sem gondoltam volna, hogy egyszer egyikük megoldja egy problémámat. Pedig most pontosan ez történt!

Elkészültem a programmal, aminek az lenne a szerepe, hogy koherenciát csempésszen abba a kaotikus világba, amit úgy hívnak pályázati adminisztráció. A program egy lokális adatbázist használ, aminek az a feladata, hogy megkönnyítse az életemet, de ezt valami Microsoftos mellékízzel teszi.

A fejlesztői gépen egy Visual Studio 2015 volt, adatbázis kezelőnek pedig egy SQL Server 2012. A program elkészülte után megpróbáltam a Publish menüponttal egy telepítőbe tuszkolni mindent, de elsőre nem sikerült. Mint megtudtam, alapértelmezetten nem rak bele minden szükséges komponenst a telepítőbe. Miután kiválogattam, hogy a PDB fájlokat, DLL-eket is tegye mellé, akkor már használható lett az eredmény.

Gondoltam kipróbálom a telepítőt a feleségem gépén is, mert azon nincs fent a több giga Visual Studio, közelebb áll az adminisztrátor konfigurációjához, aki majd használni fogja a programot. Ekkor szembesültem vele, hogy a futtatáshoz kell egy .Net Framework, és egy SQL Server LocalDB.

Szerencsére be lehet állítani, hogy milyen függőségei vannak a programomnak, és azokat a telepítő próbálja meg letölteni. A .Nettel még nem is volt probléma, de a LocalDB nem akart települni. Illetve települt, de utána hibaüzenetet adott, a kész program meg kivételeket dobott, hogy a szervert nem találja.

A Stackoverflow szerint a baj az volt, hogy a letölteni kívánt függőség megváltozott ahhoz a verzióhoz képest, amivel fejlesztettem. Ezt én nem értettem. Hogyan tudna megváltozni egy több, mint nyolc éves program?

Közben a programot egyre inkább használni akarták, én meg kapcsolatba kerültem egy fertőzött emberrel, amitől az intézet vezetősége kitiltott. Kénytelen voltam a telepítést az intézet rendszergazdáira, azon belül is Pan-ra bízni. Mondanom sem kell, ő sem jutott közelebb a megoldáshoz.

Ezért készítettem még egy telepítőt, de most azt állítottam be, hogy ne töltse le a komponenst, hanem csapja a programom mellé. Erre több, mint nyolc hibaüzenetet dobott, hogy neki azok nincsenek meg. A Microsoft dokumentációja szerint nekem kell letölteni azt a komponenst, aminek az URL-je ott van a Visual Studio könyvtárhierarchiájának mélyén, és amelyiket a programom telepítésekor le is tud tölteni.

Rendben, akkor letöltöm én. A dokumentáció arra viszont nem tért ki, hogy mind a 32 bites, mint a 64 bites verziót le kell tölteni, és elhelyezni az XML-ek mellett x86, illetve x64 alkönyvtárakban, és akkor a Visual Studio mellékelni tudja. A telepítő már több száz megabájtra duzzadt.

Ez sem jött be. Azt a hibaüzenetet kaptuk, hogy "...SQL Network Interfaces, error: 50...". Ezt sem tudtam értelmezni, mert nem használtam hálózatot, lokális adatbázist adtam meg kapcsolatként. Közben Pan kiderítette, hogy hiába lesz telepítve az SQL Server, a program képtelen lesz használni az adatbázist, kivéve, ha előtte az SqlLocalDB parancssoros eszközzel létre nem hozzuk az adatbázis bejegyzést. Mi van? Nem ezért van a telepítő? Nem az lenne a feladata, hogy a felhasználónak ne kelljen parancssorban bogarászni?

Egyébként ez a OneClick telepítő megérne egy külön bejegyzést. Fogja az elkészített programot, és kérdés nélkül elrejti a felhasználó AppData könyvtárának a bugyraiba, olyan intuitív elnevezésekkel, mint 8342-12312-74. Mikor megkaptam a hibaüzenetet, győztem megkeresni a program helyét.

Hanem, amikor elkészült az adatbázis bejegyzés, települt az SQL Server, még mindig nem lehetett használni a programot. Nem stimmelt az SQL Server verziószáma! Ekkor tudtam meg, hogy három féle verziószáma van a programnak. Van egy, amit mi, halandók használunk: SQL Server 2012, van egy belső adatbázis verzió, ami 706, és van még egy verziószám, amit akkor ír ki, ha parancssorban turkálunk benne, ami V11. Tényleg szükség van minderre? A hibaüzenet szerint, nekem 852-es adatbázisra van szükségem. A táblázat alapján ez SQL Server 2016!

Mikor Pan először kezdett beszélni nekem arról, hogy a programom a 2016-os adatbázist vár, azt hittem túl sokat ivott. Hiszen nekem SQL Server 2012-m van. Csak tudom, mi van a gépemen, még a Visual Studio is kilistázza nekem az elérhető szoftver komponenseket, és ott csak a 2012 szerepel.

Azért megnéztem, mi van a gépemre telepítve. Legnagyobb meglepetésemre volt SQL Server 2008, 2012, 2016 is. Amikor elkezdtem használni a LocalDB-t, ott valahogy a 2016-t kezdte el használni, bár nem emlékszem, hogy felajánlotta volna, melyik verziót akarom használni. A Visual Studio OneClick telepítője viszont csak a 2012-t ajánlja fel, mint telepíthető függőséget.

Hanem ekkor még nem volt vége. Pan hiába rakta fel a 2016-os verziót a célgépre, az még mindig nem működött. Ugyanis ez a szemét SQL Server képes különböző verziókat egy helyen tárolni. Mikor Pan 2012-es verziójú adatbázist hozott létre a 2016-os SQL Serverben, akkor a programom még mindig nem működött. Amint rájött erre, és javította, azonnal futott minden.

Mindig is tudtam, hogy nem értek a Windows-hoz, de azt hittem képes vagyok megoldani bármilyen problémát. Itt viszont semmi nem az volt, aminek látszott. Teljesen érthetetlenek számomra a telepítő készítés logikája, az opciók, az alapérelmezett beállítások. Semmit mondó hibaüzenetek és szürreális megoldások. Pan mégis átlátta az egészet és végigevickélt rajta. Egy rossz szavam sem lehet rá ezután.

Szólj hozzá!

Címkék: rendszergazda

Mindenki szófa scener

2020.04.23. 22:49 Travis.CG

Emberek veszítik el szeretteiket, munkanélküliség, sosem látott gazdasági recesszió. túlterhelt kórházak, szükségállapot, kijárási tilalom több országban. Mindeközben mit csinálnak a demoscenerek? Természetesen partit tartanak, és buliznak.

Sokáig úgy tűnt, hogy a demó partik gerincét képező Revision bedobja a törölközőt, és elmarad, de a kockákat egy világjárvány nem állítja meg. Amíg áram és net van, addig parti is lesz. Csak kicsit máshogy.

Az otthonunk ugyanis már nem csak munkahely, iskola, mozi, edzőterem, hanem immár egy demó parti helyszíne is. Ami azt jelenti, hogy igazából egyik sem teljesen, ami kihat az élményre. Például ha a fotó kompó egybe esik az esti fürdetéssel, akkor az eredmény, hogy egyik sem sikerül igazán.

Én két dologgal készültem. Az egyik egy fotó volt, amit nem adtak le, a másik egy videó, ahol nem volt kép. De ezzel egy kicsit előre szaladtam.

Tehát kezdjük az elején. Egy héttel Revision előtt eszembe jutott, hogy akár csinálhatnék is valamit. Futtatható stuff szóba sem jöhetett, de a szokásos videó+fotó kombináció kivitelezhetőnek tűnt. Találtam egy félig használható zenét Shamen tíz éves CD-jén. Azért mondom, hogy félig használható, mert egészen jól indult, de három perc után témát váltott. Mivel a korábbi videómnál is az volt a legfőbb kritika, hogy túl hosszú, ezért itt elvágtam a zenét, hogy teljesen használható legyen.

Három nap alatt össze is vágtam az anyagot és feltöltöttem. Egy ponton nagyon aggódtam, mikor kérték a zeneszerző lakcímét. Ezt nem tudtam, de nélküle nem engedték feltölteni a cuccot. Végül beírtam valamit, majd jeleztem a szervezőknek, hogy mit tettem.

A fotóra egy 360 fokos kamera képét választottam. Bevallom, nem számítottam semmi galibára, de tudtam, hogy nem egy égbekiáltó eredmény.

A szombati kompók este 6-kor kezdődtek. A fotók egy része nagyon jó volt, de azt nem értettem, ha előválogatás volt, akkor a szőnyegről készült kép miért maradt benne? Végül is mindegy, de azért elkeseredtem egy kicsit. Az animációknál sem lett jobb kedvem. Nosfe ismét egy zajdemót adott be, és én első alkalommal örültem neki, hogy otthonról nézhetem ezt a rettenetet, és közel a hangerő szabályozó.

Majd jött az én entry-m, de a streamen csak valami feketeség látszott. Egyesek szerint még így is jobb volt, mint a zajdemó, de ez nem sok vigaszt jelentett. Majdnem fél perc lement, én meg úgy éreztem magam, mint 2010-ben, bár akkor hang nem volt. Szerencsére leállították a vetítést és elkezdték előről, de addigra annyira elment a kedvem mindentől, hogy tovább már nem is néztem, inkább olvastam.

Másnap azért ránéztem a streamre. A 8K elég vérszegény volt. A feltöltött alkotások böngészése közben még nekem is feltűnt, Jézus milyen aktív volt. Időről-időre feltűnik egy feltűnési viszketegségtől szenvedő valaki, aki a pocsék releaseket azzal ellensúlyozza, hogy egy ideológia mögé bújik. Ilyen volt annak idején a Horror Terror Elite Legion, most meg a Love Jesus.

Aztán elkezdődtek az Amiga demók. Igazából a vége felé elég hangulatos alkotások voltak, de nem ültem a székem mellé. Amit nagyon sajnáltam, az a Titan demó. Olyan ígéretesen indult, aztán ellaposodott.

A PC demók jó része valami keretrendszerrel készült. Még Godot is volt. A legrosszabb mégis az volt, hogy szinte lehetett látni, mely alkotások készültek saját motorral. Még a Unity demók is, amelyek öt éve még tehetség pótlásnak számítottak, olyan minőségű eredményt produkálnak, hogy csak nézek.

Nem tudom, mit is gondoljak az idei Revision-ről. Egyrészt jó, hogy a szervezők nem adták fel, és sikerült valamit összehozniuk. Nem látok a színfalak mögé, de szerintem elhivatottság kell ahhoz, hogy úgy is végrehajtsák az emberek a feladatukat, hogy nem felügyelik őket. Másrészt nem tudtam rákoncentrálni a compókra, annyi minden történt.

Szólj hozzá!

Címkék: demoscene

Közbeszól a valóság

2020.04.05. 22:35 Travis.CG

Egyik demópartin, mikor megkérdeztem valakit, hogy miért nem csinált produkciót, a következő válaszolta:

- Most real-ben nyomtam, nem volt időm molyolni.

A beszélgetés alakulása közben vált világossá számomra, hogy a mindennapi élet viszontagságai a "real", és nem az észlelt valóság. Egy pillanatra ha elfelejtjük a képzavart, egyet érthetünk, hogy néha fel kell kötni a gatyát, ha úgy akarunk véghez vinni valamit, hogy közben más frontról érkező támadásokat is vissza kell vernünk. Mint történt a most bemutatásra kerülő cikkünknél is.

Az első bonyodalmat a csapat bioinformatikusának eltűnése jelentette. Elhagyta az országot és beszüntette a kommunikáció minden formáját. Illetve az elején még egy-két hét csúszással válaszolt, majd a csúszások csak hosszabbodtak, hosszabbodtak, míg végül a végtelenhez nem kezdtek tartani.

Én vettem át a helyét és szomorúan tapasztaltam, hogy még a szekvenciák jó részét is magával vitte, hogy majd "dolgozzon" rajtuk. Néhány hibásan elnevezett szekvencián kívül nem sok maradt, no meg az ábrák, amelyeket valahogy elkészített. Jegyzőkönyv nélkül nehéz volt bármit is kiokoskodni.

Mikor beszálltam a projektbe, először az elkészült kéziratot kellett megnéznem, hogy azok elég részletesek-e, helytállóak-e a következtetések. Mivel ez is egy leíró jellegű cikk volt, elég hamar elvesztettem az érdeklődésemet. Pár választ odafirkantottam a kézirat szélére és letudtam.

Ilyen könnyen nem úsztam meg. Szépen, finoman megkértek, hogy nézzem át még egyszer. Még egyszer átnéztem, de továbbra is egy leíró jellegű cikk volt. A kéziratban szerepelt négy kladogram Salmonella törzsekkel. Az első a teljes genomok alapján készült. A második a központi gének alapján. Volt egy, ami az egyedi géneket vette alapul, végül egy, ami a genomi szigetek viszonyait tükrözte. A kladogrammok teljesen különböztek egymástól, nem mutattak sem időbeni csoportosulást, sem földrajzi izolációt. Négy teljesen különböző reláció volt.

A szöveg is ezt tükrözte. Mindegyik kladogrammról volt egy fejezet, és leírta, hogy ott mit lehet látni. Nem értettem, mi a célja a publikációnak, miért készült, miért kell ennyi különböző módszert belevenni, ami semmi érdemi konklúziót nem tartalmaz.

Ezért tartottunk egy megbeszélést, ahol felvilágosítottak a dolgok hátteréről. Megjelent ugyanis egy cikk, ahol európai Salmonella törzseket vizsgáltak, majd a cikk zárásaként levonták azt a következtetést, hogy a svájci törzsek magyar eredetűek, sőt egész Európát magyar Salmonella törzsek fertőztek be. Következtetésként mindenért mi vagyunk a hibásak.

Ezen néhányan nagyon felhúzták magukat. Egyesek odáig mentek, hogy olyan kijelentéseket tettek, miszerint "Magyarország támadás alatt áll". Eleinte jól is hangzott, hogy az országot az én kis számítógépem védi meg a gonosz felforgató elemektől, valahogy úgy, ahogy affektáló Hujber Ferenc is tette a katonai hírszerzés hackereként. A megbeszélés további részeként szidtuk a svájciak anyját, apját, az editort, aki átengedte a cikket, meg a bírálókat.

Tehát a cikk igazi célja az volt, hogy bebizonyítsuk, a svájci törzsek nem magyar eredetűek. Ezért volt a számtalan módszerrel elkészített fa. Bármelyiket is néztük, a két ország törzsei messze voltak egymástól. Ráadásul mi több törzset használtunk fel, aminek az egyik következménye az lett, hogy szerológiailag Salmonella Infantisnak tartott törzsekről kiderült, genetikailag semmi közük az Infantisokhoz.

Az első feladat az volt, hogy elő tudom-e állítani az ábrákat, a rendelkezésre álló adatokból. A teljes genomok szekvencia fájljai megvoltak, de az hiányzott, hogy mely géneket tekintették központinak, és melyeket egyénieknek. A genomi szigetekről nem is beszélve.

Itt tennék egy kis kitérőt. Ha fogunk egy csomó baktérium törzset, lesznek gének, amelyek minden törzsben előfordulnak, és lesznek, amelyek csak a törzsek egy részére jellemzőek. Tehát minden gén kaphat egy százalékos értéket, hogy a törzsek mekkora hányadában fordul elő. A központi, vagy core gének, amelyek a törzsek 90%-ban előfordulnak, míg az egyedi, vagy cloud gének csak maximum 10%-ban. Ezek a meghatározások igen képlékenyek, mert nem csak a százalékos határok szubjektívek, hanem az is, mikor tekintünk hasonlónak két gént. Melyik az a százalékos határvonal, amikor azt állíthatjuk, hogy a gének szekvenciái egyformák?

Sőt, van még egy probléma, ha már így belemerültünk a baktérium genomok elemzésébe. Ha csak a genomhoz feltöltött annotációt nézzük, akkor nem találunk meg mindent gént. Ugyan annak a génnek egy másik törzsben  másik neve lesz. Ezt úgy oldottuk meg, hogy minden baktérium genomot újra annotáltunk egységes módon.

A helyzetet tovább bonyolította, hogy a fák alapját képező többszörös illesztést két különböző módon is el lehet készíteni. Fogom a gének szekvenciáit és összefűzöm őket egyetlen virtuális szekvenciává (ezt a módszert követték a svájciak), vagy nem fűzöm össze, és a Mauve-ra bízom, hogy megoldja a problémát. Mondanom sem kell, két teljesen különböző eredményt kapunk.

Mivel a teljes genomok alapján készített fák megegyeztek azzal, amit én készítettem, feltételeztük, hogy a többi fa is ugyan olyan lenne, ha meglennének a szekvenciák. Úgy gondoltuk, a módszer reprodukálható.

Sajnos az összes képet módosítani kellett, mert a nevezék nem tetszett a csapatnak, más betűtípust akartak és módosítani akarták a kiemeléseket is. Mivel nem tudtam újra előállítani a képeket, kénytelen voltam Gimp-el átrajzolni a már meglévő ábrákat. Ez egy rendkívül unalmas meló. Már nem éreztem magam szuper hekkernek, csak egy szerencsétlen flótásnak, akinek hülye feladat jutott. Magyarország becsületének védelme egy grafikus programon múlik.

Igazából letölthettem volna a szekvenciákat, és elkészíthettem volna újra a fákat, de a többszörös illesztések több napot vettek volna igénybe, míg a Gimp-el egy óra alatt megvoltam. Mivel tapasztalatom szerint az ábrákkal mindig akad pepecselni való, ezért előrelátó módon a feliratokat külön rétegekbe raktam. Ezért a második, harmadik, sokadik módosítás már könnyen ment.

Ahogy teltek az idők, a kézirat gyökeresen megváltozott. A szerkezete megmaradt, továbbra is különböző módszerekkel elkészített fák voltak benne, de ezek kezdtek egy egységes koncepció köré csoportosulni. Az ábrák is egységes stílust kaptak. Összeállt az anyag. Tartottunk egy utolsó megbeszélést, ahol ismét elszidtuk a svájciak anyját mindennek, lehülyéztük őket, mindezt olyan magas röptű stílusban, ahogy csak az akadémiai szférában lehetséges.

December 24-én kaptuk meg a bírálók anyagát. Azt szerették volna, ha több törzset veszünk be a vizsgálatokba és megnézzük az antibiotikum rezisztencia géneket is. Eredetileg ezt nem akartuk, de ezek után kénytelenek voltunk ezt is megcsinálni. Egyedül a határidővel volt probléma, mert egy hónapot adtak minderre, ami figyelembe véve az Ünnepeket, tarthatatlannak bizonyult. Rögtön halasztást kértünk, amit meg is kaptunk.

Közben újabb bonyodalom történt, az egyik szerző balesetet szenvedett, így az ő segítségét nélkülözni kellett.

Letöltöttem az új baktérium szekvenciákat, hozzácsaptam a korábbi genomokhoz, amelyekkel korábban dolgoztam és elkezdtem az elejéről mindent. Most már meg kellett csinálni az összes illesztést, annotálást. Már nem volt elég Gimpezni. De a sok munka mellett volt ennek egy előnye is: Nem kellett a régi ábrákra, elnevezésekre támaszkodni, ezért minden szekvencia, annotáció, kép, egységes nevezéket kapott. A szekvencia fájl neve, azonosítója ugyan az lett, később ez a név jelent meg a fákon is. Ezzel eléggé fel tudtam gyorsítani a munkát.

Ennek során megszegtem az egyik elvemet, miszerint nem használok szóközt fájlnevekben, de azt hittem sokkal egyszerűbb lesz a munka. A munkafolyamat nagy részén igazam is volt, a dolog akkor bukott meg, mikor a Roary képtelen volt azokat a fájlokat beolvasni, amelyek szóközt tartalmaztak. Ezt leszámítva, nem volt fennakadás, a neveket végig lehetett követni a munkafolyamat teljes hosszán.

Azért aggódtunk egy kicsit, hiszen említettem, hogy a központi és egyedi gének meghatározása elég szubjektív. Félő volt, hogy eltérő eredményt kapunk, és az egész diszkussziót új alapokra kell helyeznünk. Szerencsére az új fák nagyon hasonlóak lettek, csupán több törzset tartalmaztak. A svájci-magyar kapcsolat továbbra sem tűnt valószínűnek.

Tartottunk egy megbeszélést, ahol megvitattuk az új eredményeket. A vége felé ismét szóba került a svájciak anyaja, apja, és konstatáltuk, hogy a bírálók (akik bizonyára svájci szimpatizánsok) terve nem jött be, nem tudnak megállítani minket. Már csak az antibiotikum rezisztencia rész volt vissza, de abban nekem nem volt szerepem. Még az ábrák végső formáját sem kellett megcsinálnom, aminek örültem.

Hanem, az antibiotikum rezisztencia kapcsán az egyik szerző észrevette, hogy a magyar törzsekből hiányzik néhány olyan gén, amelyek létezéséről egy korábbi publikációban írtunk. Kiderült, hogy a magyar törzsek szekvenciái hiányosak. Néhány kontig hiányzott ahhoz képest, mint ahogy annak idején feltöltöttem az NCBI-ba.

A helyzet az, hogy a munka legelején, mikor átvettem a volt kolléga fájljait, nem ellenőriztem teljesen a szekvenciákat az NCBI-ban található verziókhoz képest, csak megnéztem, mekkora a fájlok mérete, az meg nagyjából stimmelt, nem foglalkoztam a dologgal. Ez elég súlyos hiba volt a részemről, még szerencse, hogy nem a bírálók vették észre. Tehát még egyszer letöltöttem mindent, összeraktam a genomokat, annotáltam őket, felépítettem a fát. Viszont ez már koránt sem volt akkora munka, mint korábban, mert Jupyterben volt a teljes elemzés, dokumentálva minden lépés. (Mikor az egyik bíráló arról beszélt, hogy a módszerünk nem megismételhető, akkor megkapta a linket.) Csupán kicseréltem a szekvenciákat egy könyvtárban, és mondtam, hogy futtasson le mindent.

Viszont az eredmények láttán majdnem hagyatt estünk. A svájci és magyar törzsek minden egyes elemzésben szépen együtt klasztereződtek. Egészen pontosan a magyar törzsek két csoportra oszlottak, az izolálás idejétől függően, és az újabb izolátumok tényleg a svájciakkal egy csoportba kerültek.

A csapat becsületére legyen mondva, ezután nem szidtuk a svájciak anyját, hanem elfogadtuk az eredményeket. Ezekért a pillanatokért szeretem a tudományt, amikor nem a prekoncepció, az érdekek alapján vonunk le következtetést, hanem a színtiszta adatok alapján. Nem próbálták rám erőltetni, hogy "használjunk másik programot", "másik statisztikát". Nem volt vádaskodás, hogy "biztos elszúrtad", "ez nem lehet". Át kellett írni mindent és a csapat ezt professzionálisan meg is tette. Elküldtünk mindent, mire meg is jött a válasz, hogy a bírálók mindent rendben találtak. Hurrá!

Hanem a befektetett munka miatt a szerzők sorrendje megváltozott. Emiatt mindenkitől beleegyező nyilatkozat kellett, hogy ehhez hozzájárul. Attól a bioinformatikustól is, aki beszüntette a kommunikációt. Ekkor felmerült a lehetőség, hogy ha nem érkezik válasz tőle, akkor kihagyjuk a cikkből. Ez nekem nagyon nem tetszett. Én sem szeretem, ha engem hagynak ki, ezért ahol lehetett védtem az érdekeit.

Ezzel sikerült is jól magamra haragítani pár embert. Ha ugyanis ki akartunk volna hagyni valakit, akkor a cikket vissza kellett volna vonni, majd újra beadni a módosított szerzőkkel. Kezdhettünk volna a teljes procedúrát előről. Ezért azt javasoltam, hogy mi lenne, ha mégsem változtatnánk meg a szerzők sorrendjét. Nekem estek, hogy miért védem azt, aki "ennyire hátráltatta a cikk megjelenését", meg "miért nem képes válaszolni".

Csak halkan jegyzem meg, hogy aki a leghangosabb volt, az egy korábbi cikkünknél szintén hátráltatta egy évig a publikálást, mert családi zűrjei voltak. Elég gyorsan elfelejtette ezt.

Egyébként csupán pragmatikus célok vezettek, hiszen ha vissza kell vonni a cikket és újra beadni, akár az is megeshet, hogy az új bírálók elkaszálják a cikket, és az mindenkinek rossz lesz. De mások ezt nem látták, nekik fontosabb, hogy első szerzők legyenek. (Nekem nem fontos, meg is látszik :-)

Szerencsére az elveszett munkatárs végül válaszolt, és nem kellett drasztikus dolgokhoz folyamodni. Aztán elért minket is a világjárvány, a cikk utolsó simitásait már otthonról végeztük.

Ennek a munkának rengeteg tanúsága volt számomra. Először is, ahogy Richard Marcinko is megmondta: Soha ne feltételezz! Ha kapsz egy fájlt, nem feltételezed, hogy jó. Ha látsz egy ábrát, de semmi leírást róla, akkor nem gondolod, hogy "biztos X-el készült". Második tanúság: Ha valamit rendesen is meg lehet csinálni, akkor úgy csináld, még akkor is, ha ez több időt vesz igénybe. Ha mindjárt az elején vettem volna a fáradságot, hogy rendesen elnevezem a fájlokat, elkészítem a munkafolyamatot, akkor megkíméltem volna magam egy csomó Gimp-es bohóckodástól. Végül pedig felejtsük el a prekoncepciókat. Itt mi meg is tettük, de mikor először megláttam az új eredményeket, féltem, hogy nagy veszekedés lesz miatta. Szerencsére a genetikai eredményeket a tőlem függetlenül végzett antibiotikum rezisztencia vizsgálatok gyönyörűen alátámasztották.

Szólj hozzá!

Címkék: publikáció

Enterprise 128, első benyomások

2020.04.03. 23:45 Travis.CG

Az Enterprise 128 régóta egy vágyálom számomra. Gyerekként a gépeket nem fejlesztettük, hanem újab vettünk. Ezért az egészséges versenyszellem keretében nem azzal fejeztük ki felsőbbrendűségünket, hogy semmitmondó processzor paraméterekkel dobálóztunk, hanem félig lehunyt szemmel kimondtuk gépünk nevét.

Ebben a - mai szemmel nézve nevetséges - versenyben a legtöbb gép 64 kilobyte memóriával volt ellátva. A következő nagy ugrás a 128 kilobyte-os gépek voltak. A C128 és az Enterprise. Az Amiga már akkor is a király kategória volt, azok nem versenyeztek mikroszámítógépekkel, hanem különböző bővítő kártyákkal felvértezve egymással mérték össze erejüket.

Én erről akkor semmit sem tudtam. Nem jártam klubbházakba, copy partikra. Számomra az informatika fejlődéséről egy műszaki bizományi kirakata adott felvilágosítást, ahol az elérhető legjobb gép az Enterprise volt. Szép, színes gombjai voltak, beépített joystick, sztereo hang, és nem utolsó sorban 256 szín. Hazafelé az iskolából mindig megálltam a kirakat előtt és megnéztem a gépet. Aztán a gépet eladták, én meg még évekig játszottam a C64-el, majd jöttek a PC-k. Az Enterprise feledésbe merült.

Mikor megismerkedtem a demoscene-vel, ahol nem nézik hülyének az embert, mert használhatatlan gépeket programoznak, ismét felrémlett bennem, hogy akár még szerezhetnék is egy ilyen gépet. Az idők viszont megváltoztak, gyakran tetemes pénzt kérnek el ezekért a gépekért, mert retro. (Ez a retro őrület azért kicsit túlmegy a józan ész határain. A legdurvább eset ezzel kapcsolatban, mikor egy bolhapiacon ezer forintot akartak elkérni egy kicsi, koszos gumilabdáért, mondván, hogy ez nem gyerekeknek van itt, hanem gyűjtőknek.)

Nem akartam egy fél vagyont egy Enterprise-ra költeni, amit még a maga idejében sem vásároltak, miközben Grass azzal dicsekszik nekem, hogy valami ócskásnál ötezerért talált egyet. (Ilyenkor bezzeg nem gondol rám.) Ezért csak különösebb cél nélkül böngésztem a különböző weboldalakat, eredménytelenül.

Azért néha nekem is lehet szerencsém. Találtam egyet, ami ha nem is ötezer volt, de az a kategória, amire azt mondtam, hogy "egye fene". (A feleségem inkább megrökönyödött, hogy milyen hülyeségeket vásárolok, de ez egy másik kérdés.) Így lettem egy Enterprise boldog tulajdonosa.

Azért a gépről igencsak hiányos ismereteim voltak, ami rögtön meg is mutatkozott, mikor kibontottam a csomagot. Először is, nincs rajta bekapcsoló gomb! Mintha nem is számítógép lenne, hanem egy hűtőszekrény, vagy vasaló. Szinte nincsenek is rajta csatlakozók, csak kivezetések az alaplapról.

Azt sem tudtam, hogy a gép kétféle billentyűzet kiosztással került forgalomba. Egy némettel és egy angollal. Természetesen németet vettem, német hibaüzenetekkel. (Később tanultam meg átállítani angolra.) Azt sem értettem, mit ír ki a gép. Ha már a billentyűzetnél tartunk, az valami katasztrófa. Egyszer régen vettem egy összehajtható gumi billentyűzetet, mondván az milyen menő, de használni valami borzalmas volt. Az Enterprise billentyűzete még ennél is rosszabb. Egyáltalán nem kényelmes, szenvedés használni. A 10 print "hello", 20 goto 10 program megírása itt volt a leglassabb.

Először be sem tudtam kapcsolni. Kaptam hozzá egy SCART csatlakozót, amit ha beköttöttem, és még a magnót is rákapcsoltam, nem volt képe. Ha nem kötöttem be a magnót, akkor halványan felderengett a gép képe. Kétszázötvenhat szín? Egy színt láttam, 5 árnyalatban.

Végül maradt az RF csatlakozó, mert úgy bejöttek a színek. A kazettáról a cikk megjenéséig még nem sikerült betölteni semmit, mert a betöltésnél a hangerő szabályozó állása nem mindegy milyen szinten áll. Ezt a képernyő tetején egy szines csíknak kellene jeleznie, ha a hangerő megfelelő.

Ennyit a negatívumokról. Lássuk, melyek az értékek. Először is, a BASIC értelmező egy kis dobozban, külön kapott helyet a gép oldalában. Ez hallatlanul jó ötlet. C64-en nekem nagy fájdalmam volt, hogy közönséges BASIC-ből nem lehet elérni a grafikát. Volt ugye a Simon's Basic, ami orvosolta ezt a problémát, de ha azt is betöltöttük, újabb értékes memóriát vesztettünk. Enterprise alatt erről szó sincs. Az egyetlen probléma, hogy a gép ezen tulajdonságát nem használták ki annak idején. A modern kor felhasználói azok, akik ide terveztek egy SD kártya olvasót.

A hardver elég erős, hogy más Z80 számítógépet emuláljon. Tehát elméletileg a ZX Spectrum és Amstradt CPC demók is futhatnak rajta. Majd meglátjuk, ki fogom próbálni. A gép még most is szépnek tűnik a maga egyedi megjelenésével. Még a lányom is ki akarta próbálni, annyira tetszett neki.

enterprise.jpg

Meglepő, de kicsi és csendes közösség formálódott a gép köré. Nekik is van klubbjuk, szerveznek találkozókat, és jól elvannak. Ezt elég furcsa látni az Amigás közösség után, akik nagyon hangosak tudnak lenni, és napokon keresztül el tudnak vitatkozni azon, mi is az Amiga.

Az első benyomások nem túl pozitívak a részemről, remélem a későbbi kalandok érdekesebbek lesznek.

Szólj hozzá!

Címkék: enterprise

BitLocker-es pendrive olvasása Linux alatt

2020.03.22. 22:29 Travis.CG

Időről-időre megpróbálnak kitolni a Linuxosokkal, de azok elég jól veszik az akadályokat, noha a megoldás során néha-néha csúnyább szavak is előfordulnak szókincsünkben.

Az egyik ilyen akkor történet, amikor szekvenálási eredményeket kaptunk BitLockerrel titkosított pendrive-on. A tároló sertés metagenomikai mintákat tartalmazott. Hiába, már a disznók belében élő baktériumok személyiségi jogaira is tekintettel kell lennünk.

Mindegy, a lényeg, hogy nekem el kellett olvasni a tartalmát. Az egyetlen elérhető program a dislocker. A fordítása fájdalommentes, a szükséges dependendciák szinte minden repoban megvannak. A használata koránt sem triviális. A dokumentáció szerint csak egy bejegyzés kell a /etc/fstab fájlba, és már kész is.

Ne higgyünk neki.

Mivel az eszköz titkosított, az automount megdöglik rajta. Az lsblk parancs segítségével kell kideríteni, USB tárolónk melyik eszközleírót kapta. Ha megtudtuk, kezdődhet a munka érdemi része.

Először is dekódolni kell a partíció tartalmát:

sudo dislocker -r -V /dev/sdc1 -u pendrive

Itt meg kell adnunk a dekódoláshoz szükséges jelszót. Ha a pendrive egy könyvtár, akkor lesz benne egy dislocker-file nevezetű állomány. Ez a teljes partíciót tartalmazza egyetlen fájlban. Használatához ezt még egyszer csatolni kell, pont úgy, ahogy egy ISO képfájllal is teszi az ember.

sudo mount -o loop,ro pendrive/dislocker-file pendrive2

Na, ekkor érhetjük el a fájlokat a pendrive2 könyvtárban. Erre azért van szükség, mert a dislocker csak dekódol, a partíciókat magukat nem kezeli.

Szólj hozzá!

Címkék: rendszergazda

A publikációk ábráiról

2020.03.18. 22:15 Travis.CG

A kutatók néha olyanok, mint a gyerekek. Nagyon akarnak egy ábrát. Minden nap rágják a fülem: az nagyon jó ábra, olyan kell az én cikkembe is! Elkészítem nekik, mire a következő hónapban már egy másik ábrára fáj a foguk, amit megláttak kedvenc újságjuk hasábjain.

Az ábráknak az a feladatuk, hogy információt közöljenek. De egyes ábrák nem adnak semmi új információt, csak szokatlan köntösben mutatnak valamit, amit egy oszlop diagramm is képes bemutatni, de ez elég egyes kutatóknak, hogy zombi üzemmódba kapcsoljanak. Szemük üvegessé válik, réveteg mozgással kezdenek közlekedni, és nem azt kántálják: "agy, agy", hanem "ábra, ábra". Ebből az ábra éhségből csak a filmekből  ismert módon gyógyíthatóak ki.

Az első ilyen ábra a floral venn-diagram. Mikor meghallottam, nem erre gondoltam. A venn diagrammnak az a lényege, hogy lássuk, az egyes kategóriákban mennyi átfedés van. Pont ez az, amit a floral venn-diagramm nem mutat meg. Megkérdezték, tudnék-e ilyet készíteni. Azt válaszoltam, ilyet mindenki tud készíteni, még a hat éves lányom is. Kell rajzolni egy virágot, a szirmaiba meg számokat kell rakni. Szerintem ehhez nem kell dedikált R csomag, csak egy Paint.

A második eset több fordulós volt, mint egy mérkőzés. Először egy PowerPoint prezentációt kaptam, amiben megláttak egy szép interakciós hálózatot. Olyat akartak, függetlenül attól a ténytől, hogy nem volt egyetlen iterakciós adatuk sem. Megsajnáltam őket, és mondtam, hogy a GO adataikból lehet hasonlót csinálni, de az biztosan nem ilyen lesz, mivel a GO egy irányított aciklikus gráf. Természetesen nem ezekkel a szavakkal mondtam el, mert ettől kiolvadt volna az agyuk. Ennek ellenére láthatóan csalódottak volta, amikor meglátták a végeredményt.

Ezután jó ideig nem kellett semmit csinálni nekik, de ők tovább olvasták a cikkeket, és csak idő kérdése volt, hogy valami kiváltja náluk a nyálfolyást. Következő kiszemeltjük a toxpi ábra volt, amit egyetlen programmal, a ToxPi-al készíthetünk el. Bevallom, nekem többszöri nekifutásra sem sikerült kitalálni, mit is csinál ez a program. Valami adatokat be kell nekik adni, amitől kiszámolja a ToxPi pontszámot. Kaptam egy cikket is, amibe a normalizált expressziós adatokat felhasználva elkészítették ezeket a szörnyű kör diagrammokat.

A cikk alapján ugyan azzal a módszerrel elkészítettem az ábrákat az ő adataikra is, de az eredménynek semmi értelme nem volt. Főleg azért, mert nem lehetett tudni, mit jelent az eredményül kapott pontszám. A levélváltások során teljesen egyértelmű volt, hogy a partnereknek fogalmuk sem volt, mit várnak az ábrától, de látták, hogy van ilyen, akkor nekik is kell.

Egy korábbi munkahelyemen sem volt elég ha R-ben elkészítettem az ábrákat. Azt a kritikát kaptam, hogy az "összes kínai ilyen ábrát produkál a cikkeiben". Nem értettem, ez miért baj. Nem sztárokról írunk pletykákat, hanem tudományos eredményt mutatunk be. Ennek ellenére olyan erős volt a nyomás az egyedi ábrák elkészítésére, hogy egyik munkatársam soha nem olvasta el a rendszeresen kézhez kapott folyóiratokat, csupán ebéd előtt átlapozta, hogy van-e benne "érdekes ábra". Ha nem volt, bele sem olvasott.

Szerintem elsődlegesen jó cikket kell írni. Jó cikk alatt azt értem, hogy a módszerekbe ne lehessen belekötni, az alkalmazott statisztika kifogástalan legyen. Ha ez mind megvan, akkor ezt megkoronázhatjuk egy olyan ábrával, ami szemléletesen bemutatja az eredményeket. Ha csak azért akarunk szép ábrákat, hogy a bírálókat hipnotikus állapotba hozzuk, hogy könnyebben elfogadják a cikket, akkor érdemes lenne új karrier lehetőség után néznünk. Mondjuk egy sztármagazinnál.

Szólj hozzá!

Címkék: filozofálás

Vesztes csaták megvívása

2020.03.13. 15:13 Travis.CG

Ha egy munkán elsőre látszik, hogy biztosan nem lesz belőle értelmes eredmény, azt nem kell elvégezni. De mi a helyzet azokkal a munkákkal, ahol kb. 90%-ig vagyunk biztosak, hogy felesleges? Mi a helyzet, ha ezzel a véleményünkkel egyedül vagyunk?

Ezek a vesztes csaták, amit meg kell vívni, mert nem bizonyítható teljesen, hogy vesztesek. Ezek csak kósza érzések, amelyek alapján senkit nem lehet meggyőzni, hogy az erőforrásokat másra fordítsuk. Plána, ha valakinek annyira megbízhatatlanok a megérzései, mint nekem.

A bioinformatikusokra általánosan igaz, hogy a világ összes számítástechnikai kapacitása sem lenne nekik elég, mert bármennyi erőforrást is kapnak, csak még több folyamatot futtatnának, még nagyobb memória igénnyel, több processzor maggal, stb. Ezért, mikor kaptunk egy lehetőséget, hogy ingyen és bérmentve verjünk el 1 csillió dollárt az Azure-on, rábólintottunk. (Ezt csak a hatás kedvéért írtam, a tényleges összes alacsonyabb volt. De tényleg rengeteg pénzről volt szó.)

A Microsoft mostanában erősen lobbizik az akadémiai szférában, hogy a szolgáltatásait minél többen használják. Ezért cukorka helyett hatalmas pénzösszegeket vágnak csoportokhoz, hogy rászoktassák őket az Azure használatára. Az egyik ilyen csoport is, akik tématerveikben dobálóznak az aktuális trendek vezérszavaival (big data, machine learning, stb.), kaptak is 1 csillió zsét meghatározott időre. De nem költötték el, mert nem értettek a cloud használatához.

Mikor már csak két hét volt vissza a határidőből, akkor kezdtek aggódva rohangálni, hogy mit is csináljanak. Ekkor léptünk mi a színre, akiknek ugye nem probléma processzorokat, tárhelyet és memóriát teleszemetelni mindenféle adattal, kutatás címszóval.

Az első hiba a rendszerben az volt, hogy nem mértük fel, mire is van szükségünk. A terv az volt, hogy egy teljes GATK folyamatot futtatunk több száz mintára. Ehhez a mintaszámnak megfelelő mennyiségű 20 magos gépeket kértünk, amelyek reményeink szerint 12 óra alatt emésztik fel a rendelkezésre álló pénzösszeget. Csakhogy 12 óra alatt még senki a csoportból nem futtatott le GATK-t.

A második hiba az volt, hogy nem használtuk ki a felhőben rejlő lehetőségeket. Az összes nagy szolgáltató lehetőséget biztosít, hogy egyszerre felügyeljünk több gépet, van load balancing, virtuális gép képfájlok létrehozása, mozgatása, paraméterezett számítógép indítás, speciális adatbázisok, stb. Ezekből én semmit nem kaptam. Még azt sem engedték meg, hogy magam indítsam a gépeket. Adtak egy mester gépet hatalmas tárhellyel, de szerény teljesítménnyel, és két darab nagy teljesítményű gépet, hogy készítsek egy rendszert, ami megoldja az adatok, programok, stb. utaztatását és a feldolgozás vezérlését. Ha pedig elkészültem a tesztekkel, akkor elindítják nekem az összes igényelt gépet.

Történt még egy apró konfigurálási hiba a részemről, ugyanis a mester gép tárhelyén MBR partíciót hoztam létre, és utána csodálkoztam, miért csak 2TB-ot tudok elérni a 16-ból. Túl sok retro géppel bohóckodom.

Ekkor kezdtem úgy érezni, hogy ez egy vesztes csata lesz, de adtam még 30% a győzelemre. Neki is álltam a "szegény ember Dockerét" megírni. A szkript először yum-al felpakol egy csomó szükséges szoftver komponenst, majd a pip végez telepítéseket. Amint ezek megvannak, a mester gépről scp-vel lemásolja a bioinformatikai programokat, genom fájlokat és egy minta szekvenciáit. Snakemake-el lefut a GATK, majd az eredményeket visszamásolja a mester gépre.

Ez volt a könnyebb része. Hogyan indítsam el a felmásolt szkriptet? Az szóba sem jöhetett, hogy több száz gépre egyenként lépjek be, és adjam ki a parancsokat. Szerencsére az ssh képes parancsot futtatni távoli gépen. Ez bárki ki is próbálhatja egy egyszerű példán:

ssh remote 'ls -la'

Hátránya, hogy amíg a távoli parancs fut, addig fenntartja a kapcsolatot a két gép között, addig nem kapom vissza az irányítást a mester gépen, amíg a parancsoka le nem futnak. Ha több száz gépet akarok vezérelni, akkor mindegyik gépen az elemzés egymás után lesz végrehajtva. Nekem viszont párhuzamos végrehajtás kell.

Ezért készítettem még egy szkriptet, aminek semmi más dolga nem volt, mint nice-al a háttérben futtatni az első szkriptet. A mester gépről ezt kellett csak elindítani. Ez az indítás után azonnal visszaadja a vezérlést nekem. Valami ilyesmi formája van:

nice poormansdocker.sh $1 &

A tesztek ígéretesen haladtak, de azért volt pár probléma. A két tesztelésre adott gép nem volt teljesen ugyan az. Az egyik CentOS volt, a másik Oracle Linux. Bár mindkettő Red Hat alapokon nyugszik, de természetesen teljesen más csomagokat lehetett elérni hozzájuk, például Oracle Linuxon nem lehetett fejlesztői csomagokat telepíteni 3-as Pythonhoz. Ettől nem fordult a Snakemake és nem ment az elemzés.

A másik probléma az idővel volt. A tesztek alapján csak az illesztés 30 óráig futott. Különböző trükkökkel sikerült 27 órára lecsökkenteni, de ez még mindig messze volt az áhított 12 órától, és a leglassabb lépést, a HaplotypeCaller-t még nem is számoltuk. Ekkor már 85% esélyét láttam a kudarcra.

Jött az új terv: csak az illesztési lépést hajtjuk végre, de nem több száz mintára, csak a "legfontosabbakra". Nos, a legfontosabb mintákból 18 hiányzott, és senki nem tudta, hol vannak. Elvesztek valahol a Dropbox-Excel-PhD hallgatók Bermuda-háromszögben.

Az idő közben szorított, mert a határidő közelített, az elemzésre szánt idő viszont hosszabbodott. Végül elindították nekünk a száz gépet. A szkriptet módosítottam, hogy a munka befejeztével kapcsolja ki a gépt. Itt viszont elkövettem a második fiaskót. Abban a hiszemben voltam, hogy ezek a gépek olyanok lesznek, mint amiket tesztelésre kaptam, és nem ellenőriztem ezt. Természetesen nem olyanok voltak. Hiányzott róluk a privát kulcs, amivel elérhetik a mester gépet.

A szkripteket felmásoltam, azok telepítettek mindent, megpróbálkoztak az adatok letöltésével. Ez nem sikerült nekik, ezért búcsút intettek, és lekapcsolták a gépeket. Akkor módosítottam az indítást, hogy ne csak a szkripteket másolja ki, hanem a kulcsokat is, a lekapcsolást pedig kivettem, hogy elkerüljem az újabb bonyodalmakat. (Mivel nem az én kezemben volt az irányítás, ezért emaien kellett kérnem, hogy indítsák újra a gépeket.)

Ez már jól ment. Hanem az előzetes terveket egy újabb fejlemény nehezítette: a száz gép egyszerre rácuppant a mester gépre, és próbálták letölteni az adatokat, amitől persze minden másolás lelassult. De mikor letöltöttek mindent, akkor végre egy kellemes meglepetés is történt. A 30 órás tesztfutásokhoz képest valami csoda folytán az illesztések lementek 8 óra alatt. Hurrá, végre valami jó is történt!

Ezután kicsit összekuszálódtak számomra a történések. Egyik nap még arról volt szó, hogy ezzel a felgyorsult futással az 1 csillió pénznek csak a felét költöttük el, másnap reggelre viszont kiderült, hogy mindent elköltöttük. Nem tiszta, mi is történt. Kicsit furcsa volt, az biztos.

Már csak az adatokat kellett lementeni. Ez sem ment zökkenő mentesen. A BAM fájlok letöltése olyan hosszúra nyúlt, hogy attól féltünk, lekapcsolják a gépeket, mielőtt letölthetnénk az összes mintátt. Ezért különböző gépekre pánik-szerű letöltéseket kezdtünk. Minden további kapcsolat persze lassabb volt, de szerencsére nem lassították a már elindított letöltéseket.

Végül sikerült mindent letölteni, és a gépeket lekapcsolták. A vesztes csata végül nem vereséggel végződött, mert határidőre elköltöttük a pénzt, és a munkával is előrébb jutottunk, de győzelemnek nem könyvelném el, hiszen még rengeteg futtatás van vissza. Az illesztés igazából csak az alapja mindennek.

Az ár egyébként érdekes gondolatokat vetett fel bennem. Alapvetően elég sok pénzbe került, de ha azt nézzük, hogy ezért a pénzért kb. 2 darab Dell munkaállomást lehetne venni, közel hasonló specifikációban (közbeszerzést és egyéb, a kutatók életét színesítő eseményt figyelmen kívül hagyva), akkor már nem olyan durva a helyzet. Mi pedig kaptunk száz számítógépet, igaz, csak két napig. Ha az áramot nem számoljuk költségként, és továbbra is 8 órát adunk egy illesztésre, akkor a két munkaállomással 20 nap alatt végeztünk volna.

Számomra meglepetés volt, hogy a sávszélesség költsége minimális volt. Négy terabyte adatot töltöttünk fel, ez az adat mennyiség utazott a gépek között, végül az eredmény BAM-ok is hasonló nagyságrendben mozogtak, ennek ellenére a költségek fél százalékát tették ki.

A tárhely sem volt vészes. A teljes költség 10%-t emésztette fel. A száz gép 400GB SSD-t használt két napig, a mester gépen pedig 16TB tárhelyet használtunk két hétig.

De ha azt nézzük, hogy ingyen kapunk szuperszámítógép hozzáférést (aminek használatával be fogom fejezni a munkát), akkor elképesztően drága.

Szólj hozzá!

Címkék: rendszergazda cloud computing

tmux: screen szteroidokon

2020.03.01. 22:52 Travis.CG

A screen-t nagyon szeretem, mert megadja nekem mindazt a terminál támogatást, amit egy SSH kapcsolat elvesz tőlem. Egyik hátránya, hogy könnyű elveszni a megnyitott ablakok sorában. Másik hátránya, hogy néha jó lenne két ablakot látni egyszerre, amit jobb híján az ablakok gyors váltogatásával próbálok orvosolni.

De mindez már a múltté, mert megismertem a tmux-ot. Ebben nem csak különböző ablakokat nyithatok meg, de a képernyőt fel is bonthatom kisebb darabokra, vizszintesen vagy függőlegesen. Az egyikben futhat a top, miközben a másikban írhatom a szkriptet, amivel felzabálom az erőforrásokat.

Ha ez még nem lenne elég, kapok kis státusz mezőt a képernyő alján, ahol láthatom, mennyi ablakot nyitottam meg, melyik az aktuális, mi a pontos idő, melyik gépen vagyok. Nem keverednek össze a munkafolyamatok.

A mágikus billentyűkombináció, a ctrl + b (szemben a ctrl + a-val, amit a screennél használtunk). Ez azért is jó, mert a screen belsejében indíthatok tmux-ot. Ennek természetesen alapvetően nem sok értelme van, én is egy véletlen folytán jöttem rá, de akkor nagyon hasznosnak bizonyult.

Nekem ugyanis be kell lépnem A gépre, hogy elérjem B gépet, ahol az érdemi munkát végzem. De néha A gépen is kell dolgozni. Ha A gépen elindítom a screen-t, majd egy másik ablakban belépek B gépre, ahol tmux-ot futtatok, akkor A gépen a screen parancsaival tevékenykedhetek, míg a tmux-al szabályozhatom B gépet. Nem állítom, hogy ez egy követendő példa, vagy értelmes munkamódszer, de meg lehet tenni.

A dokumentációja külön weboldalt kapott. Ezért bárki azonnal megtalálja a neki szükséges billentyűzet kombinációt.

 

Szólj hozzá!

Címkék: rendszergazda

Az 5.25-ös floppy esete

2020.02.22. 22:39 Travis.CG

Nálam a retró számítógépek felhalmozásának van határa. Ezek közül az egyik, hogy olyan eszközt nem szerzek be, amit nem használok. (De azért senki se firtassa, mikor kapcsoltam be utoljára az Amigámat) Azért, hogy rámutassak egy porosodó vasra, hogy van, szerintem semmi értelme. Éppen ezért soha nem akartam olyan gépet, amiben 5.25-ös floppy van.

Az assembly/demoscene tudásom elmélyítésére szükségem volt a VGA kártya programozása Pascal és assembly nyelven című könyvre. Hosszasan keresgéltem a net bugyraiban, de nem találtam. Végül egy könyvtárközi kölcsönzéssel szereztem meg.

Maga a könyv érdekes, de ami még érdekesebb volt, hogy elküldték a lemez mellékletet is, ami nem volt más, mint két darab 5.25-ös floppy. Mint az sejthető, nagyon kíváncsi lettem a tartalmára. Az egyetlen probléma, hogy nekem soha nem volt PC-s 5.25-ös lemezem. C64 az teljesen más, de a két lemez formátuma nem kompatibilis,

Először a könnyebb megoldást kerestem. Megkértem Charlie-t, hogy küldje el a lemezek tartalmát. Feltételeztem, neki megvan, mert azt mondta, hogy a könyv megvan neki (sőt, a könyvet is az ő ajánlása miatt szereztem be), régi hardverei neki is vannak, talán lementette magának. Nem volt szerencsém.

A második lehetőség, hogy a melóhelyen nézek szét. Annyi elavult hardver van ott, talán lelek egy floppy-t. A lemezeket lementem, és többet erről az ügyről nem beszélünk.

Az irodánk lomtárában nem volt. A rendszergazdák állították, hogy nekik van három-négy, de a helyiségeket átkutatva egyet sem találtunk. Azt javasolták, kérdezzem meg a karbantatókat, mert nekik van hozzáférése a leselejtezett eszközök raktárához. A selejtezés során ugyanis elviszik a gépeket az irodákból, de hulladék lerakóig nem jutnak el. Bekerülnek az egyik raktárba, majd rájuk zárják az ajtót. Az egyik karbantartó mondta, hogy ő kettőt is eltett annak idején, mikor ezeket az ősi eszközöket leselejtezték. Közben fennkölt filozófiai problémákról beszélgettünk:

- Azt is mondják, hogy aki biztonságban akarja tudni az adatait, az ilyen lemezeken tárolja.

Először nem értettem, miért akarna bárki is lemezen tárolni bármit is. Hozzáérek az ujjammal és vége mindennek, ami rajta van. Még a neve is az, hogy hajlékony lemez. Tehát akár el is törhetem. De rögtön meg is adta a választ:

- Ezeknek a gépeknek nincs IP-je.

- Ha egy modern gépből kihúzzuk az UTP kábelt, annak sem lesz IP-je.

Igazából akkor is van IP címe, de nem éreztem szükségét, hogy ilyen apróságokkal összezavarjam. Ezzel sajnos megakasztottam a magas röptű kiberbiztonsági eszmecserét.

- És mit dolgozik? Itt dolgozik az intézetben?

- Bioinformatikus vagyok. Több, mint egy éve itt dolgozom.

- Szerintem a legnagyobb bioinformatikus Turing volt.

Amennyire én tudom, Turing foglalkozott informatikával, foglalkozott biológiával, pont bioinformatikával nem. Nem is vagyok benne biztos, hogy lett volna értelme az akkori számítógépekre biológiai problémákat bízni. Közben átnéztünk hat raktárt, de egyikben sem láttunk olyan gépet, amiben 5.25-ös floppy lett volna.

Második kísérlet is kudarcba fulladt. Bármennyire is nem akartam, kénytelen voltam venni egy meghajtót. Régi kacatokat sokan árulnak, ami nehéz, hogy olyat találjak, ami működik is. Akkor még nem tudtam, melyik gépbe fogom beszerelni a meghajtót, ezért egy ISA vezérlőkártyát is vettem hozzá.

A meghajtót gyorsan megkaptam. Burkolata már nem volt, ezért az elektronika és a mechanikai egységek csupaszon meredtek rám. Az eladó rendes volt, küldött egy tartalék kártyát is, hátha nem lesz kompatibilis a meghajtóval, alaplappal vagy bármi mással. Nem tudom, hol tárolhatták a felszerelést, de hatalmas kosz pamacsokat fújtam ki a szerkezetből.

Először egy Pentium I-es gépbe szereltem a meghajtót. Mivel ennek az alaplapjára közvetlenül is ráköthető a lemez, a vezérlő kártya használatától eltekintettem. A második probléma, hogy nem tudtam, milyen orientációba kell a szalagkábelt bekötni. Tudtam, hogy az oldalán található piros csíkot kell figyelembe venni, de azt már nem tudtam, mihez kell azt viszonyítani. Vállat vontam, majd random bekötöttem. Majd megcserélem, ha nem lesz jó.

Mikor a feleségem meglátta, undorodva mutatott a gépre:

- Ezen egér ürülék van?

- Hol? - kérdeztem aggódva. Semmi kedvem nem volt ilyesmit a lakásba hozni.

- Ott, nem látod? Ez gusztustalan.

- Az egy kerámia kondenzátor - mondtam, miután megértettem, mire mutat.

A lemezekről nem tudtam, hogy milyen sűrűségű: egyszeres vagy dupla. Ezt a BIOS-ban kell beállítani. Majd ezeket is végigpróbálom. A permutációk számát tovább növelte, hogy az 5.25-ös floppykat jumperekkel tovább lehet paraméterezni. Volt valami T jumper, S jumper, 0, 1  2, 3. A T valószínűleg a terminator, amit akkor kell bekapcsolni, ha ez a meghajtó van szalagkábel végén. Az S talán a sebesség? Nem tudtam. A számok pedig meghajtó számát lehet beállítani. Először nem tudtam, de ez PC esetén DS1 vagy DS2, attól függően, hogy a számozás 0-től vagy 1-től kezdődik a számozás. Tehát nálam DS1-nek kell lennie. A biztonság kedvéért a DS0-t is kipróbáltam.

Természetesen az is lehet, hogy rossz a kábel. Ebben az esetben kezdhetek előről mindent a másik vezérlőkártya kábeleivel.

A gép természetesen nem indult el FreeDOS-al. A boot folyamat megállt mindjárt az elején. Emlékeztem, hogy írtak erről valamit, de pontosan nem tudtam, mit. Utána nézni nem volt kedvem, inkább beszereltem a meghajtót a következő gépbe. Ez már Pentium 4-volt, a BIOS csak 1.2MB-os lemez formátumot támogatott. Ebben az alaplapban már nem tudtam fordítva bekötni a kábelt, hála egy műanyag keretnek, ami jó volt. Ugyan csak előny volt, hogy egyetlen floppyként kötöttem be, tehát nem számított, hogy miként áll a Terminator jumper.

A rossz hír viszont az volt, hogy semmilyen módon nem tudtam elérni a lemezeket. Az A meghajtóra átlépve hibát dobott a rendszer. A boot során arra számítottam, hogy felpörög a meghajtó, de ez sem történt meg.

Rendben, jöhet a másik kábel. Ez már annyival volt jobb, hogy a boot során felvillant a meghajtó ledje, amit haladásnak könyveltem el. Ennél tovább viszont nem jutottam.

Másnap viszont a melóhelyről kerítettek nekem egy 5.25-ös meghajtót. Hurrá! Ezzel már gyorsabban ment az ellenőrzés, mert eleve jó kábelt használtam, tudtam, mit kell beállítani a jumpereken. Működni viszont ez sem működött.

Elment a kedvem az egésztől. Ennyi időt elfecsérelni, teljesen feleslegesen! Mikor visszaadtam a kölcsönkapott meghajtót, akkor annyit javasoltak, hogy próbáljak meg egy lemez felszíni ellenőrzést a scandisk-el. Közben olvasgattam, és ráakadtam egy érdekes cikkre, ami leírta, miként kell karban tartani ezeket a régi meghajtókat.

Már csak két napom volt, mielőtt lejár a könyv kölcsönzési ideje. A fejet alkohollal letisztítottam, de továbbra sem használt, és a felület ellenőrzés sem működött. A fej meg sem moccant, csak a lemez pörögtt fel egy rövid időre.

Már úgy voltam vele, hogy feladom. Nem tudtam, mit csináljak egy hasznavehetetlen 5.25-ös meghajtónak. Talán a léptető motor ér belőle valamit. A kerámia kondenzátorral meg a feleségemet idegelhetem. Azután eszembe jutott, hogy van egy AMD-s gépem is. Windows 7 van rajta, és a feleségem szokott rajta Heros II-t játszani. Ezt eddig nem próbáltam, mert az ősi gépek közül ez volt a legújabb. Esetlen az új gépeim közül a legrégebbi? Nem tudom, de a BIOS beállítások között szerepelt a 360K is. Talán annyi volt csak a baj, hogy a lemezek egyszeres sűrűségűek voltak?

Ezt a gépet is szétszedtem, beledugram a floppyt. Ezzel a trükkel sem tudtam életre kelteni a meghajtót. Oké, vége. A lemez mindörökre olvashatatlan marad. Közben eszembe jutott a karbantartó és az adatbiztonsági kiselőadása. Az adatok rohadt nagy biztonságban voltak, pedig a gépnek még IP címe is volt, amire a meghajtót kötöttem.

Ha már úgyis szétszedtem ezt a gépet is, azért nézzük meg 1.2MB-os beállításokkal is. Erre semmilyen racionális érvem nem volt, csak egy újabb időpocsékolásnak tűnt. Újra indítottam, átléptem az A meghajtóra, mire a meghajtó életre kelt. Elkezdett krákogni, reszelni, a kis fej össze-vissza rángatózott, a képernyőn meg feltűnt a lemez tartalma. Hoppá!

Mindkét lemezt lementettem, csak két fájlt nem lehetett olvasni. Gondolom az idő nem volt kegyes ahhoz a kettőhöz. Végül is, 26 év telt el a könyv megjelenése óta. Ez azért nem olyan rossz arány. A meghajtót szépen elcsomagoltam. Nem tudom, mikor lesz rá szükség, de remélem, nem a közeljövőben.floppy.jpg

Szólj hozzá!

Címkék: rendszergazda

A leíró jellegű cikkek

2020.02.20. 14:30 Travis.CG

A következő beszélgetés foszlányaiban több, különböző megbeszélésen hangzott el életem során:

- Ebben a publikációban nincs hipotézis.

- Mert ez egy leíró jellegű cikk.

- Ebben a publikációban random módszerek vannak egymás után.

- Mert ez egy leíró jellegű cikk.

- Ebből a publikációból semmi érdemlegeset nem lehet következtetésként levonni.

- Mert ez egy leíró jellegű cikk.

- Ennek a publikációnak nincs koherens váza.

- Mert ez egy leíró jellegű cikk.

- A publikáció olvasása közben többször elaludtam, mert a teljesen egyforma bekezdések összefolytak a szemem előtt.

- Mert ez egy leíró jellegű cikk - válaszolja egy képzeletbeli gyerek kórus.

Nem csoda, hogy az évek során, ha csak meghallom a "leíró jellegű cikk" kifejezést, azonnal egy elnagyolt, unalmas, érdektelen munka képe villan be.

Ha a való élet követne bizonyos kalandregényekbe illő dramaturgiát, akkor olyan szófordulatokkal élhetnék, hogy "de álmomban sem képzeltem, hogy ez a cikk is ilyen lesz". Esetleg: "de ez a cikk felfedte előttem a leíró jellegű alkotások szépségét".

Az igazság viszont legtöbbször mentes ezektől a remek kis fordulatoktól, ezért a most bemutatásra kerülő alkotás egy leíró jellegű cikk, annak minden jellemzőjével. Úgy is mondhatnám, ez a leíró jellegű cikkek archetípusa.

Ez szintén egy örökség projekt részeként indult. Akkor kaptam meg, amikor már szinte minden kész volt, pár apróságot leszámítva. Az alapfelállás egy bödön méz, ami nagyjából öt évet állt a szekrényben, mielőtt elkezdték volna vizsgálgatni, és amiben csodával határos módon találtak egy ismeretlen baktériumot. Mit csinál egy biológus, ha baktériumba nyúl? Nem, nem kezet mos. Szekvenál. Szerencsére, vagy nem, ebben a baciban volt egy rakás transzpozon, amit az egyik mikrobiológus elkezdett az inszerciós elemek manuális keresgetésével összepárosítani.

Mivel ezek a szerencsétlen inszerciós (IS) elemek nem átallottak génekbe beleugrani, amitől az annotáló programok rendre elhasaltak. Kutatónk ezért manuálisan írta be a géneket, jelezte az IS elemeket, majd az egészet átadta nekem, hogy töltsem fel a GenBankba.

Ez egy elég fájdalmas procedúra volt, mert az NCBI autómatikus annotálója felülbírálta az általam beírt annotációt, folyton kiabált, hogy "ennek a génnek nincs stop kodonja", vagy "ez a gén nem metioninnal kezdődik".

A problémák egy részét autómatikusan tudtam javítani, de így is maradt épp elég manuális szüttyögés. A sok vacak javítgatás után feltöltöttem a szekvenciákat. Azt hittem, most már vége, de nem. Jött a manuális kurátor, aki kereste a plazmid szekvenciákat, és nem értette, miért nincs meg a másik fele egyes géneknek.

Aki már levelezett az NCBI stábbal, az tudja, hogy ez úgy néz ki, hogy küldenek egy levelet, amire adnak egy hét válaszadási időt. Ha válaszoltunk nekik, akkor hónapokra eltűnnek, majd váratlanul egy újabb problémával keresnek meg, és az egész huza-vona kezdődik előről.

Természetesen itt is ez történt. A szekvencia feltöltés után a még pár ábrát kellett elkészíteni. A bírálat langyos volt, ahogy a Scientifi Reportsnál már megszokott. Talán ők is bealudtak néhány transzpozon után.

Szólj hozzá!

Címkék: publikáció

A bumeráng meló

2020.02.09. 22:11 Travis.CG

Vannak olyan projektek, amelyeket nem lehet elengedni. Az ember megpróbál kimászni belőle, de úton-útfélen beleakad, nem engedi, ráragaszkodik, mint egy olvadt rágógumi. Ez a publikáció pontosan ilyen.

Még 2012 táján találkoztam először vele, ahol is egy lelkes, akkor még PhD hallgató chip-seq kísérleteket töltött le, majd mindegyiket elemezte a Homer programmal. Az azóta eltelt idő alatt ledoktorált és három gyereke lett. Ebből a szemszögből nézve az eseményeket arcon csapja az embert az idők szele.

Két évvel később jött az ötlet, hogy adatbázisba kellene szervezni a szana-szét heverő szöveges eredményeket. El is kezdtünk egy rSNP adatbázist, de a projekt gyorsan elhalt, ahogy elfogytak az emberek, akik csinálhatták volna. Már csak ez a mementó jelzi, hogy létezett. Illetve a projekt nem is halt el, csak cserélődtek az emberek. Közben én kimentem külföldre, és az egészből nem láttam mást, csak pár emailt, amiben a következő PhD hallgató a segítségemet kéri a weboldal fejlesztése során felmerülő problémákhoz. Ezek egy része a D3.js-el volt kapcsolatos, mert annak idején azt javasoltam, hogy a grafikonokat ezzel kellene megoldani.

De effektíve nekem nem kellett dolgozni vele, és én ezt nem is bántam. A projektet ugyanis nem láttam át teljesen. Nem értettem részleteiben, amitől az egész egy katyvasznak tűnt számomra. Nem is tudom, mi történt ez alatt az idő alatt a projekttel.

Mikor véget ért a jó világ és hazajöttem 2017-ben, volt egy rövid időszak, amikor gyakorlatilag nem dolgoztam sehol. Ismét kerestek, hogy segítsek az adatokat egy adatbázisba pakolni. A weboldal akkor már működött, de mindent szöveges fájlokból olvastak be, ami nem volt éppen hatékony. Még pénzt is ajánlottak érte.

A hátam közepére sem hiányzott a projekt, még pénzért sem. Szokás szerint nagyon gyorsan kellett volna eredményeket felmutatni. De volt egy másik fontos aspektusa is az ügynek: ebből lett volna meg a témán aktuálisan dolgozó PhD hallgató első szerzős cikke. Arra gondoltam, milyen kegyetlenül nehéz megszerezni a fokozatszerzéshez a cikkeket, mennyire kiábrándító, ha ilyenkor nem kapja meg az ember a hőn áhított segítséget, ezért nagyon kelletlenül ugyan, de igent mondtam. Pénzt nem fogadtam el, mert úgy gondoltam, könnyebben kiszállok a projektből, ha mégis tele lenne a hócipőm.

Megterveztem az adatbázist és segítettem az adatok feltöltésében is. Ez végül is szórakoztatóbb volt, mint elsőre gondoltam, és segített abban is, hogy a projektet jobban átlássam. Érteni még mindig nem értettem mindent belőle, de legalább már tudtam, milyen adatokkal dolgozunk, azokat hogyan kaptuk meg.

Véget ért a rövid szabadságom és elkezdtem dolgozni az MTA-nál. A segítség kérő e-mailek száma az idő múlásával ismét fogyatkozni kezdett. Úgy éreztem, ezzel a projekttel többet már nem kell dolgoznom, megtettem, ami tőlem telhető, ha lesz belőle cikk, jó, ha nem, az sem baj.

Aztán 2018-ban úgy hozta a sors, hogy visszakerültem abba a csoportba, ahonnan elmentem, visszacsöppentem abba a projektbe, amitől hat éve próbáltam megszabadulni, és már napi 8 órában dolgozhattam rajta. Az eltelt idő alatt viszont sok minden megváltozott. Addigra az MTA-s kaland annyira megfeküdte a gyomrom, hogy még ennek a projektnek is örültem. Örültem mindennek, amiben nincs Wilcoxon teszt. Úgy gondoltam, ha már csinálni kell, akkor csináljuk rendesen.

Azért, hogy a projekt ne csússzon félre, átvettem az adatbázis és a weboldal felügyeletét is. Nem azért, mert annyira értek hozzá, hanem nem akartam, hogy több ember matasson ugyan ott, és felülírjuk egymás kódját. Így ha valami gond volt a weboldallal vagy az adatokkal, akkor mindenki tudta, hogy engem kell zargatni. Nem volt egymásra mutogatás, mert megvolt mindennek a felelőse. Arról nem is beszélve, hogy a PhD hallgatók végre a fokozat szerzéssel foglalkozhattak, és nem a webszutyok turkálásával.

Mert turkálni való akadt bőven. Kódot megörökölni mindig fájdalom, és ez alól a szabály alól ez sem volt kivétel. Igazából még most sem áll ott a kód minőség, ahol lennie kellene, de határozottan jobb, mint amikor átvettem.

A dokumentálásra is igyekeztünk nagy hangsúlyt fektetni. A nyers adatok importálását sikerült olyan jól vezetni, hogy mások is meg tudták csinálni minimális segítséggel. A weboldal is rengeteg leírást kapott, hogyan lehet használni. Ezt még a bírálók is elismerték.

Volt egy adat újra generálás, mert kiderült, az összes csontvázat nem sikerült kisöpörni a padlásról, de a doksik alapján rekord idő alatt sikerült visszaépíteni az adatbázist, bár ekkor derült ki, hogy a tudtomon kívül készítettek pár segédtáblát az adatbázisba, de azt már senki nem tudta, hogyan is generálták azokat. Mikor megfejtettem, ezeket is leírtam a doksikba. Ebben az állapotában már határozottan tetszett a projekt, és örültem, hogy a részese lehettem, mert a legnagyobb része már úgy működött, ahogy egy projektnek működnie kell: A kód GitHub-on volt, a hibákat rendesen vezettük, amit lehetett, dokumentáltunk.

Azért akadtak hullámvölgyek is. Például amikor Office dokumentumokat kaptam, hogyan nézzen ki egyik-másik weboldal, attól a falra tudtam volna mászni. (Kedvencem a PowerPoint prezentációban kapott leírások voltak, ahol diákon keresztül lerajzolták nekem, hogyan menjenek az animációk.)

Az egyik nagy hiányossága a teljes projektnek a webdesign. Sajnos ez nekem nagyon nem megy, de úgy látom, a csoportban másoknak sem, ezért néz ki úgy, ahogy. A helyzetet tovább súlyosbította, hogy a bírálatok hatására a többiek további grafikai elemeket akartak belepréselni ebben az egyébként is zsúfolt weboldalba. Egy ideig ellenálltam, de végül elbuktam. Belepakoltam mindent, amit akartak.

A projekt természetesen a cikk megjelenésével még nem zárult le. Az összegyűjtött adatokkal már most is végzünk elemzéseket, amelyek az SQL lekérdezéseknek hála gyorsabbak és egyszerűbbek, mint ad-hoc szkriptekkel bohóckodni. Fejlesztések is tervben vannak, és a hiányosságait is ki kell küszöbölni, hogy ne legyen egy, a több ezer magára hagyott és használhatatlan adatbázisból.

Szólj hozzá!

Címkék: publikáció

Intézményesített hazugság

2020.02.03. 23:21 Travis.CG

A kutatás-fejlesztésben soha nem lehet tudni, hova lyukad ki az ember. Mivel az elérni kívánt célok az ismeretlen homályába vesznek, az oda vezető út is megtervezhetetlen. Természetesen kitűzhetünk olyan célokat, amelyek kevésbé homályosak, de az eredmény is olyan lesz: unalmas és semmit mondó.

A laboratórium falain kívül eső világ pont ellentétesen működik. Ott a kiszámíthatóság az elvárt. Senki nem akar reggelente azon gondolkodni, hogy jön-e a busz, mert a sofőr tesztel egy alternatív útvonalat. A busznak jönnie kell, és kész. A buszsofőrnek megvan, hogy mennyi utat kell megtennie, milyen gyorsan, és ezért mennyi pénzt kell kapnia. Az elvárt teljesítménytől való eltérés mérhető, felelősségre vonható, és megtorolható.

A probléma akkor kezdődik, ha ez a két világ összetalálkozik. Márpedig össze kell találkoznia, ez elkerülhetetlen. Például a tervezett és kiszámítható pénznek át kell vándorolni egy megjósolhatatlan kimenetelű kutatás felé. Végeredményként a kutatót ki kell fizetni. Ki kell fizetni egy olyan munkáért, ami nem mérhető.

Ezért a kiszámítható világ kiszámíthatóvá teszi a kiszámíthatatlant. Hogyan? Természetesen adminisztrációval. Az adminisztráció viszont embereket jelent, akiket alkalmazni kell. Egyfajta puffer zóna ez a két világ között, akár csak egy dimenzió kapu valamelyik tudományos-fantasztikus műben. Ezek a kapuk furcsa dolgokat csinálnak mindkét esetben.

Vegyünk egy olyan egyszerű esetet, mint amilyen a munkaidő nyilvántartás. A tervezett világ elvárja, hogy én meg tudjam mondani, mennyi időt töltöttem egy adott munkával. De én ezt nem tudom megmondani. Ha van egy szkript, amit két évvel ezelőtt megírtam, és fut három hétig. Akkor mennyit dolgozom? Amíg elindítom? Az két perc. Amíg fut éjjel-nappal? Esetleg amíg írtam a szkriptet?

A helyzet furcsasága, hogy bármelyik értéket írom be, az rossz lesz. Két percet nem írhatok be, mert azt mondják, nem dolgoztam eleget. Ötszáznégy órát nem írhatok be, mert nem hiszik el, és egyébként sem jogosultak túlórát kifizetni. A szkriptet meg azelőtt írtam, hogy elindult volna a projekt, tehát az nem ebből a munkából ment. Végeredményben azt kell mondjam, ha igazat írok, bajba kerülök.

Ha viszont hazudok, akkor minden rendben lesz. Ha beírom, hogy 8 órát dolgoztam, akkor a rendszer megnyugszik, a kis fogaskerekek boldogan forognak tovább. A papír A-helyről tovább tud vándorolni B-helyre, mert nincs benne "hiba".

Amint egy kutató több projekten is dolgozni kezd, több helyről kapja a pénzt, több adminisztrációval kell foglalkoznia. Itt viszont a interferencia lép fel. Nem lehet minden projektre 8 órát beírni, az arányoknak mégis érvényesülni kell. Ezért teljesen elfogadott, hogy olyan nyilvánvaló hülyeségeket írnak be kutatók, hogy az adott projekttel 2,3 órát dolgozott naponta.

Senki nem foglalkozik az ügy abszurditásával. Sőt, emberek, (adminisztráció címszóval) pénzt kapnak azért, hogy az igényeknek megfelelő hazugságot összeállítsák, majd egy másik helyen, másik emberek ezt az egész értelmetlen adathalmazt ellenőrzés céljából átnézik.

Miért írok minderről? Kit érdekel ez? Azért írok, mert hála nekem, a hazugság gyártás új szintre emelkedett. Ugyanis a papírok kitöltése annyira bonyolulttá vált, hogy valakinek az az elképzelése támadt, hogy automatizálni kellene. Én pedig imádok automatizálni dolgokat. Pláne, ha olyan értelmetlen dolgokról van szó, mint a projektidő nyilvántartás. Értelmetlen alatt azt értve, hogy időt és energiát kell rá áldozni.

A programnak Windows alatt kell futnia, mert az adminisztrátorok csak azt használnak, és nem fognak a kedvemért mást telepíteni. Ezért csakis a C# jöhetett szóba, hogy a felhasználói felületet minél egyszerűbben elkészíthessem. Az is nyilvánvaló volt, hogy kell egy adatbázis, ahol tárolom a szükséges adatokat, amire a LocalDB volt az egyik logikus jelölt.

Kérdés, mit tároljunk az adatbázisban? Először jó fiú módjára olyasmiket akartam tárolni, ami az igazságot tartalmazza. Ahogy egyre többet és többet megtudtam a rendszer működéséről, rájöttem, hogy teljesen felesleges bármit is tárolni a munkaidőről. Nem csak a fent vázolt jelenségek miatt, hanem azért is, mert a csoportvezetők gyakran visszamenőleg is meggondolhatják magukat a pénz felhasználásáról. Teszem azt, X PhD hallgató helyett Y-t jelölik ki, hogy a projekten dolgozott.

Ezt úgy fogalmazták meg nekem, hogy a program eredményének "időben visszafelé is módosíthatónak kell lennie". Francokat! Ez csak azt jelenti, hogy az algoritmusnak tetszőleges időintervallumon kell tudnia hazudni. Nem egy adat tároló kellett nekik, hanem egy adat generátor. Tárolni csak a hazugságok paramétereit kell. Ez jó, mert egyszerűbb lett az adatbázis struktúrája.

Egyetlen problémám sokáig az volt, hogy miként jelenítsem meg a végleges táblázatot. Megrajzolhatom GDI-vel, ami nem tűnt túl jó ötletnek, mert minden formázási paramétert nekem kell leprogramozni, és a végtelenségig finomítani. Ez nyilvánvalóan sok időt vesz igénybe. Ha Linux alatt lettem volna, szívbaj nélkül egy LaTeX forrást állítottam volna elő, amit kedvemre PDF-é konvertálok. Sajnos C# alatt nem sok PDF készítő modult találni.

A másik megoldás, ha előre elkészített komponenssel dolgoznék. Régen volt egy Grid, amit a Visual Basic-es múltam során használtam (igen, mindenkinek van sötét korszaka), de a mostani implementáció (DataGridView) nekem nem tűnt elég paraméterezhetőnek.

Aztán eszembe jutott, hogy a táblázat lehetne közönséges HTML, amit egy WebBrowser komponenssel megjelenítek. CSS-el úgy formázom, ahogy akarom, ráadásul a komponens képes kinyomtatni a tartalmát egy szimpla metódus hívással. Túl szép, hogy igaz legyen!

Egyébként az is. Nem tudom, miért, de a nyomtatás során fejlécek és láblécek jelennek meg szükségtelen szövegekkel, amiket képtelenség kikapcsolni! Illetve az egyetlen módja, hogy kikapcsoljam, ha módosítom a Registry-t. Már kezdtem elfelejteni, hogy Windows-on vagyok.

A problémát úgy lehet megkerülni, ha nem egyből nyomtatok, hanem a Nyomtatási előnézet dialógust hívom meg, mert akkor a felhasználónak van lehetősége kikapcsolni azt. Nem a legjobb megoldás, mert a felhasználónak még egyet kell klikkelnie feleslegesen.

Így született meg a FatLiar program.

Szólj hozzá!

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

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