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”

Dzielenie się testowymi klasami pomocniczymi w Gradle’u

Czasem mamy przypadek, że piszemy test jednostkowy jakiejś klasy i okazuje się, że część kodu testowego może być przydatna w innych częściach naszego projektu. Jak udostępnić ten kod, żeby był widoczny zarówno w testach aktualnego projektu, jak i w testach projektów od niego zależnych? Gradle od wersji 5.6 udostępnia dla tego celu plugin java-test-fixtures.

Czytaj dalej „Dzielenie się testowymi klasami pomocniczymi w Gradle’u”

Importy nieprzerywające pracy w IntelliJ

Do niedawna nienawidziłem przeklejania kodu do IDE. Nie dlatego, żebym uważał, że prawdziwemu programiście nie wypada robić copy-paste ze Stack Overflow (to bzdura). Cierpiałem na samą myśl, że będę musiał dodać importy do wszystkich użytych w tym fragmencie klas, ponieważ normalnie w IntelliJ jest to niewygodne. Dobra wiadomość: istnieje wbudowana opcja, która pozwala ułatwić sobie życie — ale domyślnie jest wyłączona. W dalszej części pokażę, jak ustawić swoje IDE do wydajnej pracy z importami. Na samym końcu będzie krótka dygresja o modelach mentalnych dla programistów.

Czytaj dalej „Importy nieprzerywające pracy w IntelliJ”
Creative Commons License
Except where otherwise noted, the content by Piotr Kubowicz is licensed under a Creative Commons Attribution 4.0 International License.