This is the ninth in a series of articles of me writing up my notes from from RailsConf Europe 2006. They are all first drafts, probably technically inaccurate and slanderously misquoting people. Let me know and I’ll fix them. You can follow this series of posts by looking at articles in the RailsConfEurope category.

What a strange, quirky, funny creature. He’s the spitting image of Jack Black, highly entertaining and obviously a gifted programmer. He showed us some neat tricks with Ruby, like creative use of the splat (*) operator. One particularly nice one was for doing regexps:

m, *sub = *str.match /regexp/
if m
  ## sub contains all of your matches
end

I like that.

He also talked about his sandbox implementation, and how it can be used to run multiple rails applications inside a single mongrel instance. I got to thinking that this might be useful for merging third-party apps together into a single cohesive web site. The most exciting thing? It sounds like sandbox will be in the next Ruby 1.8.x release!

This is the eighth in a series of articles of me writing up my notes from from RailsConf Europe 2006. They are all first drafts, probably technically inaccurate and slanderously misquoting people. Let me know and I’ll fix them. You can follow this series of posts by looking at articles in the RailsConfEurope category.

Jim was talking about safe programming practices in Ruby, in particular for library writers where their code will be reused by others. Probably best to just summarise his tips:

• Use namespaces for libraries. In fact, use namespaces for everything you write. For example, how many libraries define a class called Node? Lots.

• Don’t use generic project names or namespaces since they are prone to collision. For example, a namespace of HTML is probably too generic. (In fact, there’s already a library which uses that namespace, and has a class HTML::Node…)

• Avoid modifying existing classes if you can. There are two possible ways of modifying an existing class:

  • Adding. If you have to change an existing class, add new behaviour instead of modifying existing behaviour. You should always ‘namespace’ (which in the case of methods means ‘add your own prefix’) methods that you add so that there’s no conflict with other library writers. Check if an added method already exists and, if so, pop up a warning. Better to warn the user than go blindly onwards! Apparently there’s a technique called ‘selector namespaces’, which might go into 2.0 which will mitigate these problems.

  • Replacing. Hooks (for example method_missing) should always chain to the next hook instead of assuming that hook’s behaviour and reimplementing it. After all, you might not be the first person to replace that hook… Don’t break people’s expectations of behaviour — always preserve existing behaviour and meet contracts.

He went on to discuss contracts a little. A contract for a method is a set of preconditions and postconditions. New behaviour for a method must have the same or weaker preconditions than the original, and must have the same or stronger postconditions.

This is the seventh in a series of articles of me writing up my notes from from RailsConf Europe 2006. They are all first drafts, probably technically inaccurate and slanderously misquoting people. Let me know and I’ll fix them. You can follow this series of posts by looking at articles in the RailsConfEurope category.

The format for the panel discussion was that questions were submitted during the day and that David Black would present the questions on behalf of the audience member, to the panel.

One question was about accessibility. This seems to be a hot topic for some people (it’s a requirement for some government web sites in the US & UK, for example), but I got the impression the panel didn’t think it was hugely important. Basically, screen readers are still 10 years behind current browser technology. They need to make an effort to catch up in addition to us making sites work with them. Thomas reckoned that if you need a flashy site that’s also accessible, you need to create two separate sites.

DHH is of the opinion that the fact that there are so many different i18n solutions out there means there is no one good fit that will work for everybody. And so it’s unlikely that we’ll see i18n in the core any time soon. Shopify looked at various different plugins for i18n and in the end decided it was easier just to reimplement it themselves. DHH did clarify that he’s fully behind the UTF-8 work that’s currently going on, and that is a completely orthogonal issue.

Somebody asked about how to do authentication with Active Resource. It relies on it happening at the HTTP level (HTTP auth or digest for example). Again, you can use respond_to to determine how you do the authentication. For html, you can redirect to your regular, pretty, HTML login dialog, whereas for somebody request XML, you can do HTTP auth.

