Ports

Something about the discussion around the new MacBook Pros' (lack of) ports was bugging me. In particular, this tweet:

1998 desktops plugged into one keyboard/mouse (PS/2) and one printer (parallel).

2016 laptops connect to lots of USB things, anywhere. https://t.co/nF4pRyYznk

— Marco Arment (@marcoarment) 2 November 2016

Having re-found and re-read it, I realise now that Marco wasn't saying that pre-iMac Macs used PS/2 and parallel ports. Still, it's as good a jumping-off point as any for why I think comparing the MacBook Pro's move to USB-C ports only to the iMac's adoption of USB in 1998 is a false equivalence.

Prior to the iMac, Macs used ADB, serial via mini-DIN and SCSI. These aren't just legacy ports. ADB was a proprietary Apple connection. Serial and SCSI, while industry standards, were the less popular choices in their respective categories. And that, I think, is why they had to go from Jobs' volksputer. At a time when you could pick up a perfectly reasonable serial mouse for £2, replacement ADB mice started from around £20. [I can't find an information about whether you could use serial mice in place of ADB. Even if you could, you'd need a dongle.] The £99 ink jet printers were parallel (and increasingly USB); models with serial interfaces were available, but they were typically the more expensive pro models. And the SCSI variants of external devices generally came at a premium over their parallel or USB counterparts. Adopting USB — unlike dropping the floppy drive — was as much about opening up access to a world of commodity peripherals as it was about ditching dusty old legacy interfaces.

Things

Last year I worked my first (and probably last) IoT gig. I was brought in to build a prototype of the product's iOS companion app and then asked to work on the firmware for the (still-NDA'd) product itself. It was definitely an experience.

Firstly, working with hardware engineers in very different from working with software engineers. For one thing, their desks are so much messier. They tend to have far more pointy and/or hot tools to hand, and generally do at least one thing each day which could potentially burn down the build.

Product planning also takes on a very different flavour. Brainstorming meetings typically follow this kind of pattern:

SOFTWARE GUY: Here's an idea. Why don't we do [thing involving computing]

HARDWARE GUY: Well, yes, we could. But it would have a detrimental effect on battery life.

SOFTWARE GUY: Then how about we do [another thing involving computing]

HARDWARE GUY: Maybe. But it would mean drawing an extra [ridiculously small amount of power] from the battery.

SOFTWARE GUY: Or we could —

HARDWARE GUY: No. Battery.

SOFTWARE GUY: Okay. Would anyone like a cup of —

HARDWARE GUY: BATTERY!

The hardware guys I worked with were wonderful chaps, utterly boffiny types, but boy were they obsessed with batteries.

My second observation involves embedded toolchains, and how they are utter shit. Seriously. I was never one of those complain-about-Xcode guys, but from now on, I shall stifle even the smallest gripe should it threat to escape my lips. What's that? Xcode's crashed? Well at least it hasn't caused a kernel panic, like MP-fucking-Labs kept doing.

