It occurred to me a while ago while clearing out my wallet of annoying pieces of paper that, the vast majority of the time, receipts are largely unnecessary. Most of them you will never use, and either get binned or put into a filing system to never be seen again. The problem is, of course, you don’t know which ones you might need in the future. Will they already have that game you’re gifting? Will the new TV develop a fault? You just don’t know.

So, receipts: a necessary evil (and by “evil”, I clearly mean minor nuisance).

What can we do to improve receipts? First, if we must store them, then let’s make that more convenient i.e. let’s make the receipts digital. This could be relatively straightforward:

• Ask the customer for an email address and send it to that,
• If they pay by credit card, store their email address against it for later use (if you’re worried about security, hash the credit card details),
• If they have a store loyalty card, then use the email address tied to that,
• If they don’t have one or don’t want an email, fallback to paper-based methods.

Simple. As an extra convenience, it might be worthwhile trying to get credit card providers to store a minimal amount of secure data on credit cards. This is definitely possible (though unlikely) and would ease the first-time pain.

Additionally, if we’re doing this electronically, I’d also consider providing a machine-readable version of the receipt; a standard way of marking up sales information. If that were to happen, then you can start to build tooling. You can do all sorts of deep interesting tracking if you have your financial information available electronically. If you imagine the sort of thing that Wesabe do just now, then you can start to see where we could go from there.

Are there issues? Yes, absolutely. If you want to return something, you need to be able to get your receipt (not strictly true, but that’s how you do it easily). In the digital world, that would either mean a print-off or, I imagine, getting the ID from the receipt. That ID should be sufficient to prove that you own a product and bought it in the shop you were in as all the transaction details should be available. The shop would need to rescind the receipt based on the ID to prevent multiple people trying to use the same receipt but that wouldn’t be very hard.

Another issue is that smaller shops would have an obvious overhead to pay. Well, there are two outcomes here: they can not participate (keep things the way they are, which is absolutely fine), or get someone else to run most of the system as a managed service. There’s actually really very little of this that would be shop-specific so it would be easily built and sold on.

That’s another worthwhile point: it could start a nice little niche business. People supplying these systems and building tooling around it.

Now, technically, my understanding is that receipts are not strictly necessary under UK law at all, but are a de facto part of how sales tend to work. To that end, I think that making them digital would be reasonably beneficial. Just an idea.

In a discussion recently, I realised why image galleries on websites make me uneasy (by image galleries, I mean software like Coppermine, which is extremely polished). It’s not that I dislike the content, it’s often appropriate or useful. You often do need to see something, whether it’s a bunch of application screenshots or perhaps some pictures from a band’s latest tour. They have information to convey, and are worthwhile.

No, I finally realised that the issue I have with them is that they’re almost always completely hived off from the rest of the content. You have your all the interesting news on your site, you have the products you want to sell, you have your twitter account brought into the main site, but so often the image galleries are sat on their own. You’re either in the main site, or looking at the images, but never both.

Most websites are trying to tell a story of some sort. Bands are trying to communicate with fans, software houses are trying to showcase products, and bloggers are trying to put their own little view of the world forward (myself included). In order to tell a meaningful story, you have to realise that so much of the world and the way we perceive it is connected. You might have seen the latest tour news from some band you like, but you’re part of that story if you go see them, and the pictures of those shows are too.

By putting the galleries out on their own, they’re no longer in the same context as the rest of your story. They’re telling their own story. Sometimes that’s just fine, but more often than not they’d be better understood in a larger context.

It might just look like a bunch of gig pictures on their own, but have them tell the story of the particular gig they’re from, mix in your tweets from your fans, and any other media you can lay your hand on and you have a fair richer story. That’s much more compelling and interesting. You’ve gone from a bunch of discrete sources to a tapestry, something to build a legacy on.

Is it more work to tell a story than to put it into a gallery? Right now, probably, yeah. Is it worth it? Absolutely.

Since Java and the JVM are getting proper closure support, now is as good a time as any for me to dump some thoughts about functional programming onto the site. I’ve got a few posts in mind, but I imagine this will be a somewhat sporadic series. Anyway…

When I was first introduced to functional programming, as part of my degree course, I didn’t really understand it. Not that I didn’t do well at the course, it was one of my strongest modules that year, but I really didn’t understand the benefits and potential. It did seem unusually neat, producing fairly compact code (we were taught Haskell, unsurprisingly), but also fairly burdensome. Avoiding side-effects and assignment was just too foreign, and I didn’t have enough real-world experience to really get the point. So, for a few years, I just forgot about it and got on with programming in other languages (Java, C, PHP, JS, etc).

