JetBrains Learning Platform - egyre jobb :)

Ma már Dunát lehet rekeszteni mindenféle kezdőknek való tutorial-lal és könyvekkel, nem szeretném ezeket tovább szaporítani.

Viszont írnék egy rövidet a JetBrains cég fejlesztőkörnyezetiről, mert ezek nagyon jók, és egyre jobbak.

Fontos: angolul tudni kell. Ezzel nem tudsz mit tenni, ha IT-ban szeretnél valaha is a szuperkezdő szinten túljutni, kénytelen vagy megtanulni a szakmai angolt. Vannak egészen jó magyar anyagok is (Python-hoz pl. a Pythonidomár vagy egy Youtube videósorozat), ezek is csak a nyelvek alapjait tanítják meg, ami azért még kevés az érdemi munkavégzéshez.

A JetBrains Academy oldalán jelen pillanatban (2020. május) ingyenesen lehet megkezdeni Java, Kotlin és Python nyelveken a tanulást. Ehhez kapcsolódik (a tanulás egy része is itt folyik), hogy a JetBrains fejlesztőkörnyezeteinek vannak ún. EDU kiadásai, amelyek ingyenesen használhatók, és egészen sokat tudnak. A letöltőoldalon a nyelv kiválasztásával látszik, hogy milyen lehetőségek vannak. JVM alapú nyelvekhez (Java, Kotlin, esetleg Scala) illetve Python-hoz van dedikáltan előkészített környezet (IntelliJ IDEA Edu ill. PyCharm Edu), ami ingyenesen használható és egészen sokat is tud.

Például, az IntelliJ IDEA Edu-ban teljes támogatás van:

• Java, Kotlin, Groovy és Scala nyelvekben való fejlesztésre/gyakorlásra (fordítás / futtatás / nyomkövetés / unit teszt környezetek támogatása)
• A legelterjedtebb verziókezelő rendszereket (Git, Mercurial, SVN) támogatja, Git esetén GitHub integráció is
• Szintaxisszínezést és minimális támogatást ad HTML/XML/JSON fájlokra is
• Projektkörnyezet tekintetében az ezeréves Ant mellett a Maven és a Gradle is támogatott

(Arról nem is beszélve, hogy, ha a mobileszközökre való fejlesztés érdekel, akkor az Android Studio is ingyenesen elérhető minden fontos platformra, amit otthon használhatsz.)

Igazából, ha megvan a lelkesedés, a megfelelő angol nyelvtudás és a kitartás, valamint egy közepesen erős számítógép (konkrétan ismerek olyat, aki 2. generációs Core-i5 processzoros, 8GB memóriás gépen fejleszt, ez a konfiguráció egy SSD-vel kiegészítve teljesen jó alapokat nyújt) és internet-előfizetés, akkor ezek a jó minőségű eszközök és kezdő ismeretanyagok olyan lehetőséget nyújtanak, amelyre 20-30 évvel ezelőtt közel sem volt lehetőség.

Ha esetleg kicsit több memória van a gépedben - vagy nem vagy türelmetlen :) - akkor a GitHub, a Jenkins, a SonarQube (vagy helyi kódtárak esetén az UpSource és a YouTrack, esetleg a Redmine) segítségével ingyenesen juthatsz újabb fontos, és a gyakorlatban egyre inkább alkalmazott építőkövek használható állapotához/verzióihoz:

• Kódtárkezelő eszközhöz, ahol akár néhányan össze is dolgozhattok, akár tanulási célból is.
• Projektépítő eszközhöz, amely segítségével átélhetitek, hogy mennyi előkészület / plusz munka van akkor, ha olyan projektet kell készíteni, amit nem a fejlesztőkörnyezetben "build-elsz" és onnan adsz oda mindig kézzel.
• Kód "egészségmérő" eszközhöz, aminek a segítségével számos metrikát ill. észrevételt kapsz a kódjaidhoz, ami főleg a tanulás kezdetén nagyon fontos, de később is igen hasznosak lehetnek az észrevételek.
• Feladatkezelő eszközhöz (akár a GitHub sajátját, akár egy külsőt, pl. YouTrack próbálsz ki), amelyen keresztül nyilvántarthatod a feladataidat, ütemezheted, sorba rendezheted őket.

