Fejlesztői segédeszközök Windows alatt, avagy mivel gazdagodtam az elmúlt év során

Kedves Naplóm!

Jó régen írtam már utoljára, elég sok minden történt, ami miatt nem vettelek elő (persze, mint általában mindenkit, engem is leginkább a "kreatív lustaság" tartott vissza, mindig találtam jobb szabadidős elfoglaltságot :) ).

Az elmúlt év során elém került jó néhány olyan eszköz ill. megoldás, aminek a segítségével sikerült tovább fokozni / növelni a hatékonyságom. Mivel sok okból Windows-os környezetben dolgozom (a két legfontosabb a tesztelések ill. az egyéb feladataim miatt az MS Office igen erős használata), nagyon megörültem, hogy találtam néhány olyan dologra is "megoldást", amihez hasonlókat Linux-os környezetekben nagyon könnyen meg lehet szokni. Az is nagyon jó, hogy sikerült olyan lehetőségeket is találni, amelyek segítségével viszonylag platformfüggetlen módon, a munkahelyi és az otthoni eszköztárat minél inkább "közösítve" tudok pl. feladatokat ill. dokumentumokat/referenciákat kezelni.

Nézzük, mik is ezek az eszközök!

Parancssor

A Windows Terminal (https://aka.ms/terminal) nagyon jól kezelhető és barátságos parancssor megoldás. Ráadásul vannak olyan kis utility-k, amelyekkel még jobban fel lehet turbózni, a személyes kedvencem pl. a pshazz (https://github.com/lukesampson/pshazz).

A dokumentációja is egészen jóra sikerült (https://docs.microsoft.com/en-us/windows/terminal/).

Csomagkezelés

Amikor Windows alatt csomagkezelésről van szó, akkor elsősorban a Chocolatey (https://chocolatey.org/) jut az ember eszébe. Nem is rossz kis cucc, sőt, de valahogy nekem mindig volt vele valami kis nyűgöm, ami miatt nálam nem tudott hosszabb ideig "megtelepedni".

Amikor először találkoztam a Scoop-al (https://scoop.sh/), nézegettem, és egyre jobban megtetszett. Aztán kipróbáltam, és néhány hónap használat után azt gondolom, hogy az én használati módomnak nagyon jól betalált a "cucc" :) Pont olyan dolgokat csinál, amelyek nekem tetszenek - pl. saját mappán belül dolgozik, nem pakol sehova extrákat, de mégis bekerülnek a Windows alkalmazások listájába a programok, az eredeti telepítőcsomagokból dolgozik stb.

A tapasztalatok alapján amire nem használom, az a webes böngészőprogramok telepítése és frissítése. Ott annyira megszokott a böngészőn belüli frissítés hogy jobb azt használni.

Amire viszont használom:

• A JetBrains-ek "bucket" hozzáadása után az IntelliJ IDEA Ultimate és a DataGrip telepítésére, frissítésére - bár itt van még a verziószámozással némi gixer, ezért "force-olni" kell a frissítéseket, de ettől eltekintve teljesen jól működik (de ennek a javítása is folyamatban, https://github.com/lukesampson/scoop/pull/3333)
• Java SDK-k és egyéb számomra fontos programozási nyelvek telepítése és frissen tartása: pl. adopt8-upstream (Java 8), adopt-11-upstream (Java 11), groovy, kotlin, python, nodejs-lts
• Fejlesztői segédprogramok kezelése: pl. git-with-openssh, mercurial, gradle, maven, yarn, kitty, jmeter, postman, soapui
• Szöveges / grafikus szerkesztőprogramok kezelése: pl. greenshot, paint.net, vscode, notepad2-mod
• Dokumentációkészítéshez kapcsolódó kiegészítő utility-k kezelése: latex, pandoc, plantuml, graphviz, cloc
• Terminál prompt :) pshazz - némi saját kiegészítéssel...
• Egyéb, amire szükségem van: far (Far Manager), sudo, vlc, wget, keepass, keystore-explorer, tomcat

Nagyon kényelmes és egyszerű a kezelése, saját magam ütemezem a frissítéseket, és viszonylag gyorsan meg is jelennek az egyes verziók.

Feladatkezelése, dokumentálás

A munkahelyen feladatkezelő rendszerként főként a JetBrains YouTrack rendszerét használjuk, ami szerencsére nem túl régen egyfajta dokumentációs lehetőséggel is bővült, azaz most már nem csak feladatok nyilvántartására alkalmas, hanem különböző referencia-tartalmak is jól kezelhetők benne.

Ez, továbbá az, hogy a felhős változat is ingyenessé vált max. 10 felhasználóig, valamint hogy egy egészen kezelhető mobil alkalmazás is elérhető (és a két-faktoros beléptetés is!), segített abban, hogy az otthoni "backlog" ill. referenciaanyagok kezelése kapcsán is ezt az alkalmazást válasszam. Továbbra is a Todoist a fő feladatplatform, ami az ütemezést, ill. az aktuális heti feladatokat jelenti, ott viszont pont a "Backlog" ill. a részletesebb kidolgozás tárolása/kezelése/keresése nem volt kifejezetten az erőssége. Így ezzel a két eszközzel egészen jól le tudom fedni a feladatkezelési igényeimet.  

Nagyon jónak tartom azt is, hogy a Knowledge Base a tartalmakat Markdown formátumban kezeli, mivel a Markdown segítségével - kiegészítve a PlantUml és a Mermaid diagram-kezelési lehetőségeivel - készítem mostanában mindazokat a fejlesztői anyagokat, amelyek így teljesen "plain text" formátumban vannak, azaz verziókövető rendszerben is jól kezelhetők, a Markdown részük teljesen jól kezelhető a Youtrack alatt is, továbbá mind az IntelliJ IDEA, mind a Visual Studio Code alatt megnyitva ezeket a doksikat, az előnézetekben szépen a kódpéldák mellett ezek a diagramok is renderelve jelennek meg. Ezen kívül, ha kell, a Pandoc segítségével többféle dokumentumformátumra viszonylag könnyen átültethető.

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örnyezeteirő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 :)

Pengeélen

Nemrég egy igen komoly rendszerfejlesztés/átalakítás első fázisát fejeztük be. Komoly volt az alábbi értelemben:

• Egy, már öt éve működő (és ezen időszak alatt is folyamatosan bővülő, finomodó) rendszer került szinte teljesen új alapokra, de NEM újraírásra
• Az öt év tapasztalataiból nagyon sok mindent felhasználtunk és a legfontosabb struktúrális és elvi problémákat sikerült is kezelnünk
• A rendszer teljes mértékben támogatja a korábbi folyamatokat, ugyanakkor teljesen új folyamatokat és irányvonalat is alkalmaz (pl. elektronikus dokumentumkezelés, érintőképernyős aláírások kezelése, teljes tablet- és mobiltámogatás, ami még nem volt a rendszerben a 2012-es indulásakor)
• A számos új lehetőség és folyamat miatt az adatmodell (táblák és mezők) száma kb. 40%-kal, a kódbázis pedig kb. 50%-kal nőtt (így lett kb. 440e sornyi saját kód a rendszer aktuális állapotában), ugyanakkor a teljesítmény nem csökkent, sőt több helyen nőtt (a struktúrális átalakítások következtében)

Minden naptári időben kb. 15 hónapot vett igénybe, 5-6 kollégával. Az eddigi pályafutásom talán legkomplexebb feladata volt. Szerencsére sikerrel vettük az akadályt, gyakorlatilag határidőre és egészen jó minőségben sikerült leszállítani a rendszert.

Maga a projekt ütemezési/belső technikai része is érdekes volt: pl. milyen metodikával tudtuk elérni, hogy "nem törtük szanaszét" a rendszert a teljes átalakítás során, erről később írok.

Ami a projekt kapcsán leginkább megmaradt bennem, az, hogy mennyire sokféle területen van szükség "egyensúlyozásra" annak érdekében, hogy a projekt sikeres legyen, és sokszor mennyire nehéz ezen egyensúlyozás végrehajtása. Gyakorlatilag több dimenzióban is folyamatosan "pengeélen" táncol az ember, és bármelyik irányba lép nagyot, abból tuti zakózás lesz.

Ebben a fejlesztésben - mai divatos szavakat használva - voltam business analyst, architect, product owner, tesztelő és ügyfélszolgálatos is (utóbbiak leginkább a kollégák tehermentesítése céljából, hogy legyen idejük és lehetőségük az elmélyült és alapos munkára, legalábbis annyira, amennyire az ütemezés és a feladatok komplexitása ezt lehetővé tette).

Mindegyik szerepkörben voltak nagyon érdekes kérdések, amelyek felmerültek, és nagyon nem volt egyértelmű, hogy mit kezdjen vele az ember. Ennek oka elsősorban a "tipikus nagyvállalati szoftverfejlesztés" háttere volt:

• A megrendelő részéről nem volt egy dedikált projektfelelős, aki kézben tartotta és priorizálta volna a feladatokat, hanem több üzleti területnek voltak delegált tagjai, akiknek - az egyébként is túlzsúfolt és adminisztrációval telített - napi operatív feladataik mellett kellett (volna), hogy a rendszerrel kapcsolatos elvárásaikat meghatározzák, és olyan szinten dokumentálják, ami alapján már értelmezhető a feladat. Látszott, hogy igyekeznek megfelelni a feladatnak, de erős hátrányból indultak már eleve ezen körülmények miatt.
• Több üzleti területtől voltak olyan delegált tagok, akik gyakorlatilag nem is ismerték a rendszer aktuális változatát, mivel az még az ő tevékenységüket nem támogatta, de az átalakítás és bővítés után már nekik is ebben a rendszerben kell dolgozniuk. Ez egyrészt kihívás volt (teljesen más fogalomrendszer használata, számunkra sokszor ismeretlen üzleti folyamatok), másrészt jó volt abban az értelemben, hogy kiderült, hogy a támogatott üzleti folyamatok sem úgy vannak teljesen a valóságban, ahogy az a rendszerben működik (mertháthogy nem nagy az eltérés, és erre az adaptációra, amikor a folyamatunk megváltozott, nem akartunk pénzt költeni).
• Láthatóan mindenkinek a célja a saját elvárásainak kielégítése volt, és nem igazán voltak olyan megrendelői egyeztetések, ahol az egyes üzleti területek egymással tisztázták volna a prioritásokat. Így időnként
• A napi munka melletti tevékenységnek és a korábbi rendszer "nem ismeretének" volt egy olyan mellékhatása is, amitől egyes megbeszéléseknél egyértelműen az 50 első randi című film jutott eszembe. Voltak olyan folyamatok, amelyeket a tervezési fázisban négyszer, a fejlesztési fázisban szintén négyszer alakítottunk ki/át teljesen, majd a tesztelési fázisban is sikerült alaposan felforgatni egyes területeket. És nem azért, mert az üzleti folyamat változott, hanem azért, mert igazából nincs definiált üzleti folyamat, hanem a szereplők nagyjából így és így dolgoznak, de igazából minden nap egy kicsit másképp. Hiába volt bármi leírva, ha a napi munka mellett nincs idő elolvasni, így, ha egy kérdés újra felmerült, már más volt a válasz, mint korábban (akár egy héttel azelőtt).
• Mindezek mellett ugyanakkor a teljes projekt egy, a projekt elején készített specifikáció alapján fix határidős, fix költségvetésű projektként ment. Ezért egy idő után a közös érdek mellett (ti. hogy legyen egy jól használható, hatékonyan működő rendszer, ami az üzleti elvárásokat megvalósítja és a felhasználók is szeretik használni a célszerűsége miatt) megjelentek a saját érdekek is (beszállítói oldalon értelemszerűen, hogy ne nyújtsuk túl a projektet, megrendelői oldalon pedig a "ezért a projektért sokat fizetünk, így ez még bele kellene, hogy férjen" merült fel teljesen természetes emberi hozzáállásként).

A fenti körülmények által létrehozott univerzumban minden szerepkörömben érdekes "pengeéles" szituációk voltak. Ezek közül amelyek a legjobban megmaradtak bennem, az alábbiak voltak:

• business analyst-ként:
• Ha már letárgyaltunk és specifikáltunk valamit, majd attól elkezdünk eltérni, mennyire hívjam fel erre a figyelmet és kérdezzek vissza, hogy mi az oka a változásnak? Vagy inkább figyeljem meg, hogy mik azok a területek, amelyek "folyamatosan változnak" és ott specifikáljuk úgy a folyamatokat, hogy rugalmasan kezelhető/módosítható legyen?
• Mennyire kérdezzem ki a valós üzleti folyamatot, mennyire erőltessem a nem tiszta / nem egyértelmű megfogalmazások letisztázását? Látszólag erre a kérdésre egyszerű a válasz, mert legyen minden egyértelmű, ugyanakkor teljesen más az a szint, ami egy, az adott üzleti területen gyakorlott embernek "egyértelmű", és más az, amikor egy, az adott üzleti területen relatíve kevés tapasztalattal bíró fejlesztő számára "egyértelmű".
• Ez egyébként két irányban is problémát jelentett. A megrendelővel való kommunikációban én voltam a "gyenge láncszem", nekem voltak hiányos háttérismereteim az üzleti folyamatról. A fejlesztő kollégákkal való kommunikációban viszont fordított volt a helyzet, hozzájuk képest én rengeteget tudtam az üzleti folyamatról, amit ők (joggal) nem tudtak.
• A különböző üzleti területek keveset egyeztettek egymással, és mivel nem volt üzleti oldalon priorizálási felelős, a beszállítónak (nekünk) kellett ellátni ezt a meglehetősen hálátlan feladatot (hiszen itt valakinek mindig "rossz lesz", ha egymással ellentétes elvárásokból kell kihozni "valami jót"). Ugyanakkor muszáj volt ezt megtenni, másképp könnyen halastóvá válhatott volna a projekt, és az még rosszabb lett volna. Viszont ezt a szerepet sem szabad túltolni, mert akkor nagyon rossz híre lesz a beszállítónak a megrendelőnél ("azok a kötözködősök már megint...").
• architekt-ként:
• Hogyan legyen az alap úgy felépítve, hogy az üzleti igények folyamatos változása és átalakulása a legtöbb esetben ne alapjaiban rengesse meg a felépítményt, hanem még beleférjen a koncepcionális modellbe? De ne legyen túltolva ez sem, mert akkor meg sosem lesz konkrét rendszer belőle...
• Lépjünk előre mindig mind a rendszerfelépítés, mind a felhasznált eszköztár tekintetében (cél, hogy ne váljunk "dinoszaurusszá" azzal, hogy görcsösen a már megismert környezetekhez és lib-ekhez ragaszkodunk), de ugyanakkor ne túl nagy lépésben, mert akkor a projekt helyett eszköztanulással töltjük az összes időt.
• Fontos az üzleti folyamat támogatása, de (majdnem) ugyanilyen fontos a rendszerben a "transzparencia" (problémafelderítésre, auditálásra és belső ellenőrzési feladatokra is alkalmas log-ok), a biztonság (mindenki csak ahhoz férjen hozzá, amihez kell) és a minél egyszerűbb üzemeltethetőség/frissíthetőség. Ja, és persze a teljesítmény is jó legyen :) Szóval ezen területek között is érdekesen lehet "lavírozni", és nagyon könnyű elcsábulni valamelyik faktor erősítése felé a többiek rovására.
• product owner-ként (bár itt kicsit többről/másról van szó, egy kicsit projekt menedzserként, egy kicsit vezető fejlesztőként és egy kicsit Scrum master-ként is tevékenykedtem ebben a projektben):
• Hogyan legyenek a feladatok úgy szétosztva a kollégák között, hogy mindenkinek legyen feladata; ne legyen túlterhelve de ne is tudjon "takubakuzni"; miközben figyeljünk az egyes személyek kompetenciájára, aktuális tapasztalatára, erősségeire is, építsünk rá, de engedjük továbbfejlődni/kiteljesedni is - de persze nem a feladatvégzés kárára. És persze, nem utolsósorban, a prioritásoknak és a felépítésnek megfelelő sorrendben végezzük a feladatokat.
• Ha valamit úgy lát az ember, hogy "nem megfelelő", az kivel milyen módon, formában, lehetőleg előremutatóan legyen kommunikálva.

Szóval, érdekes volt. Sokat tanultam magamról is, meg a világról is, és sikerült továbbfejlődni kommunikáció terén is (bár, néha nem vagyok biztos abban, hogy a továbbfejlődés a megfelelő szó... :) ). De az biztos, hogy ez a projekt is megmutatta, hogy a szoftverfejlesztés egy bizonyos szint felett (amikor komplex feladatokat kell több embernek sok hónapon keresztül megfelelően elvégeznie, folyamatosan változó követelmények mellett) meglehetősen embert próbáló feladat. 

Le a kalappal azok előtt, akik a következő komplexitási szinten (több millió soros projektek, több tucat szereplővel, több éves átfutás alatt) képesek irányítói szerepkörben megfelelően teljesíteni.

Így lettem anyagilag (és más téren is) sikeresebb

Nemrég olvastam az egyik követett blog-on egy bejegyzést és a kapcsolódó kommenteket arról, hogy lehetünk anyagilag (is) sikeresebbek.

Ennek kapcsán átgondoltam, hogy a saját életemben sikeres vagyok-e, vagy sem. Végül arra jutottam, hogy sikeres vagyok, mert:

• szerető családban élek, a napi összezörrenéseken túl nincs konfliktus :)
• alapvetően az egészség is megvan, bár a kor már mintha kezdene látszódni...
• szép helyen élünk, megfelelő infrastruktúrával, hitel nélkül
• a család havi bevételei fedezik a kiadásokat, van lehetőség megtakarítani is, és közben egy, számunkra teljesen normális életszínvonalat tudunk biztosítani magunknak, amelyben megvan mindenünk, amelyre igényünk van (igaz, nincsenek luxus igényeink)
• normális munkahelyen dolgozom, a főnökeim és a kollégáim is megbecsülnek, és én is őket, abszolút működik a közös munka és teljesen ismeretlen a "másik fúrása"
• azt gondolom, hogy azon emberek többsége, akiket akár a magánéletben, akár a munkán keresztül megismertem, normális és korrekt embernek tart, legalábbis ezeket a visszajelzéseket kapom :)

