Wybór języka

W moim ogródecku…

Dlaczego w ogóle Software Garden, co to znaczy?

Jeśli szukasz odpowiedzi na pytanie czym jest Software garden, to wydaje mi się, że nie znajdziesz lepszego wytłumaczenia niż koncepcja (którą przeczytałem kilka lat temu) oryginalnie wyłożona w książce Pragmatyczny Programista Andrzeja Hunta and Dawida Thomasa.

Istnieją takie książki, filmy, obrazy, etc., które rewolucjonizują nasz sposób myślenia w pewnych obszarach. Wiele osób wyciągnęło ciekawe wnioski z tej inspirującej książki: jedni zaczęli gotować żaby, inni gadać do gumowej kaczki… Ja wychowywałem się blisko natury, dlatego moim zdaniem oprogramowanie przez nas tworzone i wykorzystywane dużo bardziej przypomina ogród niż budownictwo czy jakieś maszyny. Na swój sposób ono żyje. Nigdy nie jest w pełni ukończone. Cały ekosystem dookoła podlega ciągłym zmianom. Modlimy się o deszcz. Pory roku zmieniają się po sobie. Potrzeba miejsca na nowe rośliny. Trzeba się pozbywać pasożytów, żeby było co jeść. Nie można co tydzień wszystkiego zaorać i zaczynać od nowa. I tak dalej…

Dlatego przed kilku laty zmieniłem opis mojego stanowiska z “Programista” lub “Inżynier oprogramowania” na “Software Gardener” (choć z wykształcenia jestem właśnie inżynierem programistą i mam na to papier). Oczywiście ludzie, którzy nie przeczytali Pragmatycznego Programisty, są czasem zmieszani lub zakłopotani. Z drugiej strony pozwala mi to bez słów porozumieć się z tymi paroma osobami (a spotkałem takie), które na wizytówce mają również napisane “Software Gardener”. Coś za coś.

Ta strona to taka internetowa reprezentacja mojej niekończącej się podróży w Ogrodnictwo Programowania. To nie jest wielkoobszarowa farma z monokulturą. To mój mały ogródek, z roślinkami o które staram się dbać, z ptakami śpiewającymi nad głową i z paroma robalami pewnie też. Rozgość się, proszę.

Piramidy w Egipcie zostały zbudowane w starożytności. Do dziś je podziwiamy, doceniając rzemiosło i ciężką pracę ich budowniczych. Jednak czy budujemy dzisiaj domy z olbrzymich bloków kamieni? Niewątpliwie nie, obecne czasy przynoszą inne potrzeby i oferują inne technologie.

Piramidy testowania zostały również zbudowane jakiś czas temu. Podziwiamy projekty dziedzictwa z bogatym zestawem testów, ale czy tworzymy dzisiaj projekty w taki sam sposób jak 10-15-20 lat temu? Jeśli nie, dlaczego wciąż chcemy je testować w ten sam sposób?

Podczas moich szkoleń i wykładów padają pytania “ale jak ty tak szybko przełączasz Javę?” albo nawet “to da się mieć kilka wersji Javy równocześnie na komputerze?!” Jeszcze jak!

Sposób jest bardzo prosty: wykorzystać SDKMAN! Korzystam z niego niemal każdego dnia, przydaje się nie tylko w czasie prelekcji o najnowszych wersjach Javy, ale w zwykłej codziennej pracy, gdy trzeba sprawdzić “jak to działa na innej wersji”.

Poniższy minikurs powstał jakiś czas temu m.in. jako tzw. prework przed szkoleniem z najnowszej Javy.

Podczas moich szkoleń i wykładów padają pytania “ale jak ty tak szybko przełączasz Javę?” albo nawet “to da się mieć kilka wersji Javy równocześnie na komputerze?!” Jeszcze jak!

Sposób jest bardzo prosty: wykorzystać SDKMAN! Korzystam z niego niemal każdego dnia, przydaje się nie tylko w czasie prelekcji o najnowszych wersjach Javy, ale w zwykłej codziennej pracy, gdy trzeba sprawdzić “jak to działa na innej wersji”.

Poniższy minikurs powstał jakiś czas temu m.in. jako tzw. prework przed szkoleniem z najnowszej Javy.

W poprzednim wpisie testowaliśmy, czy Wątki Wirtualne Javy nie są używane w sposób, który powoduje ich przyszpilenie/przypięcie (ang. pinning). Chcemy bowiem (i aczkolwiek!), aby nasze Wątki Platformowe (szczególnie te w puli ForkJoin Sp. z o.o.) stale obsługiwały coraz więcej nowych Wątków Wirtualnych, zamiast “nie wyłączać silnika”, podczas gdy VTs są przyszpilone. (Przynajmniej tak długo, jak nie możemy dostarczyć własnych pul wątków do przenoszenia WW).
Spoiler alert: będziemy korzystać z Testcontainers oraz Toxiproxy!

Fun will now commence

