Life is grand

Barcamp Dublin has been announced for the 21st of April 2007. Hope to see you there.

If you are in or around Phoenix, Arizona tomorrow (the 17th) then I’d be in your debt if you attended a Microsoft and NewsGator event and reported back.

Drop me a line to discuss.

An Taoiseach will be visiting WIT’s Research and Innovation Center building where I work on Monday the 16th for the official opening. The TSSG and SEEP are hosted here and the place is fairly buzzing with activity. Plenty of press and other notables will be visiting. We should get a chance to demonstrate our project to everyone.

In case you don’t know An Taoiseach is the Irish equivalent of a Prime Minister. Pretty much the top dog in the political food chain. The current living embodiment of An Taoiseach is Mr. Bertie Ahern.

The European Ruby on Rails conference 2006 has come and gone. Day 2 felt like the conference was just starting to get going from a bit of a slow day 1 starter. Either I picked better on day 2 or the quality really was up from the first day. Do I recommend the conference? I do. It is the only Rails conference out there and you do learn a good deal. I do think it could be improved though. Better vetting of talkers and their presentations without loosing some of the wild and free nature (seriously, how many times do you have a talker at a conference drinking Stella and swearing like a sailor?) I think O’Reilly will do this for next year, bringing some needed professionalism to the conference without killing it.

Here is a list of notes from various blogs on each talk:

• Katy Sierra and David Hansson get it all going (anyone got a good write-up? I was a bit late)
• Unobtrusive Ajax with Rails by Dann Webb (code and slides)
• Rails Speaks C by David Goodland*** (slides)
• Integrating Asterisk and Rails by Evan Henshaw-Plath***
• Revolutionizing the Airline Industry with Rails by Soren Burkhart
• Managing a High Performance Rails App by James Cox
• Capistrano by Jamis Buck***
• Building accessible web interfaces with Rails***
• All you ever wanted to know about Routing by Luca Mearell***
• Securing Rails by Alex Payne***
• Going off the Rails with Ruby by Eleanor McHugh***
• Real application development with Radrails by Katt Kent
• Database engineering and Rails by David A. Black***
• Polymorphism as a design pattern for social software by Gavin Bell***
• A systems view of Ruby on Rails applications by Jason Hoffman (slides)
• Cross-pollination from Django by Simon Willison***
• Localisation of Rails Apps by Till Vollmer***
• Delivering the answers to 82ASK by Paul Butcher***
• Adventures in JavaScript Testing by Thomas Fuchs (slides)
• Ruby for Java programmers by Ugo Cei***
• Panel discussion and David’s rant***
• Safe Ruby by Jim Weirich
• Splat and Why
• nouvelobs.com ecommerce and search with Rails by Gwendal Rou (slides)
• How I turned my Bank job into a Rails playground by Rany Keddo***
• Database optimization by Hussein Worsy***
• RoR against the Machine by Sean O’Halpin***
• Optimising MySQL for Rails by Jan Kneschke***
• HAML by Hampton Catlin
• A cheeky Wiki on Rails by David Anderson***
• Janitors on Rails by Lauri Jutila***
• Rails and unicode by Dominic Mitchel
• JRuby on Rails by Charles Nutter***
• Final talk by James Duncan Davidson and Dave Thomas.

*** means I haven’t found a decent post on that talk. If you know of one please email it to me and I will put it in. Speakers are also welcome to send me their presentations and I’ll host it here.

There will also be videos up of the main talks from the organisers in the coming weeks.

Next year the conference will be 17th, 18th and 19th of September in Berlin, Germany. See you there.

The final day and now the final talk in the big hall. James Duncan Davidson is up first, subtitled “The web is a pipe, and more.” James is the author of Ant and TomCat.

Unintended consequences, from airplane crashes to condition tags in Ant. This segues into the deployment/hosting tradeoff in Rails, a balance against the ease of development.

And then into systems of apps and how using HTTP as the pipe allows anything to be on either end. So RoR today but in ten years something else without changing the business case.

Steel. As in metal. Interesting story on how steel made in the 1930s is different to steel made in the 1950s thanks to the start of the nuclear age in-between. An unintended consequence and an example of continual testing. Don’t stop testing.

Nice photographs in his slides. His own of London apparently.

On to bits about Amazon S3, EC2, SQS and Google’s BigTable. Interesting Subversion development in that it will use BigTable.

Good that he mentions power usage and its impact on Earth. How wasteful applications aren’t just expensive for our clients but harmful to the environment. Don’t waste cycles.

Overall the talk was about the next step in our applications, about abstracting above single machines and thinking of the pipes between apps, not boxes. This seems a natural fit with Rails to me.

And now onto Dave Thomas, author of the famous Ruby Pickaxe book.

Risk is the topic of his talk. Terrorism is his example, how the risk paralyses and damages the community.

“Risk management must be cost effective.”

He claims programmers are great at risk management, we do it all the time.

FUD. Fear. Uncertainty. Doubt.

With it we make stupid decisions. It wastes resources.

How does this apply to us as Rails developers? FUD is being spread about Rails e.g. Joel Spolsky. Ruby is dynamic, it is slow, Rails isn’t proven.

On the slow issue he maintains that Ruby may be slower but we are prone to write smarter code with the end result being faster applications than say, Java.

The bottom line is to not let the status quo terrorise the Rails community. Don’t let fear, uncertainty and doubt make you jittery. Don’t bite on FUD, just move on and do what we, the Rails community, does so well; developing solutions. Fast and feauterful.

A good speaker and RailsConf Europe 2006 is over.

Two punkish lads, one named Hampton Catlin, drinking Stella giving a talk on HAML; a new templating engine for Rails views.

HTML Markup Abstraction Layer. But that doesn’t matter, it just sounds cool as Hampton says.