No, de mit tettem én ezért? Jó kérdés, és nem is nagyon tudnék rá válaszolni, mert sok esetben tyúk-tojás kérdésről van szó (példa: azért tudok olyan ember lenni, amilyen, mert jó munkahelyem van, vagy azért lehet jó munkahelyen, mert olyan ember vagyok, amilyen?). Ezért csak úgy, abszolút véletlenszerű sorrendben, ahogy eszembe jutott, leírok pár dolgot, amiről azt gondolom, hogy hozzájárultak az én utamon ahhoz, hogy elérjek oda, ahol jelenleg vagyok:

• rendszeres sport, legalább gyerek- és fiatalkorban: szerencsére szüleim ragaszkodtak hozzá, hogy sportoljak kb. 8 éves koromtól kezdve suli mellett, és addig próbálkoztunk, amíg nem találtunk olyan sportágat, amit nagyon megszerettem. Nekem ez a kajakozás volt, 6 éven keresztül suli előtt és suli után edzésre jártam. Valószínűleg sokat segített abban, hogy a sulit is jobban bírtam, illetve a szervezetem kellően megedződött. Később volt még harcművészet, néptánc, súlyzós edzések, futás, úszás, egészen kb. 26 éves koromig legalább heti 4-5 alkalommal edzettem. Sajnos azóta visszaesett a dolog, és érzem is...
• hitelesség: ha valamit megígérek, azt betartom. Ha esetleg nem sikerül és már látom, hogy nem fog, akkor jelzek róla annak, akinek megígértem. Ezt nagyon-nagyon fontosnak tartom, két okból is:
• egyrészt viszonylag kevesen művelik (sajnos), ezért csak ezzel az egy dologgal nagyon "ki lehet emelkedni" a tömegből,
• másrészt ha valaki hiteles, akkor tényleg bízni fognak benne, annak minden előnyével (és felelősségével) együtt
• problémamegoldási hajlam: ha feladat van, akkor arra megoldást kell találni, és nem azon gondolkodni, hogy miért nem én, miért nem most és miért nem úgy. Nem tudom, mi kell hozzá, hogy ez ki tudjon alakulni (én sokat olvastam, ez biztosan segített), de ez is egy nagyon fontos tulajdonság.
• kilépés a komfortzónából: az előzőhöz szorosan kapcsolódik. Olyan feladatunk van, amit még előtte nem csináltunk? Nem berezelni kell tőle, hanem utánamenni :)
• prioritások kezelése: sajnos sokszor hajlamosak vagyunk a leggyorsabban és legkényelmesebben intézhető dolgokat intézni először, és a nehéz (és sokszor nagyon fontos) dolgokat halogatjuk. Aki ezt képes megfordítani, és először a valóban fontos feladatokkal végezni, az minden normális munkáltató számára kincset ér :)
• gyermeki nyitottság, érdeklődés fenntartása: minden nap érjen úgy véget, hogy tanultunk aznap valami olyat (bármit, akármilyen témában), amit aznap reggel még nem tudtunk. Lehet ez családi dolog, munkával kapcsolatos, bármilyen hobbival kapcsolatos, a lényeg, hogy dolgoztassuk meg minden nap a kis buksinkat.
• empátia, figyelmesség, odafigyelés a másikra: ugye nekünk is jól esik, ha valaki törődik velünk, figyelmes és észreveszi, ha valami, számára apró dologgal nekünk nagy segítséget tud adni (akár csak azzal, hogy figyelmesen meghallgat bennünket)? Legyünk mi is ilyenek a számunkra fontos emberek számára, de akár bármilyen hétköznapi helyzetben is lehetünk figyelmesek. 

