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

Niedawno zobaczyłem gdzieś w mediach społecznościowych fragment kodu. Jak mniemam, miał pokazać, że “Java jest zła i martwa”. Myślę, że to dobry moment, żeby przyjrzeć się niektórym twierdzeniom, nieprawdom i półprawdom, które pojawiły się w komentarzach i nie powiem, nawet mnie rozbawiły. Przy okazji odpowiem na część zarzutów, które padły podczas kilku wykładów konferencyjnych jesienią (sprawdza kalendarz) 2026 roku!

TL;DR: kompaktowe pliki źródłowe już są z nami, obiekty value z Valhalli nadchodzą, możesz nadal tkwić mentalnie w 2005 roku, ale miej świadomość, który rok mamy teraz.

Zanim zacząłem pracować na pełen gwizdek jako developer advocate, nie spotkałem się z terminem BBL. Oczywiście samo przeczytanie tytułu tego wpisu zadaje kłam insynuacjom pewnych złośliwców, że jest to wyłącznie termin medyczny. Okazuje się, że niekoniecznie ;-)

Zatem: co to jest i co to nie jest ten BBL?

NoSQL for years was associated with JSON. The thing is: if you’re a hardcore backend Java developer, JSON, YAML, and other data formats might not feel native to you. Also, if you were ears-deep into debugging a query from Java code, sending the same request for visualization in Kibana using KQL wasn’t trivial. Meet ES|QL: Elasticsearch’s new query language, being at first glance a mixture of SQL and… Bash ;-) Works the same in Java and Kibana (and other programming languages too!) Additionally, by leveraging Project Valhalla and vector operations, ES|QL can achieve performance improvements over previous solutions. If you’re eager to investigate the options of the ES|QL and how it makes your life easier (while also giving a feel of being a SQL DB), this talk is for you.

Gdybym dostawał jednego dolara za każdym razem, gdy słyszę “musieliśmy wyłączyć security i uwierzytelnianie w Elasticsearch, bo inaczej nie dało się z tego korzystać”, to byłbym już parę dolarów do przodu ;-)

Prawdę mówiąc, to nie bardzo rozumiem, skąd bierze się to zamieszanie. Mamy 2024 rok, jednak niektórzy z nas są wciąż zaskoczeni przez “ale jak to certyfikat i hasło???”

Pozwólcie mi w paru prostych akapitach wyjaśnić temat security w Elasticserchu.

Do tej pory prezentacja była wygłaszana wyłącznie po angielsku. Chętnych na wersję polską zapraszam do kontaktu ;-)

Streams were a very nice addition to Java 8, based on lambdas. They allow streamlined data processing without side effects, taking us gently towards functional style. With newer additions to Java, like records and pattern matching, they shine even more in data-driven flows. However, they don’t come without flaws. For starters, the only available extension point was collectors: if your needs for gathering data weren’t satisfied by the whole Collectors ZOO, you could always fall back to creating your own Collector. However, if map, filter or flatMap weren’t enough, you couldn’t add your own intermediate operation. Secondly, parallel streams were limited to ForkJoin pool, effectively rendering them unusable for scenarios involving any IO. Since Java 22, Stream Gatherers are our extension point for intermediate operations in streams. If you’d like to comprehend how they work, find nice use cases and hunt for more performance, this talk is for you.

Oto Ty: programist(k)a Javy z pewnym doświadczeniem, a wszyscy wokół zdają się mówić tylko o LLM, NLP, RAG i innych rzeczach związanych ze Sztuczną Inteligencją. Z jednej strony trochę się tego boisz, ponieważ wśród tych skrótów nie ma JPA, a mówią, że SI może zabrać Ci pracę już w przyszłym miesiącu. Z drugiej strony jesteś też zmęczony/a, ponieważ każde wiadomości, każda platforma społecznościowa bombarduje Cię wszystkimi odmianami SI tak bardzo, że boisz się otworzyć lodówkę (kto wie, może SI jest już między jogurtami?)

Do tej pory prezentacja była wygłaszana tylko po angielsku. Jeśli ktoś byłby chętny na wersję po polsku, to zapraszam do kontaktu ;-)

Integration tests are nice. We all know that and love using them, don’t we? It’s just using all those databases, message brokers and other things as real dependencies, only wrapped by Testcontainers, might result in a really heavy CI/CD pipeline and developers’ attitude to never run them locally, because they’re so slooooooooooow. What if I could show you a number of techniques, mindset changes and tricks to get your integration tests shortened from quarters to seconds? Would that be interesting for you, to benefit from the confidence integrations tests give you, before you’re able to brew a fresh coffee? It’s really not about re-inventing the wheel, but using it the smart way.

Java 22 zostanie wydana jutro. W tej wersji jest wiele super rzeczy. Podejrzewam, że korzystanie z wywołań rodzimych/zewnętrznych w projekcie Panama sprawi, że życie wielu osób stanie się łatwiejsze, jak również trwające zmiany we współbieżności, szablonach napisów i wreszcie możliwość wywołania czegoś przed super. Super! Jednak jest jedna rzecz, która podejrzewam stanie się moim (prawie) ukrytym bohaterem Javy 22. Ludziska, przedstawiam wam Gatherers.mapConcurrent!

Strumienie są bohaterem Javy 8 (ale nie w świecie równoległym)

Java 8 była dużym kamieniem milowym w rewolucji Javy w swoim czasie. Pamiętam atmosferę po stosunkowo niewielkim wydaniu Javy 7, wersja 8 była NAPRAWDĘ WIELKA. Wprowadzenie lambd pozwoliło Stream API na istnienie w Javie 8 (bez krwawiących oczu, oczywiście). Moim zdaniem skierowało to Javę w stronę deklaratywnego i funkcyjnego sposobu myślenia o przetwarzaniu danych: zamiast pętli z pośrednimi wywołaniami i pakowania wyników w pojedynczy obiekt, mogliśmy wreszcie wyrazić intencję w bardziej deklaratywny sposób.

Wykład odbył się jak na razie tylko raz i tylko dla Silesia JUG w Katowicach, po angielsku. Chętnych na wersję polską zapraszam do kontaktu:

Let’s talk about Java 21 and have a sneak-peek into Java 22, and things like: Java was supposed “to be slow”. However, Java turns out to evolve so fast, that next releases aren’t just version bumps, but might significantly change the rules of the game. That’s a good reason to check out what’s new in Java. To name a few changes: