JTechLog - Viczián István magyar nyelvű Java blogja

Magyarországi Web Konferencia 2026

2026-04-06T09:00:00+00:00

Újra megrendezik a Magyarországi Web Konferenciát 2026. április 18-án, az Óbudai Egyetemen.

Egyetlen nap alatt több mint húsz előadás közül lehet válogatni fejlesztés, web, DevOps, UX, AI, valamint low-code/no-code témákban. A program már elérhető, a részvétel pedig ingyenes, de regisztrációhoz kötött.

Java témában is több előadás lesz: szó esik majd a servletekről, a párhuzamos programozásról (virtual threadek), a funkcionális megközelítésről, a Springről és a Play Frameworkről, valamint az AI-ról is.

Én is tartok előadást “Merre tart a Java és a Spring 2026-ban?” címmel.

Ha érdekel a téma, gyere el — és ha ott leszel, szívesen beszélgetek veled személyesen is!

Álljon itt az előadásom rövid összefoglalója:

A Java továbbra is az egyik leggyorsabban fejlődő platform: félévente érkeznek az új verziók, legutóbb 2026 márciusában a Java 26. Az elmúlt kiadások alapján jól kirajzolódik, merre tart az ökoszisztéma. Az előadásban áttekintem a legfontosabb irányokat: performancia, párhuzamosság (virtual threads, structured concurrency), Data Oriented Programming, egyszerűbb tanulhatóság, integrálhatóság (Project Detroit), és természetesen az elmaradhatatlan AI. A Spring is megállíthatatlanul zakatol, a Boot már lassan a 4.1, a Framework a 7-es verziónál, és… az AI. Az előadás célja, hogy segítsen eligazodni a trendek között, és megmutassa, mely technológiákra érdemes már most felkészülni.

ThreadLocal, Project Reactor Context és a Java 25 ScopedValue

2026-03-15T09:00:00+00:00

Előfordul, hogy az egyik metódusból értéket kell átadnunk egy másik metódusnak anélkül, hogy azt paraméterként adnánk át. Lehet ez amiatt, mert a két metódus között nincs közvetlen hívás, és nincs ráhatásunk a közbülső metódusokra.

Ilyen lehet pl. a bejelentkezett felhasználó, a tranzakció, vagy a log MDC. Ezeket gyakran környezetnek (contextnek) nevezik, pl. Security Context, Transaction Context, Mapped Diagnostic Context.

Másképp kell ezt megoldani Servlet API-ra épülő megoldásnál (ThreadLocal), pl. Spring MVC-nél, és máshogy reaktív módon, pl. a Project Reactorra épülő Spring WebFlux esetén (context). Sőt, a 25-ös Javaban megjelent a ScopedValue osztály a ThreadLocal osztály kiváltására.

A poszthoz tartozó példaprogram elérhető a GitHubon.

A poszt még két videót tartalmaz.

Otthoni hálózat és labor (home lab)

2026-01-24T09:00:00+00:00

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.

Java, Spring Boot natív fordítás

2026-01-03T09:00:00+00:00

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.

Spring AI webinar a NETAcademián

2025-10-22T08:00:00+00:00

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.

Hogyan használják rosszul a BDD-t?

2025-05-28T08:00:00+00:00

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

Spring Data JPA és a Blaze-Persistence

2025-01-05T09:00:00+00:00

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.

Események a Spring Modulith-ban

2024-07-24T08:00:00+00:00

Következő videóm témája, hogy egy modularizált alkalmazás felépítésekor az eseménykezelés segít nekünk abban, hogy a modulok lazán kapcsolódjanak egymáshoz. A Spring Modulith ezt kiegészíti, biztosabbá teszi a hiba- és tranzakciókezelést, valamint képes ezeket az eseményeket más service-ek felé is elküldeni valamilyen message brokeren keresztül.

Lesz szó modularizált alkalmazásról, eseménykezelésről, Spring Modulithról, tranzakciókezelésről, Testcontainersről, Kafkáról.

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

A Spring Modulit modulkezeléséről írtam korábban egy posztot Modularizált alkalmazás fejlesztése a Spring Modulith-tal címmel.

A poszt végén a videóhoz képest extra tartalom is van.

Bevezetés a Testcontainers használatába Spring Boot alkalmazásban

2024-07-16T08:00:00+00:00

Megjelent az első videóm, melynek témája, hogy hogyan lehet használni a Testcontainers-t Spring Boot alkalmazásban.

A videóhoz a forráskód is elérhető a GitHubon.

Ha valaki mégis a szöveges tartalomhoz ragaszkodik, olvasson tovább.

OAuth 2.0 támogatás a Spring Boot 3.3-ban és a Pécs IT Meetup

2024-06-27T08:00:00+00:00

A Spring Boot 3.3 verzióban tovább egyszerűsítették az OAuth 2.0 integrációt. Az előző verziók esetén, amennyiben a JWT tokenben a felhasználónév nem a sub claim alatt szerepelt, saját magunk kellett ezt kiolvasni, pl. egy saját JwtDecoder bean megadásával. Amennyiben a JWT token tartalmazta a szerepköröket is, saját JwtAuthenticationConverter beant kellett felvennünk, mely képes volt a szerepkörök kiolvasására.

Erre a Spring Boot 3.3 verziótól kezdve nincs szükség, hiszen beállíthatjuk ezt az application.properties állományban, és a Spring Boot automatikusan konfigurál egy JwtAuthenticationConverter (vagy reaktív esetben egy ReactiveJwtAuthenticationConverter beant).

Ezt is említettem a XV. Pécs IT Meetupon. A meghívást ezennel is köszönöm a Kovács Bálintnak, a meetup egyik szervezőjének, aki többedmagával a Webstar céget is képviselte.

