Skip to main content

5 things to consider when moving from Windows to Ubuntu


1.

You'll have to download utilities to perform even the most basic tweaking (tool tip color, anyone?). Don't worry, there's an apt-get for that.

2.

If you didn't apt-got it, the chances of it to actually work drop exponentially with the number of *.sh files in its bin directory.

3.
The true meaning of an "Open Source" project is that you can't get it to work unless you open its source. C'est la vie.

4. 
Even when software is commercial, the sooner you leave your "things should work after you install them" assumption behind, the less you'll want to bang your head against the wall when they don't, which is a most considerable amount of time.

5.
Sometimes doing stuff with your bear arms and the shell is actually more productive. Linux shell is pretty awesome, the force is strong with this one.

Comments

Popular posts from this blog

Sending out Storm metrics

There are a few posts talking about Storm's metrics mechanism, among which you can find Michael Noll's postJason 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.

Dependency Injection - The good, the bad and the ugly

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.