Watching

Just about every bar in Singapore has automatic-flush urinals. My brother visited while I was there, and coming back from the toilet one time he quips, “That little flashing light is Lee Kwan Yew watching me pee, isn’t it?”

He’s a funny bugger my brother, but there’s more than a little ring of truth to it. Having lived previously only in Australia and the UK I wasn’t prepared for the profound sense of unease that subtly pervades your day when you live in a surveillance state.

I used to joke that there I probably broke seventeen laws before dinner time though I had no idea what they were. But you can guarantee the ISD did, and if I’d managed to piss off the right person, I’ve no doubt that sufficient evidence could be found to put me away for however long they thought was necessary to teach me a lesson. Or maybe they’d just fix it so I couldn’t sit down for three months.

I’m hardly a criminal mastermind or a violent scofflaw, but I’m no earnest rule-following “heartlander" either. The thought in the back of your mind that you’d better keep your nose clean, the self-censorship when talking about anything remotely controversial or political, the second-guessing yourself about whether this or that action might piss off someone with just enough power to make your life hard—it all generates a constant low level anxiety that was a large part of my distaste for living in the place.

So despite the standard of living my income there afforded, I left for Amsterdam. Not because I wanted to smoke weed so much as I wanted nobody to care if I did. For a while, I was able to relax.

And then Edward Snowden showed up with evidence that the USA and its partners were running a global surveillance operation the totality of which would make a Stasi officer blush.

The feeling of being watched and the low-level background anxiety is back. But this time, for everyone. I’m being melodramatic? You’ve got nothing to hide? Ok, quick: how much do you earn, have you ever cheated on your partner and do you have a family history of schizophrenia? Answers in a public Facebook status please. In any case, it’s not about having nothing to hide. It’s about being watched and the feeling of being watched. That some arbitrary bureaucrat can ruin your life on a whim. And they do.

And now the Australian government is diving in. Even scarier, this is from an Attorney-General who quite clearly has no understanding of the technology he is drafting laws about.

Tony Abbott has set the groundwork in place for turning Australia into a facist dictatorship. Once security services are are given these kinds of powers it is almost impossible to wind them back without some form of revolution (violent or otherwise) and I am afraid the Australian electorate does not have much of a taste for that.

I have no idea how we fix this problem, in Australia or globally. But it starts with people ignoring the Abbott government’s cynical attempts to manipulate the public into believing the abolition of privacy is a good thing.

Kentucky Fried LED project

… or, “How I nearly burned down the truck that was taking our camp to Burning Man.”

One of my side projects for this year’s Burn was some bike underlights, the BikeBlinder. Pretty simple construction, just some WS2812B 144 LED/m strips mounted to RHS aluminium channel, controlled by a DFRobot Beetle, powered off a 125W DC-DC 5V buck converter and a 12V sealed lead acid battery.

I had some SLA batteries in the blinky box my friend was going to send up to me from Vegas. He’s a champion, so before he sent them off, he tried to charge them for me at which point he found that the charger was busted. So I bought a new charger and 5Ah SLA battery when I got to Seattle, hooked everything up to make sure it worked (it retina-searingly did!) and packed it all away neatly for the trip to Black Rock City.

It wasn’t until our bikes arrived on the Playa on Tuesday that I discovered what could have been a huge disaster. I’d left the SLA battery plugged in during transit. At some point it had been jostled in such a way that it pushed a wire onto the prongs of the toggle switch, breaking the wire’s insulation and creating a short. 5Ah of charge had been dumped through about 10cm of 18AWG wire in a few seconds, vaporising the insulation and carbonising the copper. If there had been anything else even remotely combustible in that box (and if it wasn’t air tight) we could have had a proper fire on our hands.

I was royally pissed off that yet another one of the projects I’d worked so hard on for the previous few months was a bust, but could console myself that I didn’t burn the totality of our camp infrastructure (and my friends who were driving the truck) to a cinder.

So I’m sharing this lesson with you here for free: do not fuck with batteries. Always insulate battery terminals in transit and never leave them connected in storage. The project you save may be your own.