Telemetria és a Java

2024-06-11T08:00:00+00:00

Napjainkban a telemetria egy nagyon fejlődő terület, napról napra jelennek meg új eszközök és szabványok, melyeket igen nehéz nyomonkövetni. Ez a poszt ebben szeretne egy kis rendet tenni, hiszen úgy lehet valamit a legjobban megismerni, hogyha másoknak elmagyarázod.

A telemetria (telemetry) klasszikusan egy rendszer különböző elemein mérési adatok előállítása és továbbítása egy központi helyre. Ennek célja, hogy a múltbéli és jelenlegi adatok elemzésével meg lehessen bizonyosodni a rendszer helyes működéséről, észlelni, esetleg előre jelezni lehessen annak hibáit. Erre különböző eszközöket és folyamatokat használunk, melyek biztosítják a rendszer folyamatos megfigyelhetőségét (observability).

Szoftverrendszer esetén is pontosan erről van szó, különböző mérési adatokat állítunk elő különböző szinteken, pl. operációs rendszer szinten mérjük a CPU, memória és lemezhasználatot, de alkalmazás/szolgáltatás szinten mérhető a bejelentkezett felhasználók, beérkező kérések, tranzakciók száma, válaszidők. Ezen adatokból kinyert információkból következtethetünk a szoftver állapotára, hibára. A túl magas válaszidő biztos valami problémára utal, de az rossz jel lehet, ha hirtelen lecsökken a tranzakciószám.

AWS Lambda és a Spring Cloud Function

2024-05-10T08:00:00+00:00

Az AWS Lambda egy AWS szolgáltatás, mely lehetővé teszi, hogy a különböző programozási nyelven megírt alkalmazásainkat (függvényeinket) anélkül tudjuk futtatni, hogy gondunk lenne az azt kiszolgáló infrastruktúrára. A szolgáltatás a serverless computing kategóriába tartozik, ami kicsit megtévesztő, hiszen itt is van futtató környezet, azonban ez számunkra láthatatlan. A másik ismert megnevezése a Function as a Service (FaaS). Természetesen más cloud szolgáltatóknak is van hasonló megoldásuk, a Microsoftnál az Azure Functions, a Google-nél a Cloud Functions.

A függvények tipikusan valamilyen beérkező eseményre reagálnak, ami lehet egy felhasználói kérés, valamilyen üzenet más szolgáltatás (pl. S3) felöl, vagy üzenet brókeren keresztül beérkező üzenet, pl. valamilyen IoT eszköz, vagy alkalmazás irányából. Miután megírjuk a választott programozási nyelven a függvényünket, azt össze kell csomagolni, és telepíteni. Ez lehet akár egy tömörített fájl, akár egy container image. A szolgáltatás rugalmassága miatt ma akár bármilyen programozási nyelven írhatunk ilyen függvényeket.

A futtatókörnyezettel nem kell foglalkozni, azt a szolgáltatás önmaga kezeli. Ez magában foglalja a hardvert és az operációs rendszert, annak frissítését, erőforrás kezelést, automatikus skálázást és naplózást. És fizetnünk is csak annyit kell, amennyit futott a függvényünk, idő alapján (ezredmásodperc alapon).

A kód futtatása természetesen konténerekben történik, melyek tartalmazzák az adott programozási nyelv futtatókörnyezetét. Azonban a szolgáltatás nem mindig indít minden bejövő eseményhez új konténert, hanem megpróbálja azokat újrahasznosítani. Ennek egyik következménye, hogy bizonyos kérések kiszolgálása tovább tart, mikor a konténert el kell indítani (ún. cold start). Bizonyos kérések kiszolgálása azonban nagyon gyorsan megtörténik (ún. warm start). A nem használt konténereket a szolgáltatás automatikusan leállítja. Másrészt mivel a kérések kiszolgálása ugyanabban a konténerben futhat, lehet ezeknek egymásra hatása (pl. ha használják a fájlrendszert).

Egy AWS Lambda konténer rendelkezésére álló memória konfigurálható 128 és 10240 MB között, természetesen egy ezredmásodperc ára is annál nagyobb, minél több memóriát használ a konténer. Valamint 512 MB és 10240 MB között tudunk hozzá tárhelyet is rendelni, minél többet, annál nagyobb felárral.

Amennyiben saját image-t állítunk elő, először a Amazon Elastic Container Registry (Amazon ECR) szolgáltatásba kell feltöltenünk.

Ha a Lambda függvényünket REST-en akarjuk meghívni, akkor még az API Gateway szolgáltatást kell használnunk.

Ezek alapján mikor érdemes az AWS Lambdát használni? Olyan funkciók megvalósítására ideális, amik eseményekre reagálnak, nincs rá folyamatosan szükségünk, nem kell azonnali választ adnunk, és az üzenetek beérkezése nem egyenletes. Ilyen lehet pl. a kép- és videófeldolgozás, bejövő események adatainak aggregálása, (PDF) dokumentumok generálása.

Vannak azonban esetek, amelyeknél el kell gondolkodnunk, hogy tényleg az AWS Lambda-e a jó választás. Ilyenek például a klasszikus webes alkalmazások. Itt egy gyenge forgalom esetén lehet, hogy a cold start miatt nagyobb lesz a válaszidő. Valamint egy nagyon nagy terhelésű alkalmazás esetén pedig lehet, hogy az idő alapú számlázás nem a legkedvezőbb.

