This is an appeal to anyone who may know a 21 year old Sarah (born April 6th, 1991) in Windsor, UK. Her camera and other precious items have been found and we want to get them back to her.

Sarah a celebrated her 21st birthday on friday 6th april. she got picked up by a taxi in windsor on sat morning. a bag containing a pink floral photo album celebrating her life upto her 21st birthday, camera, scarf and other things were left. please help me locate this young lady. precious photos, im sure she would want back

People are losing cameras all the time and thankfully there are plenty of nice people out there that find them and are happy to give them back. There are many more stories like these on the lost and found map over on stolencamerafinder.com.

Cheers, Matt

There are so many reports, you can barely see the map underneath!

Spoiler Alert - This will ruin the film if you haven’t seen it.

F

This film started great, a teacher tangled in red tape, falls into depression and alcohol etc etc. But then these supernatural hooded psychos spring into the film and start killing everyone. If that is all the film is then, well, let’s just say it’s not my kind of film.

However, I didn’t think that was what the story was about. I googled around to see if others had come to the same conclusion as me, but no-one had so I figured I’d post my interpretation here.

I thought at the end you were supposed to realise that the main protagonist, Robert, was the one who had killed everyone. There never were any crazed ASBO ninjas.

My reasons:

1. The hoodies have no motivation for their killing spree.
2. The start of the film is all about his crumbling mental state. His paranoia about unstoppable violent youths. He hits his daughter, he’s losing it.
3. People get killed just after he leaves (like the librarian).
4. When he was with the security guard and they see a hoody, I assume Robert was going mental, schizophrenic style. The guard says something like “leave us alone” which could have referred to him and the daughter, not him and Robert. The guard then locks the door against him. Robert isn’t killed at this point even though he’s looking through the door for ages and they’re uber-fast freaking ninjas.
5. At the end I assumed Robert thinks he’s stabbing a hoody, but actually went a bit nuts again and stabbed his daughter.
6. At the very end, and his daughter sees her mum’s car, she wants to get out and find her mum. Perhaps she meant that they should stop her seeing the bodies, or that she wanted her mum to take her to the hospital.

Obviously I’m probably completely wrong since no-one else has come to this conclusion and I’m rubbish at understanding films. Heck, when I saw the 6th sense I was practically in the cinema car park before I twigged what it was about. Anyway, I don’t really care. That’s what I think it was about and that helps make the film better for me!

Today I ran my first parkrun. If like me you’ve never heard of them:

parkrun organise free, weekly, 5km timed runs around the world. They are open to everyone, free, and are safe and easy to take part in.

Pretty simple really. You just register for free on the website for a personal barcode, print it out then turn up and race. You just register as a runner, not for individual races, it’s up to you which races you attend.

The parkrun in Bristol is held in Ashton Court, a pretty simple out-and-back course that takes you up a hill then back down it.

The races starts at 9am so I left the house a little late at 8:40 but thought I’d be ok. I underestimated how rubbish my bike is, how strong the wind was and how slow I am. It too me 22 minutes of flat-out cycling to get to the start line. Luckily the race started 5 minutes late so I was able to join in (heart still beating like mad!).

As usual, I started near the front over-filled with optimism. Half way up the climb my pace slows to a crawl and I realise I left all my optimism at the start line. I plod on.

At the half way point of the course you’re at the top of the park and turn back on yourself. Panoramic views of Bristol spread before you and you realise it’s all downhill from here. The optimism has caught me up and I smile. I probably look like a complete idiot when I run downhill, bouncing with huge lanky strides. I don’t care, it feels great, I love running downhill. The wind is also on my back and it just feels like flying. I start picking off the people that overtook me on the climb. Clap clap, my feet pound the path picking up dangerous speeds. This can’t be good for my bones. It doesn’t even feel like hard work, I can feel my heart rate dropping. Did I mention I love running downhill?

If you’re expecting me to say I won the thing, well, I was nowhere near. I guess I finished about 30th and I forgot to stop my watch so don’t really know what my time was (although it’ll be on the website later). That doesn’t matter though, it was a good, fun race. Well, I say it doesn’t matter but I’m far too competitive to leave it there. I wonder if I can get into the top 20 before the end of the month…

Want better photos?

As I’ve mentioned before, I get asked what camera to buy a lot. I mean loads, it’s silly. Generally, I get asked by people who are fed up with the blurry, grainy photos they are currently taking and think a new camera will solve everything. If this sounds like you, then go read my previous post about whether or not an SLR is for you.

