November, 2007

My good friend Keith says he’s not starting a language war, but he wants to tell Java programmers what’s so great about Ruby. So here are the reasons:

• Generally speaking, Ruby is much quicker for development than Java, and for some projects, time to market is important.
• Ruby’s great at scripts. Java isn’t. Why not use it to automate repetitive tasks.
• Meta programming Rocks! (Actually Keith didn’t say “Rocks!”, but if he was 17, that’s what he would have said.)
• Ruby has a bunch of interesting Domain Specific Languages.
• Rails make it dead easy to build web apps.
• JRuby means that Ruby code and Rails apps can make use of standard Java libraries and be deployed in standard Java environments.

Paul King, co-author of Groovy in Action is speaking on Grails, the Groovy version of Ruby on Rails.

• Grails is rip-off of Rails. Development in Grailsis much the same as Rails. It even has the same folder layout.
• There is IDE support for Grails.
• Grails is in its infancy. 1.0 due out in a few weeks.
• Integrates robust tools such as Hibernate, Spring and Jetty.
• Several Javascript frameworks incorporated, including Prototype, Dojo and Yahoo.
• Because it uses Hibernate, Grails supports a wide range of databases.
• Grails can build a standard WAR file, ready to be deployed to just about any Java servlet engine.
• Grails “is growing enormously”. The number of people involved is growing by an order of magnitude every six months. (!)
• Performance is comparable to Ruby on Rails, but somewhat slower than a bespoke Java web app. The good news is that it’s easy to replace performance hotspots with Java code.

Grails looks nice, partly because I can make use of the giant body of Java libraries in any Grails code I write. Next time I’m building a standalone web-app, I’ll definitely consider it.

Update: Paul, of course is also responsible for much of the Groovy content in the PLEAC.

Caught a number of interesting sessions yesterday:

• Adam Kennedy spoke animatedly on the topic of CPAN 1.5. I have only an abstract interest in the CPAN as a colossal piece of software engineering, but Adam is always amusing.
• Josh Heumann’s Intermediate Perl Testing turned out to be more about testing than Perl. Lots of good advice for organisations that don’t yet have testing as part of their culture.
• Google’s own Leslie Hawthorn, Geek Shepherd, spoke about the Google Summer of Code program, which she manages, and then launched a similar program for High School students, Google Highly Open Participation Contest. My eldest is just one year too young to join in this year – next year for sure.
• Paul Fenwick’s dinner talk, An Illustrated History of Failure was funny, interesting and geeky. Everything a dinner talk should be.

And after dinner, went out with a crowd from Sydney. We drank lemonade and ginger ale.

Anthony Baxter, Python release manager, filled us in on the state of Python:

• 2.5.2 is coming and will be a bug-fix release.
• Moving from 2.x to 3.0
  • There will be a -Wpy3k flag for 2.6 which will warn of constructs incompatible with Py3K.
  • 2.6 will have “from future import” new features.
  • There will be a -3 flag to enable all future features.
  • There will be a “2to3” converter to programatically convert Python 2.x to 3.0.
• 2.6 final will come at about the same time as 3.0 final. There will be a 2.7. after that.
• 3.0 is not a rewrite.
  • The Python guys claim to have learnt from the Perl6 experience.
  • 3.0 is about throwing out junk, removing mistakes and adding new features.
• Big new 3.0 features:
  • print is now a function.
  • The <> not equals operator is going away.
  • String exceptions are going away.
  • All strings are now unicode.
  • Iterators are being used in many places where lists used to be returned, e.g dict.keys().
  • Parameters and return values can be annotated.
  • Absolute imports will be the default.
• There will be a standard library reorganisation, with lots of culling and renaming.
• 3.0 is nominally due for release August-September 2008, but Anthony thinks it might take a bit longer.

OSDC day 2 kicked off with Rasmus Lerdorf talking about security problems on the web. Highlights so far are:

• Pointing out the that many browser plugins are URL handlers. If you can find a bug in a plugin that handles a URL, then you can compromise users clicking on that kind of link.
• Live XSS hacking on http://www.liberal.org.au, the conference hotel’s website and a few others
• The JS-Yamanner worm.
• IE6 has some interesting problems, including:
  • in UTF-8, it interprets the character 0xE0 as the first byte of a 3 byte sequence. If you can inject an E0 into a data field and get it to redisplay on the browser, the browser will ignore the next two bytes, which may be an attribute close quote.
  • it will run Javascript source in an image tag: <img src=“http://evil.com/hack.js ”>.
• Until everyone upgrades their Acrobat plugins, it’s possible to execute arbitrary Javascript in the context of a site serving a PDF, or even the user’s local machine. The only safe way to serve PDF files is from a domain other than your own.
• Use crumbs to stop XSRF problems. A crumb is a unique piece of data put into each web form. When the user submits the form, the server should check that the crumb is the one that is expected.

Andrew Bolt presented very calmly on Insiders on Sunday, and I thought, “Hooray! The culture wars” are over. But no. Today Andrew Bolt is back denying the Stolen Generations.

In summary, his argument is that, because Robert Manne couldn’t name ten people out of the 100,000 in the Stolen Generations, the Stolen Generations must be a myth. And because of that myth, Aboriginal people don’t trust the government to take their children away, even when it’s obviously the right thing to do.