A Spring Cloud Function egy olyan projekt, mely a Spring ökoszisztéma tagja, Spring Boothoz illeszkedik, és segítségével az üzleti logikát Java 8 funkcionális interfészek implementálásával tudjuk megvalósítani. Ezáltal teljesen leválasztja az infrastruktúrális elemekről. Azonban adapterekkel, konfigurációt használva össze tudjuk kapcsolni az üzleti logikát különböző szolgáltatásokkal, pl. AWS Lambdaval is. A Spring Cloud Stream használatával pedig különböző message brokerrekkel, mint pl. RabbitMQ-val vagy Apache Kafkával.

Mivel nem mindegy, hogy a function mennyi memóriát használ, és mennyi idő alatt indul el, ezért a Java bytekód nem feltétlenül a legjobb választás. Azonban a Spring Boot alkalmazásokat könnyű natívvá fordítani.

Ebben a posztban azt mutatom be, hogyan lehet egy natívra fordított, Spring Cloud Functiont használó alkalmazást AWS Lambda függvényként futtatni.

(A példa ingyenesen kipróbálható az AWS Free Tier használatával. Bankkártya adatok megadása szükséges.)

Project Reactor és a szálkezelés

2024-02-01T09:00:00+00:00

A Project Reactor egy Springhez közel álló reaktív könyvtár. Erre épül a Spring Framework 5-ben megjelent WebFlux webes keretrendszer reaktív webes alkalmazások készítésére. Ez nagyban hasonlít a Spring MVC-re, azonban reaktív módon működik. Ezzel találkozhatunk akkor is, ha WebClient-et használunk REST webszolgáltatások hívására (ez a RestTemplate-et hivatott leváltani, de úgy tűnik, hogy mégis szükség van egy szinkron megvalósításra is, ezért jelent meg a 6.1-es Spring Frameworkben a RestClient). A reaktív elvekről és keretrendszerekről már írtam a Reaktív programozás posztomban.

A Reactor ún. concurrency-agnostic, ami azt jelenti, hogy nem erőltet ránk semmilyen párhuzamossági modellt. Azonban a fejlesztőnek lehetőséget ad a szálak használatára.

Ez a poszt azzal foglalkozik, hogy lehet szálakat használni, hogyan befolyásolja a szálak használatát a publishOn és subscribeOn operátor (Mono és Flux osztályokban lévő metódusok).

A REST API hypertext-driven legyen

2023-10-11T08:00:00+00:00

Bár erős vitákat tapasztalok a REST körül, valahogy a hypertext-driven API-val ritkán találkozom.

Roy T. Fielding, a REST megálmodója a gyakran idézett REST APIs must be hypertext-driven cikkjében a következőt mondja:

In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period.

Erre erősít rá a Richardson Maturity Model is, mely három lépésben mutatja be a REST alapvető elemeit:

Level 1 - Resources
Level 2 - HTTP Verbs
Level 3 - Hypermedia Controls

És egy API csak akkor nevezhető RESTfulnak, ha az összes szinten leírtakat teljesíti, igen a hypermedia control használatát is.

De mit is jelent ez? Az állítás egyszerű: a kliensnek minden előzetes tudás nélkül igénybe kell tudnia venni a RESTful API mögötti szolgáltatásokat, és ez linkek segítségével valósulhat meg.

Pl. az előző Workflow REST API-n posztomban szereplő Issue Tracker alkalmazás a következőképp adja vissza a hibajegyek listáját:

{
  "_embedded": {
    "jtl:issueResourceList": [
      {
        "id": 1,
        "title": "Write a post about REST",
        "state": "NEW",
        "_links": {
          "self": {
            "href": "http://localhost:8080/api/issues/1"
          },
          "actions": {
            "href": "http://localhost:8080/api/issues/1/actions"
          }
        }
      }
    ]
  },
  "_links": {
    "self": {
      "href": "http://localhost:8080/api/issues"
    }
  }
}

Látható a hibajegyek listáját reprezentáló URL-jét tartalmazó self link, valamint hibajegyenként a hibajegyet reprezentáló URL-jének linkje szintén self névvel, valamint a hibajegyhez tartozó lépéseket reprenzentáló URL actions névvel.

Ez a Hypermedia as the engine of application state (HATEOAS), melyet szintén Roy T. Fielding vezetett be a disszertációjában. A HATEOAS szerint a szerver a kliens számára linkekkel jelzi, hogy mit tehet.

Az elv mögötte az, hogy a REST API-t is úgy lehessen használni, mint a webet. Ahol vannak oldalak és linkek és semmilyen előzetes információra nincs szükségem a használatához.

Hogy hogyan viszonyul ez az OpenAPI-hoz (Swaggerhez)? Elvileg a cél ugyanaz, és míg a HATEOAS a REST gonolatiságához illeszkedik, az OpenAPI inkább az RPC-hez.

Workflow REST API-n

2023-08-31T08:00:00+00:00

Bár kétségtelenül a REST a legelterjedtebb kommunikációs mód, akár ugyanolyan platformon fejlesztett alkalmazások között is, REST API tervezéskor nekem sok kérdés merül fel, melyre nem kapok megnyugtató választ, és sok olyan megoldással találkozom, amelyek nem felelnek meg a REST elveknek, vagy egyszerűen csak nem tetszenek.

Sokáig próbáltam megfogalmazni, hogy mi az alapvető problémám, és talán most sikerült közelebb kerülni. Vegyünk két microservice-t, melyek mindegyike Javaban készült, Spring Boot használatával. Mindkét oldalon a programozási nyelv alapeleme az osztályok, ahol érvényesül az egységbezárás, azaz az attribútumok mellett ott vannak a metódusok, a megfelelő paraméterekkel és visszatérési értékekkel. Ez a legtöbb fejlesztőnek triviális.

