Rails Camp NZ Wrapup

Months of planning culminated last weekend in Rails Camp NZ. I first posted to the Rails Camp Google group with the idea in December 2009 so it's been a while to get every one on board and an event actually happening. The event was from my perspective a success with everyone going away happy as far as I can tell. There were a few hiccups in getting things going properly as we don't have as much in the way of experience running Rails Camps in NZ but after a somewhat hectic week leading up to the event and Friday night, most things ran smoothly.

The weekend saw the development of a number of cool things, particular things I noticed included: a distributed achievement system using bananajour, quite a few Refinery plugins, rornz, a javascript game engine and a game where you click on ruby programmers in questionable swimsuits. It was great to see people being pulled onto things and building into a proper NZ (and AU) rails community.

We had a good selection of talks including: coffeescript, javascript, engines in 3.1, balsamiq, people who go to SXSW are cooler than you, vim, web servers and  although I think I'd like to look at building a scheduling system for them on the server next time around  so that short talks are handled better than the current system of squares on the whiteboard. Coming prepared with all the stupid mac display adapters will probably also help.

I didn't really have time to do a lot of sponsor hunting this time around but the two we did have were awesome Ninefold sponsored what turned out to be awesome coffee and 3months helped out with getting wifi gear at the last minute. In the course of the 44 person camp around 400 coffees were made using these coffee machines. I think they can be called a roaring success.

Coffee thanks to Ninefold

 
The hardest part of running Rails Camp in terms of getting under way with planning was finding a venue as it's quite a time commitment in the weekend to drive out to various places and find somewhere suitable for us. Camp Kaitoke basically won us over by being the friendliest and promptest with emails and when we saw the place it looked really nice(as a number of people commented at rails camp). Really I think friendliness should be the key factor in picking anything like this, it makes the staff much more friendly, even when they see the first three people show up with three kegs(Henry Collingridge did a great last minute job of organising people who wanted to do a group beer thing).

We do have a lot of room to grow if we use the venue again as we used the lunch hall for coding and another room for presentations, but there was also another large room and a small room available in other spots if we had wanted to spread out more. The large room we didn't use was particularly notable for having a proper roof mounted project setup, unfortunately the projector was stolen. I'd also have liked to see more use of the gymnasium, the two person game of basketball I fit in was a good way to recover from some of the Sunday morning sleep deprivation, but it's not easy to have pick up games in it as people can't see in from outside the building.

I do advise others avoid setting their Camp dates for shortly after a national disaster. Having a few people people out or just not sign up because of earthquake pressures was a real pity. Losing the networking gear when I had already relaxed about that area of things was a pain and meant that the number of things sitting on my todo list really close to camp dates got uncomfortably large. It all mostly turned out ok but networking wasn't as tidy as I would have liked it to be.

Ticketing started off with a bang and then slowed down a lot. There were a couple of months where I was quite worried about us not making enough sales to cover minimums at the venue. They picked up a bit, but I did end up spending a lot of time hunting people down and giving them the hard sell to convince them to come. In general we had a lot less locals than I would have liked. But people went away positive with a lot of other Kiwi's interested in running or helping run the next Rails Camp NZ so I think we're going to grow a decent amount and the event will be able to run a lot more smoothly with more people to spread the organisation around. 

Given that there shouldn't be a problem with having to pay for extra bunks next time around and that we've proven that we'll get a decent crowd it should be possible to lower ticket prices a bit next time around and to drum up a bit more sponsorship. We only really started looking like we'd definitely have more than 30 people in the last week of sales and it was hard to claim that we were a serious thing with so few people signed up. I'd like to also make a more explicit effort to pull in people who may not be able to afford full priced tickets for whatever reason. A couple of people who were a bit cash-strapped at the time are paying me back when they get the chance, but that only covers people who I was prodding directly.



Werewolf continues to be a brilliant way to meet people at camp and remember learn people's names. I did a lot of "Who are you?", point, "Yeah, you're the werewolf". Unfortunately Phil Arndt and I played up our roles as lovers a bit too much in one werewolf game and ended up getting paired a lot throughout the weekend to the detriment of our survivability.

I'm going to do another blog post in the next few days covering all the networking and server stuff as it started off a bit chaotic, though it doesn't seem like many people noticed as Friday night is pretty much beer and meet people time. I'm hoping for the post to also serve as documentation for how to set up this kind of thing in the future without our approach of having a general idea and then changing settings until everything worked.
 
Ryan Bigg has already written a write-up that covers a lot of what happened at the camp from the perspective of an attendee who pitched in a decent amount as well.

Crafting Rails Applications Review

Jose Valim is well known in the Rails community for writing a lot of code and being on the Rails core team. He's also to blame for Inherited Resources a plugin that I've seen be more horribly misused than any other. He's one of the most qualified people you could get talking about some of the more advanced tricks that are present in Rails these days and Crafting Rails Applications really does cover a lot of ground in intimate detail.

Crafting Rails Applications is a tough book to review, there's a lot of really good information in it that can't be found anywhere else short of reading through the Rails source and trying to work out what's happening. But, anyone who really is going to get a lot out of the book is going to end up reading a lot of the source anyway. A good deal of the information in it will be of more use to people creating plugins and engines than the general run of the mill development people involve themselves in. This may be a reflection of Rails maturing as a framework in that it's starting to really support expert level content being published as books rather than disparate blog posts.

The book covers a wide array of the new features in Rails 3, but unfortunately it isn't particularly well organised making it difficult to use as a reference book. Much of the book is spent examining the status of various features of the rails rendering stack, this is interesting information and there's use for it when building something like a CMS, but outside of that I can't see it being used for that very much. Indeed, of the topics that are explicitly addressed I have only needed one of them in the past(Building a translation module for kete using mongomapper)

On the other hand, throughout the book there are lots of little tidbits and functions of Rails that I did appreciate learning and will use in the future. The poor organisation makes this a book to read with a notebook or sticky notes at hand to keep track of things that interest you. And the section of creating custom responders in particular was an interest addition that I'd quite like to try for cleaning up code.

The book suggested layering custom responders on top of custom renders as a powerful way of tidying things up. That might have been the aim in tying things together but I think for most development shops that would lead to entirely too much magic and the code becoming quite opaque to less experienced developers. Worthwhile if you're writing a plugin that needs the powerful generic solution, but not something I want to see everyone using.

One particularly useful bit of coverage is Rails engines, they aren't covered in any section in a particularly focused fashion but are used a lot and the demonstration 'Enginex' gem helps with creating them. If you've been wanting to work with engines this is probably the best overview of them that has been published so far, although that is perhaps more of an indictment of current resources than anything else, hopefully some of the upcoming rails books will deal with them more explicitly.

Is it worth reading? Yes, but there are a lot of other books that you should definitely have read first before this gets to the top of the reading pile. If you're doing a lot of work with plugins or gems, or one of the chapter headings jumps out at you as something you need to do soon, then pick it up with haste. But if it's just on your reading list out of interest then in the Ruby world Metaprogramming Ruby is a more important "advanced" book and I'd also suggest reading more broadly in related technologies before hitting this book.