techblog 

I have recently become a co-chair of the RIPE Test Traffic Working Group. RIPE NCC operates a network of test traffic measurement devices, and the working group exists to both report on and direct that project. There is also scope within the group to discuss other performance measuring techniques or products.

The working group does most of its work by email but meets twice a year in dedicated sessions at the RIPE Meetings. The next RIPE Meeting will be held from 5-9 May 2008 in Berlin. If you have a talk you would like to give to the working group at this session please send an email to me at Ian.Meikle AT nominet.org.uk.

Demon’s own Gary Feldman wrote some alternative lyrics to “American Pie” in the hotel bar, and performed the next day during Ripe-55’s closing planery. If you haven’t attended the ripe meeting, it contains the yeast of several presentations about the need to migrate to IPv6.

Enjoy.

This is the third instalment of my experiences at JAOO 2007, following on from my previous description of day two.

Once again, here are some quotes from the sessions I attended so that you can get a flavour of the day without having to read all of my notes:

• Kevlin Henney - With Economy and Elegance - “Our job is to turn a general purpose machine into a specific one”
• Laurent Bossavit - The Journeyman’s Tale - “You are a 17th Century Cathedral Builder!”
• Michael Feathers - The Ethics of Error Prevention - “Quality is in the intangibles”
• Pete McBreen - Applying Craftsmanship - “Software should be a pleasure to use, or we’re doing it wrong”
• Closing Panel hosted by Martin Fowler - “Iterative development is a constant cycle of failure”

Continue Reading »

These are my notes from the second day of the JAOO conference in Århus in Denmark. They follow on from my notes from day one. I didn’t think this day was as good as the first, but then it never looked as interesting on paper, so I wasn’t surprised. Once again, since this is a long post, I will give a quote or summary from each session and you can click through if you want to read more

• Erik Meijer - Democratizing the Cloud - “Can we take an ordinary 1 tier app and stretch it over 3 tiers?”
• Jean Bezivin - Models that work - “MDE, MDA, MDSD, DSM, ADM…”
• Eric Evans - Strategic Design - “In software there are no pleasant surprises”
• Trygve Reenskaug - Things your mother didn’t tell you… - “A computer amplifies your brain like the soundbox of a guitar”
• Glenn Vanderburg - The Overlooked Power of JavaScript - “Ajax is a gateway drug for JavaScript”

Continue Reading »

These are my notes from the JAOO conference in Århus in Denmark. Since this is a long post, I will start with a list of the sessions I went to and the best quote from each. If you think this is worth reading, you can click through to read the whole thing.

• Bob Martin - Clean Code - “Avoid Turgid Viscous Architectures”
• Charles Nutter and Tom Enebo - JRuby - “Struts is the redheaded stepchild that everyone picks on”
• Joe Armstrong - Erlang - “When x=x+1 is not deterministic, programming is really difficult”
• Justin Gehtland - Ruby in the Enterprise - “This stuff is not rocket surgery”
• Diana Larsen - Agile Retrospectives - “Software developers are smart people who are good at thinking individually, but not necessarily together“

Continue Reading »

As I mentioned in my previous post, I was at XPDay 2006 in London last week. These are my notes from the second day.

Keynote: James Noble and Robert Biddle: Love in the age of software

I’m afraid that the notes I actually wrote during this are not fit to be repeated in their entirety. However I think that the phrase keynote panto sums up my thoughts. I’m not sure quite what point they were trying to get across, but unfortunately I found their presentation style intensely irritating. It involved some hit-and-miss (mostly miss) comedy, shouting, talking at the same time and feedback. I left about halfway through so I could be at the front of the queue for coffee. What was particularly ironic was the fact that some of their presentation seemed to be about communication. Surely rule number one of communication is don’t annoy the person you are communicating with?

Chris Matts: Managing Uncertainty and Risk using Real Options

This was the most interesting and useful session of the day for me. The speaker’s background is in proper financial options and so on. In this area, they use the Black-Scholes equation to determine the price of an option. However, he said that people who attempted to use this in areas outside financial mathematics were misguided, because it makes a number of assumptions that aren’t applicable outside that situation. This doesn’t mean that ‘real options‘ (which are just options in the sense of choices) are not valuable. He pointed out that often people would rather have a decision made, even if it is the wrong one, than leave things undecided. That’s just human nature. But of course, if you can delay your decision then you will have more information and therefore will be more likely to make the right choice. The important thing is working out when you actually need to make your decision.

He gave an example from ordinary life to show the value of these real options. He was flying back from holiday in Italy and due to arrive at Stansted Airport at 23:30 on Sunday night. He lives in Surbiton and works in central London. If he took a taxi home or decided to stay at an airport hotel, he’d have to book these in advance. He didn’t want to make this decision beforehand, so he took a suit into work, knowing that there was a shower there. In this way, he could stay anywhere for the night and still be able to get to the office on Monday morning ready for work. In the event he ended up staying at a friend’s house. But he was only able to do this because he didn’t have to make his decision until the plane actually landed. The cost of the option was low (just taking a suit in), but he saved himself booking an expensive taxi ride or hotel room.

