Last night’s NSCoder Night London was the smallest gathering yet. Not surprising considering that most regulars had been to NSConference Mini the previous Friday. It was also at a new place – The George Inn on Borough High Street because the Bunch of Grapes was showing football.

After spending the evening in the Old Bar which was mostly empty we thought we’d try and have the next meeting there as well. Far more space and quiet enough to hear everybody. This could have been because people had gone elsewhere to watch the football or were sitting on the benches outside to enjoy the clement weather. The downside was that the food wasn’t as good.

So, for next month, we’ll try and have the meeting at the George Inn and see how it copes with a larger group of people, and for those who turn up early they can go to the Bunch of Grapes for food. There is no point in trying to arrange dinner afterwards because people have got trains to catch.

The usual venue will be showing world cup football on our usual night so rather than put up with the a crowded upstairs room and droning vuvuzelas it seems a better idea to shift the meeting from one week. The suggestion is The George Inn on Borough High street. It’s just a couple of minutes further on from London Bridge station.

View Larger Map

The other idea I had was to gather on the embankment outside the London Assembly building. But the weather reports say it might be windy.

This is just a temporary location for a week.

Today is the third Tuesday of the month, so it’s time for the London NSCoder Night.

The meeting is at the usual place at the usual time. There is a table booked upstairs from 7pm. Send me an email or a DM on twitter if you need my phone number or any other details.

As it’s such a nice day, I might turn up early. See you later.

Pieter Omvlee of Bohemian Coding has been inspired to post a snippet of Objective-C/Cocoa code every day for a year.

It’s a great idea and starts with a useful category on NSArray. Go and see what you can learn over at http://365cocoa.tumblr.com/.

Sorry for the late notice but there is an NSCoder Night London on Tuesday, January 19th at 7pm ish. at the Bunch of Grapes in Borough. Google Maps isn’t accurate, so use this map to find it. I’ve booked a table upstairs so we won’t have to hang around waiting to find a place to sit.

WiFi can be spotty in the pub, so if you want to be sure to find us drop me a message and I’ll let you have my mobile number. There is food available until 9pm if you’re likely to be hungry. Unfortunately, there is a minimum age of 21.

As usual, you don’t have to bring a laptop and code; you can just come and be social.

Finally, at one of last year’s meetings, mention was made of having a Cocoa hackday along the lines of CocoaDevHouse. If you have any ideas for this or have experience in setting up these kinds of events I’d love to talk to you about taking this further.

See you tomorrow.

We all know what we should be doing when writing code. Each methodology you choose to use has it’s own best practices, whether it’s working from full specifications, writing unit tests first, programming in pairs, yadda, yadda. But, as developers, we’re only human, and we’re lazy. We have tools to make things easy for us. Here are a few tips that you can use to help when you’re not as rigorous in your coding as you should be.

Use a static analyser.

You can use the Clang Static Analyser in Xcode by setting a build option. This will find a whole host of errors in your code, even down to unconventionally named functions.

Now you can just code away and have the compiler pick up your mistakes when you run ‘Build and Analyze’ (Shift ⌘ A).

Find your mistakes quickly

Any real application you develop will have a large number of resources that need to be copied to your application bundle. The default projects that Xcode create for you will copy these files first before compiling.

But, the lazy Xcoder knows that there are probably errors in the code that need to get flagged by the compiler, so this copying is a waste of time. Reorder the build steps by dragging so that the compilation is done first.

Your builds will now break early (and often!).

Don’t fear the version controller

I’m going to stick my neck out and say that if you’re not using version control you’re an idiot. The lazy Xcoder uses a powerful system that lets him or her branch easily, make lots of little changes, and lots of mistakes (that can be backed out). These changes can then be bundled into larger commits to be merged into the main branch so that your co-workers don’t see what an idiot you’ve been.

One such version control system is git. The lazy Xcoder writes a bit of code, checks it in out of habit and then compiles. The compiler picks up the mistakes, and he or she fixes them. Rather than make a new commit, and retype the commit message, just call:

git commit --amend -a -C HEAD

This will bring up the previous commit message in the editor, which you can amend if you wish. This new commit will replace the previous one. The -a option means you don’t even need to do a git add and the -C HEAD option means it will use the commit message from the last commit.

Of course, if you’re a rockstar programmer, you don’t make mistakes at this level. But I’m not, and I prefer to work with human nature rather than against it.