Categories
Software

[BarcampLondon3] Message-Oriented Architecture (Matt Bidulph, Dopplr)

HTTP not ideal for asynchronous stuff (“Are we nearly there yet?” “No.” “Are we nearly there yet?” “No.” “Are we nearly there yet?” “No.”). Message-passing architecture is better (“Let me know when we’re there” … “We’re there!”).

Also useful for clusters, multi-core machines etc.

Erlang (also Scala, Haskell, E etc) are becoming interesting because they operate using messages. Not that different to pure OO. No shared state. Scalability doesn’t come for free, but it’s much easier.

Spread, MQ, JMS etc: publish and subscribe. Stick a message on a topic or queue and any subscribers receive it. Allows very loose coupling. One-to-many, with publisher not needing to know about subscribers.

Comet allows a connection to be held open between browser and server, rather than having to poll.

Jabber can be used to return future results for a search (for example). “There will always be more pictures of kittens.”

Worker queues remove expensive calculations from synchronous tasks (eg calculating Dopplr coincidences does your own immediately, and queues a job to calculate coincidences for all your contacts).

Using JQuery you can create your own events in a browser. Becomes more like traditional GUI programming.

Extreme late binding: combine data and code in application (eg javascript and data in browser – mashups).

The Internet is the computer.

First question: “How does Dopplr work?” :-)

Interesting point about hiring: go for the people who are good at the cool stuff (Erlang, Haskell, etc), because they’ll probably be really good at the workaday stuff too, and are obviously interested in the field.

[tags]barcamplondon3, messaging, erlang[/tags]

Categories
Software web Web 2.0

[BarcampLondon3] Caja/OpenSocial (Ben Laurie)

Caja compiles Javascript into different javascript, allowing you to put untrusted gadgets in trusted container pages (eg OpenSocial). Removes potentially evil code (eval etc), and passes in an object representing the global scope (document etc).

Ben’s writing a Caja wrapper for OpenSocial. Lots of hairy stuff with closures wrapping callbacks in functions, then wrapping the response in more functions. I haven’t really looked at OpenSocial yet, so some of this is flying merrily over my head.

[tags]barcamplondon3, caja, opensocial, javascript, gadgets[/tags]

Categories
Software web

[BarcampLondon3] Tom Morris on GRDDL

Screen-scraping HTML is evil. APIs are better, and can return structured XML, JSON or even SOAP (everyone laughs at the latter!)

If page is marked up semantically using microformats, an XSL stylesheet can convert it into RDF. Put the stylesheet on a profile page and link to it from the HTML (<head profile="...">), and triplr can generate triples from it in various formats. This can then be parsed using SPARQL.

The end result is custom microformats, possibly specific to your site, or something like class="nsfw" to mark up stuff that’s not safe for work, which Tom uses on his blog.

GRDDL allows

[tags]semanticweb, grddl, barcamplondon3[/tags]

Categories
Agile

[XPday 7] The Informed Coding Dojo

This session was run by Karl Scotland & Johanna Hunt. I helped run a coding dojo at work for a while, until it just kind of fizzled out, so I was interested to see how someone else approached it.

The twist was that the dojo was run using Inform 6, which is a domain-specific language for writing text-based adventure games (“You are in a maze of twisty little passages, all alike…”). this meant that none of the participants were familiar with the language, which forced us to take very small steps rather than quickly hacking together large chunks of code based on experience.

The baby steps thing seemed to work quite well, helped by the strict five minute pair rotations (driver back to audience, navigator to driver, audience member to navigator). Those rotations weren’t quite like the way we used to do it (we never really settled on a fixed policy, and experimented with ping-pong pairing, swapping both people out of the pair at once and increasing timeslots to ten minutes). We also weren’t as strict about banning suggestions and comments from the floor – stopping that seemed to help avoid circular conversations and let the pair get on with coding, although the unusual language may have helped here too. It was very frustrating though when you could see an mistake that was causing compilation errors, but the pair hadn’t seen it yet.

As it turned out we only got about halfway through the tasks we’d been set. It was quite an enjoyable hour and a half, but I’m not sure how much I learned.

[tags]xpday, coding dojo, pair programming, inform6[/tags]

Categories
Agile

[XPday 7] Jeff Patton Keynote: “Embrace Uncertainty”