Van még persze egy csomó dolog biztosan, de a fentieket érzem talán a legfontosabbnak. 

A vezető fejlesztővé válás rögös útja

Épp a minap futottam bele az alábbi blogbejegyzésbe:

https://simpleprogrammer.com/2018/01/22/accidentally-lead-developer/

Nekem nagyon "betalált" ez az írás, mert egy ilyen jellegű "átalakuláson" haladok már én is jó néhány éve, csak én, a cég (kis) mérete miatt még messzebb kerültem a fejlesztőtől, nemcsak vezető fejlesztői irányba, hanem architect és business analyst irányokba is (ezeknek a szerepköröknek sajnos nem ismerek jól értelmezhető magyarítást, bocsi).

Fejlesztői szemmel tekintve a mostani feladataimra, időnként úgy érzem, hogy nem is dolgozom, hiszen a tevékenységeim egy jelentős részének nincs közvetlenül látható jele a készülő rendszerekben. Ez az egyik oka annak, hogy néha nagyon nehéz meghatározni a következő feladatokat és lépéseket. Magamnak kell kitalálni, hogy mit kell ahhoz tennem, hogy a projekt határidőre elkészüljön, az adott időkereteken belül elvárható minőségben, és a projektcsapaton belül mindenki kellő mennyiségű és típusú feladattal bírkózzon (ne túl kevéssel, de ne is túl sokkal; jelentsen kihívást neki, de ne megoldhatatlan szintű ugrással; a feladatok segítségével is legyen lehetősége a szakmai fejlődésre stb.).

