I said it was relatively easy, but the truth is that it took me several hours to get everything configured properly. There are a few guides out there, but none that succinctly explained everything correctly. This is my attempt to rectify that problem.

This guide also assumes your server is running a Linux distribution and the clients are Mac OS X or iOS. I don’t have Windows clients, so I can’t say if this will work for them. I use Debian Linux; adjust package installation and configuration file paths if you use something else. My configuration is typical for “road warriors,” meaning clients can connect from any IP address and may be behind a NAT.

Install Openswan (IPsec userspace daemon) and xl2tpd (L2TP daemon):

$ sudo aptitude install openswan xl2tpd

Edit /etc/ipsec.conf. In the config setup section, add an exclusion for your internal network to the virtual_private line. Mine looks like %v4:!192.168.1.0/24. Unless you’re on an old kernel, change protostack from auto to netkey to squelch a warning. Then add a connection section. Here is mine:

conn L2TP-PSK
	authby=secret
	pfs=no
	rekey=no
	keyingtries=3
	dpddelay=30
	dpdtimeout=60
	dpdaction=clear
	compress=yes
	left=%defaultroute
	leftprotoport=udp/1701
	right=%any
	rightprotoport=udp/0
	auto=add

This says the IPsec connection will authenticate with a pre-shared key (instead of client certificates). DPD is Dead Peer Detection and is needed because iOS clients don’t tell the server when they disconnect. My settings send DPD keepalives every 30 seconds, and clear connections that don’t respond after 60 seconds.

Edit /etc/ipsec.secrets and add a line similar to this:

1.2.3.4 %any: PSK "put-your-preshared-key-here"

Replace 1.2.3.4 with your VPN server’s public IP address and put your chosen pre-shared key in quotes. This is the secret shared between the server and your clients.

Next, edit /etc/xl2tpd.conf. I added the following to mine.

[global]
access control = no
rand source = dev
 
[lns default]
ip range = 192.168.1.120-192.168.1.127
local ip = 192.168.1.1
require chap = yes
refuse pap = no
require authentication = yes
name = LinuxVPNserver
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tp
length bit = yes

ip range is the range of IP addresses from your internal network that you want clients to get an address from. local ip is the internal IP address of your server.

Edit /etc/ppp/options.l2tp:

ipcp-accept-local
ipcp-accept-remote
ms-dns 192.168.1.1
noccp
name vpn
auth
crtscts
idle 1800
mtu 1410
mru 1410
nodefaultroute
debug
lock
proxyarp
connect-delay 5000
plugin pppol2tp.so
require-mschap-v2

ms-dns is the address of a DNS server on your internal network. name is used in the next file.

Finally, add entries to /etc/ppp/chap-secrets to set up individual VPN users:

username	options-name	"password"	192.168.1.1/24
options-name	username	"password"	192.168.1.1/24

username is the client’s user name and options-name must match the name parameter from the previous file, options.l2tp. The last parameter is the subnet and mask to match this client. It should be the range of your internal network.

On my server, Openswan didn’t create the links in /etc/rc?.d required to start itself when the server boots. insserv addresses that:

$ sudo insserv ipsec
$ sudo invoke-rc.d ipsec start

Finally, you need to allow incoming connections if your server uses a firewall. iptables rules look like this:

iptables -A INPUT -m state --state NEW -i eth0 -p udp --dport 500 -j ACCEPT
iptables -A INPUT -m state --state NEW -i eth0 -p udp --dport 4500 -j ACCEPT
iptables -A firewall -p esp -j ACCEPT
iptables -A firewall -m policy --dir in --pol ipsec -p udp --dport 1701 -j ACCEPT
iptables -A firewall -i ppp+ -p all -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

This allows UDP traffic on ports 500 (IPsec) and 4500 (NAT-Traversal) and all ESP (IPsec Encapsulating Security Payload) traffic. Additionally, it allows incoming UDP traffic to port 1701 (L2TP) if it’s wrapped in IPsec. Finally, PPP interfaces are created to pass traffic and we need a rule to permit that.