Bonus “holy shit” image: here’s the poor DFRobot Beetle that was meant to be powering the big bike blinder. Ouch.

The Technocolour Dreamcoat at Burning Man 2014

So, what did my 640-pixel Technocolour Dreamcoat’s shipment of fail arrive in at Burning Man this year? I’m glad you asked!

There were two main problems, plus a couple of annoyances.

Power

Due to the PITA (and expense) of shipping lithium batteries around, I had four Limefuel L130X batteries delivered to meet me at my friends’ place in Seattle, so I’d never hooked it all together on the eventual power source (I’d been running off a mains-wired 100W PSU during development.) The special thing about the Limefuels is that they promise 2.1A on both of their USB ports—all others I’d seen say 2.1A on one port, 1A on the other. So over four batteries, I ought to have got a total of 16.8A, or 84W @ 5V.

Problem one is that I misread the spec and thought it was 2.4A from both ports simultaneously, where it’s actually 4.2A from both simultaneously, but 2.4A max from one port (if you’re pulling only 1.8A or less from the other.) So using FastLED’s dynamic power management to cap my draw at 80W, I had way way less headroom than I thought.

But even so, I should have had some headroom: maybe the the Limefuels aren’t actually capable of delivering the current advertised on a sustained basis, OR I may have had an intermittent short somewhere? In any case, after running my rainbow plasma for a while (draw of about 30W), the batteries’ protection circuit kicked in and they all shut off. Briefly plugging them back into the charger reset them, and I tried again. This time not so lucky. All four tripped again, but one wouldn’t turn back on. The sniff test revealed I’d let the Magic Smoke leak out.

Not good. Fortunately one of the awesome people on the FastLED Google Group was leaving for the Playa after me and had time to Amazon Prime a new battery that I could pick up from him when I got there. So I lowered the max draw to 50W (giving me a whole battery’s worth of headroom) and crossed my fingers.

It didn’t work out. Even with a max draw that should have been within the current delivery capabilities of three of the four batteries I had connected, their over-current cut-outs kept tripping, and I eventually fried another battery. By now I was pretty sure that running these packs wired in parallel was not a good idea (I had been warned.) My best guess as was that one battery tripped, then the other three had to suddenly take up the load, one of those tripped, then it was two… and all of a sudden one poor unit is left holding the (twenty amp) bag and pop.

I did take the jacket out another couple of days, but made sure to only run it on the less dense, lower power patterns.

Wiring

