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" :)