I came, I coded, I debugged.

Today's recruiting managers have become salesmen, and oftentimes will be willing to tell you more than a few "alternative truths" to get you onboard. During an interview, one of your main goals is therefore to get wind of any such suspicious statements, and try to get to the bottom of them by kindly asking for more information. If you're told you have a once in a lifetime opportunity to join a new team that is building from scratch a product that's helping millions of users do this and that, take a minute to think things over and consider getting (satisfying) answers to the following questions.

Reflection has always been a bit of a trickery, and while there may be some true to it, it does not mean one cannot master mind some cool stuff using it, and by cool I mean useful,  re-usable, elegant and the likes. In this post we put on the wizard hat and pull out some rabbits. Problem Statement In this post we'll discuss 3 use-cases in which we want to retrieve runtime information for some generic parameters. In all three of the following use-cases, our goal is to retrieve the runtime information for the generic type parameter T. The first use case is when you have a class deriving from a generic class, without having generic parameters of its own: class GenericInt extends Generic<T> {} // one wants to know the type of T of its parent new GenericInt () The second use case is when you create a new instance of a generic class by providing a generic parameter: // one wants to know the type of T inside the class new GenericClass<Integer> () The third...

At QCon 2014, LinkedIn gave a talk ( slides ) about their Gobblin projec t (as well as published a  blog post ). Gobblin is a unified data ingestion system, aimed at providing  Camus -like capabilities for sources other than Kafka. While Gobblin is a fascinating piece of engineering, what I find to be no less fascinating is the direction LinkedIn has chosen by going for a system like Gobbblin.

This is, as a matter of fact, an industry proven method.

There are a few posts talking about Storm's metrics mechanism, among which you can find  Michael Noll's post ,  Jason Trost's post  and the  storm-metrics-statsd  github project, and last but not least (or is it?)   Storm's documentation . While all of the above provide a decent amount of information, and one is definitely encouraged to read them all before proceeding, it feels like in order to get the full picture one needs to combine them all, and even then a few bits and pieces are left missing. It is these missing bits I'll be rambling about in this post.

The Good Dependency injection (DI, a.k.a IoC - inversion of control) is a well known technique to increase software modularity by reducing coupling between modules. To provide the benefits of DI , numerous DI frameworks have arisen ( Spring , Guice , Castle Windsor , etc.) all of which essentially give you "DI capabilities" right out of the box (these frameworks tend to provide a whole lot more than just "DI capabilities", but that's not really relevant to the point I'm about to make). Now, to remove the quotes around "DI capabilities", let's define it as a DI container - a sack of objects you can manipulate using a provided API in order to wire these objects together into an object graph that makes up your application. I've worked on quite a few projects employing Spring, so it will be my framework of reference throughout the rest of the post, but the principles and morals apply just the same. 

When asked about what's a module, no two people give the same answer. The interesting thing is, it doesn't keep modularity from being one of most pronounced words when it comes to the desirable set of attributes a software system should ideally have. It's somewhere just next to scalable and robust, in no particular order.