Skip forward a few years, and as a reasonably experienced coder, I often found myself frustrated at the languages I was using. I would always try to make my code as neat and compact as I could, trying to minimise any wasteful re-use. If two classes were vaguely similar, then I’d look to find the common elements and make the differences abstract. Joel Spolsky talked about this when covering Javascript.

That’s all well and good but without certain key language features you can only get so far. The very constructs that hold the language together (loops, ifs, locks etc) are often the part that are either impossible or very difficult to abstract. This revelation brought me back to functional programming.

I now realise that the core of functional programming is freeing yourself from the constraints of the language, using different higher-order functions to express yourself more clearly and succinctly. A necessary consequence of this is lack of side-effects, and that’s a GOOD thing.

Stick around, I’ll be covering a number of libraries and ideas that make life simpler for the functional programmer.

I try to avoid anything remotely political on this site, for many reasons, but I feel it worthwhile discussing some of the issues around Peter Mandelson’s Digital Economy Bill: one of the most wrong-headed political policies I’ve seen in the technology space.

In this country we, by and large, have a solid basis for our justice system: we are all innocent until we’re proven guilty. Suspicion of committing a crime is not good enough, it must be proven beyond a reasonable doubt. The upshot of this is generally positive. We can’t be accused of something and be punished for it, without proof that we actually did it. This is a fundamental right that allows us the liberty we enjoy.

Importantly, you also can’t be tried by the victim of a crime. If you are accused of stealing from someone, that person cannot serve on the jury, nor can anyone with an obvious bias. You have the right to a fair trial by a jury of your peers.

If we did not have these rights, then it would be all to easy for society to be manipulated by scaremongers and sociopaths, the idiotic and the greedy. One accusation, and you’d be finished. This is not a hypothetical. In our past, we tried people as being witches with no evidence, just an accusation. This has happened before.

Now, the media industry is in a difficult place. They’re making less money than they used to, and want to blame piracy for their failing business models, rather than adapt. That’s a whole deep dark hole of debate by itself, but is not what I want to talk about today.

No, I want to talk about the Digital Economy bill. As a way of stopping the perceived threat of piracy, the Digital Economy bill will give media companies the right to accuse people of copyright infringement and have them disconnected from the internet. Think about that for a second: the accuser gets to blame anyone they like and with no evidence of copyright infringement, have a punishment inflicted upon them.

No trial, no right to see the evidence against you and fight it. You’re presumed to be guilty. This is, of course, the opposite of how justice works at present. We’re basically putting justice into the hands of very large companies to protect their revenue in the way they see fit, whether they are right or wrong. We’re handing liberties over to commercial interests for no benefits.

To me, that is very wrong and I hope you join me in signing the petition to stop this very wrong policy.

For more views, Open Rights Group have a great site up called Three Strikes.

As someone working in technology, I’m faced with a fairly moving landscape. The number of new technologies and ideas that pass through my domain of interest make is so that the skills that I had yesterday might not be useful today, and are probably going to start looking silly tomorrow.

A necessary outcome of that is that technologists rely a great deal on different forms of training material, from full-on seminars to simple tutorials and APIs. It strikes me that a great amount of this material, perhaps the majority, is terrible; lacking the ability to convey meaningful lessons to the reader.

Ignoring the material which is underdeveloped or simply inaccurate, my experience tells me that the next worse kind of material is that which runs through a series of steps: do x, do y, do z, you’re done. While this is certainly better than no material at all, it doesn’t help build any understanding, and that’s the key to any successful tutorial. If you build understanding, you’re doing a much better job.

Rather than simply run through steps, take the time and patience to indicate the goals. What will each step achieve, how exactly does it achieve that goal, and what other outcomes are there in slightly different circumstances? Each step should be there to help build understanding of your domain (by which I mean the fundamental components and ideas underpinning your subject matter), and in doing so ensures that the reader will be able to reason about your domain for themselves much earlier.

An extraordinarily good example of this is something like the Spring Framework manual. Each section introduces concepts with worked examples, alternatives, and consequences. The outcome is that given a small amount of time working with Spring you can fairly well reason about a new class that you’ve never encountered.

Always build on the domain understanding, always underline core concepts and always teach underlying principles, rather than simply stating steps.