A REST a kettő között viszont egy teljesen más absztrakció. Bár a REST nem mondja ki, hogy csak HTTP-vel együtt használható, más protokollal működni még nem láttam. A REST alapfogalma az erőforrás, és az azon végzett műveletek, melyeket a HTTP metódusok valósítanak meg, mint a GET, POST, PUT és DELETE. Ez nehezen feleltethető meg az objektumorientált világnak. Egy objektum létrehozására tipikusan konstruktort használunk, ebből nem feltétlen egy van. Ezen kívül egy objektumnak lehet több metódusa, amik nem feltétlenül feleltethetőek meg a HTTP metódusoknak, hiszen nem csak ezeket az alapműveleteket használjuk, valamint lehet belőle sokkal több is, mint négy. Míg a Java nyelv szabvány, addig a REST csak egy ajánlás, és az sincs megfelelően definiálva, hogy hogyan kéne implementálni, az meg aztán pláne nincs, hogy a kettőt hogyan feleltessük meg egymásnak. És ennek az az eredménye, hogy minden projekten teljesen más megoldásokat látok, a legtöbb helyen kompromisszumokkal.

Az RPC alapú kommunikáció esetén igazából nincs ilyen probléma, mert nem szükséges átfordítás, nincs szükség az absztrakció váltására. Hiszen ott is eljárások vannak, paraméterekkel és visszatérési értékekkel. A Spring Frameworkben volt is ilyen lehetőség, hogy egy távoli eljáráshívás történt, azonban a protokollt kódolás nélkül cserélni lehetett alatta, pl. választhattunk RMI-t, vagy ki emlékszik még a Hessian és Burlap protokollokra. Sajnos ez azóta eltűnt. A SOAP esetén sem volt akkora probléma az átfordítás, hiszen ott is vannak az operációk (eljárásnak felel meg), és a paraméter, valamint a visszatérési érték is egy-egy (XML) dokumentum. Vannak modernebb RPC alapú kommunikációs protokollok is, mint pl. JSON-RPC, vagy az egyre inkább elterjedő multiplatform gRPC, bináris Protocol Buffers formátummal.

Amennyiben CRUD alkalmazásról van szó, a REST használata talán triviális. De ha egy olyan alkalmazásról beszélünk, amiben komoly üzleti logika van (és hiszem, hogy a legtöbb alkalmazásnak ilyennek kéne lennie, csak a fejlesztők “butítják le” CRUD alkalmazássá, amely végső soron oda is vezethet, hogy borzasztó felhasználói felületek kerülnek kifejlesztésre), akkor már több kérdés merül fel.

Vegyünk például egy hibajegykezelő alkalmazást (issue tracker), mely rendelkezzen egy minimális üzleti logikával. Ha hibajegy kerül felvételre, az új (new) állapottal kerül létrehozásra. Amennyiben valaki elkezd rajta dolgozni, átkerül folyamatban (in_progress) állapotba. Amennyiben elkészült, átkerül megoldott (resolved) állapotba. Bár a legtöbb hibajegykezelő alkalmazás lehetővé teszi, hogy egyedi munkafolyamatot lehessen benne létrehozni, ettől most tekintsünk el, mert akkor megint más problémák merülnek fel. Ezt egy egyszerű állapotdiagrammal lehet a legegyszerűbben szemléltetni.

Talán egy hibajegy felvételét még el tudom képzelni REST API-n (bár már ott is vannak kérdéseim), azonban a különböző munkafolyamat lépések implementálásakor már bizonytalanabb vagyok. Ez a poszt ezt a problémakört járja körbe, forráskódokkal alátámasztva.

Hőmérséklet monitorozása

2023-08-18T08:00:00+00:00

Nagyon régóta érdekel az IoT (Internet of Things, azaz Internetre köthető kütyük) világa, ugyanis ezek azok az eszközök, melyek összekötik a virtuális világót a való világgal. Már régóta rendelkezem egy Raspberry PI számítógéppel, melyet azóta is lelkesen használok egy alacsony fogyasztású home serverként. Telepítve van rá a Prometheus és Grafana, mely a DevOps világban egy kvázi standard monitorozó eszköz. Mindkettő ingyenesen használható, nyílt forráskódú eszköz. A Prometheus különösen alkalmas idősorok hatékony tárolására, gyors lekérdezésére, aggregált műveletek végrehajtására. Az idősorok olyan megfigyelések, melyeket egymást követő időpontokban (időszakokban) regisztrálták, és ez az időbeliség az adatok fontos tulajdonsága. Ilyen például egy szerverrel kapcsolatban a bizonyos időpontokban lekérdezett CPU és memóriahasználat, vagy a háttértárakon lévő szabad hely mérete. A Grafana használatával ezeket tudjuk vizualizálni, gyönyörű dashboardokat létrehozni és akár riasztásokat beállítani.

De melyik is lehet az az IoT eszköz, melyet a legegyszerűbben, lehetőleg barkácsolás nélkül és olcsón lehetne bekötni ebbe a rendszerbe? Már régóta szemezem a Xiaomi Mi Temperature and Humidity Monitor 2 hőmérséklet-, és páratartalom mérővel, amihez most 2000 Ft-ért lehet hozzájutni az mStore akciója keretében.

Ez pontosan a LYWSD03MMC modell, mely egy precíz Sensirion szenzorral, 1,5”-os LCD kijelzővel rendelkezik, és Bluetooth 4.2 BLE vezeték nélküli kapcsolaton keresztül kommunikál. Egy CR2032 elemmel működik, ezt külön szerezzük be, mert nem része a csomagnak. Ezzel akár fél-egy évig képes üzemelni. Természetesen Bluetooth-on tud kapcsolódni mobiltelefonhoz, illetve Bluetooth Gateway-hez, azonban én direktbe, egy Linuxos számítógéppel, jelen esetben egy Raspberry PI-vel szeretnék hozzá kapcsolódni, és kinyerni belőle az adatokat. (Nincs szükség egyedi firmware telepítésére.)