This was another issue. The spade lug connectors I had soldered into the bottom of the strips to connect to the power bus were on short, stiff wires without enough strain relief (despite me trying to pot the ends of the strips in heat shrink filled with E6000 (aka “Our Lady of Perpetual Adhesion”—it’s going to be a bastard to undo so I can fix it.) Quite a few of the wires just snapped off, but funnily enough, not enough of them to make it an actual problem! I had enough redundancy that despite both the +5V and ground connectors coming off the bottom of at least one strip, the circuit was maintained by the connection to the adjacent strips at the top.

I am going to fix this by changing how my power bus is mounted: I’ll sew two parallel pockets vertically adjacent to each other around the bottom jacket for the +5V and ground bus braids, and have longer wires coming off the end of the strips to connect to them (instead of short wires off which the power bus braids hung.) This will allow me to pot the connection into the bottom of the strips properly and will be much more reliable, with the added benefit that there won’t be such a big “bulge” at the bottom, leading to less bunching and a flatter profile.

Other annoyances

I think I have a dodgy signal wire somewhere, but that should be easy to fix. More annoying was the touchiness of the cheap-arse rotary encoder I was using to switch patterns. It was registering a count before settling into a detent; I thought I’d fixed it in software but it was still touchy as hell. I’ll get a (stiff) rocker switch for up/down next time, and also a separate (analogue) pot for brightness control, and a separate button whose use would be up to the currently selected effect.

Future plans

Until I realise my dreams of doing stupid shit like running 40A across my torso via explosive lithium chemistry strapped to my back, I’m going to try splitting the power bus in two and running each half off separate Limefuels to see if this fixes the “last guy standing cops it” effect. I need to get the new power bus pockets sewn in, and strip down and rewire the power bus ends of the strips. I’ll also rebuild the control box with independent controls, and see if I can find a better way of attaching the strips themselves to the velcro that holds them in place on the jacket (the adhesive that comes on the strips isn’t worth a damn, and the velcro expands in the heat at a different rate to the strips, so it has the tendency to all come undone.)

Hopefully I can get that lot seen to before London Decom at the end of October? Yipe!

The Builder pattern in Objective-C

When @kluivers pointed out @klaaspieter's post on using the Builder Pattern in Objective-C I took note, as this is something I’d used quite extensively doing TDD in Java. I thought I saw a way to finesse it slightly and finally having had the time to do it, I’m happy to say it’s worked out like I’d hoped.

The idea was to use an Objective-C category to hide the builder-related code and prevent it from “polluting” the original implementation.

This gist has an example. Say I have some kind of “value item” class (GroupableItem in this case) having a bunch of properties which all need values, most of which might not be germane to any given test and some of which might be complex to set up. I create a GroupableItem+Builder category containing an implementation of a GroupableItemBuilder class with properties for all the configurable options. GroupableItemBuilder's init method sets default values for all the configurable properties of the builder. Finally, this category defines the itemWithBlock class method, which creates the value object from the defaults set in the builder, after they’ve been “offered” to the user to change via the block.

This way in my SomethingUsingGroupableItemTest I can import the category and use the builder to set whichever properties are relevant to my particular test, knowing I’ll always end up with an internally consistent object.

Better, if the GroupableItem+Builder category is declared in my test tree, it isn’t even compiled into my app.

This is kind of a degenerate example and I could of course have just created a method in my test class with parameters for the configurable options that returned an instance of my value object. But this breaks down pretty quickly when you have more than three or four configurable properties (only one or two of which you might want to alter from the default for any given test.) It also creates a pleasing separation between the “meat” of the test and the “plumbing” (which can be easily reused in multiple places.) This approach is also type safe across refactorings of my value object’s property names.

Now you have two problems

Up until the advent of the iPhone App Store you could split the problems you needed to solve to produce a software product into three broad categories: development, marketing and distribution.

The App Store solved problem number three in an effortless and comprehensive way—anybody who could possibly use your software is able to buy it instantly, wherever they are, at no up-front cost to the developer.

The misconception was that the App Store solved problem number two as well. For a short time it did: the novelty of the App Store itself drew attention to the products available there. The fact those products were initially so few in number resulted in an amount of attention-per-product sufficient for customers to discover them, and there were many indie developer success stories.

But with the growth of the App Store this “attention effect” has been diluted to almost nothing. The whole progression starkly illustrates just how important the “marketing” component of a software product is and this has profound implications for the careers of those of us who identify as “software developers”.

The other, other ninety percent

Software engineers joke that the first ninety percent of a programming task takes ninety percent of the time and the last ten percent takes the other ninety percent. The idea is that once you’ve got a program working for the majority of “happy paths”, there’s always a bunch of edge cases you need to take care of. (Daylight saving changeover? Unreliable network? German translation where all the strings are three times as long and muck up your interface?). Tying up these loose ends typically takes about as long as writing the code for the happy cases.

Having gone through this process myself and finally having an app I’m reasonably proud of on the App Store, I’ve discovered there’s another ninety percent between that and a product. No matter how good your code is or how legitimate or large a problem your software solves, you’re not going to make any money until you market it well. That means writing App Store copy (with localised screenshots, translated into a dozen languages.) It means writing a press release. It means finding relevant people to send that press release to, sending it to them and fielding any follow-up enquiries.

It means signing App Store contracts and registering in a bunch of tax jurisdictions and eventually filling out their returns (or at least deciding whether it’s worth it.) It means dealing with support enquiries. It means organising with your translators (times twelve) to update the strings in your app when they change in a new version. A hundred little details like this turn a piece of software into a product worth paying for.

I like writing software. I’ve got a bit of aptitude, over a decade’s worth of experience and maybe even a little skill doing it. I’m interested in doing it and learning how to do it better. This other stuff, not so much. I’m not so sure how I’m going to bridge that gap.

I am an App Maker

A bunch of different people have said something along the lines of, “In order to become a writer, you must write.”

Well, about two years ago I decided I wanted to become an App Maker. Now I am.

Cheapr App Store link

Thank you to everyone who’s helped beta test and translate, helped me with questions about iOS and Objective-C and suffered through me banging on incessantly about this little project. I owe you a beer.

Objective-C is like Jimi Hendrix

The first time I heard Jimi Hendrix I had no idea what all the fuss was about. Sure, it was great, but it wasn’t changing my life. Maybe a decade later, it hit me: thirty years previous, he’d changed every guitarist’s life and changed the sound of guitar music forever. He was the first person to play a guitar like that but it happened before I was born, so I just accepted the post-Jimi guitar sound as normal and nothing special.

I’m getting some sense that Objective-C is like that. Books, manuals and grey-bearded Objective-C programmers bang on about how marvellous the runtime is and the power of code introspection and method swizzling and dynamism and I’m thinking, “Yeah, so what?”. Even as a Java programmer[1], I just expect my programming environment to have those features.

But as a C programmer in the 1980s, this stuff must have been fucking mindblowing! Having joined the industry in the late 90s, the languages I’ve used have been mostly paving over the trails blazed by Objective C (and friends) without needing to carry the burden of backwards compatability.

So if you’re new to Objective-C and, as I am, struggling to come to terms with the fact that it’s one great big leaky abstraction on top of C, put yourself in the shoes of an 80s C programmer and remember you get to use these neat “modern” features in a systems programming language.

[1] Yeah yeah, Java’s hardly “dynamic”, but most of the rest of the “amazing” bits of Objective-C can be (and regularly are) done with reflection and aspects. If you squint really hard, you can even use anonymous classes to pretend you have lambdas.

No really, I want to start a band!

That said, there are a lot of “musicians” in Appsterdam who would quite like to form bands. But as any black-t-shirt-wearing highschooler knows, it doesn’t work very well when six guitarists show up to a jam session. Just as a successful band will need a rhythm section, singer, songwriter, road crew and tour manager, a successful app product will need back-end developers, designers, support engineers and marketing.

So consider this an open invitation: don’t be scared off participating in Appsterdam events just because you’re not an Xcode maestro. I’m seeing a growing realisation among my “lead guitarist” colleagues that killer riffs aren’t enough. The audience needs to be addressed on its own terms and that’s something many of us aren’t the best at. We see the value that great marketing, design and other skills bring and we realise we need help in those areas.

Lots of developers are looking for people who want to be equal partners in building successful products. If you have experience in any of the other skills necessary to bring a great app to life, if you’ve got money to invest in a great performance or if you’re just smart and keen to learn, we’d love to meet you.

Let’s start a band!

“Hey, let’s start a band!”

“Cool, what instruments do you play?”

“I don’t play any instruments.”

“Oh, so you’re a singer?”

“No, I can’t sing.”

“Do you write songs?”

“No.”

“What records have you produced?”

“None.”

“Can you book us gigs?”

“No. I’m not a sound engineer, A&R person, tour operator, venue owner, merch supplier or roadie either… but I’ve got a really good idea for a band name!

Every app developer has had the above conversation with an enthusiastic but overly optimistic (and possibly misguided) person who’s got a “great app idea and they just need a dev to implement it”. It’s come up a few times at Meeten and Drinken and my preferred strategy is, as gently as possible, to disabuse our hopeful friend of the notion that it’s as easy, fast and cheap (!) as they think it is.

“What’s the best way to get my app built?”

“Offer a developer €150/hour to build it.”

“Oh, ah, well, what’s the second best way?”

“Offer €100/hour.”