the smart ones have probably noticed I’ve been lately writing much more about traveling, friends, mood, and fewer about software in general. nice shot! in fact the last 6 months have been so full of news and changes for me, in my private and personal stuff. don’t want to bore anybody, but: I’ve moved to a new flat, which j’adore, I traveled a lot (Spain, Crete and southern Italy), and finally bought a car (this is such a big change!), to name a few.

but only the smarter ones could have guessed it was due to kinda a “tiny” breakdown I had, and thanks to friends it’s all gone. funny enough, at least when I tell people about, it seems to be an “age of 30” breakdown!

anyway, I’m not done with telling you news. in fact, in order for you to understand how I could travel so much, and spend so much time on my own, you miss one more bit. here it goes: I left my job.

past year has been really tough. first, I learned new stuff and skilled a lot on system administration and shipping to production. even more, my company had a major internal restructuring, so my team no longer belonged to Sourcesense but had a brand new home: XPeppers.

big changes outside, big changes inside. that’s when I realized I should have had some time focusing on myself. and quitting my company was a natural choice. bank account said saved money was enough for a few months off. so I embraced change without fearing the future too much. sure, I briefly looked for open jobs in Europe, and Milan as well, but targeting a very long holidays before starting any new job.

and we’re done. next week I’ll join 7Pixel Nautilus team, where I’ll meet two ex colleagues: Davide as a full-time coach, and Antonio as a uber senior developer. this means moving from customer development and even consultancy, to product development, facing both internal stakeholders and the market.

can’t really say how much I owe Matteo and Orione team, and all the people at Sourcesense and XPeppers. I had more than 3 years of intense learning and fun, working side-by-side with skilled people in Milan, Rome and Amsterdam (shame is I could not join UK people too).

well, don’t forget they’re hiring!


Robots invasion

May 6 2011

again, and again, and again.. “how can I test this”? same old question.

this week my team had to “instruct” spiders not to follow certain links, in order those not to be processed by search engines indexing process. given robots.txt is a standard de-facto for this, we tried to test this behaviour. we initially only found syntactic check tools, useful while developing, but not enough as a safety-net against regressions. so, we later decided to go a bit further: testing that the actual URLs were not processed by spiders.

having a robots.txt file published under the site root with these rules..

User-Agent: *
Disallow: /shop/cart
Disallow: /shop/one-page-checkout

.. our goal could be easily documented by the following test:

test "should skip disallowed paths" do
  lets_crowl "/shop/cart"

  lets_crowl "/shop/one-page-checkout"
  lets_crowl "/shop/contact-us"
  assert_surfed_only '/shop/contact-us'

