Bevezetés

Figyelem! A poszt nem AI-jal készült!

Talán minden ott kezdődött, mikor az első Linux kernelt fordítottam egy 486-os PC-n. A számítógéphez egy betárcsázós modem volt kötve, és a sötét szobában néztem, ahogy a konzolon szaladnak végig a számomra érthetetlen sorok. Persze elhasalt. Majd újra elhasalt. De maradandó élmény volt, mikor hiba nélkül végigfutott, és használatba vehettem az első saját kernelemet. (Azt ígérték, gyorsabb lesz, hittem is, hogy gyorsabb, de valójában nem volt az.)

Az egyetemen a gépteremben VAX/VMS-t használtunk, távoli terminállal, konzolos böngészővel és levelező programmal. Fordítottam rajta Java forráskódot is. Percekig. Az asztali gépbe be volt dugva a külső winchester keret, benne a saját disk, mi csak úgy hívtuk, rack. FTP-vel másoltam rá az MP3-akat az Internetről.

Második munkahelyemen mondták: “Ha megírtad a programod, telepítsd is fel. Itt egy SSH elérés.” Linux, JDK 1.4, Tomcat, 2008-at írunk. Ekkor még nem létezett a szó, DevOps.

Később, mikor már komolyabb rendszerek fejlesztésében vettem részt, többször megfordultam nagyobb szervertermekben. Egyszer bementünk a BIX-be, a Victor Hugo utcában. Mindig elvarázsoltak az embernyi rack szekrények, rajta a villogó ledek, a deréknyi kötegek UTP kábelekből, és az RJ45 csatlakozó jellegzetes kattanása.

Érdekes, gépet építeni sosem szerettem. Nem szerettem a SATA kábeleket, a PCI csatlakozókat, az elgörbült CPU lábakat, a pasztázást, a jumpereket.

Hálózatok 1 tantárgy teljesítéshez kötelező olvasmány volt a Tanenbaum-féle Számítógép-hálózatok könyv. Nem varázsolt el. Most már igen, meg kellett rá érni.

Mikor megjelent a Raspberry Pi, azonnal rendeltem. Sokáig a fiókban volt, de ma már folyamatosan megy.

Ma a YouTube-on előszeretettel nézem azokat a timelaps videókat, ahol egy kábeldzsungelből egy rendezett szervertermet varázsolnak. Ahol lelkes kollégák saját labor környezeteket (home hab) alakítanak ki, vagy egymás megoldásaira reagálnak. (Párat meg is fogok osztani.)

Eljött az idő, hogy én is kialakítsam az otthoni hálózatomat, és labor környezetemet.

Bevezetés

Cloudban egy viszonylag kevés erőforrással rendelkező virtuális gépen futtatok egy Spring Boot alkalmazást. (Ez amúgy a Learn web services oldalamhoz készült példa alkalmazás, mely CXF keretrendszerrel SOAP-os webszolgáltatást biztosít.) Sajnos többször elfogyott a memória, így választhattam, hogy vagy natív binárist készítek belőle, és bízom benne, hogy kevesebb memóriát foglal, vagy váltok egy erősebb gépre.

Gondoltam itt az alkalom, hogy élesben kipróbáljam, hogy mit nyújt a GraalVM, beváltja-e a hozzá fűzött reményeket. Külön érdekelt, hogy lesz-e gond a CXF keretrendszerrel, melynek nincs GraalVM támogatása. Már most elárulom, a natív bináris hetek óta fut gond nélkül.

A NETAcademia (, mely mögött a Training360 áll) NETA.live néven egy új, ingyenes előadássorozattal jelentkezik.

Az első online webináron 2025. október 29-én 18:00-kor a Spring AI-ról fogok előadást tartani. Nem a hype-ot akarom tovább duzzasztani, hanem élő kódolás közben bemutatni a Spring AI lehetőségeit, azaz hogyan lehet LLM-hez kapcsolódni, RAG technikát alkalmazni, vagy egy MCP szervert fejleszteni, amit aztán agentek tudnak felhasználni.