You can now create L2TP VPN configurations on your Mac and iOS devices, using the values you chose along the way, and you should have a working VPN.

If I have something wrong (it’s entirely possible I left something out), get in touch and I’ll fix the post.

RubyMotion is interesting, but I don’t have any plans to use it myself, especially for client work. There are two reasons.

The first is from a business standpoint. I learned long ago to put aside my own opinions of how things should be done whenever possible and to swim with the current. This applies to managing servers (use the package manager and avoid installing your own software) and developing software (understand the intention of the API’s author and use it accordingly).

Apple ships a lot of open-source software with OS X, but they aren’t great about keeping up with releases. Nor are they good at supporting alternative ways to write software on their platforms. Remember Java, RubyCocoa, and PyObjC? This is even true, to some extent, of MacRuby. Apple paid Laurent to work on MacRuby, yet MacRuby never shipped with an OS X release. If you want to use MacRuby in a shipping application, you either require your users to install it (terrible UX) or embed it yourself (at a cost of 10+ MB to your app bundle).

Lion shipped on July 20, 2011. It includes Ruby 1.8.7-p249. 1.8.7 has been in maintenance mode for a long time and Apple has ignored numerous patches.

• p299, released on June 23, 2010, over a year before Lion
• p302, released on August 16, 2010
• p330, released on December 25, 2010
• p352, released on July 2, 2011

The Ruby core team has encouraged people to move to 1.9 since the official release of 1.9.2-p0 on August 18, 2010. There are no signs that Apple will move the system Ruby to the 1.9 series in the upcoming Mountain Lion release, either, nearly two years later.

I’m offering all this as a long-winded way to say that I do not put much faith in Apple’s desire to avoid breaking a third-party toolchain such as RubyMotion when they can’t be bothered to do a good job supporting the Ruby they ship on OS X. It’s less troublesome, but still an issue, that they never shipped the MacRuby framework, which they paid an employee to work on.

If Apple were to break RubyMotion, intentionally or otherwise, in a future iOS release, I would be unable to fix those apps until RubyMotion adapted to the change, however long that took. In the meantime, the apps would be broken, making users unhappy. If the apps were for clients, my choice of a third-party toolchain will reflect very badly on me, as well.

Objective-C is how Apple wants developers to build apps for iOS. Choosing something else means swimming against the current and invites trouble later. At the very least, the pool of available talent is massively reduced. This puts my clients in a bad place if they can’t or won’t come back to me for updates.

My second concern is about programmer productivity. Xcode takes a lot of abuse, and Xcode 4 has been somewhat of a step back, but it’s still a pretty good IDE. I may in the minority, but I really like the wordiness of the Cocoa APIs and the way that Objective-C’s mixes arguments into the middle of method names. For any method that takes more than two arguments, this naming style saves me from needing to remember things. Xcode’s code completion is crucial to this, though. When it stops working, writing to the Cocoa APIs is painful.

One of RubyMotion’s selling points is that I get to use my preferred editor. Does any text editor offer intelligent code completion for classes from both frameworks and my own source files, without a manual indexing step? If not (and I doubt it, since it’s a big job), then I’m back to having to remember things, and a lot more than just the order of method arguments.

RubyMotion also throws Interface Builder out. The promise is that you’ll build interfaces in code, using an ASCII art style similar to Cocoa Autolayout. I don’t see this as anything other than an admission that RubyMotion can’t work with IB. It is a huge weakness, perhaps worse than the code completion problem.

RubyMotion is an interesting idea, but I won’t consider it for anything more than prototyping in the near term.

Update: Ian Phillips demonstrates that it is possible to use Interface Builder, but very minimally. You can lay out the interface, but that’s it. No outlets, no actions and no storyboards (which are great, if you haven’t tried them yet). A big part of what makes the Cocoa + IB combination so wonderful is that we can freeze dry a set of objects that make up an interface and later recreate them, with all their connections intact. This work must still be done in code with RubyMotion, which is ugly. Until RubyMotion can support NIBs 100%, it might be better not to use them at all.

