Kategoria: Po polsku

Wyciszanie śmiecących logów Springa przy kończeniu testów

Wielowątkowe testy (takie jak używające Kafki) są źródłem kłopotów. Na przykład zaśmiecają przebieg buildu w Gradle’u.

Normalnie Gradle przechwytuje stdout i stderr z testów, przerzuca je do raportów HTML-owych, a terminal zachowuje czysty:

> Task :my-module:testClasses
> Task :my-module:test

Moduły korzystające ze Springa i uruchamiające wiele wątków potrafią kompletnie zabić czytelność terminala:

> Task :my-module:testClasses
INFO [ntainer#0-0-C-1] o.a.k.c.c.internals.ConsumerCoordinator  : [Consumer clientId=consumer-my.event-2, groupId=my.event] Revoke previously assigned partitions my.event-0, my.event-1, my.event-2
20
ERROR [sson-netty-1-15] i.n.u.c.D.rejectedExecution             : Failed to submit a listener notification task. Event loop shut down?
java.util.concurrent.RejectedExecutionException: event executor terminated
	at io.netty.util.concurrent.SingleThreadEventExecutor.reject(SingleThreadEventExecutor.java:934)
> Task :my-module:test

Łatwo może się zdarzyć, że dostaniemy ponad 100 niechcianych śmieciowych linii.

W dalszej części artykułu objaśnię, co w działaniu biblioteki spring-test powoduje taki zgrzyt w integracji z Gradle’em. Zaproponuję też obejście problemu za pomocą specjalnego beana wyłączającego część logowania.

Czytaj dalej

Pułapki transakcji Springa dla programistów Kotlina

Wydaje się, że Spring i Kotlin to dobre połączenie. Z jednej strony najbardziej popularny framework dla Javy, ale deklarujący wsparcie dla języka od JetBrains. Z drugiej Kotlin został zaprojektowany dla jak największej kompatybilności z Javą. Na papierze i w ogłoszeniach na social mediach wszystko gra. Tyle że w rzeczywistości można bardzo nieprzyjemnie się zaskoczyć, niestety zazwyczaj dopiero na produkcji.

Problem będący głownym bohaterem tego artykułu leży w różnym podejściu do wyjątków w obu światach.

Pisząc w Kotlinie można zapomnieć o dyskusjach programistów Javy, czy wyjątek ma być checked czy nie. Jeśli w repozytorium piszemy wyłącznie w jednym języku, wszystko nam jedno i nie trzeba sobie tym zawracać głowy. Chyba że kod działa w Springu. Wtedy brak uwagi kończy się zobaczeniem UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only. Zgodnie ze słowami 'unexpected’ i 'silent’, jest to sytuacja zaskakująca, a do tego upierdliwa w zdiagnozowaniu.

Czytaj dalej

ArchUnit czy Konsist: testy architektury dla Kotlina

Posiadanie w projekcie testów architektury (architecture tests) powoli staje się czymś oczekiwanym. Użytkownicy Kotlina od niedawna mają problem bogactwa wyboru. Mogą użyć biblioteki ArchUnit, już ustabilizowanej, całkiem szeroko znanej, stworzonej dla Javy, ale działającej też dla Kotlina. Pojawiła się jednak alternatywa. Konsist to narzędzie napisane specjalnie pod Kotlina, o krótszej historii, ale zdobywające popularność.

W dalszej części artykułu porównam ze sobą te biblioteki. Nie będę kopiował haseł reklamowych: zawodowo używam obu od ponad roku, więc mam sporo obserwacji natury praktycznej.

Po lekturze będziesz (mam nadzieję) wiedzieć, czy do twojej sytuacji bardziej będzie pasować ArchUnit, czy też Konsist, a może potrzebujesz obu.

Moim celem jest porównanie, więc nie omówię wszystkich cech obu narzędzi i będę się streszczał. Spragnionym szczegółów na temat konkretnej biblioteki polecam moje wcześniejsze artykuły: wprowadzenie do ArchUnita, wprowadzenie do Konsista.

Artykuł jest skierowany do programistów Kotlina. Jeśli programujesz tylko w Javie, to z Konsista nie skorzystasz, bo obsługuje tylko język od JetBrains. Mimo wszystko, polecam pod uwagę wyliczenie niedostatków ArchUnita – nie podaję tu lepszego narzędzia do Javy, ale moim zdaniem lepiej znać wady swojego narzędzia, niż ich nie znać.

Czytaj dalej

Konsist – rzut oka na nowe testy architektury dla Kotlina

Biblioteka Konsist to nowy gracz na rynku narzędzi dla Kotlina. Umożliwia tworzenie testów architektury, ale zarówno sposób pisania, jak i zasada działania różnią się mocno od najpopularniejszego dotychczas narzędzia w świecie JVM, czyli ArchUnita. W tym artykule pokażę krótko, jak wygląda używanie Konsista w praktyce.

Nie lubię nazwy „testy architektury”, bo kojarzy mi się z architektem-mądralą, który pilnuje, czy warstwy zgadzają się z jego podręcznikiem, albo czymś równie oderwanym od realnych problemów. Jednak innej nazwy nie mamy, więc zostaje mi tylko zapewnienie, że takie testy mogą mieć bardzo konkretne, życiowe użycie, a pisać może je każdy, nawet jeśli nie ma „principal senior lead architect” w tytule zawodowym. To taki linter z regułami, które sami piszemy. Warto umieć je pisać, nawet jeśli jest się juniorem.

Nie będę kopiował strony domowej Konsista. Moje przykłady pochodzą z prawdziwych, zawodowych projektów, jakie tworzę. Są tylko trochę uproszczone.

Ten artykuł ma zamiar być krótkim wprowadzeniem, żebyście lepiej zrozumieli, co bierzecie albo czego będziecie odtąd unikać. Nie będę porównywał Konsista z ArchUnitem. Napisałem o tym osobny tekst. Nie będę też omawiał każdej możliwości Konsista. Od tego macie oficjalną dokumentację.

Czytaj dalej

ArchUnit – praktyczne zastosowanie

W artykule o podstawach ArchUnita przedstawiłem, jak i po co pisać testy architektury. Być może znasz temat, ale wciąż nie jesteś do końca przekonany (-a). Lub takie testy masz, ale nie są rozwijane, a nikt nie wie, co i w jakim celu do nich dodawać.

Poniższy tekst dostarcza konkretne, życiowe przykłady użycia. Są to zastosowania z innej bajki niż to, co podaje jako „use cases” oficjalna strona ArchUnita albo clickbaitowe „tutoriale” w stylu tych na Baeldungu (nie linkuję, nic nowego nie wnoszą).

Pokażę, jak stosuję ArchUnita do wykrywania pomyłek w testach. Oraz do wykluczania kodu, który źle działa w Kotlinie: Optional.orElse oraz adnotacji z jakarta.annotation.

Mam nadzieję, że te przykłady pomogą ci lepiej zrozumieć potencjał testów architektury, oraz dostarczą nowych inspiracji do pisania własnych, dostosowanych do potrzeb twojego projektu. Możesz też podany tu kod po prostu skopiować do siebie (udostępniam go na licencji MIT).

Czytaj dalej

Quartz czyli scheduling ze śmietnika historii

Quartz to narzędzie, które jest niestety popularnym wynikiem przy wyszukiwaniu haseł „scheduler”, „job”, „Java”. Strona domowa projektu tytułuje się „Enterprise Job Scheduler”. „Enterprise” ma sugerować, że to rozwiązanie poważne, więcej: skalowalne na duże projekty. W ramach wzbogacenia dyskusji chciałbym dorzucić inną opinię: że Quartz to niebezpieczny szrot, którego nieusuwalne wady mogą zarżnąć waszą produktywność i spowodować incydenty na produkcji.

Przejdziemy od kodu z błędami N+1 zapytań, przez alarmujący stan projektu, do architektury z single point of failure.

Czytaj dalej

Resetowanie i testowanie połączenia sieciowego z linii komend

Być może tak jak ja masz sieć bezprzewodową, która czasem wariuje i połączenie pada. Pomaga zaś proste rozłączenia się i połączenie ponownie. Nie mogę obiecać pewnego sposobu na uporanie się z każdą możliwą przyczyną takiego stanu, ale mogę podzielić się linuksowym skryptem, który pozwala zredukować do minimum ręczne czynności. Użyjemy nmcli, czyli konsolowego interfejsu do Network Managera. Przy okazji trzeba jednak uważać, by nie popsuć sobie kontenerów Dockera.

Wyjaśnię też, czemu warto używać curla (a nie pinga) do testowania dostępności sieci, zarówno na własnej maszynie, jak i w kontenerach Dockera na CI.

Czytaj dalej

Sonar dla Kotlina nie ma sensu

Sonar reklamuje się obsługą Kotlina, ale co reklamy i dokumentacja przemilczają, to bardzo niska użyteczność sugestii, jakie oferuje dla tego języka.

Jeśli ktoś nie wie, o co chodzi: to popularne narzędzie do znajdowania problemów w kodzie. W marketingu pojawia się też jako SonarQube i SonarCloud. Ma opinię sprawdzonego „industry standard”. Jest duża szansa, że jeśli ktoś rzuci problem „potrzebujemy narzędzia do static analysis”, to od razu padnie sugestia „weźmy Sonara”. Czy słusznie? To zależy. Jeśli stawiamy na Kotlina, to nie.

W dalszej części artykułu skupię się na konkretnym zastosowaniu Sonara: do projektów napisanych w Kotlinie. Jeśli szukacie informacji jak odpalić SonarQube dla Javy – przykro mi, nie tu. Co jeszcze będzie? Podam linki, dzięki którym samodzielnie zweryfikujecie aktualną sytuację (nawet w wypadku, gdybym przestał aktualizować ten artykuł). Podzielę się też subiektywnymi wrażeniami o tym, jak deweloperzy i deweloperki Sonara radzą sobie z problemami w integracji z Gradle’em.

Czytaj dalej

Najciekawsze programistyczne materiały w 2023

Podsumowanie będzie składać się z dwóch części. W pierwszej wymienię nagranie, książkę i tutorial na stronie internetowej, które zrobiły na mnie w minionym roku największe wrażenie.

W drugiej będą artykuły mojego autorstwa, które wzbudziły wasze największe zainteresowanie.

Podsumowania z poprzednich lat znajdziecie pod tagiem podsumowania.

Czytaj dalej

editorconfig na CI – automatyczna weryfikacja jednolitego stylu

Większość języków programowania ma swój style checker tudzież linter. Czy to wystarcza? Jeśli do tej pory w repozytorium miałeś/aś tylko CheckStyle, to mam zamiar przekonać Cię, że warto dorzucić też plik .editorconfig. Napiszę też, czemu należy standard editorconfig wspierać na serwerze CI i jak to zrobić – moją propozycją jest narzędzie editorconfig-checker. Jego największą zaletą jest niezależność od typu naszego projektu. Czy to rozbudowana aplikacja w Javie albo TypeScripcie, czy repozytorium zbierające luźno powiązane skrypty w Pythonie i Bashu – zawsze będzie przydatne.

Mnie do wpięcia tego narzędzia do continuous integration przekonała typowa sytuacja – w pewnym repozytorium edytowałem dwa skrypty shellowe, w jednym ktoś narobił wcięcia spacjami, w drugim ktoś inny tabulacjami. Nie widać różnicy na pierwszy rzut oka, wstawiłem linijkę tu, linijkę tam. Patrzę w git diff, a tam moje linijki nie równają się z otoczeniem, do tego w zmianach pojawiło się \ No newline at end of file, czyli ktoś nie używał poprawnie ustawionego edytora tekstu. Potem znalazłem Dockerfile wcinany raz to spacjami, a raz to tabulacjami.

Czytaj dalej