Like most of us Hampton loves Rails but thinks RHTML is, well, just PHP warmed over.

HAML has principals. The first rule of HAML is… it has to be beautiful. Like the rest of Rails. The second one is XHTML is repetitive and prone to errors. The other two are irrelevant.

So, an example. Before:

<div><p>Hello, World</p></div>

After:

%div
  %p Hello, world

Like YAML it is double-spaced though this will be made flexible eventually.

HAML is like a Haiku, says Hampton.

Scarily, there are no blocks; No loops, no conditions. The simple answer is a list_of helper. Not sure about conditions and control structures yet. I’ll have to give it a shot later.

Ah, the Stella is for his nerves. Brilliant.

One of the best things about HAML is it indents properly. Thank god. RHTML is terrible at that.

Get the plugion at unspace.ca/discover/haml.

An interesting idea overall and it seems to work in most cases.

One thing I have learnt in this conference is that Windows laptops seem to connect better to busy Wifi networks than Macs. Bloody annoying.

(code and slides)
Dan Webb’s Unobtrusive Ajax With Rails talk proved so popular yesterday that it is being redone in the main hall during lunch today.

Unobtrusive Ajax (or JavaScript really) is all about removing all those inline onclick=”return myFunc(an_id)” bits of code from your HTML and into your JS. Separating behaviour and mark-up. Attaching behaviour to your class definitions e.g. class=”productbutton”.

At the very least this makes your pages smaller (think of a 1000 item list which has onclicks inline vs. attached via a class in a separate JS.)

At the most it is the idea of the class assigned to HTML elements.

A big theme is graceful degredation for when JS is not available.

A good point is around a href=”#” which semantically and functionally doesn’t make sense. I am an offender here but aim to change.

button_to is a little known Rails helper that generates a button in a form. This is for when you should be using buttons and not links e.g. for delete links. Remember, links should not have side effects (if for no other practical reason than avoiding pre-fetch technologies like the Google Toolbar that will wipe your records.)

To get started with UJS checkout the Rails plugin at ujs4rails.com.

A good talk and as Dan says, it isn’t rocket science. It has obvious benefits even if you don’t care about semantics. Hopefully Rails takes the ideas into the trunk.

(slides)

Now at the shopping.nouvelobs.com ecommerce talk which is a large news site in France. Speaker is Gwendal Rou, very French.

ModelSearch is an extension of find that allows something like this:

search = ProductSearch.new()
search.buyable = true
search.Find(:all)

The idea is that searching with multiple columns is not at the usual high-level in Rails. You have to use SQL.

ModelSearch is capable of; Televisions costing less than 300, sorted by price.

search = ProductSearch.new
search.keyword - 'television'
search.max_price = 300
search.sort = :price
search.find(:all)

That is quite handy. I assume ‘max_’ is dynamically added onto model members. i.e. I assume you could have min_price too. My assumption is nearly correct, you just need to set it up in the model a bit.

A further extension lets you pass the search object into the normal model find e.g. Product.find(:all, search.find_options)

ProductSearch is a class you subclass from ModelSearch and setup with various params. e.g. search_key :keyword, :search => :keyword, in => [:name, :description]

All nicely model based this. Buyable, from the first code, is a custom method in the ProductSearch model. It works well with a form, letting you just pass in properly named input fields.

ModelSearch is planned for release soon.

All in all a nice bit of code for real world problems.

It has just been announced that RubyCentral and O’Reilly Media will be producing next years RailsConf Europe and it will be in Berlin. 3 day event, 1 day of workshops and 2 days of talks.

And now for Why.

We start with a love poem for Ruby. It’s erotic, passionate, beautiful and… red. Like a ruby. And foxes.

Splat (*) in Ruby is not only eye grabbing but useful. e.g. array.push *IO.read ‘list.txt’ and then a put will break on newline. Splat (*) seems to be an array tool. [*0] => [0].

Seems this talk is about useful tricks in Ruby. I think. Bit of an interesting talker, from philosophy to code and around to romance in a single sentence.

Some sandboxing tips. With lightning, sans foxes. His library seems to be a way for a module to interact with two separate Rails apps. It launches mongrel with your module and puts the loaded apps into sandboxes that you can access.

And that was Why.

The second and final day of RailsConf Europe 2006 starts.

Jim Weirich, author of Rake, starts an interesting talk on the inherent dangers of the dynamic nature of Ruby. 3rd party libraries you may use that, instead of sub-classing, open and change standard Ruby libraries e.g. Logger.

And now we are moving on to the famous Leroy World of Warcraft video. It illustrates collborative systems and how they can go wrong.

So, tips for safe Ruby programming:

• Use namespaces (class Node for instance occurs 9 times, good thing all but 1 are namespaced.)
• Choose a good project name (not generic, checkout Rubyforge, RAA and gems first for conflict.)
• Avoid top level constants and functions (e.g. Rake is a bad example. Jim wrote Rake.)
• Try not to modify existing classes or at least add behaviour rather than modify.
• He recommends prefixing existing class modifications with your project name. I can’t say I agree, this is ugly and non-intuitive.
• Sometimes you should take risky steps to reap productivity advantages.
• You can wrap method definitions in a conditional block. Jim uses this to check if a method exists before he adds his own. Got to love Ruby.
• Forthcoming selector namespaces should help Ruby a good deal.
• Careful with cool tricks e.g. adapting to old calls with const_missing.
• Limit the scope of your changes as much as possible.
• Preserve the original behaviour as much as possible. This ties into Design by Contract. Feel free to improve internal code but don’t break the contract.

The conclusion though is that Ruby shouldn’t be crippled to protect against the ignorant. Very good talk, thanks Jim.

Why just arrived and will gives his talk in a few minutes. See you then.