NWE.pm Hackday lessons learned

[pozorvlak]

Last November a few of us from Glasgow.pm went to the North-West England Perl Mongers Hackathon, kindly hosted by Shadowcat Systems at their offices in Lancaster. The following are my notes on the day; I'd intended to present them at Glasgow.pm's December meeting, but the weather meant it was put off until the January meeting last night.

1. The night before, I met up with my friend Caroline for a drink. We hadn't seen each other for a couple of years, and it turned out that we had a lot of catching up to do, so one drink turned into two, which turned into five, which turned into a gig. Then I got up very early and got on one of these, which made me feel like this.
   
   So, Lesson Learned number 1: do not go out and get steaming the night before the Hackday, especially if you're travelling there by a very juddery train.


2. Some Modern Perl modules have very long dependency lists: Task::Kensho, for instance, depends on all of these modules. CPAN is great, but installing and testing all of those modules takes a long time. So, Lesson Learned number 2: if the project you're going to be working on has some dependencies, or is planned to have some dependencies, then find out what they are and install them beforehand. Dually, if you're running a hackday project and you plan to depend on some module or other, tell people about it and encourage them to install it in advance.


3. Lesson Learned number 3: you're going to need a version control repository sooner or later - you might as well set it up in advance and write the URL on the whiteboard for everyone to see when they come in. For a Hackday setup it's probably better to use a push model than a pull-request model; GitHub will support this, but you need to create a Hackday user and add everyone's ssh public keys to its keychain.


4. Communication is really hard. My first commit was at 16.47 because we spent so long arguing about what exactly Oyster was meant to do and how it was meant to work. Most of the time this was because there were people still arguing about things that I'd thought were settled.
   
   So, Lesson Learned number 4: this is one of those cases where it's better to make a decision now than to make the best decision when it's too late and everyone's gone home. And when you've made your decision, communicate it clearly.


5. Other lessons learned: Shadowcat (and NWE.pm more generally) are great people, Osfameron is a dude, pizza is tasty, and hackathons are great fun.

Thanks once again to the Shadowcat team for a great day.

Comments

[neoanjou.livejournal.com]

because we spent so long arguing about what exactly Oyster was meant to do and how it was meant to work

I'm not surprised. Reading the North-West England Perl Mongers Hackathon page, and the link to their wiki I can't find even a basic description of what it is/is meant to do.

[pozorvlak.livejournal.com]

There's this brilliant program/site called Heroku (http://heroku.com/). You call the heroku tool with the name of your new site, and it sets up a skeleton Ruby on Rails app for you and a git repository to host it. Then when you git-push to the repository, the new version of your app is deployed and immediately available at yourapp.heroku.com. Oyster is meant to do that, only with Perl and Catalyst rather than Ruby and Rails. But the question is, how much of that was it meant to do? The cloud provisioning? The DNS? Should there be a central Oyster site like heroku.com? What if people already have an Amazon EC2 account, and want to run their Oyster site on that space? Which of the many Perl module deployment tools should we work with?

My answers to the above questions were "yes, yes, yes, let them run their own instance of the oyster.com service with their own settings, dunno." But it was frustratingly difficult to get people to agree on what decisions should be made, or even whether a decision had been made or not - it kept happening that someone would say "we should do X" when I'd thought we'd already had a fight over doing X and decided not to do it hours ago.

[neoanjou.livejournal.com]

Thanks. I don't fully understand the context, but that makes sense.

I kinda wish it had something to do with Shellfish or TFL though :).

[plasmasturm.org (from livejournal.com)]

Maybe the answer would have been what it was on usenet: make an FAQ, ie. write down all the design decisions on a whiteboard, and maybe set up a network-local wiki and jot down all the positions that have been proposed and what the arguments were. (Briefly! It’s a lot of work to write things down. If the project is hackathon-sized, and it takes longer to write a coherent synopsis of the discussion than to have the discussion all over, then no time was won. (If the project will be large and the hackathon is only meant as ignition, then every second spent writing down design decisions is well invested. It’s almost more important than getting any code written at all, because those discussions take so much longer to hash out over the internet vs having them in person.))

[pozorvlak.livejournal.com]

We had both - in fact, the wiki (http://www.nwewiki.markkeating.me.uk/index.php?title=Projects/Oyster)'s world-visible. I guess what I'm saying is that the experience left me with a new-found respect for the difficulty of coordinating a roomful of hackers: next time, I'll write things down much earlier and more often.

[necaris.livejournal.com]

Heroku's really brilliant -- and IIRC they have some support for Node.js as well as Ruby? Which is something I've been meaning to try and explore...

[plasmasturm.org (from livejournal.com)]

GitHub will support this, but you need to create a Hackday user and add everyone’s ssh public keys to its keychain.

You can set up a gitosis repo for this (then you still need everyone’s keys, but gitosis itself is a snap to set up and provisioning a new repository is equally quick) – or better yet just run a network-local git daemon that has no authentication at all.

[pozorvlak.livejournal.com]

Yeah, I think we went the gitosis route in the end. MST handled that side of things.