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ę.
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.
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. Była mowa o:
–illegal-access=deny, Sealed Classes, dopasowaniu wzorców w switch, z czym się żegnamy i z czym będziemy się żegnać, i innych.
Co myślę o Lomboku?
Wydaje się, że to ciekawa wyspa, chętnie bym tam kiedyś się wybrał.
Co myślę o Projekcie Lombok?
Cóż, zadano mi to pytanie tak wiele razy, że postanowiłem popełnić ten wpis. Głównie po to, żebym mógł wkleić odnośnik i wycofać się na z góry upatrzone pozycje, gdyż intensywność kolejnej dyskusji może wzrosnąć do poziomu wygrażania pięściami i toczących się głów… Poczyniłem trzy założenia:
To są moje opinie.
Wiele zmian, które obserwujemy w kolejnych wydaniach Javy (jeśli nie większość z nich), powstaje w ramach projektów grupujących / parasolowych. Często widzimy usprawnienia składni z projektu Amber, projekt Jigsaw przyniósł nam moduły, projekt Loom (uwaga, niespodzianka!) zajmuje się wątkami, projekt Panama, gerenalnie rzecz biorąc, jest o wydajnym i bezpiecznym wykorzystaniu metalu pod spodem. Spośród tych najbardziej znanych, projekt Valhalla też zaczyna do nas docierać, dzięki wydaniu JEPa-390 w ramach Javy 16.
W zeszłym roku poczyniłem dwa wpisy o torturowaniu rekordów w Javie Lombokiem. Na nasze (nie)szczęście (zależy, jak to widzisz), zespół Lomboka zdecydował się ukrócić nasze niecne zabawy. Jednakże nie składamy broni i tym razem idziemy po wzorzec budowniczego!
Minęło kolejne pół roku, kolejne wydanie nowej wersji Javy™ za nami. 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:
Rekordach: gdzie i jak ich użyć (poza DTO/VO) dopasowaniu do wzorca z instanceof (zwane również smart casting) klasach zapieczętowanych (czyli nowym wymiarze widoczności typów) ostrzeżeniach z projektu Jigsaw (–illegal-access kontratakuje!
W zeszłym roku poczyniłem dwa wpisy o torturowaniu rekordów w Javie Lombokiem. Na nasze (nie)szczęście (zależy, jak to widzisz), zespół Lomboka zdecydował się ukrócić nasze niecne zabawy. Jednakże nie składamy broni i tym razem idziemy po wzorzec budowniczego!
W czasie moich wykładów, gdy opowiadałem o rekordach w Javie, wielokrotnie padało pytanie: czy hashCode() w rekordach jest jakoś cache’owany?. Sprawdźmy to ;-)
Przeglądając media społecznościowe można odnieść wrażenie, że “wszyscy wiedzą”, że “jak masz rekordy w Javie 16, to nie musisz pisać equals() i hashCode()”. A gdybym tak powiedział Ci, że czasem jednak musisz…?
Po parunastu latach używania Linuksa zawstydziłem dziś sam siebie. Dość dużo czasu spędzam przed terminalem. I o ile nie jestem pewien, że znam wszystkie wykrętasy w Vimie (nie wspominając o Emacsie, ale dziś nie będzie o akurat tym systemie operacyjnym), o tyle wydawało mi się, że raczej potrafię korzystać z emulatora GNOME terminala. O święta naiwności! Dziś odkryłem nową funkcję, niezłą perełkę, więc postanowiłem podzielić się nią z Wami, razem z innymi dobrodziejstwami (może nie tak oczywistymi dla nowych w Linuksie), o które czasem bywam pytany po wykładach.
