I came, I coded, I debugged.

I have always been intrigued with the idea of being able to identify one's engineering persona, and develop a framework (of thought) which would allow effective team building based on personal and professional traits. Having spent a while in both academia and industry worlds of software engineering, I have been experiencing an increasingly disturbing feeling of disconnect between the two. In particular, between what is considered best practices in theory and what actually takes place in the industry. One particular aspect that has not been well incorporated into (empirical) software engineering research, is the human in the loop, or the social, cultural and human-centric aspects of software engineering as the authors of " Empirical Software Engineering: From Discipline to Interdiscipline " elegantly put it. We have little knowledge of how social and behavioural patterns in software engineering affect what came to be known as "best practices". Take automatic refa...

Even the trivial things are not A common activity the vast majority of software engineers share is working with code. There are many programming languages out there, some are statically typed, while others dynamically. Some are object oriented, and some are functional. Others are still trying to make up their mind (just kidding, we love you Scala!!). Regardless of the programming language at hand, in the end, working with code means manipulating code. These manipulations can be read-only, e.g., code navigation, or mutating, where existing code is being changed, and/or new code is being written, or both. Not only is manipulating code a very common activity for software engineers, some would argue that this activity is what takes up most of one's time as a software engineer, or at the very least, one of the top activities software engineers spend time on. Other activities includes consuming coffee, debugging, context gathering, etc.  Manipulating code is not trivial. For example, in...

The debate on which laptop is the best for professionally developing software has a tendency to get somewhat fanatic and emotional. When it does, this debate quickly depreciates because it becomes particularly difficult to discern opinions from facts, plus people get all shouty which is rarely a good thing in the context of a discussion. It's a shame, because I do believe that it's an important question which will most certainly affect one's development experience in many ways. Seeing that I have had experience working with all the major contenders (i.e., Windows, Linux, and macOS) at least to some extent, I'm hoping my experience can be of use to people contemplating new setups for professional software development. It's important that we define KPIs (a fancy word for criteria) which we will use to perform the comparison. Hopefully this will help avoiding statements like X is better because it's gray. Unless gray is a criteria I actually care about (spoiler...

I have recently had a number of colleagues tell me about their work environment. I find tech culture fascinating and rarely miss out on a chance to get first hand details. One of the companies I was told about, had a well stocked kitchen area with an LCD monitor looping through various dashboards. Sales leader boards, news about deals getting closed, social media and tons of other sales related material. Occasionally it would also display pics of people who had birthdays coming in. This may be be a good point to mention that the friend who told me this, had been working at a branch which consisted of mostly R&D and some product, few to none sales people whatsoever. This setup made me think. Dozens of software engineers and researchers walk by the LCD monitor in the common area every day, numerous times, and get an excruciatingly detailed view of the names of the sales persons who made the most sales, how many places they went up or down that week, the number of deals closed ...

When I tell people how strongly I feel about my IDE preferences they are often surprised and go all "haters gonna hate" on me. Being all into empirical software engineering, here's a post on the little things that make all the difference between Eclipse and an IDE that actually puts effort into trying to understand people who write code (Java in our case).

Macbook pro has an incredible retina display, and if you had a chance to work with it so much as a few days, going back to anything less feels quite unsatisfying to put it mildly.

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.

A short one. I've already posted about IntelliJ in the past , and judging by my enthusiastic PR for IntelliJ IDEA someone might mistake me for a share holder. Well, I'm not, though come to think of it, it might actually be a good IDEA (pardon the pun). I just love working with IDEs that understand developers and make things easier on them, and IntelliJ does just that. I've recently been brushing up my (automatic) refactoring skills, and IntelliJ has some really awesome stuff to offer in that department. Truth be told, there are some issues here and there, but hey, I have my bad days too. All in all, for me it's done the unbelievable job of making programming in Java ... kinda fun, not a simple task by any means. I even managed to enjoy editing a bash script the other day, I mean, that's unprecedented! All that before I even had a chance to try out the Ultimate edition, as I'm working with their (free!) Community version. Speaking of community, check out th...

(Crossposting from Outbrain's techblog ) Using Storm for real time distributed computations has become a widely adopted approach, and today one can easily find more than a few posts on Storm's architecture, internals, and what have you (e.g., Storm wiki , Understanding the parallelism of a storm topology , Understanding storm internal message buffers , etc ). So you read all these posts and and got yourself a running Storm cluster. You even wrote a topology that does something you need, and managed to get it deployed. "How cool is this?", you think to yourself. "Extremely cool", you reply to yourself sipping the morning coffee. The next step would probably be writing some sort of a validation procedure, to make sure your distributed Storm computation does what you think it does, and does it well. Here at Outbrain we have these validation processes running hourly, making sure our realtime layer data is consistent with our batch layer data - which we c...

Feature flags have always made me feel ambivalent. On one hand, I can relate to the need for having a mechanism to easily enable or disable particular features, while on the other hand, being a software engineer I pretty much loathe this concept, since feature flags make your code ugly more often than not. Especially if such a flag is left in place even after its corresponding feature has become fully operational, eliminating any practical need to be turned off on demand. Cliché ahead in 3,2,1: not everything in life is black and white, and sometimes, even in the face of feature flags, we can still, well, save face.

Same JAR, different version.   If you have multiple projects in your workspace depend on different versions of the same JAR, Eclipse will hand out all of them the same version, which is the one it happened to load first. Uncool . IntelliJ handles this case properly. Spring support. IntelliJ is capable of certain  tractability  between your Java and your spring XML context. For instance, if you refactor a class name, its bean will be renamed accordingly. You can also navigate from your Java class name to its corresponding spring bean . How cool is that? Static imports. Because I simply hated looking for the proper import for every Hamcrest static  mather  I needed. IntelliJ suggests to add them for you. Out of the box SVN integration. IntelliJ supports SVN right out of the box, no need to download any SVN plugins or tweak any configuration files . Not a biggy, but it's nice  nonetheless .

Some relationships are just not meant to last - c'est la vie. Be it the timing, emotional state, or the fact compiz takes up shit load of CPU in still water. Unity, I think it's time we see other user interfaces.

PowerPoint and presentations have been synonyms for over a decade, recently I've had the opportunity to "leave the comfort zone" (as life and career coaches mentor nowadays) and try Prezi for one of my talks. Looks like my next presentation is going to be in Prezi as well.

I'm not sure if it's the particular laptop model (Lenovo W530) or the particular Ubuntu version (12.04 LTS) or perhaps the fact I'm a complete and utter Linux newbie, but getting this show on the road has been quite a bumpy ride, to say the least (just shoot me would probably describe it more accurately, all I wanted was to set up a dual monitor environment).