Weapon of choice

After 7 months of fairly hardcore OSX usage (on a relatively underpowered Mac Mini) I'm finding using Windows both less relevant and, given my latest project focus, harder to use as a default development platform. More and more of the tools and packages I want to use are freeware, and the more I dig into open source hardware, the more I realise that using Windows to develop in is not the best choice. And the correct choice is, obviously - Unix.

Not OSX? I hear you whisper ... Oh yes, you wanted me to say that. Except the really obvious thing I've found over the last 7 months is that I spend a lot of my time in a terminal window, ssh'd into a remote box somewhere doing stuff the old fashioned way. In fact, my machine is becoming increasingly less relevant - the relevant machine is in the cloud, or in that cupboard over there, or under the stairs ... The glitzy GUI is really a thin veneer over a command line which takes me to where I want to actually be. Increasingly, I'm finding my windows-centric CLI skills give more cumbersome results than the equivalent linux results. I've got used to using Bash and Python for the small stuff, I can just about steer Vim between file creation and edits and I'm getting comfortable with greps, finds and some of the other linux CLI utils. OSX makes this effectively seemless, helping me transition between my Mac and a remote Ubuntu/BusyBox/whatever distro. Windows just puts spanners in the way - the file system is different, the tools for security are different, all of the commandline tools I'm getting used to work slightly differently.

So I'm biting the bullet, and from this month, I'll be using raw Ubuntu for my local development. Sure, I could set up a VM or a box in the cloud, but this means I can stop scratching my head and fighting the urge to work inside the prison I've built for myself. No More spending an hour hunting for the Windows install of something before giving up and switching to a different language or my Ubuntu VM.

Once that's set up, I'll be delving into CMUSphinx4, PocketSphinx and Arduino. After that, world domination.

Tinkering

I've recently bought an Arduino Uno and a small selection of components. I have high hopes that my dream of a voice-controlled house can take a step closer to reality - the only remaining missing piece of the puzzle is the time and inclination to glue everything together from software stack down to the box the end result goes in for my first prototype. There's something quite primal about making motors and sensors work - tapping in some numbers on a keyboard and watching a servo spin is darned cool.

Something is rotten in the state of Denmark

This post is in no way endorsed by Boss Alien, and is entirely my own mini rant.

Boss Alien has had the pleasure over the last six (count em!) months to be developing some really splendiferous products for iOS. Mobile hardware (including phones and tablets) is an obvious growth area in the next decade - if you think that smartphone is cool, just wait until they are that good but cost 50 bucks and everyone else on the planet can afford one. THAT is a market to aim for.

I am a lover of technology, have been for pretty much my entire life. I've mostly been a Windows PC user for the last decade, but before then I followed the path most of my geek generation followed - Spectrums, C64s, the Amiga vs ST wars - all fantastic bits of hardware which had flaws but you could forgive them. And the best part was that the fanboi-ism normally had some sort of counterpoint - you point out a flaw in your friends' device, they implicitly acknowledge it by coming-back-atcha with a flaw in your gear.

iOS requires you to use Macs to do development on (sure, I could hackintosh, but there be dragons). So I've had the "pleasure" of using a Mac Mini and a Macbook Pro at work and at home now pretty much exclusively for the last six months, and for the most part I think they are capable machines with many excellent features, but ...

Oh, but. Where to start. I can list off a litany of absolutely shit design flaws in this hardware, but it seems like any mention of Apple design issues is simply met with a criticism-swallowing black hole - no acknowledgement, no rebuttal - the best I can ever hope for is the occasional sideways "Oh, Timothy" look from my beleaguered colleagues when I go off on a rant.

Here's a few for starters, so you can see where the wrath rises from. My macbook pro has a small divot on the front to let me open the machine, which requires TWO HANDS to use. That divot is so sharp, I have actually cut my wrists on the points before while opening the machine. Yes, that's right - opening the laptop lead to blood.

Then there's the keyboard layout, which has cost me days in retraining my muscle memory, and how it's utterly non-trivial to switch keyboard maps, and how the hash key has moved entirely off the primary key set - great for coding Python.

Then there's all the fun and games using Finder, which is such a badly named utility it's untrue.

That's without even stepping close to the cost/performance curves, or the requirement for extra hardware just to plug in a monitor with DVI, or the hideousness that is iOS development profiles, or ...