Ezt utána csak be kell kötni a Prometheusba, mely időközönként lekérdezi és eltárolja az adatokat, majd egy Grafana dashboardot létrehozni, mely megjeleníti azokat.

Közben természetesen szerettem volna megismerni a kapcsolódó technológiákat is.

JTechLog Technology Radar

2023-08-12T08:00:00+00:00

Emlékszem régebben mennyire nagy esemény volt mindig, mikor kijött a Thoughtworks Technology Radar legfrissebb kiadása. A Thoughtworksről annyit kell tudni, hogy 1999-ben csatlakozott a céghez Martin Fowler, és több munkatársával együtt jelentős és meghatározó könyveket írtak, melyeket én is javaslok elolvasni. Ezek például:

Martin Fowler - Refactoring
Martin Fowler - Patterns of Enterprise Application Architecture
Jez Humble, David Farley - Continuous Delivery
Sam Newman - Building Microservices

A cég mindig nagyon haladó gondolkodású volt, és bizonyos időközönként közreadta a Technology Radart, melyben grafikusan ábrázolták, hogy mi is a véleményük az épp aktuális technológiákról, eszközökről, módszertanokról.

Gondolatok a modell osztályokról, entitásokról, DTO-król

2023-08-01T08:00:00+00:00

Nagyon szeretem azokat az írásokat, melyek különböző területekről származó fogalmakat próbálnak valamilyen egységes rendszerbe foglalni, a fogalmaknak egységes elnevezést adni. Ilyen volt a Tom Hombergs - Get Your Hands Dirty on Clean Architecture (2nd edition) könyv, mely a modell osztályokkal próbálta ezt tenni. Különösen tetszett, hogy nem egy megoldást fogad el igaznak, hanem ismerteti a különböző megoldásokat, összehasonlítva azok előnyeit és hátrányait.

A mostanában fejlesztett alkalmazások vagy a klasszikus háromrétegű (3-layer) architektúrával készülnek, vagy a modernebb Hexagonal vagy Clean Architecture-t használják.

Egy klasszikus Spring Boot alkalmazás esetén a három réteg a repository, service, controller. Java EE esetén ez a web, üzleti és EIS (Enterprise Information System) rétegek. Én egységesen úgy fogok rájuk hivatkozni, hogy prezentációs, üzleti logika és perzisztens réteg.

Clean Architecture esetén is megjelennek ezek, az alapvető különbség a függőségek irányában van, hiszen amíg a klasszikus háromrétegű alkalmazás esetén az üzleti logika réteg függ a perzisztens rétegtől, addig a Clean Architecture esetén a perzisztens réteg függ az üzleti logika rétegtől.

Minden rétegben szükség van azonban az adatokat tároló osztályokra, nevezzük ezeket modell osztályoknak. Manapság ezek egyszerű POJO (Plain Old Java Object) osztályok, pár attribútummal, konstruktorokkal, getter/setter metódusokkal.

Kérdés, hogy ebbe a fogalomrendszerbe hogyan illeszkednek be az entitások, DTO-k, stb.? Melyik rétegben helyezkednek el? Illetve kell-e, és hogyan kell ezek között a megfeleltetést elvégezni (mapping), konvertálni? Ez a poszt ebben próbál egyfajta rendet tenni.

Spring Security és Spring Boot

2023-03-28T08:00:00+00:00

Frissítve: 2023. november 15.

Technológiák: Spring Security 6.1, Spring Boot 3.1, Thymeleaf, Spring Data JPA, H2

(Azért írtam meg ezt a posztot, mert sokan kerestek a Spring Security-re, továbbá 2022 novemberében kijött a Spring Security 6 és Spring Boot 3, valamint teljesértékű Spring Security poszt Spring Boottal eddig hiányzott. A Spring Security használata Springgel Frameworkkel poszt továbbra is elérhető.)

A Spring Security egy olyan keretrendszer, mely támogatja az autentikációt, autorizációt és védelmet biztosít bizonyos támadási formák ellen. A Spring Security a de-facto szabványos eszköz a biztonság megvalósítására Springes alkalmazásokon belül.

A Spring Security támogatja a felhasználónév és jelszó párossal történő bejelentkezést, de ezen kívül pl. webszolgáltatások védelmére támogatja a HTTP BASIC, HTTP Digest és tanúsítvány alapú bejelentkezést, sőt az OAuth 2.0 használatát is.

A felhasználók és a hozzá kapcsolódó szerepkörök tárolhatóak memóriában, adatbázisban, LDAP szerveren, stb. Ezekhez adottak beépített implementációk, de saját is készíthető. Támogatja a jelszó hashelését különböző algoritmusokkal. A felhasználóval kapcsolatos információkat képes cache-elni is. Különböző eseményekre eseménykezelőket lehet aggatni, pl. bejelentkezés, így könnyen megoldható pl. audit naplózás.

Az alkalmazáson belül szerepkörökhöz lehet kötni bizonyos url-eket, valamint metódus szinten is meg lehet adni, hogy milyen szerepkörrel rendelkező felhasználó hívhatja meg.

A poszthoz egy példa projekt is tartozik, mely elérhető a GitHub-on. Egyszerű Spring Boot webes alkalmazás, Spring Data JPA perzisztens réteggel, Thymeleaf template engine-nel.

Modularizált alkalmazás fejlesztése a Spring Modulith-tal

2022-12-19T09:00:00+00:00

