Thursday, September 6, 2012

An introduction to the Internet of Things

Would you like to visit Florence? Book for the weekend of September, 22 and plan for another week in which yon can enjoy two great conferences by Develer: Better Embedded and Better Software.
I will be presenting a talk with Paolo (as usual) on the Internet of Things: we'll see how to talk to the world and listen to what the world has to say. You can see all the details of our talk at the official page.
Meet you there!

Thursday, July 12, 2012

Physical computing: all around you

Another year, another WhyMCA conference. As always, the organization of the event was awsome, so first of all I'd like to thank Alfredo, Andrea, Paolo and Riccardo (strictly in alphabetical order) for all their effort: I'm sure that the great results have rewarded them well.


As neither Paolo nor I were slaughtered by angry birds or unhappy attendees after our last talk, we decided to risk our already ruined reputation and to give another speech on physical computing. For the lazy ones here are the slides we used:


All the details and the complete video of our talk can be found on the official page of the conference. Thanks to all the attendees for not falling asleep while we walked through the 146 slides (probably the excitement for the incoming mojito party gave a little help). By the way, the hotel staff were only expecting about 20 people, imagine them preparing 200 mojitos for overheated developers!

See you next year - and let everyone know that Alfredo Morresi is a friend of mine :-)

Monday, April 23, 2012

Anti-if workshop #4

During the last weekend I have attended an intense three days workshop lead by Francesco Cirillo on the importance of objects in Object Oriented Programming. Maybe you're reckoning it should be obvious, after all the name states it crystal clear.

Yet, too often we (at least I do) translate the concept to something we could call Class Oriented Programming. Don't get me wrong, classes are good, but only to evaluate the design after we have carefully and thouroghly worked with objects, scenario after scenario. Classes can be confusing, because they solve many different problems: they actually consolidate all the objects that solve each scenario. Then we must start from objects, which means that we should start with a single scenario.

So what is an object?

An object is not only "state and behavior", as we often hear. An object is an instance of a class, but this definition does not add anything to our knowledge (and moves the focus back on classes, where we don't want to keep it).

We used a phenomenological definition: an object is characterized by a series of operations that operate on the object itself and by a state that keeps track of the effects of the said operations (please help me to rewrite it avoiding the pun).

What did I learn? I did not learn to truly think with objects, as three days are not enough to overcome many years of bad habits (I can see clearly now the rain has gone), but I learned that I must strive to do it. And I have some more tools in my shed, even if I have to learn how to use them properly :-)

In a few words, the workshop was completely different from what I was expecting, but I suppose it's been much more effective this way. If I survive from all the homeworks Francesco gave us, I'll plan to write more about it.

I have joined Anti-IF CampaignMeanwhile, join the anti-if campaign as I did a long time ago.

Thanks again to Francesco and to all the brilliant guys I had the luck to meet there... looking forward to meeting you all soon!

Another Grand Slam for Wales

I know, I know... I'm late, very late, way too late. Nevertheless, I could not let it pass :-) I only wonder what would have happened if Wales beat France in the world cup semi-final...


Sunday, March 11, 2012

Don't pass (too) backwards

This is one of the most common mistakes I always see whenever I watch Italy play. The Welsh pas the ball almost parallel to the end line, so that the players have to accelerate to catch it: this gives them an advantage in the impacts, while Italians have to slow down, or they are already still, waiting for the ball to come into their hands.

It should not be so hard, I remember Santa teaching us that trick when we were 15 years old. I can't believe that players of a national team still have not learned it.


Pity for all the missed tackles. On the other hand, Halfpenny could avoid to hit Parisse while he was in the air. Anyway, the final 24-3 says it all.

Next turn: Italy and Scotland will battle for the wooden spoon, while I hope to see the Wales defeat the French team to secure a Grand Slam (they already won the Triple Crown). Shall the Dragons have great years like in the Seventies?

Monday, February 13, 2012

This was closer

I must admit that this time I really thought we could do it. Italy had never beaten England before, and it could have been a hard blow for the Whites of the Rose. Sadly, Italy still has to master the fine art of kicking to points, an art which their opponents seem to know well. At the end of the match the field was not the only cold thing in the stadium, and we hope that the Azzurri are not paving their way to another wooden spoon.


How much time has to pass before images like this one become the norm? Will Italy be able to really be one of the big dogs? Will my friend James ever stop smirking at me?

Ok, forget it, the last one would really be impossible... but one can still dream, can't he?

Saturday, January 21, 2012

The rules of the blame game

There should be no (bad) rivalry between different teams of the same company, just that healthy sense of competition that always pushes you to do better. Yet, sometimes you can witness disfunctional behaviours that flow into a blame game.

Just to be clear: blame games are useless, they waste people's time and eat your liver. If you still want to play, you should at least know the rules.

One of these rules is very simple: CYA. When you're talking nonsense you're not covering it very well. Example: check this excerpt from a conversation between a system engineer and a developer:

Sys: The server is not working. The problem is the application.
Dev: The servlet container can only use less than 1GB of RAM, the logs show an occupation of more than 1.5GB. Could it be the antivirus?
Sys: Out of question.
Dev: How can you be so sure?
Sys: If it was the antivirus then the server would never work.
Dev: Right... then it must not be the application, otherwise it would never work, even without an antivirus :-p

Sounds insane? Yeah, the same that I thought. In another domain it would sound something like this:

Doctor1: The patient has a bad cough.
Doctor2: It must be the lungs.
Doctor1: Out of question.
Doctor2: How can you be so sure?
Doctor1: If it was the lungs then the patient would always have a bad cough

WTF??? have you ever heard something like this? do you realize there's something weird? do one of the doctors sound like an idiot? would one of the doctors lose your trust?

Remember: you cannot blame anyone when you're not covering your you-know-what, otherwise you could be, well, you know.

And, if you'll accept a hint, don't blame anyone, even if you're in a full cast iron armor. We got there because we got there, now it's time to go on, so let's go on.

You'll have more time and less enemies, and you will always get a better result.

When you see a disfunctional conversation on the horizon, keep in mind that the best thing you can do is sail away and avoid it. If you're stuck in it, escape.

Automated vs manual testing

Yesterday I had an interesting tweetversation (it actually looks like this word exists) with @lunivore which started with this sentence:
My #1 suggestion for legacy code: If it works, and you change it, check that it still works. If there aren't any tests, run the app already.

I replied something about writing tests, and the discussion went on with several interesting remarks that made me think. As on many others, here's one thing on which I agree with Liz: automated tests do not imply that your app is working as it should. I have seen it too many times to be so naive. It could be (almost) true if our code coverage was perfect, but let's face it, it is not. Please note that I'm not talking about having tests on getters. We should have unit tests, integration tests, end-to-end tests, there-is-no-try-yoda-tests and everything you can think of as long as it ends with "tests" for almost everything. And more often than not we don't.

And even if we did, tests are not users. Well they are, but they are not the users we're most interested in: those who receive value from our app.

Automated tests are very important, but in the end they only are our safety net (even if they also guarantee our customers), but in the end it all comes up to real users.

Automated tests never sign checks, users do. Or at least the bosses of users do. Then, if we belong to that overrated category of people that still insist on eating every day (possibly more than once), we shoud strive to have happy users more than happy tests.

Automated tests are one of our means, not our ends. Let's not forget it.

PS don't forget to follow Liz on Twitter and on her blog.