I decided to dip my toe into paid advertising, and Facebook seemed the natural place to start. The way I figure it: people who spend time on Facebook, and more to the point, people who look at, and especially click on, Facebook ads are people who are looking to waste time online. That’s my target audience for Web Roulette: people looking to waste time online. Facebook makes it easy and fairly affordable to experiment with ads, offering both a CPM (impression-based) and CPC (click-based) model. Knowing that the proportion of Facebook users who also have iOS devices is probably well less than half, I opted for the CPC model.

Facebook lets you target your ad in some nice ways and lets you set a bid price for each click and a daily maximum. I won’t go into all the details, but it is pretty nice for someone getting started with advertising.

This first experience with it was, to say the least, disappointing. I started the campaign on Monday, August 23 and set a daily maximum of $20. The first day, Facebook served 189,795 impressions, garnering 31 clicks, for a click-through rate of 0.016%. The second day, 160,000 impressions, 32 clicks: 0.02%. The third day, 68,478 impressions, 3 clicks: 0.004%. The campaign ran for a week, but Facebook served essentially no ads the last four days, resulting in no clicks. This is hardly surprising, as my ads performed horribly.

I created additional, more focused ads within the campaign. The first ad targeted anyone in the United States, and ended with 204,479 impressions, 31 clicks (0.015% CTR). A second ad created later that day targeted people 18-35 in the United States (219,146 impressions, 35 clicks, 0.015%). A day or so later, I created ads targeting people who had “liked” various iPhone keywords, and another targeting people who had “liked” StumbleUpon, which is a web site similar to what Web Roulette does. These last two ads were shown so few times (3663 and 1755 impressions, respectively) that I don’t think I can draw any conclusions regarding their effectiveness.

Maybe my ads weren’t written very well or I didn’t bid enough, but given these results, I’m not eager to run another campaign. Worst of all, I sent the clicks through LinkShare, and I know that of the 66 clicks I received, not one resulted in a sale. For a 99¢ app. This is a brutal market.

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.

1. Edit /opt/local/etc/macports/macports.conf and set portautoclean to no.
2. Install PostgreSQL (sudo port install postgresql83) or, if you’ve already installed it, re-install it (sudo port upgrade --force postgresql83).
3. Change into MacPorts working directory: cd `port work postgresql83`/postgresql-8.3.11/contrib. Your specific version will differ from mine if you’re reading this more than a few months after I wrote it.
4. For each extension you want installed, cd into the directory, make all, then sudo make install. This compiles C code, if any, into a shared library, then copies the library and supporting SQL files (to create types, functions, etc., and also to drop them) to /opt/local/share/postgresql83/contrib.
5. Change into /opt/local/share/postgresql83/contrib and run the SQL files associated with the extensions you want. This probably needs to be done as the PostgreSQL super-user. For example, psql -U postgres dbname <cube.sql.
6. Enable auto-clean again by editing /opt/local/etc/macports/macports.conf and setting portautoclean back to yes.
7. Clean the postgresql83 port: sudo port clean postgresql83.

One interesting statistic from the first couple weeks of sales is that iPad users are the large majority of daily users. It’s hard (impossible?) to say if this is because there is less competition in the iPad part of the App Store or if people prefer to use a web-centric app like Web Roulette on an iPad.

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.

1. Plug in your laptop to the Ethernet, pay and get it working.
2. Go to System Preferences -> Network. Take note of the IP address, router and one DNS server.



3. There are three IP address ranges reserved for private use: 10.x.x.x, 172.{16-31}.x.x and 192.168.x.x. Looking at the IP address, router and DNS address from the previous step, pick one of those ranges that is unused. You’ll use this for the wireless network you create shortly. For example, the router is in 10.1.x.x and the DNS server is in 172.16.x.x, so I’ll use 192.168.x.x.
4. You may find it easiest if you’re moving between locations to create a new network location for this Internet sharing configuration. You can do that in the Location drop-down at the top of the System Preferences window.
5. Still in the Network part of System Preferences, choose AirPort, then click Advanced. Go to the TCP/IP tab.
6. Pick any IP address in your chosen range, with a matching subnet mask. 10.x.x.x should use 255.0.0.0, 172.16.x.x should use 255.255.0.0, and 192.168.x.x should use 255.255.0.0. Enter the same router address you copied down from the Ethernet configuration. For this post, I’ll use 192.168.1.1.



7. Go to the System Preferences -> Sharing. Click the Internet Sharing item, but not the checkbox next to it. This should show “share your connection from” is Ethernet, and “to computers using” has AirPort checked. Click AirPort Options.



8. Pick a network name. I also recommend turning on 128-bit WEP. It’s not great, but it’s better than nothing. You need to pick a password, which unfortunately must be exactly 13 characters.
9. Click the checkbox next to Internet Sharing and Start in the scary warning dialog that follows.
10. From one of your other devices, you can now connect to your new wireless network. You will have to configure its IP address manually, since your Mac is not running a DHCP server to supply it.
11. Use another, different address for your wireless device, but in the same network as the AirPort you just set up. Since it’s using 192.168.1.1, I’ll use 192.168.1.2. Use the same subnet mask, but use the AirPort’s IP (192.168.1.1) as the router. Use the DNS IP you copied down in step #2.

That’s it: you should now be able to use the Internet from your wireless device, via your laptop plugged into the Ethernet.

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.

There is a work-around, though it does mean storing your user and password in plaintext in your device’s bookmarks. HTTP allows you to supply authentication credentials as part of the URL, in the form http://username:password@example.com/.

In the last few days, I’ve considered building a form-based login for one of my sites, just so I can do basic management from my iPad. I’m comfortable that since the device rarely leaves the house, and the data on this site is not sensitive, that leaving the password in plaintext in the bookmark is an acceptable trade-off.

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:

• If you are switching from SSHKeychain, remove the environment override for SSH_AUTH_SOCK from ~/.MacOSX/environment.plist.
• To get the GUI passphrase dialog and the option to save the passphrase in your keychain, you must use the system ssh, not one from Fink or MacPorts.

Here in America, we’ve become rather used to the idea that fresh fruits and vegetables are available whenever we want them. What we don’t always realize is that this convenience comes at the cost of flavor and price. Plants grow according to a schedule, and while we can force things somewhat (hothouse tomatoes, for example), if you want peaches in the dead of winter, they aren’t coming from the northern hemisphere.

Shipping produce from South America is a long trip to an American market, though, so food has to be bred to survive the journey and someone (the consumer) has to cover the costs of that travel.

There are even disadvantages to strawberries grown and sold in season. Strawberries are so fragile, growers have had to breed them exclusively for shipment, resulting in a berry that has only a pale shadow of true strawberry flavor left.

I created In Season to help my own family, and hopefully others, with this problem. Food tastes better when it’s grown according to its natural schedule, and even more so if you can find a local farmer supplying produce to your market. It will take less effort to grow it and supply will be higher, so you will pay less. Locally-grown produce also means less fuel is burned bringing that food to market, further bringing prices down and reducing your carbon footprint at the same time.

The economics of the App Store being what they are, version 1.0 is a toe in the water. If it is well received and I can justify further development, I have some great ideas to make it an extremely useful and educational app.

If you are interested in those books I mention above, they are terrific reads: How to Pick a Peach: The Search for Flavor from Farm to Table, by Russ Parsons and Animal, Vegetable, Miracle: A Year of Food Life, by Barbara Kingsolver.