Just A Summary

For years I’ve managed to dodge learning JavaScript. People have told me it’s a fine language with some dodge implementations. Friends have built an entire business model in the language, and I’ve continued to treat as if it were The Sound of Music (I’m 39 now and I have managed to completely avoid watching that film).

Except, today I finally had a technical need that I couldn’t dodge by writing another .rjs file, so with the help of the Prototype docs, a helpful article or two and healthy dose of cribbing from others, I was off.

What do you know, it really is a fine language. I doubt I’m writing idiomatic code though – I’m leaning heavily on closures and private member functions, and I haven’t written a single for loop yet, but it seems to accommodate my style.

Now, if I can just get my head round the innards of keyboard events I shall be a great deal happier.

Wow:

$ rake spec
...

156 examples, no failures

$ ./script/spec spec
...

156 examples, 2 failures

$ rake
[unit tests, all pass]
[functional tests, all pass]
[specs...]

156 examples, 2 failures

For extra points, the 2 failures from running the plain rake are not the same as the failures from running ./script/spec spec. And if I run ./script/spec spec after a full rake run, I get a host of extra failures.

I wonder what I’m doing to so comprehensively screw up test isolation.

Ho hum.

It’s definitely fun to commit a major rework of something that’s been bugging you to SVN. It’s slightly less fun to check it out in your production server and have it fall over until you remember you to retweak the environment.rb file.

Anyhow, we’re now running on Typo 4.1.1+r1438. Typo 4.1.1 got released last night and, pretty much as soon as it had cleared the gates I checked in a major rework of the Article and Feedback state mechanisms.

What state mechanisms?

When you’re modelling blog posts, and comments, it’s very easy to think of them in terms of simple status flags. An article is published, or its a draft, so we have a #published boolean and we’re done.

Except, what about an article that you want to publish at a specific time? And how do we work out when to send notifications and trackback pings? Should you send the pings again when an article is first published then withdrawn, then published again?

It’s complicated, and you can end up with a rats nest of complex conditional code.

So, you work out that an article can be in one of several states. We went with :new, :draft, :just_published, :published, :publication_pending, :just_withdrawn and :withdrawn, and we used the State Pattern to handle this. All our tangled conditionals were replaced with simple delegations to the state object. There’s still some conditional code, but there’s a great deal less of it now.

Until recently, we implemented the states using Rails’s composed_of helper, but it’s not really suited to the task – you know your code isn’t happy when you find yourself calling a class ContentState::Factory and overriding its new method. It was also really hard to divine the workings of the state machine.

So, during a discussion of Coding without ifs I found myself sketching a way of setting up a state field declaratively and thought to myself “Hey, I could implement that for Typo and make things a good deal clearer…”

So I did.

Now, if you look at the top of article.rb, you’ll find:

  has_state(:state,
            :valid_states  => [:new, :draft,
                               :publication_pending, :just_published, :published,
                               :just_withdrawn, :withdrawn],
            :initial_state =>  :new,
            :handles       => [:withdraw,
                               :post_trigger,
                               :after_save, :send_pings, :send_notifications,
                               :published_at=, :published=, :just_published?])

  include States

