In the past, we advised using the constructor to inject dependencies with Spring, and we introduced Lombok.
Guess what?
Those go quite well along together, except maybe for a little trick to known when you wish to use Spring’s @Value.
We’ll cover all that in this post.
A few months back, a new guy joined our team and the Java world after a few years of being a .NET programmer.
He had many reactions like, “What, you need to write that yourself in Java? In .NET, the compiler does it for you!”
It’s true that, in Java, the language and conventions drive you to write a non-negligible amount of low-value code.
But don’t fear!
Lombok aims at simplifying that task for you.
Microsoft publishing its tools under an open-source license did quite an effect.
Thing is, the MIT-license applies to the source code, but not to the binary they distribute.
Here are some explanation on this, and two possible alternatives.
If you’ve been using Spring for a while, or copy-pasting some web tutorials or examples, you’ve probably put some @Autowired annotations on private fields.
This does work, but it’s not the best way to do it.
Last week,
Tony asked me about the technological stack behind my website.
It’s a subject I wanted to write about once the website was stable, but I keep tinkering with it.
As such, it’s far from finished and I still have many ideas, but let’s talk about it now nonetheless.
I’ve discussed with several people, this year.
Technical leads, technical supervisors, architects…
You get the gist.
Among those discussions, I heard a recurring complaint, which I previously feared to be my demanding nature expressing itself.
But no! Other people noticed it too, and it basically boils down to something like this: we’re facing a new generation of developers, who like to do things fast and don’t care much about how things work deep down, and we’re living in an era proposing a new framework to help them go faster and not understand.
The two together won’t make for great developers. Good developers, maybe, but not great ones.
We developers often spend a great deal of attention choosing our tools: computer, editors…
Yet, we often fail to see the gain of choosing an appropriate font.
Here is some food for thoughts on this topic, and some of my favorite coding fonts.
More than once in my—no-so-long—career, I’ve had to work on machines that were not appropriate to my development needs.
These were most often the result of company policies designed to reduce the cost of machines to a reasonable level, but that doesn’t take the specific case of developers into account.
In the (not-so-)long run, it’s actually often money sent down the drain nonetheless.