Egyébként messze ez a legnehezebb feladat, a megfelelő "erőforráskezelés" (ezúton is elnézést kérve a kollégáktól, hogy őket is beleértem ebbe a gyűjtőszóba). De ezen kívül is számos olyan kérdés van, amelyre a végső választ a projekt vezető fejlesztőjének kell kimondania, még akkor is, ha közben azért kap segítséget a többiektől (nálunk szerencsére kap :) ).

Néhány példa az "egyéb", a fejben zsongó kérdésekre:

• Ha egy már élesben futó projekten van egy nagyobb továbbfejlesztés, lehet-e olyan "technical debt" csökkentést is bevenni a feladatok közé, amely segítségével legalább szinten lehet tartani a problémásabb gócpontokat, vagy - ha szerencsénk van - csökkenteni lehet azokat?
• Eljött-e már az ideje a rendszer által használt technológiák frissítésének? Ha igen, melyiknek, és mennyivel ugorhatunk előbbre? Az sem jó, ha nagyon elmaradunk a frissítésekkel, de az sem feltétlenül az üdvözítő út, ha mindig mindenből a legfrissebb verziókat használja az ember. Főleg akkor, ha nem tarthatja kézben az éles környezetet és nincs lehetősége nagyon gyakori, kvázi "funkciónkénti" élesítésre.
• Ha az új funkciókat (vagy akár egy új rendszert) nézünk, akkor a már meglevő és ismert technológiai eszköztár elegendő és megfelelő rá? Ha nem, akkor mi az, aminek a megismerése a projekttel együtt szükséges (új keretrendszer, új lib, új nyelv, új fejlesztőeszköz, ...)? Mennyi időt és energiát kellene fordítani az ismerkedésre, mielőtt a döntés meg kell hozni, és van-e ennyire lehetőségünk?
• Mennyi időt lehet és érdemes fordítani a csapat mentorálására közösen illetve egyedileg is? Hiszen, ha mondjuk öten dolgoznak egy munkán, és sikerül a hatékonyságukat növelni némi időbefektetéssel, akkor lehet, hogy megéri a dolog. Tőlem ugyan időt vesz el, de összességében a projektben bőségesen megtérül ez a befektetés.
• Kinél mi az a tényező, ami motiválja? Van, akit az motivál, ha látszólag "agyonnyomják" feladatokkal, mert ilyenkor "érzi, hogy él", és fel tud pörögni. Van, aki viszont pont az ellenkező módon reagált egy ilyen "agyonnyomásra", így nála másképp érdemes a feladatkiosztásokat végezni. Van, aki egészen megbízható időbecsléseket tud adni a feladatokra, de van, aki tipikus alábecslő, tudni kell ezt is a helyén kezelni.

Nem egyszerű kérdések, és sajnos nincsenek rájuk egyértelmű válaszok sem. De ez természetes is, hiszen sokszor jóval egyszerűbb programozási kérdések esetén sincs egyértelműen jó vagy rossz válasz, hanem létezik sokféle megoldás, mindegyik saját erősségekkel és gyengeségekkel felvértezve.

Igazából azt, hogy sikerült-e jól elvégezni a házi feladatot, nem is lehet objektíven mérni, hanem a környezet visszajelzései azok, amelyek rámutathatnak a problémákra, vagy amelyek jelezhetik, ha valami jó úton halad:

• Az ügyfél visszajelzések száma és minősége.
• A teljesítés paraméterei (időben megtörtént-e, megfelelő minőségben megtörtént-e).
• A kollégák direkt és indirekt visszajelzései a feladatok, a projekt és a vezető fejlesztő tevékenységeinek tekintetében.
• Ha megy már a rendszer 3-4-6-8-10 éve, és folyamatosan vannak igazítások rajta, de azok még mindig építhetők a korábbi elvi vázra, vagy egyértelműen meghatározható, hol kell az elvi vázon bővíteni/módosítani anélkül, hogy "kettétörnénk" a rendszert.

Így, ha sikerül tartani a határidőt és azon belül egy elfogadható rendszerminőséget, és a kollégák részéről, valamint az ügyfél részéről sincs nagy elégedetlenkedés / visszhang, akkor jöhet a vállonveregetés, és a következő feladatra koncentrálás... :)

Két (vagy max. négy) Windows-os gép hatékony kezelése billentyűzettel és egérrel

Úgy alakult, hogy az otthoni két monitoromból az egyik (amelyben volt tuner is) elkerült a nagyszülőkhöz. Így otthon egy monitor maradt előttem, és ilyenkor jön ki igazán az, hogy a jóhoz milyen könnyű hozzászokni :)

Szóval, maradt egy monitorom. Van viszont egy notebook-om is, ami így már elfért a megmaradt monitor mellett, és elkezdtem keresgélni, hogyan tudnám hatékonyan használni a két gépet.

Mindkét gépen Windows 10 van, és némi keresgélés után találtam is egy érdekes "Microsoft Garage" fejlesztést, Mouse without Borders névvel.

Megnéztem a hozzá kapcsolódó súgót is, és kíváncsivá tett az eszköz:

• Legfeljebb 4 számítógép vezérelhető (ebből egyikük a "master", amihez a használandó billentyűzet, illetve egér hozzá van kötve)
• A különböző gépek között megosztható a vágólap
• A különböző gépek között lehetőség van egy, max. 100MB-os fájl "kopipészt" jellegű átvitelére (több fájl, illetve mappa átvitele nem támogatott, de már így is igen hasznos tud lenni)
• Lehetőség van "ALL COMPUTERS" módra, amikor is minden csatlakoztatott gépen egyszerre mozog az egér és jelez a billentyűzet (szuper lehetőség pl. junior kolléga oktatására, ha azonos a monitorméret, és be van töltve teljes képernyőre a fejlesztőeszköz - látja a saját gépénél, hogy mi történik)
• Van még képernyőkép készítési lehetőség is benne, de ezt nem használom, a Greenshot ott van minden gépemen :)

Egy szó, mint száz, feltettem mindkét gépre, és kipróbáltam. Egy hét után a munkahelyemen is kipróbáltam (két monitoros "fő gép" + 1 notebook összekötése, mert a notebook-on van telepítve olyan szoftver, amit szintén használnom kell egy ideig, de licensz okokból a "fő gépre" nem telepíthető). Így összességében eddig két hét otthoni, és egy hét munkahelyi tapasztalatom van.

Egy szóban: király :) Nagyon kényelmes, és újra van otthon "két monitorom". Igaz, nem annyira jó, mintha azonos géphez lenne kötve, mert azt pl. nem tudom így megcsinálni, hogy "átdobom az alkalmazást" az egyik monitorról a másikra, viszont a leggyakrabban használt megosztásaim probléma nélkül működnek így:

• egyik képernyőn a levelezés, másikon a "fő alkalmazás", amivel épp foglalkozom
• egyik képernyőn könyv / cikk / leírás / dokumentum, amit felhasználok éppen a másik képernyőn levő programban

A párhuzamos univerzumok esete :)

Szakmai ártalomként, szeretek különböző absztrakciókat kitalálni a való világ folyamatainak modellezésére is :)

Néhány évvel ezelőtt olvastam Robert A. Heinlein Azok (They) című novelláját, amely főszereplője meg van arról győződve, hogy ő az egyetlen emberi lény, és mindenki más csak egy mellékszereplő az univerzumában. Érdekes gondolatkísérlet, nekem tetszett a novella. Majd, kicsit kiegészítve azzal a ténnyel, hogy a világból igazából azokat a dolgokat fogjuk fel, amelyeket az érzékszerveink engednek meg, megalkottam a saját univerzum absztrakcióját (*).

(*) Nem gondolom, hogy rajtam kívül másnak nem jutott eszébe, sőt, nagyon is sokaknak eszébe jutott, csak más szavakkal írnak/beszélnek róla. Szóval szerzői jogok és hasonló ötletek tekintetében azt mondhatom kicsit pontosítva, hogy a saját univerzumomban én alkottam meg ezt az absztrakciót :)

