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ę.

Ten wpis powinien mieć chyba ładniejszy tytuł, ale jakoś nic lepszego nie przychodzi mi do głowy. Jest o czynnikach bezpieczeństwa i pewnych mitach z nimi związanych.
W czwartek 22 października, w ramach JAVIPS online, miałem niekłamaną przyjemność wzięcia udziału w zlocie tytanów, których przedstawiać nikomu nie trzeba
W dawnych mrocznych czasach musieliśmy czekać 3-4 lata, by zobaczyć nową wersję Javy ze zmianami w API, składni i JVM. Obecnie mamy dwa duże wydania każdego roku! Czy możemy korzystać z tych wydań przed pojawieniem się kolejnego LTSa? Chcesz wiedzieć, co się wydarzyło od czasu Javy 11? Rekordy? Wyrażenia switch? Pattern matching? Jakieś zmiany w NullPointerException? Nowe funkcje w API? O co chodzi z Shenandoah i ZGC? AppCDS, żeby przyspieszyć start?
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: ZGC i Shenandoah w gotowości produkcyjnej (jeśli kto nie lubi epok lodowcowych) dopasowaniu do wzorca z instanceof (zwane również smart casting) klasach zapieczętowanych (czyli nowym wymiarze widoczności typów) klasach ukrytych (tak bardzo, że same siebie nie widzą) blokach tekstowych, które pozwalają łatwo deklarować napisy bardziej skomplikowane od “Hello World!
W jednym z moich poprzednich wpisów traktowałem Java™ Records Lombokiem. Po otrzymaniu wielu zachęcających komentarzy (“co za chory pomysł, szacunek!"), prezentowaniu “Java 15. Nowości godne uwagi” i paru dyskusjach na kanale JVM Poland, pora na kolejne tortury. Sorry ;-)
W poprzednim wpisie nie było pogłębionej analizy shebang. Ściśnijmy zatem tę cytrynkę i zobaczmy, co z tego wyjdzie w JavaScript(s). Czy w da się zapisać shebang tak, żeby skrypt działał zawsze i wszędzie?
Niektórzy ludzie są zszokowani, że można obecnie pisać skrypty (które da się uruchomić w terminalu) nie tylko w Bashu, Perlu, Pythonie czy PHP, ale także w Javie.
Konkurs już się zakończył, nagrody zostały przyznane… I choć szkolenia toczą się nadal swoim trybem, to można już chyba bez obaw opublikować rozwiązanie prostej zagadki. I okrasić stosownym komentarzem.
W czasie moich aktywności online dotyczących tłumaczenia rekordów parę osób rzuciło podkręconą piłkę “no a Lombok?” W szczególności pytanie przybiera formę “skoro rekordy są immutable, to czym się różnią od @Value z Lomboka?”
Na okoliczność wydania Javy 14 widziałem parę dyskusji przebiegających mniej więcej takim stylu: - O, rekordy w Javie, fajnie, w końcu mamy automatycznie generowane settery i gettery! - Nie, rekordy w Javie to POJOs bez setterów… - A, okay… Fajnie, w końcu mamy w Javie generowane Beany, ale bez setterów!

Wybór języka