Időzónák használata

Az időzóna az a terület, ahol az óráknak azonos időt kéne mutatniuk. Funkcionális okok miatt ezeket nem a földrajzi hosszúságok határozzák meg, hanem tipikusan az országhatárokhoz igazodnak. Mindegyik időzónát a UTC világidőhöz (egyezményes világidő) viszonyítják. A UTC a GMT-t váltotta, de ez utóbbi már elavult, ne használjuk. A magyarországi időzóna a téli időszámításkor a CET (ami egy órával van előrébb a UTC-nél, jelölése ezért UTC+1), nyáron pedig CEST (, ami kettővel).

A dátumok formázásra van a ISO-8601 szabvány, ennek felel meg például a 2011-12-03T10:15:30+01:00[Europe/Budapest] formátum is, mely tartalmazza az UTC-hez képest az eltolást, és az időzóna nevét.

Ebben a posztban megvizsgálom, hogy hogy lehet kezelni az időzónát operációs rendszer szinten, adatbázisban, Java SE-ben, valamint egy Springes alkalmazásban, JPA/Hibernate perzisztens réteggel, és Jackson JSON library-vel.

Talán nem is fontos a teljes poszt megértése, inkább azt érdemes megjegyezni, hogy hol történnek konverziók, és ezeket hogy érdemes debuggolni.

Óda az integrációs tesztekhez

Megrendezésre került 2019. október 17-én a Training360 Nézz be a hype mögé fejlesztői meetupja. Ezen az Integrációs tesztek nehézségei (Javaban) címmel tartottam előadást, bár inkább az integrációs tesztek pozitívumait taglaltam.

Figyelem! A következő poszt nyugalom megzavarására alkalmas elemeket tartalmaz. Célom annak a hangsúlyozása, hogy olyan alapvető állításokat, tételeket is néha meg kell kérdőjeleznünk, mint a tesztpiramis. Ezért a posztban találkozhattok némi hangsúly áthelyezéssel, kéretik ezt a helyén kezelni.

Fotó a meetupról

A rendezvényre készült diák elérhetőek itt.

A posztban végigveszem a tesztpiramist, és az ezzel kapcsolatos fogalmakat, sőt fenntartásaimat is. Majd megvizsgálok egy alternatív megközelítést, mely különösen alkalmazható microservice-ekre. Közben példákat is hozok egy egyszerű Spring Boot alkalmazás tesztelésére. A példa projekt elérhető a GitHubon.

Clean Architecture

Robert C. Martin erőteljes hatást gyakorolt napjaink szoftverfejlesztésre. Egyike volt az Agile Manifesto aláíróinak, és számos tervezési elv kötődik a nevéhez. Ő alkotta meg a SOLID elvek rövidítést, mely saját és mástól átvett elveket is tartalmaz (pl. a Liskov-féle helyettesítési elvet Barbara Liskovtól). Ő a szerzője a közismert Clean Code és a The Clean Coder könyveknek. (A Clean Code-ról egy előző posztban írtam.) A 2017-ben megjelent Clean Architecture könyvről szól ez a poszt, és a poszt végén a saját véleményem is megosztom veletek.

Clean Architecture könyv

A Clean Architecture a szerző által megfogalmazott architektúráról ír, azonban részletesen bemutatja azokat az elveket is, melyek mentén eljutott a javasolt architektúráig. Talán nem meglepő, hogy a SOLID elvekből indult ki, és ezeket próbálja magasabb absztrakciós szinten is alkalmazni. Egy objektumorientált alkalmazás legfinomabban szemcsézett darabkái az osztályok, több osztály összetartozó egységét ő komponensnek (component) nevezi (klasszikus modul fogalom), és a teljes alkalmazást szolgáltatásnak (service). Nála a komponens a külön release-elhető, csomagolható és deploy-olható egység, Java esetén a JAR, C# esetén pl. a DLL fájl. A könyv próbál programozási nyelv független maradni, és főleg Java és C# példákat hoz.

Az architektúra hasonlít is a manapság elterjedt 3-rétegű architektúrához, azonban jelentős különbségeket is tartalmaz. Azt gondolom, hogy az elveket mindenképp érdemes megismerni, azt meg mindenki döntse el maga, hogy az elvek alapján létrehozott architektúrát mennyire szeretné követni.

OAuth 2.0 Spring Boot és Spring Security keretrendszerekkel

Használt technológiák: Spring Boot 2, Spring Security 5, Keycloak 9

