Introducing: backlogged.com

Well, it's been a busy old time here at the new Aspect Towers on the Edgware Road and it's only going to get busier in the next few weeks - provided we get plenty of alpha users for our new offering, backlogged.com.

Backlogged is an agile project management offering with a very distinct difference: it's actually agile. We got sick and tired of trying to find a tool that properly followed the agile approach - all we could find were ugly beasts with ugly plugins that are as agile as a rhino doing the pole vault, or things so lightweight they're barely more use than a shared spreadsheet.

And, given that we're an agile company and absolutely brilliant (that's a direct quote) at design and development, we figured we'd just build one ourselves. And, plenty of coffee and cookies, a lot of post-its (we'd rather use them than date an ugly one), and a bunch of Magic Whiteboard strips later, we're on the verge of letting people get their hands on it.

At the moment, we're asking people to let us know if they want to be involved in the alpha but it's not going to be a closed shop - if you want to give it a whirl, we'd love you to. One we word of caution, though: it is an alpha at the moment and we're looking for plenty of feedback so there are likely to be a few changes, which may mean changes to the database and may mean bits and pieces get lost - although we'll provide plenty of warning if we're going to make such changes. Basically, just don't put all your desperately important stuff in there until we go properly live.

Rails sorting with nil

I just thought I'd add a quick blog post on something that came up recently while we were developing something in Ruby on Rails.

When you attempt to sort items in rails, any nils automatically come first - they're considered to have a lower "value" than anything that's not nil.

Now, on many occasions, you'll want to ensure that nils go at the end - as was the case with the thing we were working on - so there are a couple of options: one obvious, one much less so.

Sort by "property" in ascending order:

:order => 'property is nil ASC, property ASC'

The above two examples shift any nils to the end of the list in the first part of the sort as "property is nil" resolves as 0 for non-nils and 1 for nils. You can then order by that property as normal.

Alternatively, you could do the following to sort in ascending order:

:order => '-property DESC'

Notice that there is a minus sign in front of the property, which effectively reverses the order the items would be listed in. The minus sign has no effect on nils so when we then sort in descending order (notice that the ASC has become a DESC), we get the non-nil items back in the original order (we reverse the reverse) and the nils at the end as we would expect from a DESC.

Just thought I'd share that with you as it had us scratching our heads for a wee while.

VAT on mileage expenses

For the best part of a year now, I've been unsure about whether VAT should be added to mileage expenses to our clients and have received conflicting information from accountants, clients, websites, and forums. HMRC were of no use when I called them and asked for advice - they pointed me towards their website and refused to give me advice on a specific example.

Finally, an accountant from a forum (FreeAgent Central) has managed to get a definitive answer out of HMRC. He replied to my queries with their email response and I include it here for the benefit of anyone else confused by this. In short, VAT is always applicable on mileage as it is "not a service received by your client" and cannot therefore be treated as a disbursement.

Thank you for your email dated 17 August 2009, regarding the VAT treatment of mileage costs.

You have asked if VAT must be added to any mileage costs reclaimed from a client when it is itemised separately on the invoice.

Firstly, I would point out that the sub-paragraph you refer to in The VAT Guide, 25.1.3, gives examples of supplies that cannot be treated as disbursements, and concludes each example with a confirmation that VAT is due on the full value of the supply.

However, in respect of the recovery of costs from a client, these would always be taxable unless they were third party payments made by you, and therefore treated as disbursements. Mileage costs are something that you will have incurred and which you wish to recover. They are therefore always taxable as they are not a service received by your client.

My thanks to Stuart Jones for this.

Server-side validation: a follow up

From the response to my previous post of a few days ago on the subject of server-side validation, it seems some of you remain unconvinced as to its need and continue to hold the belief that the client is responsible for all data validation.

Primarily, the argument seems to be that it's not needed if you're writing both the client and server components - that you're happy to rely on your own ability as a front-end developer and not bother with server-side validation. In this post, I will attempt to demonstrate how even data with a high level of accuracy can benefit from server-side validation, and how you can do that validation in an entirely inobtrusive way.

Flex persistence patterns

It is rare you will find a Flex application that doesn't require data persistence of some sort, whether it be to server via remote objects or web services; or saving locally to an SQLite database as in the case of AIR.

Working on various projects throughout my Flex life, I've come across many different approaches to how this is done, especially in the context of Cairngorm. Exhibit A:

[as3]
// Create my user
var myUser : User = new User( "John", "Smith" );

// Dispatch a Cairngorm event to save it
new UserEvent( UserEvent.SAVE, myUser ).dispatch();
[/as3]

This is the simplest method but, should your event design change, or you want to pass in another argument, you have potentially a lot of code to change where that event may be dispatched. Also there is the added complication that this code could be just about anywhere.

Rails audit trail

I know I've just done another post but I wanted to also mention something to you I discovered yesterday for Ruby on Rails that is, frankly, excellent.

Many applications need to keep a history of things that have happened and those responsible for auditing purposes. In fact, this is very often a legal requirement. For anyone that's worked on an application where this is the case, you'll know all too well that every "Solution Architect" out there has their own favourite way of doing it, that it can be a headache to implement, and that it often arrives as a bit of an afterthought ("Ummm... shouldn't we be auditing this stuff?").

Server-side validation

I must admit, I had assumed that server-side validation was something everyone just did. I thought it was obvious that the server should validate whatever data it receives, rather than relying on client-side validation. It seems, however, that I was mistaken in that belief - some people remain convinced that validation of, for example, mandatory fields in a form should be done on the client... and only done on the client. What follows is a brief explanation of why all applications must do server-side validation.