Now the point of this post is not to rag on the hardware and ecosystem - but rather to highlight that it is valid and just to rag on the hardware and ecosystem. Apple are good at what they do, but by god they are a long way from perfect. If I read one more post this month anywhere on the internet where the reality distortion kicks in on changes like the Mac App Store sandbox proposals, how Kindle "just isn't quite as Apple-y as Apple" or similar, I'm going to melt down. I'm really getting tired of seeing how otherwise rational people get subsumed into love for these products to the point where all else suddenly becomes a non-viable choice.

I guess I'll look back at this post at some point (when we begin Android development, no doubt) and laugh at myself, but it feels great to get this out.

End of rant!

Tired

I had expected the last couple of months to be pretty hard work, but good lord. Some lessons learned, I think. Good job I still like pizza.

Eff Eff Ess

To whoever stole the badge off the boot of our car - karma will get you in the end, of that you can be sure.

Git and Subversion, or There and Back Again.

Around the end of our first month at Boss Alien, we had been using Git for all of our code revision control (including coder art assets and the Unity project contents). While setting things up was fairly painless and managing local commits was fairly painless, we had various issues and problems while trying to use Git to do merges when people pushed and pulled from the Origin (mainline on our primary Git server).

We had attempted to use a few different OSX GUIs for Git, and the only one that we tried that worked to our initial satisfaction was Tower. Unfortunately there was a bug in Tower that made merges give incorrect results. (This bug has since been resolved with a test case that I sent them). Because we couldn't find another decent GUI, we ended up doing things using a commandline, and that really is not the best way to have people using Git. Merge issues continued to crop up whenever we tried to reconcile parallel changes. After an awful lot of messing around in Git configuration files we managed to get a bearable workflow using P4Merge, but it was still a pain in the arse compared to using a GUI.

This caused us to switch to Subversion, as well as the hope that, because Subversion uses a single server model rather than a distributed version model, we would be able to use the File Locking mechanism in Subversion to help us mitigate the issues with "merging" binary assets. Really, you can't merge binary. This leaves you with three choices - pick yours, pick theirs, don't mess with the file in the first place. With a DRCS there is no way to enforce "don't mess with this". With something like Perforce or Accurev, there are mechanisms to allow you to say "I have this file locked, you can't mess with it".

The main binary assets like models and textures will occasionally cause this problem, but it's rare - you're much more likely to have a single contributor modifying these files and conflicts simply don't arise in that change flow. However, some of the key files in a Unity project (scenes, prefabs and a few others) are currently binary files. Apparently this will change in a future revision of Unity, but working with them right now means that either you can't (easily) collaborate within a scene, or you need to very carefully structure your scenes and prefabs so that other people can modify subsets of assets without breaking the subset you're currently working on.

For projects the size of the ones we're working on, this is annoying. It will undoubtedly cause lost work, but it's probably not going to bring the project down. Any larger, though, and you'll most likely end up in a situation where you just can't work because you're contending with other people changing the same binary files.

Once Unity moves to a text (mergeable) representation of these files, the problem will be drastically reduced (although there will still be undoubtedly painful merges, as we saw using Renderware on the Potter games).

So, to get back to the point - we wanted to have Subversion put a lock on a scene file, for example - to say, effectively "Tim's changing this, so you can't". Not elegant, but in theory it should work. Unfortunately, in practice it doesn't work - in Unity, you can quite happily write over the file without any warning, meaning you end up in the same place at the end of the day - you have a local change and a remote change, and one of you just lost their work.

Subversion brings with it another (in this case, pretty much insurmountable) problem when you're working with Unity. the structure of the Subversion repository is held in hidden directories (.svn directories) inside each directory in your repository folder. This is annoying when trying to copy folders around in your project workspace, as you need to be very careful that you don't move or copy the hidden .svn directories. If you do, then the subversion client will give you all sorts of horrible problems, like thinking a directory exists when it doesn't, not allowing you to add a directory it thinks it already has, that sort of thing. This caused us a good few hours of pain, definitely more pain than resolving Git merge issues.

That's something we can work around when using Finder or windows Explorer. It's simply not something we can work around when moving items in the Unity project browser. When you move directories around inside Unity, it also moves the .SVN directories with it, and you've just broken your local working copy. Unpicking these issues is, pretty much always, more effort than simply redoing the work. Today, I've had three cases where I couldn't redo the work, because I'd lost local files after doing updates in Subversion and I had no way of persuading Subversion to put files back or retrieve them from history without totally deleting my local working copy and starting again. This is simply not a viable workflow.

So, primarily for this reason, we're moving back to Git today - it's not perfect and I'm sure we'll see issues with it, but at least you can work inside Unity without breaking the source control with seemingly innocuous activities.

Logo

We have a logo. Next up, business cards, attitude and schmoozing.