A Java geek

Last week, I wrote about the creative use one can make of Filters by grading assignments of students. About, there’s another recurring issue that warrants a blog post: servlet mappings. While servlet mappings seem easy on the surface, they sometimes can be the cause of huge headaches. The issue In the assignment mentioned above, students have to create a mock e-commerce shop application. The home page shows a title, an introduction phrase, as well as a catchy image.

I’ve just finished grading the assignments of my students for the semester. I change the assignment every now and then. The current one is a very simplified e-commerce shop. The main feature revolves around a couple of screens, and cart management: The product detail page is mainly composed of the product detail component. One can add one such product to the cart by clicking the Cart button The products list page aggregates a couple of product detail components.

Most tutorials about Git history rewriting state that history should never ever be rewritten. Like all principles, it depends mostly on the exact context. The principle should probably be updated like this: Public Git history should not be rewritten The reason is that once the Git history has been pushed, it has been made public: other developers might have started working on top of it. Then, and only then, is rewriting the history an issue.

In this post, I’d like to tackle some widespread thought found in software development’s circles: the magical creatures known as 10x developers. If you’ve been working in a software development team, even for a short period of time, you probably came to the conclusion that some developers contribute more than others. I came to this conclusion already some years ago: I noticed that some developers get their tasks done more quickly, other less quickly.

I know a lot of people who have interesting things to say: when I can, I try to encourage them to write their own blogs. I think every developer who has interest should do it, with the minimal hurdle possible. However, for reasons I cannot fathom, Medium has become the blogging platform of choice. Let’s face it, while the platform is okay-ish for non-technical posts, it’s not adapted for subjects that involve code - and formatting.

A couple of years ago, I wrote a post focused on how to avoid sequences of if-else statements. In that post, I demo several alternatives: the usage of proper OOP designmapswhen there’s no return, switch statements in a case. Recently, I stumbled upon a slightly more complex use-case. This post describes it, and details what additional options are available in Kotlin.