Done? Still interested? Excellent…

For entry-level, buy new

In that post I suggested that buying second hand may be a good way to go. Well, I just had a rummage around eBay, and although I would recommend it for buying more expensive second hand pro stuff, the entry level stuff seems to hold its price a lot better. So much so that most of what I saw is now better specced brand new for the same money. When buying entry-level equipment, I suggest you buy new. Sleep easy knowing that you’ll probably be able to sell it for a decent price should you choose to upgrade in a few years.

Manufacturer lock-in

The first choice to make is between Canon and Nikon (some argue Sony but I wouldn’t). Lenses and flashes are generally not interchangeable between brands, so whichever one you pick, you’re kinda stuck with forever. (I’m on team Canon, but Nikon also make awesome stuff). Don’t stress about it too much, it doesn’t matter, flip a coin.

My favourite

After looking around, my recommendation is the Canon 1100D. It is a cracking little camera. Packing great bang for buck, it also shoots HD video. It’s just dropped in price on Amazon for some reason, so I think it’s an absolute bargain.

£352 – Camera body + kit lens (18-55mm)
The kit lens is a great all-rounder and worth a good £100 on it’s own.

Extra lens

If you’re feeling flush, the first lens you should buy is a no-brainer (in my humble opinion).

£81 – 50mm lens. The “nifty-fifty”

This lens is amazing and dirt cheap. In my short experience, you normally have to spend £300 before you can get a lens that is worth having. This one bucks that trend by producing the best photos you’ve ever taken.
Warning: It has no zoom at all. None. Nada. Zip. If you want to zoom in or out you have to walk. It sounds pretty crazy but it’s worth it for the picture quality. It’s f1.8 which means it practically sees in the dark and takes prints that look like they belong in a magazine. Bear in mind this lens is perfect for taking portraits, baby photos etc. but no good for anything wider like landscapes. I find landscapes boring anyway. Being a “fast” lens means you’ll be able to take sharper images (same bright image in faster shutter time) which is handy for fast moving kids.

Film Memory

You’ll need a memory card, I always choose memory cards in this order:
Brand – for reliability
Speed – don’t buy a slow one
Size – your budget will decide this

There’s no point putting a link for this, prices change by the minute, just have a shop around. Perhaps you already have one lying around in an old camera/phone/wii…

Good luck

Even though this equipment is described as “entry-level” don’t let that put you off. Seriously, you’ll take photos so good you’ll grin from ear to ear. You’ll show your friends and they’ll compliment you on what a great photographer you are. Six months later you’ll look back at those photos with a harsh and critical eye and be surprised at how amateur they were. Congratulations, you’re on your slippery way to an expensive but rewarding hobby.

If you take this advice, be sure to post a link to your flickr / Google+ photos page in the comments below.

Disclaimer: I’m no javascript expert so I may be am almost certainly talking a load of rubbish here.

I was just looking for a unit testing framework for some javascript I’m writing (rather the the home-rolled framework I’ve out-grown) and came across QUnit. I’ve not tried any others so feel free to suggest alternatives. So far, it’s great and does everything I want and took me almost no time to learn. Easy.

The one thing that bugs me though is that they’ve swapped “expected” and “actual” parameter arguments around for the equality test. Technically it’s not that important since it won’t affect the result of the test, but in practice I think it’s very important. Your tests form part of your documentation of how the code should behave. If you get them the wrong way around and a test fails with “expected 10 but got 20″ the developer may well go off and try to make the code return 10. *shudder*.

Java method signature in JUnit:

1

public static void assertEquals(Object expected, Object actual)

public static void assertEquals(Object expected, Object actual)

The class offers overloaded implementations with primitives or with message etc. There are also ways of writing your tests in a type-safe fashion to prevent this whole problem in Java, but in my experience, this is more common. Another post maybe…

Javascript function signature in QUnit:

1

equal( actual, expected, [message] )

equal( actual, expected, [message] )

I can only assume they reversed the order of the arguments because of the way that javascript allows optional arguments.

I flip between writing Java and JavaScript quite a lot which would be a disaster waiting to happen so I’ve just wrapped it in my own function:

1
2
3

function assertEquals(expected, actual, message) {
    equal(actual, expected, message);
}

function assertEquals(expected, actual, message) {
    equal(actual, expected, message);
}

This all feels wrong and stupid. What do you think?