Jeff gave an entertaining presentation on strategies for coping with the inevitable changes that take place during a project release. The talk was punctuated with blasts of music from various artists filling in as personas, from Mel B as a developer capturing user stories (“So tell me what you want, what you really really want”) to Johnny Rotten as an experienced agile practitioner (“Don’t know what I want, but I know how to get it”).

Many companies are now adopting agile methodologies such as Scrum to jump on the agile bandwagon, and are looking for consultants to provide training, and to come in and tell them all the answers to their problems. Because they are looking for prescriptive processes that they can put in place for people to follow, we are starting to see ever-more complex systems for things that were previously considered simple tasks (such as prioritising user stories). This is what Fred Brooks referred to in No Silver Bullet as ‘accidental complexity’ – complexity in the activities around writing software, rather than in the domain of the business problem you’re supposed to be solving.

Is this process rigor, or rigor mortis?

We have forgotten the meaning of iteration, and are working in increments instead. We are expecting an ‘iteration’ to contain a number of fully-completed stories, which we can then forget about and move on to new features. The problem with this is that when we deliver those stories, the customer is not entirely satisfied, and we have to introduce new stories to refine the design. This in turn affects our velocity, because we find ourselves spending more and more of our time enhancing features that we thought were done.

It’s not iteration if you only do it once.

Alastair Cockburn has suggested a ‘three story’ approach, where you make the iteration explicit by putting two additional cards behind each user story – one to fix the original story, and another to fix the second attempt. Jeff’s only concern with this was that people might take it too literally, doind a seond rework even if the customer was already happy, or stopping after the third story when the feature clearly wasn’t really done.

Along with YAGNI, Jeff suggested adding YAGRI (you ain’t gonna release it). This was to remind us that it’s OK to present non-production features to the customer, in the knowledge that they won’t be released until they’ve been iterated into a deliverable state. To me that seems OK for shrink-wrapped software and other things where iterations aren’t released, but I wonder how it applies to web applications, where it is becoming the norm to release small changes frequently (perhaps multiple times per iteration). In that case, we’re used to making the assumption that everything is always releasable. Maybe the answer is to separate new, ‘beta-quality’ features from the main body of functionality.

Three strategies for coping with the inevitable uncertainties in building a release were described:

Follow the Money

Prioritise the business goals. By focussing on the things with the highest value to the business you restrict the user constituencies which you should target first, and hence identify the highest priority user stories.

Don’t Choose the Solution Too Early

Focus on the user goals rather than the perceived requirements on the application, and consider and discuss alternative ways of meeting those goals. It may be that a simpler or cheaper implementation than the immediately-obvious one may be sufficient.

Build up Quality in Iterations

Sometimes the customer really does need everything to be implemented before the product can be released. In this situation, you can start by implementing stories to a very basic, almost prototype, level. You then build up the quality iteratively, using feedback from the rough-cut implementations to guide you. One way of doing this is to grade each story (eg A+ down to F, plus I for incomplete), then have a ‘passing grade’ at which the feature is considered fit for release.

One consequence of actually iterating, rather than using ‘iteration’ as a label for an incrementl chunk of functionality, is that there’s a lot more work for the customer (or product owner, or whatever you want to call them). They need to work frequently with the developers to evaluate each version of a story’s implementation and describe the changes necessary to make it fit their needs.

The summary of the talk was to question common practice and to trust your instincts. As an aside, that leads into a rant I keep meaning to get round to, on the subject of people who say that a particular behaviour “isn’t agile”, because it doesn’t fit the letter of their particular methodology of choice. Watch this space.

[tags]xpday, iteration, agile[/tags]

Categories
Rails

Weird Rails bug

I Spent some time yesterday tracking down a bizarre bug which was causing some of our Selenium tests to fail. Watching the browser running the tests, I could see that occasionally a page would fail to render, with an “invalid argument” error and a stack trace. The line in question was an <%= end_form_tag %> in a layout. The strange thing was, it didn’t display the same behaviour when I ran the single failing test on its own, or when I viewed the page myself.

Or at least, I thought it didn’t. Because it seemed intermittent, I tried reloading the page a few times, and sure enough, the error appeared. Once. Then the page reloaded successfully six times, before failing again. This was completely repeatable – six times OK; one stack trace. Regular as clockwork.

