Okay, so I'm almost a month and a half late in finishing this. And the content might already seem a little dated given RailsConf is currently on in Vegas and EuRuKo kicks off this weekend in Barcelona. But better late than never.
So in summary, how was it? Pretty good and great value. It wasn't blow my mind amazing, but there was enough good stuff going on to justify the trip. Plus Scotland is a beautiful country, and Edinburgh in-particular a great city, so any means of justifying a business expense to get there is worthwhile ;)
So onto the sessions I saw or chatted in depth to people about.
I'd heard of Marcel before, I'd even seen his name grace the cover of some books I own, but I didn't know much about him beyond that. For those like me, he was one of the original core team at 37signals that worked on Rails. And his keynote was quite a personal look at the beginnings of the framework. Digging up old usenet posts from DHH showing how he's trying to learn ruby, to slowly building the hype around rails, to a public release. For a presentation that was essentially reading old emails and newsgroup postings I found it thoroughly enjoyable. It was particularly interesting to see just how quickly DHH went from new to ruby to releasing probably one of the most widely used tools written in the language.
I'd had big hopes for this presentation. I've dabbled with geo-awareness stuff before, heck I've even written my own rails mapping plugin because I thought YM4R and the alternatives weren't very ruby (btw. it's in use for the collaborative mapping/direction site I quickly rustled up for my girlfriend Map.ly). I was really looking at some idea re how to make an existing site more "geo aware", and this presentation was little more than "how to put a google map on your site 101". For all my complaints about the existing plugins and their approach, they're still quite simple to use. With any level of ruby/rails knowledge, this talk could have probably been reduced to 5-10mins.
Scott is part of the team at Logical Awesome working on Github. He's also done the peepcode on git, and maintains the community book. He really knows his git, and by all accounts I'm disappointed I missed this one for the geo-awareness session. Thankfully the guys I pair with most days, Graham Ashton and Jon Ramsey, went and filled me in somewhat on it. The first half was a bit of an introduction on what it is, why it's different, how to use it, etc. that could mostly be ignored if you've used it at any length. Apparently the second half of the talk (which unfortunately he tried to cram into 10mins) was amazing. Showing how to use bisect to identify which commit introduced a bug as one of the highlights. The slides are available at github and hopefully the videos will be up soon.
A well times presentation for my perspective. I've been looking at a number of relational database alternatives of late for one of my side projects, and CouchDB had come up as one of the most likely contenders. So I'd done a fair degree of research on CouchDB itself, but not much on the most suitable adapter for using it with rails.
Alex did a good job going through all the various know adapters for talking to CouchDB (including his own, CouchPotato) and pointed out the pros and cons of each. Amazingly for a presentation like this he admitted that you should avoid his. For those interested, the winner was Paul Carey's RelaxDB. A point of contention which spilled onto the twittersphere was Alex's recommendation to avoid George Palmer's CouchFoo (George was in the audience). The rationale being that CouchFoo, much like CouchPotato, is too "ActiveRecord" and that document-based databases are different to relational databases so this means the approach must be inherently wrong.
Personally I think no, the rationale is wrong. Sure, you don't want to treat CouchDB like a relational database because you're missing the benefits gained in the document approach and kind of missing the whole point. But that doesn't mean ActiveRecord for CouchDB is wrong. ActiveRecord does not have to mean Object Relational Mapper, it's just up until this point it's all people have used it for. In fact, there is is nothing in the name ActiveRecord that inherently infers it is only for relational schemas. I think if people had grown up being accustomed to AR being an Object Document Mapper instead of an ORM then this argument would be moot. In rails you interface with an object, the adapter takes care of how to store it be-it in a document store or a relational store. We've got a pretty well documented API for AR, with lots of validation rules and other plugins that are useful. If you then decide to go build a relational schema in your document database that isn't the fault of CouchFoo, just like AR can't be blamed if you decide to try and keep everything in a single big flat table in MySql.
My own conclusion after some research was the two best adapters out there were RelaxDB and CouchFoo. RelaxDB seems the best (I'll go into details in a future post) but CouchFoo is ideal if you want to transition quickly or need access to some of the AR helpers/mixins. So all in all, a good presentation and made me go back and re-assess my own research on the topic and we ultimately shared the same conclusion albeit with different reasoning.
Probably not a lot to go through here which wont be out of date due to RailsConf. An interesting and high-paced presentation from Yehuda on what's coming in rails 3.0, some of the design decisions, etc. Probably not a huge amount of new information for anybody that had been using merb or following the public updates.
I often wonder how I'd go on stage in front of a bunch of peers, but I'm thankful that many of the presenters at these conferences looks as nervous up there as I'd be. Kevin made me rethink if I should ever bother. A really excellent and clear presenter that was a joy to listen to.
That being said, I didn't take from this as much as I'd hoped. It's my own fault as the talk was exactly what was presented on the label, mostly about why you shouldn't use fixtured data and then a look at what the alternatives are. I was looking for a bit more of a detailed comparison of the pros/cons of each of the object factory approaches (much like Alex had done in the CouchDB talk) but it was really just a cursory mention of them all and then a look at how to use the one Kevin had developed, ObjectDaddy.
I only caught the tail-end of this talk, but from those I spoke to it was quite insightful. Scott went into detail about how the developed a Facebook app and then needing to scale quickly to deal with the load. Everything from scaling into EC2, switching between technologies, and having to handle people trying to game the system. The 10 mins I saw were thoroughly enjoyable.
This is one that I felt wasn't at all what was described on the label. I'd normally consider deployment something more akin to "getting your stuff onto servers". Instead this covered lots of high-level architectural options you have available to you, the alternatives for each, but without any real explanation on why you should choose one over another. An interesting topic, but pitched to the wrong crowd with the wrong name I feel. Much better for manager types with little-to-no hands on rails experience. I think anybody who's actually deployed an application would have known the answers to all the theoretical questions raise.
The guy that brought is the Pragmatic Programmers and a number of ruby books and videos from that stable gave a great presentation on the object model with ruby. The shoeless maestro strutted around the stage and made what could be a very dull and overly technical topic seem approachable and simplistic. When you call a method where does it look to first to run it? Where does it bubble up to? In what order? And how do you access an anonymous method? All this arnd more was answered! Not sure if I picked up anything new, but it was a great cementing of my understanding in a highly graphical fashion. 6 weeks on when I'm debugging the internals of something I'm still visualising Dave's charts in my head to help me. Much of the content you can go through at leisure and in more detail in the $5 videos from pragprog.
Fernand took the noble risk of trying to do a live demonstration of the possibilities of using home automation with ruby. Thankfully for the most part it worked, and when it didn't he was entertaining enough to cover it and continue. And I have to appreciate the level of work that has gone into R-house and the libraries it depends on to make this happen, with such a range of different home automation equipment out there and each with there own slight nuances on how to interface it can't have been a simple job. A great presentation, not sure how soon I'll be able to use any of it though.
A presentation with no slides?! The horror!! Steven was another excellent presenter, and with a great presentation to boot. He went into what it takes to actually make a successful Rails app (hint: actually releasing it is a big part), and the advice was sound. The other big one which I think many developers ignore, I know I've been guilty of it, is trying to do the design yourself. Pay for a few days of their time and make it look professional. He was awfully opinionated on a number of topics without any real basis. That was fine when I agreed with him, I thought he was full of shit when he didn't justify it ;) One point that niggled at me throughout most of the presentation was that the reason I know of Steven and his company was through the the open-source Lovd by Less social networking framework they'd built in rails. I'd needed something like it once upon a time and looked at Lovd, and the code was horrible. So here I was being lectured by someone on how to make a Rails app who'd produced some of the ugliest code I'd tried to use.
Then the bombshell hit (paraphrasing), "I don't care what the code looks like if it works, just get it out the door and see if people like it. Anybody who's seen some of our code will know it's horrible". And he was right, on all counts. But...; I still had hesitations reservations. This was an open source framework, so the consumers in this instance are developers. So for the same reasons that you should get a designer to make your site look good for regular punters, I think you should take the time to make your code elegant and usable for developers. He's got a great looking product which does what it needs to, it's a shame that it's such a pain to use and made me question the validity of what he was saying. To that end, and rather than continuing to pay other developers to extend my own social networking engine I've taken it upon myself to fix everything I think is broken with Lovd. There's still a long way to go and I'll make a more formal announcement once it's nearer completion but it's already come a long way IMHO. Get it from github.
Reading through this initially I thought it was going was a bit of a sensational headline for what was going to be an intermediate level look at rmagick. And given my own experience with rmagick, I couldn't possibly stomach the thought of it ever being considered a viable photoshop replacement. I was wrong.
This was another thoroughly entertaining and informative presentation. Cory went through in detail the logic behind the one feature that has been making me want to upgrade to the latest version of photoshop, content aware scaling, complete with code samples. Next up was facial recognition which could be applied to suggest smart cropping, or apparently put party hats on cats. It's most likely made my CS4 upgrade redundant, which paid for the trip numerous times over.
It sounded like a boring topic, it should have been a boring topic, and a very odd note on which to end a conference. It turns out Joe and Jim are brilliant entertainers taking the audience through a hypothetical role play of a consultant coming in to refactor an existing rails code base. While it's unlikely they'll be invited back to do their return for the Edinburgh Fringe Festival in August, they thoroughly deserved their rapturous applause at the end. I've not got any notes unfortunately, I'm not sure if that's because I was laughing too hard or most of it was common sense. In any event, it was a great reminder that you should step back and look at you code to make sure you aren't trying to be clever for the sake of it. Simple solutions are often the best.
It was well worth the trip. The conference was super cheap so it's really not hard to justify the expense and Edinburgh is a great place to visit. I've been there as both a tourist and lived there for 12 months, so I'll do a subsequent post for those looking to attend next year with my own off-conference highlights.