A látogatottsági adatok alapján a legkedveltebbek a Spring Security-val foglalkozó posztjaim, ebből is kiemelkedik a JWT-vel foglalkozó JWT és Spring Security posztom. Ezért most arról fogok írni, hogy hogyan támogatja a Spring Security 5.x az OAuth 2.0 szabványt, mi is az az OAuth 2.0, valamint hogyan használható vállalati környezetben, miért érdemes ott is ebbe az irányba elmozdulni. Szó esik arról is, hogyan kell egy külön szervert beállítani a felhasználói adatok eltárolására és azonosításra/hitelesítésre/bejelentkezésre/autentikációra (authentication), erre a Keycloak nyílt forráskódú eszközt fogom használni (de mivel szabányos protokollok vannak, használhatnék más is). Valamint ehhez fogunk kapcsolódni egy Spring Boot alkalmazással, a Spring Security keretrendszer használatával.

Az OAuth egy nyílt szabány erőforrás-hozzáférés kezelésére, vagy ismertebb nevén authorizációra (authorization). Alapja, hogy elválik, hogy a felhasználó mit is akar igénybe venni, és az, hogy hol jelentkezik be. A legismertebb példa erre az, hogy mostanában ha igénybe akarunk venni egy online szolgáltatást, akkor nem feltétlen kell magunkat regisztrálnunk, hanem bejelentkezhetünk a Google vagy Facebook fiókunk használatával is. Ehhez az említett oldalon lehet bejelentkezni, ott megadni a jelszavunkat, majd folytathatjuk az online szolgáltatás oldalán a tevékenységünket. Nagy előnye, hogy egyrészt nem kell annyi jelszót megjegyeznünk, valamint az OAuth kialakítása miatt nem kell a jelszavunk megadni egy harmadik félnek.

Ha valaki most itt abbahagyná az olvasást, hogy az alkalmazásába nem akar sem Facebook, sem Google bejelentkezést, az is olvasson tovább. Ugyanis az OAuth szabvány használatával természetesen saját authorizációt is megvalósíthatunk, sőt, ez a javasolt mód. Ugyanis nagyon hamar eljuthatunk oda, hogy nem csak egy alkalmazást akarunk üzemeltetni, hanem kettőt, és nem szeretnénk, ha a felhasználóinknak több jelszót kelljen megjegyezniük. Ezt Single Sign-On-nak (SSO), egyszeri bejelentkezésnek nevezzük. És ez nem csak a felhasználóinknak jó, hanem a fejlesztőinknek is, hiszen ha kitaláljuk, hogy módosítani szeretnénk az autentikáción vagy authorizáción, például kétfaktoros autentikációt szeretnénk bevezetni, akkor elegendő egy helyen módosítani, nem kell módosítani a többi alkalmazáson. Erre jó példa, hogy a Google különböző szolgáltatásaiba sem kell külön bejelentkeznünk, mint pl. a GMail, YouTube vagy Maps.

Java Thread Dump

Mostanában úgy alakult, hogy egy webes alkalmazás belső működését kellett elemeznem. Ennek több oldalról is neki lehet ugrani, mint memóriahasználat, garbage collector működése, heap dump (JVM memóriájának tartalma), thread dump (futó szálak állapota), napló állományok, stb.

Vannak eszközök, amelyeknél nem kell feltétlen a JVM működésébe avatkoznunk, pl. naplófájl elemzésekor. Persze itt is előfordulhat olyan eset, hogy a naplózás szintjét állítanunk kell, ez történhet az alkalmazás újraindításával, de bizonyos megoldások engedik a naplózás szintjének futás szintű állítását (pl. Spring Boot Actuator /logger endpoint).

Vannak eszközök, melyekkel futó JVM-hez lehet csatlakozni, anélkül, hogy ezt erre felkészítettük volna. (Tipikusan az adott gépről, távoli hozzáféréshez biztos, hogy további konfiguráció szükséges.) Ilyen pl. a jstat a GC működésének és a memóriahasználat elemzésére, a jstack a thread dump lekéréséhez, valamint a jconsole mely egy komplex grafikus eszköz a JVM monitorozására. (Ez utóbbi használata már problémákba ütközhet, hiszen szerveren nem feltétlen van grafikus felület, a távoli hozzáférés meg további konfigurációkat igényel.)

Egyes eszközöket pedig már előre kell telepíteni és konfigurálni, hogy használni tudjuk.

Ez a poszt a thread dump készítéséről fog szólni, valamint annak elemzéséről, értelmezéséről. Szó esik hogy milyen eszközöket tudunk erre használni. A legtöbb poszt ezzel kapcsolatban arról szól, hogy lehet a hibásan programozott párhuzamosságból adódó deadlockokat, livelockokat kiszűrni, de én arra koncentrálok, hogy hogy lehet egyáltalán értelmezni a thread dumpot, hogy épp mit is csinál az alkalmazás.