Aero Vacation made mistakes that are beginning to become more and more common in iOS games, and I sincerely hope the trend reverses sometime soon. They were, in no particular order:

• Requiring a constant network connection. Aero Vacation would display an alert view and prevent any user interaction until it could find a network connection. This happened every time the app was opened – even if only backgrounded for a split second – and took a good three to five seconds to complete. In some cases, the network connection would fail, even with a strong WiFi signal, requiring the user to hammer a “retry” button a couple times until it finally decided to go through. And if no network was available, the app would force-close itself, requiring a much longer reloading procedure the next time it was launched.
• Requiring in-app purchase for critical game function. Around level 16, Aero Vacation wanted me to build a Ballroom in my airship. Unlike most other buildings (which cost regular coins), the Ballroom cost special Aero Vacation dollars, which – though you could earn them in-game – were very difficult to come by, unless you felt like paying serious cash. In my opinion, games like Tiny Tower and Cut the Rope get this right: new content is available regardless of cash spent, even if it is a bit slower or requires that you play more. I’m more than willing to play extra if I enjoy the game; I’m not always willing to pay extra.
• Losing player progress. This was the most critically obvious flaw in Aero Vacation, and the proverbial straw that caused me to uninstall: the app reset me two levels, representing several days of play, after a bad network-related crash (see point #1 above). For players seriously invested in the game, this can be a huge blow, and the arbitrariness of the loss makes it that much harder to come back and rebuild: why bother continuing to play if the app can just lose my work?

As I continue sampling iOS games for a week or two at a time, I’m noticing more and more that they get their respective game mechanics right; I’m very rarely worried about flaws in gameplay or graphics anymore. I tend to focus more on the problems surrounding the app itself: whether it can function offline, how much it expects me to spend in an average day of play, and whether it can guarantee my progress is safe.

Thankfully, there are still a good number of games that get this right: Tiny Tower and Cut the Rope are two examples from above. Temple Run is another popular recent game that works well offline, making Game Center purely optional, and one I’ve never seen progress lost in. After playing these types of games, Aero Vacation served as a rather painful reminder that not every developer is quite so observant of the needs of their users. In fact, I was rather surprised (when researching for this post) that Chillingo made both Cut the Rope and Aero Vacation, as they seemed incredibly different in behavior and user-friendliness. Let’s hope their next game can return to some of their former success.

After some digging, I discovered an AppleScript from user TingTingBen on GetSatisfaction that accomplishes this:

tell application "iTunes"
set TheITunesWindowName to name of (first window whose its class is browser window or its class is playlist window)
activate
if selection is {} then reveal current track
end tell
tell application "System Events" to tell window TheITunesWindowName of process "iTunes"
click (first button whose value of attribute "AXDescription" is "Genius")
end tell

By adding this to Alfred’s extensions and binding it to the keyword genius, I can play a song with the iTunes Mini Player, then reopen Alfred and immediately Genius the song. I can also let a playlist or album start playing through, then turn it into a Genius playlist when I hit a favorite song.

The basic class header looks like the following:

@interface MyDataManager : NSObject

@property (nonatomic, strong) NSArray * collection;

- (id)initWithCollection:(NSArray *)collection;

@end

Here’s where the Xcode magic kicks in: beginning a method signature with the type NSUInteger and name count produces an autocomplete suggestion for the method countOfCollection. The toolchain will look at the existence of the property and infer that you want methods based on that collection – something beyond any other IDE I’ve seen.

I was a bit surprised at the rather unequivocal answers most people were giving: one comment says,

I don’t think they do, look at Skype for example. There are even “jailbreak” apps that start these kind of apps for you.

An answerer to the question even posted almost immediately, garnering a number of upvotes and becoming (for a short time) the top answer:

Without jailbreaking the device, it is not possible to automatically start an app on start-up – except for Apps from Apple. I have no official reference for this, but just ask the mentioned person to demonstrate how to do this (he likely won’t).

First off, that’s a terrible reason to assert something: the fact that some given person won’t sit down and hold your hand to an answer that should be well-documented is no indicator that the answer isn’t true, or reliable, or anything less than solid. It’s not really an indicator of the reverse, either, but doubting something documented explicitly and only because it’s rather time-consuming to prove is rather arrogant.

More to the point, though, what’s the answer? Common wisdom in this situation seems to say that iOS won’t start apps automagically at boot time, but Apple’s documentation mentions a very specific circumstance that’s an exception: adding the voip key to the application’s property list, under the “required background modes” array key. In this one instance, the iOS documentation says that the app will be launched so that it can negotiate a background connection and handle incoming calls as soon as the device is turned on.

From that little piece of information, it should be pretty trivial to make an app that contains the necessary keys and hack it to track its own startup time. Right?

So to test this little theory, I started with the Utility app template, with Core Data enabled (but without unit tests – shame on myself). The only entity needed was an AppLaunch class with one attribute: a timestamp. After that, it was trivial to add a tiny method in the app delegate that inserted a new instance of the AppLaunch entity into Core Data with the current time as the timestamp, and hook up the main view controller to display the most recent AppLaunch instance’s timestamp in a label. (Please don’t judge me on my UI design.)

Turns out the documentation is accurate (surprise!), and apps with the voip key do start with the system – the sample app I tested updated its own launch time after a phone reboot, but before I had the chance to open the app myself. I gave each action about a minute of wait time, so there’s little chance of fuzzing a second here or there and messing up the results. All the same, I encourage other developers interested in the app/system boot relationship to clone the code and try it out.

That’s a lofty intro for little more than a link: I just saw this series of videos by Robert “Uncle Bob” Martin, and I thought they served as a really good introduction to the concept (if a little dated). Watch and enjoy.

I’ve been asking this question at the end of interviews (in the “Do you have any questions for me?” phase) for the last two weeks, and it’s turned out to be one of the most revealing questions I could possibly have asked. Answers have ranged from CVS (still!) to Git to Perforce to that Microsoft Team Foundation Server thing.

And those are all well and good; it doesn’t really matter to me what SCM you’re using, nor will your choice (on its face) affect my decision. What really matters is why.

The reasoning behind your SCM choice tells me an incredible amount about you, your company, and your management, all veiled as a technical question. If it’s a tech interview, you’re likely a developer, and I can see whether you appreciate your source control, look at it as an annoyance, or just don’t care one way or the other – indicative of how important that SCM system is in the company. If you’re management, you likely had to make a choice (or deliver a decree) at some point about that system, and your reasoning tells me about how strongly you micromanage, care about centralization, and understand your own release process. Either way, it’s all good information.

Let’s look at a couple examples (both real companies).

“Company A” uses Subversion – not uncommon in the industry. In a tech interview, though, the interviewer said that they had looked at Git and wanted to migrate, but literally didn’t have enough developers to explore the switch (hence the hiring process for the company). Furthermore, on a small scale, the company allowed individual developers to use their own systems, so long as they integrated with the central repo as necessary (for Git, this means git-svn or similar).

“Company B” also uses Subversion. Their approach, however, is much different: the CEO made a decree that SVN was the required tool for all developers. He justified this due to his desire for one central, “official” repository that always had the master branch, and the need for developers to always be working against that branch.

As an advocate of distributed version control, Company A sounds pretty good – they allow Git or Mercurial on a small scale, and are open to newer technologies companywide, indicating an agility within their development department. Company B, on the other hand, sounds as though development is hamstrung by management, and that the people with decision-making power don’t understand the new technologies available in DVCS.

I extend this kind of reasoning to pretty much every company I talk to. The ones on CVS better have a good reason (large legacy code, for example); Microsoft TFS users are usually apologists as well, which has its own implications; and people on Git or Mercurial generally go into great detail about why they like it and what problems they’ve had recently. The last is the most encouraging, because it implies a level of software craftsmanship (caring about their tools) rather than a focus on just slinging code. There was even one company on Darcs, which was incredibly interesting just for the different perspective they offered.

In general, SCM choice offers an interesting window into a company from a development perspective – it speaks to the mentality of the developers and the atmosphere of the company, more than a straight-up question about “day-to-day experience” might.

I used my first Macintosh at the age of two – a Mac LC III, purchased in early 1993 along with an expanded hard drive. In elementary school, my friends and I stayed in during recess to install and play games on the classroom Macs. I learned to type on the early iMac G3s. I got my very own MacBook Pro in late high school, and upgraded to another Pro last year. I own an iPhone 3GS and iPad, and will place a preorder for the 4S tomorrow.

Steve Jobs and Apple brought something special to each one of these moments.

More importantly, Steve and his company made each of these moments possible. I couldn’t imagine getting my computing start on Windows 3.1 in ’93, or hacking on a Linux box in fifth grade. Steve, and Apple, had the unique ability to take computing, devices, programs, and UI, and make them simple. And elegant. And fun.

I’ve played with a number of systems and machines in the past 18 years. Never have I found one that’s had the same feeling as a Mac, the same intuition or style. I use a Mac now, and it’s made everything – from just plain browsing to intense coding sessions – feel incredibly natural. And it was Jobs’ skill, vision, and intellect that helped guide today’s Mac into that place.

Apple – and the world – has lost a true leader in the technology industry. We can only hope his influence and passion remain.

In a pull request, though, there are two key people: the author and the committer. The author is the one actually responsible for writing the code; the committer is the one that sticks it in a repository (usually a privileged or “main” repository for release purposes). Both of these people should have their names attached to the commit, but by default in a pull request, only the author’s name appears – the committer is ignored entirely.

This article lays out a series of Git commands to resolve this problem and mention both contributors on a single commit in GitHub, using a recent patch to Multiverse-Portals as an example.

In this case, a friendly dev named VibroAxe added support for portal cooldowns. (What they are isn’t important; the important part comes next.) This support was spread across two patches, and regrettably used tabs instead of spaces, so there was still some work to do.

Let’s first lay out the existing situation:

• Central repository managed by myself and FernFerret
• Forked repository for VibroAxe with two new commits
• Fix implemented but with poor tabbing practices

And what do we want to happen?

• Central repository gets one new commit
• New patch contains content from both VibroAxe’s patches and fixed tabbing
• New commit mentions VibroAxe as author, myself as committer

As mentioned, we can’t use GitHub’s built-in merge button, since that just does a branch merge with fast-forwarding; it has no mention of the committer anywhere.

So let’s start by checking out the primary repository, then adding a remote for VibroAxe’s repository:

git clone git@github.com:Herocraft/Multiverse-Portals.git
cd Multiverse-Portals
git remote add vibroaxe https://github.com/VibroAxe/Multiverse-Portals.git

Now we can fetch the contents of his repository, which contains the commits we’re merging:

git fetch vibroaxe

Once fetched, we need to work with the new code, so we can check out a branch. However, since we fetched without explicitly branching to track VibroAxe’s repository, we need to create a branch name while checking out:

git checkout -b vibroaxe-cooldowns vibroaxe/master

Now we’re on a branch with the new code that needs to be merged back. Before we combine, though, let’s fix the spacing issues – we alter any code that needs to be changed and create another commit. Now we’re three commits ahead of the upstream master branch.

From this point, getting those commits onto master involves a simple rebase:

git rebase -i master

While rebasing, we can leave the first commit as “pick,” but “squash” the next two commits down onto the first – this will leave us with only one commit on master that combines the work done in VibroAxe’s two commits and the spacing work done in the third.

After fixing up the messages for our new combined commit, we simply push back to master and call it a day:

git push origin master

And voila! GitHub shows VibroAxe as the committer of a single commit combining all work needed for the new cooldowns feature.

Github commit with committer and author

Hello happy players! This post is meant to be a pretty in-depth explanation of what’s new in Minecraft 1.8 on our server. It assumes you have a passing familiarity with the upgrade already, but even that isn’t 100% required.

The biggest change by far is in the “game mode.” Minecraft 1.8 introduces an experience bar, a food/hunger bar, and a difference between creative and survival modes. The server integrates all of these in some way.

First off, all existing worlds will play in survival mode by default. This is most similar to the Minecraft experience you’re familiar with; the only addition will be the hunger and experience bars. Mob settings remain the same; there will continue to be no hostile mobs in the main world, but new hostile mobs will begin appearing in the hostile worlds (including “hostile,” “scratch,” and “skyland”).

We will be creating a new “creative” world. This world will be the only world to play in creative mode, and we will be separating its inventory from all the other worlds. This means that, even though you can have an unlimited number of any block in creative mode, you can’t bring them back to other worlds and sell them for a profit.

Unfortunately, the terrain generator changed in Minecraft 1.8, and there’s no option to keep the old generator. This means that land outside the current world boundaries will behave as it has in past updates, and will generate new 1.8-style chunks. This will lead to some pretty sharp edges (cliffs and the like) in all existing worlds. I’m sorry, but there’s no way to avoid this – players can choose to just deal with it, stay within existing world boundaries, or (my personal favorite) build cool walls/stairs/transports across chunk edges.

In order to avoid the inevitable issues with hiking 20 minutes to get to 1.8-style chunks in the main world, we will also be creating a new peaceful world that will be completely unoccupied. The rules will be the same as the current peaceful world: it will play in survival mode, and players must respect each other’s territory. The purpose of this world is to allow players to get new materials from 1.8-style chunks more easily. Its inventory will be shared with the current network of worlds.

Thankfully, all the existing plugins still work, with one exception: SignShops. There will be breakage in some of the shops that are set up; again, I’m sorry, but this is unavoidable. We are moving to a different shops plugin with a better record for supporting new Minecraft versions, and I will provide more info and help transition as soon as possible.

Thanks for your patience during this transition, and happy mining!

Being a creature of habit, though, I kept doing this after I started buying my own gas, and eventually wound up with a stack of gas receipts with two numbers scribbled across the top. Since my parents no longer cared about them, though, I became responsible for these little scraps of paper. Why not have some statistical fun with them?

To satisfy my curiosity (and to be able to throw away all those crumpled-up receipts), I wrote GasTracker, a single-serving Sinatra application that allows users to list cars and drivers, then record the gas purchases made by each driver on each vehicle. To get some usefulness out of the thing, I also made it generate summary statistics for the purchases it tracked:

Screenshot of the prototype gas tracker with current data set

Yes, those numbers are accurate for my gas purchase history: I really have spent almost $1,800 on gas since September 2009, even though I got an average purchase price of $3.17 per gallon.

Right now, I have this deployed internally behind Apache (with Passenger) so that I can have some password-protection. Next steps are to clean up the UI, finish out the REST API, and write a mobile application. (Feel like contributing? Fork it on GitHub!)