I started a month-long campaign, targeted at people who list “CrossFit” as one of their interests, and who aren’t already fans of the page. I set the maximum cost-per-click to $2, and the actual price per click averaged $0.78. The maximum I would spend per day is $5 (nearly every day, this budget got filled). The ad was shown 292,955 times, and was clicked on 160 times. The ad looked like this:

Fans of the page increased by a significant amount: up to 76 fans from a previous 27. That seems like a win.

Did it impact sales of the app? Not one bit. Here is the revenue graph for WOD over the past four months, including last month, when the ads were up (daily numbers, and the 10-day moving average):

There doesn’t seem to be any correlation between the ads and revenue; for part of the campaign, revenue went down significantly. It doesn’t seem worth it, to me, for this domain: I was able to afford about 7 daily clicks total, and it’s not clear if any of those clicks turned into sales — maybe every click was a sale, too, but it’s impossible to know if it did or not. The ads would pay for themselves if only two of those clicks turned into sales.

Do I think the ads made a difference? No. Will I try to expand the campaign, spending more? Nope.

Oh, wait. Well that was presumably the idea, if I could, you know, log in to the PlayStation Network and connect it to my Steam account and what-not, so I could then activate my copy. But nope; PSN has been offline for nearly a week now, after a huge breach of security that likely let someone download all ~60 million PSN users’ account information, including sensitive things like credit card numbers.

So, it occurs to me that this is not a big, public-yet-isolated incident, but rather that this is one of the first in a coming wave of very large and damaging security breaches. Attackers are becoming more sophisticated, at a pace that far outstrips how we’re making progress at making systems better, and becoming better programmers.

In fact, I think the industry is making very little progress in making more secure systems, and programmers are not getting any better at writing code. Attacks, on the other hand, keep getting better, since the incentive to do so is so much stronger — the incentive to prevent these attacks is simply a decent salary; the incentive to clean up after the fact is stronger yet, but then it’s more legal mitigation than engineering.

What I’m anticipating, then, is that over the next few years attacks of this scale will become more numerous, as will quiet attacks that you’ll never hear about, unless it’s your bank account or credit card that gets attacked. The thing is, banks and credit cards have relied on small, easy-to-leak numbers for years; now it’s easier to transmit information, especially if efforts to prevent these leaks are few, and are working against the market’s established momentum.

My bank accounts are linked to a number of services I use, so I can pay my bills over direct deposit and not have to worry. Dozens of sites on the web have my credit card number. Dozens have various overlapping bits of personal information. I don’t care about personal information about me getting online generally, I only care if there’s a practical downside for me if it does; if someone sees a photo of me drunk at a bar, well, not a big deal. If someone can gain access to my bank account because some green college graduate only learned how to copy and paste code, that’s something else.

This isn’t even about our best hope for privacy on the Internet — PKI, which backs the extremely important protocol TLS — being broken, but that’s part of the problem too. Most programmers are either lazy, or not smart enough to handle these issues, or both. The brightest hackers are getting better and will have better tools. None of this will change anytime soon. Barriers are hard to erect; they are easier, and funner, to take down.

I don’t think the shitstorm has even begun; Sony and the PSN incident were the first splat.

The first issue was odd: occasionally, the navigation views on the left would get wonky; the color scheme is such that it’s white text on a dark background (the built-in, dark textured background), but occasionally these views would switch to a white background, and some of the views wouldn’t get populated with data anymore. This happened when memory pressure started hitting, and views needed to be unloaded.

I spent a long time trying to figure this out; I thought the problem might have been with UINavigationController, which people say is really only meant for full-screen views, or as the “root” view controller of a split view.

So, I spent some time reimplementing UINavigationController from scratch, and produced this: https://github.com/csm/CustomNavigationController. This is also nice, because it supports custom animation directions.

This wasn’t the problem, though; the problem was that I was subclassing UITableViewController in each of the content views, but wasn’t setting the view property to a table view: instead, it was a container view that held the table view. Well, it seems that if a UITableViewController gets unloaded, it doesn’t seem to re-load this correctly from the nib: instead, it was creating a brand-new UITableView that had the default settings and occasionally, didn’t have the delegate or dataSource properties set properly. So the solution was actually simple: just subclass UIViewController and implement the appropriate protocols. UITableViewController seems really optimized for just handling a single table view, so it’s better to just ignore UITableViewController if you’re doing anything fancy.

But anyway. I made something neat out of the process.

You buy now!