Let’s try and add something new to our NSCoder Nights — talks.
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.
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.
Here’s an old screencast which I never got around to uploading.
It makes sense to set up a single directory in Xcode where built products and intermediate files are kept. You can blitz all the files at once if you don’t need them, you don’t have to set up manual exclusions for your version control and you can set up the files to be excluded from Time Machine backups.
This was recorded with an earlier version of Xcode, but the steps still apply. Please excuse the sound quality.
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.
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.
Related Reading
If you liked this post, have a look at my 365Git site for more tips.
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.