Mennyire figyelsz az összképre?

Nemrég történt velem egy "kaland", ami kapcsán elgondolkodtam (ismét) pár dolgon. Az történt, hogy mentem autóval dolgozni, egy kocsisorban haladva a reggeli szokásos forgalomban, amikor megláttam, hogy kb. 150 méterre egy alárendelt útról kikanyarodna egy autó a szembejövő sávba. Ott éppen üres volt a pálya, én meg a kocsisorban már eleve kicsit hátrébb voltam (még nem zárkóztunk fel teljesen az előttünk haladó sorhoz), mögöttem viszont megint csak elég sok autó volt.

Így aztán elvettem a gázról a lábam és jeleztem a kikanyarodónak, hogy mehet. Ő ment is, meg is köszönte, viszont így megtörtént az a csúfondárosan szégyenletes eset, hogy kb. 10 másodpercig 50 km/óra alá esett be a kocsi sebessége (kb. 44-ig mentem le). Így aztán a mögöttem jövő autós már dudált is meg már integetett is.

Belegondolva a szituációba, két lehetőségre tudtam gondolni, és egyik sem tetszik:

• vagy a mögöttem jövő sofőr is látta a közlekedés összképét de telibesz***a, hogy egy kis előzékenységgel minimálisan tart fel másokat de lesz, akinek jobb lesz, nem csak úgy történhet valami, hogy az neki a lehető legjobb legyen,
• vagy eljutott már addig a szintig, hogy a kormányt és a pedálokat tudja kezelni, de addig még nem, hogy lássa a közlekedést a maga egészében.

Ráadásul - ami aztán az én számomra főleg viccessé teszi a szituációt - amikor visszagyorsítottam (és nem mentem túl gyorsan), akkor meg lemaradt és onnantól kezdve "ok nélkül" tartotta fel az egész mögötte haladó kocsisort. Vagyis, kis híján agyf***t kapott attól, hogy 50 helyett 44-el mentem már másodpercig, de ha az előtte haladó 55-el megy, az már menjen, ő annyival nem fog, kit érdekel, hogy még 15 másik autót feltart ezzel legalább annyira, mint amennyire én tartottam fel őket... néhány másodpercig...

Egy ilyen autóvezetőnél látszik, hogy elvégezte a sulit (mert remélhetőleg volt azért jogosítványa :) ), és még az is lehet, hogy konkrétan volt autóvezetői tapasztalata is - nem fiatal gyerek ült a volán mögött -, de ő még mindig junior autóvezető volt (függetlenül a vezetett km-ek és évek számától), mivel képtelen volt a közlekedés ritmusára figyelni, azt felvenni és azzal együtt élni. Ráadásul még keménykedni is próbált azokkal, akik viszont nem az ő szája íze szerint közlekednének, ami sok esetben megint csak intő jele a tapasztalatlanságnak és/vagy az alapvető emberi szociális képességek gyenge állapotának.

Ezért is nehéz egy adott helyzetben felmérni, hogy partnerünk / társunk / interjúztatott leendő kollégánk vajon mennyire lesz jó egy adott szituációban. A tapasztalati évek száma jellemzően szükséges, de nem elégséges feltétel, és itt is vannak üdítő kivételek, amikor valaki 3-4 év valódi tapasztalattal problémamegoldás tekintetében "leveri" a 15x1 év tapasztalattal bíró társát, hiába van utóbbinak papíron 15 év tapasztalata, ha nem különféle problémákkal foglalkozott és elmaradt az önfejlesztés is az adott időszakban. És az is kérdés, hogy ha elmaradása van egy adott területen, akkor fejlődőképes lesz, vagy tojik rá. Ez is csak idővel derül ki...

