Just A Summary

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.

If you’re reading this on the website rather than through a feedreader and you look to the left you’ll see either a bunch of links to cited books or an Amazon ‘self optimizing links’ banner (though, if it keeps ‘optimizing’ like it has being I’ll be changing it to something else). This is implemented using a mildly hacked version of the standard typo amazon_sidebar plugin.

“But,” I hear you say, “The sidebar’s over on the right, and Typo can only support one sidebar.”

And you’re right, Typo’s admin interface can only handle configuring one sidebar, and I’m not entirely sure how to make it work with too – hopefully our new maintainer and usability advocate, Frédéric de Villamil has some ideas along those lines. So, how does it work.

Let’s take a look at a fragment of my layouts/default.rhtml file shall we?

In case anyone’s interested, I’ve written a list of some of the things I’m currently mulling doing with Typo below the fold.

Mmm… Rails routes, don’t you love them?

Well, not unreservedly, no.

Here’s my current problem: Typo articles have a permalink that looks like /articles/:year/:month/:mday/:permalink, so the permalink for this article is /articles/2007/03/15/cover-me-im-going-in and when someone visits it, the controller gets a params hash which contains keys along the lines of:

1. the session, controller, etc }

Which is okay as far as it goes¹, but it’s a complete pain when it comes to generating the url. I have to do:

Every value in that hash is dependent on a single object, every key is the same as the method used to find its associated value. I want to be able to write a route that looks like this:

That’ll do for starters; I’ll worry about making it Resourceful once I’ve got the basic recognizer and generator working.

So, that’s what I shall be working on within acts_as_resource for the next while. Once I’ve got it working, I’ll start using it within Typo and we can get rid of the various model methods we ended up adding to cope with generating our URLs.

Why bother?

The thing to remember is that, while routes like /:resources/:id are okay when you’re prototyping, they’re problematic for production. Opacity is not a virtue. Exposing internal database keys in the URL is a positive vice.

Meanwhile /articles/2007/03/15, /articles/2007/03 and /articles/2007 all have obvious meanings and typo supplies the obvious index pages when you go to look at them.

¹ However, it would be better if it were actually more like: {:article => {:year => '2007', ...}, :controller => ...} because then I can find the article by a simple Article.find(:first, :conditions => params[:article]) and let sanitize_sql do all the work for me.

I’ve been eyeing the rspec and rspec on rails packages and thinking I should give them a go.

To my eye at least, something like:

context 'Given a published article' do
  fixtures :contents

  setup { @article = contents(:published_article) }

  specify 'changing content invalidates the cache' do
    @article.body = 'new body'
    @article.invalidates_cache?.should_be true
  end
end

context 'Given an unpublished article' do
  fixtures :contents

  setup { @article = contents(:unpublished_article) }

  specify 'changing content keeps the cache' do
    @article.body = 'new body'
    @article.invalidates_cache?.should_be false
  end
end

reads far more fluently than the equivalent Test::Unit based tests:

class CacheSupportTest < Test::Unit::TestCase
  fixtures :contents

  def test_changing_published_article_invalidates_the_cache
    art = contents(:published_article)
    art.body = 'new body'
    assert art.invalidates_cache?
  end

  def test_changing_unpublished_article_keeps_the_cache
    art = contents(:unpublished_article)
    art.body = 'new body'
    assert ! art.invalidates_cache?
  end
end

So, I installed everything and started to work on a new class in Typo using rspec. Rather annoyingly, this seemed to break the current test suite, so instead of working on my new model class, I set to porting the existing suite.

And, on about my third test suite, I found what I think is a bug in the suite. I’m not sure it’s a bug, because, the way the test is written (by me, I admit it), masks the intent quite dramatically. I’m also finding that the freedom to name specifications and contexts in English rather than method_names_that_go_on_for_ever is forcing me to come up with much more useful descriptions of what I’m testing. I find myself working on making the spec runner output read reasonably well as English, and doing that casts light on what is and isn’t being tested.

I’ve known for a while that Typo’s test suite is, um, spotty, but the porting process is really helping me get familiar with what’s being tested. I’m half tempted to start adding extra specs as I go, and if I could work out how to keep the existing tests working while I did it, I would, but my priority for now is to get to the point where I can check the specs and be confident that the new specs are no worse than the old tests.

Because I’m much more confident that I know what the specs are doing, I’m also confident that it won’t be hard to revisit them to help specify typo’s behaviour better. I’ll just have to give myself the discipline of beginning each coding session with half an hour of fleshing out the specifications before I get back to adding behaviour.

Writing migrations can get pretty tedious when you’re being scrupulous about writing both the up and the down side of the migration. Okay, so the Textmate ninjas amongst you can use scarily clever snippets to populate the down migration while you write the up method, but I can’t be the only Mac user who still prefers Emacs. And not everyone gets to run on Macs either.