What makes PaintCode different from most vector drawing apps is that it generates code that can be pasted directly into a project. In the 1.0 release, it could export to a couple of graphic formats, but unfortunately not PNG. The 1.0.1 release addresses this, and now I have the choice of generating a simple icon on-the-fly, using the code generated by PaintCode, or exporting to PNG and bundling the files with my app.

Back in January at CUSEC 2012, Bret Victor presented a talk titled Inventing on Principle. One of his main points was that it is important for a developer to see immediate feedback as code is changed. For me, PaintCode serves this purpose: if I have a visual effect in mind, I can play with the shapes, shadows, colors and gradients visually to achieve the effect I want, and then look down to see how to do it in code. This greatly shortens the experimentation cycle time.

PaintCode isn’t cheap, but the time it saves me when I need it makes it worth every penny.

Get Air Display on the iOS App Store ($10) and use that older iPad as a second display when you’re working away from your regular desk.

In my office, I’m used to two good-sized monitors, and I typically have my editing environment on one side and a browser or documentation on the other. My laptop is a 13″ MacBook Air, and the screen is simply not large enough for that arrangement. With Air Display, it works great.

A river of gold for the people who build good phones. Another river for the people who run the networks. And for the developers, crumbs.

I’m going to take a leap here and blame it on venture capital.

One thing you won’t find a venture-backed hardware startup doing is giving away their product. For consumer software and service startups, however, this is common. Consumers are now conditioned to expect that software, whether it’s a website or an app, is free.

The unfortunate part of this that the average person won’t look far enough down the road to see that not paying for something they value (in some form) now will often mean that it disappears entirely later. See Maciej Cegłowski’s wonderfully snarky discussion of the business of bookmarking (PDF).

Growing a business without VC takes time. It means growing slowly, increasing headcount and expenses as revenue grows. With VC, a business can grow very quickly and work on solving big problems from the start. This isn’t a bad thing, but in the Internet age, it now also means ignoring revenue. That isn’t sustainable, and if you don’t figure out how to sell something by the time the funding runs out, you’re done.

There is nothing wrong or shameful in exchanging software or a service for money. The creation of these things is a skilled task that takes years to master. We don’t expect plumbers or carpenters to give away their expertise for free. Why should software developers?

The latest example of this decline in how we value software is from Readability. To be fair, as near as I can tell, they aren’t venture funded, but they suffer from the same symptoms. Their app is free, yet clearly they retain a faint memory of what running a business means because they offer an “optional contribution” in-app purchase for $5. It is a tacit acknowledgement that software requires time, effort and expertise to create, yet I’m left with the impression that they are embarrassed to ask for money. It is deplorable. Meanwhile, the king of the vertical, Instapaper, costs $5 up front, same as it’s been from nearly the beginning.

The wasted billions of VC is making it awfully hard for the rest of us to make a living selling software.

I’m starting a new Rails project. I want to use Ruby 1.9.3 from the beginning to ease a future upgrade to Rails 4.0, which will require it. This presented a few issues I had to work through for my development and production environments.

Mac OS X ships with Ruby 1.8.7, but I’ve been using RVM to manage different Ruby versions in development and it’s worked fine. Debian is my preferred server distribution and the latest stable release includes Ruby 1.9.2-p0.

I’m not completely comfortable with using RVM in a production environment, and I don’t want to take on the work of installing my own Ruby entirely by hand, so this led me to look at rbenv, a lightweight alternative to RVM. It seems better suited for use in a production environment. I like to match development to production when possible so there are less things to remember, and so I switched to rbenv on my development machine, as well. Paired with ruby-build, it gives me the important features I used from RVM (I never made much use of gem sets).

It did not go well.