A quote I liked, which came up in the questions at the end was:

Making a decision reduces the solution space, not the problem space.

Pascal van Cauwenberghe: The Toyota Way of Managing

This session was about the Toyota Production System and its philosophy. While it was good, I’ve heard much of this before in the context of Lean Software Development. This meant that I didn’t take many notes. I suggest you read my colleague Graeme’s detailed write-up.

Agile Adoption Experiences

This session was split into several mini-sessions given by a variety of different people from different organisations. I’m just going to summarize some of the interesting ideas that came out of these.

Manish Shah and Thomas Granier talked about doing agile away from the usual OO technologies that are agile’s usual area. They mentioned utPLSQL, which is a project I was once the maintainer for. There was a discussion of how to handle the problems of having multiple different customers who want different customizations to a core set of code. The solution put forward was to have a separate source control branch for each customer. This code was looked after by ‘pioneers’ who did the customization work. The core or ‘gold’ code was looked after by ‘guardians’ who made sure that anything integrated into the core did not disrupt the coherence of the system.

Dave Nicollette talked about how agile was introduced into two different companies. In one case (where he worked) it was bottom-up, the other top-down. Interestingly, in the first case the organisation was not in a very competitive market so management were not particularly interested in this area. However it sounded like a bureaucratic nightmare of an organisation, which is why the agile ideas started from the ’shop floor’. The second company was in a much more competitive arena meaning that the management were keen to find ways to make things more efficient.

What I liked from his story was when he described putting together his ‘agile dream team’ in the heart of this heavily process driven company. Somehow he got all the people he asked for, mainly because the people he wanted were those who questioned the bureaucratic processes. This meant that they were perceived as trouble makers which the managers were keen to get rid of.

Courage: How Brave are you?

This final session was a goldfish bowl style discussion facilitated by Giovanni Asproni. I’m not sure quite how much I got out of this, but the following are some interesting tidbits:

• The opposite of courage is paralysis.
• Courage is when you say to your team the thing that no-one wants to say. The elephant in the room, I guess.
• After a life and death situation, such as being lost on a mountain, fears of project failure just vanish, at least for a few weeks.

Earlier this week I was at XPDay 2006 in London. This was my third time at this conference, so how did I find it? It certainly seemed to be rather busy compared with previous years. The venue was Ironmongers Hall, which is an amazing old building surrounded by the brutal concrete of the Barbican. I’m sure there is some clever metaphor there, with agile software development being the human-scale alternative to the industrial-scale processes. It’s a great place, but I don’t think it could have taken more people without it becoming uncomfortable.

This was also the first time I have presented a poster at XPDay. I wanted to promote my book group and get some feedback from attendees, but I didn’t think it warranted an actual session, so this seemed like the perfect compromise. I was a little disappointed that the posters were situated at the back of one of the session rooms, rather than in a ‘public’ area. This meant that I had to promote it myself, so when I talked to people I suggested that they should take a look. But at least one person learnt about the group and might come along, so all that time fiddling around with Comic Life was not wasted…

Keynote: Joshua Kerievsky: The Selling Game

The first session was by Joshua Kerievsky. (You may notice I namecheck him in my poster - that is a complete coincidence, honestly). Apparently it had been suggested to him that he talk about scaling agile to large teams and organisations, because that’s what he has done. He decided to approach it from a slightly different angle and look at it as the ’selling’ of agile to people who may be skeptical or unsure. He talked about what people do in other areas when they are trying to sell something. He mentioned a problem he had with his plumbing, when 3 different plumbers gave 3 different diagnoses and quotes, ranging from $9000 down to $200. Not surprisingly he went with the final one, which involved blowing CO2 down the pipes to clear them rather than replacing all the pipes in the house (and it worked too). Referring back to selling agile, he said that he want to find the CO2 solution to scaling agile, particularly to avoid having to teach the same class to group after group of people in a large company. The approach he used was eLearning and screencasting.

Talking about selling again, he said that when you try to sell something, people will raise objections. He pointed out that these are not the same as rejection, but are more like uncertainty. The best tactic is to repeat their objection back to them, but then show them that their objection is due to lack of information or misconception. He talked about how he got external experts in metrics to provde measures proving the benefits of the agile approach.

The best point of the presentation was when he asked the audience how they would sell pair programming. They came up with a variety of very reasonable ideas. He then said that he doesn’t sell pair programming, he talks about the risks associated with solo programming instead. In fact, he usually gets the person he is talking to to come up with these risks.

Finally he talked about how if one group in an organisation uses agile successfully, others become jealous of their success and try to attack them. He likened these forces to organisational ‘antibodies’. He solution was to start selling to them early on too and also to carefully assess what approach will fit a particular organisation.

Ben Fuchs and Joseph Pelrine - Turning up the heat without getting burnt

