Piotr

Nowy BIOS naprawił pracę na baterii i… klawiaturę

Lubicie aktualizować BIOS? Myślę, że dla wielu to czynność równie ekscytująca jak wizyta u dentysty. Może więc zaciekawi was historia, gdzie aktualizując BIOS w moim laptopie HP EliteBook nie tylko pozbyłem się freeze’ów przy pracy na baterii, ale też rozwiązałem problem, którego nigdy w życiu bym nie podejrzewał o związek z jakimikolwiek łatkami w oprogramowaniu. Wbudowana klawiatura ponownie zaczęła nadawać się do użytku. Do pozytywnych niespodzianek dorzucam pracę wyświetlacza, który w moim subiektywnym odczuciu daje czystszy obraz przy pracy z okienkami.

Co ciekawe, BIOS (a dokładniej UEFI) dał się zaktualizować bardzo szybko i wygodnie, nie był potrzebny nawet pendrive.

Czytaj dalej

Spring Kafka with Retry-After support

The Spring Kafka library provides error handling via a well-established exponential back-off mechanism. However, if the error is HTTP 429 “Too Many Requests” (that is, rate limiting), ordinary exponential increases in the delay between retries are a bit like a brute-force attack: we either waste resources by retrying too early, or waste time by waiting too long. It would be better to wait exactly as long as the server tells us to.

In the following sections, I will show how to approach the implementation. In short, it boils down to writing a single, uncomplicated class.

Czytaj dalej

Spring Kafka z obsługą Retry-After

Biblioteka Spring Kafka umożliwia obsługę błędów przez sprawdzony mechanizm exponential back-off. Jednak jeśli błędem jest HTTP 429 „Too Many Requests” (czyli rate limiting), zwykłe wykładnicze zwiększanie przerw między kolejnymi próbami jest trochę jak atak brute force: marnujemy zasoby na próbowanie przed czasem, albo marnujemy czas czekając za długo. Lepiej byłoby czekać dokładnie tyle, ile wysyła serwer.

W dalszej części pokażę, jak podejść do implementacji. W dużym skrócie, wystarczy napisanie jednej nieskomplikowanej klasy.

Czytaj dalej

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