Of course there are tools like Jekyll, but they kind of force you to adopt their conventions when you write your site.

What I'd really love to do, is to write my web site using one of those nice web frameworks we have now, update the data in there using all the nice tools they provide, and then generate the static version of the site to deploy. Most the fancy "dynamic" stuff can be handled with JavaScript on the browser.

This is what wallflower does. Given a list of URL and a Plack application, it will save all those URL into a set of files, ready to be uploaded.

Some advantages to this approach:

• works with any Plack application
• all the data entry can be done offline, running plackup myapp.psgi (or whatever your web framework offers) on your laptop
• no need to setup a web server to generate the data
• no network involved: it's faster than wget -m
• publishing is as easy as ./generate_urls | wallflower -a myapp.psgi -d output && git commit -m "Site update" && git push

The next step is to pick all the local links from the pages, to crawl the whole website from a limited set of starting points. This is on my TODO list.

Try it!

Back in October 2010, at OSDC.fr I saw sukria's talk about Dancer. Of course I loved it. However I'm a rather shy person in regards to web sites.

I find that static web sites have a lot of advantages:

• they are easy to setup anywhere (just upload the files)
• they have no security issues themselves (of course the webserver may have some)
• they don't need maintenance

A discussion started, with (as far as I remember) Marc Chantreux, Alexis Sukrieh and Franck Cuny (the great thing about Dancer devs, is that they attend conferences in France!).

We were saying:

• Wouldn't it be great to be able to have say, a blog, written in Dancer, but entirely static?"
• We could always deal with the comments at an external site, with clever use of JavaScript...
• Hey, That's another great project!
• Too bad we have so little time...

(We later found out about DISQUS)

A tool for making a static web site out of any Dancer application, that would be neat. After Alexis' talk, made with Broadway, and Franck talking about jitterbug, it was obvious we needed to make a dance-related pun.

And in fact,I knew exactly how to describe it. It was like the people at a party that do not dance, and always have a perfectly good excuse, like "Sorry I can't dance, I'm holding on to my friend's purse".

Lacking the English name for those, we still didn't have a name for the project, until Alexis popped up on the IRC channel a few days later with a link to the urban dictionary definition of wallflower. After a little time spent search on YouTube, I found the perfect example of a wallflower dance.

Because a good pun should never be wasted, a first version of the program has been included in Dancer since version 1.3000_01. Very early on, Vincent Pit remarked that (besides the name) it really had nothing to do with Dancer, and was all about Plack. This has been on the back of my mind ever since.

The App::Wallflower module is the proper, Plack-aware, version of the original program. As said in the documentation:

wallflower treats all Plack applications equally, even if the first version of the program was targetting Dancer only.

Thanks Plack, for helping us to be so inclusive.

In this post, I'd like to give some information about the organization.

The idea of doing a QA Hackathon in Amsterdam actually dates back to the 2009 hackathon in Bimingham. At the time, Abigail and I both talked with Barbie about doing it in Amsterdam, already counting on our employer to sponsor it. Then we went back to work, and time slipped.

Lars (daxim) and the Vienna.pm team announced the 2010 QA Hackathon in Vienna at the time we were actually starting to think about doing it in Amsterdam (i.e. it was much too late for us to actually organize anything). At the end of the QA Hackathon in Vienna, I was a little more explicit about doing it in Amsterdam.

In December 2010, after almost abandoning the idea of doing a QA Hackathon in Amsterdam, I finally went to our IT Director to talk about it, and he really liked the idea. Booking.com instantly became a sponsor and a supporter.

Budget

Booking.com not only sponsored the Hackathon with money, but also with the venue and network, with all the lunches and some employee time (Erica and myself).

The Perl QA Hackathon is also a community event, and no less than four Perl organizations (Vienna.pm, the YAPC Europe Foundation, the Enlightened Perl Organization and the French Perl Mongers) have supported us with money.

This hackathon was also special because contrary to the previous two, there was official organization directly organizing it (Birmingham.pm in 2009, and Vienna.pm in 2010). Which means there was no bank account for the event.

Luckily, the YAPC Europe Foundation was able to support the Hackathon with its bank account: it accepted all the donations on behalf of the organizers, and donated money back from that budget to cover the expenses incured by the event: 11 people received a donation to cover their travel expenses, I arranged payment for the accomodation and what was left to pay for the dinners and will also receive a donation to cover that.

Here is a summary of the Hackathon budget:

Don't forget the very generous sponsorship that are the venue and lunches: a hackathon having to pay for those definitely needs to include them in their previsions...

So, after taking the bank fees into account, this hackathon made a profit of 1061.31 €. This is a final budget. (This post was updated (twice) with the bank fees to make the budget final.)

All the surplus money from this QA Hackathon will integraly be given to the organizing body of the next QA Hackathon, as a kickstart donation.

The dinners

I wasn't really sure if the dinners should have been paid by the Hackathon or not. At first, none would have been paid, because the budget could only cover travel and accommodation. But then Alias' flight was covered by his work, so the budget suddenly had a surplus instead of a loss.

Having a surplus felt great, and given I expect there will be another QA Hackathon next year, it would be very nice to start a tradition of sponsoring the next event with the surplus of the previous one, like YAPC Europe conferences do. This is especially relevant this year, because there was no non-profit organization holding the "organizer" role. We started with an empty bank account, and YEF can't and shouldn't keep the surplus for itself.

Still, some of the attendees were students, and didn't have a lot of money (and remember the attendees are giving their time and work to help improve the toolchain), so it would harsh to ask them to pay for a restaurant that they didn't choose and that didn't match their budget.

In the end, I settled on the following slogan for the dinners:

If you pay for yourself, it will be appreciated,
if you don't, it will be taken care of.

The total dinner bill for Sunday evening was about 1050 €. The organization only had to pay around 280 €. Which means the attendees basically sponsored 770 € to next year's budget simply by paying for their evening meals that night.