A lényege igen egyszerű. Mindannyian a saját univerzumunkban élünk, amelyek egymással párhuzamosan léteznek. Általában ezek a párhuzamos univerzumok eléggé hasonlítanak egymáshoz.
Pl. ha veled egy kávézóban futok össze, akkor valószínűleg mindkettőnk univerzumában azt gondoljuk, hogy egy kávézóban vagyunk és egy asztalnál ülünk. De abban már nem biztos, hogy egyezik az univerzumunk, hogy a felszolgálólány udvarias vagy sem, és abban sem biztos, hogy egyezik a két univerzum, hogy az asztal, amelynél ülünk, milyen színű :)

Az univerzumaink alapjait a világ valósága és az abban végrehajtódó történések alkotják. Ezen felül azonban van két olyan fontos tényező, amely egyedivé teszi mindenkinek a saját univerzumát:

1. Az érzékszerveink "felfogási képessége" (van, akinek jobb a látása, vagy hallása, így az ő univerzumában több a szín, vagy hangosabbak a madarak és a tücskök :) ).
2. A gondolataink, amelyeket az általunk felfogott világhoz és az abban zajló történésekhez kapcsolunk. Ez utóbbi a legnagyobb felelőse az univerzumok testreszabásának.

Nagyon sok önfejlesztéssel foglalkozó könyvben, előadáson, weboldalon találkozhatunk azzal, hogy mindannyian egy saját szemüvegen keresztül látjuk a világot, és ez a szemüveg a múltunkból, a hiedelmeinkből és a gondolatainkból épül.

Mire jó nekem ez a párhuzamos univerzum absztrakció? Egy nagyon fontos dologra: én csak és kizárólagos azért vagyok (és lehetek) felelős, ami az én univerzumomban történik, azért viszont kizárólagosan csak én tartozom felelősséggel!

Más szóval, teszem, amit jónak látok, és ha valaki más, a saját univerzumában ehhez a történéshez olyat kapcsol hozzá, amit én nem szerettem volna, akkor az már az ő egyéni szociális problémája, azt neki kell megoldania.

Nyilván, ha teszek valamit, amiről utána úgy gondolom, hogy nem kellett volna (mert persze bőven van ilyen, gyarló ember vagyok), akkor természetesen lesz folytatása (elnézést kérek, jóváteszem stb.). DE, ha később is úgy gondolom, hogy akkor és ott azt és úgy kellett tennem, akkor nem fogom sajnálni, hiába minősül majd ez a cselekedet más univerzumokban "nem helyénvalónak". Nálam az lesz :)

Magyarul: ha valaki megsértődik rám egy olyan dolog miatt, ami miatt az én univerzumomban nincs ok a sértődésre, akkor nem fogok azon gondolkodni, hogy "jaj istenem, vajon mit gondolhat?". Ha nem mondja ki, hogy baja van, akkor megtartja saját magának. Hát, akkor tartsa is meg... Ha pedig azt gondolja, hogy "de hát nekem ezt tudnom kellene", akkor, hát, bocs, ha nem mondod, nem kellene tudnom. Nekem azt kell tudnom, ami az én univerzumomban van.

Ha a fentiekből még nem derült volna ki, egy arrogáns, magának való köcsög vagyok :) Bár az én univerzumom szabályai szerint az átlagosnál jóval korrektebb, felelősségtudatosabb, empatikusabb ember vagyok, nyilván ez csak az én univerzumomban van biztosan így...

Egy dologra viszont nagyon jó ez az absztrakció. Nap mint nap látom a teljesen felesleges, időrabló "szerepjátékokat", ahol gondolunk valamit, teszünk valami egészen mást, és - mivel mi közben azt gondoltunk, amit - elvárjuk a másiktól, hogy ő is azt gondolja a mi "egészen más" tevékenységünkről. És persze, mivel nem azt fogja, már meg is van a fincsi kis konfliktusforrás...

Hát kedveseim, az én életem annál sokkal rövidebb időtartamra szól, hogy ilyen "játékokra" fecséreljem azt. Így is éppen elég időt b****k el egy csomó olyan dologra, amire nem kellene, ezt az egyet legalább jó eséllyel ki tudom küszöbölni. Időt is spórol, és nyugalmat is teremt.

Ha képernyőkép kell Windows alatt - Greenshot

Sokszor van, hogy képernyőképet kell készítenem Windows alatt egy alkalmazás felületéről, vagy annak egy részéről a napi munkám során, különféle okokból:

• Napi ügyféltámogatásban "vizuális segítség" nyújtása az ügyfeleknek
• Fejlesztett rendszereink kapcsán különféle leírások tartalmához (pl. újdonságok az előző változathoz képest, felhasználói kézikönyv)
• Bemutatók, prezentációk készítéséhez

Ilyenkor a képernyőképet sokszor annotálni is kell (pl. valamit bekeretezni pirossal, vagy jelölni nyíllal és szöveggel/számokkal egy "workflow sorrendet"), valamint - értelemszerűen ugyebár :) - a készített képernyőképen esetlegesen látható személyes adatokat "anonimizálni" kell.

Ezekre a feladatokra immár jó egy éve a Greenshot nevű alkalmazást használom, amiben a képernyőkép készítés mellett van egy kis képszerkesztő is. Na, ez nekem annyira, de annyira kézre áll, hogy kaptak is a fejlesztők egy 25$-ot támogatást a fejlesztéshez, megérdemlik :)

Nem túlzás azt mondani, hogy az általam elvárt funkciók mindegyikét nagyon felhasználóbarát módon támogatja:

• Lehet rajzolni különféle színű és vastagságú téglalapokat (keretezéshez), vonalakat, nyilakat; ráadásul ezek a szerkesztőben külön objektumként viselkednek, ha tehát elsőre nem sikerült jól pozícionálnom, akkor nincs gond, arrébb teszem, átméretezem, vagy átszínezem :)
• Lehet könnyen beírni szöveget simán is, vagy "speech bubble-ben"
• Ha valami sorrendet kell mutatni, akkor van egy sorszámozója, ami 1-től indul, és minden kattintásra eggyel nagyobb számot tesz le
• Van beépített kiemelője, amivel több mindent is meg lehet csinálni (vagy háttérszínnel emeli ki a szöveget, vagy a többi tartalmat "fakítva" emeli ki a kijelölést, vagy akár megnagyítja a kijelölt tartalmat
• Van beépített "kikockázója", ami nagyon jól jön az egyes tartalmak gyors anonimizálásához
• Az egész képre lehet tenni néhány "keretező effektet" is, ha úgy érezzük, szükségünk van rá
• Természetesen forgatást, átméretezést és kivágást (crop) is támogat

Alább egy jó kis képernyőkép, amit kb. 2 perc alatt készítettem el az eszközzel (de csak azért, mert bő egy percet gondolkodtam azon, hogy milyen funkciókat is "demózzak" a képen :) ).

Vim "alapszintű túlélőkészlet"

Nemrég olvastam egy StackOverflow-s blog bejegyzést arról, hogy a "hogyan tudunk kilépni a Vim szerkesztőből" kérdést már több, mint 1 millióan nézték meg. Illetve, olyanok is vannak, akik nem találtak még rá erre a kérdésre :)

No, de viccet félretéve, vannak időszakok, amikor egészen sok időt töltök én is a Vim szerkesztőben. Mondjuk, én szeretem :) Egyszer rászántam az alapok megismerésére és begyakorlására, meg egy "alapszintű bekonfigurálásra" néhány héten keresztül napi kb. fél-egy órát. Amit akkor "felszedtem", azzal egészen hatékonynak tűnök a kollégák számára, pedig igazából nem túl sok, ha a Vim összes lehetőségét nézem (egy élet is kevés alaposan megismerni...).