Bevezetés

A microservice alkalmazások népszerűsége továbbra is töretlen. Miért is választják sokan ezt az architektúrát? Egyik ok természetesen a hype factor, sokan szeretnék kipróbálni, valamint hogy bekerüljön az önéletrajzukba. További ok, hogy sokan megcsömörlöttek a monolitikus alkalmazásoktól, hiszen sok kötöttséggel járnak mind fejlesztés, mind üzemeltetési oldalról. Ebből talán a legfontosabb, hogy gyakori jellemzője a spagetti kód, ennek következményeképp ha valahol belenyúlunk az alkalmazásba, lehet, hogy másik helyen romlik el, ezért ha telepíteni akarunk, ha biztosra akarunk menni, a teljes alkalmazást újra kéne tesztelnünk. Erre megoldás lehet a microservice architektúra, ahol az alkalmazásunkat lazán kapcsolódó szolgáltatásokra bontjuk fel. Ezzel kapcsolatban azonban a leggyakrabban elhangzó kérdés, hogy hol a határ, hol vágjunk, mi alapján bontsuk szét az alkalmazásunkat szolgáltatásokra. Monolitikus alkalmazásnál további kötöttségek a technológiai kötöttségek, valamint hogy a teljes alkalmazást egyben lehet csak telepíteni. És érdekes módon, csak ritkán szoktam azzal az indokkal találkozni, hogy azért választották a microservice architektúrát, mert gond volt a skálázhatósággal, aminek pedig nagy szerepe volt a kialakulásában.

Gyakran elfelejtjük, hogy egy monolitikus alkalmazásnak sem kéne szükségszerűen egyben lennie, hanem azt is felépíthetjük lazán kapcsolt komponensekből. A hiányzó láncszem itt a modul. A modularizált monolitikus alkalmazást szokás modulith-nak nevezni. Ennek létét két okból is fontosnak tartom. Egyrészt úgy vélem, hogy ahol nem tudnak modularizált alkalmazást fejleszteni, ott nem érdemes a microservice architektúrával foglalkozni, ugyanis ezek a technológiák nem mutatják meg, hogy hogy kell vágni. És a rossz vágásnak az eredménye ugyanúgy spagetti lesz, de már meg lesz nehezítve az elosztottságból adódó technológiai és üzemeltetési bonyodalmakkal is. Többek által is jónak tartott út a microservice-ek felé, hogy először modularizáljuk az alkalmazásunkat, majd utána emeljük ki a moduljainkat külön service-ekbe. A másik ok, amit érdemes észben tartani, hogy már egyre több helyről hallani, hogy a microservice architektúra nem vált be, nem váltotta be az ígéreteket, a szervezet még nem állt készen (pl. agilis módszertanok, DevOps, CI/CD hiánya - igen, ezek a microservice-ek előfeltételei), nem volt szükség skálázhatóságra, még rosszabb lett performanciában, stb.

Technológiailag a modulok azonban elég kevésbé támogatottak. Kezdeti próbálkozás volt az OSGi, azonban komplexitása miatt nem terjedt el, pedig olyan igéretei vannak, mint a futás közbeni plugin telepítés, valamint egy library-nek különböző verziói a classpath-on. Szabványos megoldást a Java Platform Module System próbált adni a Java 9-ben, de annak ellenére, hogy már mikor megjelent, szintén nem sikerült még elterjednie. A leggyakrabban használt megoldás a build rendszer által biztosított modularizáció, gondoljunk itt a Maven multi module projectre. Illetve a Gradle is azt hangoztatja, hogy multi module projektek kezelésében jobb és gyorsabb, mint a Maven. Azonban ez is plusz komplexitással jár, különösen a build folyamat, a CI/CD terén.

A kézenfekvő megoldás a Java csomagok használata lenne, azonban ez sajnos túl kevés eszközt ad a kezünkbe, a láthatósági módosítók csak nagyon szegényes hozzáférés szabályozást nyújtanak. Ennek kiegészítésére jelent meg az Spring Modulith projekt, mely több jó megoldást is ad. Nem hiszek feltétlenül abban, hogy ez az eszköz el fog terjedni, de a benne lévő ötleteket érdemes ismerni, és akár a saját projekjeinkben is bevezetni.

Perzisztens réteg technológiák és a MyBatis

2022-10-06T08:00:00+00:00

Bevezetés

Amikor adatbázist kell választani, főleg a relációs adatbázisok és az SQL kerülnek szóba. Az ezzel való kapcsolattartásra az alkalmazás oldalon főleg a JPA szabványt, és annak valamelyik implementációját, pl. a Hibernate-et használjuk.

Régóta sokan ódzkodnak ettől a technológiától, különböző okok miatt. Hamar lehet vele eredményeket elérni, azonban nagyon nehéz megérteni a mélységeit. Ennek hiányában azonban az alkalmazásunk rosszul teljesíthet, az N + 1 probléma miatt nagyon sok SQL utasítást adhat ki, és mivel a JPA implementáció ezeket generálja, nem tudjuk finoman szabályozni. A JPA ezen kívül nehezebben alkalmazható egy már meglévő, esetleg nem körültekintően megtervezett adatbázisra, sokkal inkább támogatja azt, ha a Java osztályokból indulunk ki.

Ezért érdemes megnézni, hogy milyen alternatív technológiák vannak, és ezek milyen jellemzőkkel rendelkeznek.

A technológia kiválasztása valamilyen szinten hat az alkalmazásunk architektúrájára is. Többrétegű alkalmazás esetén a perzisztens réteg tartja a kapcsolatot az adatbázissal. Itt különböző architektúrális mintákat használhatunk, ebből egy pár darab:

