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.
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).
In my previous post, I demonstrated how fast you can insert 50 millions time-event entries with MongoDB. This time, we will make use of all that data to fuel our aggregation tests.
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.
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.
JOOQ is a neat framework, and it addresses a long-time issue I’ve had with advanced dynamic filtered queries. While Hibernate and JPA come with a useful Criteria API, which I’ve been using for quite some time, there are understandable limits to what you can do with those. For instance, you cannot go beyond simple SQL operations (e.g JOINS, NESTED SLECTS, AGGREGATION) and do something like: window functions, user-defined functions or easy sequencing to name a few.
JOOQ doesn’t feel like competing with Hibernate, but instead, I feel like it completes it. I’ve been using Hibernate mostly for the WRITE part of my Data Layer, hence its name or the “Persisting” part in JPA. For simple to medium complex queries, Hibernate does its best, but I don’t have to solely rely on it for all my queries, am I? There is also a drawback to querying properties and that’s because you sometimes have to add an association to your Domain Model just for the sake of querying it for a small number of use cases.
So, since I’m not afraid of writing native queries, I could, therefore, do it in a DSL fashion and vendor-independent way.
While you can go with string-based column naming, JOOQ offers a better approach through the use of a type-safe Metadata, so the first thing we need to do is to generate our table mapping for our database schema.
I like integration testing. As I explained in this article, it’s a good way to check what SQL queries are generated by Hibernate behind the scenes. But integration tests require a running database server, and this is the first choice you have to make.
Using a production-like local database server for Integration Testing
For a production environment, I always prefer using incremental DDL scripts, since I can always know what version is deployed on a given server, and which scripts required to be deployed. I’ve been relying on Flyway to manage the schema updates for me, and I’m very content with it.
On a small project, where the amount of integration tests is rather small, you can employ a production-like local database server for testing as well. This is the safest option since it guarantees you’re testing against a very similar environment with the production setup.
Some people believe that using a production-like environment would affect the test execution time, but that’s not the case. Nowadays, you can use Docker with tmpfs to speed up your tests and run them almost as fast as with an in-memory database.
While experimenting with some time series collections I needed a large data set to check that our aggregation queries don’t become a bottleneck in case of increasing data loads. We settled for 50 million documents since beyond this number we would consider sharding anyway.
Each time event looks like this:
"_id" : ObjectId("5298a5a03b3f4220588fe57c"),
"created_on" : ISODate("2012-04-22T01:09:53Z"),
"value" : 0.1647851116706831
Software development is all about knowledge, and nowadays the number of things a programmer needs to know skyrocketed. Most of the time developers are hired by matching their current skills with some project requirements. The project eventually ends, and the developer is assigned to a new project, sometimes using different technologies than what he was previously hired for. What’s the policy for training this guy to deliver his best the soonest possible?
Usually, training and coaching are left-out, so each programmer is on his own. Every time we leave things to chance a huge risk is implicitly undertaken. I believe we should give more to training and coaching and see them more of an investment rather than a spending.