Egy másik területen is láttam erre példát. Fiam nemrég iskolás lett, és az iskolában is ott is nagyon érezhető, hogy vannak tanárjelöltek, tanárok és pedagógusok. Mindannyiuknak megvan a maga hivatalos végzettsége, kinek több, kinek kevesebb tapasztalata. De reggel lehet látni, hogy kik azok a pedagógusok, akikhez rohannak a gyerekek és körbecsimpaszkodják (és jellemzően nem, ők nem az engedékeny típusúak!). Itt is nagyon erősen látszik a hitelesség fontossága, hogy ne bújjunk más bőrbe, mint akik vagyunk, és ne prédikáljunk olyan dolgokról, amit mi sem úgy csinálunk.

Te mennyire figyelsz a családban, a munkahelyen, az utcán az összképre? El tudod-e engedni hogy nem a számodra legjobb fog történni, ha cserébe számodra sem lesz rossz de rajtad kívül még sok másik ember számára így jobb lehet? Én, őszintén szólva, most úgy érzem, hogy lassan elértem a 80/20-as határt (kb. az esetek 80%-ban már az összképre figyelek, de még mindig van 20% erős önzés...).

R.I.P. BitBucket - avagy egy eddigi szép világ halála

A munkahelyen még valamikor a ködös távoli múltban (egészen pontosan 2011-ben), döntöttünk arról, hogy a Subversion-t új projektek esetén lecseréljük Mercurial (HG) kódtárakra. A csere oka az volt, hogy az akkori SVN branch-merge abban az esetben, amikor kénytelenek voltunk egy projektben párhuzamos fejlesztési szálakat vinni (és erről a megrendelők szerencsére gondoskodtak, hogy legyen ilyen), akkor meglehetősen nyögvenyelős kézimunka volt a merge folyamata.

Azt reméltük, hogy egy osztott verziókezelő esetén - ami kifejezetten arról szól, hogy párhuzamosan vannak fejlesztések, és sűrű a merge, így azt nagyon támogatni kell - sokkal jobb támogatást kapunk. Ez be is jött, határozottan sokat javultak a lehetőségeink.

Az akkori választásnál mérlegeltük a lehetőségeket, és oda jutottunk, hogy jobb nekünk a Mercurial a Git helyett. Ennek akkor több oka is volt, ezek együttesen billentették a mérleget. Nagyjából erősorrendben a következők voltak:

• Alapvetően Windows platformon dolgoz(t)unk, legalábbis a fejlesztői gépeken, de akkor még a szervereink is Windows Server 2008-ak voltak, és 2011-ben a Git messze nem volt jól támogatott Windows alatt.
• Akkor már pár éve a FogBugz feladatkezelőt használtuk (aminek akkor még volt itthon is értelmezhető árazással helyben telepíthető verziója) és akkoriban jelent meg hozzá a Kiln kiegészítés, amely segítségével a feladatkezelővel szorosan integrált Mercurial kódtárkezelést és code review lehetőséget is kaptunk. Jó kis cucc volt :)
• Az SVN után a Mercurial parancsai és opciói egyszerűbben kezelhetőnek tűntek.

Az azóta eltelt évek során nem is volt gondunk a kódtárkezeléssel, és azt gondolom, hogy rendesen be is gyakoroltuk a Mercurial használatát azon módszertan alapján, amit követünk (master branch az átadásokra, default-on megy alapvetően a fejlesztés, kivéve, amikor párhuzamos fejlesztés vagy valamilyen nagyobb feature van, az saját branch-en megy). Ami változást jelentett, hogy megszűnt a FogBugz és a Kiln azon, helyben telepíthető verziója, amit használtunk, így, előrenézve a jövőbe, 2017-ben úgy döntöttünk, hogy áttérünk a BitBucket-re, és szépen lassan átvittük a Mercurial kódtárainkat BitBucket alá.

Idén augusztusban aztán szomorúan olvastam, hogy úgy döntött az Atlassian, hogy beszántja a Mercurial támogatást a BitBucket-ben. De nem csak úgy simán beszántja, hanem sóval fel is hinti a helyét, biztos ami biztos.

