And on we go to the next monthly meeting which is on January the 18th at 7pm. We’ll try the usual venue of The George Inn, 77 Borough High Street. SE1 1NH.

Please make sure that you’re subscribed the proper calendar. I think the update of MobileMe Calendar killed the old link. So, you can subscribe to the calendar using this link. I think the alarms are pushed as well, so don’t be surprised if you get a reminder 3 days before.

You can also keep up to date by following the NSCoder Night Category.

If it’s your first time, contact me about getting my mobile number so you can find us if it isn’t obvious where/who we are. Or, DM the Twitter account.

See you in a couple of weeks.

And this week Alex Blewitt (@alblue) will be talking about DVCS and Git. Yes, that’s right; someone else is going to be talking about Git.

So come along for the usual collection (array or set, your choice) of chat, food, drink and learning. Nourishment for body and mind. And me telling you how you should always work on a private branch and that commit messages should be written in the present tense.

Where: The George Inn, Borough High Street
When: 6:30 pm onwards

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

Tomorrow is the third Tuesday of the month, and that means another London Mac developer get together.

See you there.

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.

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.

“Why do you need the answer in eighths?” I asked.

“Because I’m trying to convert a recipe and my scales only go down to eighths of an ounce.”

“Why don’t you just use grams?”

“…”

This little episode reminded me of an article by Alex Papadimoulis where he used the analogy of being asked whether it was better to use a bottle or a shoe to pound a nail. Although there are situations where either could be used, the real answer is, of course, to use a hammer. Sometimes we are asked questions to which we can provide an answer; but perhaps we should first stop and ask the reason for the question before answering it.

Let’s take Stack Overflow as an example. The programmer’s question and answer site that is also a game. ‘Good’ behaviour, such as asking good questions, providing helpful answers, are rewarded by upvotes, ‘bad’ behaviour; lazy questions, incorrect answers, are discouraged by downvotes. It is becoming increasingly common to find a Stack Overflow link as the top hit when searching the web for answers to programming questions. But, if you follow a mailing list for your chosen speciality it isn’t hard to see the same question in both places and different approaches to answering them.

Stack Overflow’s recommended approach to help vampires is a pragmatic one. Essentially, you can either be aloof and use the tools of the site to discourage the behaviour; or you could just answer the question and get some points. On a mailing list like, say, CocoaDev, a weak question will get sharp answers (if any); but on Stack Overflow, somebody might just answer the question because they get something out of it.

This might be useful to somebody. I’m sure there are times where we all just need a quick answer to question without deeper knowledge. Get help with the ‘how’ to get something done, and pick up on the ‘why’ later. But read enough questions in public forums and you’ll soon recognise those who just want to know the ‘how’, and no amount of saying they need to learn the basics is going to help. Maybe back up and ask why they are asking so you can better answer their question.

To tie this back to fractions, have a look at this Republic of Math post about the difference between relational and instrumental understanding in mathematics. A particular example is how the invert and multiply method of fractional division is widely taught without actually developing an understanding of the operation itself. When I was 14 my elder brother taught me differentiation. Not by saying “subtract one from the exponent and multiply”, but rather by drawing a curve and working through calculating a tangent using deltas and differences tending to zero and how it led to the simpler method. I’ve long forgotten the hard way, but after that I was very good at calculus.

Perhaps this is something to think about next time you see somebody ask how to write an application without using Interface Builder.