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

Several of the buttons, especially the colored ones along the bottom half of the directional pad, are not rectangular.

It doesn’t matter if we’re developing on the Mac or iOS. Views are rectangular and they either gobble a click/tap or they don’t. Take a look at the green button. The blue outline shows the frame of the view. It overlaps two other buttons: down and rewind. Especially on iOS, where a fingertip is an imprecise input method, a user will find it very frustrating if a tap on down was instead interpreted as green.

The solution is quite straightforward on iOS: create a subclass of UIButton and override -pointInside:withEvent:.

- (BOOL) pointInside:(CGPoint)point withEvent:(UIEvent *)event
{
    /* Surprisingly, this method is called even when point has a negative
     * component and is obviously outside of self.bounds. */
 
    if (CGRectContainsPoint(self.bounds, point))
    {
        /* The point is within our bounds. If a mask exists, check the mask
         * for an allowed tap. If there is no mask, let the superclass
         * (UIButton) do the work. */
 
        if (mask != NULL)
        {
            return mask[(NSUInteger)point.y * maskWidth + (NSUInteger)point.x];
        }
        else
        {
            return [super pointInside:point withEvent:event];
        }
    }
    else
    {
        return NO;
    }
}

pointInside:withEvent: is called by hitTest:withEvent:, once for each subview. If a subview returns NO, then its branch of the hierarchy is ignored. By making pointInside:withEvent: sensitive to only the part of the image that is the button, it’s possible to ignore events for taps on a part that doesn’t.

The key is building a mask. Here, it is a two dimensional BOOL array. If mask is not NULL, the x and y of the point is used to index into the array and return the value there. If mask is NULL for any reason, the code simply falls back to the superclass’s behavior.

One way to build the mask is to look at the alpha channel of the image.

- (void) buildMask
{
    if (mask)
    {
        free(mask);
        mask = NULL;
    }
 
    CGImageRef image = [self imageForState:UIControlStateNormal].CGImage;
    if (image == nil)
    {
        return;
    }
 
    NSUInteger width = CGImageGetWidth(image);
    NSUInteger height = CGImageGetHeight(image);
    uint32_t *pixels = malloc(width * height * 4);
 
    if (pixels != NULL)
    {
        /* Provided that memory for the temporary 32-bit pixel array was
         * available, draw the CGImage into that memory. */
 
        CGColorSpaceRef colorSpaceRef = CGColorSpaceCreateDeviceRGB();
        CGContextRef context = CGBitmapContextCreate(pixels, width, height,
                                                     CGImageGetBitsPerComponent(image),
                                                     width * 4, colorSpaceRef,
                                                     kCGImageAlphaPremultipliedLast | kCGBitmapByteOrder32Host);
 
        CGContextSetBlendMode(context, kCGBlendModeCopy);
        CGContextDrawImage(context, CGRectMake(0, 0, width, height), image);
        CGContextRelease(context);
        CGColorSpaceRelease(colorSpaceRef);
 
        mask = malloc(width * height * sizeof(BOOL));
        maskWidth = width;
        if (mask != NULL)
        {
            for (NSUInteger y = 0; y < height; ++y)
            {
                for (NSUInteger x = 0; x < width; ++x)
                {
                    /* RGBA: high 24 bits are color, low 8 bits are alpha.
                     * Less than 50% alpha is the untapped part of the image. */
                    mask[y * width + x] = (pixels[y * width + x] & 0xFF) > 128;
                }
            }
        }
        else
        {
            NSLog(@"Unable to allocate memory, will fall back to UIButton behavior.");
        }
 
        free(pixels);
    }
    else
    {
        NSLog(@"Unable to allocate memory, will fall back to UIButton behavior.");
    }
}
 
- (void) setImage:(UIImage *)image forState:(UIControlState)state
{
    [super setImage:image forState:state];
    [self buildMask];
}

The subclass overrides setImage:forState: so that when the image is set or changed, the mask is regenerated. To use a non-rectangular button within Interface Builder, we need to also override initWithCoder:.

- (id) initWithCoder:(NSCoder *)coder
{
    self = [super initWithCoder:coder];
    if (self)
    {
        [self buildMask];
    }
 
    return self;
}

If you don’t want to use the alpha channel, another option is to provide an explicit mask image. Masks are monochrome bitmaps, where white indicates the visible area. Building the mask array from a mask image is very similar to using the alpha channel. The only difference is what part of the pixel data is analyzed.

- (void) setMaskImage:(UIImage *)maskImage
{
    if (mask)
    {
        free(mask);
        mask = NULL;
    }
 
    if (maskImage == nil)
    {
        return;
    }
 
    CGImageRef image = maskImage.CGImage;
    NSUInteger width = CGImageGetWidth(image);
    NSUInteger height = CGImageGetHeight(image);
    uint32_t *pixels = malloc(width * height * 4);
 
    if (pixels != NULL)
    {
        /* Provided that memory for the temporary 32-bit pixel array was
         * available, draw the CGImage into that memory. */
 
        CGColorSpaceRef colorSpaceRef = CGColorSpaceCreateDeviceRGB();
        CGContextRef context = CGBitmapContextCreate(pixels, width, height,
                                                     CGImageGetBitsPerComponent(image),
                                                     width * 4, colorSpaceRef,
                                                     kCGImageAlphaPremultipliedLast | kCGBitmapByteOrder32Host);
 
        CGContextSetBlendMode(context, kCGBlendModeCopy);
        CGContextDrawImage(context, CGRectMake(0, 0, width, height), image);
        CGContextRelease(context);
        CGColorSpaceRelease(colorSpaceRef);
 
        mask = malloc(width * height * sizeof(BOOL));
        maskWidth = width;
        if (mask != NULL)
        {
            for (NSUInteger y = 0; y < height; ++y)
            {
                for (NSUInteger x = 0; x < width; ++x)
                {
                    /* RGBA: high 24 bits are color. Anything other than black
                     * is tappable. */
                    mask[y * width + x] = (pixels[y * width + x] & 0xFFFFFF00) != 0;
                }
            }
        }
        else
        {
            NSLog(@"Unable to allocate memory, will fall back to UIButton behavior.");
        }
 
        free(pixels);
    }
    else
    {
        NSLog(@"Unable to allocate memory, will fall back to UIButton behavior.");
    }
}

Just because your configuration file’s contents are written in a DSL does not mean you should pretend it’s not Ruby anymore.

The worst offenders are those that name these files without a reference to the thing that uses them. Bundler‘s “Gemfile” and Foreman‘s “Procfile” are two examples.

You can read more in the press release.