Ez számomra elég hihetetlen volt. Igaz, lehet, hogy még változik a helyzet, mert a fenti linken olvasható tartalom is már legalább kétszer át volt alakítva, finomítva az elmúlt három hétben, amikor (gondolom, látva az első reakciókat), a korábbi kemény kijelentéseket igyekeztek finomítani.

Nyilván érthető, ha egy cég a profitra koncentrál, hiszen bizonyos értelemben ez a célja. Ugyanakkor, egy olyan kódtár szolgáltatásnál, amely:

• Mercurial-ra épült és később jött hozzá a Git, és kifejezetten deklarálta is azt a versenyelőnyét, hogy mindkettőt támogatja,
• Kifejezetten támogatta a nyílt forráskódú projekteket,
• Privát kódtárak esetén (>5 felhasználónál) pénzt kér a szolgáltatásáért,

Egyszer csak úgy döntenek, hogy 1 éved van arra, hogy - lényegében részükről mindenféle támogatás nélkül - elköltözz vagy konvertálj (ami szintén elköltözés, Git kódtárakba, csak kérdés, hogy a szolgáltató ez esetben marad-e, vagy azt is váltja az ember), és utána törlünk mindent.

És ez a törlünk mindent az, ami engem nagyon zavar. Megértem, ha nem támogatják már tovább a Mercurial kódtárakat, mert valóban, a Git (saját véleményem szerint sajnos) sokkal jobban elterjedt, és nem azért, mert "jobb".

De azzal, hogy egy csomó szolgáltatás felé volt integrációs lehetőségük, ahol pl. az egyes commit-okra hivatkozások lettek elhelyezve (pl. egy feladatkezelőben), azzal, hogy nem maradhat meg legalább csak olvashatóan egy állapot még évekig, vagy nem kerül átkonvertálásra statikusan elérhető html oldalakra az egyes commit-ok információja, gyakorlatilag megölik a múltat is. Azaz nem csak a jövőben lesz gondunk, hanem pl. nekünk megszűnik minden olyan feladatnál az általunk használt feladatkezelőben a most ott levő linkek működése, amely segítségével egyszerűen ugorhattam a feladat mellől a kapcsolódó kódmódosításra. Helyette a kódtár felől kell közelítenem, és commit megjegyzéseket kell lekeresnem, hogy össze tudjam szedni, hogy mi történt egy feladat mellett :(

A Google Code amikor bezárt, akkor nem csak támogatást nyújtott áttérésekhez, hanem egy archívumban meghagyta az elérhetőséget, és átirányít minden korábbi url-t az archívumba. Ez az archívum ma (2019. szeptember) is elérhető, több mint 3 évvel a bezárást követően.

Amikor a CodePlex bezárt, akkor nem csak támogatást nyújtott áttérésekhez, hanem egy archívumban meghagyta az elérhetőséget, és átirányít minden korábbi url-t az archívumba. Ez az archívum ma (2019. szeptember) is elérhető, lassan két évvel a bezárást követően, és nem is tervezik egyhamar a végét.

Nagyon örülnék annak, ha végül arra a - talán ésszerű - következtetésre sikerülni jutni az Atlassian-on belül, hogy valami hasonló archívum lehetőséget hasznos lenne biztosítani...

Addig is, a saját személyes BitBucket account-om pár napon belül véglegesen törlődik, átléptem a GitHub-ra, mivel ott is van már lehetőség privát kódtárra, és majd legalább megtanulom a Git használatát is.

Ez is megérne egy írást egyébként, mert normál módon nem is tudtam elindítani a törlést, mivel összekötötték a BitBucket account-ot egy Atlassian account-tal, és itt végtelen ciklusba keveredtek (mivel a BitBucket account-om egyfajta szolgáltatás volt, nem törölhettem a kapcsolódó Atlassian account-om, mert volt hozzá aktív szolgáltatás berakva - viszont ezt a szolgáltatást külön nem tudom lekapcsoltatni...). No mindegy, erről nem akarok már külön regélni :)

