Probably the last NSCoder Night of the summer started outside in the courtyard. A group got together for food at Pizza Hut beforehand and a couple more went to the Bunch of Grapes a little later on. It pays to watch the Twitter feeds to see what pre-meeting arrangements are being made.

After the usual chat outside we moved in to the Old Bar for Richard’s talk on Test Driven Development (sorry I spoke over you, Richard) which went well and generated some interesting discussion. Richard has made his slides availables here.
Next month’s talk is going to be about Git and distributed version control (not by me) and we may also have another talk lined up for the following month. If you have an idea for a talk you would like to give, please get in touch with me.

Our evenings don’t usually follow the norm of people all sat down and coding. I suppose that’s because of the choice of venue, but who would turn up for an evening in Starbucks?

I’ve got a couple of volunteers lined up for the next couple of meetings, but I thought it would be a good idea to put some draft ground rules down.

For Presenters:

Keep talks short and focussed. 15-20 minutes should be enough time. Think of it as being an initiator of the discussion that might follow.

Forget about any audio-video support. We are in a pub, where there are other people around. A few slides on your laptop or iPad is the most you have to work with. If you do a slideshow I’ll happily host the slides or post a link back to where you have them.

Don’t be offended if not everyone listens to your presentation, or scuttle of during it. Some people are just not interested in the topic, or are having a more interesting discussion somewhere else. The talks are not the point of the evening, just something that happens during the evening.

Be prepared to expand upon and explain your ideas further if someone asks.

For Listeners:

Don’t feel you have to listen to the talk if you don’t want to, but please don’t have a conversation over it. If you start listening and decide to bail, do so in the least disruptive way possible.

Ask questions, make comments, ask for help with related code. The presentations are necessarily short, but that doesn’t mean you can’t keep talking about the topic.

If you feel you have something to talk about, let me know and I’ll add you to the list.

Upcoming Talks:

August – Richard Buckle on Test Driven Development
September – Alex Blewitt on Git/DVCS

If anyone has any amendments to propose for these rules or have subjects for talks, please let me know. See you on August 17th.

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.

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.

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.

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/.

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.

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.