This session was about conflict and difficult behaviour. Their thesis was that conflict can be a healthy thing within a team and that you need to keep things cooking to stop the team stagnating. Obviously this does not mean that you have fights breaking out! For example, they suggested that the conflict brought about by having players in a football team competing for a starting place was healthy for the team as a whole. They then gave various ways to push people just out of their comfort zone to keep things interesting. These ways to ‘turn up the heat’ included increasing work pressure, adding new people into the team, changing the physical environment or introducing new tools. I wasn’t entirely convinced by this idea, but it was certainly interesting.

The part that I found more interesting was about how to deal with difficult people. This was a series of questions, the most searching of which were “Why do I care?, has this violated some of my values?” and “Why is this behaviour occurring?”. I think that keeping these in mind might help to avoid just setting the bozo bit in these situations.

Joshua Kerievsky - Patterns of Refactoring

This session covered some techniques that he discovered while writing his book Refactoring to Patterns, which is about refactoring your code to (or just towards) design patterns. He found that there are different ways to do refactoring, some much better than others. Another thing he found was that there are some elegant refactorings that are not intuitive and that you often need more than just the standard “Extract method” refactoring and so on. The whole idea is that you make small changes and keep running your tests as you go. This is the fundamental Pattern of Refactoring which he calls “Piecemeal Refactoring”.

Unfortunately, often the situation is that you see the code is in state A and you know it would be much better in state B. It is difficult to see how to get from A to B in small steps. This means that you end up breaking everything in the hope that you’ll end up at point B once you’ve fixed everything up. I’ve been in this position myself. His various techniques and tricks help you make the transition and keep the test bar green. He had a special name for the red marks that appear all over the code when you follow the “sod it, I’ll just break it” technique: Refactoring Rash. I liked this colourful analogy.

One simple pattern he showed was ‘Narrowed Change’. In this pattern you isolate the piece of code that needs to change so that it can be changed without large scale breakage. Often this will be something like changing an Array to a List. In that case, you would encapsulate access to the object and then only once that was done would you change the type. Finally you would inline the getters and setters created to allow the change to occur. He compared this to putting up scaffolding around a building to do some work on it and then removing it at the end.

He showed a technique that he didn’t have a name for. In this situation you want to extract some functionality from one class and put it into another. First you create an empty class and just push something like a simple member into it, with the original class using a getter to obtain its value. You then extract a method in the original class and move it into the new one. I suggested “Embryonic Class” as it seemed like a mother and child, initially connected by a cord (that getter). He liked that, so perhaps it’ll show up in his next book…?

I recently went to RailsConf Europe 2006. Rails is very exciting technology, but the Rails community is still a bit excitable. Anyway, here are my notes. Apologies in advance if I offend anyone!

Keynote - David Heinemeier Hansson on Rails

1.2 is out soon. Changes are

• entire dependency system. Modules auto-reload, paths will reasonably work, bolt in controllers and models.
• Routing also changes, to prevent issues like that before
  hundreds of bug fixes
• also some REST stuff - called SimplyRestful.

SimplyRestful

• Slapping a grid of conventions down on controllers. So controllers will look the same as you move from project to project.
• New scaffolder (not shiny like streamline) will look ugly by design. Intended as a supplement to the current scaffolder, but will work with the new restful style. Remember the intention behind scaffolders is for them to be a learning tool
• Basically there will be a convention based mapping for HTTP verbs to controller functions that map to database operations.

e.g. I create a controller for my blog posts called PostController. The scaffolder automatically define a function called index that is automatically routed to from GET /posts/. The scaffolder does this by writing up the routing file.

• Great quote: “that smells a little bit like configuration so we might need to change it”
• Automatically does things like giving you an XML based output of your page

ActiveResource

• Built on top of SimplyRestful but is an external GEM that has to be added onto 1.2. Not sure if it will ship with 2.0
• Like ActiveRecord but for HTPP. This is basically a way of creating a class that represents a remote restful service on another server - in the same way that an ActiveRecord class represents a remote table. Very, very neat.
• Great quote: “Woo hoo”.
• Unlike ActiveRecord, where the class can check what the schema is and therefore check any data sent to it, this does not do anything like reflection to create the class, so checking is not done (need to see what this means a bit more later).
• Great quote: “so all the stuff I talked about at the last conference actually works”.

SimplyHelpful

• The more they worked on other modules, the more they realised that views do not have sufficient conventions to make them transparent. So they now have a module called SimplyHelpful, which is views by convention.
• They want to ‘encroach’ on your HTML, CSS, JavaScript.
• Already a plugin, but this is really cutting edge now, though it does work and it is in production. Will be a part of 2.0
• Great quote: “if there is one convention that is easily guessable, then it makes me happy. The great thing with conventions, is that as soon as you lay them down it is like a super highway for information to run down.”
• effectively it builds a model of the html, scripts or whatever and lets you address it by convention.
• Also has lots of extremely nice syntactic sugar for the rhtml files that reduces the amount of code you need considerably.

Next release will be 2.0

Lots of Rails cruft still hanging around that will be removed for this release. Flagged as deprecated in 1.2.

Vendoritis