Viszont, hogy cégesen mi lesz a döntés és a helyzet, még nem tudom. Nagyon jó lenne megtartani a branch-eket és commit-okat úgy, ahogy most vannak és félek, hogy egy Git migrációval nem lesz 100%-osan ugyanolyan a történetiség. Úgyhogy lehet, hogy maradunk a Mercurial-nál és visszatérünk egy helyi hosting lehetőségre pl. a Phabricator segítségével... ennek meghatározása még egy előttünk álló feladat, ami az egyéb, ügyfelek által adott feladatok mellé most épp nem jött jókor...

Van-e gyakorlati tudás elméleti háttérismeret nélkül?

Olvastam nemrég egy prog.hu fórumtopik-ot, az alábbit:

https://prog.hu/tarsalgo/205333/netbeans-ide-hasznalata-kozepiskolaban

Erről eszembe jutott néhány gondolat, amikről egyébként írtak is egyesek a topik-ban, de az én gondolataimat is megmozgatta annyira, hogy bejegyzés szülessen belőle :)

Szóval, az én gyakorlati tapasztalataim alapján (kb. 25 év szoftverfejlesztés, azon belül már jó 15 éve architektúra-tervezéssel is kiegészítve):

• Teljesen, 100%-osan egyetértek azokkal, akik az alapelvek oktatását hiányolják. Teljesen mindegy, hogy "végül" milyen fejlesztőkörnyezet lesz használva Java vagy C++ programozás tanítására, mert a programozás tanítása - még középiskolás, sőt általános iskolás szinten is - a következőképp kellene, hogy kezdődjön:
• Általános algoritmikus és programozási alapelvek tanítása, úgy, mint mi az, hogy egész szám, lebegőpontos szám, karakter, szöveg, dátum, logikai érték, mit jelent az utasítás, az értékadás, a vezérlés (feltételes elágazás, ciklus), mi az a változó
• A fentieket tanítva akár több különböző programozási nyelvből is lehet olyan egyszerű példákat mutatni, amelyeket látva megértheti a diák, hogy valóban nem a szintaxis megtanulása a célratörő, hanem a mögötte rejlő alapelvek
• Erre jöhet rá később néhány magasabb szintű alapelv (pl. legalább a tömb/lista/halmaz/map adatstruktúrák ismerete, funkcionális programozási alapok, objektum-orientált programozási alapok, aspektus-orientált programozási alapok stb.) bemutatása, szintén, az alapok akár több különböző nyelvből is példákkal illusztrálva - ahol pl. már arra is rá lehet mutatni, hogy milyen nyelven, környezetben milyen típusú megoldás van "natívan támogatva", és mi az, ami nincs, illetve akár arról is lehet kicsit elmélkedni, hogyan lehet valamit megvalósítani, ha az adott környezetben nincs natív támogatása
• A mai, 21. századi informatikában nagyon sok terület, lehetőség van, de ami szinte mindenhol előjön, mint haladó téma, és mindenképpen megéri foglalkozni vele, elméleti és gyakorlati szinten is:
• Párhuzamos, több szálú program végrehajtáshoz kapcsolódó fogalmak és azok működése a kiválasztott környezetben
• Változók, objektumok életciklusa, static typing vs. dynamic typing közötti különbségek, futtatókörnyezetek működési alapjai, "szemétgyűjtés"
• A kiválasztott programozási nyelv esetén a nyelv, a környezet (fordító, linker, virtuális gép stb. hol mi az, ami van) és a nyelvhez tartozó standard library közötti összefüggések, különbségek (hogy egyértelműen értsük, hogy végződik a nyelv és hol kezdődik a library). Ennek része az is, hogy az adott nyelvi környezetben hogyan zajlik az alapvető folyamat, ahol a forráskódból végrehajtható program válik.
• Számomra csak ezt követően jön el az, hogy fejlesztő környezettel kezdünk ismerkedni, hiszen ekkor meg rá lehet mutatni, hogy az adott fejlesztőkörnyezet pl. hogyan támogatja a projektek létrehozását és kezelését, hogyan segít a forráskódból végrehajtható programmá alakulás folyamatában stb. És - a fejlesztő környezettel együtt - fontos néhány további dolgot is tárgyalni, úgy, mint:
• programozott tesztelés: teljesen mindegy, fejlesztők vagy tesztelők leszünk, vagy mindkettő egyszerre :), fontos, hogy értsük és tudjuk, mint jelent a unit tesztelés, az integrációs tesztelés, a kézi és az automatikus tesztelési folyamatok, és azon alapelvek, amelyek segíthetnek jól tesztelhető kódok ill. komponensek készítésében (pl. IOC)
• build eszközök: pl. JVM környezetben (ahol én is dolgozom) ma már teljesen alapvetőnek kellene, hogy számítson a Maven és a Gradle alapszintű használata, a 3rd party lib-ek elérhetősége függőségkezelésen keresztül
• segítő eszközök: a legtöbb környezetben elérhetők olyan eszközök, amelyek segíthetnek a programjainkban a nagyon elemi elírások/hibák észlelésében és felderítésében. Ilyenek pl. a statikus kódelemzők, a tesztfuttatások során "direkt hibákat vétő" megoldások, de ide tartozik a debugger (és azok gondolkodási mód, ami segíthet a hatékony használatában), a naplózási alapelvek és naplózási eszközök és a különböző, a programjainkat futásidőben monitorozó megoldások (profiler-ek)
• további elvi érdekességek: ide sorolhatók pl. a tervezési minták, a SOLID, DRY, YAGNI stb. ismerete, ezek is sokat segítenek a szemléletformálásban

