
PostgreSQL is my database of choice. The main reason is that a standard distribution comes with just about everything one could ask for in a free RDBMS, and if what you want isn’t already installed, it’s often in the “contrib” directory. In particular, now that I’m doing a lot of iOS development, and location awareness is a big part of mobile apps, it’s useful to be able to work with coordinates. PostgreSQL does this using the cube data type and earthdistance functions, both in “contrib”.
MacPorts, however, doesn’t include much of the contents of “contrib” in a standard install, including both of these extensions. This makes it a lot harder to develop code using them unless I want to set up a development database on my production server, something I am not eager to do.
Thankfully, there is a solution: disable auto-clean, and after installing the postgresql83 (or 84, depending on the version you want), you can install the extra “contrib” extensions by hand.
These days, it’s not uncommon to be faced with the situation of having two or more Wi-Fi devices you might wish to use in a hotel room when the hotel does not provide free in-room Wi-Fi. The hotel doesn’t know that those devices are all yours and in one room, so using them means paying per device, which is crazy.
This explains how to easily set up Internet connection sharing in Mac OS X 10.6 so you can pay once, and piggyback the rest of your devices off that one laptop. These instructions assume that you have a wired Ethernet connection available in the room.
That’s it: you should now be able to use the Internet from your wireless device, via your laptop plugged into the Ethernet.
Early during development of a new iPhone OS application, I discovered that App Store submissions must use a strict format for the CFBundleVersion key in the Info.plist file. It can only be numbers and dots. This left me a little frustrated with how to version pre-1.0 releases to testers. I didn’t want to use an open-source style “0.9″ and yet it wasn’t 1.0. What I really wanted was “1.0 b1″ or similar.
I stumbled on Daniel Jalkut’s post about automatically stamping the Subversion revision into Info.plist and thought that might be a good way to go. I also created a new key in Info.plist, LYSApplicationDisplayVersion, that I use as a human-friendly version string, which is where I get my preferred “1.0 b1″ form. CFBundleVersion now takes the form of major.minor.revision, where major and minor are the important parts of the human-friendly version (“1.0″) and revision is the Subversion revision number that produced the binary.
I like this method because it solves one problem raised by commenters on Daniel’s post. Because the Subversion revision is the third component, it doesn’t matter than r3999 is a mature 1.2 point release and r4000 is a risky pre-2.0 alpha for testers. Those versions end up 1.2.3999 and 2.0.4000 and it’s clear that they are from two different branches of development. For iPhone Ad Hoc distribution, iTunes also parses the version properly and knows that 1.0.100 is newer than 1.0.95.
Here is the script to paste into your custom script build phase:
# Xcode auto-versioning script for Subversion # by Axel Andersson, modified by Daniel Jalkut to add # "--revision HEAD" to the svn info line, which allows # the latest revision to always be used. use strict; die "$0: Must be run from Xcode" unless $ENV{"BUILT_PRODUCTS_DIR"}; # Get the current subversion revision number and use it to set the CFBundleVersion value my $REV = `/usr/bin/svnversion -n ./`; my $INFO = "$ENV{BUILT_PRODUCTS_DIR}/$ENV{WRAPPER_NAME}/Info.plist"; my $version = $REV; # (Match the last group of digits and optional letter M/S/P): # ugly yet functional (barely) regex by Daniel Jalkut: #$version =~ s/([\d]*:)(\d+[M|S]*).*/$2/; # better yet still functional regex via Kevin "Regex Nerd" Ballard ($version =~ m/(\d+)([MSP]*)$/) && ($version = $1); die "$0: No Subversion revision found" unless $version; die "$0: Modified, switched or partial working copy, you sure about that?" if $2 && ($ENV{"BUILD_STYLE"} eq "Ad Hoc" || $ENV{"BUILD_STYLE"} eq "App Store"); open(FH, "plutil -convert xml1 \"$INFO\" -o - |") or die "$0: $INFO: $!"; my $info = join("", <FH>); close(FH); $info =~ s/([\t ]+<key>CFBundleVersion<\/key>\n[\t ]+<string>\d+\.\d+).*?(<\/string>)/$1.$version$2/; open(FH, "| plutil -convert binary1 - -o \"$INFO\"") or die "$0: $INFO: $!"; print FH $info; close(FH);
There are a couple of other changes to this script for Subversion 1.5 and later, and for iPhone OS targets.
The first is that the regular expression allows for a trailing P in the Subversion revision. This signals a working copy from a sparse checkout, which I never use and therefore may be a problem. I have the script fail if any letter is appended to the revision when the BUILD_STYLE is “Ad Hoc” or “App Store”, which are two new configurations, cloned from Release, that I use for Ad Hoc and App Store distribution, respectively. Especially for modified working copies: I never want to accidentally hand out a build made from a modified working copy. Should the day come that I really do, I can comment this line out, make the build, and uncomment it again.
The second is that iPhone projects convert Info.plist to the binary plist format in the application bundle. In order to extract the existing CFBundleVersion key, it must be converted back to XML. When writing the plist back out, it is again converted to binary. Both of these steps use plutil, which is part of the Developer Tools.
Bill Bumgarner posted a nice tutorial on using malloc to debug memory misuse in Cocoa. I’ve run across these before when reading the malloc(1) man page, but it’s nice to have a tutorial that shows how to use them in practice.
For as long as I can remember, I’ve been using a tool called SSHKeychain on Mac OS X to manage ssh-agent and my identities, to make logging into remote servers secure, yet password-free.
Lately, however, something has changed and SSHKeychain isn’t able to keep track of my keys. The result is that instead of rarely typing my passphrases, I’m doing it constantly. I think it started around the time I updated to 10.5.8.
Turns out that Leopard has much better support for ssh-agent built-in and SSHKeychain isn’t necessary. Dave Dribin’s blog lays it all out: ssh-agent on Mac OS X 10.5 and, for the security conscious, Securing ssh-agent on Mac OS X 10.5.
A couple of things to watch out for:
Contact us: info (at) lightyearsoftware.com | Press
Copyright © 2007-2010 Light Year Software, LLC. All rights reserved.