If you’re a materialistic idiot like me, you’ll be interested in how you can get your hands on a disgustingly extravagant smartphone while parting with the least amount of cash possible.

The best deal I found for the Galaxy S2 (by far) has been through Tesco:

• Free handset
• T-Mobile network
• 300 mins/300 texts
• 24 month contract
• Free delivery
• 500MB Data Booster + Unlimited Internet
• £20 of free apps available (through some T&Cs)
• £20.42 per month

Current T-Mobile customers:

Alternatives

Conclusion

I recently wrote an article about singletons in java. The only thing I wanted to cover was that if you really want a singleton, I recommend you use the enum pattern. This post was motivated after more interesting comments were raised about testability when you see the “static” keyword.

When you type “static” a little alarm bell should ring in your head to warn you that there could be trouble ahead. As Dan correctly pointed out, a reference to the static member INSTANCE will tightly couple the caller to Elvis. This is not good if testing with Elvis will cause you problems. For example, if Elvis is slow, or accesses a database or something like that which would be better tested with a mock implementation.

However, sometimes the static keyword makes sense because it is an implementation detail that you are not concerned with. By you I mean a client of the code. Why muddy an API so that you can pass around objects that will never change. To illustrate my point, I wrote a very simple bit of code that hopefully isn’t too contrived.

Imagine you have to write a computer system for a Blackpool nightclub called “Elvis Live!”. This club has a different Elvis impersonator on every night. The system has to manage the bookings of the different Elvis impersonators and print the posters which list which impersonators are performing each night.

In my very simple implementation I wrote a class to represent the club:
ElvisClub.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

package uk.co.mattburns.elvis;
import java.util.Map;
import org.joda.time.LocalDate;
import com.google.common.collect.Maps;
 
public class ElvisClub {
 
    private final Map<LocalDate, ElvisImpersonator> bookings = Maps
            .newTreeMap();
 
    public boolean bookImpersonator(LocalDate date,
            ElvisImpersonator impersonator) {
        if (bookings.containsKey(date)) {
            return false;
        } else {
            bookings.put(date, impersonator);
            return true;
        }
    }
 
    public ElvisImpersonator getImpersonatorOnDate(LocalDate date) {
        return bookings.get(date);
    }
 
    public String getPosterTitle() {
        return "Keeping The King Alive since " + Elvis.INSTANCE.died();
    }
 
    public String getPosterBody() {
        StringBuilder stringBuilder = new StringBuilder();
        for (LocalDate date : bookings.keySet()) {
            ElvisImpersonator act = bookings.get(date);
            stringBuilder.append(date.toString() + " : See " + act.name());
            stringBuilder.append(" who was born " + act.yearsBornAfterElvis()
                    + " years after Elvis");
        }
        return stringBuilder.toString();
    }
}

package uk.co.mattburns.elvis;
import java.util.Map;
import org.joda.time.LocalDate;
import com.google.common.collect.Maps;

public class ElvisClub {

    private final Map<LocalDate, ElvisImpersonator> bookings = Maps
            .newTreeMap();

    public boolean bookImpersonator(LocalDate date,
            ElvisImpersonator impersonator) {
        if (bookings.containsKey(date)) {
            return false;
        } else {
            bookings.put(date, impersonator);
            return true;
        }
    }

    public ElvisImpersonator getImpersonatorOnDate(LocalDate date) {
        return bookings.get(date);
    }

    public String getPosterTitle() {
        return "Keeping The King Alive since " + Elvis.INSTANCE.died();
    }

    public String getPosterBody() {
        StringBuilder stringBuilder = new StringBuilder();
        for (LocalDate date : bookings.keySet()) {
            ElvisImpersonator act = bookings.get(date);
            stringBuilder.append(date.toString() + " : See " + act.name());
            stringBuilder.append(" who was born " + act.yearsBornAfterElvis()
                    + " years after Elvis");
        }
        return stringBuilder.toString();
    }
}

A simple pojo to represent a performer at the club:
ElvisImpersonator.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

package uk.co.mattburns.elvis;
import org.joda.time.LocalDate;
 
public class ElvisImpersonator {
 
    private final String name;
    private final LocalDate birthdate;
 
    public ElvisImpersonator(String name, LocalDate birthdate) {
        this.name = name;
        this.birthdate = birthdate;
    }
 
    public String name() {
        return name;
    }
 
    public LocalDate birthdate() {
        return birthdate;
    }
 
