Miért lettem mentor egy Java fejlesztő képzésben?

Magyarországon egyre több junior programozóképzés indul. Ahogy egyre többekhez jut el, egyre több tévhit és félreértés terjed az interneten. Mivel egy ilyenben veszek részt, mint mentor, szeretném egy kicsit erről az oldalról is bemutatni. Minden reklámtól mentesen, és sokszor a technológiára koncentrálva, hiszen ez az én fő területem. 2016 végén kerestek meg a Training360-tól, hogy csatlakozzak a Yellowroadhoz, kidolgozni a Java junior képzés tematikáját, valamint mentorként részt venni a csoportok munkájában, embereket hozzásegíteni egy új karrierhez. Kis gondolkozási idő után igent mondtam. Hogy miért? És hogyan próbálok minden nap helyt állni? Erről szól ez a poszt.

Előző posztomat hasonló témában Programozó szeretnék lenni, menjek-e egyetemre? címmel írtam.

Disclaimer: 2001 óta Java fejlesztőként, architektként dolgoztam, rengeteg projektben vettem részt, programozót interjúztattam, és közben folyamatosan oktattam. Jelenleg a junior fejlesztőképzéssel foglalkozó Yellowroad egyik mentora vagyok. Az itt közölt poszt csak a saját személyes véleményemet tükrözi. Fenntartom a jogot, hogy a posztot folyamatosan bővítgessem, javítgassam.

Programozó szeretnék lenni, menjek-e egyetemre?

Ez a poszt, a címéből is következik, egy könnyedebb témával foglalkozik. Manapság különböző fórumokon jön elő a kérdés, hogy érdemes-e egyetemre mennie annak, aki programozó szeretne lenni. Most itt próbálom részletesen összefoglalni, hogy később tudjak hivatkozni rá.

Hasonló cikkeim a Miért ne fejlesszünk saját keretrendszert?, Ki is az a Java architect? vagy a Java források tanuláshoz.

Következő posztomban a manapság egyre jobban terjedő fejlesztőképzésről fogok írni.

Disclaimer: Mivel a Debreceni Egyetemen végeztem 2001-ben, főleg erről van tapasztalatom. Azóta Java fejlesztőként, architektként dolgoztam, és rengeteg embert, köztük végzős egyetemistát is interjúztattam, és rengeteget oktattam. Jelenleg a junior fejlesztőképzéssel foglalkozó Yellowroad egyik mentora vagyok. Az itt közölt poszt csak a saját személyes véleményemet tükrözi. Fenntartom a jogot, hogy a posztot folyamatosan bővítgessem, javítgassam.

Hackerrank megoldások JUnit Rule-lal

A JUnit Rule-ok gyakran méltánytalanul mellőzött osztályai a JUnit keretrendszernek. A rule-ok használatával pedig kibővíthetjük a teszteseteinket újrafelhasználható funkciókkal. Léteznek már előre megírt rule-ok, mint a TemporaryFolder rule fájlműveletek teszteléséhez, vagy az ExpectedException rule, melynek használatával az elvárt kivételekre tudunk pontosabb feltételeket megfogalmazni. Természetesen saját rule-okat is írhatunk, ha szabadidőnket erre áldozzuk, ahelyett, hogy a kora őszi erdőt járnánk szarvasbőgést hallgatva.

A Hackerrank egy olyan oldal, ahol különböző nehézségű programozási feladatok vannak a kezdőtől a profiig, melyek megoldásával pontokat gyűjthetünk. Választhatunk különböző témakörök közül, használhatunk különböző programozási nyelveket. A feladatok angolul vannak leírva, és több teszt eset is tartozik hozzájuk, jellemzőjük, hogy a standard bemenetről kell beolvasni a teszt adatokat, és a standard kimenetre kell a megoldást kiírni. A tesztesetek (bemenet és kimenet) fájlként letölthetőek.

Természetesen nem túl kényelmes a megoldásokat a weboldal beviteli mezőjében megírni, sokkal jobb kedvenc fejlesztőeszközünkben. Java esetén JUnit teszteket is használhatunk, ekkor azonban a Hackerranken publikált kódvázat kell átalakítanunk. Ahhoz, hogy ezt a lépést ne kelljen megtennünk, és egyszerűen másolhassuk le a kódot, készítettem egy JUnit rule-t, mely a standard inputra irányítja a példa bemenetet tartalmazó állomány tartalmát, naplózza a standard kimenetre az írásokat, és szabályos assert hívással összehasonlítja a kimenetre írt tartalmat a megoldást tartalmazó állomány tartalmával.