Repository pattern, a Domain Driven Design (DDD) könyvből
Table és Row Data Gateway a Patterns of Enterprise Application Architecture (Martin Fowler) könyvből
Data Mapper ugyanonnan
Data Access Object (DAO) a Java EE tervezési minták közül

Bizonyos neveket ráadásul bizonyos technológiák is használnak, ilyen pl. a repository, melyet a Spring Framework is használ a perzisztens rétegének elnevezésére, amit a Spring Data JPA is átvett.

Az eredeti tervem az volt, hogy ezek jelentését részletesen kifejtem, és összehasonlítom őket. De rossz hírem van. Arra jöttem rá, hogy ezeket a fogalmak nincsenek jól definiálva, nem összehasonlíthatóak, és mindenki másra használja ezeket. És ezt a különböző technológiák tovább bonyolítják, ugyanis saját komponenseik elnevezésére használják ezeket a fogalmakat, helytelenül.

(Egy szemléletes példa erre, hogy a DDD szerint a repository egy olyan objektum, mely az üzleti logika és az és az üzleti objektumok adatbázisból olvasásáért vagy oda írásáért felelős ún. mapping réteg között helyezkedik el, és az üzleti objektumokat a kollekciókhoz hasonlóan kezeli. Ezen túl komplex lekérdezési lehetőséget is biztosít úgy, hogy a lekérdezési feltételeket dinamikusan lehet összeállítani. A Spring Data JPA repository-ja ezzel pont ellentétes, előre definiálnunk kell a metódusokat, melyek csak egy jól meghatározott feltétellel hívhatóak meg. Saját véleményem szerint a repository-nak a JPA Criteria Query API-ja sokkal jobban megfelel.)

Ezért úgy döntöttem, nem én fogok ezekben a fogalmakban rendet szabni, hanem inkább egy tulajdonság rendszert állítok össze, ami alapján a perzisztens technológiák osztályozhatóak. Ez legyen a következő:

Szabvány-e vagy egyedi implementáció
Ingyenes-e
SQL lekérdező nyelvet kell használni, vagy saját nyelve van, amiből maga generál le SQL utasításokat
Van-e benne mapping, azaz az adatbázisból jövő adatokat automatikusan meg tudja-e feleltetni az objektumokkal
Elég-e interfészeket definiálni, amihez maga generálja ki az implementációt.
Képes-e metódusnév alapján implementációt generálni

A mapping tipikusan reflectionnel működik, és rendelkezik alapkonfigurációval (pl. az attribútum neve megegyezik az oszlopnévvel), de ez személyre is szabható.

Azt is eldöntöttem, hogy nem a különböző tervezési minták neveit fogom használni, hanem a különböző technológiák elnevezési konvencióit.

Ezek alapján a JPA:

Szabványos, a Java EE szabvány része, implementációi pl. a Hibernate vagy az EclipseLink
Mindkét elterjedt implementációja ingyenes
Saját nyelve van, a JPQL, vagy a Criteria Query API is használható
(Object-Relational Mapping) ORM eszköz, azaz megfelelteti az objektumokat az adatbázisból jövő adatokkal
Nem elég interfészeket definiálni
Ezért metódusnév alapján sem tud implementációt generálni

Spring Boot 3 újdonságai

2022-09-13T08:00:00+00:00

Frissítve: 2023. október 3.

Bevezetés

Mivel a hétvégén megkaptam, hogy írjak már Javas cikkeket, így ebben a posztban a Spring Boot 3 újdonságait veszem sorra. A Spring Boot 3-as sorozat már a Spring Framework 6-os sorozatára építkezik, ennek újdonságait nem fogom külön tárgyalni. A poszt megírásának a pillanatában a legfrissebb verzió a 3.1.4.

Az említendő változások a következő területeket érintik:

Alapkövetelmény a Java 17
Jakarta EE 9 függőségek
Problem Details
Tracing
Natív futtatható fájl elkészítése

Fejlesztőként mivel akadályozom a tesztelők munkáját?

2022-08-20T08:00:00+00:00

Bevezetés

Frissítve: 2022. november 04-én, kiegészítve a Rossz gyakorlat: Egy projekten már teszteltünk, nem vált be, a Rossz gyakorlat: nem megfelelő üzleti fogalmakat használok, a Rossz gyakorlat: nem megfelelő branch-en történik a tesztelés, és a Rossz gyakorlat: nem bontom részproblémákra a problémát fejezetekkel

Frissítve: 2022. augusztus 21-én, kiegészítve a Naplózás fontossága résszel, valamint a cache-re vonatkozó ajánlásokkal

Ahhoz, hogy sikeres szoftvert tudjunk szállítani, hiszem, hogy nagyon fontos a fejlesztők és a tesztelők közötti szoros együttműködés. És mikor tesztelőket említek, ugyanúgy gondolok a manuális és automata tesztelőkre is. Az irányzat, mely a fejlesztők és az üzemeltetők közötti kapcsolat fontosságát hangsúlyozza, a DevOps nevet kapta. Célja egy olyan kultúra kialakítása, gyakorlatok és eszközök kiválasztása, ahol a fejlesztők és az üzemeltetők közös munkával tudnak gyorsan, megbízhatóan alkalmazásokat és megoldásokat szállítani. Ez a fogalom manapság igencsak felkapott, de méltatlannak érzem, hogy a tesztelőkkel való közös munka fontosságának kiemelése korántsem ennyire hangsúlyos.