    public int yearsBornAfterElvis() {
        return birthdate().getYear() - Elvis.INSTANCE.born().getYear();
    }
}

package uk.co.mattburns.elvis;
import org.joda.time.LocalDate;

public class ElvisImpersonator {

    private final String name;
    private final LocalDate birthdate;

    public ElvisImpersonator(String name, LocalDate birthdate) {
        this.name = name;
        this.birthdate = birthdate;
    }

    public String name() {
        return name;
    }

    public LocalDate birthdate() {
        return birthdate;
    }

    public int yearsBornAfterElvis() {
        return birthdate().getYear() - Elvis.INSTANCE.born().getYear();
    }
}

Crucially, both of these classes have a dependency on Elvis. I decided to make Elvis a singleton:
Elvis.java

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

package uk.co.mattburns.elvis;
import org.joda.time.LocalDate;
 
public enum Elvis {
    INSTANCE;
    private final LocalDate born = new LocalDate(1935, 1, 8);
    private final LocalDate died = new LocalDate(1977, 8, 16);
 
    public LocalDate born() {
        return born;
    }
 
    public LocalDate died() {
        return died;
    }
}

package uk.co.mattburns.elvis;
import org.joda.time.LocalDate;

public enum Elvis {
    INSTANCE;
    private final LocalDate born = new LocalDate(1935, 1, 8);
    private final LocalDate died = new LocalDate(1977, 8, 16);

    public LocalDate born() {
        return born;
    }

    public LocalDate died() {
        return died;
    }
}

You can browse all the source code here. Or better still, checkout the code and simply import the project into eclipse:

I already know what you’re thinking:

Elvis.java should be an interface: Celebrity.java. Then I could have a concrete Elvis to pass around which implements Celebrity.

ElvisImpersonator.java should be an interface: Impersonator.java. Then I could write a CelebrityImpersonator.java which would take a Celebrity on construction.

That is one way of solving it, and it’s not a bad way. I agree that you should expect change, embrace it, marry it, have its babies, but don’t start writing code for it before it’s happened. One day the club may have a Marilyn Monroe night and in that case you anticipated change beautifully luckily. What if it changes into a comedy club? How about a restaurant?

What’s really important is writing code that’s easy for programmers to read, and therefore, easy for programmers to change.

Here is a snippet from some of my test code which gives you an idea of what I mean:

1
2
3
4
5

ElvisClub theClub = new ElvisClub();
LocalDate today = new LocalDate();
LocalDate brianBorn = new LocalDate(1970, 1, 1);
ElvisImpersonator brian = new ElvisImpersonator("Brian", brianBorn);
theClub.bookImpersonator(today, brian);

ElvisClub theClub = new ElvisClub();
LocalDate today = new LocalDate();
LocalDate brianBorn = new LocalDate(1970, 1, 1);
ElvisImpersonator brian = new ElvisImpersonator("Brian", brianBorn);
theClub.bookImpersonator(today, brian);

A similar snippet, without using the Elvis singleton would look something like this:

1
2
3
4
5
6
7
8

LocalDate brianBorn = new LocalDate(1970, 1, 1);
LocalDate elvisBorn = new LocalDate(1935, 1, 8);
LocalDate elvisDied = new LocalDate(1977, 8, 16);
 
Celebrity realElvis = new CelebrityImpl("Elvis", elvisBorn, elvisDied);
Impersonator brian = new CelebrityImpersonator("Brian", realElvis, brianBorn);
Club theClub = new Club(realElvis);
theClub.bookImpersonator(today, brian);

LocalDate brianBorn = new LocalDate(1970, 1, 1);
LocalDate elvisBorn = new LocalDate(1935, 1, 8);
LocalDate elvisDied = new LocalDate(1977, 8, 16);

Celebrity realElvis = new CelebrityImpl("Elvis", elvisBorn, elvisDied);
Impersonator brian = new CelebrityImpersonator("Brian", realElvis, brianBorn);
Club theClub = new Club(realElvis);
theClub.bookImpersonator(today, brian);

There’s not a massive difference but I still think the constructors are a bit “noisy”. In a real-world application, you would probably expect references to a more complex set of collaborating objects.

I haven’t sacrificed any testibility of my code. If anything, I’ve reduced the amount of code I need to test. My way, there can only be Elvis and so I only need to test that the club handles things to do with Elvis. If I wrote a more generic version I would have to test that it handles Celebrities that are still alive, that they were born before they died, and so on.

