I came across this the other day and I ended up spending quite some time on it pulling my hair and I still couldn’t explain it in the end so I thought I’d post here to see if anyone can shed some light into it.
In brief, it’s about Groovy’s (otherwise awesome!) feature of comparing maps using
== operator: we know that translates to
equals() and if we look at the JDK
Map.equals() that performs a key/value pair by key/value pair comparison, in other words it’s not a shallow operation based on just the object hash.
This makes it useful when writing unit tests in Groovy because any method that returns a Map I can simply write:
resultOfMethod == [some: map] which makes the code much more succinct and easier to understand.
Also, because Groovy has the nice
GString implementation and the
GString == operator returns true when dealing with
String‘s with same characters, this makes Groovy preferable for me, especially for unit tests, where I use the
== operator everywhere.
I decided to continue my short (so far) series on “tales from pre-1989 Romania” as it seems my posts so far triggered quite a few reactions. Mostly, I gathered from the folks in the Western world, curiosity. It appears that my readers want to know more about some of these (really odd) things that back in the day we just accepted (since there was no alternative) and got on with it.
One such oddity was the “Bucharest ID”, which is what I’m going to write about today.
A bit of context, for those of us who are not that familiar with the geography of that part of the world: Bucharest is (and was) the capital of Romania. It is also the largest city in Romania at about 1.9 MM people — though at some point the city counted over 2MM souls. Being the capital it meant that parliament and the president were always based here. (Yes, odd as it might sound, Romania was actually during the communist still a republic, supporting a bi-chamber parliament and a president… which, ahem, kept getting re-elected all the time 😀 ) This arguably accentuated its development throughout the years but whether that is true or not it’s sort of irrelevant; the truth of the matter is that the city has been for a while now the biggest and most advanced in the country. (By contrast for instance, my home town, Constanta, which ranks the 3rd in size in the country only counts about 425,000 inhabitants.) This has given it its own status, unique throughout the country — however, this was taken to a new level during the communists.
Just spoke with an old Romanian friend of mine who told me this joke, which was famous in Romania during the “old times” and I thought I’d put it out here as it’s bloody hilarious. Quite likely “oldies” like me will laugh at this, but for the Romanian youngsters out there probably means nothing. Sic transit … so to speak (As a heads-up, this is a Radio Yerevan joke.)
Radio Yerevan gets asked:
Is it true that comrade Stoianov won a family holiday including the airplane trip to New York, USA and back following your last week’s radio broadcast?
Radio Yerevan answers:
Yes, that is true, however, a few corrections since you haven’t got your facts quite right:
- It wasn’t a a family holiday, it was just for him
- And it wasn’t a holiday, it was just a trip
- And it wasn’t to New York, it was to Moscow
- And it wasn’t by plane, it was by bike
- And finally: he didn’t win it, he lost it!
Thank you for your question!
I’ve decided to plug in Cobertura in (some) of my projects to have an idea on the unit test/code coverage going on. I use Gradle, so I started looking at the Cobertura Gradle plugin. It turns out it’s pretty good — and offers a lot of the functionality that I needed. However, I came across a (weird) issue so I’m going to investigate it and present the findings in this post.
First of all, I’m planning on using Cobertura as part of the build and have it fail the build if the coverage is falling under a certain threshold. This means that if we start with a build that’s acceptable (in terms of code coverage), any changes made in the future need to have accompanying tests, decent enough to keep that threshold within acceptable limits. It turns out this is easily done with the plugin by setting
coverageCheckHaltOnFailure coupled with
coverageCheckTotalLineRate. To start with I’ve set up the threshold quite low and give it a spin…
Turns out my project failed right away as it had occasionally line coverage falling under 20%!!! WTF?
I set off to look into it — turns out there’s a few packages where my line coverage is nearly 0! A closer look reveals there’s a lot of simple Java beans / POJOs in there and also some exceptions. I’m pretty sure that no one cares about testing their getters and setters and their exceptions constructors, right?
I find myself nowadays mixing a lot of JVM languages: I write a lot of “core” code in Java, as I prefer the verbosity of it somehow, but then I find myself a lot of times I just need a lot of utilities or “quickies” around this code — be it for unit testing purposes or to provide nicer interfaces to the outside. And that’s when I switch to Groovy language and its syntactic sugar so to speak.
I write about 50% of my unit tests in Groovy nowadays — though, granted, partially because of the Spock framework too. Also, I tend to write most of my beans now using Groovy too as it allows for a more terse syntax while achieving the same. I’ll walk you in this post through one of the niceties in Groovy around Java beans.
First of all, I’ll just say, that before using Groovy for my Java beans, I did try out the Project Lombok in Java and relied on its annotations for generating getters, setters, constructors and so on. However, I found that at time to be buggy and it still needed a few annotations in place for what seems to me rather a natural thing when it comes to Java beans: constructor, getters and setters. As such, I ditched it in the end — and I’m sure the framework will improve in time so soon I might have to revisit them and see where they got — and switched to Groovy.
OK so I felt like I needed to share this code with “the world” as I think it’s a good example of a few things:
And now, after this (rather majestic and) long intro, let’s look at what is this small costly mistake I’m talking about.
I have encountered this with Gradle recently and I have struggled to find right away a solution to the issue — it took a bit of reading (more) about Gradle, Checkstyle and some digging in until I found the (rather simple) solution. So I thought I’d post it here for others to hopefully find this when they’re encountering the same problem
The problem that I encountered is the following: I’ve put together a Java project which exposes an API and compiled it as a jar/library. The idea is that other projects I’m working on can use this API, as you would expect.
And since I wrote the library mainly for my own use, as soon as I was done with it I’ve started working on the project which was going to use this API. In the process of working on this, I realized that I actually needed to make a couple of small changes to the initial library — so to save me switching in between the 2 projects, compiling, updating dependencies and so on, I’ve used gradle’s multi-project facility. (I’ve actually combined this with Git feature of having sub-projects in a repo, so my main project includes in git the library as a subproject — then I’ve referenced that project as an include in the gradle build files.)
All looks pretty standard so far, no surprises there. Until I run a
gradle clean build in the main project and I get an error regarding to Checkstyle not finding configuration files! WTF??? The library (sub)project compiles fine if I launch gradle in its own folder so where is the problem?
I was asked recently by a friend of mine about what does my “standard” day of work consist of at Netflix. I had to explain to him that it’s hard to talk about a “standard” day as each day sees me looking at different pieces of our infrastructure and requires different challenges to be solved. Still though, I explained that there are a few common denominators throughout a day in Netflix — and in fact throughout a day of work for anyone who works in software development. And one major such common denominator, as I explained to him, is the fact that we, software engineers (“coders” as we are often labelled), spend lots of ours a day looking at lines of code and producing lines of such code. Then testing it, checking if it works, tweaking it a bit, trying it again and so on until we reach perfection or code nirvana At this point we are happy with our work and ready to move onto the next task. (Which more often than not is to deploy that code onto servers, but perhaps I’ll talk about that bit in a separate blog post. For now, I will just concentrate on the fact that we spend a lot of our time in front of countless lines of code — written by us or someone else.)
“Do you guys not get bored?” asked my friend, having listened to my talking about this.
I wrote before about what I think of handwriting — I think this is a dying communication form. And this is in favour of visual communication. See my previous post on whether handwriting is something I need to keep in my brain or not as well, where I was talking about the fact that one picture can actually communicate in millisecond time the same amount of information — without my brain having to give all the commands to my hands to “encode” the message in writing then send a text/email to my friend which then has to engage his brain to decode the letters, assemble the phrase then decode the phrase again and finally interpret the meaning of it; a single image encodes all of that and making it visual makes it much easier for the brain to decode.
This has found me obsessed lately about whether it’s just me thinking this way or is it actually the case that this is happening? And just when i start thinking that maybe it’s just a silly thought of mine, something like this happens: