casperfabricius.com

RailsConf was a blast. But I barely had the time to consume all the impressions, since my vacation was just after the event in Chicago. So I went directly to Roskilde Festival, North Europe’s biggest festival with 100.000 partying people near Copenhagen, Denmark, and from there I got on a bus to Rumania as part of choir singing Danish songs in the Rumanian churches. When I got back, I realized my blog had gained quite a lot of attention (at least compared to its very silent past), not at least my posts on David Heinemeier Hansson’s and Paul Graham’s key notes. While 70 subscribers and 200 visitors a day doesn’t sound like much to some, it fills me with a certain amount of humility: “Surely people will expect my future to be of high professional quality and deep insight”, I think.

See, my problem is, that while I seem to do pretty good on referencing what really, really smart people say and adding a bit of my own pocket philosophy, I find it a wee bit harder to provide genuinely usable Rails knowledge on my own. I have plans for posts about my on-going experiences with Substruct, and about my struggles with actually being RESTful when developing, but for now, as a way to scare most of my newly gained audience away again, I’ve decided to write a completely non-technical and probably quite un-insightful blog about some the great people I met at RailsConf.

Always taking the analytical approach to things, I have divided those people into two categories: The VIPs and the VFPs. The first are VIPs of the Rails community; key note speakers, widely read bloggers, authors, etc – people I wanted to meet because I admired they work, but who won’t actually remember they met me afterwards. The second are some of the Very Friendly People I met at the conference, that is; people that I didn’t know beforehand, but that I ended of talking a lot to during the event. Of course the VIPs where also friendly, and the VFPs are probably also important (to some people), but most likely being a clever geek, I’m sure you get the idea.

VIPs

David Heinemeier Hansson: Of course everybody at the conference wanted to meet DHH, and my twist was supposed to be to surprise him by talking Danish to him. In fact I happened to be talking to David Black when DHH came along, and Black was so kind as to introduce us and take our picture, but there wasn’t any time to talk further, so I can’t say I have any insight on DHH I can share.

Geoffrey Grosenbach: I had a great deal of respect for Geoff because of this persistent work with the Ruby on Rails podcast and his many insights about deploying, so I really looked forward to attending this talk and meeting him. It was strange to look at the guy and hear his unique voice I knew so well from the podcasts; kind of like meeting some one talking like Darth Vader.

Amy Hoy: Amy is – literally speaking – a colorful part of the Rails community. Probably the most well-known girl in the community and the only female speaker at the conference, I of course had to meet her. I did, and she willingly lined up for a photo. What I don’t like about Amy is that she keeps reminding me that good – and fun – writing is hard work, and I just don’t have the patience to rewrite a sentence five times like she does, which means that my blogs will never match hers in enjoyability, I’m afraid.

David Black: I meet Black at “day 0″, where I didn’t get to participate in the Guidebook session, so I went early into the room reserved for improvised events, where he sat all by him self with his Mac. I didn’t know who he was – in fact, I thought he looked completely wrong in the setting (remember, the conference wasn’t started yet, and I hadn’t yet realized that Ruby gurus generally mature, bearded men), but he explained to me that he was the organizer. Later that day, I bought Black’s book in Chicago and got it signed by him – nice!

VFPs

Tim Trautmann: Migrated from Germany, Tim was the closest thing to a European I got to know at the conference. We enjoyed a nice dinner Friday, and he was part of the drinking buddies sitting outside the bar. Tim is a consultant, having a one-man company with a funny name I seem to have forgotten.

Jeremy Seitz & John: When I realized that nothing was going to happen at “day 0″ besides the Guidebook, I went to Chicago. I met Jeremy and John waiting for the shuttle bus, and we ended up buying a brand new Macbook for John at the Chicago Apple Store. I can’t seem find John’s last name or blog, but both of J’s was great fun to hang out with through out the conference days.

Brian Eng & Jeff Cohen: Meeting the Softies was definitely one of my goals at the conference since I really like their blog, and they turned out to be extremely friendly and great company. These guys actually works in cubicles like they do in Dilbert (which only seems to amusing to Europeans), so you’d think they be grumpy and bitter, but they where all smiles and even paid for our dinner at Chilies – I owe you one, guys!

Hisa: This cool Japanese actually wrote the RubyCocoa framework, which I definitely want to try out once I get my hands on a Macbook, and we talked many times during the conference. Hisa wasn’t bothered about his English being a bit rusty, and a really funny thing he explained to me, was that he found it just as to distinguish between western people, as we often find it to distinguish between Asians. Fair enough!

Jim Greer: Once the conference ended Sunday afternoon, Jim was one the people that – like me – was staying at the hotel till Monday. A minor hack fest formed in the bar that evening, and I sat opposite to Jim, writing on my blog about DHH’s key note. I discussed the whole normalization issue with him, and this actually inspired Jim to start up his blog and write his first post, which was later referenced in DHH’s blog about the issue. Jim is starting a web game company in England, and I’m pretty sure he will be a success.