Történetileg kialakult, hogy a fejlesztés és az üzemeltetés a legtöbb cégnél elvált egymástól, tisztán elválasztott szervezeti egységekben, sőt akár külön cégekben működtek, melyek között a kommunikáció finoman szólva is döcögős volt. Sőt, úgy érződött, hogy a két csoportnak eltérő a célja. Az üzemeltetők stabilitást, biztonságot, tervezhetőséget szerettek volna, míg a fejlesztők mindig az örökös változásért, fejlődésért harcoltak. Észrevehetjük, ugyanez megfigyelhető a tesztelőknél is, egyrészt a különválás, a nehézkes kommunikáció, és a látszólag ellentétes cél. Van, hogy a fejlesztők által késznek minősített alkalmazást a tesztelők “visszadobnak”. Kezdjük felismerni, hogy az üzemeltetés és a fejlesztés szétválasztása káros, de vajon így érezzük a tesztelők munkájával kapcsolatban is? Ráadásul az egyes agilis módszertanok, mint pl. a Scrum szerint a csapat felelős a sprint végén a kész termék leszállításáért, és ebben olyan egyenrangú csapattagok vesznek részt, akik persze rendelkeznek speciális ismeretekkel, pl. üzleti elemzés, fejlesztés, tesztelés vagy üzemeltetés.

Voltam olyan helyen, ahol a fentebb bemutatott elszigeteltség jelen volt, és mindig dolgoztam ennek csökkentésén. Voltan olyan projekten is, ahol ezen különböző ismeretekkel rendelkező szakemberek egy csapatban dolgoztak. Régóta tartok fejlesztői tanfolyamokat, köztük kezdő fejlesztői tanfolyamokat, amin egyre több tesztelővel találkozok, aki el akar mozdulni az automata tesztelés irányába. Sőt részt vettem tesztelői bootcampek megszervezésében is, ahol nagyon sokat tanultam a tesztelő kollégáimtól, és beleláthattam ennek a szakmának a szépségeibe is, és erősítették bennem a hitet, hogy mennyire fontos az együttműködés. Sőt, automata teszt eszközökkel kapcsolatos képzéseket is tartok, amin szintén sok tesztelő vesz részt.

Ezen tapasztalataim alapján, és a tesztelők (akár szünetekben elmesélt) történeteit meghallgatva gyakran úgy látom, hogy a fejlesztőknek a teszteléssel kapcsolatban rengeteg tévhit él a fejében, és rengeteg rossz gyakorlatot folytatnak. Ebben a posztban ezeket próbálom felsorolni, megcáfolni. Lesz szó általános elvekről, de pár helyen lemegyek technológiai szintre is. Egyes szám első személyben fogok írni, fejlesztő lévén, még akkor is, ha magam nem így gondolkozom, így megpróbálok senkit sem megsérteni. Félreértés ne essék, nem ellentéteket szeretnék szítani, hanem megoldásokat kínálni.

Gondolatok az objektumorientált programozásról

2022-04-22T08:00:00+00:00

Egy fejlesztő számára a legtöbbször öröm egy új keretrendszer vagy lib kipróbálása, és használatba vétele, azonban szerintem ugyanilyen fontos újra és újra visszanyúlni az objektumorientált alapokhoz, az osztályok és metódusok tervezéshez. Ebben a posztban egy egyszerű példán keresztül próbálom bemutatni, hogy ennek is milyen mélységei lehetnek, és mennyire nem egyértelmű a jó megoldás kiválasztása. Az itt megismert fogalmak használata egyszerűsíti a fejlesztők közötti kommunikációt is.

A posztot az ihlette, hogy szó esett az invariánsról a Clean Code könyvben. És nem sokkal később a Domain-Driven Design könyvben is megemlítették.

Szoftverfejlesztés okosan Pythonnal

2022-02-03T09:00:00+00:00

Bár egyetértek azzal, hogy a programozással kapcsolatos szakirodalom nyelve az angol, mégis üdvözlöm a magyar nyelvű könyveket, és blogokat (hiszen ezért írom a JTechLogot is). Ezek a tartalmak itthon egy olyan réteget is meg tudnak szólítani, akik esetleg kedvet kapva, ezen az úton elindulva elkezdik fogyasztani az angol szakirodalmat is. Gondolok például az középiskolásokra, felsőoktatási intézmények diákjaira, manapság annyira népszerű bootcampeken tanulókra, rokon szakmákból érdeklődőkre (pl. üzleti elemzők, manuális tesztelők, matematikusok, stb.)

Ezért is tartom rajta a szemem a magyar nyelven megjelenő könyveken. Sok megkeresés érkezik hozzám azzal kapcsolatban is, hogy mivel ajánlott kezdeni, és a programozással kapcsolatos fórumokon, listákon, csoportokon is újra és újra előjön a kérdés. Mindig érdekelt az is, hogy egy kezdőknek szóló könyv hogyan próbál bevezetni rendkívül absztrakt fogalmakat, mennyire hoz új példákat, mennyire mer elrugaszkodni az eddigi tanítási módszerektől. Különösen a magyar szerzők könyveinek örülök.

Már 2020-ban láttam Guta Gábor Szoftverfejlesztés okosan Pythonnal : agilis csapatok közös nyelve című könyvét, és múltkor, mikor ki szerettem volna venni a könyvtárból, hogy belelapozzak, és nem találtam benn, döntöttem el, hogy írok neki, hátha van neki egy-két elfekvőben lévő példány. Gáborral már régóta ismerjük egymást, akkor még mindketten Javaval foglalkoztunk, azóta váltott át, és merült bele nagyon mélyen a Python világába. Mostanában ebben a témában ad elő különböző szakmai konferenciákon is, pl. kifejezetten ajánlom a Python és a turbó csiga című előadását a Python teljesítményhangolásról, mely a HWSW free! meetup-sorozaton hangzott el 2020. februárjában.