Good vs Bad Leader

Software is more about people than technology. When I graduated from college, I thought I only had to master technical skills to be a great developer, thinking that people skills are the appanage of managers solely. But experience taught me a good lesson on this one. Whenever I hear that people skills can’t be acquired, and you have to be a born with them, I just beg to differ.

Nobody is born with any given skill, we learn through observation and by copying others (our role-models). You might get some valuable info from reading books on this subject, but I remember an old saying, scribbled on the cover of a book I read in my teens: “Life is not learned from books, but by living it.”

If you feel you’re having troubles dealing with people, then you only have to watch and learn. It’s as simple as that. Even if you are not currently leading anyone, it pays off learning how to handle people, especially in our people-centric industry.

While meeting great leaders has always been a wonderful experience, it is the bad ones that really enforce the true values of a leadership. I’ve been lucky in this sense, as I got the chance to meet some of the worst leaders you can possibly imagine. Let’s see how a good leader compares to a bad one.

Continue reading “Good vs Bad Leader”

NoSQL is not just about BigData

There is so much debate on the SQL vs NoSQL subject, and probably this is our natural way of understanding and learning what’s the best way of storing data. After publishing the small experiment on MongoDB aggregating framework, I was challenged by the JOOQ team to match my results against Oracle. Matching MongoDB and Oracle is simply honoring Mongo, as Oracle is probably the best SQL DB engine. Being a simple experiment, it’s dangerous to draw any conclusion, since I was only testing the out-of-the-box Mongo performance, without taking advantage of any optimization. I will leave the optimization part as a subject of a future post, and dedicate this post to why NoSQL is a great tool in the Architect’s toolbox.

I really like how JOOQ defends SQL, and I’m constantly learning a lot from their blog and JOOQ documentation. SQL is one of the best ways of modeling data, and most of my projects requirements call for a relational data model. I would always recommend Oracle vs any other free RDBMS, since it’s safer to go with the best available tool, but not all of our clients want to spend their money on Oracle licenses, and therefore we have to build their products on top of MySQL or PostgreSQL (not a big issue so far).

Continue reading “NoSQL is not just about BigData”

Why I like Spring bean aliasing

Spring framework is widely used as a dependency injection container, and that’s for good reasons. First of all, it facilitates integration testing and it gives us the power of customizing bean creation and initialization (e.g. @Autowired for List types).

But there is also a very useful feature, that might get overlooked and therefore let’s discuss about bean aliasing.

Bean aliasing allows us to override already configured beans and to substitute them with a different object definition. This is most useful when the bean definitions are inherited from an external resource, which is out of our control.

In the following example, I will show you how bean aliasing works. Let’s start with the following bean definition, coming from the src/main/resources/spring/applicationContext-tx.xml configuration file.

Continue reading “Why I like Spring bean aliasing”

Why you should always check the SQL statements generated by Criteria API


Criteria API is very useful for dynamically building queries, but that’s the only use case where I’d use it. Whenever you have a UI with N filters that may arrive in any M combinations, it makes sense to have an API to construct queries dynamically, since concatenating strings is always a path I’m running away from.

The question is, are you aware of the SQL queries your Criteria API generates behind the scenes? I’ve been reviewing many such queries lately, and I’ve been struck by how easy it is to get it wrong.

Continue reading “Why you should always check the SQL statements generated by Criteria API”