Niestety, tłumacz aktualnie jest mocno zarobiony i na razie nie da rady przetłumaczyć tego wpisu. Całość dostępna po angielsku.

Jak włączyć Wątki Wirtualne?

W czasie moich wykładów, gdzie omawiana jest Java 19 (i gdzie obowiązkowo pojawia się sekcja dotycząca Wątków Wirtualnych), padało pytanie: jak włączyć wątki wirtualne na JVM przynajmniej kilka razy.

Niestety, tłumacz aktualnie jest mocno zarobiony i na razie nie da rady przetłumaczyć tego wpisu. Całość dostępna po angielsku.

You shall not pin Virtual Threads!

Kiedy mam czas, aby mówić o Javie przez ponad godzinę, jest to Deep Dive (nazywam to “Nowości godne uwagi”). Kiedy mam mniej niż czterdzieści minut, możemy ledwo dotknąć powierzchni, stąd nazywa się to wtedy “Surfing Modern Java”. Wszystko pomiędzy, taki normalny wykład, to więcej niż surfowanie, ale mniej niż głębokie nurkowanie, stąd “Sailing Modern Java”.

Podczas takiego wykładu zazwyczaj omawiam jedno lub dwa najnowsze wydania, czasami wspominając o tym, co nas czeka, starając się przemycić jak najwięcej przykładów kodu.

Bądźmy szczerzy: na Wątki Wirtualne (ang. Virtual Threads) czekaliśmy dość długo. Czekaliśmy z niecierpliwością, widzieliśmy zmieniające się nazwy (to nie są fibers ludziska), ale oto wreszcie są: Wątki Wirtualne.

Niektórzy twierdzą, że Project Loom jest największą zmianą w Javie od czasu wersji 8, lambd i strumieni. Inni uważają, że jest to jeszcze większa zmiana. Odkładając dyskusje na bok, zapowiada się na wielką zmianę.

Pamiętam, jak byliśmy podekscytowani (byłem wtedy jeszcze na studiach), że w końcu możemy używać prawdziwych wątków w Javie na Windowsie. Jednak czas leci, branża się zmieniła, sprzęt się zmienił, sposób, w jaki budujemy nasze systemy, również się zmienił. Choć znaleźliśmy sposoby na obejście ograniczeń “jeden wątek systemowy na jeden wątek Javy”, to jednak miało to swoją cenę: zagmatwane stosy wywołań i trudne debugowanie to pierwsze, co przychodzi na myśl. Wątki Wirtualne mają za zadanie utrzymać nas w nuuuuudnym, ale łatwym do zrozumienia modelu wątek-na-żądanie (ang. thread-per-request), jednocześnie odblokowując moc krzemu poniżej.

Minęło kolejne pół roku, pora na wdrożenie kolejnej wersji Javy™ na produkcji. Tym razem na pewno, bo to w końcu LTS. ;-)

Zdaniem wielu “Java jest wolna”. Okazuje się, że rozwój Javy jest tak “wolny”, że kolejne wydania nie są tylko podbiciem wersji, bo mogą znacząco zmieniać reguły gry. To dobry powód na kolejny deep dive w Javie. Będzie mowa o:

  • Pattern Matching for switch,
  • Record Patterns,
  • Virtual Threads,
  • Simple Web server,
  • co wyleciało i wyleci,
  • i innych.

Dużo rzeczy pokazane w kodzie, nie tylko na slajdach.

“Nie jesteś w stanie zrozumieć języka, zanim nie zrozumiesz przynajmniej dwóch”. – Geoffrey Willans

Przez lata programowałem głównie w językach działających na JVM. Czasem w innych językach wywodzących się z C, co było ciekawe i zarazem dość łatwe.

Kilka miesięcy temu (ze względu na zmianę pracy) musiałem się szybko nauczyć programować w Go. Co prawda słowa kluczowe w Go wyglądają podobnie do tych z C, jednak wiele koncepcji jest innych, wręcz niespotykanych w innych językach wywodzących się z C, szczególnie tych zorientowanych na obiekty. Nauka Go to świetna przygoda, a najlepsze są w niej te chwile AH-HA, gdy robiąc coś w Go, można nagle zrozumieć Javę lepiej.

Java jest naprawdę świetna, gdy trzeba napisać program “Hello, World!” Jest również genialna dla wyrafinowanych systemów i algorytmów, pod warunkiem, że ich autorzy piszą kod, który przestrzega kilku dość prostych umów i unika oczywistych pułapek.

Istnieje kilka mantr dotyczących najnowszych cech współczesnej Javy, takich jak:

  • rekordy mogą wszędzie zastąpić JavaBeans
  • nigdy nie musisz pisać hashCode() dla rekordów
  • dopasowanie wzorca za pomocą instanceof jest najlepszym narzędziem dla equals()
  • po prostu zignoruj --illegal-access lub ustaw go na permit
  • synchronize (new Long(42)) jest najlepsze dla monitorowania i tak dalej.

Do tej pory prezentacja pojawiła się w trakcie jLove, Doing Java Better oraz Java Day Lviv.