Great argument, except that the Stolen Generations are real. Many, many children were really, in actual life, taken from their families for no reason apart from a smug, racist belief that it would be better to raise them in White culture.

It got my blood boiling. I wrote a Letter To The Editor:

I was stunned to read Andrew Bolt deny the tragedy of the Stolen Generations. If Aboriginal communities have lost respect for their government, it is because of actual mistreatment suffered by older relatives and friends, not because a bunch of latte-sipping, academic, city dwellers told them a reconstructed history.

As Andrew Bolt points out, lack of respect for the government is hindering the intervention. Regaining that respect will be a long process, but it must start with acknowledging past wrongs and apologising for them. Saying “sorry” is the first step toward helping these little children.

The sooner people like Andrew Bolt start to ground their rants in reality, the better off we’ll all be.

And while I’m at it, I’d just like to point to an interview with Alexander Downer in which he describes the Northern Territory intervention in terms that the uncharitable might take to mean that it was just grubby vote-grabbing.

Well, it’s after lunch, and straight into The Consumer View of Technology by Steve Ellis and Cherie Carbines from OpenMedia, a New Zealand company that’s build a MythTV based PVR.

There seems to be problems around communicating with customers. Both explicit and implicit communication needs to be clear.

• There’s many ways to mis-communicate with customers. Moral: be careful.
  • One of OpenMedia’s early case designs looked like an amplifier so customers were confused and thought it was an amplifier.
  • Another example: broadcasters in NZ advertised “High Resolution” services and customers thought it meant “High Definition”, but it wasn’t.
  • OpenMedia’s literature said the hardware was based on a standard PC, so some customers were planning to use the PVR as their PC.
  • Be careful what you promise to customers when they request features. Even if you can deliver, you might have a world of pain supporting it.
  • Don’t be afraid to say what your product doesn’t do. It can save a lot of disappointing confusion for your customers.
  • When selling a new piece of hardware, product lifetime is a customer’s consideration. We expect fridges to last 10 years. Phones we only expect to last a few years. Is your new product a fridge or a phone?
• Eye candy is important for sales. Quote: “Blue lights sell products.”
• Even the cheapest routers come with 24×7 support.
  • Do you want to put out a product that customers expect 24×7 support with?
  • Email and web support don’t work. People want to talk to People.
  • Poor support can ruin your reputation. (Cue clips from The IT Crowd)
• Customers expect a printed manual, in the box. Pictures are helpful for the 20% of customers that read the docs. But too much documentation is intimidating.

BYAG means “Because You’re A Geek”. Consumers are your bread and butter, not the geeks.

Great talk. Valuable content that can be applied to online apps too.

Tom Adams’ Better testing through Behaviour on the topic of Behaviour Driven Development. BDD is an offshoot of “Test Driven Development” and Domain Driven Development. The central idea is that you first specify the behaviour that you’d like your code to have, in the form of tests, and then implement that specification.

Tom presented a bunch of examples from his Instinct Java test framework. Instinct differentiates itself from JUnit by paying a lot of attention to producing readable test cases – readable in the sense that you can make sense of it in English. Because of this, the test cases end up more like specifications. In the example on the Instinct website, he has a class named “AnEmptyStack” that tests the behaviour of empty stacks. This class has a method named “mustBeEmpty” that tests that the stack’s isEmpty() method returns true. You would read this as, “An empty stack must be empty”.

In comparing to TDD and JUnit some of the points (I think I heard) Tom made were:

• xUnit tends to work only at the code level, whereas Instinct and BDD tend to work both on high level stories and at the code level.
• Instinct and BDD dosn’t guide you so much toward strict units of code, but into adding behaviour wherever it’s needed to support the specification. In cases where you do need very clearly defined APIs – such as when providing public APIs to distinct processes or libraries, you will need to take extra care.
• Instinct does tend to drive more usable APIs.
• Instinct makes for more readable tests than JUnit, and plays nicer with IDEs.
• Because of the language, Instinct is a valuable resource for developer-developer and developer-analyst communications.

I think I’d like to try Instinct on one of my home projects, then perhaps use it in the office.

OSDC just started. Great to catch up with Keith and Mark. It’s great that Google could support the conference by sponsoring the dinner, but it feels little weird having “Sponsor” on my name badge.

The conference opened with a nice little speech by Scott Penrose, chair of last year’s OSDC committee, passing the baton to Arjen Lentz and the new committee.

Then it was straight into a keynote, Rusty Russell explaining what it is that he likes about C, that it is close to the machine. By way of enticing the PHP, Perl and Python programmers in the audience, he also demonstrated that C can do shell scripts too, by way of the Tiny C Compiler, tcc. I found the talk an interesting insight into hard-core C development.

Right now I’m listening to Ian Clatworthy of Canonical explaining why I might want to use a distributed VCS. I can see that there might be advantages, and I can see how it better fits the open source development model. I’m not sure there would be overwhelming benefits in the environments where I do most of my work. He’s saying that he sees a market for only three big distributed VCS systems – Bazaar, Mercurial and git – but that they all have “maturity” issues at the moment, and don’t yet have the kind of tool support many developers expect. Oh, and Bazaar is just a few weeks away from a 1.0 launch.