Windows alatt is van telepítve és bekonfigurálva egy GVim, egy viszonylag szolid színsémával és jó néhány kiegészítő plugin-nel (igen, a sötét hátteret szeretem kódszerkesztésnél, változatos felüdülés a szememnek a számos dokumentumkészítés és -olvasás között/után :) ).

Ugyanakkor azt is meg kell mondanom őszintén, hogy viszonylag ritkán veszem elő, sokkal gyakrabban indítom el a Sublime Text 3-at. De jó dolognak tartom, hogy sikerült megismerkedni az alapokkal.

Legtöbbször akkor használom, amikor valamilyen Linux szerveren kell úgy beállításokat eszközölnöm, hogy időveszteség lenne onnan letölteni a fájlokat, helyben módosítani és visszatölteni. Ehhez nem is kell túl sok parancs ismerete, én az alábbiakkal a leggyakoribb feladatokat gyorsan és hatékonyan (és nem utolsó sorban magabiztosan!) el tudom végezni:

<Esc>:q! - Kilépés mentés nélkül
<Esc>:w - Fájl mentése (ha ki is lépnénk utána, akkor <Esc>:wq)
<Esc>:set bg=dark - ha sötét hátterű a shell, amivel dolgozunk, és nem látjuk jól a Vim-ben a karaktereket
<Esc>:%s/mitkeresünk/mirecseréljük/igc - "klasszikus" keresés/csere művelet, az igc toldalékok miatt minden cserére rákérdez a Vim, kis-nagybetű érzéketlenül keres és egy soron belül mindegyik előfordulást megtalálja, ha több is van

A fenti parancsokban az <Esc> az Escape billentyű megnyomását jelenti. Ha valamilyen szerkesztő üzemmódban voltunk, akkor abból ezzel kilépünk a szerkesztő üzemmódból az ún. normál módba. Onnan a : (kettőspont) segítségével kaphatjuk meg a vim "parancssorát", ahova gépelhetjük, amit gépelünk.

Ha normál módban vagyunk, az i megnyomásával átmehetünk szerkesztő üzemmódba. Sok más parancs segítségével is átmehetünk, de, mivel minden modernebb környezetben szépen támogatja a Vim a kurzorbillentyűk használatát még a szerkesztési navigációban is, kezdetben elég ezt az egy átmenetet ismerni. Következőnek - már félig "haladóként" - erősen javaslom a c (change) parancs és a Vim szövegobjektumainak (text objects) a megismerését, ez az a pont, amit, ha valaki jól megismer, akkor - általában - megszereti a szerkesztőt.

Normál módban "ugrálni" a következő parancsokkal szoktam, ez nekem többnyire elég (vagy a fájl végét szerkesztem, vagy egy bizonyos környezetet, amire rá szoktam keresni):

/mitkeresek - keresés a fájlban előrefelé (a kurzorpozíciótól)
?mitkeresek - keresés a fájlban visszafelé (a kurzorpozíciótól)
n - keresés után a következő találatra ugrás
G - fájl végére ugrás
gg - fájl elejére ugrás
<sorszám>gg - a megadott számú sorra ugrás

Nagyjából ennyi az, amit gyakran használok a Vim lehetőségei közül. Nem sok, de az alap dolgokat kiválóan el lehet vele látni. Ha pedig tovább szeretnénk lépni, kiváló online anyagok állnak rendelkezésre, többek között:

• Vimcasts.org: cikkek és rövid bemutató videók egyes Vim lehetőségekről
• A Byte of Vim: online elérhető és olvasható könyv

Rövid elmélkedés a Pomodoro technika kapcsán

Elég sokat kutakodom a nagyvilágban hatékonyságnövelő ötletek, gondolatok után. Igazából túl sokat is... sajnos hajlamos vagyok beleesni időnként abba a csapdába, hogy ahelyett, hogy alkalmaznám, amit már megértettem, még újabb és újabb ötleteket hajkurászom. De azért már javulok :)

Az egyik érdekes kirándulásom a Pomodoro-technika irányában volt. Sok blog bejegyzést, cikket, videót, és alkalmazást megnéztem, de nem sikerült megértenem, hogy miért is működne nekem ez a technika. Mégis, már mekkora "hülyeség" az, hogy majd 25 percig dolgozom, és utána szünetet tartok? És, ha egy feladat 40 percig tart, akkor hagyjam félbe? Ha meg 20 percig, akkor utána kezdjek bele valami másba még 5 percre? Tisztára nem értettem.

Az a része világos volt, hogy segít a nap tervezésében, illetve segíthet koncentráltnak maradni. De nagyon szigorúnak éreztem, és úgy láttam, hogy a saját világomban nem fogom tudni egyáltalán alkalmazni.

Aztán szembetalálkoztam más írásokkal is (pl. a 15 perces szabállyal), ami további ötleteket adott, hogyan tudnám használni mégis valahogyan.

Végül arra jutottam, hogy nem fogom arra használni, hogy "pomodoronként dolgozzam le" a napi feladataimat, hanem elsősorban heti "időbecslésre" és a napi feladatmennyiség behatárolására fogom használni. A munkám során számos, egymástól független tevékenység van, amelyekkel  rendszeresen (ha nem is minden nap, de heti szinten biztosan) kell foglalkoznom:

• Általam vezetett/koordinált projektek esetén:
• belül "architekti", "projekt menedzseri", konzulensi, tesztelői és reviewer feladatok,
• ügyfél felé "business analyst" és támogatási feladatok
• Egyéb, már működő rendszerek esetén ügyféltámogatási feladatok
• Cégen belüli folyamatok / eszközök folyamatos ellenőrzése, felülvizsgálata, változáskövetése, újdonságok kipróbálása / bevezetése
• Kollégák mentorálása, nem csak projekt, hanem általános szakmai értelemben is

Alapfeltevések:

• 1 órába 2 pomodoro-nyi feladat fér fele :)
• egy átlagos, "kellemesen laza" munkanap kb. 12 pomodoro (nagyjából 6 órányi "effektív munka"); egy koncentrálós, keményebb munkanapba kb. 15 pomodoro fér bele, egy extrém munkanapba pedig kb. 18 (ez utóbbi már kb. 11 órányi munkahelyen töltött időt jelent, tehát tényleg extra, ezt hosszú ideig nincs értelme csinálni)
• a fentiek alapján egy átlagos hétbe kb. 70 pomodoro fér bele, ezen lehet némileg feljebb tornászni, kb. 80-ig, de csak időszakosan

Heti tervezés:

• A GTD is használja, és tényleg, szerintem ez az egyik legfontosabb dolog annak, aki kicsit is szeretné jobban tervezni és megvalósítani a dolgait. Heti szinten viszonylag gyorsan át lehet tekinteni az előző hetet, levonni a tanulságokat, és legalább nagy vonalakban megtervezni a következő hetet (hogy akkor, milyen területeken kell előrehaladni).
• Fontos, hogy a hetet tervezem, nem a napokat! Vagyis azt táblázom be, hogy az adott héten kb. hány pomodoro-t foglalkozom a soron következő feladatokkal. Azt, hogy egy konkrét napon ténylegesen mivel töltöm az időt, a nap elején határozom meg (amit persze még mindig felboríthat valami "vis major" dolog, de általában több, mint 80%-ban tudom magam tartani a tervhez).
• Ez a megközelítés nekem sokat segített abban is, amikor olyan időszak van (és többnyire ilyen van :) ), hogy párhuzamosan több "nagyon fontos" projekt vagy "eseményszál" is megy. Ha nincs heti terv, akkor folyamatosan bennem van, hogy "a többivel is foglalkozni kellene", míg, ha van, és van azokra is idő tervezve, akkor sokkal nyugodtabban tudok az éppen aktuálisra figyelni.

Feladatok:

