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!)

The most striking and obvious problem that even casual Bukkit users immediately encounter is the fractiousness of the plugin developer community. Normally this isn’t a huge deal: developers argue all the time, and one of the most stable projects I know of (Linux) has a leader famed for his sharp tongue as much as for his code. But the debates often evolve into numerous conflicting projects, often with near-identical functionality. Off the top of my head, I can name:

• Three warp plugins (xWarp, MyWarp, OpenWarp)
• Four economy plugins (iConomy, Essentials, Bose Economy, RealEconomy)
• Two multiworld plugins (Multiverse, WorldManager)
• Four permission plugins (Permissions, PermissionsBukkit, PermissionsEx, Privileges)

Choice is good for a user. Overabundance of choice, often with little to no distinguishing value, is not.

And with the proliferation of plugins comes another, potentially more dangerous issue: many plugins aren’t maintained across Bukkit releases. Developers have the nasty habit of writing a plugin then abandoning it, or providing only cursory updates. When the Bukkit team provides major new releases, then, plugins rapidly become outdated, causing users to refuse to update other parts of their system for fear of breaking it. The end result is irate users who can’t use newer plugins that are updated because they can’t bear to abandon the old ones that are no longer compatible.

Then there are the “problem devs.” Every so often, a plugin has a developer who just can’t handle a bug report, or insists that his plugin be the plugin in the category, and that all the others are terrible. Some developers will up and remove a plugin from distribution for no reason other than some minor criticism. In one of the most egregious cases, a developer updated his plugin’s API – just changing method names, no functionality – in order to force dependent code to adapt to his software or lose users.

I won’t name names, since this is all open source and developers have a right to do as they see fit, and I’m in no position to call anyone out. However, the most successful open source projects didn’t get where they are today through infighting and competing implementations. I myself am not entirely innocent: one of the plugins mentioned in the conflicts list above was my own, and now with a dedicated user base, I can’t in good conscience abandon it in favor of helping on another similar project.

I humbly ask of the Bukkit plugin developer community: please, be a little more mature about your coding practices. Rather than write a new plugin from scratch that works your way, patch or submit pull requests on another similar plugin. Keep your code up to date, and be willing to perform rewrites as Bukkit recommends it. And know that your users are only human: some of them are going to be dumb or mean from time to time. It’s the inevitable consequence of publishing software.

There are millions of registered Minecraft users out there, and a large portion of them play SMP on Bukkit-powered servers. Your plugins have the chance to affect hundreds or thousands of players and administrators. Just keep that in mind as you make your next project choices.

The following is a summary of the various aggregate statistics these programs have been gathering. Some of the numbers are a bit scary.

Overall, I own eight computers, with administrative control over another three. (There used to be a round dozen in the house, but we decommissioned a laptop.) On my current primary laptop, I’m using 484 of the 500GB of space available (97%). 114GB of that is taken up by movies I brought to Albuquerque with me. (By comparison, my total storage capacity – over all eight machines – is somewhere in the range of 10TB, making my laptop 5% of my total. Stats from personal records.)

I wind up typing a lot managing all those computers – since March 2010, I’ve pressed 10,200,878 keys, an average of one key every 3.84 seconds. My mouse has moved a total of 177.13 miles, and I’ve clicked 949,626 times. (Stats from whatpulse.org.)

My music library recently broke 50GB, containing 8,046 songs. It would play for 21 days, 12 hours, 40 minutes, and 3 seconds if songs played nonstop. Since early 2006, I’ve played 72,342 tracks – an average of 37 per day, every day for the last 1966 days. Far and away the most popular of those is Coldplay’s “Don’t Panic,” with 192 listens. (Coldplay is also my most listened artist, with 4,608 plays – 6% of the total, and 1.62x the listens of second-place Death Cab for Cutie. Stats from last.fm.)

Speaking of media, my movie collection is sitting at a round 1,250 movies, taking up 1.5TB of space. Television is another 2.4TB, consisting of 14,548 episodes across 125 series. All told, media (music, movies, and TV) takes up 4TB – 40% of total available storage. (Stats from local servers.)

And what good is that media if it doesn’t go places? On Facebook, I’ve uploaded 478 photos (sharing with 465 friends); I’ve posted 3,621 tweets in the last 924 days, an average of 3.9 tweets per day, to 122 followers; and I’ve earned 11,223 reputation points on StackOverflow, an average of 15.9 points for each of the 705 days I’ve visited. (Stats from the respective sites.)

Then of course there’s the mobile world. My iPhone 3GS is using 23.4 of its 32GB capacity (73%); about 20GB of that is music. Over the lifetime of this phone (since January 2010), I’ve made 5 days, 7 hours worth of calls; sent 571MB of data; and received 3.4GB – almost 5 CDs worth. (Stats from iPhone settings.)

What other things should I be keeping data on?

Enter Liza.

Liza is meant to give Bukkit/CraftBukkit plugin developers a basic platform on which to more thoroughly test their plugins before release. It aims to mock Minecraft players, handle I/O testing, load and unload plugins, and a host of other features that Bukkit developers use.

At present, it’s incredibly rough, but some basic functionality is implemented, including the ability to create a player on a local (JUnit-driven) test server:

As it evolves, we’ll probably start by testing the LightLevel plugin, then moving on to some more advanced open-source works.