Jedną z najlepszych zmian wprowadzonych przez wersję 5 JUnita są według mnie testy dynamiczne. Można z ich pomocą pisać testy parametryzowane. Jednak DynamicTest/TestFactory to coś więcej niż skopiowanie funkcjonalności znanej z TestNG czy Spocka. Siłą mechanizmu z JUnita jest, że mamy pełną programistyczną kontrolę nad produkowaniem przypadków testowych. Wcale nie trzeba o dynamicznym teście myśleć jako o liście czy tabelce danych. Niżej pokażę, jak ten mechanizm może dać krótszy i łatwiejszy do zrozumienia kod testowy. Jest w stanie pogrupować powiązane testy w lepszy sposób niż zagnieżdżony test @Nested.
Czytaj dalej „JUnit 5: DynamicTest i czytelne testy o jasnej strukturze”Kategoria: Po polsku
Slack: pisanie bez rozproszeń
Blokując powiadomienia jesteśmy w stanie uniknąć rozpraszania przez wiadomości otrzymywane na Slacka. Wszystko może jednak wziąć w łeb, jeśli przyjdzie potrzeba skontaktowania się z kimś. Otwarte po dłuższym czasie okienko atakuje przegapionymi wiadomościami i okazuje się, że przeglądamy je zamiast pisać.
Problem da się rozwiązać korzystając z istniejących od dawna możliwości Slacka: minimalizując niepotrzebne elementy. Podobna zasada może być zastosowana do pisania wiadomości przez Facebooka.
Czytaj dalej „Slack: pisanie bez rozproszeń”Dark mode w KDE i nie tylko
Niby środek lata, ale ostatnio przez gwałtowne zmiany pogody w środku dnia często mamy ciemno jak w nocy. Co może być wtedy lepsze niż tryb ciemny? Okazało się, że w moim Kubuntu 21.04 nie jest oczywiste, jak przestawić KDE w dark mode, więc postanowiłem, że to dokładniej opiszę. W dalszej części podzielę się instrukcjami „przyciemnienia” IntelliJ, Chrome’a i LibreOffice. Na koniec odpowiem, czy zwariowałem, skoro przełączam się między jasnym i ciemnym motywem.
Czytaj dalej „Dark mode w KDE i nie tylko”Wgląd w konsolowy pipe
Kontynuując temat sprawnego używania terminala. Czasem przy pisaniu pipe’a brakuje podglądu tego, co dzieje się między krokami:
curl http://localhost:8080/admins | awk get-username.awk | ./delete.sh
Łatwym sposobem wydrukowania danych na danym etapie jest użycie tee podłączonego do stderr:
curl http://localhost:8080/admins | awk get-username.awk | tee /dev/stderr | ./delete.sh
Bonusowy content: linki do materiałów do uczenia się obsługi shella.
Czytaj dalej „Wgląd w konsolowy pipe”Konsola: sprytne przeklejanie argumentów
Wpisujesz komendę w konsoli, uruchamiasz… i coś jest nie tak. Trzeba poprzednie polecenie zmodyfikować i odpalić ponownie. Co teraz? Wpisywanie wszystkiego od zera nie wchodzi w grę. Można pomóc sobie myszą, zaznaczać, kopiować, wklejać, dusić backspace – są jednak szybsze opcje, niewymagające odrywania rąk od klawiatury. Opowiem o nich, zaczynając od tych wspominanych w większości poradników (jak !! i !$), kończąc na rzeczach mniej znanych: odwoływaniu się do argumentów po indeksie i usuwaniu z nich rozszerzeń i fragmentów ścieżki. Opisywane mechanizmy działają w Zsh i Bashu. Część może uprościć pisanie skryptów.
Wyciąganie danych z YAML-a za pomocą yq
yq to konsolowe narzędzie do manipulacji YAML-em. Czemu warto je znać?
YAML jest teraz wszędzie – konfiguruje się nim pipeline’y CI, sposób deploymentu, pojedyncze aplikacje. Przewagą tego języka nad na przykład JSON-em jest możliwość unikania duplikacji przez zdefiniowanie powtarzającego się kodu w jednym miejscu i „dołączanie” go wielokrotnie. Mając konfigurację CI GitLaba:
.jvm_job: &jvm_job
image: openjdk:11-jdk-slim
.gradle_job: &gradle_job
<<: *jvm_job
tags:
- medium
check:
stage: test
image: openjdk:11-jdk
script:
- ./gradlew check
<<: *gradle_job
deploy_cit:
<<: *cit_variables
<<: *deploy_job
# a dookoła jeszcze tak z 50 różnego rodzaju jobów
możliwości YAML-a umożliwiają nam dzielenie konfiguracji joba na reużywalne kawałki i komponowanie z nich ostatecznych jobów. Z drugiej strony dużo trudniejsze staje się dla czytającego odpowiedzenie na pytanie, co tak właściwie robi dany job: we fragmencie wyżej mamy zarówno coś w rodzaju dłuższej hierarchii dziedziczenia (check) jak i coś w rodzaju wielokrotnego dziedziczenia (deploy_cit). Konfiguracja GitLaba definiuje prawie 30 parametrów konfiguracyjnych jobów, więc rzeczywiste pliki są zazwyczaj dużo bardziej skomplikowane niż przykład wyżej. Nagle od tego, czy umiem w głowie merge’ować spore struktury danych zależy to, czy wprowadzę błąd w konfiguracji, czy nie.
Idealnie byłoby, gdyby jakieś narzędzie wypluwało mi ostateczną postać pliku konfigurowaniu, po wstawieniu wszystkiego na miejsce i zmerge’owaniu. Tyle, że jest z tym bieda: taki GitLab na przykład chwali się w tym miesiącu wizualizacją pipeline’u generowaną z edytowanej konfiguracji, ale konkretnych parametrów tam nie ma. Jeśli ciekawi mnie, jaki image będzie użyty w jobie check, wizualizacja GitLaba nie przybliży mnie ani o krok do odpowiedzi. Tak w ogóle to odpowiedź brzmi: nie ten image, jaki zamierzył sobie autor kodu, więc pewnie wszystko nie działa.
Ogólnie: systemy przyjmujące YAML-ową konfigurację często nie oferują dobrej możliwości zrozumienia skutków zaaplikowania tej konfiguracji. Dobrze jest znać więc coś niskopoziomowego, nieprzywiązanego do tej czy tamtej aplikacji, coś, co potrafi operować na dowolnym YAML-u, niezależnie od jego przeznaczenia.
Czytaj dalej „Wyciąganie danych z YAML-a za pomocą yq”Koniec z git-checkout
Git to obecnie w zasadzie synonim systemu kontroli wersji – mało kto dzieli się otwartym kodem w inny sposób, ale też przy pracy nad zamkniętym komercyjnym kodem coraz rzadziej widzi się inne rozwiązania. Ważąc wszystkie za i przeciw, jest to prawdopodobnie bardzo pozytywna zmiana, jeśli przypomnieć sobie z jakimi potworkami zmuszeni byli nie tak dawno temu pracować programiści. Tyle że biorąc Gita za coś oczywistego możemy zacząć zapominać o jego wadach – a nie jest to idealny system kontroli wersji. Narzędzie stworzone przez Linusa Torvaldsa było chyba od początku mocno krytykowane za user experience: że ma dziwną logikę, podporządkowaną bardziej sposobowi działania samego oprogramowania, a nie temu, jak pracę z wersjami widzi człowiek. Najmocniej przejawia się to w komendach, które robią kilka bardzo odległych koncepcyjnie rzeczy w zależności od podanych argumentów. Na przykład checkout: czasem odrzuca niezacommitowane zmiany w plikach, a czasem zmienia gałęzie.
Znalazłem ostatnio instrukcje, jak pozbyć się git checkout, korzystając z nowych poleceń switch i restore. W dalszej części opowiem, czemu warto tak zrobić i jak wygląda praca na nowy sposób.
Czytaj dalej „Koniec z git-checkout”3 najbardziej pouczające materiały z 2020
Prezentuję moje podsumowanie minionego roku w takiej formule jak poprzednio: najciekawsze materiały o programowaniu na jakie trafiłem, bez trzymania się jednego ustalonego medium. Tym razem wybrałem książkę, odcinek podcastu i nagranie wideo.
Czytaj dalej „3 najbardziej pouczające materiały z 2020”Vim jako edytor Gita
Najczęściej w pracy do tworzenia commitów używam IDE IntelliJ. Jest to naprawdę świetne narzędzie: pozwala w jednym oknie dialogowym przejrzeć jeszcze raz diff zmian, pominąć niektóre pliki albo nawet części plików, sprawdza pisownię, podpowiada poprzednie opisy zmian. Czasem jednak zdarza mi się tworzyć commity bezpośrednio z linii komend — zwłaszcza gdy projekt nie jest pisany w Javie/Kotlinie, nie chce mi się czekać na kobyłę, jaką jest IntelliJ — zmieniam coś prostym edytorem tekstowym lub graficznym i odpalam wprost git commit. Domyślnie w Ubuntu przy tworzeniu commitu otwiera się bardzo prosty edytor nano. Ja sam używałem nano z Gitem od wielu lat, od pół roku jednak opisy zmian i podobne teksty zmieniam w Vimie. Napiszę teraz krótko, czemu moim zdaniem to świetny wybór i co ustawić, żeby dać szansę takiej kombinacji.
Kubuntu 20.04: Long Term Support a zaczyna z poważnymi błędami
Ubuntu 20.04 aktualizuje się łatwo i przyjemnie, od strony obsługi programów (KDE) działa dobrze, natomiast obsługa sprzętu kuleje tak, jak w Ubuntu nie pamiętam od dawna. Jeśli ktoś planuje podbicie wersji systemu – polecam jeszcze poczekać. Zwłaszcza, jeśli używa laptopa firmy Dell.
Czytaj dalej „Kubuntu 20.04: Long Term Support a zaczyna z poważnymi błędami”