A Java geek

This is the 3rd post in the Start Rust focus series. To continue building my understanding of Rust, I searched for some simple Rust exercises. Hence, I dedicated my weekly personal work time to the Rustling exercises. There will be two posts dedicated to Rustlings. The reason for that is that it contains many (many!) exercises. Besides, I need to learn about the more advanced themes such as threading.

This is the 2nd post in the Start Rust focus series. Last week, I drank my first cup of Rust. I learned concepts that are foreign in the languages I know: ownership, borrowing and lifetimes. This week I want to drink the second cup and see where it leads me.

This is the 1st post in the Start Rust focus series. It all started with an informal chat with my friend Anthony. We were talking about languages, and I said that I preferred compiled ones. He then went on to mention Rust. We admitted that we were too afraid to learn it because of its perceived complexity. After the chat, I thought about it, and I wondered why I didn’t check by myself. I did. And I became interested.

The JVM ecosystem is mature and offers plenty of libraries, so you don’t need to reinvent the wheel. Basic - and not so basic - functionalities are just a dependency away. Sometimes, however, the dependency and your use-case are slightly misaligned. The correct way to fix this would be to create a Pull Request. But your deadline is tomorrow: you need to make it work now! It’s time to hack the provided API. In this post, we are going through some alternatives that allow you to make

In my penultimate post, I described the use-case of an e-commerce shop. In general, interactions in such a shop are the following: You can browse a catalog of itemsEach item has a price tagYou can put x items in your cart It’s when the exciting part starts. On most pages, you want to give users a condensed view of their cart’s state. Here are a couple of options for the state’s view: Empty/non-emptyNumber of cart linesNumber of itemsTotal cost. In demos, it’s as sim

Last week, I described a use-case for a custom Stream Collector. I received a intriguing comment on Twitter: There was a 'Forbidden' error fetching URL: 'https://twitter.com/Miguucm/status/1389258245886390292' Hats off to you, Miguel! Your comment revealed a method I didn’t know! So I decided to investigate what the teeing() method is about. Returns a Collector that is a composite of two downstream collectors. Every element passed to the resulting collector is processed by both down

Java Stream’s Collectors methods fit most use-cases. They allow returning either a Collection or a scalar. For the former, you use one of the toXXX() method, for the latter, one of the reducing() one. Let’s imagine an e-commerce platform that implements a shopping cart. The cart is modeled as the following: This diagram might translate into the following (abridged) code: Product.java public class Product { private final Long id; (1) priva

This week’s post is pretty short. I’ve already written about overengineering, but this adds a personal touch. I had to rewrite my Jet Train demo to use another data provider, switching from a Swiss one to a Bay Area one. One of the main components of the demo is a streaming pipeline. The pipeline: Reads data from a web endpointTransforms data through several stepsWrites the final data into an in-memory data grid Most of the transform steps in #2 enrich the data. Each of them requi

Kotlin offers many exciting features. In general, developers tend to cite null safety as their favorite. For me, it’s function extensions. But delegation comes a close second. The delegation pattern The delegation pattern is described in the GoF book: Delegation is a way to make composition as powerful for reuse as inheritance [Lie86, JZ91]. In delegation, two objects are involved in handling a request: a receiving object delegates operations to its delegate. This is analogous to su

Frameworks promise to speed up one’s development pace provided one follows the mainstream path. The path may be more or less narrow. I’m a big fan of the Spring ecosystem because its design is extensible and customizable at different abstraction levels: thus, the path is as large as you need it to be. Functional Programming is becoming more and more popular. Spring provides a couple of DSLs for the Kotlin language. For example, the Beans DSL and the Routes DSL allow for a more funct