Odd Behaviour in Groovy when Comparing Maps

groovy-langI 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.

Read the rest of Odd Behaviour in Groovy when Comparing Maps

Tales from Ole’ Romania: Bucharest ID

romanian_flagI 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.

Read the rest of Tales from Ole’ Romania: Bucharest ID

The Job That Never Was

Business background with beautiful female hands

It’s interesting what LinkedIn can reveal sometimes to me. Every time I log in and have a look I get a huge stream of updates from friends, old colleagues and people I’m connected to — nothing new there, this is a common pattern in social media nowadays. Sometimes I see certain connections changing jobs and often I go and read more about the new job they embraced, congratulate them or even engage in a discussion to find out more. It’s occasions like these which give me a chance to actually spend some time going through my connections full resume. (I confess that if I don’t meet/connect with someone for a year or so I tend to forget details, so something like this provides me the perfect opportunity to remind myself that John used to work at XYZ as a something-or-other before he moved into company ABC where his/her career really started to rocket.) These moments spent re-visiting someone’s LinkedIn profile paint a better picture for me at times than simply looking at their skill set and experience: who they worked with, what sort of trajectory they have, which then tells you a lot about where they are probably aiming, how quickly or slowly they progressed, which environments they liked and which they didn’t and so on…

And occasionally, these snippets of time spend on LinkedIn reveal some interesting (though disappointing) things: people occasionally lie a lot about their jobs :-)

Read the rest of The Job That Never Was

Radio Yerevan Joke

romanian_flagJust 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!


Cobertura Issue with Ignoring Annotated Methods

ScriptingI’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 coverageCheckTotalBranchRate and 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?

Read the rest of Cobertura Issue with Ignoring Annotated Methods

@TupleConstructor in Groovy Language

groovy-langI 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.

Read the rest of @TupleConstructor in Groovy Language

Small Yet So Costly Java Mistake

DukeWithHelmetOK 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:

  • first of all nobody’s perfect — I know you read that in my website tag line :) but yeah nobody’s perfect… sadly, in this instance, myself included :)
  • secondly, it shows that the smallest (really really small as you will see!) mistake can have huuuge repercussions. This ought to be an incentive for most people to get a second pair of eyes on their code every now and then — I’m not talking pair programming and rigorous lengthy code reviews, but just someone else to spend half an hour maybe a week over your code. In this particular case, I was definitely experiencing “code fatigue” — so I was staring at the same piece of code which screams obvious mistake to everyone with a fresh pair of eyes but it did not occur to me until I took a break of a few days then looked back at the code and spotted it right away.
  • thirdly, it should discourage everyone to re-invent the wheel. In my case, simply using something like the Guava library and their ThreadFactoryBuilder would have avoided this from the beginning.
  • and last but not least, to the devs out there looking after plugins such as FindBugs, PMD and the likes — this sort of issue would never get caught by these tools (at the moment at least!) so perhaps might be something to add to these tools.

And now, after this (rather majestic and) long intro, let’s look at what is this small costly mistake I’m talking about.

Read the rest of Small Yet So Costly Java Mistake

Gradle Multi-Project Issue with Checkstyle

gradle_logoI 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?

Read the rest of Gradle Multi-Project Issue with Checkstyle

Coding — My Daily Dose of Dopamine

iStock_000021169266SmallI 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.

Read the rest of Coding — My Daily Dose of Dopamine

More on Emoticons and the Deprecation of Handwriting

Gesturing handsI 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:

Read the rest of More on Emoticons and the Deprecation of Handwriting