• This is a personal rant by DHH (and what an angry rant it was). There have been two big events recently that have been x-rays of Rails. The first was the security patch in the routing code, a 23 hour fix window, which they are proud of. Showed early signs of vendoritis
• Symptoms of this are ‘entitlement’ and ‘indignation’. The first is a belief that by downloading some open source you are entitled to the time of the developers. This is not a shop, the customer is not always right. You gain your entitlement by contributing to the project, code or insights. Similarly with indignation.
• One of the arguments was “do you want Rails to be the standard web platform or do you want it to be a hobbyist platform for people running their blogs”.
• There are a variety of treatments for dealing with this. None of them very polite. But it must be treated to stop it spreading. More important though is preventing it.
• Of course there are some valid criticisms, they just have to be reasonable. The JavaRanch terms of service are good to remember ‘be nice’. It matters how you say it.
• Core Rails team is like a mutex and is not fast at accepting patches. This shows that it is too big to work the way it currently does. Needs to split up into smaller communities that build plugins. For example l10n should be a plugin. Most of the new work the core team are doing is coming out as plugins.

Keynote - Kathy Sierra - Creating passionate users

• Great quote: “If you saw a man drowning and you could either save him or photograph the event - how would you tag it in flickr?”.
• People believe their decisions are 90% logic and 10% emotions, but even for geeks they are 10% logic and 90% emotions - to prove this she asked everyone who owned an iPod to raise their hand and the entire room raised their hands.
• Our goal is to give our users a higher resolution experience, in the same way that modern jazz afficionadas can actually hear distinct patterns, not just noise. (or so they claim).
• Good products are quick to get over the suck threshold and make it as far as the passion threshold. Too many people just hang around in between because of the fear of an upgrade dropping you down below the suck threshold.
• We assume we are teaching being about the tool, but actually we need to teach them what they can do using the tool. Particularly important when writing manuals.
• We treat people who are about to be customers to so much better information than those that are customers (not at Nominet of course!).
• You have to think “how can I help my users do extraordinary things?”
• Cognitive theory shows us that the mind is very sophisticated, but the brain is still in the stone age. It has a set of primal responses and filters.
• These responses include things like ‘what is unusual here’, and then all the normal apple pie stuff.
• When your brain is reading conversational documentation, it cannot tell that it is not involved in a real conversation and so it is forced into paying attention. When you read formal documentation your brain just switches off.
• So now you have their attention, what comes next?
• Some books to read “Flow” and “Mindhacks”. First one is about the psychology of optimal experience.
• The brain loves discovery, challenge, narrative, self-expression, social framework, cognitive arousal, thrill, triumph, accomplishment.
• These things can get them into the flow state. This is where they do not notice the passing of time and things appear to pass directly into their brains.
• Another book “Don’t make me think”
• Brains can’t stand to have something left unresolved. They need to know the ending. This means that presenting something as a problem of two possibilities can get it involved.
• remember, ‘just in time’ learning is so much better than traditional ‘just in case’, since you end up forgetting it if you are not interested.
• People are tribal and like to get the ‘nod’ - being recognised by others in the group. We also like to discuss with other experts rather than newbies.
• So give users social things. Why not try ‘t-shirt first’ development.

Rails speaks C

Why would anyone want to do this?

• gots lots of C/C++ code (know anyone like that?).
• speed for some algorithms compared to Ruby (not sure I always agree)
• integration

Primary ways of extending Ruby for C.

• Has a basic C API. But you need to manage all the memory carefully.
• Ruby/DL quite an old library for which a rewrite is long overdue. Basically links in OS dynamic libraries. However there is a limit of 8 or 10 callbacks in total. Limits on C types.
• RubyInline. Lets you write C code inline with your Ruby. Uses gcc at runtime (!) to compile and then cache the code in memory to use it.
• SWIG. Will have seen it with subversion, as this is how sv provides support to so many different languages. Automatically generates Ruby (and other language) modules directly from some slightly annotated C code.

So how do these apply to Rails?

• BackgrounDrb. Basically a way of running background tasks decoupled from Rails, based on the Distributed Ruby library (DRb). Define worker classes and then make calls to it, (which are asynchronous with callbacks?).
• DHH commented that he wanted to get ActiveResource to do some of this stuff, including talking to other languages. He also thinks that for most needs people can just send XML between servers, only switching to proper Ruby object (via DRb) for big object.

High performance Rails applications - James Cox

Based on real-life experience of getting a site running that is receiving millions of hits per day.

Language performance race

• Joel Spolsky has been ranting against Ruby and Rails performance
• some truth in it, but then the development speed is so much improved

Best way to beat this is proper planning. Don’t expect to do it all by refactoring. Good planning is always better.
Sometimes the most important thing to do is make it seem faster, even if it isn’t. Quick responses to the user even if it is still doing something

Tips

• ActiveRecord tricks, mainly obvious SQL stuff, but sufficiently hidden by Rails that you need to explicitly tell Rails so that it then generates the correct SQL.
• Use CachedModel (which uses memcached as the back end)
• template optimiser. Some templates are actually quite slow, it depends on how they are built.
• publish once, caching always wins. Every time you edit it, publish it, then cache it. Don’t expect anyone to wait for a page to be rendered.
• don’t use cached_pages