Ha valaki egy olyan oktatónál tud tanulni, aki figyelembe veszi a fentieket, ott biztos lehet abban, hogy a Netbeans, vagy az Eclipse, vagy bármilyen más környezet dolgait fogja elsősorban megtanulni, hanem azt a gondolkodásmódot, amely segítségével valóban szoftverfejlesztővé válhat.

Egy volt kollégám, aki az én első munkás éveimben az egyik fontos mentorom is volt, írt egyszer nagyon velősen arról, amiről Peter Norvig kicsit bővebben, hogy miért nem jelenti ugyanazt egy programozási nyelv megtanulása, mint a programozás megtanulása, és, hogy miért is kell hosszú idő ahhoz, hogy valakiből valóban jó szoftverfejlesztő váljon.

Persze, a mai eszközök és megoldások (akár a Scratch, akár egyéb, "vizuálisan összekattogtatós megoldások") egyre jobban terjednek és azt a feeling-et adják, hogy "ez nem is olyan bonyolult". És, igazuk is van :) Viszont a fejlesztés sosem azért volt bonyolult, mert nehéz a szintaxis. A fejlesztés mindig is azért volt bonyolult, mert:

• Tudni kell megfelelően kialakítani azt az absztrakciót, amely lefedi az aktuális igényeket, és teret hagy a továbbfejlesztésekhez abban az esetben, ha nem változik meg teljesen az alap működési elv
• Ehhez meg kell tanulni szöveget értelmezni, abból absztrakt modelleket felépíteni, azzal összemérni az elvárt igényeket és pl. észrevenni, ha ellentmondásosak az elvárások, ...
• Tudni kell kiválasztani a megfelelő eszköztárat, amely segítségével az adott igény megvalósítása megfelelő színvonalon, ugyanakkor lehetőségek szerint az elvárt határidőn és költségkereten belül megtehető

Persze, nagyon sokféle terület van jelenleg is, amire azt mondjuk, hogy fejlesztői feladat. Nyilván, ha a fő profil, hogy van egy vagy két féle "termék", amelyeket minimális testreszabással szállítunk, és ezen - viszonylag egy kaptafára történő - testreszabásokat fejlesztők végzik, erre a feladatra nem feltétlenül kell olyan fejlesztőt felvenni, aki "nulláról" is képes fejleszteni, és képes új megoldásokat adni felmerülő problémákra.