Victoria: I had a great conversation about everything from the Rails community to the differences between USA and Denmark with one of the very few girls at RailsConf, while I was trying to spot James Adams, the creator of Rails Engines, with out any luck. Victoria was attending the 37signals workshop the following week, and I believe she promised to blog about it…

I met plenty of other nice and friendly and important people, but this has to end some where. I wish I could finish telling you how I much I look forward to RailsConf 2007 and seeing some of these people again, but the fact is that it’s very unlikely that I’ll be there. The conference is in May, and I’m in school – what do you do in school in May? You have exams. Tough break.

(Looking for DHH’s keynote at RailsConf Europe 2007? Find it here)

I’d been looking forward to David Heinemeier Hanssons (DDH) key note in the same way I’m guessing people looks forward to hearing Bill Gates and Steve Jobs talking at the big Microsoft and Apple conferences. Any community needs its mythical founder amongst whom the community can revolve, and DHH makes a good job of filling that role, backed up by wise men such as the Fowlers and the Pragmatics.

DHH had just returned from a trip to a Ruby conference in Japan, and – still very much jetlagged, as he explained later that evening in the bar – introduced the topic of his key note: CRUD. Create, Read, Update, Delete. An idiom so widespread that they even teach it in my Java-centric school, an abbreviation that lays out the four basic operations of manipulating database tables. DHH explained that he has lately started seeing all his code in the light of CRUD, in fact, he starts to spot “crudness” everywhere – perhaps CRUD can be used as the basic pattern for making beautiful code?

DHH pointed out the similarities between CRUD, database operations, Rails actions and – last but not least – the http methods:

• Read, SELECT, find and GET
• Create, INSERT, create and POST
• Update, UPDATE, update and PUT
• Delete, DELETE, destroy and DELETE

When you browse to a url like GET /people/show/1, you are basically repeating yourself: show is redundant, because the http method sent by the browser has already specified that you want to do a GET. So the beautiful version of the url would be GET /people/1, just as PUT /people/1 is more beautiful than POST /people/update/1.

The problem is, however, that even though the http protocol specifies all of the mentioned methods, only GET and POST has achieved wide spread use, and thus, specifying PUT or DELETE as the method on a form tag won’t work as intended, since browsers just ignores it and defaults to GET, and if even if it is capable of passing the method on, many web servers and proxies sees the use of methods like PUT and DELETE as unsafe and rejects them. No problem, DHH said, we’ll just fake it in Rails using a hidden field to specify PUT and DELETE methods. This should raise some alarm bells, he continued, and it certainly did with me. By using a hidden field I get ugly flashbacks (well, wish they were flashbacks, I’m still doing loads of .NET) to the heavy use of hidden fields in .NET which result in 500 KB pages – excluding images – so asked, at the Rails Core Q&A session, if this wasn’t a slippery slope taking Rails in a wrong direction?

No, DHH answered without hesitating, we’ve done plenty of things that could be a slippery slope before. It’s a hack, and we might be able to take it away eventually, but right now it’s the way to go. I guess I’ll just have to try it out, since the Simply Restful plugin, which promotes this kind of urls, will be implemented in Rails 1.2, according to the Rails Core team (and they should know it).

Tightly connected to the point about restful urls, is DHH’s newly found desire to promote controllers that only do the four CRUD operations. Basically, he argues, if you have more than the default actions in a controller; index, show, list, new, create, edit, update and delete, you haven’t thought enough how to structure your controllers and actions. If have “scoped” actions like add_user or post_comment, you haven’t “crudified” your application, and you should move those actions to a UserController or a PostController.

As I discussed later with Victoria, many of the brilliant people at RailsConf are self taught college drop outs doing cool projects their own way, instead of worrying about learning the “right way” at school. But with this “crudness” or “crudiness” DHH wants the controllers to respect, I actually think he is trying to phrase a concept both of us learned about, while getting our bachelor’s degree in Business Administration and Computer Science at the Copenhagen Business School: Normal form. Normal form is known concept throughout logic, language and mathematics theory, but from my education, I know it from database theory. It’s all about optimizing your database by normalizing your tables into a certain normal form, and I’d guess that’s what DHH wants us to do: To normalize our controllers.

I realize DHH is not too interested in databases – during the Rails core team Q&A he said in fact: “I don’t like databases. I pretty much use them as hashes.” – but I like the analogy, and I propose we start talking about normalization in this context, because really, normalization is just another word for beauty. However, beauty is a bit unspecific and it’s widely used to describe anything good in Rails, so why not instead say: I’ve normalized my controllers and action to the CRUD normal form. There are in fact things we can learn from traditional school paradigms such as relational algebra or object oriented design, or maybe it’s just general programming wisdom which has some how snuck into education, and one of those things is this: “If you think about it a bit harder, a simpler approach will appear.” (DHH). You do this when you normalize databases. You do this when draw UML diagrams. And now you should do it when you normalize controllers – think simpler, think CRUD!

