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.

Czytaj dalej „Konsola: sprytne przeklejanie argumentó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.

Czytaj dalej „Vim jako edytor Gita”

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”

Jak Kotlin wypada w codziennej pracy

Ponieważ od listopada zarabiam na chleb pisząc prawie wyłącznie w Kotlinie, czuję się wreszcie uprawniony do podzielenia się opiniami, jak ten język sprawdza się w poważnej pracy. Kotlina używam dłużej, ale wcześniej tworzyłem w nim kod dla moich prywatnych projektów – nie były to warunki, żeby wydać rzeczową ocenę. Codzienna zespołowa praca nad kodem pozwala rozpoznać rzeczy naprawdę usprawniające kodowanie, a nie tylko wyglądające fajnie na papierze. Z drugiej strony ujawnia niedoróbki.

To nie będzie artykuł z gatunku „kompletne porównanie Kotlina z Javą w 10 częściach” ani „jak mam zacząć programować w Kotlinie”. Łatwo takie znaleźć w wyszukiwarce, plus dokumentacja Kotlina jest świetna i czytając ją można znaleźć odpowiedzi na powyższe dwie kwestie. Napiszę tu o wybranych rzeczach, które subiektywnie dla mnie są najbardziej wyraźne i ciekawe. Nie będzie nic o programowaniu na Androida, bo się na tym nie znam – skupię się na tym, w czym mam doświadczenie, czyli pisaniu back-endu.

Czytaj dalej „Jak Kotlin wypada w codziennej pracy”

Czas Mavena minął

Aż ciężko uwierzyć, jak mocno ludzie potrafią trzymać się rozwiązań, które kiedyś podbijały rynek i ułatwiały życie, a obecnie są już tylko groteskowym reliktem przeszłości i hamulcem rozwoju. Japończycy cały czas używają faksów, Amerykanie czeków, a programiści Javy — Mavena. Od razu trochę sprostuję, żeby nie być niesprawiedliwym w ocenach: przywiązanie do czeków może nie być takie złe, bo zapewne nie pozwala na społeczne wykluczenie ludzi, którzy mają kłopoty z nauczeniem się korzystania z komputerów lub są zbyt biedni, żeby z łatwo z nich korzystać. Skupmy się jednak na programowaniu.

Czytaj dalej „Czas Mavena minął”

Funkcyjna obsługa błędów w Kotlinie i Javie

Czasem obsługa błędów jest prosta, „zerojedynkowa”: albo operacja się powiedzie, albo rzuci wyjątkiem. Mamy jednak też sytuacje, gdy od strony biznesowej podejście „wszystko albo nic” nie ma sensu i oczekiwane jest działanie w trybie „best effort”. Na wejściu jest zestaw danych, wykonujemy na nich operacje, jeśli w trakcie pojawiają się błędy, to po prostu idziemy dalej i próbujemy doprowadzić do końca tak wiele, jak się da, nie wycofując się z niczego. Nie mówimy o beztroskim ignorowaniu błędów: nawet jeśli zgadzamy się na częściowe niepowodzenie, dobrze jest wiedzieć, które z danych były przetworzone pomyślnie, a które z błędem. Jak zaprogramować takie podejście w sposób czytelny i jasno przekazujący intencję?

Imperatywne podejście (try-catch) w naturalny sposób modeluje sytuację zerojedynkową. Żeby zamodelować wersję „best effort” musimy myśleć w sposób bardziej funkcyjny, potraktować zarówno operację do wykonania jak i błąd jako byty na równi z danymi. Będziemy „kolekcjonować” błędy, żeby móc później zanalizować, ile ich było.

Języki nastawione na programowanie funkcyjne ułatwiają tu sprawę, ponieważ mają sprawdzone i dobrze opisane rozwiązania. Przykładowo Scala ma w bibliotece standardowej typ Try. Kotlin i Java nie są językami tradycyjnie wykorzystywanymi w sposób funkcyjny — nie oznacza to, że nie da się działać w nich w analogiczny sposób, jedynie to, że może być trudno znaleźć odpowiedź, jak do tego podejść.

Czytaj dalej „Funkcyjna obsługa błędów w Kotlinie i Javie”

Praca ze schowkiem z linii komend

Efektywna praca ze schowkiem systemowym to nie tylko umiejętność szybkiego wciskania Ctrl+C i Ctrl+V — przydatna jest też na przykład wiedza, jak korzystać ze schowka w terminalu.

Warto oglądać dobrych programistów przy pracy, pozwala to nauczyć się rzeczy, o których istnieniu po prostu nie wiemy. Ostatnio uderzyło mnie to przy słuchaniu prezentacji twórców Springa — w pewnym momencie Rob Winch potrzebuje zakodować hasło, a potem wkleić je w jedno pole w IDE (patrz 30-sekundowy fragment nagrania). Do tej pory gdy miałem zrobić coś podobnego, uruchamiałem komendę wypisującą coś w terminalu, zaznaczałem tekst myszą i kopiowałem. Upierdliwa rzecz, trzeba oderwać ręce od klawiatury, można kliknąć w złym miejscu, a z dala od biurka, na przykład na chodzącym jak spróchniała deska touchpadzie Lenovo, taka prosta czynność staje się utrapieniem. Natomiast Rob wykonał po prostu w terminalu:

spring encodepassword password | copy

Jak możemy uzyskać coś takiego na naszej maszynie? Sprawa jest nieco skomplikowana, bo nie ma jednej metody dla wszystkich systemów.

Czytaj dalej „Praca ze schowkiem z linii komend”
Creative Commons License
Except where otherwise noted, the content by Piotr Kubowicz is licensed under a Creative Commons Attribution 4.0 International License.