Convert OPML into rspec spec files

August 20th, 2007

I’ve been doing lots of work recently by writing up my specs in OmniOutliner and then converting them into spec files before I start writing my code. I knocked up a quick ruby script to handle the conversion for me.

First off, as I write my specs in a certain way in OmniOutliner the script follows my own conventions so will probably need modifying if you use it in a different way. In OPML form they should look like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<?xml version="1.0" encoding="UTF-8"?>
<opml version="1.0">
  <head>
    <title>billing_specs</title>
    <expansionState>0,1,5,9,10,14,18,19,23,26,27,34,42,48,57,60,69,78,85,89,94</expansionState>
  </head>
  <body>
    <outline text="Account">
      <outline text="when placing a first order">
        <outline text="should do something"/>
      </outline>
      <outline text="when upgrading">
        <outline text="should do something"/>
      </outline>
   </outline>
  </body>
</opml>


This will produce a spec file like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

describe Account, "when placing a first order" do

  it "should do something" do

  end

end

describe Account, "when upgrading" do

  it "should do something" do

  end
end

And there you have it, this has speeded up my development and saves me the tedium of rewriting everything into spec files.

You can download the script here – you’ll need to have the ‘xmlsimple’ gem installed for it to work

A new beginning

August 1st, 2007 It's official - the team behind SiteVista (me, Matt and Paul) are almost ready to release the new incarnation of SiteVista... and we've called it "Litmus"

Keep an eye on litmusapp.com for details and I'll also post an update here when we go live.
This is the culmination of many months hard work and bringing in all our skills to get the site completed. Paul on the design and marketing, Matt on the backend .net work and me creating the Rails based customer facing site.
More news soon.

Lighthouse: Basecamp for developers?

March 29th, 2007

I just received the launch announcement for Lighthouse hot off the press from the two guys that brought you Mephisto – the Rails blogging software I use to run this blog.

With an app authored by Rick Olson and Justin Palmer you expect something good and at first glance Lighthouse seems to deliver. Rick is a member of the Rails core team and a big contributor to the Rails plugin scene, his subversion repository alone leaves you in no doubt as to the strength of his Rails-Fu. Jason is a member of the Prototype core team and based on the visuals and javascript magic on the back-end of Mephisto I’d say he’s pretty good as well. So really, a pretty awesome partnership…

A first look picture.png

Recognise that screen cap? Looks a lot like Basecamp to me, but I think that’s ok… 37 Signals have really hit on a winning formula with their interface, it works well in Mephisto which as a similar layout and it works well here as well.

The ticket tab Picture2.png

Lighthouse allows you to manage what is going in within your projects, it tracks tickets and milestones much like industry staple Trac but does it with a lot more style, sophistication and importantly – simplicity. An interesting addition, also in the style of Basecamp, is the “Messages” tab which allows you to track messages and keep track of communications over time, something which is definitely important to any project and in the past was solved with a developers mailing list.

The messages tab Picture 1.png

It’s late and I don’t want to do this product an injustice so I’ll quickly skim over the other features of note… an api to allow external integration (examples are with subversion commit notices at the moment), ability to set projects as public, ability to create and respond to tickets via email as well as watching other tickets (and getting email notification of changes).

Prices seem pretty good as well – although the way features map to price points I’m not sure I’ve seen an ‘ideal’ plan for me. In terms of the number of projects you can manage the Bronze price plan is the best for me personally. However I don’t think the number of people per account reflects the number of people that may wish to report bugs. If every member of staff at one client company wanted a login to report bugs then that might use up my entire allowance, but at the same time what does it mean to make the project “public”. I might want people from that company to come and report bugs but I don’t want the whole world to see it – am I supposed to give that company one login to share?

Picture 2.png

I intend to give Lighthouse a good test out on a few project I’m working on at the moment so I’m sure I’ll have a few more points to add in the immediate future.

4 comments »

ActiveRecord Delegation and demeter

March 18th, 2007

A while ago I looked into the various aspects of the laws of demeter sparked by a post I read whilst trying to find out why Mephisto had the word “delegate” sprinkled throughout it.

If you haven’t come across demeter before then its worth reading the post I linked above and the Wikipedia Article

To sum up the concept in one short sentence, the magic that AR gives us that allow us to, for example, say: person.address.city is a dangerous thing to do. It’s all lovely and magic when its working but as soon as our person doesn’t have an address every reference to that throws a lovely nil.city error and promptly blows up our app.

Rails provides a delegate method which seems to have wrongly been assumed to handle this and protect delegated methods from returning nil errors but this isn’t the case. Using delegate you would expect to say:

delegate :city, :to => :address

and then expect to be able to call

person.city

without it all blowing up horribly if there is no address object attached to the person.

Well, after moaning about this to Dave we devised a new AR mixin called ar_delegate that lets you safely delegate methods to other classes and protect against the horrible nil errors that occur when you start nesting relationships using AR magic.

Dave has really come up with some lovely syntax that feels Railsey and hopefully we’ll be able to get this into core if it looks like its a good fit (and we write some tests). All credit to Dave for the code, I was merely an IM-advisor as he was writing it.

See ActiveRecord Delegation over at Dave’s blog for a much better write up and links to the plugin.