magpiebrain

Click for larger image

I’ve long been a fan of the python-based ticket tracking/wiki/subversion browser, trac. It manages to integrate subversion changesets with tickets quite simply – go to a changset page and you’ll see the edits; go to a ticket and you can see all changesets that apply to the ticket. On top of that you can use wiki syntax in your subversion commit messages (or anywhere for that matter) – to my mind trac is perfectly capable of doing away with the need for separate systems (certainly on my next project I’ll be recommending trac over a Jira/Wiki/ViewCVS or FishEye combination).

I’ve long been a critic of the CruiseControl reporting application. Whilst the underlying build-loop is fairly solid, the separate reporting application lacks features, is slow, and is in need of some UI love. With the new 0.9 development, edgewall have added a plugin architecture. Ditching the CruiseControl reporting application in favour of a system which is fully integrated with your changset and ticket monitoring system seemed like an obvious next step, so I spent the weekend working on a spike to do just that.

The overall aims of the plugin are:

• To show CruiseControl builds in trac’s timeline, alongside wiki edits, ticket changes and SVN modifications.
• To have a page for each build which can be linked to using trac’s wiki syntax as with tickets and changsets
• The build page should show the same information as the existing reporting application
• It should be faster than the existing XSLT-driven reporting application
• When looking at a ticket, you should be able to see what builds apply to it (this for me is the real killer feature)

• Going forward, the plugin should work with other Continuous Integration tools (top of the list will probably CC.Net)

  As you can see from the above image, integration into the timeline was fairly easy. Currently when the timeline is requested, my simple SAX-based cruise log file parser pulls out the relevant information. The next step here is to place this information in trac’s built-in SQLite DB (which should take care of the ‘being faster than XSLT’ requirement). I may even create a plugin for CruiseControl so it can ‘push’ build results to trac in a cleaner, more efficient manner than parsing the XML files (a simple REST webservice for trac should do the job here – trac already seems pretty RESTful). A page for each build is probably my next priority though. The only unknown at present is whether or not I can integrate the builds into the ticket view – the plugin API doesn’t seem to expose any hooks here, but I’ll raise the issue with the trac developers and see what they think.

  Anyway, feedback on what CruiseControl users would like to see by way of features would be appreciated – as would anyone willing to test it. As I said, it is a spike right now – I’ll probably start reimplementing it tonight – but you’re welcome to play around with what I have right now (if you have the latest version of trac from subversion, installing the plugin should be a breeze).

The inclusion of the enclosure element in the RSS 2.0 specification opened the door for what Ben Hammersley called Podcasting. The enclosure element was originally introduced by Dave Winer to allow Christopher Lydon to associate mp3’s of his radio shows. Adam Curry and other’s software took enclosures and developed software such as iPodder to automatically download mp3’s (for more information on this see the increasingly excellent wikipedia).

Recently I was mentally bemoaning the lack of developers who provided RSS/Atom feeds that let me know when their software has been patched, or when new versions of their software is available. Then a thought occurred to me – if software such as iPodder can automatically download mp3s referenced in RSS enclosure elements, then why couldn’t a similar system automatically download software patches and new versions, and perhaps even instal them?

At it’s simplest you could use existing technology to download the patches, then notify the user that new patches are available. Taken to the logical extreme and using some application/os specific plugins such software could also enable you to install the patch/upgrade. Even better, information on the plugin required could be contained in the RSS/Atom feed itself in some way – you subscribe to the update feed in this new bit of software, the program then detects which plugin is needed to enable installing the plugins, and does the rest for you.

The simplest plugins would simply download and run the executable. Others might work with OS’s built in upgrade mechanisms, such as debian’s apt-get – others still could use language specific management techniques such as Ruby Gem’s. This would be useful for a single user, but imagine how useful this would be in a large organisation – rather than using often expensive centralised installation software, system admins could create their own RSS feeds of the needed patches and enable automatic download and patching for all company workstations.

It’s possible that some of the more advanced features such as identifying he needed plugins, downloading via BitTorrent or detailing OS specific updates (or perhaps even general update criteria such as “upgrade only if you have version 2.11”) that you might need to use an RSS extension, but even using simple RSS enclosures you could achieve a lot.

So the name? Well, it’s not simply mp3s any more. I originally thought “Patchcasting” which has a nice ring, but still seems limiting – “Softwarecasting” is too unwieldy, so I was very happy to come up with Bitcasting – which seems like a blanket term to cover the distribution of any binary format using an RSS feed to determine when and what to distribute. Annoyingly enough a company called “Digital Bitcasting Corporation” already exists…

The uses are varied, and the technology is there, but as you know if you’ve spent any time reading this blog (unlikely given the stats) then I very infrequently follow through with this stuff, so I’m pinging LazyWeb too.

Seems to be a UK English usage. A snagging list details the outstanding and remedial work as a construction scheme comes to an end. Sometime the final stage payment is conditional on rectifying the items on the list.

