You may have occasion to rename an Xcode project.

You can find step-by-step instructions and scripts with a little bit of Googling. But there is another way. If you’re running Xcode 3.2 on Snow Leopard there is a menu item you can use instead. Have a look at the Project > Rename… menu item instead.

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

Almost every git user knows about adding a .gitignore file to their repository to control the visibility of files and folders. This per project configuration will apply to all repositories of the same code base. But it’s not the only way. I’m going to tell you how to get git to ignore files on a per computer and per repository basis. These could be better choices in some circumstances.

There are three types of exclude files; from highest to lowest order of precedence they are:

Per Project: .gitignore file in the repository

This is the usual way of adding an ignore file. Call it .gitignore and save it to the root of your project to apply to all the files (you can add different .gitignore files in subdirectories where they have lesser scope). It is a part of the repository, so it will need to be git-added and committed for each change. This is useful for repositories that are passed around with others who may not have a per computer exclude file, or when there are project specific files that need to be taken into account. Even easier if you have per computer file, you can copy it straight in to your project with a simple cp ~/.gitignore .gitignore and edit to handle your specific requirements.

Per Repository: in .git/info/excludes

You can exclude files on a per repository basis by editing the .git/info/excludes file in your repository. (Why it takes it from this location rather than .git/config I don’t know: add it to the list of git annoyances). These exclusions (or inclusions, you can override the higher level exclusions by prepending ! to lines that you want to include) are not shared with the working directory, so they only apply to that particular repository. This is useful when you have particular requirements because of your workflow or machine setup.

Per Computer: through ~/.gitconfig settings

There should already be a .gitconfig file in your home directory. This is where the global setting for your git installation are stored; such as the user’s name and email address. Within this you can set a path to an excludes file that will apply to all git repositories on the computer in the same way as the name and email defined in this file apply to all repositories.

For example: Most of what I do is in Xcode so I have the following ~/.gitignore file

And in my .gitconfig file under the [core] section I have added the path to this file for the excludesfile key. (If you’re sharp eyed, you’ll notice that I don’t have an exclusion for /build. That’s because I don’t keep my products in my project directory, but that’s for a different post).

Now, I have a standard set of ignores that apply to all my git repositories on this machine without me having to add a specific .gitignore file to each one. This is probably most useful if you create a lot of repositories for yourself, but I recommend it to everyone. It’s lowest on the precedence scale and provides a neat catch-all.

Summary

Most of the time the first solution is quite adequate, having exclusions with a repository that is likely to have a public face is probably the most effective way of managing file visibility. But, as with most of git, there are ways of handling edge cases. You just need to know that they are there.

REFERENCE: the gitignore man page.

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.

On New Year’s eve, Dámasa asked me to calculate some fraction of a fraction and provide the answer as a fraction in eighths. The post had just arrived so I flipped over an envelope and started working it out.

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

The London chapter of NSCoder night closed the year in style. More developers than ever attended travelling in to London from as far as Brighton, Cambridge, Reading and Colchester. A very crowded and noisy pub meant that it was more of a social occasion with laptops being brought out only now and again. The picture was taken early on so it doesn’t look that croweded, but we ended up taking over the whole corner. The numbers were also swelled by combining it with the London CocoaHeads group this month.

Thank you to everyone for coming out and making these monthly gatherings a success. We’ll start again in January, just as the wind up to NSConference starts. Keep an eye on the feed and the calendar for up to date information.

Seasons greetings to you all!

For those who haven’t noticed, the next meeting is on Tuesday, December 15, 2009 at 7pm ish. at the Bunch of Grapes pub in Borough. We’re usually upstairs and are easy to spot. If you still want to be sure, drop me a line and I’ll send you my mobile number. WiFi can be spotty at the pub so calling me if you’re lost is probably better than resorting to the great communication medium of our time that is twitter

There may be some books brought along so people can look through them if they are considering buying them.: Coders At Work, Cocoa Design Patterns, Core Data, Xcode3 book, Head First Design Patterns, Head First Javascript. Please let me know if your interested in any of these; I don’t mind bringing them along, but not just for the sake of it. Particularly the Head First books, which have a unique approach which looks strange to a lot of people, so they are worth a look.

The Hemingway wordpress theme used to be quite popular. I like Hemingway, and I also like Heinlein, so it seemed a good name for the theme of this rebranded site. I’ve brought a few of the posts over from the old place Stompy.org, mostly to do with NSCoder Night in London.

There is more about this you can read in the about page. I also hold my hand up to stealing some of the designs I used form Nik Fletcher and Alex Payne I’ve also got my eyes on some other sites that I want to grab inspiration from. I make no claim to being a web developer, so feel free to send constructive criticism. I haven’t finished with this yet.

They say that good artists borrow, and great artists steal. But real artists ship.