2019. szeptember 10., kedd

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...

2019. március 3., vasárnap

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