Thanks to Davide, some weeks ago I had the pleasure and the privilege of being one of the speakers at the Google Developers Groups DevFest Lombardia in Milano. Being part of such an event, surrounded by many brilliant speakers, is not a responsibility to be taken lightly. I hope I have managed the task, and if the attendees have had at least half the fun I've had I consider myseld more than satisfied (this sentences reminds me a little bit of the parting speech of Bilbo Baggins, so if you find I have not expressed myself clearly enough please assume it was intentional)
The talk presents an introduction to the Google+ platform (thanks to Google for the materials), and shows how easy it is to go
beyond social as we know it and bring it to a different level in the
Internet of Things.
It was great to meet so many brilliant people, some of which were so lucky to be in Mountain View the following week, so I'm looking forward to the next DevFest!
Monday, December 2, 2013
Google+ gets physical!
Etichette:
arduino,
arduino yun,
Google+,
Internet of Things,
iot,
physical computing,
processing,
temboo
Sunday, September 8, 2013
A bit of fun with Zend Framework 2
After writing web applications in Java for about ten years, we recently approached PHP. After a bit of training and experiments on the Zend Framework 1, before starting to actually work on a real product we decided to switch to the Zend Framework 2 (mostly because of a great Zend Framework Day).
But it was only after a few months that my colleagues had started to use the framework that I eventually joined them.
At the beginning it was really frustrating. After ten years of Java, getting "back" to PHP has been somehow weird: I kept using dots instead of arrows, always forgot the dollar sign before variables, yet insisting on declaring their types. Not to mention the syntax to declare and use arrays (which, to tell the truth, I never remember also in Java). But these were not problems, just minor diversions.
My real problem was that I didn't know what happened under the hood, and I mostly proceeded tentatively. In the Zend Framework 2, of which by the way I have quite a good opinion, so many things happen automagically, and some of them are not very well documented. I mean, thanks for a great tutorial for beginners and all, but... why on earth do I have to create an album/album directory for the view? Would it be so terrible to say that there is a folder for the module and one for the controller? Or to explain how camel case turns to dashes and dashes turn to... what do they turn to?
And so, even the simplest tasks seemed daunting. Then, after banging my head on the wall for a while, I slowly started to get the gist of it, up to the point that now I feel quite confident, at least for the basic things.
And, hear, I started to enjoy playing with it: controllers, factories, autoloading... and, last but not least, tests. And (and, even if this was the fifth and in such few a lines, I somehow managed to slap in a sixth and a seventh one) I slowly switched from "how the hell do I get this parameter from the route?" back to "where should I put the responsibility of horizontally filtering data"?
Up to the point that I am seriously considering the possibility to REALLY get way out of my comfort zone and submit a proposal for one of the next conferences introducing the framework for beginners like me, trying to smooth the path I have lightly trodden with so many difficulties.
Hey, maybe it's only me, maybe I'm particularly dumb... but then again, somebody could find it useful. As always, I'm wide open for suggestions... but closed for modification :-)
As an end note, I'd like to thank Antonio for being so patient and putting up with my musings, questions and doubts. Looking forward to some more programming fun time together!
But it was only after a few months that my colleagues had started to use the framework that I eventually joined them.
My real problem was that I didn't know what happened under the hood, and I mostly proceeded tentatively. In the Zend Framework 2, of which by the way I have quite a good opinion, so many things happen automagically, and some of them are not very well documented. I mean, thanks for a great tutorial for beginners and all, but... why on earth do I have to create an album/album directory for the view? Would it be so terrible to say that there is a folder for the module and one for the controller? Or to explain how camel case turns to dashes and dashes turn to... what do they turn to?
And so, even the simplest tasks seemed daunting. Then, after banging my head on the wall for a while, I slowly started to get the gist of it, up to the point that now I feel quite confident, at least for the basic things.
And then, suddenly (snaps glove), you get a break... all the pieces seem to fit into place
And, hear, I started to enjoy playing with it: controllers, factories, autoloading... and, last but not least, tests. And (and, even if this was the fifth and in such few a lines, I somehow managed to slap in a sixth and a seventh one) I slowly switched from "how the hell do I get this parameter from the route?" back to "where should I put the responsibility of horizontally filtering data"?
Up to the point that I am seriously considering the possibility to REALLY get way out of my comfort zone and submit a proposal for one of the next conferences introducing the framework for beginners like me, trying to smooth the path I have lightly trodden with so many difficulties.
Hey, maybe it's only me, maybe I'm particularly dumb... but then again, somebody could find it useful. As always, I'm wide open for suggestions... but closed for modification :-)
As an end note, I'd like to thank Antonio for being so patient and putting up with my musings, questions and doubts. Looking forward to some more programming fun time together!
Etichette:
framework,
PHP,
programming,
Zend Framework 2
Thursday, May 2, 2013
I broke a build... let's celebrate!
Some three years ago I wrote a small test for a very particular factory: it worked pretty well, even if I've never really liked the constraints imposed by the requirements about the exception that is expected to be thrown.
Yesterday, not quite unexpectedly, the build was broken.
Obviously this is not really a unit test, as it depends on real data, so I'd call it more an integration test. Anyway, the data changed and the test failed, thus breaking the build. Normally I wouldn't be so happy. Yet in this case, even if it might be an antipattern (it clearly is), I think I won't change the test to be independent from data, but change the test instead:
@Test(expected=IllegalArgumentException.class)
public void makeBaby() {
Family family = moz.getFamily();
assertEquals(3, family.getChildren().size());
BabyFactory factory = family.getWife();
Baby babyboy = factory.makeBabyBoy("Ethan");
assertNotNull(babyboy);
family.addChild(babyboy);
assertEquals(4, family.getChildren().size());
boss.askForRaise(moz);
}
Now I'm only waiting for the requirements to change so that I can remove the exception...
Monday, February 4, 2013
PHP Application Development with NetBeans: a review
After too much time I've been able to review "PHP Application Development with NetBeans: Beginner's Guide" by M.A. Hossain Tonu, published bky Packt. The official description of the book says that it's "aimed at PHP developers who wish to develop PHP applications while taking advantage of NetBeans functionality to ease their software development efforts and utilize the powerful features of the IDE. Familiarity with NetBeans is not assumed. However, a little familiarity with PHP development is expected.".
TLDR? You can skip the review and jump to the rating. Of course that would kill my ego, but if you still want to stab me in the back here's your knife. Et tu, Brute?
I must also note that I have received a free copy of the book in exchange for the review.
Every now and then there are some "Pop quiz" sections, short multiple choice questions. As a rule of thumb I am not very impressed, because they remind me too much of a braindump. I'm OK with the ones on concepts, but not so much with the ones regarding actions, for which I'd rather have more hands-on. Speaking of which, we have the "have a go hero" sections, that often asks us to do completely new things rather than insisting on variations of what has already been done: that can be seen as a plus or a minus, depending on the eyes of the reader.
The first chapter guides the reader through the installation of the IDE and the whole stack environment. Having everything already installed (see initial disclaimer) I didn't check each and every passage, but everything seems very well explained and pretty much the way I remembered it.
The second chapter introduces the editor, yet I'm afraid it doesn't effectively convey all its power and potential, many things have been left unsaid or have not been deepened enough, like the possibility to customize the code templates and the folding criteria, not to mention specific editors for other languages.
One thing I didn't like is the position of the shortcuts, which are often presented out of context and way after the corresponding feature has been described. I think that an approach like "this is your action, and this is its shortcut" would be much better, as the proximity helps to sink the concept in.
The chapter follows the "here's the theory, try it in practice" pattern, yet I find the loop between the two to be too long. This is an issue throughout all the book (at least, it is in my opinion). A little less conversation, a little more action.
The third chapter introduces us to project in which we complete a whole user story. It starts with a description of the technologies used, then slowly presents all the code. The chapter is very similar in concept and structure to the seventh one, in which the skeleton for an enterprise feature (user registration, login and logout) is presented. In both cases there is a lot (trust me, when I say a lot I mean it, particularly in chapter 7) of code before we can actually see something working. Forgive me for the politically uncorrect comparison to another publisher, but from this point of view the "Head First" series are much better, as they start with something working, then they slowly build things up.
Moreover, the chapters are more about the technologies used in the application rather than NetBeans. Chapter 7 in my opinion is even worse, because it deals with more advanced subjects that a beginner probably doesn't know. OK, take the probably away. Yet, ironically, after several patterns and abstractions, and almost at the end of the book, the author says "it is recommended that you are familiar with PHP sessions and cookies in this tutorial", a subject simpler than many others that are taken for granted.
Chapter 4 is on testing and debugging, it's quite good (I must admit I had some problems with my instance of PEAR but that has nothing to do with the book). Some more details on Selenium would do no harm, at least a screenshot of the results should be inserted.
Chapter 5 deals with documenting your code and it's quite good. It also happens to be the chapter that you can download to evaluate the book.
Chapter 6 is about versioning with git and NetBeans. It's not bad, yet it does not show how to unstage a file (why not a have a go hero here?). Another feature that's dealt with too lightly is merging, and the resolution of conflicts is only briefly cited. And, talking about versioning, chapter 2 ends with a warning about the position of NetBeans metadata directory with respect to versioning, but it does not explain the consequences of the choice; some hints or advice would be nice.
The book should be an introduction, yet some PHP concept are quite advanced for a beginner. It helps you to get up and running with a complete environment and introduces you to many features of NetBeans, yet some important things are left out. All in all, in my very personal scale the books rates 3.5 our of 5.
TLDR? You can skip the review and jump to the rating. Of course that would kill my ego, but if you still want to stab me in the back here's your knife. Et tu, Brute?
A small disclaimer
I do have a little familiarity with PHP development, and I have a strong familiarity with NetBeans, being a NetBeans Certified Professional, so while on the one hand I belong to the right target, on the other hand I might get extra-critical. Well, the book has been reviewed by no less than six professionals, so I guess my rants can happily and safely be ignored.I must also note that I have received a free copy of the book in exchange for the review.
Here we go
As every Packt book I've seen (and I've not seen a few) the fonts are easy on the eye and there are many clear pictures. A bit of critic on the code sections, sometimes too long and with a lot of boilerplate that could be found in a downloadable file (it actually is) or confined in an appendix dedicated to the complete code.Every now and then there are some "Pop quiz" sections, short multiple choice questions. As a rule of thumb I am not very impressed, because they remind me too much of a braindump. I'm OK with the ones on concepts, but not so much with the ones regarding actions, for which I'd rather have more hands-on. Speaking of which, we have the "have a go hero" sections, that often asks us to do completely new things rather than insisting on variations of what has already been done: that can be seen as a plus or a minus, depending on the eyes of the reader.
The first chapter guides the reader through the installation of the IDE and the whole stack environment. Having everything already installed (see initial disclaimer) I didn't check each and every passage, but everything seems very well explained and pretty much the way I remembered it.
The second chapter introduces the editor, yet I'm afraid it doesn't effectively convey all its power and potential, many things have been left unsaid or have not been deepened enough, like the possibility to customize the code templates and the folding criteria, not to mention specific editors for other languages.
One thing I didn't like is the position of the shortcuts, which are often presented out of context and way after the corresponding feature has been described. I think that an approach like "this is your action, and this is its shortcut" would be much better, as the proximity helps to sink the concept in.
The chapter follows the "here's the theory, try it in practice" pattern, yet I find the loop between the two to be too long. This is an issue throughout all the book (at least, it is in my opinion). A little less conversation, a little more action.
The third chapter introduces us to project in which we complete a whole user story. It starts with a description of the technologies used, then slowly presents all the code. The chapter is very similar in concept and structure to the seventh one, in which the skeleton for an enterprise feature (user registration, login and logout) is presented. In both cases there is a lot (trust me, when I say a lot I mean it, particularly in chapter 7) of code before we can actually see something working. Forgive me for the politically uncorrect comparison to another publisher, but from this point of view the "Head First" series are much better, as they start with something working, then they slowly build things up.
Moreover, the chapters are more about the technologies used in the application rather than NetBeans. Chapter 7 in my opinion is even worse, because it deals with more advanced subjects that a beginner probably doesn't know. OK, take the probably away. Yet, ironically, after several patterns and abstractions, and almost at the end of the book, the author says "it is recommended that you are familiar with PHP sessions and cookies in this tutorial", a subject simpler than many others that are taken for granted.
Chapter 4 is on testing and debugging, it's quite good (I must admit I had some problems with my instance of PEAR but that has nothing to do with the book). Some more details on Selenium would do no harm, at least a screenshot of the results should be inserted.
Chapter 5 deals with documenting your code and it's quite good. It also happens to be the chapter that you can download to evaluate the book.
Chapter 6 is about versioning with git and NetBeans. It's not bad, yet it does not show how to unstage a file (why not a have a go hero here?). Another feature that's dealt with too lightly is merging, and the resolution of conflicts is only briefly cited. And, talking about versioning, chapter 2 ends with a warning about the position of NetBeans metadata directory with respect to versioning, but it does not explain the consequences of the choice; some hints or advice would be nice.
TLDR
Now, here we are with the conclusions. If you skipped all the article to jump to this section, please feel a little guilty.The book should be an introduction, yet some PHP concept are quite advanced for a beginner. It helps you to get up and running with a complete environment and introduces you to many features of NetBeans, yet some important things are left out. All in all, in my very personal scale the books rates 3.5 our of 5.
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!
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!
Etichette:
better embedded,
Florence,
Internet of Things,
microcontroller,
presentations,
twitter
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 :-)
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:
Physical Computing - Tutto intorno a te
View more presentations from Andrea Maietta
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 :-)
Etichette:
mojito,
physical computing,
presentations,
WhyMCA
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.
Meanwhile, 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!
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.
Thanks again to Francesco and to all the brilliant guys I had the luck to meet there... looking forward to meeting you all soon!
Etichette:
anti-if,
design,
education,
Object Oriented Programming,
workshop
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...
Etichette:
Grand Slam,
rugby,
Six Nations 2012
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?
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?
Etichette:
rugby,
Six Nations 2012
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?

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?
Etichette:
rugby,
Six Nations 2012
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.
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.
Etichette:
people
Automated vs manual testing
Yesterday I had an interesting tweetversation (it actually looks like this word exists) with @lunivore which started with this sentence:
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.
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.
Etichette:
refactoring,
TDD,
testing
Monday, November 21, 2011
Startup without falldown: the slides
Here are the slides of my talk "Startup without falldown: strategic planning beyond wishful thinking", held at the 8th Italian Agile Day in Rome:
If you want an exhaustive bibliography please register here and you'll receive it in a few days, with a bonus mind map of the talk.
Startup senza falldown
I'd like to thank everyone who has attended, I hope I haven't wasted their time. If you are one of the lucky (???) ones, please help me to improve and leave a feedback here. View more presentations from Andrea Maietta
If you want an exhaustive bibliography please register here and you'll receive it in a few days, with a bonus mind map of the talk.
Etichette:
agile,
BDD,
business,
business model,
business plan,
iad11,
TDD,
testing
Monday, October 24, 2011
Wednesday, October 19, 2011
Startup without falldown: strategic planning beyond wishful thinking
The official program for the 8th Italian Agile Day has been officially published. I am really happy (and a bit surprised) to see that my talk has made it to the final 26: I am sure that many of the talks that were left out would have been really interesting, so I'd better work really hard to be up to the task. Even because I know that the conference normally has quite a high bar...
It is always difficult to pick one of the talks that are held at the same time, and this year I will lose one more than I did in the previous years. I hope all sessions will be recorded, as it seems, so I'll be able to see them later.
Meet you there... And don't forget to register and donate :-)
It is always difficult to pick one of the talks that are held at the same time, and this year I will lose one more than I did in the previous years. I hope all sessions will be recorded, as it seems, so I'll be able to see them later.
Meet you there... And don't forget to register and donate :-)
Etichette:
agile,
business model,
business plan,
iad11
Monday, October 10, 2011
Agile Day: independent, thanks to donations
The Agile Day is an event organized by members of the Italian agile community.
To mantain its independence, and at the same time guarantee both a quality programme and free access to registered attendants, in the last years the Agile Day has chosen a brave strategy: sustain itself with self-financing.
This choice has proven itself effective, and the Agile Day has reached its eighth edition and more than six hundred attendants in 2010.
The donations obtained from participants, enthusiasts and professionals that daily work with agile methods represent the esteem and the affection that the Agile Day has been able to conquer year after year.
All the raised money will allow the organization to reach the organizational targets that will make a great Agile Day.
That's why everyone committment becomes essential, every single donation is a step towards the success of the Agile Day.
The Agile Day will be held in Rome on November 19, 2011.
The access will be, as always, free.
All details can be found on the official site.
To mantain its independence, and at the same time guarantee both a quality programme and free access to registered attendants, in the last years the Agile Day has chosen a brave strategy: sustain itself with self-financing.
This choice has proven itself effective, and the Agile Day has reached its eighth edition and more than six hundred attendants in 2010.
The donations obtained from participants, enthusiasts and professionals that daily work with agile methods represent the esteem and the affection that the Agile Day has been able to conquer year after year.
All the raised money will allow the organization to reach the organizational targets that will make a great Agile Day.
That's why everyone committment becomes essential, every single donation is a step towards the success of the Agile Day.
The Agile Day will be held in Rome on November 19, 2011.
The access will be, as always, free.
All details can be found on the official site.
Etichette:
agile
Sunday, October 2, 2011
PMBA & The Frankenstein Garage experience
Who we are
We are a small team of IT experts, and we have been working for a while trying to create something of our own, in addition to our daily jobs. We definitively are bootstrappers, because we don’t have so many bucks in our pockets (and even if we had, we’d want to use each penny wisely).How it started
We knew pretty well that being an expert on a given technical subject is not enough to help you start a business. None of us has an MBA, but we wouldn’t let that hinder us, so we have started reading a lot of business related books - actually devouring them: finance, marketing, business, innovation. We wanted to reach a level of understanding similar to that of an "institutional" and much more expensive MBA. Being technicians, we're really pragmatic and believe in practical and operational knowledge, so we’ve rolled up our sleeves and delved into the groove.Frankenstein Garage
The project we’re working on is called Frankenstein Garage, and it’s going to be the first FabLab in Milan. FabLab stands for Fabrication Laboratory (but also for Faboulous Laboratory), and it is a place where people can make (almost) anything. The first FabLab was born at the MIT in Boston to support a course held by Neil Gershenfeld. The laboratory, beyond the usual tools you can find in any lab, will have tools for digital fabrication, like 3D printers or CNC machines: this means that the machines will sort of “automagically” build things out of CAD drawings.We employ waste materials (electronic, electric and mechanical) to develop low cost prototypes and to be green. Our experience in the IT world has taught us that being agile is the right choice almost in everything: that’s why the early stage of our prototypes heavily involves the use of LEGO bricks.
To sustain our activities we have developed our MEVO: the ABNormal, a little micro-controller board, which we’ll be ready to sell in a matter of days.
How PMBA helped us
A few months ago we have found on Google a link to Josh Kaufman's wonderful list of books, to find that we had already read many of them. Obviously we've bought PMBA as soon as it became available, read and re-read it and, most of all, started to use it, putting into good use all the knowledge distilled into it. We consult it almost daily and follow the advices contained in it each and every day: Kaufman's work has proven really useful for very busy startuppers like us.
As PMBA helps us a lot as a quick reference, we have also created some mind-maps from the book, to achieve faster results: seeing all the concepts in a single glance is really effective and a great time saver, as we can now check multiple aspects in just one shot. This has helped us to develop clear concepts and refine our proposals in an acceptable Business Plan (by the way, Business Model Generation has helped us a lot to prepare for the BP, when shall we see it in the list?).Following the advices found in the book(s) we also won two awards just a few weeks after starting this project: "Dall'Idea all’Impresa" e "Diamo casa a 10 idee creative", which more or less sound like "From idea to business" and "Let’s host 10 creative ideas". That won us, among other services, a free office for year in Milan, and that is really helping us as it means a great saving, leaving our (small) resources for other uses.
Interested? check out the official Frankenstein Garage page!
Etichette:
business,
business model,
business plan,
FabLab,
Frankenstein Garage,
MBA,
PMBA,
reading
Friday, September 23, 2011
Angry Birds slung from WhyMCA to Vimeo
The video of our talk on Angry Birds is finally online!
All details can be found on the official site. Thanks again to Paolo for putting up with me and to the organizers of the event. Looking forward to WhyMCA 2012 :-)
All details can be found on the official site. Thanks again to Paolo for putting up with me and to the organizers of the event. Looking forward to WhyMCA 2012 :-)
Etichette:
Angry Birds,
brain,
games,
mobile,
patterns,
presentations,
WhyMCA
Tuesday, September 20, 2011
Hard times for reading stats
This year I have no time for reading. I really try, but I can't manage to save myself some time. Up to now I have only read 29 books in 2011, and the last one I finished is a book I started to read in January. What a shame.
On the other hand, I've got my hands dirty in a lot of things, and this partially justifies the stats. I don't see a lot of free time in my immediate future, but I hope this will change. I still have more than 150 books to read, not to mentions the ones that I have not yet registered in anobii.
Nevertheless, I am looking forward to the 8th of October, not only because it is the anniversary of my friends Katia and Nea, but also because "The Lean Startup", an absolute must have, will arrive on the shelf of my favourite bookstore.
That said... I'll delve into one of the nine books I'm reading. At the moment, the target for 2011 is a modest 36 (exactly the half of last year), we shall see whether I'll reach it or not.
On the other hand, I've got my hands dirty in a lot of things, and this partially justifies the stats. I don't see a lot of free time in my immediate future, but I hope this will change. I still have more than 150 books to read, not to mentions the ones that I have not yet registered in anobii.
Nevertheless, I am looking forward to the 8th of October, not only because it is the anniversary of my friends Katia and Nea, but also because "The Lean Startup", an absolute must have, will arrive on the shelf of my favourite bookstore.
That said... I'll delve into one of the nine books I'm reading. At the moment, the target for 2011 is a modest 36 (exactly the half of last year), we shall see whether I'll reach it or not.
Etichette:
reading
Thursday, August 25, 2011
Page Hyerarchies in WordPress
While implementing the information architecture of a website based on WordPress, I kept trying to create a hyerarchy between the pages, failing over and over because the "parent" select was nowhere to be seen, even if the label was plainly there, happily mocking me. I googled for what seemes forever without coming out with anything good.
Yet, it just required the smallest amount of brain one can think of. It was Alessandro that pointed me to the simplest solution of them all: you have to publish your pages BEFORE you can use them in a hyerarchy. That's all :-)
What a fool. The answer was there, all the time.
Yet, it just required the smallest amount of brain one can think of. It was Alessandro that pointed me to the simplest solution of them all: you have to publish your pages BEFORE you can use them in a hyerarchy. That's all :-)
Etichette:
WordPress
Subscribe to:
Posts (Atom)


