Release the dogs

December 17 2011

I’ve been thinking about this post since a few months, and I’ve now got some more data to share about. the title stuck in my mind while listening to “Tomorrow Come Today” Boysetfire’s album, driving back home after an intense day of working with the team.

it all started in a study session on the XP practices, discussing what was stopping us from applying some of them. for example, Small Releases. the immediate objection was “well, we deploy more than once a week!”. in fact, user stories are moved to production as soon as they’re completed, validated and accepted. so, is this a non-sense question?

this week we kicked-off a new project, which is critical, because it aims to improve the company product’s core. the stakeholders asked for a technical solution that could answer the question “is this worth it? does the company receive any benefit from the new business rules”. so, we agreed on an architecture that keeps the two sets of rules in parallel for a short period, and as soon as we collect positive data, we’ll switch the product to the new system.

it took us two days to come with a Release Plan and an Iteration Plan for the first iteration. we collected themes and user stories, discussed a feasible architecture, then set rough estimates. this initial process showed we could answer stakeholders’ question in less than one month. then, it would take us another month to develop enough user stories to switch to the new system. eventually, we could then focus on the less important themes, which we didn’t even analyzed nor estimated, just tracked down on index card.

to recap, we focused on the smallest chunk of stories that could be put into production in order to bring value as a whole, and a release date has been attached to. then we iterated this process. the result is a three-releases plan, which is being adjusted and adapted whenever we found something new about estimates, technical risks, and the domain itself. we also know the first release it’s about two iteration long. then we know what’s going to be developed for the next two weeks, in much more detail, having discussed acceptance criteria and technical alternatives.

back to the initial study session, I think the problem is due to the fact we talk in Italian. the Italian for “release” and “deploy” is exactly the same: “rilascio”. we say “piano di rilascio” for “release plan”, and “rilascio in produzione” for “deploy to production”. combine this whit the continuous delivery practice gaining more and more popularity these days, and maybe the communication problem gets explained. to be fair, the project we referred to, deployed on production frequently, was more in a maintenance than a developing phase. there was no clear reasoning about planning. hence the confusion.

to recap, and to state a take-away message: don’t confuse release planning with production releases, especially if in your native language the two words sounds similar. my suggestion is to mentally translate to “milestones” for release planning, and to “deploy” for production releases. would this help you?

Mas vale tarde que nunca

November 23 2011

8th Italian Agile Day has gone. funny, amusing, almost interesting and well-scheduled. I had positive feedback about my session too, even if we were just 30 people (it’s no surprise, being Francesco in the room next to us!). don’t forget, I collected resources about my session here, as usual.

I’m late answering one of the question from the audience: “how to successfully apply XP while still having to negotiate contracts with customers?”. my humble answer was: I’m not an expert in this field, but I can provide links to further readings. so here it comes!

resources in English:

resources in Italian:

I’m glad someone asked this during my session, this finally forced me to collect all those links in one single place! and sure I’m referring this blog post again, really really soon..

Thank god it’s saturday

November 8 2011

I’m almost done.

rush to finish preparing stuff ’till late night yesterday, today I trained giving my team a preview, and I collected valuable feedback… but yep, I’m almost done! what the hell am I talking about? well, that’s my session for the Italian Agile Day 2011 conference, which is going to hosted saturday November 19th in Rome.

on my side, this is going to be the fourth year in a row preseting at the conference, and I’m very pleased. this time I’m experimenting something new, and potentially off-topic: telling a story about me as a musician, using this stuff as a medium to bridge a well-known domain with a relatively new field, at least for the newbies amoung the audience: live bands performance and successful XP teams. my hope is having the people not focusing too much on the (almost funny) story-telling, but picking some helpful hints.

conference got quickly sold-out, 600 people are expected to come, and there’s a huge waiting list. 25 session scheduled, as 5 parallel tracks. conference organization team did a great job, valuating and selecting sessions from more than 40 proposals: this is going to be the biggest event ever for the Italian Agile community, so far. what else? see you in Rome!

Cruising with clouds

October 3 2011

for all you monitoring guys out there, here’s a bunch of new stuff which I’ve recently added to Cruise-monitor. ready? here it comes:

  • Windows support (see documentation here)
  • CruiseControl.NET support, both for RSS feed (not available by default) and HTML project report page (see documentation here)
  • Jenkins support (minor differences with Hudson)
  • Rake tasks for configuring and monitoring
  • build server on Amazon EC2 (dog-feeding anyone?!)
  • Rake task for deploying configuration on EC2 and restart services
  • wiki documentation pages under revision control as well

porting to Windows has been tricky, because (no, you can’t guess it) tests where failing! after playing with sockets library a bit, it turned out to be a “missing” loop statement (while running fine both on MacOs and Ubuntu). even more, don’t forget the obvious filesystem tmp path! then, Microsoft Speech API was good enough to be wrapped by a script, in order to emulate say command.

support for CruiseControl.NET was funny to develop, because I had to force a little bit the code to host HTML parsing as well. in the end, relying on HTML and CSS styles is a bit too fragile, because, you know, HTML is going to be drastically changed. anyway, enabling RSS publisher you can start monitoring an RSS feed.

then, all the EC2 stuff. I’ve signed for a free micro instance, which seems to be good enough for my purposes. currently, CruiseControl.rb and Jenkins are running, with an Apache frontend acting as a proxy. all configuration is under revision control, deploy is completely performed with Ruby, as a Rake task, thanks to the net-ssh client and this nice wrapper script, which sends a bash script to be executed remotely.

I’ve also registered the free domain at, configured for the EC2 instance via DNS, thanks to the free service. www domain is served by the Apache frontend as a permanent redirection to Cruise-monitor wiki pages on GitHub.

finally, all documentation is versioned as a separate git repository, and eventually tested locally with Gollum. if only I could refer images as relative URLs instead of absolute ones..

anyway, I think it’s enough to say Cruise-monitor is evolving, and to be fair I’m really having fun. I’m not a tech zealot, so my appreciation of all the Ruby/Rake/Gem ecosystem is genuine. some SSH, Ubuntu and bash magic and it’s ready to serve!

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!

In my shoes

July 19 2011

back from an amazing journey in Crete: 11 days, 5 main cities, lot of beaches and towns only by public transports, hostel by hostel with a light backpack. can’t count how many buses and boats I’ve been taking. and, best of all, people I’ve met.

here’s a quick report:

  • day 1: plane from Milan to Hania. Agioi Apostoli and the Kalamaki beach
  • day 2: Gramvousa island and Balos beach, by boat
  • day 3: bus to Paleohora. sandy beach and pebble beach
  • day 4: Elafonisi beach and island, by boat
  • day 5: boat and taxi to Plakias, via Hora Sfakion. Plakias beach
  • day 6: hiking to Moni Preveli (Preveli monastery), then palm trees beach. way back by boat
  • day 7: bus to Rethymno. beach and old town
  • day 8: Panormo beach, by bus
  • day 9: bus to Iraklio. old town
  • day 10: Agios Nikolaos, beach and town, by bus. Kolokytha peninsula and Spinalonga island, by boat
  • day 11: Cnosso palace, by bus. historical museum and archaeological museum. plane to Milan

following is the initial plan, but of course, as any well-done plan, it has been adapted day by day:

pictures here.

sure, it’s been a tough journey: hostel owners were impressed by my willing to see as much as possible in so short time. sadly, I could not visit eastern coast, like the Vai beach. that could probably be the goal for another journey!

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!