Infrastructure tips

• don’t use shared hosting
• 2GB RAM minimum and dual core processor (for a small Rails app)
• If you think you will have more than a couple of hundred thousand hits per week then you will need more than one server.
• • eight server gem
  • 2 x proxy web/static servers (small, 1GB, single core)
  • 4 x application servers (medium 2GB, dual core)
  • 2 x database servers (big, 4GB, dual/quad core)
  • this can handle around 10 million hits per week
  • don’t forget load balancing
  • mysql replication works well (master/slave)

MySQL

• Much prefer this after six years of using it
• Do not use this for things like session keys since it queues things and performance can be poor (use memcache instead)
• Use InnoDB instead of myISAM for greater survivability *
• some specific config tips
• • query_cache=0
  • key_buffer_size=100M (sole most important thing to do, make this huge)
  • max_allowed_packet=1M
  • log-slow-queries=/var/log/mysql_slow_queries
• if networked DB then
• • wait_timeout=90
  • net_write_timeout=180
  • net_read_timeout=60
  • max_connections=500

Other tips

• Use mongrel (app server) with nginx (proxy server)
• If you have just one machine then Apache with fcgi threads is best. Otherwise use mongrel.
• Ditch keepalive, unless you are using Ajax that specifically requires it.
• Don’t do any hostname lookup
• Turn off any unneeded logging, including access logs
• Put the stats code at the bottom after the style code. Browsers process the page simulataneously and the styles code take longer, so let it have it first.
• Use NFS for file sharing or MogileFS and FS Clusters

Ruby stuff at .tel - Eleanor and Romek

• Web stuff without Rails: bitstruct, pcap, camping, webrick, markaby
• Camping is a microframework written in Ruby. (4k big).
• Lovely tool called bistruct allows you to look at things at the IP level.
• Used bitstruct to define UDP. (50 lines of code)
• Then added pcap to some bistruct stuff to do a udpdump programme. (50 lines of code)
• Then want on to build a web based DNS-sniffing application
• Used webrick beacuse you can add code blocks into it. Showed their own, very short Ruby app that uses the WEbrick library to load a server. Then showed the server object being started with a code block and then a new servlet object that just inherits from the webrick servlet library, but with custom code blocks.
• That’s the basics, then you move onto a proper application server.
• This is like writing your own version of Rails. You created a request/response object, then for each path you register that object and the handler.
• Then decides that they should have done it in Rails, rather than rolling their own.
• However their management did not understand Rails and did not want it
• So then started to use camping as a microkernel to do the page serving. Very small though - one file per application. Creates each app in its own namespace and each database handle is within that namespace.
• Used Markaby, an xhtml domain specific language. So this means that it creates new ruby language elements that are analogous to xhtml entities.
• Romek pointed out that text interfaces are much simpler than all of this.

Relational Database Engineering and Rails - David A. Black

• David notes that he is not a DBA, but a developer.
• Rails has a basic mapping between HTPP verbs (REST) and CRUD using convention in controllers. More so with SimplyRestful (as discussed above).
• [big chunk of stating the obvious - waste of time by a slow thinker]
• Suggests that you think of everything in terms of CRUD. For example logging in is actually and authenticated way of Creating a session.

Integrating Ruby and Java - Ugo Cei - Sourcesense