$ rbenv install 1.9.3-p0
$ RBENV_VERSION=1.9.3-p0 gem install bundler rails
$ rbenv rehash
$ RBENV_VERSION=1.9.3-p0 rails new app
...
/Volumes/User/Steve/.rbenv/versions/1.9.3-p0/lib/ruby/1.9.1/net/http.rb:799: [BUG] Segmentation fault
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin11.3.0]

Searching for solutions led me to suspect that this is due to a library version mismatch between the compiled Ruby and a gem. MacPorts can make this more common, because unlike Homebrew, it imposes strict control over dependencies and will install a new version of something (e.g., OpenSSL) even if Mac OS X ships with an older one that would work fine.

Rather than track down the problem library, then figure out how to ask rbenv to link with a different version of it, I decided to try Homebrew.

It worked flawlessly. The error when creating a new Rails project is gone.

What really sealed the deal for me came next. I like PostgreSQL, partly because it supports additional data types that can be very useful. One example is cube, which is used by the earthdistance extension to store locations and do fast proximity searches. On MacPorts, installing those “contrib” extensions is a manual, clunky process. On Homebrew, all the contrib extensions are already compiled and available.

Sold.

Let’s take a hike on the coast from San Francisco to Los Angeles to visit our friends in Newport Beach.

Other answers point out that coming to a task with related experience certainly helps, but just because you’re an experienced hiker doesn’t mean you know how long it’ll take to hike an entirely new trail. Even if you’ve hiked a particular trail before, it doesn’t prepare you for mud, wildlife or broken ankles.

I finally realized today that this doesn’t matter. Unlike the rest of the gems your Rails application uses, Bundler lives above the fray. It is perfectly safe to use a prerelease version of Bundler on your development machine and stick to the stable release on your production servers.

I encourage you to give it a try. bundle install imposes practically no overhead over the actual gem installation time, and bundle outdated is tremendously useful when planning for gem updates.

$ gem install bundler --pre

Though it goes against the spirit of Git, I prefer the central repository model for two reasons. The first is backups. With a central repository, I only have to think about backing up one place to an off-site location. The second is access. My primary development system is a desktop, but I do occasionally take a laptop on the road. It’s easier to pull relatively recent source from a central, Internet-facing repository than it is to tunnel back into my network. I also do a lot of Rails work, and it’s simplest for Capistrano to pull from an Internet-facing repository.

So my goals are:

• Public repositories are available over plain HTTP without authentication
• Pushing into a public repository requires authenticated HTTPS
• Private repositories are only available over HTTPS and require authentication for any access
• The ability to allow a user access to only a subset of private repositories

Some details of the discussion will only be applicable to Debian/Ubuntu systems, but are easily adapted to other distributions.

The first step is creating a central repository.

$ cd /home/git
$ mkdir repo-name.git && cd repo-name.git
$ git --bare init
$ sudo chown -R www-data:www-data .

Next, you need to set up Apache to serve this repository. I use the smart HTTP transport supported by Git 1.6.6 and later, which is nearly as fast as the git:// protocol, but doesn’t require poking a hole in the firewall. Add this to your appropriate virtual host configuration.

<VirtualHost *:80>
        ServerName YOUR-SERVER-NAME
        ErrorLog /var/log/apache2/git-error.log
        CustomLog /var/log/apache2/git-access.log combined
 
        DocumentRoot /home/git
        SetEnv GIT_HTTP_EXPORT_ALL
        SetEnv GIT_PROJECT_ROOT /home/git
 
        # Let Apache serve static files
        AliasMatch ^/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$          /home/git/$1
        AliasMatch ^/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /home/git/$1
 
        ScriptAlias / /usr/lib/git-core/git-http-backend/
 
        <Directory /home/git>
                AllowOverride None
                Options +ExecCGI -Includes
                Order allow,deny
                Allow from all
        </Directory>
 
        <Location />
                Order deny,allow
                Deny from all
        </Location>
 
        <LocationMatch ^/public-repo.git>
                Allow from all
        </LocationMatch>
</VirtualHost>
 
# mod_authn_alias essentially configures groups of users.
<AuthnProviderAlias file internal>
        AuthUserFile /etc/apache2/git-internal.htpasswd