Így ezen poszt bemutatja a JUnit rule-ok használatát, valamint egy eszközt biztosít, mellyel kényelmesebben lehet Hackerrank feladatokat megoldani.

Naplózás

Szintén egy régi tartozásomat szeretném letudni, méghozzá a naplózó keretrendszerek ismertetését. Az egyik legrégebbi keretrendszer a Log4J, melyet Ceki Gülcü kezdett el fejleszteni. Bizonyos Apache projekteken belül az Apache Commons Logging volt elterjedt. Valamint bekerült naplózás a JDK-ba is, bár kicsit későn reagált az igényekre, a java.util.logging csomagba került, ezért gyakran hívjuk JUL-nak is. Mivel az eltérő library-k eltérő naplózó keretrendszereket definiáltak függőségként, ezért egy alkalmazás fejlesztésekor sajnos több naplózó rendszer is bekerült az alkalmazásba.

Erre a problémára megoldásként hozta létre szintén Ceki Gülcü az SLF4J keretrendszert, mely egy egyszerű API a különböző naplózó keretrendszerek elé. Van egy egyszerű implementációja is (SimpleLogger), de az összes többi keretrendszerhez van illesztése. Mindenképpen érdemes ezt használnunk, hiszen ekkor bármikor cserélhetjük alatta az implementációt.

A Log4J fejlesztése közben tanultak alapján alkotta meg Ceki Gülcü a következő keretrendszert, Logback néven.

Hogy még bonyolultabb legyen a helyzet, kijött a Log4J 2 is, melybe a Logbackből átemeltek pár dolgot, de úgy, hogy közben javítottak is rajta, olyan dolgokat, melyeket a Logbackben nem lehetett annak architektúrális megkötései miatt.

Ebben a posztban nézzük meg pár trükköt a naplózó keretrendszerek használatával kapcsolatban.

(Ennek kapcsán frissítettem egy régi Log4J cikkem, mely elérhető a GitHub-on, valamint van Log4J példa projekt is. A poszt további része természetesen a Logbacket is tárgyalja.)

SonarQube

Bár a SonarQube (korábban egyszerűen csak Sonar) a Java fejlesztés alap eszköztárába tartozik, mégsem írtam még róla, így ezzel a poszttal ezt szeretném bepótolni.

A SonarQube egy olyan komplex szoftverrendszer, mely azt biztosítja, hogy folyamatosan nyomon tudjuk követni a kódunk minőségét (ezt Continuous Code Quality-nek nevezi). A projektünkre statikus kódelemzőket lehet futtatni, melyek elemzik a forráskódot, és annak feltérképezésével próbálnak hibás részeket keresni. (Ezek általában rossz programozási gyakorlatok, az idők során kialakult programozási konvencióknak ellentmondó kódrészletek, vagy tipikus - nem olyan gyakorlott fejlesztők által elkövetett típushibák). A SonarQube-ot először Java nyelvre fejlesztették, de már több, mint húsz programozási nyelvet támogat (, akár egy projekten belül, pl. Java backend, és JavaScript frontend). A SonarQube ezen elemzések eredményét képes hisztorikusan tárolni, így nyomon követhető, hogy idővel hogyan alakul a kódunk minősége. Ezen kívül képes a tesztlefedettséget is tárolni, hogy az automatikus tesztek futása során mely utasítások lettek végrehajva, és mely osztályokra, metódusokra, végrehajtási ágakra nincs tesztünk. Ezeket az információkat nem csak tárolni tudja, hanem egy intuitív felületen képes ezeket meg is jeleníteni. A SonarQube tetszőleges számú projekt adatait képes tárolni és megjeleníteni. Nyílt forráskódú, de licensz is vásárolható, mellyel támogatást kapunk, illetve más nyelvhez is elemzőket.

Nézzük meg, hogy milyen komponensekből áll a SonarQube, hogyan lehet telepíteni, és hogyan elemezhetünk ki vele egy projektet, és hogyan integrálható a fejlesztőeszközünkkel (IDEA, Eclipse és NetBeans).

Issues