• Ha elkezdek egy feladatot, akkor amennyire csak tőlem telik, nem hagyom, hogy bármi vagy bárki megzavarja (nekem nagyon bejött az, hogy legalább 15 percig kötelező csinálnod, utána szabadon eldöntheted, hogy folytatod, vagy áttérsz másra). Ugyanakkor, mivel többségében koncentrációt igénylő feladatokat végzek, ezért van egy max. 45-50 perces határ (ami végül is 2 pomodoro :) ), ami után biztosan tartok szünetet.

Ezt a megoldást alkalmazom kb. fél éve, egyelőre váltakozó sikerrel, de hatékonyabb vagyok, mint korábban, amikor csak napi szinten terveztem meg valamennyire, hogy mit fogok csinálni.

A leggyengébb láncszem a folyamatban a heti tervezés, és a feladatokhoz való "pomodoro becslés" (tehát hogy azon a héten kb. hány pomodoro folyhat el az adott feladatra). Ha ez elmarad, vagy csak félszívvel csinálom meg, akkor azt nagyon megérzem a következő héten.

IT tanulás "ingyen"

Az informatikai, főleg a szoftvertervezés és szoftverfejlesztés világában számos olyan lehetőség nyílik meg, ami talán egyáltalán nincs is meg más szakmában. Ez pedig annak a lehetősége, hogy "ingyen" jussunk jó minőségű eszközökhöz és tudáshoz is.

Az ingyen azt jelenti, hogy pénzt nem fizetünk érte (az internetkapcsolat díján és a számítógépünkön túl), viszont rengeteg időt kell "beletenni". Ez az a pont, ahol a legtöbben elvéreznek. Viszonylag kevés olyan embert ismerek, aki hajlandó átlagosan napi 1 óra plusz tanulást folytatni a munkaidején túl. Ugyanakkor, napi egy óra, és esetleg hétvégén még pár óra plusz az már heti 8-10 óra, havi 32-40 óra. Vagyis havi szinten mondhatjuk, hogy "plusz egy heti" tudást / tapasztalatot felszedhetünk, vagyis egy év alatt majdnem három havi, öt év alatt pedig másfél évnyi tudással lehetünk előrébb. Ez az egyik olyan faktor, ami a munkavállalói világban meg tudja különböztetni a jó szakembert és a kevésbé jó szakembert. Van persze még sok más is, de ebben a posztban csak az "ingyenes tanulás" a téma.

Főleg az iskolaévek alatt, illetve az első 10 munkaévünk alatt számít rengeteget a plusz tanulás, itt nagyon "el tudunk húzni". Ebben az időszakban ráadásul még gyorsabban megy a tanulás, és elvileg jobban is tudunk rá időt szánni (talán kevésbé vannak családi kötelezettségeink, de ez nyilván egyéni élethelyzet kérdése).

Hihetetlen mennyiségű információ vesz minket körbe az internet jóvoltából, és ezek között sok jót is találni. Vannak szakmai podcast-ok, YouTube csatornák, blog-ok, oktatóoldalak, szabadon elérhető egyetemi előadások és jegyzetek, szóval tényleg rengeteg információ közül választhatunk.

Az én személyes kedvenceim (mivel elsősorban JVM platformon dolgozom, Windows-os környezetben, így az eszközök és a többi link is ennek megfelelők - de más területre is ugyanígy megvannak az eszközök, a keresők segítenek megtalálni azokat):

Ingyenesen elérhető, nagyon jó minőségű eszközök szoftverfejlesztést tanulóknak, gyakorlóknak, hobbistáknak (van, ami "csak" magánszemélyeknek, tanulóknak, illetve néhány fős csapatoknak "ingyenes", ezért mindig meg kell nézni a kapcsolódó licensz információkat):

• Fejlesztőkörnyezet (IDE): IntelliJ IDEA Community Edition, Eclipse, Netbeans, Visual Studio Community Edition
• Szerkesztő (editor): Visual Studio Code, VIM (nem szabad leírni, tényleg szuper, ha rászánjuk az időt :) ), Notepad++, Notepad2
• Felhős kódtárkezelés: BitBucket (nagyon jó, hogy privát repository-kat is lehet benne kezelni, és meg lehet vele ismerni mind a Git, mind a Mercurial alapjait)
• Kódtár vizualizáció, code review: UpSource
• Feladatkezelés: YouTrack
• Dokumentációkészítés (specifikáció, leírás stb.): Pandoc (némi plusz tooling-gal kiegészítve nagyon jól lehet vele dolgozni, én nagyon szeretem az egyszerűsége miatt a markdown és textile formátumokat), LibreOffice
• Projektek "build-elése", "kód egészségmérése": Gradle, Jenkins, SonarQube

A felsorolásból kimaradtak a kódtárkezelés kivételével a "felhős dolgok" (pl. IDE a felhőben), ennek az oka, hogy én, személy szerint azokkal még nem igazán foglalkoztam, nincs bennük tapasztalatom. Amiket itt felsoroltam, azok mindegyikével dolgoztam vagy dolgozom, és "nagyon rendben" láttam a stabilitásukat / funkcionalitásukat, az árukhoz képest meg főleg :)

Az oktatóanyagokból, blog-okból még nagyobb a választék, és nagyon függ attól a választás, hogy milyen IT szakterület irányába szeretne valaki orientálódni. Az én Top 5 ingyenes kedvencem a tanuláshoz:

• Simple Programmer: lehet rajta kifejezetten programozási bejegyzéseket is találni, de a blog nagyon nagy hangsúlyt fektet az ún. "soft skillek" (kommunikáció, tanulás, "fitten maradás" stb.) népszerűsítésére. Abszolút egyet tudok érteni vele, hiszen, ha valaki megfelelően tud kommunikálni, gyorsan tud olvasni és értelmezni, akkor szinte bármit meg tud tanulni élete során, később sem okoz akkora problémát, ha pl. technológiai stack-et kell váltani.
• Packt Publishing: ha regisztrálsz (ingyenes), akkor van minden nap egy olyan e-book, amelyet ingyenesen megszerezhetsz a Free Learning program keretében. Én (bár nekem van Mapt előfizetésem is, de ez most itt nem lényeges), a Free Learning program keretében évente kb. 15-20 számomra érdekes e-bookot tudtam beszerezni (elsősorban PostgreSQL, Java, Python, webbiztonság, web fejlesztés, DevOps témakörökben).
• Udemy: rengeteg oktatóvideó található meg, közülük több ingyenesen is elérhető. Kicsit "kavarni" kell az oldalon, mire eljut az ember az ingyenes kurzusokig, de utána már lehet válogatni (pl. ezen a linken keresztül a szoftverfejlesztéshez tartozó ingyenes kurzusok érhetők el; van itt Ruby on Rails, Android, Python, webfejlesztés, web design, Java, Github, Swift, C#, Eclipse, hogy csak néhányat említsek, közel 500 kurzusból lehet választani). Nyilván, a fizetős kurzusok alaposabbak és naprakészebbek is, de az ingyenes anyagok is nagyon értékesek, ha valaki valóban tanulni és fejlődni szeretne.
• Free books via GitHub: egy korábbi nagyon jó StackOverflow gyűjtemény továbbvitele és karbantartása. És egyúttal nagyon jó példa arra, hogy miért fontos egy szoftverfejlesztőnek angolul megtanulnia (ha megnézed a magyar és az angol listát, hát, van különbség :) ).
• Zen Habits: egy kicsit "fura" ebben a válogatásban, de nagyon szeretem az itt megjelenő írásokat. Az itt leírt dolgok közül néhány megértése és megélése segíthet abban, hogy érzelmileg jó, kevésbé frusztrált életet éljünk meg, és ez is rengeteget tud segíteni a szakmai fejlődésben is (több időnk, és sokkal több energiánk marad, mint ha hagyjuk, hogy a külvilág történései miatt a napjainkat folyamatosan idegeskedéssel és rohanással töltenénk).