</AuthnProviderAlias>
 
<AuthnProviderAlias file clients>
        AuthUserFile /etc/apache2/git-clients.htpasswd
</AuthnProviderAlias>
 
<VirtualHost YOUR-SERVER-IP:443>
        SSLEngine on
        SSLCertificateFile PATH-TO-YOUR-CERTIFICATE-FILE
 
        ServerName YOUR-SERVER-NAME
        ErrorLog /var/log/apache2/git-error.log
        CustomLog /var/log/apache2/git-access.log combined
 
        DocumentRoot /home/git
        SetEnv GIT_HTTP_EXPORT_ALL
        SetEnv GIT_PROJECT_ROOT /home/git
 
        # Let Apache serve static files
        AliasMatch ^/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$          /home/git/$1
        AliasMatch ^/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /home/git/$1
 
        ScriptAlias / /usr/lib/git-core/git-http-backend/
 
        <Directory /home/git>
                AllowOverride None
                Options +ExecCGI -Includes
                Order allow,deny
                Allow from all
        </Directory>
 
        # Require authentication to all repositories
        <Location />
                AuthBasicProvider internal
                AuthType Basic
                AuthName "Git"
                Require valid-user
        </Location>
 
        # Allow both internal and client users to access this repository.
        <Location /client-repo.git>
                AuthBasicProvider internal clients
                AuthType Basic
                AuthName "Git"
                Require valid-user
        </Location>
</VirtualHost>

Create the password file. Remember to set user and group ownership and permissions appropriately.

$ sudo htpasswd -m -c /etc/apache2/git-internal.htpasswd <user>
$ sudo chown root:www-data /etc/apache2/git-internal.htpasswd
$ sudo chmod 640 /etc/apache2/git-internal.htpasswd

Repeat the htpasswd command once for each user, dropping the -c option (which creates the file, or truncates if it already exists) for subsequent users.

For each repository you want to export, you must run git update-server-info once by hand, and enable the post-update hook to do the same. On Debian, the sample post-update hook already does it, but it must be renamed to enable it.

$ cd /home/git
$ foreach r in *; do (cd $r; git update-server-info; \
    mv hooks/post-update.sample hooks/post-update); done

For any existing repositories that you push to, writes to those files is now done by Apache, so you must change the ownership of all of the files in the central repository to the web server user (www-data on Debian).

The final roadblock is that I use a wildcard, self-signed SSL certificate. Git refuses to accept these unless you approve it. There are two ways to do that.

1. The simple, but insecure way: set http.sslVerify = false in your ~/.gitconfig. This turns off certificate verification for all HTTPS remotes.
2. The more secure, complicated way: preface any command that talks to the remote (clone, push) with GIT_SSL_NO_VERIFY=1. Once you have a local copy, you can also edit its .git/config and add a new http section with the sslVerify = false setting.

Marketing

By far the biggest problem for the small developer in the App Store is visibility. We cannot rely on Apple to market our apps. Getting featured is akin to winning the lottery; it’s great, but we can’t count on it. Nothing has changed from selling software before the App Store: we still have to figure out how to market it.

In both 2010 and 2011, I used prMac to send a press release to iOS-related news outlets. With the exception of some automated repostings of the press release, neither year resulted in any real editorial coverage. I also submitted the app to many iOS review sites. Again, nothing came of this.

I did three things in 2010 that I did not repeat in 2011: a screencast, mostly for review submissions, advertising (Facebook and AdMob, neither were worthwhile), and a free weekend in early December.

Last year, I priced the app at 99¢, figuring that it would appeal to the mass market audience and be a good impulse buy. Sales were disappointing, so for 2011 I figured I had little to lose and raised the price to $1.99. The free weekend in 2010 didn’t boost visibility at all, and since weekends are the biggest sales days of the week for this app, I felt no need to repeat the experiment.