So, inspired by something Jamis Buck wrote about designing a DSL, I’ve been sketching out a DSL for describing the easy parts of a migration in declarative style. None of this is implemented yet, but I’m pretty sure that it’s relatively simple to implement for a decent Ruby metaprogrammer. I’m brain dumping it here so I can come back to it later, or, you never know, someone might have implemented it by the time I revisit…

Typo users with longish memories will recall the absolute disaster we had when Rails 1.1 shipped and Typo wasn’t even remotely compatible with it. Even edge Typo didn’t work with 1.1. Chaos and confusion, strong words from DHH, all manner of unfun things.

So, this time, we’re not going to let it happen. We hope.

For starters, the current Typo release, 4.0.3 is locked to Rails 1.1.6 – if you install it from the gem it will insist that you have an appropriate Rails gem installed too. If you install it from SVN, it will use the magic of svn:externals to stick the right version of Rails in vendor/rails and, if you’re using SVK, we assume you have enough of a clue to populate vendor/rails appropriately.

What about Edge Typo then?

Edge typo is currently fetching edge rails via svn:externals, but I’ll be switching it to the Rails 1.2 branch in the next couple of changesets, which should mean that, as soon as Rails 1.2 is released, we’ll be able to push out Typo 4.1.0 pretty promptly.

What does Rails 1.2 mean for Typo?

Over time, Typo and Rails have diverged somewhat; in part it’s because we were trying to do some stuff before Rails made it easy, and we didn’t necessarily make the same choices as Rails did, so we’ve got a pretty huge code base that’s doing an awful lot of heavy lifting that could (and should) be left to Rails. One of my goals in the next development cycle is to bring Typo more into line with the Rails way. Some things are sacrosanct of course: Article permalinks are sacrosanct – if an article has the url http://www.bofh.org.uk/articles/2006/11/24/typo-on-rails-1-2 today, then it’s going to continue to have it for as long as you’re running typo and on the same server. And any new articles will have canonical URLs of a similar form.

Pretty much everything else is up for grabs though. We’re going to try and keep well known URLs working but they may be redirects to a more RESTful canonical version, and we’re not about to break your feeds any time soon, but the admin urls will certainly be changing (again we’ll put redirects in for a few releases, but they won’t be supported in perpetuity).

You may or may not know that Typo is multiblog capable under its hood. There is a blogs table in the database and every single request ends up fetching the blog object by doing a Blog.find_by_base_url query.

We don’t have UI support for multiblogging though, and the vast majority of Typo installations have exactly one blog object. Even when multiblogging comes along, there won’t be that many blogs in any given installation.

The problem is, the instance caching tool we’re currently using only caches objects that are fetched using Model.find(id), so we end up with a basic page hit finding the blog by searching for the base url and then, later, fetching it again using the id.

One option is to fix the caching mechanism.

But that’s too much like hard work. So, in the latest checking on the typo trunk I’ve fixed things so that environment.rb builds a hash which maps from base urls to blog ids. So now, the first thing we do with any incoming request is use the hash to find the id of our blog object and then do Blog.find(id) et voila we’ve fetched our blog and populated the instance cache as well. God is in his heaven, all is right with the world, and we’re doing one less query per page hit.

I’ve been taking an accidental sabbatical from Typo. It started during conference season, then there was a bunch of housekeeping and general home type stuff that needed doing, so I’ve been away from the codeface for a while (and I still haven’t turned my EuroFOO talk into a podcast, or finished scanning and uploading all the EuroOSCON photos…)

However, I am back and coding, and a new typo feature just made it to the top of my todo list: This morning, in a fit of over enthusiasm, I managed to zap the 36 most recent comments on this blog. And, for bonus points, I didn’t have a backup.

So, now I have a backup regime in place. And the next feature I add to Typo is going to be a confirmation box when you attempt to delete any feedback that hasn’t been marked as spam.

Recent changes added to the typo trunk add CachedModel support, which dramatically reduces our query count per page, which is no bad thing either; I have other ideas for getting that count down too.

So, until the Typo Trac is back up, watch this space, I shall try and post here whenever there’s any significant changes on the trunk.

Updates

Google cache is my friend!

Miles Barr reminded me in the comments that, as well as hanging on to all those embarrassing infelicities, Google’s search cache also remembers good things like comments that you foolishly delete.

Sadly, it didn’t remember everything, but it did remember everything, but it did remember a lot, so various articles have their commenty mojo working once more.

Did I really just say ‘commenty mojo working’? It seems I did. Ah well, it’s 6.20am and I’ve been awake since 4, I think I’ll let myself off with a caution.

Oops I did it again

But my backups just saved my arse. Now I really should get on with making sure I don’t do it again.