How to include Ruby in Java code and vice versa. Or call one from the other.
Explained a Java web site he wrote oszone.org, uses cocoom, spring, lucene, hibernate and rome (https://rome.dev.java.net - an RSS feed lib). Could see how to replace some of these with Rails and other Ruby equivalents
Gave an example - wanted to write an XML validation class but the standard Ruby XML parser is not good enough, so used jruby to call the Java XML parser.

RubyJavaBridge (RJB).

• These are libraries typically written in C, using JNI to call the Java. Ruby then calls the C code.
• no mapping from Java iterators to Ruby loops
• no data type conversions
• no support for javabean properties
• works and is being maintained but not very pretty to use. Your Ruby code looks too much like Java
• great quote: “not very Rubish” - pronounced ‘roobish’

YAJB (Yet Another Java Bridge)

• looks much the same as RJB
• can also be used to write Java code inside arguments to Ruby methods.
• uses javassist

SWIG (mentioned previously)

• e.g. Jakarta POI, nifty library for manipulating OLE2 compound document objects (office files), written in Java (compiled with gcj) with SWIG providing the Ruby bindings.

JRuby

• full featured Ruby interpreter written in 100% Java (whole talk about this later).
• Gives Ruby instant access to all Java libraries - with a very Rubish syntax.
• Cannot load Ruby extensions written in C
• Mostly able to run Gems and Rails
• Not as fast as C Ruby but the developers think they will beat the C Ruby performance by the end of the year. I believe him.
• But could wrap the C extension with JNI.
• Supports iterators etc.
• Might be some naming conflicts, especially with core Java libraries. Use modules or remap names.
• Runs Rails and Camping.
• Has a JDBC ActiveRecord adapter. Works with almost all proper databases.

Remoting

• Could of course use XML-RPC, but remember the network is not transparent. For example cannot return a collection, just a vector of hash tables.
• Uses the Apache XML-RPC on the Java side - bit clumsy because of the collections issue.
• Then showed SOAP using XFire. Client looks almost reasonable but some weird added bits of code.

Rails core team panel discussion

Why/when did you get to Ruby?

• Struggling to learn Python until realised it was Python that was wrong not him.
• Spend a week and then decided never to touch PHP or Java again.
• Got sick of the whitespace in Python

Apart from the obvious cases (such as real-time) when would the panel advise against using Rails?

• Lots of projects, including many enterprise ones, that are doomed to fail, so don’t use Rails for them.
• When you are paid by the hour instead of results

Is the principle “optimise developer cycles over CPU cycles” an inviolable principle of Rails?

• There is someone working a lot on optimising Rails.
• Incredibly rare for speed to actually matter. Always a tradeoff, but they are very rare.
• But when it matters, bottlenecks must be removed, such as the recent rewrite of the routing code

What work would you like to see to get the focus on accessible Rails apps? (what?)

• SimplyHelpful could be used to help generate more accessible code.
• Screen readers such as Jaws are living a decade in the past as far as browser technology is concerned.
• It is the screen readers that need to change to support Ajax, not us to stop using it.
• Ajax and accessibility just do not mix.
• On a separate thread Rails should be far better at dealing with utf-8 than it is.

Will any HTTP authentication stuff (RFC2617) be built into Rails?

• No, it is best done as a plugin
• Authentication is so much wider than this
• HTTP authentication does not do anywhere near as much.

What about adding RSpec to Rails?

• People in the rspec community are already doing this.
• TestUnit is fine so far. Not entirely convinced by it.
• Rest of the answers were too boring to record

Keynote - Jim Weirich - Author of Rake

• Playing it safe - writing Ruby libraries so they don’t annoy people.
• Someone recently asked “are Ruby open classes a poor fit for large projects?”. Gave a simple example of a class that has a list in it and prints out the contents of the list, assuming they are all strings. Suppose someone then amended the printing method to raise an exception if the list is empty - how would anyone be able to see all the implications of this?
• Also “the chainsaw infanticide logger maneuver” was a rant posted some years ago. A developer spent three hours trying to fix problems with the Ruby logger class, only to find that one of the libraries he had installed had fundmentally changed the behaviour of it, including using :nodoc so that there was no documentation on this. He then trolled through a number of other projects and discovered lots of idiotic changes to the logger class.
• Great quote: “an agile language lets you do anything but also gives every other idiot on the planet the chance to stab you in the back with a rusty pitchfork”
• So, quite obviously, we need some rules (some DHH conventions perhaps?).
• He then played us a video showing a clip from World of Warcraft (an online game). Very amusing, showing a group of players planning a large attack, but then one of them, who was not listening to the plan, runs in and so loses the element of surprise and they all die. The motto “guard against Murphy not Machiavelli”.

Tips

• Use namespaces. He ran a grep on a set of GEMs and found 10 classes called Node, all but one were in namespaces.
• The namespace should be the name of the project, not a generic name. e.g. HTML::Node is wrong.
• Before creating a project look in Rubyforge, Ruby Application Archive, gems
• Avoid top level functions and constants. His own project, Rake, violates this terribly.
• Prefer adding behaviour rather than modifying behaviour
• And here is a convention -> if you need to add behaviour to someone else modules then prefix your method name with your prefix name, i.e. def myproject_mymethod.
• There are some exception. For example he adds an ‘ext’ method to the string class that gets the extension if it is a file name. But in this case he actually tests to see if someone else has added an ext class before he adds his and prints out a warning if not.
• When adding public methods ask first. The developer can then decide.
• One solution is selector namespaces, but Matz has promised this for Ruby 2. Basically you choose whose extensions to use and in what order.

If you need to let your code handle libraries with global constants that is in the process of transitioning then you can redefine the const_missing method in your own module to spot if the globals are missing and then give you private mapping to them

alias :my_const_missing :const_missing def const_missing (const_name) case const_name when const == :My_Global My_Module.application.const_warning(const_name) My_Module::My_Global else my_const_missing(const_name) #calls the original end end

Can also use the method missing, which can me even worse if done wrong.

Require hooks. This is a redefinition of require. But in this case you call the original require first and then catch any error, which then leads to you use your own code, and if that fails then you reraise the original error.

Strong view that you should design by contract. Eiffel actually lets you do this in the code, but Ruby doesn’t. A contract is:

• What must be true before a method is called - precondition
• What must be true after a method is called - postcondition
• So, for real sqrt precondition is n >= 0. postocondition (result*result - n).abs < 0.001.
• When you replace it then you must have the same or a ‘weaker’ precondition.
• And you must have the same or ’stronger’ precondition.
• Replaced behaviour must be ‘duck type’ compatible.

Keynote - Why the Lucky Stiff - Author of Camping, YAML API and Try Ruby sandbox

All presented through cartoons. Described his book (http://poignantguide.net/ruby/), which is a technical book based on cartoons. Too off the wall to take good notes.

Showed some tricks with the splat operator *.

ary.push *IO.read('list.txt'), which automatically reads the file by lines.

case food when *items devour_that food end

(Though Ruby will soon have an ‘in’ operator. ‘for food in items do‘)

If VALID is a list, including ranges then ‘case ch when *VALID’ will work, because when uses a === not a ==.

0.to_a will give you an array with just zero in it and a warning that default to_a is deprecated. However [*0] does the same thing without any warning.

And the following very Perlish code

if str =~ /REGEXP/ puts "#$1: #$2" end

can be:

m, *sub = *str.match /REGEXP/

m contains true if it matched and sub is the array of matches.

When you load/require a library it does not load into the namespace of the module, but globally. ‘Why’ has a solution, which is his Sandbox extension, load the library into the sandbox and then eval the code inside it. Then showed an example of how to do this to partition rails apps so that /thisone and /thatone each have their own sandbox. Compartmentalises the service and for the first time allows two rails apps in the same web root using the same web server. (BTW everyone it seems uses Mongrel as their production Ruby web server).

With Sandbox you can specify exactly what libraries the user is allowed to load. You can load different versions of the same library in different sandboxes.

How to turn your enterprise job into a Rails playground in three easy steps

• Bad: He works for a bank now. Only use proven stuff, very conservative, don’t take risks, overseas HQ so more people to convince. Very comfortable, even the developers.
• Good: However does have a boss that pushes for change and allows flexible working roles. Want everything done now.
• Ugly: J2EE hell. Class loading issues, huge XML files etc.

Showed some invented statistics of unhappy develpers (95%) and happy Rails developers (5%). It is your civic duty to introduce Rails into your workplace for the happiness of others.

Three step plan

1. Lull management into a false sense of security
2. Steal
3. Cheat

Step one. At the time they were organising bi-weekly talks for the team. Idea was to get some more fun stuff into work. Used this as a platform to get started talking about Rails. Gave management the time to learn to trust him.

Then along came a small project, with the following characteristics:

• no existing database
• low business risk, the bank would not fail on it
• small team (including the business people)
• nobody watching (no outside project management)

Requirements were:

• a new bank product
• augment internet applications with it
• tie into other client server applications
• wanted it right now

So decided to move all this into an ActiveWebService SOAP object.

Step two. Told boss that he knew exactly what he was doing. However he had never written a single line of Ruby before. Also told boss that it would be at least seven times faster than Java.

Some hard bits:

• connect to schufa, which is a secure service with client certs etc
• had to use a third party C module
• no idea what the production environment should be
• had never done any of this before, ever

So told management how he was going to manage these risks

• hard stuff in rjb or if needed to switch back to Java then could use jruby
• just went for Apache 1.3 with fastcgi

Did not tell anyone else what he was doing unless they asked. The server teams never asked so they never know.

Step three: Stole developers by promising them a good time. Had three developers working on it before they were officially assigned to the project because they liked the idea.

They then developed it.

• Used mysql for it.
• The active webservice was simple.
• Then did lots of iterations so the users could work out what they wanted.
• Used XML builder to build XML very easily.
• Did the authentication with a Ruby wrapper around openssl (in around two lines of code)
• The external C module was not difficult either
• Used xconf.rb to build libraries and then used SWIG to connect it to the Ruby word.
• so in the end there was no hard stuff. Ruby just glued it all together.
• tooke five months for three main developers to do.
• Around 5,000 lines excluding the unit tests

Then came deployment

• Wrote a one-click installer for the server team to keep them happy.
• Used capistrano with a small tweak for Solaris
• Unfortunately the server team do not like one-click installers and were quite annoyed
• They went off and complained to the overseas über-architect

But then their boss stepped in and saved them:

• Main argument was that they were almost done.
• Also claimed ‘this is only a pilot’ (great trick that seems to be used in lots of cases to get Rails into production).
• Final argument was that this could all run on JRuby real soon now (not that they had actually tried it).
• Also offered to port it to Oracle
• Then showed how much easier it is to learn Ruby than Java, winning the skills argument

Just when they thought it was all over, bar the port to Oracle, the DBA entered the scene. He thought they wanted to disrespect his ‘precious’ Oracle, with funny practices like foreign key listeners. Unhappy with the migration plans because of the unchecked SQL scripts (this DBA wanted to check all SQL to see if it was good enough!)

Final thoughts

• Don’t try to push too many things at once (pick your battles)
• Try and stick to the best bits of what you have, don’t get carried away with changing things for the sake of it
• Respect your local release processes, someone else is going to be told off if it goes wrong not you

It went into production and there have not been any problems. The business was happy with the result. The bank is now looking into using it again for a second pilot. Rapid prototyping using streamlined is now gaining ground.

JRuby - Charles Nutter - Lead developer

In case you don’t know, Charles started working for Sun last week. So it is official.

Why Java?

• pervasive
• well tested
• highly performant

What do Rails devs get from JRuby?

• lots of libs
• JDBC
• Good EE stuff, clustering, failover, deployment etc (surely this is container dependent not hotspot)
• extensive remote monitoring
• a gateway to the enterprise

What do Java devs get from using Rails on JRuby?

• a usable web framework (because the rest are not)
• a useful schema management tool
• markup that doesn’t suck (JSP etc)
• Four extra days per week
• happiness

Then demonstrated the classic depot app (from the pickaxe book) on JRuby and it worked fine. They do think that their port is still a bit slow though. Showed it getting some stuff out of a session bean with automatic backend persistence (EJB stuff). One line of code sets up a manager object that has all the methods needed for the controller.

Also used JMX to manage it, with a J2SE Monitoring and Management Console service that could inspect various mbeans. (I’m not sure how this works without a container, is it just a case of loading JMX into your Java runtime?)

Next

• fix broken bits
• • marshal-based session (like calling super)
  • interpreter bugs
• performance
• script based java EE/Java library support. i.e. write the equivalents of scaffold for the Java EE stuff. But not just for Java, to do things like auto build the session bean stuff mentioned above.
• implement remaining C extensions, Mongrel, SSL
• continue expanding ActiveRecord-JDBC
• • abstract out schema definition. JDBC does not provide the schema data to ActiveRecord that it needs to do its automagic on properties that match fields.
  • solidify automatic CRUD support. Mainly just adding types like decimal
• more GUI tool support

As far as they are concerned, JRuby is not finished until it fully supports Rails. Java EE works so much better with Rails. Actually makes it fun!

Keynote - The Web is a Pipe and More - James Duncan Davidson

• In the early days of Rails they used Apache and FastCGI to deploy. But this was fairly sticky from a sysadmin point of view with processes and other things going wild in odd ways. His blog covers all the things he tried.
• Switched to Mongrel (http://mongrel.rubyforge.org) and noticed that it was so much easier to manage. For example you can telnet to it since it is plain http, but a fastcgi server uses a proprietary protocol. Used Apache with mod-rewrite to then push different urls to different rails apps.
• So what will we be using in ten years time? Can we do something now so that we can just switch things in as we need, not make a major binary change?
• Sticking mongrel into all apps as a library means that all of them can easily be exposed as a web service (well not quite - you have to write the code) over http.
• [Huge amounts of boring waffle - this man needs a sound thrashing even if he did invent servlets and other good things]
• Mentioned the new google oss project hosting, it has a customised subversion that stores all the data in a google big table. See http://www.infoq.com/news/Reviews-Mixed-on-Google-Hosting

Keynote - Dave Thomas - Author of the pickaxe book

He showed us his new Rails logo, two fingers sticking up.

The FUD fightback against Rails has started.

• It is not a case of Ruby not being ready for the Enterprise, it is the Enterprise that is not ready for Rails.
• What happens if DHH goes mad. Too late for that. Anyway Rails is far more than one person.

Lots of stuff about why not to let the FUD get to us, starting with an analysis of the psychology of 9/11. All very rabble rousing. Standing ovation. Not worth writing down.

I’m just back from Århus in Denmark and the JAOO conference which I blogged about last year. My posting from last time came to the attention of the conference organisers so they linked to it from their ‘Trackback Blog‘. I even had an email from one of the organisers asking me how to make the conference more appealing to UK based developers. I think that first off they need to make people aware of their existence. As it stands, this conference is mostly unheard of, despite the quality of the speakers. My colleague Matt also pointed out that they need to decide what the conference is about and make that plain. You’ll notice that the front page of the web site doesn’t tell you and that you have to go off to the About page to find out. So I think he has a point.

So how was it this time around? Good, despite the disappointment of Martin Fowler pulling out of the event. I don’t think I got as much out of it as last time though, but that was probably because the best presentations were by people whose books on the same topics I’ve read and enjoyed (Alistair Cockburn and Eric Evans).

Any gripes? Only that the tutorials before and after the conference seemed to be finalised only a month or two before they were due to take place. If you’re making the effort to come from Britain and have booked flights and hotels etc, it is irritating if the tutorials move around or get cancelled.

I recently attended the JAOO conference in Aarhus, Denmark (don’t ask me how you pronounce it, I heard “Yow”, “Jow” and “J.A.O.O.” amongst others). The list of speakers was pretty impressive, including:

• One of the Gang of Four
• One of the Three Amigos
• One of the Two Agile Dave Thomases
• The one and only Martin Fowler

What was surprising to me was the split of the attendees by nationality. I’d guess it was 90% Danish, 5% Swedish, 3% German and 2% Others. Now considering the calibre of those giving the presentations, I would have expected more Brits and Germans. In fact it was only on the very last day that I met another Brit who wasn’t a speaker or with a company at the exhibition. I can only begin to guess as to the reasons. Maybe it is too expensive, or perhaps people just don’t know about it? The bottom line is that if you want to see Martin Fowler speak and you don’t want to leave Europe, this is almost your only chance.