Excluding the free downloads, year-over-year sales for December were up 13%. Apple hasn’t announced earnings for the quarter including December 2011 yet, but for the prior quarter, iPhone sales were up 21% year-over-year. My sales lagged overall iPhone growth, but it’s still growth and customers seemed no less willing to buy at $2 than $1.

Design

Lights Finder is a classic “scratch my own itch” app. For years, since I was a kid, my family set out once or twice a year to drive around and look at lights. I moved to Columbus in 2006. In a new place, it isn’t obvious which neighborhoods are good to visit and which are mostly dark. Young children have short attention spans and aimless wandering isn’t very popular.

For the first version, I was fine investing time, but gave myself a very limited budget, which meant I had to design it as best as I could myself. The result was serviceable, but far from polished.

For 2011, my biggest goal was to get rid of the programmer art and work with a professional designer. I have mixed feelings about my decision. While I am very happy with the result, sales didn’t cover the costs. It’s hard to justify spending thousands on a personal project when sales don’t cover costs.

Technology

In 2010, I supported iOS 3.1 and later. At the time, this followed the common “current version plus the previous major release” advice. For 2011, I stuck with this, but a year later that meant iOS 4 and 5. Since any device that can run iOS 4.0 can run 4.2 (and should, given how sluggish 4.0 is on iPhone 3G), I set the minimum version at 4.2.

This allowed me to delete quite a bit of code, modernize my API usage, and, most importantly, convert the project to ARC.

ARC is wonderful. There isn’t even one crash report in iTunes Connect, on any iOS version.

Next year, and for every new app, I will only target iOS 5 and later, though. Take a look at these charts:

For the sake of completeness, the chart on the left shows the breakdown by device type. Unsurprisingly, most people used the app on their iPhones.

The next two are the pleasant surprise. The middle apes Marco Arment’s device and OS stats from Instapaper. Almost 78% of Lights Finder users were already on iOS 5, and 90% were at 4.3 or later. Of course, anything running 4.3 can also run 5.0, but it turns out that quite a few people running 5.0-capable hardware were still using 4.2 or earlier. Fully 99% of users were on a device that is capable of running iOS 5!

While I don’t feel like sharing raw numbers, I acknowledge my sample size isn’t nearly as large as Instapaper’s. Still, I’m encouraged by the data. Lights Finder is as likely to be used by casual people as technology nerds. iOS 5 has only been available for a couple of months, and the lagging 21% will upgrade eventually, especially if more apps require it. Looking forward from iOS 5, adoption should be even faster with over-the-air updates.

Customer Support

Based on a presentation a few months back at CIDUG, I decided to add a link on the about screen soliciting feedback. This resulted in some ego-bruising moments, but overall it was a good choice. Some people wrote in with a question, and it was nice to have the opportunity to help them. It also allowed me to ask for a review, and several obliged.

Others were unhappy and demanding refunds, sometimes rudely. I suspect most of these people never expected an answer, and some became much nicer after I sent one. I tried to be helpful, explained that App Store developers can’t issue refunds, and how to contact Apple about one. (To date, AppViz shows no refunds.)

It is disappointing that people can get so worked up about a $2 app. These are probably the same people who spend $2 on a lousy cup of restaurant coffee and don’t think twice about it. If an app doesn’t meet their lofty expectations, though? A venomous 1 star review and demands for a refund.

Giving these people a quicker route to vent their disappointment than an App Store review likely worked in a few cases. Often, they were unhappy because the directory, while robust, didn’t have excellent coverage in their area. I asked where they lived and, for those that replied, dug up some addresses from Google. In the long run, it makes the app better, but it left me feeling bitter about doing so much for $2 (well, $1.40) and rewarding rudeness.

The upside is that about 30% of the people who used the app in 2010 came back in 2011. That doesn’t seem very high, but it’s likely that half of the 2010 users acquired the app during the free weekend, used it once, then forgot about it. If most of the returning users were the ones that paid, that bodes well for 2012 and beyond. Eventually, the holes in the directory will be filled, and maybe one day Apple will decide it has a place in the holiday apps feature.