And it sets up the delegations (as well as a set of #new?, #draft?, ... predicates based on the names of the valid states) for you. I pulled the States module out into a separate article/states.rb file, but given a simple set of states there’s no reason not to declare them inline.

I’m really pleased with it. I’ll probably do a bit more work on the interface (I want it to be more language like), add a has_strategy declaration (which I intend to use for our feedback spam checking system) and then extract a plugin from it. If you’re interested in doing something similar in your own code right now, the thing you need to pinch is lib/stateful.rb in the Typo distribution, and the only documentation is the source. Check app/models/feedback/states.rb and app/models/article/states.rb for examples of states written to this interface.

Last year, you would have been forgiven for thinking that Typo was pretty much dead in the water as an ongoing project. Typosphere was a placeholder, changes were few and far between, the app was a bloated monster. So, people switched, in droves, to Mephisto the new, (and excellent) kid on the block. Heck, even Tobi, the original author of Typo, has switched.

Mephisto’s a great piece of software, and I’m as sure as I can be (without taking a closer look) that its underpinning code is cleaner than typo’s. When you’re developing on a rapidly moving platform like Ruby on Rails, there could be said to be a second mover advantage – the later you start, the more likely Rails is to already do what you want, and the less likely you are to zag where Rails later zigs.

However, Rick and Justin have other projects and demands on their time, and once something is Good Enough, it’s hard to summon up the motivation to make it better until you find something that you want your application to do.

So now, as Typo comes out of hibernation, it seems that Rick and Justin have been getting it in the neck because their project is ‘stalled’. Okay, so I admit, I did smile ruefully to myself when I read that.

Then I read the comments. Wow. Some people have some serious entitlement issues.

It’s been said before, it’ll be said again I’m sure: if you don’t like something about an open source project, “Patches welcome!”. If your patches are repeatedly rejected: it’s open source, fork off. If a project is moribund: offer to help.

Complaints just put people’s backs up.

I think it’s great that there’s choices available if you want a blog built Rails. Different perspectives on a problem space are important – if nothing else, everyone gets to steal from each other, everyone’s apps get better and everybody wins.

Let’s say you’re running tests against your rails application and a test fails.

“Hmm…” you think, “I wonder what could be causing that, let’s run that test file by itself.”

The test passes.

“Okay… I wonder if it’s the rake test loader, let’s run that test file using that.”

The test passes

“Right, it’s only the third test file on the list that’s failing, let’s try running just the first 3 test files.”

The test fails.

“Okay, so it’s one of the first two test files that’s causing the problem. Let’s remove one and see what happens.”

The test passes.

“Right, because I’m paranoid, let’s try running it with the other test file instead. It should fail.”

The test passes.

“Hmm… the failure appears to be fixture related, let’s try turning of use_transactional_fixtures in test_helper.rb and running the failing set of tests again.”

The test passes.

Houston, we have a problem

Part of our problem is that Typo is so huge and old, and its test suite is somewhat spotty. Something we’re doing in the workings of a couple of our controllers is confusing transactional fixtures and that can’t be good. I suppose my first step is to get all the tests that are still failing with transactional fixtures turned off passing and see if that solves my transactional problem, but I can’t pretend it’s a fun option.

When you read Christopher Alexander’s A Pattern Language, the patterns within the language are interdependent and ordered from big patterns down to small ones. Each pattern has a number and wherever one pattern refers to another it’s referenced with both the pattern’s name and its number.

Beck, Fowler and the Gang of Four (if memory serves) go one better, wherever they reference a pattern, they give the pattern’s page number (ah, the joys of computer typesetting). I’m not sure it’s an enormous improvement over pattern numbers with the pattern numbers in the running heads, but both practices make the books easy to use.

Writing this up as mini patterns, (very roughly based on Alexander’s pattern format) you’d have something like:

A Tiny Pattern Language for technical writers

1. Organizing Principle

You’re writing a Pattern Language on paper

Without some organizing principle, a random collection of patterns is just that

When you’re organizing material in a book which needs to be usable both as a learning resource and as reference material there’s a tension between the needs of the new reader who wants each pattern to follow logically from the patterns she has already read about, and the needs of a seasoned pattern user who needs to find details of a specific pattern.

It’s tempting to take the view that a reader is only new once, so it’s best to arrange the material to suit the reference user and put your patterns in alphabetical order. Don’t. If your material doesn’t make sense to the new reader, they’ll never reach the point where they use your book as a reference.

Therefore:

Arrange your patterns for new readers. Provide an index and cross references to support reference use

Use Arrange Patterns by Scale(2) to order your patterns and Reference by Name and Number(3) for your cross references. Provide a Table of Contents and an Alphabetical Index.

2. Arrange Patterns by Scale

You’re choosing an Organizing Principle(1) for your pattern language

It’s hard to understand a pattern without some idea of where it fits in the scheme of things

Read A Pattern Language, look at the way that each pattern in the book flows from the ones that precede it and leads you on to the patterns that support it. There’s a huge amount of information in that book, but it just flows. It has The Quality Without A Name.

Now read Universal Principles of Design, another book which contains a great deal of good information backed up with great pictures and some real research. Each spread in the book is analogous to a Design Pattern, and each spread is great. It’s a bugger to read though. The designers have chosen to arrange their principles in alphabetical order; reading through is like being taken on a drunkard’s walk by a conceptual grasshopper. Many of the principles are hierarchical, but the reader is left to work that out for themselves. It reminds me of the joke about reading a dictionary; the content’s great, but the characterisation and plot are all over the place.

Therefore:

Find patterns that use other patterns, put them before the patterns they use. Group patterns with a similar scale or motivation in chapters.

3. Reference by name and page number

You’re referring to a pattern.

Why can’t books be more like the web?

We’ve all done it I’m sure; one part of a book refers to another part and gives just the section title. We curse the author or his editor and go scurrying off to the table of contents or the index to find the referenced page and then turn to it, all the while keeping our index finger jammed between the pages so we don’t lose our original place.

Or the author has taken pity on us and, following the Chicago manual of style, supplies a section number (with multiple decimal points) and we start flipping forwards or backwards to find the right section number. This is less fun than it could be because no two sections are the same length. Or the content’s arranged alphabetically, and every section is the same length, but we’re not entirely sure of how many sections start with any given letter – I’m looking at you Universal Principles of Design.

There has to be a better way. Wouldn’t it be great if we could just go directly to the right page as if we were following a hypertext link?

Indeed it would.

Therefore:

Whenever you refer to another pattern, use both the pattern’s name and its page number; that way the reader can turn directly to the right page without having to visit an index or flip hopefully trying to guess how long each section is.

What next?

Obviously we need to hunt down and deliver a good telling off to authors, editors and publishing houses that don’t follow this pattern language.

Would you believe that I started this article meaning to write a review of Universal Principles of Design? Despite my grumbles about it above, it’s a cracking book full of really meaty stuff. I commend it to you all.

From Extreme UI Testing:

Method wrappers. Easily possible in VW and Squeak since you can subclass CompiledMethod and much with the method dictionaries [...] Niall uses a strategy pattern to automatically wrap threads that get forked off by looking up the stack to see if the code is under test (and if it is, make sure to install a wrapper)

So what if the language doesn’t give me the callbacks I need, I’ll just rejig the system classes until it does. Until Avi needed them for Seaside, Smalltalk didn’t have continuations, but it’s malleable enough that he could implement them.

Malleability rocks (even though rocks aren’t exactly malleable.)

So, since I couldn’t sleep, I’ve been hacking on the routing drop in replacement.

I’ve reached the point where things are mostly working and I can at least run the benchmark tests.

On this machine, Rails recognizes routes at a rate of around 22K url/s.

At the start of the night, with the recognizer rparsec, to do the recognition, my new routing system was running at around 5K url/s, which isn’t exactly great. So, I rejigged things to build a regular expression and use that to parse the request URL and the recognition rate jumped to 12K url/s. I’m really pleased with that number for the time being.

Rails goes faster because it’s doing some hairy eval STRING optimization that makes things rather hard to follow. If I can get up to better than half that speed without the hairiness, I’m happy.

For now.

Those of you who’ve been reading attentively will be aware that I’ve been working on a drop in replacemen for a chunk of Rails’ routing subsystem. You will also be aware that things have gone a bit quiet on that front.

I got a job.

Which is lovely, and fabulous, and safeguards my mortgage payments and all that good stuff. But it has rather put dampeners on any non paying work.

Finding the balance

What with throwing myself into the new job and spending last weekend visiting friends, family and the Brighton Coding Dojo mob, I’ve been neglecting other coding commitments. This should not be a permanent state of affairs, I’m hoping to return to the new routing project over the weekend. It’s all a matter of finding the balance.

On Monday I was down in Brighton for a Brighton Coding Dojo where I had a crack at doing Kata four in Smalltalk.

It took a while to find the balance, but once we got going I think it went well.

We stuck in what seemed like the strangest places though. At one point, I had a method that did almost exactly what I wanted for a new method I was writing so I called up the method in the browser, changed the selector and the few bits that needed fixing up and accepted the changes.

Uproar! “Wha? What’ve you done to testGetMnT?”

“It’s still there, look.” I said, pulling testGetMnT up in the browser.

“But…!”

People were impressed by OmniBrowser’s refactoring tools and slightly boggled by the sheer number of instance methods on Object.

Because we dived straight in, people got a wee bit stuck on the syntax as well. Next time I do something like this, I’ll spend more time walking through what’s going on in each line of code, until people get a bit more secure, and I’ll start handing the keyboard off to other pairs way sooner. Once I did that, it became far more apparent which bits were sticking points.

The session certainly confirmed my opinion that you can read all you like about Smalltalk, but you won’t really get it until you see it in motion.

So, once I have some tuits of the appropriate shape, I’m planning on making a longish screencast of me running through Kata four, with commentary. It won’t be an exemplary example of a Smalltalk user getting the very best out of the toolset; I’m very much a beginner myself, but I hope it’ll give you a feel for why you should at least try Smalltalk for yourself. I also hope that any experienced Smalltalkers watching the screencast will be able to give me some tips on better ways of using the tool.