But: CRUD is not a goal in itself, it’s an aspiration, a design technique, DHH emphasized, and normalizing (“crudding”) won’t be the answer to everything. Basically though, you can normalize anything, and DHH gave examples with the state of case having its own model and its own controller – this way, the CaseController was normalized, and didn’t have to had any add_state actions or something like that – instead, these actions was implemented in the StateController through the standard CRUD actions. At first, DHH explained at the Rails Core Q&A, he thought login was an example of actions that couldn’t be normalized, but Jamis Buck had the solution for this, implementing CRUD actions on a SessionController, since that’s basically what a login does; adding and removing stuff in the session.

Enough with the theory. The big revelation of the key note was a new API DHH started hacking away at two days before the key note; Active Resource. The API is basically all about describing things as resources, and as I understand it after discussing it with Geoffry Grosenbach and Chris McGrath, it’s basically an alternative to Action Webservice based on the REST concept. Since it’s still work in progress, I’m not really sure it’s going to work at all, but it seems like it will usable for both providing an API as well as consuming it. I guess DHH don’t want to repeat the work on the Basecamp API now that he is doing Sunrise, but also, he wants to emphasize that almost anything can be viewed as a resource. Active Resource will be released as a small, compact plugin as part of Rails 1.2.0, and basically, it sounds like that release will very much focus on the REST principles, and on making the Rails core smaller by pulling thing out in plugins.

The example DHH gave on using Active Resource was based on his notion on viewing XML basically as a hash. So perhaps your code would look like this:

Person = ActiveResource::Struct.new do |p|
	p.uri “http://www.example.com/people”
	p.credentials :name => “dhh”, :password => “secret”
end
matz = Person.find(1)

- and Active Resource will automatically wrap the XML response, which could look like this:

<person>
	<name>Matz</name>
</person>

For now, we’ll just have to wait and see what turns up in Edge Rails and try it out.

Paul Graham delivered a brilliant key note at the first day of RailsConf, with jokes and insights coming so fast in succession that it felt like a new chapter in his trademark book; Hackers and Painters. It is impossible to do Graham’s speech justice in a blog, as the softies realized, but I got pretty decent notes, so I’ll give a try anyway.

Graham titled his keynote “Power of the marginal”, and his theme for talk was just this: The advantage of being an outsider, and the amount of great ideas that stems from outsiders. “Using Ruby on Rails is a marginalizing yourself – welcome to my world!” Graham said, hinting his preference for Lisp as a programming language. He pointed out that there, due to the definition, will have to be more outsiders than insiders, and that this is part of the reason that most of the good ideas comes out the marginal. But that’s not entire reason – there are actually several disadvantages to being an insider:

• You will often select the wrong people from your pool of other insiders
• You need to seem serious
• You want to avoid risks
• The task becomes a duty, rather than being pleasurable

You can pass a test either by being good at it or by being good at hacking it, and you can tell how interesting a scientific field is by the overlap between its practitioners and the people who teaches it, where you have, on one end, mathematics, where all the great scientist are also the best teachers, and on the other end you have computer science, where the people who can’t do, teach. Grahams point with this was that you shouldn’t learn things from people who are bad at those things. He also points out that it’s hugely valuable to be able to look like a fool, to make mistakes – something insiders can’t afford to do, because they want to stay insiders – but something outsiders can without a worry – they are already outsiders. Bottom line is that stupid ideas don’t make you stupid – it takes many stupid ideas to come up with a great idea.

Another advantage of being an outsider is you have lots of time. Successful people often answer, to the question on what’s wrong with their life, that they don’t have enough time. Everybody wants a piece of them, and that way they loose a lot of the freedom they had as outsiders. (This point actually made me feel bad for pulling DHH into a photo with me earlier that day, since that’s a perfect example of an outsider taking a bite of an insider.) So being an outsider, you should take advantage your freedom, and be flexible instead of being ruled by plans.

Repeating some his well known views, Graham stated that every programming language should be written together with a large application using it, like C with UNIX, so the language doesn’t turn into a big, unusable science project. Another point was that outsiders are compelled to make things that are cheap, because they have very limited resources. An example of this was Steve Wozniak, who created Apple with Steve Jobs, used a TV as a monitor for the computer, since he couldn’t afford a real computer monitor. The insiders can’t make it as cheap or as small as the outsiders, they have to work on big projects, which will, by their sheer size, impress people. Small things are magical, Graham says, because they can be done fast and seem perfect, and working on small things is a good way to learn.

The biggest disadvantage of being an outsider is that you don’t, as opposed to the insiders, have a big audience. It’s good for moral and motivation to an expectant audience, and luckily, the internet has made it much easier to get such an audience for the outsiders. This way, outsiders can retain most of the advantages of being and outsider, while still having an audience.

Graham ended his talk by underlining the power of marginal: Just try hacking something together. Spend less time worrying and more time building stuff, Graham said, and how does this leave someone like me (that’s me, Casper Fabricius, not Graham being quoted), who are actually spending more time studying and making plans for future than executing and try building stuff? With a feeling of wasting my time and not being willing to take a risk – but I’ll have to take my chances. Graham suggest that you can check if you are on the right track by noticing if people call you unqualified and tells you that you are doing inappropriate stuff. As long as the worst thing the insiders can say about what you are doing is to point out that you are an outsider, you are on the right track.

UPDATE: You can now read Paul Grahams key note transformed into an essay at his website.