Apparently, with regard to testing, integration tests do test the routing setup, whereas functional tests don’t. Actually, I think I was surprised that integration tests did run through the routing code, though I don’t know why. It’s good to know, though.

Tail end of DHH’s keynote

David over-ran his keynote in the morning, so it was added at the end of the day instead. Basically, it was a long, vitriolic rant about what he called “vendoritis”. It was about all these people who were complaining at the recent security upgrade and demanding things of 37Signals and the core contributors. His reponse? “We don’t owe you shit!” The key thing I got from this rant was that entitlement is gained from contribution to the community. Which is something I’m guilty of not doing often enough and this got me to thinking how I could do better.

This is the sixth in a series of articles of me writing up my notes from from RailsConf Europe 2006. They are all first drafts, probably technically inaccurate and slanderously misquoting people. Let me know and I’ll fix them. You can follow this series of posts by looking at articles in the RailsConfEurope category.

Don’t ever use alert boxes for javascript debugging. And certainly never leave them in your production application! There’s a unit testing framework now available for Javascript which is bundled with the script.aculo.us library. It looks and behaves a lot like every other xUnit. You create a test suite by writing an HTML page with the appropriate JS in it to run the tests, and a div with the id of ‘testlog’ which will show the results.

Add in the javascript_test plugin and you get the goodness of being able to run rake test:javascripts from your Rails project. It will test on the available browsers on your platform (including IE, Firefox, Safari & Konqueror).

There isn’t a cross-platform way of simulating DOM events, so automated functional (behavioural?) testing is near impossible. There was a way to do it in old versions of Firefox (or was it Mozilla?) but it was considered a security issue and removed.

There are a number of tools available for JS debugging:

• Venkman, a plugin for Firefox. It also does profiling.

• The latest nightly builds of Safari have the ‘web inspector’.

• Microsoft Script Debugger is useful for tracking down IE issues, and it’s even free.

One question from an audience member brought up the prospect of using vino (apparently a command line JS client) for automated testing. Thomas seemed to think this was a great idea and is going to look into it further.

This is the fifth in a series of articles of me writing up my notes from from RailsConf Europe 2006. They are all first drafts, probably technically inaccurate and slanderously misquoting people. Let me know and I’ll fix them. You can follow this series of posts by looking at articles in the RailsConfEurope category.

Rails is a small part of the whole stack. A really small part. One of Jason’s slides talked about all the daemons and services required for their connector application. The list went to about 30 items. The rails application was in at number 21.

Joyent has an opinionated view of hardware: they only use one type of each thing. One type of console server, one type of disk subsystem, one type of network switch, even down to only using one type of power plug.

Their load-balanced web setup is a redundant pair of F5 6400 hardware load balancers with a RAM cache, talking directly to mongrel_rails instances.

Jason then went on to talk about how fantastic Solaris 11 is, including its support for zones & containers (virtualisation, which he considers to be absolutely essential for scalable, efficient use of hardware), dtrace and ZFS. I didn’t write any notes on these bits because it was nothing new to me, but I think I am now also a Joyent Fanboy, mostly because their opinion of Solaris matches mine. Look out for Joyent releasing their work on dtrace for ruby soon.

This is the fourth in a series of articles of me writing up my notes from from RailsConf Europe 2006. They are all first drafts, probably technically inaccurate and slanderously misquoting people. Let me know and I’ll fix them. You can follow this series of posts by looking at articles in the RailsConfEurope category.

A new discovery for me. In the controller you can do:

render :update do |page|
  ## Inline RJS goes here
end

I’m not sure if it’s a great idea, but it could be useful for tiny bits of RJS. It’s a building block for what follows though. The page object in RJS also has the << operator so you can splat out javascript code directly, for something that isn’t well supported by the JS helpers. With both of these tools, we can start to create helpers:

def my_helper
  update_page do |page|
    page.do_hoopy_ajax_things
  end
end

and then make use of them in the RJS code:

page << my_helper

That’s it, really. It’s a pretty simple solution and allows you to share RJS code amongst several views.