Ha viszont valaki túl szeretne valaha lépni az "emelt szintű fejlesztői segédmunkás" szerepkörön, az kénytelen a fenti - nyelv- és környezetfüggetlen - alapelvekkel is megismerkedni, mert ezek nélkül viszonylag hamar "meg fog rekedni" egy szinten...

Visszatérve egy gondolat erejéig a Netbeans "betiltására", ami a témaindító topik volt. Kollégáimmal:

• A 90-es évek végén Java fejlesztésre a Visual J++ eszközt használtuk, mert fényévekkel gyorsabb és kezelhetőbb volt, mint akkoriban bármilyen versenytársa (a 233Mhz-es MMX Pentium processzorral és 128MB memóriával szerelt fejlesztői gépen mindenképp)
• Utána tettünk kitérő Visual Café, Forte (a Netbeans elődje), Borland JBuilder irányokba is, sőt megnéztük az Emacs-ot is a JDEE-vel; mindegyikkel végeztünk produktív szoftverfejlesztést
• Végül rátaláltunk az Eclipse-re (ekkor még az Eclipse 2.0 volt aktív fejlesztés alatt :) ), és utána egészen sokáig az Eclipse maradt, illetve később az STS (SpringSource Tool Suite)
• Végül, 2016-ban váltottunk az Intellij IDEA-ra, és azóta azt használjuk

A lényeg: mivel kollégáim ismerték/ismerik az alapelveket és megvan a szükséges háttértudásuk, gyakorlatilag mindegyik váltásnál gyakorlatilag a 2. napon már teljesen produktívan tudtak dolgozni, aztán persze még jobban megismerték az eszközöket és még hatékonyabbá váltak. Nem azt tanulták meg, hogy "és akkor az eszköztáron a 8. ikont, ami olyan izé... színű és formájú, ha megnyomom, akkor utána tudom majd futtatni a programomat", hanem azt, hogy "hol van a build menüpont" :)

2019-es "álom" fejlesztői eszköztáram :)

Lassan eljön 2018 év vége és beköszönt 2019. És immáron legalább 5 éve, hogy a "mainstream" fejlesztési feladatokból "kiestem", helyette főleg architekt ill. business analyst jellegű feladatokat látok el néhány projektünknél. Viszont próbáltam azért minél kevésbé "visszaesni", bár a Pat Kua által említett "még foglalkozzunk programkód írással" (https://www.thekua.com/atwork/2018/02/5-tips-for-being-an-effective-tech-lead/ 2. pontja) nem nagyon megy, főleg, mivel a tech lead mellett más szerepkörökben is helytállok (business analyst ill. 2. és 3. szintű ügyféltámogatás egyes projektekben). Viszont arra ügyelek, hogy minél jobban lelassítsam a teljes kiesést, így azért néhány szituációban még programozom, ill. olvasok kódot, azaz nem szakadtam el teljesen a kódbázistól:

• néhány kiosztott feladatnál én vagyok a reviewer (elsősorban olyan feladatoknál, ahol nem az API használat a lényeges, hanem bizonyos algoritmikus / üzleti megoldások, így ugyanis, hogy napi szinten nem kódolok, a forráskód elviségét tudom elsősorban áttekinteni és véleményezni, nem a helyes külső API paraméterezéseket)
• főleg nagy átadások során (akár UAT, akár éles átadás után), ahol az első hetekben azért sok apróság tekintetében jön visszajelzés, egy-egy, az adott projektnél teljesen "lokális" probléma esetén én végzem el a javítást (szintén általában ott, ahol elvi probléma volt a korábbi megvalósítással, és nem valamilyen rossz paraméterezés)
• időről időre felmerül kisebb, belső használatú, vagy projektnél egyszer lefutó kis utility-k készítése, ahol messze nem feszítő a határidő, azok közül is van, amit még bevállalok
• van egy nagy álmom is :) bár alapvetően a projektjeink dokumentálva vannak, még érzek "fehér foltokat" kifejezetten a belső fejlesztői dokumentáció tekintetében (azaz, kellene egy olyan anyag, ami mélyebb/más jellegű, mint az ügyfelek felé átadott informatikai specifikáció, viszont továbbra is főleg a felső szintű áttekintést biztosítja, viszont ezt fejlesztői oldalról, segítve az adott projektben új embereket a minél gyorsabb bekapcsolódásban)