Az esemény alapvetően olyan Java fejlesztőknek szól, akik szeretnének megismerkedni a Spring AI képességeivel.

Regisztrálj az esemény oldalán, és kapcsolódj be te is a YouTube élő közvetítésbe, ahol kérdéseket is feltehetsz! Ha nem érsz rá, de regisztrálsz, akkor később is visszanézheted a felvételt.

Bevezetés

A Behavior-Driven Development (röviden BDD) már egy 2000-es évek elejétől létező módszer. Még a mai napig is sokan használják, sőt vezetik be létező vagy új projekteken.

Sajnos azonban azt vettem észre, hogy sokan félreértik és hibásan használják. Az Interneten is rengeteg rossz példa terjed, sőt a különböző nagy nyelvi modellek is hibás megoldásokat hoznak (nyilván az előbbi példák alapján), ezekből is fogok többet is mutatni. Ezzel azonban nem segíti, hanem inkább hátráltatja a projekt előrehaladását.

Ebben a posztomban megpróbálom összegyűjteni, hogy hol lehet elrontani a BDD használatát, valamint milyen rossz gyakorlatokat látok a mai napig. Saját tapasztalatokat és erősen szubjektív elemeket is tartalmaz. Ez a korábbi Fejlesztőként mivel akadályozom a tesztelők munkáját? írásom folytatásaként is felfogható.

Röviden a BDD-ről

Nem célom a BDD részletes kifejtése, csak amennyi feltétlenül szükséges a megértéshez. Hivatalos definíció hiányában a kialakulásának céljait érdemes megérteni. Ez olyan módszer, megközelítés, melynek célja hogy a szoftver elvárt viselkedését példákon keresztül mindenki számára érthető, természetes nyelvi formában fogalmazza meg. Gyakran emlegetik a Three Amigos (magyarul: Három Barát) kulcsszereplőket is, ami arra utal, hogy az üzleti szereplők, fejlesztők és tesztelők közösen dolgoznak annak érdekében, hogy mindenki ugyanazt értse “kész alatt”. (Utalva itt az elfogadási kritériumokra - angolul: acceptance criteria.) Általánosan elterjedt még a Given-When-Then használata, mely szavak segítségével struktúrálni tudjuk az üzleti követelmények leírását. Elterjed eszköz a polyglott, azaz több programozási nyelven is használható Cucumber eszköz, valamint a nagyon egyszerű Gherkin nyelv.

Cucumber esetén a követelményeket ún. feature fájlban lehet leírni, mely forgatókönyveket, példákat (scenario) tartalmaz. Ezek lépésekből (step) állnak, az előbb említett Given-When-Then struktúrában. A természetes nyelven megfogalmazott lépést implementálni kell valamilyen programozási nyelven, ez az ún. step definition.

Bevezetés

A JPA, új nevén Jakarta Persistence egy szabvány, mely relációs adatbázisok elérését teszi lehetővő, object-relational mapping (ORM) használatával. Ennek különböző implementációi vannak, talán a legelterjedtebb a Hibernate. A Jakarta Persistence-re épül a Spring Data JPA, ami a repository mintát valósítja meg, valamint újabb lehetőségeket is az a JPA-hoz.

A JPA azonban nem fejlődik olyan dinamikusan, valamint több megszorítás, illetve kényelmetlenség is van benne.

Kényelmetlen a Criteria API használata, valamint korlátozott a DTO-k kezelése. Valamint nem támogat olyan hatékony SQL megoldásokat, mint a Window Functions vagy a Common Table Expression (CTE).

Ezeken egyrészt próbál segíteni a konkrét implementáció, mint pl. a Hibernate. (Ekkor persze elszakadunk a szabványtól.) Valamint a Spring Data JPA-val is több problémát próbál orvosolni. Vagy választhatjuk a mindkét előbbi technológiához jól illeszkedő Blaze-Persistence-t is kiegészítésül, mely további lehetőségeket rejt.

A példa alkalmazás forráskódja megtalálható a GitHubon.