Complete gig history
All talks by Piotr Przybyl
7 talks·7 with video·3 years
Loading talks…
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.
Java™ 21 is real now. And so are virtual threads. Everyone got excited about them, yet you prefer to keep your Java 8 job forever and you already have a nice plan to "accidentally" derail the migration to 21 by using virtual threads in a very, very unfortunate way. What a pity... So you decided to come for this talk to look for some inspiration 😉 Okay, please join us to learn how NOT to use virtual threads, and see the potential performance pitfalls of using them the wrong way.
The pyramids in Egypt were built in ancient times. We still admire them today, appreciating the craftsmanship and hard work of their builders. However, do we build houses from giant stone blocks today? Not likely, current times bring other needs and offer other technologies. Pyramids of testing were also built some time ago. We admire legacy projects with a rich set of tests, but do we create projects today the same way we did 10-15-20 years ago? If not, why do we still want to test them the same way? Maybe the shape of today’s projects' tests should no longer resemble a pyramid? Our needs are different, and the possibilities, thanks to the Testcontainers family of libraries, have also advanced a lot. If you have a feeling that integration testing can bring a lot to your project, but somehow you haven’t had the chance to get acquainted with Testcontainers so far, or you’re afraid that it’s just “magic for top developers”, this lecture is for you. We will quickly, easily and pleasantly rearrange the pyramids of our times 😉
🎙 Piotr Przybyl, Software Gardener @SoftwareGarden.dev 🔗 https://twitter.com/piotrprz ☑ Website: https://devoxx.com.ua/ ☑ Facebook: https://www.facebook.com/DevoxxUkraine ☑ Instagram: https://www.instagram.com/devoxxua/ ☑ Twitter: https://twitter.com/DevoxxUA ☑ YouTube: https://www.youtube.com/@DevoxxUkraine Devoxx Ukraine 2023 partners: 🫶 Platinum Partner & Organizer - EPAM Ukraine https://careers.epam.ua 🫶 Silver Partner - SPD Technology https://spd.tech/ 🫶 Streaming partner - Mediastream https://mediastream.com.ua/
For more info on the next Devoxx UK event 👉 www.devoxx.co.uk The pyramids in Egypt were built in ancient times. We still admire them today, appreciating the craftsmanship and hard work of their builders. However, do we build houses from giant stone blocks today? Not likely, current times bring other needs and offer other technologies. Pyramids of testing were also built some time ago. We admire legacy projects with a rich set of tests, but do we create projects today the same way we did 10-15-20 years ago? If not, why do we still want to test them the same way? Maybe the shape of today's projects' tests should no longer resemble a pyramid? Our needs are different, and the possibilities, thanks to the Testcontainers family of libraries, have also advanced a lot. If you have a feeling that integration testing can bring a lot to your project, but somehow you haven't had the chance to get acquainted with Testcontainers so far, or you're afraid that it's just "magic for top developers", this lecture is for you. We will quickly, easily and pleasantly rearrange the pyramids of our times 😉
For more info on the next Devoxx UK event 👉 www.devoxx.co.uk “You can never understand one language until you understand at least two.” - Geoffrey Willans For years I've been developing mostly in JVM languages. Sometimes in other C-derived languages, which was both cool and easy. A few months ago (due to career shift) I had to learn Go rapidly. While technically Go has keywords looking similar to C, many things are simply different and even unheard of in C-based OOP languages. Learning Go is a great journey and the best are these AH-HA moments, when doing things in Go I suddenly understood Java better. Sure, during a single talk I won't teach you Go. Thing is: I don't event want to, as all I want is to show you some concepts in Go which can help you (just as they helped me) become better Java developer and understand why we need projects Valhalla and Panama. It's about leaving our comfort zone to get... more comfort.