There are always things that we miss. The building industry has known this for a while – towards the end of a construction project, a snagging list is drawn up to detail all those little mistakes that have been made, or damage that has been done inadvertently.
Continue reading…

Some of you may of seen the recent Quicktime movie showing Quicksilver posting Backpack updates. There isn’t that much information out there explaining how to do it, so I thought I’d post a quick tutorial on getting it all to work.
<!-more->

1. Make sure you’re using the latest version of Quicksilver, with the Apple Mail and Backpack plugins installed
2. Make sure Mail.app is setup properly. You can check this simply by firing up the client and try sending some emails.
3. Next, you need to configure the email actions. In Quicksilver preferences, you need to enable the "Email Item... (Send Directly)" action, for the "Email Addresses", "Text" and "Files & Folders" types.
4. Check this works – fire up quicksilver, hit ”.” and type some text in. Then hit Tab, and select the "Email Item... (Send Directly)" action and hit tab again – finally press ”.” and type in the destination (or select an address form your address book). If that works out, you’re ready to try sending email to backpack.
5. Log in to Backpack to get your developer key. Go to your Account page, and towards the bottom, you’ll see an option to show your developer key.
6. In the Catalog preferences for Quicksilver, click the ”+” button to add a new catalog – select "Backpack Pages" from the drop down. This will be the catalog that will work out how to talk to our Backpack pages. Your newly added catalog will be under “Custom”. Select it, then click the “i” icon in the bottom right. Put your username and developer key in.

1. To try out your integration, bring up quicksilver and enter "note>> sometext". Hit tab and select "Email Item... (Send To)", tab again and bring up the backpack page you want to send the note to, hit enter and enjoy!

I’ve been writing a ‘toy’ Rails application by way of a learning excerise (read: attempting to de-hype Rails, in my own mind if nowhere else). Whilst investigating at the tool offerings (or lack thereof) I started looking at the mocking tools available. Coming from a perspective as a frequent JMock user I was hoping to find something similar.
<!-more->

RubyMock

Originally written way back in 2001 by Nat Pryce (who also wrote Java’s DynaMock and JMock tools) RubyMock was the first mocking tool for Ruby. It was written to integrate with RubyTest which has now been superceeded by TestUnit – now built in to the core Ruby distribution.

Test::Unit::Mock

Test::Unit::Mock (try saying that three times fast) is a reimplementation of RubyMock, only this time using the newer TestUnit. For someone used to the nice, readable JMock expectations, RubyMock is far from pretty. This example shows setting the expectation for a mock to return a value when the do_stuff method is called:
(C)

(C)<textarea name="code" class="ruby" cols="60" rows="10">
mock_object.setReturnValues( :do_stuff => [
“Mocked Return”
] )
</textarea>

Personally, I dont find it as readable as JMock:

mock_object.
  expects(once()).
  method("do_stuff").
  will(returnValue("Mocked Return"))

That seems about as sophisticated as the mocks get – you can specify call order (something I’ve never needed to do in JMock) but I couldn’t see any way to verify expected arguments made in method calls, apart from adding your own mocking methods.

FlexMock

FlexMock seems a little more recent than either of the above, and I prefer it’s wording if nothing else:

mock_object = FlexMock.new
mock_object.mock_handle(:do_stuff) {
  "Mocked Return"
}

The only way to assert arguments being passed to the mock is to place assertions within the block itself – compare this with JMock:

mock_object.expects(once()).
  method("do_stuff").
  with(eq(someParam)).
  will(returnValue("Mocked Return"))

A JMock port for Ruby?

Much of JMock is focused at making readable expectations – I certainly find them to be more self-explanatory than the Ruby equivilents shown above. There is a certain amount of extra language required for the expectations to work in Java which wouldn’t need to be done for Ruby – for example you could do away with the need to cast the mock’s proxy, so instead or:

MyObject object =
  new MyObject((Dependency)mockDependency.proxy());

You could have:

MyObject object = MyObject.new(mockDependency.proxy())

Even better, you could do away with the need for the proxy altogether due to the nature of Ruby’s typing:

MyObject object = MyObject.new(mockDependency)

Likewise I think there is scope to simplify the way you define expectations in JMock. Instead of:

Mock mockObject = new Mock(ClazzToMock.class);
mockObject.expects(once()).
  method("someOperation").
  with(eq(arg1), eq(arg2)).
  will(returnValue(someReturn));

Compared to:

mockObject = Mock.new(ClazzToMock)
mockObject.expects(:someOperation).
  with(arg1, arg2).
  willReturn(someReturn)

Implementing such a mocking tool would be simple – much of the work in JMock covers the creation and use of dynamic proxies, which are a breeze to implement in Ruby. Whilst writing my tool I’ve already created the bits that should make this possible, the question is whether or not I can be bothered to finish it off. In the meantime I’m going to take a look at the Python version of JMock, PMock for inspiration.

