Python build és Continuous Integration

Technológiák: Python 3, venv, pip, make, pytest, coverage, pytest-cov, pylint, SonarQube, Jenkins

Amint az mér egy korábbi posztból kiderülhetett, a Java mellett a Python az egyik kedvenc programozási nyelvem, ráadásul mostanában sok inspirációt és motivációt kapok, hogy foglalkozzam vele, egészen a nyelvi alapoktól (például az objektumorientáltság is) egy teljes projekt felépítéséig.

A Python nézetem szerint különösen alkalmas nyelv a programozás oktatására, valamint a programozásba való bevezetésbe, sőt akár olyanoknak is megmutatható, akiknek csak érintőleges kapcsolata lesz a programozáshoz.

A Python nyelvvel kapcsolatban nagyon sok írást, könyvet, videót lehet találni, azonban arról, hogy hogyan építsünk fel egy projektet, milyen build eszközt használjunk, hogyan integráljuk Continuous Integration eszközbe, hogyan biztosítsuk a kódminőséget, valamint mindezt hogyan érjük el fejlesztőkörnyezetből, arról már sokkal kevesebb, és egymással ellenmondó (esetleg elavult) információt lehet találni.

Java esetén viszonylag egyszerű, a Maven, JUnit, Jacoco, Jenkins, SonarQube eszközökkel nem lehet hibázni. Python esetén kicsit színesebb a kép. Nem árulok el titkot, hogy a SonarQube, melyről nemrég írtam, Python forráskód elemzésére is alkalmas, így azt megtartom.

Ezen poszt összefoglalja, hogy ezzel kapcsolatban meddig jutottam a kutatással. Amennyiben tévedést találsz, esetleg jobb megoldásod van, kérlek ne késlekedj velem megosztani. Természetesen több megoldás is elképzelhető, tetszőlegesen bonyolítható, azonban próbáltam egy minimális eszközkészletet összetenni, ráadásul olyanokat összeválogatni, melyek kellően elterjedtek.

Spring tranzakciókezelés

Technológiák: Spring Framework, Spring Boot 2.0.5

Ezen poszt bemutatja a Spring tranzakciókezelés mélységeit, a propagációs tulajdonságokkal, valamint kivételkezeléssel.

Előtte érdemes elolvasni a Tranzakciókezelés EJB 3 és Spring környezetben című régebbi posztomat, mely az alapfogalmakat mutatja be.

A példában egy DAO/repository osztály egyik metódusa meghív egy másik osztály egy metódusát. Először nézzük meg, hogy mi történik alapértelmezett esetben, mikor az első osztály metódusa van ellátva @Transactional annotációval, és kivétel történik, akár az első, akár a második metódusban. Majd nézzük meg, hogy lehet megvalósítani, hogy a két metódus külön tranzakcióban fusson, azaz az egyikben keletkezett kivételnek ne legyen kihatása a másik metódus tranzakciójára.

A másik érdekesség az szokott lenni, hogy ugyan lekezeljük a kivételt, mégis rollback történik. Nézzük meg, hogy lehet ezt megakadályozni.

A kivetelkezeléssel kapcsolatba belefutottam a Spring Boot egy érdekes tulajdonságába is, ami a repository rétegben keletkező kivételeket átfordítja.

Tapasztalatok a Java Platform Module Systemmel

Nagy rajongója vagyok a modularizálás témakörének, mint ezt több korábbi posztban is említettem (Modularizáció Servlet 3, Spring és Maven környezetben, Java Application Architecture). A Java Application Architecture könyv szerint a modularizálás első eszköze a csomagok, azonban ezek nem adnak megfelelő felügyeletet a láthatóság felett, hiszen nem lehet definiálni egy csomag láthatóságát, így azt sem lehet megmondani, hogy egy csomagban lévő osztályok, interfészek, stb. mely más csomagban található osztályok, interfészek, stb. számára legyenek láthatóak. A következő szint a JAR állományok, azonban az alapvető elvárásokat ez sem teljesítette, mint pl. az előbb említett láthatóságokkal kapcsolatos igényeket. Erre egy kezdeti megoldást a build eszköz (pl. Maven) adott, multi-module projektek használatával. Azonban itt sem lehetett definiálni, hogy egy modulon belül mi látható, és mi nem. Kizárólag modulokat lehetett definiálni, és ezek közötti függőségeket. A másik megoldás a Java részét nem képező OSGi jelentette, azonban ennek nehézkessége elég sokakat eltántorított.

A Java 9-ben jelent meg egy megoldás a fentebb vázolt problémákra, Java Platform Module System néven. Elég régóta húzódik ennek kiadása, egészen a Java 7-től kezdve ígérgették, akkor még Jigsaw néven. Figyelembe kell venni azonban azt is, hogy nem csak a lehetőségét adták meg a modularizációnak, hanem a teljes JDK-t is modularizálták. Már nem egy rt.jar állományban van a teljes osztálykönyvtár, hanem a jmods könytárban van majdnem száz jmod kiterjesztésű állomány, mely a modulokat tartalmazza.

Ebben a posztban egy példa alkalmazás implementációja közben szerzett tapasztalatokat szeretném megosztani. A projekt elérhető a GitHubon.

További posztok migrálása

Régebben jó ötletnek tűnt, hogy a nem olyan részletesen kifejtett, valamint a nem Javahoz kapcsolódó posztokat külön blogon posztolom. Azóta készült egy felmérés is, amiben a legtöbben azt válaszoltátok, hogy nem zavarna titeket a kevert tartalom. Így a könnyebb karbantarthatóság miatt a régebbi cikkeket is importáltam ide. Mivel 2014-es a legfrissebb poszt, elég elavultnak számíthatnak, de hátha még valakinek segíthet. Részletes lista a poszt végén olvasható. Kedvencem a Flightradar24 cikk, mely a repülőgépek helymeghatározásáról szól.

Ékezetes karakterek PDF állományban

Ismét egy régi tartozásomat pótolom. Aki próbált már magyar nyelvű PDF dokumentumot generálni, akár Java, akár más programozási nyelven, belefuthatott abba a problémába, hogy az ékezetes karakterek rosszul jelentek meg.

Ebben a posztban azt mutatom meg, hogyan lehet ékezetes karaktereket helyesen megjeleníteni olyan eszközökkel, mint az iText, PDFBox vagy a DocBook (Docbkx Tools használatával). De ha már itt tartunk, megnézzük, hogy mik is azok a betűtípusok, hogyan lehet osztályozni, milyen főbb betűtípusok vannak, valamint hogyan lehet ezeket használni PDF dokumentumban. Megnézzük hogyan épül fel ebből a szempontból egy PDF dokumentum, mi a kódolás, és milyen kódolást kell használni.