A fentiek mind csak csepp a tengerben. Így, ha valaki informatikai területen szeretne tanulni, egy dologban biztos nem lehet kifogása, ha van számítógépe és internetelérése: abban, hogy nincs miből tanulni :)

Bemutatkozás

Szoftverfejlesztőként (pontosabban programtervező matematikusként) végeztem még a 20. században Szegeden, az - akkor még - József Attila Tudományegyetemen.

Aztán elmentem 9 hónapra katonának Kalocsára, az ottani kiképzőközpontba. Sok szempontból életem egyik legjobb döntése volt, hogy nem próbáltam mindenféle mondvacsinált okokra hivatkozva elbliccelni a dolgot. Sok hasznos tapasztalatot szereztem az élettel kapcsolatosan, kilépve az otthoni biztonságból. Persze mondhatjuk, hogy ezeket minden józan paraszti ésszel rendelkező ember tudja, de én már azt is tudom, hogy más "tudni" és más "megtapasztalni" :)

Mik is voltak ezek a tapasztalatok?

•  Az alapvető emberi értékek (szeretet, barátság, őszinteség, döntésképesség, felelősségvállalás, és hasonlók) teljesen függetlenek az iskolázottságtól. Kiválóan tudtam kommunikálni és jól éreztem magam "csak" 8 általános végzett emberrel, és iszonyatos nehézségeim is akadtak több diplomával rendelkezőkkel, vagy akár a laktanyaparancsnokkal :), csak hogy a két végletet említsem.
• Négy nagyon fontos dolgot tapasztaltam meg, ami a jó vezető ismérve: a példamutatás, a hitelesség, az empátia, valamint annak a felismerése és helyén kezelése, hogy nem feltétlenül mi tudunk mindent a legjobban. Szerencsém volt, mert kiváló szakaszparancsnokot sikerült kifognom, rengeteget tanultam tőle, amit később, a munkahelyemen kamatoztatni is tudtam (tudok). És sajnos láttam az ellenkezőjét is...
• A kapott feladatot el kell végezni. Mindig van egy rendelkezésre álló idő, és az sosem elegendő a tökéletes végrehajtáshoz. Viszont általában ki lehet hozni egy, a lehetőségekhez képest jó eredményt.
• Az élet nem habostorta :), de - megfelelő hozzáállással - az esetek túlnyomó többségében teljesen élhetővé lehet tenni. Szerintem.

A katonaság előtt is szerencsés voltam több szempontból. Egyrészt szüleim miatt, akik mindig is önállóságra neveltek, és arra, hogy magam tanuljam meg, melyek azok a tevékenységek, amelyekre érdemes időt szánnom. Ezáltal már a középiskola végére kialakult bennem egyfajta tudatosság és felelősségvállalás. Ezt szerencsésen erősítette a gyerekkori és fiatalkori sportolás (kajakozás, később többféle harcművészet és néptánc), valamint a 16 évesen megismert agykontroll (amiből sok dolgot azóta sem használok..., de a legfontosabbat, a gondolat-nagytakarítást rendszeresen).

Nagyon szerencsés voltam, mert a katonságtól leszerelve azonnal egy olyan munkahelyet találtam, ahol mind emberileg, mind szakmailag megfelelő a légkör, a csapat, a feladatok és a munkám minden téren elismerik (a bemutatkozás írásakor lassan már 18 éve, így hamarosan "nagykorúvá válok" munkaügyileg).

A belépés óta eltelt idő alatt is rengeteget fejlődtem mind emberileg, mind szakmailag, hála a főnökeimnek, a kollégáimnak, és a feladatoknak, valamint emberi oldalról volt feleségemnek, jelenlegi páromnak és fiunknak köszönhetően.

Aktuálisan "több dimenzióban" mozgok, a munkaidőm többségében, a ma divatos szakmai fogalmak és szerepkörök alapján elsősorban business analyst, architect és lead developer feladatokat látok el, de nem ijedek meg akkor sem, ha ügyféltámogatási vagy tesztelési feladat merül fel.

Mai napig elemző, teljességre törekvő gondolkodásmóddal állok neki egy-egy problémának, vagy új eszköz megismerésének. Itt, a blogon is - elsősorban a saját tapasztalataim "online mentéseként" - kivesézek problémákat, eszközöket, körbejárok dolgokat. Meg az az igazság, hogy imádok dumálni, hát most online is tudok... :)

Ha egyetlen dolgot javasolhatok "életvezetési útmutatóként" a blogra tévedt :) kedves olvasó számára, az a cserkészek egyik aranyszabálya: "mindig hagyd tisztábban a táborhelyet, mint ahogyan találtad". A lényege a folyamatos fejlődés, így számos módon lehet "szövegesen testreszabni" ezt a szabályt:

• Minden nap úgy feküdj le, hogy megtanultál valami olyat, amit reggel még nem tudtál. Ez lehet emberi dolog, szakmai dolog, idegen nyelvben új szavak, bármi, a lényeg, hogy tanulj valami újat minden nap.
• Minden nap kevesebbet kritizálj másokat, mint az előző napon.
• Minden nap egy kicsit jobban figyelj oda a családodra, mint az előző napon.
• Minden nap egy kicsit egészségesebben étkezz, mint az előző napon.
• Minden commit-nál legyen érthetőbb a kódrész és környezete, mint a commit előtt volt :)
• ...

Ahogy Lao-ce is mondta: "Terebélyes fa hajszál-gyökérből fejlődik, kilenc-emeletes torony kupac földből emelődik, ezer-mérföldes utazás egyetlen lépéssel kezdődik."

Semmi sem megy egyik napról a másikra, de menj előre minden nap egy métert, és néhány év múlva már sokkal messzebb leszel, mint azt az első napon gondoltad volna. Csak ne a szakadék felé indulj...

Online szakmai "névjegy"

Notepad2 - a hasznos "kicsike"

Szoftverfejlesztőként sok esetben dolgozom szövegfájlokkal. Megvannak a kedvenc, komplexebb szerkesztőim és fejlesztőkörnyezeteim, ugyanakkor van egy nagyon aranyos kis programocska, amit ajánlok mindenki figyelmébe, akinek sokszor "csak egy kicsit jobb" jegyzettömbre lenne szüksége.

A Notepad2-ről van szó, annak is arról a változatáról, amely a https://xhmikosr.github.io/notepad2-mod/ oldalról tölthető le. A telepítője felajánjla azt a lehetőséget, hogy lecseréli a Windows jegyzettömböt, így a telepítést követően minden alkalmazás, ami a Jegyzettömböt (Notepad) indítja el, az a Notepad2-t fogja elindítani.

Aki magyarul szeretné használni, az innen töltse le a telepítőt: http://people.inf.elte.hu/kpeter/notepad2-mod/

Kicsike, gyors, és mégis számos olyan dolgot tud, ami igen hasznos a mindennapokban. A számomra legfontosabbak ezek közül:

• Szintaxis színezés

• Reguláris kifejezés alapú keresés és csere

• Számomra fontos karakterkódolások és sorvégek kezelése

• A 64 bites változattal néhány 10MB-os szövegfájlok teljesen jól kezelhetők, sőt néhány száz MB-osak is; nemrég egy 3,8 millió soros, 1,5GB-ot meghaladó méretű SQL szkripttel "bohóckodtam", ahol már egy-egy keresésre, vagy cserére várni kellett jó egy percet, viszont végül azzal is elboldogult.

• Beállítható a kijelölés kiemelése a többi szövegrészben (választható, hogy csak egész szóra működjön)

• Több, rövid kódíráshoz használható szerkesztési segítség van benne (pl. sor duplikálása, fel/le mozgatása, blokk indentálás, zárójelek párjának kiemelése, ugrás nyitó-csukó zárójelek között stb.)

Mivel kicsi, gyors, és ügyesen be tud illeszkedni a Windows-ba, csak javasolni tudom a telepítését :)