Persze, amellett, hogy igyekszem azért "kódközelben maradni", viszonylag rendszeresen figyelem azokat a változásokat, újításokat, amelyek segítségével az eszköztárunkat hatékonyan lehet bővíteni / fejleszteni. Mi JVM alapú rendszereket készítünk, középméretű (néhány százezer "saját kódsor") nagyvállalati szoftvereket, ahol vagy webszolgáltatás alapú API-t biztosítunk, vagy webes felhasználói felületet, és jellemzően kell más rendszerekkel kommunikálni, ill. oda kell figyelni a nagyvállalati biztonsági és egyéb előírásokra. Java-ban (most már a 8-as verzióban is), illetve Spring keretrendszer, Hibernate, JOOQ viszonylag nagy tapasztalattal rendelkezünk, de, mivel a projektek közül sok már jó néhány éve kezdődött és azóta is működik (rendszeres finomítással/továbbfejlesztéssel), már sok külső könyvtárral ismerkedtünk meg, amelyeknél most már vannak ügyesebbek / jobbak / "teljesebbek".

Ha most, 2018 év végén, 2019-ben kellene új rendszert kezdeni a fenti területen, akkor szívem szerint a következő technológiai stack-et használnám (amiről úgy érzem, hogy nem hátráltatna, és a mostanában nálunk futó nagyvállalati projektkörnyezetben is kiválóan alkalmazható lenne):

• Futtatókörnyezet: JVM, Java 8 vagy Java 11
• Programozási nyelv: Kotlin 1.2
• Felhasznált 3rd party keretrendszerek, könyvtárak:
• Egyszerűbb esetekben:
• DB kezelés: Spring JDBC vagy, ha csak alapok kellenek, akkor Exposed (https://github.com/JetBrains/Exposed)
• Web API: Ktor (http://ktor.io/)
• Kiegészítések a standard Java / Kotlin osztálykönyvtárakhoz:
• Eclipse Collections (https://github.com/eclipse/eclipse-collections/)
• Spring Framework (IOC konténerhez)
• Ha nagyobb/bonyolultabb dolog kell / web GUI kell hozzá, akkor a fentiekhez kiegészítésképpen:
• Web GUI: követelményektől / körülményektől függően ReactJS (+PrimeReact: https://www.primefaces.org/primereact/#/) vagy JSF (PrimeFaces: https://www.primefaces.org/showcase/)
• Backend: Spring Boot 2 (https://spring.io/projects/spring-boot) és függőségei
• Unit és integrációs tesztelés: JUnit 5 és Mockk (a https://blog.philipphauer.de/best-practices-unit-testing-kotlin/ cikk alapján)
• Fejlesztőkörnyezet: IntelliJ IDEA Ultimate :)
• Build és CI környezet (amennyire lehet, Docker konténer alapokon összeállítva :) ):
• kódtár: Mercurial (BitBucket-en keresztül) - tudom-tudom, nem Git, de ebben sokkal nagyobb a tapasztalatunk és nem érezzük egyelőre a saját munkamenetünkben, hogy a kódtár sajátosságai miatt hátrányos helyzetben lennénk
• build környezet: Gradle (https://gradle.org/)
• CI környezet: Jenkins LTS (https://jenkins.io/) + SonarQube LTS (https://www.sonarqube.org/) a Sonar-Kotlin kiegészítéssel (https://github.com/arturbosch/sonar-kotlin)

A közeljövőben jobban bele szeretném / fogom ásni magam a Kotlin és a kapcsolódó eszköztár környezetbe, hogy lássam, mennyire jól mértem fel, hogy ezzel a nyelvvel hatékonyan előreléphetünk a JVM alapú feljesztésben a Java-hoz képest :)