Another year has almost come to an end and another year of technological advances has passed. I’d like to share my toolbox going into 2014.
Anyone who has done any software development has heard it. The sentence that makes you feel like getting a shotgun. It’s a client shouting “How hard can it possibly be to add that feature? The last one you implemented in a couple of hours and this one looks like the same thing!”.
Dear client, it’s never that easy. Sometimes it is. But don’t assume it is. Imagine you’re building a house. You want a window installed in your roof. They’ve already installed more than one window in the walls of your home and it didn’t take a long time. Will you argue with the professionals installing the window when they tell you it’ll take longer due to the added complexity of adding a unplanned window to a built roof? I’m betting you won’t. So why do you argue with software professionals when they tell you the unplanned feature you just asked isn’t that simple to implement, even if it looks like something else that’s already in the application?
Eventually consistent data seems to be the buzzword nowadays, especially in any NoSQL discussion. For those not versed in tech talk, having eventually consistent data means that you’re willing to sacrifice data consistency in order to gain in other areas. The most common area is performance or throughput. Not having to check for consistency every time speeds up an application tremendously. However, you cannot guarantee that your data will be consistent at a certain point in time.
In a couple of months I’ll get to experience what I think will be one of the defining moments in my life: becoming a father for the first time. Today I can say I seriously underestimated all the preparation that comes with this event. A lot of stuff needs to be done, and as a first-time father a lot of information needs to be gathered. Which coincidentally brings me to the subject of my post.
At our regular hospital 4 sessions are given to new parents in order to give them as much information as possible. The presentations are given by resident gyneacologists. Yesterday we went to the first of the 4 sessions and it’s safe to say: this was by far one of the worst presentations I’ve ever seen. It wasn’t the underlying content of the presentation, most subjects were handled. However, the way the information was presented and how it was presented, it made me twitch.
Recently, at my current project, we’ve been hunting down a bug in our software. See, our source data comes from Excel files and need to be imported into our system. Since it’s a Java project, we’re using POI.
Our problem began when we tried to read a certain cell that contained the value 929 as a numeric field and store it into an integer. So we did something like this.
POI only has one way to read numeric cell values, and that’s by using
double. Guess what we got after reading the cell? 928. The reason? The numeric cell value, that shows in Excel as 929, is actually read as 928.99999999… You have to love floating points. You’re probably wondering why we just didn’t read the value as a
String value and used
Integer.parseInt(...). Well, POI doesn’t allow reading a cell as a
String value if it’s actually a numeric cell type.
The sad part is that this only happens for certain numeric values, if you’re unlucky, the first code example will work (until it suddenly doesn’t anymore). Again, that’s floating point logic. This, by the way, is why I hate floating point and why I think they shouldn’t be allowed in modern development. It’s the principle of least surprise. Groovy, for examples, understands this and considers all decimal values in code as
BigDecimal (and allows for easy math operations on those fields, unlike Java). You need to explicitly state your want to use a double.
So remember, when reading Excel numeric values, what you see isn’t always what you get. That, and always use
BigDecimal, even if the API forces you to use floating point fields. There’s really no excuse for using