Just for a bit of fun, I thought I’d see how many of the people over on the Rails mailing list were actually getting to use it in their day jobs. Completely unscientific, and obviously a completely self-selecting sample group, but like I said it’s just a bit of fun.

The four questions I asked were, “are you using Ruby on Rails”:

1. As the primary development tool at your Day Job
2. As a small part of your Day Job
3. Not using Rails in your Day Job, but are using Ruby

1. For OS/outside work/hobby

   Of the 50 responses received in around a day an a half, here are the results (note: people could respond more than once – many people are doing it as both a job and a hobby as example):

2. As the primary development tool at your Day Job – 50%
3. As a small part of your Day Job – 22%
4. Not using Rails in your Day Job, but are using Ruby – 18%

1. For OS/outside work/hobby – 66%

   No analysis – this is deeply unscientific – but feel free to come up with unfounded claims as to how Rails is going to take over the universe or something – I’m sure the blogsphere will lap it up.

Rails, as you’ll no doubt be aware from the recent spate of blog-hype (sometimes so breathless in it’s praise that I fully expect some bloggers to keel over after choking on their own spleens) can be considered as a cross between AppFuse and NakedObjects, only for Ruby.

Like AppFuse Rails takes a series of technologies and with the help of some scripts creates a project for you in which most of the simple configuration and wiring is done for you. Like NakedObjects, Rails gives you a UI and persistence mechanism based on a domain model. Unlike NakedObjects Rails is highly flexible – you are free to change pretty much anything you want.

Initially the thing that makes you sit back and start to listen to at least some of the hype is the amount of work the helper scripts can do for you. Once you’ve created a DB table, you simply have to type:

ruby scriptgenerate model MyModel

To generate a persistable domain model and test stubs (I’ll talk more about the pattern used here later). Then you can generate the controller, with this simple command:

ruby scriptgenerate controller MyModel

Adding scaffold :recipe to the resulting controller dynamically enables all views required for CRUD operations for your Model. This can be shortened to:

ruby scriptgenerate scaffold MyModel

This does both of the above steps, and exposes all the scaffolding code inside your controller. For the most part, this code is there (in rails-speak) as scaffolding around your application. It’s there to get yourself started. As such you are encouraged (expected even) to edit virtually all the code generated for you – the obvious conclusion from which is that the generation steps have to be considered to be a one-shot deal. If you change the Rails version, you may now be required to edit much of your code by hand. This is by no means a fatal flaw – but when analysing the productivity gains of Ruby, the initial benefit of code generation should be seen as just that – an initial benefit. Rails will stand (or fall) based on Ruby itself – both its technologies, tools and workforce.

In Rails (well, ActiveRecord) you can support simple ordered collections fairly easily. Say I had a Post object, with multiple Comment objects, but I want to keep the Comment objects in order they were posted, where posted_on holds the posted date:

class Post "posted_on"

	
...

	
end

This has been a post on behalf of the just-letting-you-know-I’m-alive and the I’m-blogging-this-so-I-can-find-it-with-google-later parties.

That’s me that is

Normally a much longer list, but right now the things that annoy me most are:

• People who correct my punctuation. Like a 3 foot high Fox News presenter, it’s not big and it’s not clever. It’s not my fault english is so sodding inconsistent.
• People who correct my spelling while I’m half-way through writing the sodding word. Kiss my ass, smart boy.

• People who respond to stuff I write, but don’t let me know via email, or trackback, and provide no way of responding to their response because they don’t have comments, so I have to find out from other people (see? I’m pinging you with this post – just how hard is it?).

  This has been a public information broadcast from the angry kitten party.

In the world of Those Who Cut Hair, there are Barbers, and there are Stylists. Barbers tend to be cheaper, and will be fairly limited in what they do. When you turn up at a barbers you tell him exactly what you want (which he may or may not be able to do) – if you ask for something he can’t do, chances are you’ll getting a short-back and sides. Stylists are more expensive. When you go to a stylist, you can say things like “Well, I’m not quite sure” or “Something more – funky!” or “Whatever haircut David Beckham’s got this week”, and the stylist can hopefully use their skills to give you the haircut you need. What’s the difference? Apart from price, barbers are only capable of giving you want if you tell them exactly what you need. Stylists can work out what you need – and believe me it won’t always be what you’d expect.

So where am I going with this? Those of us who work for consultancies (or even freelance) have to decide whether or not we want to be the development equivalents of barbers or stylists. Do you want to be told what the problem is, even what the solution is, and go off and do it? Or do you want to spend the time working out what the problem really is, even if your clients don’t know. Being a software-stylist is harder – it’s more work, and some clients really don’t want to be told what the problem is (“I’m telling you, I want a mohawk!”), but you should end up with a better solution that is what they really need. The other good news? If your the software development equivalent of a stylist, you can charge more. At the same time, prospective clients need to make sure they aren’t hiring barbers in disguise…