(Or at least that was the plan before I started working with Swift… But that's a story for another day.)

I don't really want to go too in-depth into exactly how shite the MPLabs IDE is. I'm trying to put the whole experience behind me. I won't bitch about how the compiler's a modified version of GCC which they've somehow managed to make worse. Or how Microchip want to charge you money for allowing you to write in C++. Or even C99. I am completely over the stress-induced headaches which come from it optimising-away entire blocks of code I had set breakpoints in, even at the lowest setting (or that the higher settings were a paid upgrade).

Let me just make a single observation about the IDE: it doesn't feature any kind of code autocompletion, but it does spellcheck your comments.

Finally, let's deal with the important stuff: the hardware and software. What OS did we use? Ha! Where we're going, we don't need no OS! Okay, this isn't entirely true. The hardware doesn't require an OS (this is embedded microcontroller programming, after all), but after a couple of months of random flailing around it because quite obvious that I did. My years wasted writing assembly language on the Atari ST hadn't properly prepared me for getting this close to the metal. In the end there was some considerable re-tooling and we settled on FreeRTOS to provide a sheen of civilisation to the otherwise register-level barbarity. Tasks! Queues! If felt like someone who went camping and ended up booking into a hotel as soon as it started raining, but sod it, I was comfortable again.

There was a little concern that adding the decadent excess of an OS would fritter away our limited resources, and I must admit I got caught up in this until the point where a took a step back and realised that the chip in question — based on the 32-bit MIPS M4K core running at 40Mhz — was more powerful then the first half dozen computers I owned combined. Sure, it only had 32k RAM and 256k ROM, but we were only asking it to perform some very basic coordination between peripherals. The hardware they'd used to make Jurassic Park wasn't that much more powerful. We could manage.

I left the project when yet another shift in hardware was on the cards. It seemed like a natural break. I'd been telling them from day one that they would be better served by hiring an embedded specialist, and eventually I just felt I had to make a move and force them to take that step. I would have liked to stay on to see The Thing go into production and onto the market. Imagine: seeing neatly shrink-wrapped boxes containing a product that you helped take from an idea to a finished item, rolling off the production line and onto the shelves. I'm keeping an eye open for when it does.

Rez '16

I know there's really no cosmic significance to the 1st of January, but it's as good a day as any to make a new start.

This year I'm going to write every day. Simple as that. Sure, I have a good idea of what I want to write, a list of stories waiting to come to life and be checked off the list, some pie-in-the-sky dreams of where I want to end up, but let's not overcomplicate things. I spent most of last year with fingers on keyboard — at least 10 hours a day, as a result of the day job — and yet I produced nothing, adding only a few paragraphs to one short story. And that simply isn't good enough.

I've started running again. I'm wondering why I can do that — peel myself out of a lovely toasty bed, dress myself in silly clothes, go out into the freezing morning and stumble about wheezing and red in the face — and yet I'm finding it so difficult to devote even half an hour a day to writing. That's going to have to change.

TV

I recently treated myself to one of the new AppleTVs. To be honest, I'm kicking myself for not signing up for the Developer pre-release lottery earlier in the year. I didn't because I knew I wouldn't be able to work on anything for launch day, so why risk taking a unit away from a dev who might. (This is also why it takes about half an hour each morning before I can squeeze my way onto a train.)

My initial impressions? I can't say I'm overly impressed. I've had an Amazon Fire TV box for the last year or so, which received a lot of use and which will be my main point of comparison.

The most obvious area where the AppleTV falls down in my opinion is the controller. The touch pad is too imprecise, making even simple navigation difficult. Selection veers off all over the place and trying to enter text becomes a major frustration. The Fire TV's controls are unimaginative but they're all the better for that. They work. When I click to the left or right I can be fairly certain where my selection in the UI will end up. With the AppleTV's touch pad it's a lottery.

Where the AppleTV will in future excel — and I've absolutely no doubt that it will quickly pass both Amazon's and Google's boxes in terms of units sold and users — is with apps. I should really start thinking up some ideas for it.

Faulty

I am now 40 years old. I honestly have no idea how this has happened. It feels like only yesterday that I was a stupid teenager wasting his time messing around with computers in his bedroom. I'm still just as stupid, and I still waste my time messing around with computers, but now I've been allowed to do it in the lounge.

This last years generally been pretty damn good, but I'm still left with the aching feeling that I've achieved nothing. None of my pre-forty goals have been met. I really need to step things up next year.

(Queue no further posts for another 12 months…

Rez

This year's resolution: a thing a month. It could be some fiction. It could be a game (I'm going to get into game making this year). It should be something more substantial than a blog post — although doing a few more of those this year wouldn't go amiss. Let's see how many months it takes for me to give up on this one.

Countdown

Happy birthday to me! (39, in case anyone's keeping count.)

40 still holds a certain psychological significance. Maybe it's a halfway point: 80 should be easily obtainable these days, barring any of the nastier health issues. I can probably look forward to still being active in another 40 years — if not still actively employed. (I really should re-start paying into that pension.)

Nevertheless, I feel a certain amount of pressure to achieve something in the next twelve months. The last year has been a bit of a bust. Professionally I've only managed to reaffirm that I'm not really suited to working with anyone (or that I have a monumentally low threshold for fuckwits). I've hardly written anything, which isn't a great loss because no one is reading anything I've written previously. I haven't worked on any of my own projects either, deciding instead to spend my dwindling spare time working on apps for other people.

I think it's time for some ridiculously optimistic new years resolutions.

Raspberry Pi iBeacons

I finally got around to playing with iBeacons on the Raspberry Pi today, following this tutorial from The Register. I chose a cheap (£12) Bluetooth LE USB dongle from Amazon, which Raspbian (from NOOBS v1.3.4) found without any problems. Configuration wasn't quite so effortless. I found that the following was a better order of steps once the BlueZ stack had been compiled and installed:

    sudo hciconfig hci0 up       # to ensure that the device was running
    sudo hciconfig hci0 noleadv  # unadvertise
    sudo hciconfig hci0 leadv 3  # readvertise, but as not-connectable
    sudo hcitool -i hci0 cmd ... # etc. etc.

I wrote a quick Python script to automate starting and stopping the beacon. (I'm still only starting to learn Python, so be gentle.)

On the iOS side, it appears to be necessary to set the (poorly-named) .notifyEntryStateOnDisplay property of the CLBeaconRegion instance you're monitoring to YES in order to get beacon entry and exit notifications while the app is active (as apposed to only when the device is sleeping or the app is in the background).

At the moment I have to walk to the far side of my flat in order to get an 'exiting beacon region' message, so I'm going to have to have a play about with the signal strength property. Or get a larger flat.

Scarce

Reading John Robb's excellent Punk Rock: An Oral History, what struck me from the beginning were the reoccurring tales of the difficulty early fans had in finding information about their new favourite bands, let alone getting hold of their records. Allegiances were formed on the strength of single paragraph reviews in the music press; overnight cross-country pilgrimages were made to see the bands play; the photocopied fanzine was the organ of record. (This was at the grassroots level. The Sex Pistols of course were the brainchild of an arch media manipulator. You had to work hard to avoid hearing about them.)

All of which William Gibson describes far more eloquently in his essay "1977" in Punk: An Aesthetic. He describes the shock of the new upon first seeing a stack of UK fanzines brought back to Toronto. "Today we know what new things look like before we encounter them physically. Usually we know what they'll look like before they even exist." He identifies grunge as the last of the pre-digital counterculture movements, the last to start its slow burn to popularity away from the gaze of a public always hungry for something new.

Even though I grew up in the pre-internet world, I find it hard to image what it would be like to experience such scarcity when nowadays even the most niche form of entertainment is, from its very earliest days, its very inception, only ever a Google away. Rather than fighting to have their voices heard across the great open expanse of culture, these day new experiences struggle to be heard above the cacophonous din of a million competing entertainments. Will the next significant movement benefit by the increase exposure the internet allows? or instead be drowned in a sea of noise?

NIB-Based Xcode iOS Template

I once failed one of those coding test job interviews things because of the changes made while I wasn't looking to Xcode templates. In my defence I hadn't actually needed to create a new project in a while and we'd just moved to a new version of Xcode and so on. The challenge itself wasn't too hard — just grab an XML file from a server, parse it, and then display the results in a table — but by the time I'd beaten the empty project into a shape I recognised most of the time had already slipped away. Ce la vie.

More recently, Xcode has moved to having all new templates use Storyboards by default. Often, this isn't what you want. While there are ways of reverting to the NIB-based templates available in Xcode 4, they aren't quite as simple as all that. Which is why I made this basic NIB-based template, which you can grab from GitHub here. Full installation instructions ("drop it into a folder") are included.

This template isn't a direct clone of the old-style ones, since by default it creates the application window and root view controller in code rather than loading them from a main NIB. What it does do is to create a NIB (or two NIBs, in the case of universal apps) for the root UIViewController subclass. I think this is close enough to the old behaviour for the usual use case of needing a quick test bed for trying something out — for any more substantial projects you're going to want to take the time to configure them by hand anyway. The template inherits (as far as Xcode templates implement inheritance) from Xcode's default iOS template, which means that projects created from it in the future will benefit from whatever (hopefully sane) changes Apple make there.

I was helped to throw this together by this StackOverflow post, and this description of the template format which it linked to.