I think I’m right but I’ve changed software design views pretty frequently over the last 10 years. If you think I’m wrong, I challenge you to convince me why…

I had the following html in my form:

1
2
3
4

<label for="email-input">Email</label>
<input id="email-input"
       type="text"
       title="Don't worry, your email will not be displayed on the website or given to anyone else. We hate spam too." />

<label for="email-input">Email</label>
<input id="email-input"
       type="text"
       title="Don't worry, your email will not be displayed on the website or given to anyone else. We hate spam too." />

Nothing complicated there I hope.
I had the help text set in the title attribute of the input which I styled with the lovely qTip to make it look nice. I validated my entry using the jQuery validation plugin which also works well. The problem is that if an attempt is made to submit the form before any attempt at editing the value or showing the tooltip, the error message would show the value of the tooltip (“Don’t worry…“) instead of the validation error message (“This field is required“).

It’s taken me a while to find the cause, but the fix is easy. When invoking the validator, throw in the option to ignore title attributes.

1
2
3

$("#your-form").validate({
ignoreTitle: true
})

$("#your-form").validate({
ignoreTitle: true
})

Do you still not have the offline option for Google Docs?

If you’re a Google Apps user, then your apps administrator has to enable it first:

1. Log in to the Google Apps control panel at https://www.google.com/a/your_domain.com (replace your_domain.comwith your actual domain name).
2. From the menu bar at the top of the page, click Settings.
3. In the left menu, click Docs.
4. Select the Allow users to enable offline docs check box.
5. Click Save changes.

Then your users can choose to set it up in the same way normal gmailers can with the docs cog in the corner:

Hope this helps you out.

Matt

Singletons get a pretty bad press. Often described as an “anti-pattern”. I think it’s a little unfair since I find them pretty useful in several situations. However, the reason they can be bad is important to understand:

Making a class a singleton can make it difficult to test its clients, as it’s impossible to substitute a mock implementation for a singleton unless it implements an interface that serves as its type.

That quote, and most of what I am about to write are completely stolen from Josh Bloch’s excellent book, Effective Java (highly recommended in paperback or kindle editions). Those are affiliate links, but I still recommend you buy it no matter where you get it from.

Anyway, it raises an important point about testability, but one that I think doesn’t matter. The way I see it, if you’re writing a singleton that represents something you want to swap with a mock, such as a database connection or network resource etc then your design will change as your tests evolve. You practice TDD right? You’ll soon realise that a singleton doesn’t make sense or you need an interface of some kind. This post is about how to write a good singleton.

In the bad old days before java 1.5 there were 2 common ways to implement a singleton. A public final field:

1

public static final Elvis INSTANCE = new Elvis();

public static final Elvis INSTANCE = new Elvis();

or a static factory:

1
2
3
4

private static final Elvis INSTANCE = new Elvis();
public static Elvis getInstance() {
    return INSTANCE;
}

private static final Elvis INSTANCE = new Elvis();
public static Elvis getInstance() {
    return INSTANCE;
}

The static factory version is slightly better in that the you have a bit more flexibility to change your implementation details at a later date. In my two examples there is no performance benefit of either technique in modern JVMs. This is all well and good. There is only one Elvis in the world. There is the possibility a privileged client can invoke the private constructor reflectively but I’m not going to dwell on that.

Bloch raises another problem:

To make a singleton class that is implemented using either of the previous approaches serializable, it is not sufficient merely to add implements Serializable to its declaration. To maintain the singleton guarantee, you have to declare all instance fields transient and provide a readResolve method. Otherwise, each time a serialized instance is deserialized, a new instance will be created, leading, in the case of our example, to spurious Elvis sightings.

Oo-er, this sounds messy. You implied in java 1.5 there’s a better way, please, what is it, I’m desperate!

1
2
3
4
5

// Enum singleton - the preferred approach
public <strong>enum</strong> Elvis {
    INSTANCE;
    public void leaveTheBuilding() { ... }
}

// Enum singleton - the preferred approach
public <strong>enum</strong> Elvis {
    INSTANCE;
    public void leaveTheBuilding() { ... }
}

TADA!

This approach is functionally equivalent to the public field approach, except that it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiation, even in the face of sophisticated serialization or reflection attacks. While this approach has yet to be widely adopted, a single-element enum type is the best way to implement a singleton.

Have a little think about it, let it sink in, then run off and replace any singletons in any projects you can get your hands on.