Much and more has been written about Apple’s new programming language, Swift. I even did a talk about it at Yow: Connected 2014. If you saw me there, you’d know that I’m not the biggest fan of Swift. I think the rollout of it has been an absolute disaster: the compiler is a shambles, the language design is inconsistent in places¹ and it’s stupidly difficult to get working in libraries, particularly if you want to support iOS 7. Surely though, at the very least its performance would be all right. After all, it’s designed to be more static and do more checking at compile-time and is meant to be made with the LLVM optimiser in mind…

Let’s talk about performance in Swift, then.

Just as it is with coding standards, everyone thinks they have the answers when it comes to hiring new people. I’m under no such delusions. I don’t pretend that this method will work for everyone. It won’t. This is simply the mechanism that I used to hire the team I currently work with. The team in question has turned out rather spectacularly, thanks in no small part to the effectiveness of this method. If you or your business is looking to hire more developers, I’d encourage you to consider this method, or at the very least, consider simplifying your hiring process to just the bare essentials that tell you what you’re really looking for.

It’s no secret that the rhythm game genre is dying, or at least wheezing its last wretched breaths. From 2008 to 2009, both the Guitar Hero franchise and Rock Band franchises saw up to 50% declines in revenue – Activision responded by releasing even more games, to the collective sigh of the entire games-consuming public. The last major title in the genre, the venerable Rock Band 3, released in 2010 and the finest entry of the bunch in my humble opinion, barely sold a million copies. Compare this to the monstrously successful Guitar Hero 3 from 2008 which sold somewhere over 3.5 million copies and it paints a pretty depressing picture.

I’ve lost count of the number of times I’ve opened a .plist file in Sublime Text only to have it come up with binary goobledegook. It’s pretty standard in the Apple universe to see binary plists with the standard .plist extension, so there’s no way to know whether they’re binary or not without trying to open it first. The common answer to this is “just use Xcode!” – however, anyone that’s actually used Xcode before will know just how much it sucks at casual editing. Opening Xcode is a commitment I’m just not willing to make sometimes.

It’s become painfully obvious to me recently that developers tend to be really, really bad at setting up a decent build environment. Xcode is shonky at the best of times, but it certainly doesn’t help if you let carelessness or ignorance lead to complexity creep. Eventually, you’ll end up with a project requiring 10 different build scripts, all with their own sets of assumptions and dependencies (such as ruby, brew, pod, perl versions).

Jenkins

Jenkins is shit. No really, it’s actually really rather terrible. When you think about it, it’s basically just a pretty (well ok, it’s not pretty by anyone’s definition) interface over cron. For the purposes of continuous integration, there’s pretty much nothing Jenkins gives you that you couldn’t achieve with a cron job, a decent build script in your repository and a disciplined filing system.

Maybe that’s a bit harsh, but from my personal experiences from it, most of the things it’s good at is solving problems that it’s responsible for creating in the first place. Your net gain from using Jenkins is damn-near close to zero, but you inherit a massive amount of maintainence burden.