Completely stumped, I thought I might as well at least replace the deprecated <%= start_form_tag %> … <%= end_form_tag %> with <% form_tag do %> … <% end %>, and lo and behold, that fixed it.

Unfortunately, I have no idea why. An imaginary prize to whoever can explain it!

Categories
Java Ruby

String#casecmp

As far as I can tell, this is the correct way to do case-insensitive string comparison in Ruby:

if string1.casecmp(string2) == 0
  # strings match, ignoring case
end

That’s so ugly, it almost looks like Java. Actually, it’s worse than Java, which has String#equalsIgnoreCase.

Categories
Agile Ruby Software

Driving Selenium from the RSpec Story Runner (RBehave)

[Update] The story runner is now included in the 1.1 release of RSpec, so a lot of the hackery mentioned below is no longer required. See http://rspec.info/ for details.

Background

A while ago I cobbled together some code to drive Selenium from Exactor (which was the acceptance testing framework we were using at the time). That project was offshored shortly afterwards, and I’m pretty sure Selenium never actually got integrated into the build (sneaking a peek at the continuous integration server reveals that even the pre-Selenium acceptance test build hasn’t run successfully for months), but I was convinced of the value of Selenium for testing non-trivial web applications.

On my next project (the Web21C SDK portal) we used Selenium on Rails heavily for automated acceptance testing. This worked well, although the fact that the tests are deployed with the application limits what you can do – you can’t interrogate the database after a test, for example, or dynamically set up stubs for systems you interface with (unless you also deploy the stubs as part of the application, and drive them from the browser).

With Mojo there’s an additional complication: as well as being accessible through a browser, most functionality is also available as a RESTful API, using digest-based authentication. To keep our acceptance tests in one place, we wanted to be able to drive a browser using Selenium, alongside other tests which talked to the server directly. The obvious answer was to use Selenium Remote Control, and I also liked the look of RBehave, which has now been incorporated into RSpec (but not released yet).

The RSpec story runner

The story runner in the upcoming release of RSpec is an evolution of Dan North’s RBehave, which in turn is based on JBehave (from the same author). In the past couple of weeks, David Chelimsky has done some excellent work on extracting the text of stories from the code, leading to the plain text story runner.

Read on for the gory details of my solution to running Selenium tests from the story runner.

Categories
Apple Ruby

Ruby in Leopard: so close and yet…

I was quite excited to see the announcement of improved Ruby and Rails support in Leopard, and one of the first things I did after upgrading was to delete my MacPorts installations of Ruby and RubyGems, and try using the built-in ones instead.

For a while, all seemed well. The milk was cold, the food stayed fresh, my specs still passed, my Rails projects still worked, and even the light worked when you opened the door.

But then the trouble started.

Firstly I tried updating and installing gems while behind a firewall. The gem command completely ignored my http_proxy setting, and when I explicitly provided the proxy using -p, I got this error:

ERROR:  While executing gem ... (NoMethodError)
    undefined method `[]=' for #

I worked round this by downloading the gems manually and installing the local copies (despite this being a pain, especially when there are dependencies).

I then tried using gemsonrails to freeze some gems, and it got confused by the fact that Leopard stores built-in gems separately from user-installed ones. Thinking about it, if I’d successfully frozen the gem, it might have turned out to have been tweaked in some Mac-specific way and broken on other platforms.

Forgetting about that issue, I carried on with other work for a while, then found that autotest wouldn’t work, and mysteriously was trying to run something from /opt/local (where MacPorts install lived). Even after removing any gem-related scripts from /opt/local/bin, the problem persisted.

Oh well, looks like I’ll be re-installing everything using MacPorts. I’m not sure whether all these problems are intrinsic to the Ruby installation that comes with the system, or whether some are caused by lingering remains of my MacPorts installation – I’d be interested to hear how others got on.

[tags]ruby, rails, mac, 10.5, leopard[/tags]

Categories
Rails Software

Rails, SOAP and REST

From the list of new features coming in Rails 2.0:

It’ll probably come as no surprise that Rails has picked a side in the SOAP vs REST debate. Unless you absolutely have to use SOAP for integration purposes, we strongly discourage you from doing so.