Jónás Richárd
Egy szoftver akkor sikeres, ha kevesebb munka van vele, mint amit helyettesít
Egy szoftver akkor sikeres, ha kevesebb munka van vele, mint amit helyettesít
Amióta világ a világ engem mindig is a szoftverfejlesztés érdekelt. 2000-ben végeztem a Debreceni Egyetemen programtervező-matematikus szakon, de már jóval előtte is fejlesztettem szoftvereket. A C, C++ nyelvek fogtak meg először, ahol megtanultam a feladatok komplexitása mellett kezelni hogyan kell hardverközeli kódokat írni. Ez nem állt tőlem távol, mert évekkel előtte Assembly nyelven is programoztam
Diplomamunkámnak a morfológiai zajszűrést választottam a digitális képfeldolgozásban, ebben az időben több képfeldolgozó szoftvert is fejlesztettem a fent említett könyezetben. Diploma után rövidesen a Java programozási nyelv fogott meg, és szerveroldalon körülbelül 10 évig programoztam különböző rendszereket Java nyelven és a köré épülő technológiákkal (EJB, Spring, Tomcat, Hibernate). Időközben megismerkedtem egy projekt keretében az Erlang programozási nyelvvel, és a lightweigh process modellje nagyon megtetszett. Ezután már máshogy láttam a párhuzamosságot és a hibakezelést a Java programokban.
2013-ban az Erlang Solutions budapesti irodájában helyezkedtem el, és innentől kezdve az Erlang programozási nyelv és a hozzá kötődő technológiák a szakterületem. A Riak NoSql adatbáziskezelő segítünk integrálni, hangolni különböző európai és amerikai nagyvállalatok számára.
Már az első percektől jobban érdekelt, hogy mi zajlik a masszívan dolgozó szervereken a háttérben, mint a frontend fejlesztés. Természetesen a Web és a benne rejlő lehetőségek egyből megfogtak, így kézenfekvő volt, hogy webes alkalmazásokat fejlesszek.
A szerveroldalon azt találom kihívásnak, hogy a rendelkezésre álló kapacitásokkal takarékosan bánva, minél több felhasználót tudjunk kiszolgálni. Ugyanakkor a szerveren megadatott kapacitásokat 100%-osan kell kihasználnunk, tehát olyan szoftvert kell írni, ami takarékos, de mégis maximálisan ki tudja hajtani a szervert (hiszen azért költöttek rá pénzt).
Ezt a legjobban párhozamos és konkurrens programozással tudjuk elérni. A mai funkcionális programnyelvek párhuzamossága pontosan ezt hivatott megvalósítani (Erlang aktor modell, illetve később Scala, Clojure, stb.)
Egy megadott algoritmust leprogramozni nem bonyolult feladat. Viszont olyan algoritmusokat kitalálni, amelyek lehetővé teszik, hogy a folyamatokat párhuzamosan lehessen végrehajtani, már komoly szellemi erőfeszítést igényelnek. Agyunk alapvetően szekvenciális, tehát egy feladatot lépések sorozatával a legkézenfekvőbb megoldani.
A párhuzamos programozás ezzel szembemegy azzal, hogy itt a folyamatokat egymástól kvázi-függetlenül végrehajtható lépésekre bontja. Ez nem minden esetben tehető meg, és ráadásul egy újszerű gondolkodást is igényel. A zip tömörítő algoritmust például szekvenciális, tehát akárhány magos laptopot is veszünk, ez a folyamat nem fog felgyorsulni.
Masszívan konkurrens rendszereket máshogyan is kell tervezni. Itt a feladatot, sok kicsi, egymástól független életciklussal rendelkező folyamatra bontjuk. Ezek a folyamatok beszélgetnek egymással - igény szerint, és mindenképpen külön-külön halnak meg, abnormális körülmények esetén. Sokan nem értik, hogy tervezés közben a hiba lokalizációja határozza meg, hogy miket fognak ezek a folyamatok elvégezni (Erlang - Let it crash filozófia).
Ha valamit el tud végezni egy számítógép, miért mi végezzük el? A szoftver folyamatosan fejlődik. Új igények jelennek meg, amire reagálnunk kell új funkciók leprogramozásával. Változhatnak régóta stabil funkciók, adatok, az új funkciók bekerülésével. Ennek végigellenőrzése olyan tevékenység, amit nagyon gazdaságtalan emberi erőre bízni.
Mindig is úgy gondoltam, hogy a szoftver minőségét szoftveres tesztekkel a legkönnyebb elfogadható szinten biztosítani. Szeretek jól tesztelhető, jól mérhető kódokat írni, hiszen a tesztelés alapvetően fejlesztési időben ellenőrzni a program működését, de élesben muszáj diagnosztikai pontokat építeni a szoftverünkbe, hogy beavatkozás nélkül meg tudjuk mondani melyik részével vannak kifogásaink. Ezáltal a hibát is könnyebben tudjuk lokalizálni.
‟Az első webes projektemen megtanultam mennyire fontos a jó teljesítmény és a pontosság„
Igazi LAMP project (Linux, Apache, MySQL, PHP), ahogy mind a négy technológiát megismertem. Szüleim import-export kereskedelmi vállalkozásához fejlesztettem ezt a szoftvert, ami a havi ÁFA fizetés alapja volt. Mondanom sem kell, hogy a pénzügyi felelősség itt óriási volt, ez nem egy kockázati tőkes pénze volt... Szóval aki kételkedik, hogy komoly intranetes rendszert lehet-e fejleszteni ezekkel a technológiákkal, próbálja ki maga is.
A vámraktár jelentéseket LaTeX által generált Postscript dokumentumokba generálta a rendszer, a vámosok gyönyörködtek a lézernyomtató által nyomtatott reportokban.
A Java világban számtalan eszköz könnyíti meg a programozók életét ha adatokat valamilyen külső formában akarnak tárolni (adatbázis, bináris file, web). Töménytelen számú annotáció alapú JSON konverter létezik.
Erlang-ban egy kicsit más a helyzet, ez olyan csináld magad világ, mindenki a saját kényelmére szab egy low-level JSON konvertert. Én erre találtam ki egy deklaratív keretrendszert, amivel szabályokat meghatározva az ejson automatikusan átkonvertálja az Erlang adatokat JSON formátumba. És ami a múltban még fájdalmasabb volt, JSON-ből automatikusan konvertál Erlang termekbe - hibaellenőrzés mellett.
Ez egy open source projekt, a github-on hosztolom.
2007 februárjában kezdtem el futni, futógépen, hátizom és súlyproblémákkal küszködtem. Pár hát futás után mindenem fájt, hiszen a szalagok, csontok kezdték megérezni a terhelést. De ugye ilyenkor nem szabad abbahagyni, és persze már 2 hét után is tudott hiányozni a futás.
Innentől kezdve könnyű dolgom volt, csak nevezni kellett versenyekre (kitűzni a célt), majd a megvalósításukon dolgoztam (edzés). Első 10km-es versenyemet 2008 március végén futottam, az akkor még megrendezett Duna-parti futógála keretében. A cél egy 1 óra alatti idő volt, 58:42-es időmmel, kis belesétálással ez sikerült is. Emlékszem, a 170-es plafonomon volt a pulzusom 6 perc/km-es tempónál. Pár évvel később egy 43:06-os 10km-rel tartom az egyéni legjobbamat.
Első félmaratonomat 2009-ben futottam a Nike félmaraton versenyen. Ez 2 óra 14 perc alatt sikerült, nagy küzdelem árán. Sokat készültem rá és nagyon örültem az eredménynek. 2014-ben 1:36:44-es félmaratonom az eddigi legjobbam, amit Budapesten a Tudás útja félmaratonon futottam.
2010-ben adtam a fejem a maratoni táv teljesítésére, a Firenze maratonra neveztem, amit november végén, viszonylag hűvösebb időben rendeznek meg. Sok sötétben futás, készülés, hegyi edzés után a 4 órás maratont nem, de egy 4:08-as időt sikerült behúznom, és viszonylag kevés szenvedéssel teljesítettem első maratonomat. Ma már 10 maratonon vagyok túl, 3:49-es maratonomat a Garda-tónál futottam.
Olyan 2012-ben kezdtem komolyabban foglalkozni a terepfutással. Itt több időt és nagyobb erőt is kell kifejteni, mint egy lazább aszfaltfutásnál. A hegyi edzések jótékony hatással vannak az aszfaltos eredményeimre, szóval innentől ha tehetem terepen edzek. Leghosszabb teljesítésem a Piros 85 teljesítménytúra, kocogva, futva, túrázva (88km 3,300m szintemelkedés, 13,5 óra). A legbrutálisabb pedig a Mátra 60 (59km 3,400m szint júliusban, 11:04).
2014 júliusában elkezdtem gyorsúszni tanulni, hiszen nem hévíz stílusban szeretném átúszni a Balatont. Azóta 150km úszóedzés van mögöttem (2015 szeptemberében), és haladok afelé hogy jónak nevezhető legyen az úszásom.
Szeretek olvasni, mert ahogy mondják az olvasás az egyetlen kockázatmentes tapasztalatszerzés. És kinek nincs szüksége tapasztalatokra? Korábban regényeket olvastam, ma úgynevezett önismereti és életrajzi könyveket, a szinte már kötelező szakkönyvek mellett.
Néha összejövünk és dzsemelünk egyet, nemrég Steve egyik számára improvizáltunk felváltva Veréb Krisztián barátommal.