next step was running this test against a local development server (http://localhost:3000 for a Rails webapp). spiking around, I started looking for existing spider engines, written in Ruby so that I could easily integrate into our test codebase. it took me one hour for evaluating tools: the winner was ruby-spider, forked from Spider.

we actually start a new Spider intance, run it against a given URL, check if it was allowed to surf it or not. then we “stop it”: this is done instructing the Spider to only process URLs that match the exact target URL. otherwise, the Spider would continue processing every URL found in the HTML response, recursively, and so on.. extra points would be setting a timeout to the test, or a max depth. anyway, here’s the fixture code:

def setup
  @surfed_urls = []

def lets_crowl(target_path)
  Spider.start_at(local_url(target_path)) do |site|
    site.add_url_check do |an_url|

    site.on :every do |an_url, response, prior_url|
      @surfed_urls << an_url

def assert_surfed_only(path)
  expected_url = "#{local_url(path)}"
  assert_equal @surfed_urls, [ expected_url ]

def assert_nothing_was_surfed
  assert @surfed_urls.empty?

def local_url(path)

last thing done: running this test against a test server. shame on me, I could not manage to setup a Webrat integration test (server is in-process). so, after verifying our staging server would have really slowed down the test suite, I went for a Selenium test: actually, I only changed one line of code, switching local_url to http://localhost:3001. really, really nice!

Video from IAD 2010

December 9 2010

just updated personal page adding links to both slides and video for the presentation I had at the last Italian Agile Day 2010. enjoy!

Thank god it’s friday

November 18 2010

have you got any plan for next friday, november 19th? still puzzled by all that Agile thing? good news: people from all over Italy are meeting in Genova, to discuss, debate, questioning, maybe learning something valuable for their company and team.

Matteo just published a brief tourist guide for anybody new to Italian Agile Day conference, 7th edition! we’re both hosting sessions, but please have a look at the official agenda: four conference rooms, sessions from 11 to 18, with additional rooms for openspaces discussions and lightning talks.

I’ll be posting slides and code samples from my session here.. see you in Genova!

Killing me softly

May 7 2010

continuous task switching: that’s it.

can’t manage to work developing one project, following production setup for a second one, doing email/phone consultancy on a third one (where I’m officially no more involved), then helping colleagues in Rome spiking around with a fourth one.

I’m broken.

even more, our near past and future involvment as a team on customer-side is managing a pipeline of (initially) four projects: then (working targeting success) this is getting broader, and more projects are expected to be started on a monthly basis. this is probably the most interesting thing: a shared release plan, one team, more projects.

and a single source for budgets. expect more on this soon..

this is the transcription of the 10-minutes lighting talk i had last weekend during our company meeting in Amsterdam, which is based on the great article by Alistair Cockburn “Incremental means adding, iterative means reworking”. so, here it comes..

Incremental vs. iterative development

every project is big enough not to be completed just in one shot. so, we focus on delivering subsystems on a regular basis, e.g. one or two weeks. we face complexity with simplicity and feedback.

first strategy we can adopt is delivering complete subsystems, every week, splitting projects into small chunk of complete functionality, also known as user stories. we add features every other week: this is incremental development, the heart of every agile process.

in other words, we try to get it right in the first place, targeting quality for a final product.

another strategy is reaching the final product by revisions. we start from a rough prototype, and improve it by later adding details, till the final result. we do reworking: this is iterative development.

a great essay on the two strategies is Jeff Patton’s Monalisa example, as reported by Gojko Adzic on the waterfall trap.

back to the initial motto, here is my suggestion: even if you’re already doing incremental development, don’t forget to iterate. (it’s a shame the term “iterations” does not relate to iterative development, but to incremental development!)

why? because customer, not us, choose when to stop incrementing (adding) and iterating (reworking): you’ll be surprised by what a customer can consider good enough.

Time for an example

my team is currently working on an e-commerce website, and the customer asked for a complex checkout procedure: adding items to the shopping cart, mandatory login, shipping and billing addresses, payment details (e.g. credit card info), and finally a checkout with notification via email and to the reporting system.

during release and iteration planning, we first asked the customer to split the procedure into smaller user stories, so that we could understand and estimate with confidence. then, we started developing the most important ones; for example, no billing address nor reporting system notification were chosen.

this is incremental development.

one day was the turn of the shipping address user story: calculate shipping costs for each country (Italy has a fixed cost, other countries costs are taken from the database of our customer’s shipping company), displaying italian provinces when shipping to Italy, validating zip codes when in Italy (CAP). everything in a dynamic fashion.

having a lot of work to do, we decided to start with a minimal layout: a combo box for countries and a text displaying shipping costs for current country. it was far away from the final product, but gave us feedback that everything was working, from UI to database import script.

shipping costs

later, we decided to put two forms, for Italy and other countries, into the same page. that was an easy way for having a different layout and data for Italy. again, it would have probably not been the final product, but helped us focusing on designing UI and setting up data.

two shipping addresses

we finally moved on trying to understand how to dinamically change layout, based on current country. first idea was to use Javascript code client-side: something like having two hidden forms from which setting a third form’s innerHtml, and the like. we did a spike, but our result was not satisfying.

then, having our iteration going to end soon, we decided to propose to the customer a simpler way: an onchange event on the country combo box! dynamic, but server-side. it took one pomodoro for spiking a solution. then we just asked the customer, and after other two pomodoro of layout restructuring, it was done.

that was iterative development.

shipping address

hope it does make sense to you: increment on the long term, iterate day by day!


September 24 2009

after almost a full day of nervous coding and testing..
trying to simplify a complex scenario..
before making it more complex with new requirements..
i finally found out it was easier than i thought..
simply asking the customer what he wanted.

so, please, don’t forget to ask the f**ing question!