Frabjous Dei @frabjousdei - Tumblr Blog

The Technocolour Dreamcoat, v3.0-release

After putting in a whole lot of work (roughly 2h/panel × 8) over late winter/spring sewing another ~700 pixels, plus re-numbering and re-wiring everything, I finally finished the Technocolour Dreamcoat hardware a couple of months ago. With the deadline of the first festival of the summer season looming, I then sat down to the part I dreaded most: (re-) mapping all 1400 pixels in the PixelBlaze software.

Theoretically the pixels are laid out in an (isometric) grid, but due to the panels being different sizes and shapes and the “start” and “end” pixel in each vertical row not being identical on each panel it’s not entirely regular. In addition, given it’s on fabric and made “lumpy” by the batteries and controller box in the inside pockets, I couldn’t get any of the camera-based auto-mapping tools to work well. So I would have to map each pixel onto the grid manually.

Obviously that would take weeks, so I vibe-coded a tool with Claude to help. I got it to draw the isometric grid with numbered pixels, and allow me to click each pixel to turn it “on” or “off”. It would then spit out the JSON file that Pixelblaze’s mapper needed. I could count up each column on the actual jacket and click “off” the pixels that were in the underarm cut-outs, etc. By loading a pattern into Pixelblaze that lit adjacent rows as different colours I made sure I hadn’t miscounted. So in this fashion, panel by panel, I was able to map the whole thing in a few hours rather than days.

When I thought I’d gotten it all done, something was still off. The tip from the Pixelblaze forums was correct—everything was upside down. This was very confusing and in fact I’d gone back and forth with Claude about this a few times as I was vibe-coding the tool: but now I understand what Pixelblaze wants is a map with the origin 0,0 in the top left which is also pixel zero on your string of LEDs. My pixel string actually starts at bottom left, so the visualisation in Pixelblaze is upside down and that confused me. Fortunately Claude 4.0 Opus (released the previous week!) was able to take the JS map I’d generated and reverse each column for me so it now started at the correct point. I got to this point late Tuesday night planning to leave for my festival Friday morning so I was very relieved.

And, for the first time, it worked perfectly! Not a single glitch, and easily the 7-8h whole night runtime I was gunning for. Very happy with the power distribution bus, USB-C trigger cables (which enabled the 3A@5V × 2 = 30W at full power), the panelisation of the strings (enabling 100-200 pixels off each of the 8 lines of the Pixelblaze Output Expander and the frame rate that unlocks), the 30W Anker batteries and Pixelblaze itself.

This was an entirely linear mapping which essentially “rolls out” the jacket as a flat panel starting from the left of the front zip, going around my back to finish again at the right of the zip. This isn’t ideal as for some patterns most of the “action” goes on on my back (as that’s the nominal “centre” of the map), and it looks funny where the zips meet. Next upgrade will be to map it in 3D as a cylinder (hello again Claude 4 Opus!) and use polar coordinates so the patterns will cross the zip smoothly. But for now, here’s me doing my Christmas Tree impression…

#electronics #pixelblaze

A recommended setup for a craft cocktail bar without running water

Having taken up making them at home as a pandemic hobby, I was disappointed at the quality of cocktails available at Burning Man the last couple of years. So in the spirit of radical self-reliance I started putting some thought to how I might be able to achieve something better within the constraints of the playa, notably the lack of running water. I speculated a bit about how I might run a glass rinser (for the mixing tins) without water pressure and came up with the idea of using a hand-pumped garden pressure sprayer. After having built the contraption, I finally got to try it out at a little private festival run by some friends outside of Berlin last week:

And I’m pleased to say it worked really well! In this pic you can see the rinser on the left mounted in a modified beer crate (I needed clearance underneath for the fresh water and drain hoses), the garden sprayer underneath the bar, and behind that the slops bucket it drained into. Next to the rinser is a 200mm GN 1/4 stainless steel tub in which I mounted the (slightly modified, see below) glass brushes; in the foreground you see the bar mats and the rest of my setup including way too many obscure liqueurs and syrups.

The method was to take a cup, give it quick a dunk-and-twist in the brush “sink” (filled with fresh water and a few drops of ultra-concentrated commercial glass cleaner at the start of every “shift”), then rinse it with the rinser and set it on the bar mat to drip dry. Used jigger and mixing tins got a quick “fssht” with the rinser. If I used the strainer I could wash that off with the rinser by putting it in underneath one of the tins, spring down. Similar for the barspoon and teaspoon/tablespoon measures. I could even spray a cupped hand if it got uncomfortably sticky.

I needed to pump the sprayer a few times every two to three hours of use, and only filled it twice over the weekend. The whole setup is very economical with water.

The first time I bulk-juiced citrus I made the mistake of rinsing the squeezer in the glass rinser and lemon pulp and pips blocked the drain hose a bit. Fortunately this was easily fixable by sticking a zip tie down the drain and up the far end of the hose where it led into the bucket. That was pretty much the only technical issue with the whole setup. I had to mod the base of the glass brushes by filing a few mm off the the corners because even though it fit, the curvature of the bottom of the “sink” ran into the corners of the base which prevented the suction cups from sticking. But no big deal. Also in addition to the above I was aided by the availability of a handwashing station elsewhere and I’d definitely want to have that available when doing this.

I wholeheartedly recommend this setup if you want to run an a-la-carte craft cocktail bar without access to running water and/or drainage.

#burning man #Cocktials

A portable craft cocktail bar

I took up making cocktails at home as a pandemic hobby. I love making cocktails for my friends (and they seem to like it!) but I never had the aspiration to be an actual barman doing it down to a price and up to a pace. Smacks of hard work.

But maybe it’d be fun to do it for a bigger bunch of friends? Like, 70,000 of them? There are logistical issues. Making cocktails uses a lot of ice and produces a lot of waste water. You kind of need a sink. But what if I can’t have a sink and running water?

My intuition was that a glass rinser would be the most water-efficient way to clean the tins. But how to feed it? My first thought was a battery-operated camp shower pump. But they seem flakey; how long does the battery last, would it burn out with a mostly-closed valve upstream of it, would the famed AliExpress quality survive a week in harsh conditions? Serious marine pumps were suggested but that starts getting expensive and big batteries are a pain to keep charged.

I needed a portable, reliable, renewable source of water pressure. Hey what about hand-pumped garden sprayers? After a terrible trek about town attempting to find hose fittings that might fit the wand of the sprayer I bought, all I came away with was a positive ID of the name of the fitting on the glass rinser. If I got a barbed hose connector to male and female of the same fitting as the rinser, I could splice the hose and make the wand it came with interchangeable with the glass rinser.

It worked!

Between ordering the parts off Amazon and trying it I was worried the sprayer mightn’t be able to generate enough pressure to make the rinser work well. It claimed 3 bar which is on the low side of normal domestic supply but it turns out it’s plenty. I gave it 50 “fssht”s testing it out and then got bored, and I think I could’ve got another 50 out of it easily. So I’ll only need to pump it once every 30-40 drinks or so. Which is way better than having to charge a battery.

Given the inlet and outlet hose (which I’ll direct into a waste bucket) stick quite a way out the bottom of the rinser I’ll need to build a mount for it. I was thinking of CNC-ing some ply and making some kind of Playa-tech-esque bench with a hole for the rinser, but I think hacksawing the bottom of a milk crate might be simpler. And I could zip tie some more of those together to make the bar itself. Do they have milk crates in this country…?

#burning man #cocktails #diy #maker

The Technocolour Dreamcoat 3.0 beta

After ten years of faithful service, the Technocolour Dreamcoat 2.0 finally kicked the bucket. The silicone potting over the LED strips hardens over time and when the strip bends, the hardened silicone grips the LED chips and lifts them off the copper substrate. I replaced one glitchy strip and then identified the same problem in the neighbouring one, at which point I worked out was going on and realised it was futile.

So it was time to think about a redesign. This was great, as I’d get to incorporate a bunch of the ideas I’d had and new technology that had been released over the previous decade.

What needed improvement?

It turns out the silicone-potted strips have a lifespan. What’s new in the last few years are “pearl” LED strings which contain (I assume) 2020 WS2812 LEDs potted in little blobs of milky resin. These strings are much more flexible than strips and so will at least have a different failure mode (and I hope they’re significantly longer-lived.) They’re also light—important for a wearable!—and come in an interesting variety of pitches.

Another technology that didn’t exist a decade ago is the PixelBlaze. Don’t get me wrong, FastLED on a Teensy served me very well, but I’m not a huge fan of the “C++ in nose glasses” and “IDE that took a decade after the Retina MacBook Pro to catch on to Retina font rendering” aspects of the Arduino environment.

PixelBlaze also has a very interesting approach to LED mapping: patterns draw to a 0.0 to 1.0 line (or grid, or volume) of floats and the software re-maps that back out to the physical grid of pixels for your particular build. This means it natively supports non-regular pixel maps of arbitrary size from the same pattern code. It also supports 1-, 2- and 3D mappings, including cute arrangements like polar coordinates, which is useful for a piece like a jacket that’s essentially a cylinder. I thought that was worth trying for the trade of its “JavaScript in nose glasses” environment. More thoughts on how this tradeoff went later.

Finally, power. I was peaking at about 4A delivered by two USB batteries. But that is way, way less than what the LEDs themselves can take. I wanted the next version to be able to deliver all the power the LEDs could possibly consume at max brightness.

What worked well?

I briefly flirted with the idea of a new structure but after tearing the electronics off the jacket and washing it (for the first time in… um, let’s not say) I realised that was silly. The original jacket I’d commissioned from the fetish wear shop in Amsterdam[1] was too good a starting point to give up.

Another thing that really did hold up from the first design was the power bus. I’d had my fetish fashion designer friend run a couple of flaps right around the bottom of jacket, closed with Velcro. Through each of those I ran a length of braided copper ground strap with spade connector tabs bolted onto it (the positive bus is split in two, one half for each battery; the ground goes right around.) Wires soldered onto the LED strip’s positive and negative pads had spade connectors crimped on and connected to the appropriate power bus. This gave me a low resistance power bus and basically no voltage drop between the “first” and “last” strips.

Finally, I also liked having physical controls; namely a next/previous pattern button and a brightness pot. The PixelBlaze has a built-in web server for control, but “Wait a minute, I need to connect to my jacket’s wifi” is not something I ever wanted to have to say on the Playa.

The Design Process

I ordered 1m of 50mm pitch pearl LED string to prototype with. After playing around with them and some graph paper, I decided 25mm pitch would be perfect if I offset them in alternating rows. This gives me equilateral triangles of not quite exactly 20mm per side (but close enough for government work) and a non-rectilinear arrangement which I find quite pleasing, plus a high, but workable density. Back-of-envelope calculations with the area of the jacket gets me to about 1400 pixels total with this arrangement.

Next problem was how to attach them to the jacket. The theory about Velcroing the strips to the jacket bottom layer so they could be removed for cleaning was sound, but in practice removing 32 individual strips (and unplugging their connectors) was so laborious I never did it. Plus, the pearl strings don’t really lend themselves to having Velcro attached to them. The docs for the strings (such as they are) recommend injecting power every 100-120 pixels or so and at my chosen density that’s four rows up and down the jacket from hem to collar. So I needed “panelise” the strings in lots of four columns somehow.

I could do this on strips of fabric with Velcro sewn to their backs, which I’d then sew the strings on the front of. For attaching the strings I initially shied away from sewing (because it’s not a skill I had heretofore developed) and tried using small zip ties. This didn’t work out well; it was as slow and laborious as sewing would have been and got you a bunch of sharp edges for your trouble (where you cut the tails of the ties off.) I chose hessian (burlap) as the substrate material, originally because I thought it would be easier to get the zip ties through, but it turns out it’s also amenable to sewing with a darning needle and stout thread. Another advantage is that it has a built-in “grid” that helps me keep my strings of LEDs straight and set my offsets correctly spaced.

The build

First I drew up paper patterns for all the panels; unsurprisingly one half of the jacket is a mirror image of the other so I only had to make six. Using these as templates I drew the panel outlines on the hessian then cut them out coarsely. I have access to an overlocker at my hackerspace, so I used this to hem the panels and trim them to size at the same time. Thank you to whoever had threaded and set the tension on the overlocker before I used it, it was pretty straightforward after testing out how it worked on some scraps first.

I arranged and numbered the panels flat out on the table, being double-triple careful to ensure I had everything the right way up given half of them were mirror images of the other half. Then I outlined two things: lines on the “top” of the panel, correctly-spaced for the rows of LEDs; and on the bottom two sets of “lanes” for the Velcro to be sewn in between. I had to experiment on paper first to get the spacing right as, given you can’t hand-sew through the Velcro, the LED lines and Velcro “lanes” had to be separated properly.

Next up was sewing the Velcro. This was a horrible job, considering that I’d forgotten absolutely everything I knew about using a sewing machine in the two decades or so since I’d last done it. Winding a bobbin, threading the goddamned thing, setting thread tension—I did all of these the hardest possible ways out of pure ignorance. Sewing Velcro isn’t easy either, but made less so by the Velcro I’d bought having hooks edge-to-edge with no “hem” to sew on up each side.

But with a lot of swearing I finally worked it all out and got it done. Next came attaching connectors to the LED string. I had a bunch of 3 pin JST connectors left over from a previous build but soldering them on would have been a massive pain. So I learned about the latest thing in butt connectors: solderless butt connectors! I ordered the smallest ones I could from Amazon and they turned out to be the perfect size to connect the tiny wires on the strings (32AWG?) to the much bulkier (~24AWG) tails on the JST connectors.

I soldered the female JST onto the start of the string, then sewed it onto the hessian from the reel until I got half way down the last row, at which point I’d know what my last LED would be so I could cut the string then solder on the other JST connector. Then sew down the rest of the row. The sewing is the tedious part and took the most time and swearing. You have two choices: tie on a short length of thread and have to tie it off and the new one back on quite frequently, or use a much longer thread and have it tangle on everything from the Velcro on the backs of the panels to the buttons on your shorts as you’re sewing. In the end I went with the longer thread and being careful[2], but I still don’t have a reliable knot for tying the start and end of the thread off on the hessian. Suggestions please.

The important (and deliberate) part about this design with the panels was that I could complete the whole piece in stages. As long as I had done at least two panels and stuck them either side of the zipper at the front, the piece would be presentable and I could test it in public. Indeed its first public appearance was in that form and I took it to Burning Man with only four panels finished.

Then, there’s the control hardware and software. Available alongside the PixelBlaze controller itself is the output expander. It uses a serial protocol connection to the PixelBlaze controller and can output frames to each of the 8 connected strings simultaneously, greatly increasing your effective frame rate for 3-wire LEDs. My plan was to knock up a quick protoboard harness for the controller and expansion board and socket them in but that didn’t quite work out. The PixelBlaze pins aren’t breadboard-compatible and in addition, despite being the same sizes, the controller and expansion board’s power and RX/TX pins don’t line up. I’ve got to admit I found this kinda odd and it will make it more difficult than it needs to be when I ultimately have to design a proper PCB to mount them on alongside the power components.

But with some socket headers soldered at OCD-triggering angles I got it to basically fit together. Add some header terminals for power and signal and then it’s a Simple Matter Of Programming.

Actually before programming, there’s “mapping”. As I mentioned earlier, the PB software has a really interesting approach where patterns are programmed against an 0.0 to 1.0 line/area/volume and that’s mapped back out automatically to your actual pixel grid—which you have to specify. This can be done programmatically or by uploading a photo of your piece into a web tool and clicking on each LED, in order. This is tedious for 400-odd LEDs, but do-able.

You then take the mapping file (a JSON array of 2D points in my case) and upload it to the web interface the PixelBlaze serves. Its configuration pages can then show you previews of the various patterns that come preloaded with the system as they would look on your project. There’s a “playlist editor” where you can select which patterns will play in what sequence and with what delay, and you can edit the pattern code directly.

That is, you must edit the patten code directly. The editor is built into the interface the PixelBlaze serves over http. You can’t really create and preview a pattern on a computer then upload it to the PixelBlaze—you have to create and edit patterns on the PixelBlaze, which means you can’t effectively keep them under source control. I realise the target user might not be someone who is aware of the existence of git, but as someone who does software for a job it’s a bit of a drawback.

Next the control box. I soldered a couple of buttons and a potentiometer onto a little protoboard along with some pull-up resistors and designed a 3D printable case for it in ShapeScript (thanks to Nick for helping me out with how to do beveled edges!) Then I went to check out the APIs for changing patterns in PixelBlaze and they didn’t exist. There was only one way to change the pattern, and that was to press the button that was soldered onto the PixelBlaze board—or pull the pin it was connected to down to ground. Fortunately, Wizard was able to quickly add an API for me that allowed me to do what I wanted; I wired my buttons to some GPIO pins and everything worked great[3]!

And that’s the state it was in when it came with me to Burning Man. Unfortunately, I got one wear out of it before it started glitching out. From previous experience (it took a couple of outings to get the previous version to be reliable) I’ve determined that attempting to debug this kind of thing on-Playa is futile and not much fun, so I wore other pieces. At home I worked out that poking it in a particular place on the power bus would make it glitch but I couldn’t figure out why so I stripped the panels and power bus off and re-connected everything. It was better, but still not perfect, and for now I’m side-eyeing the power connection to the control box. Given the next phase requires a complete rebuild of that, I’m not too worried.

There are several more things to do before I’m going to count the hardware as “finished”: the most obvious is the grind of sewing and wiring the remaining eight panels. Once that’s done, I will work on…

MOAR POWER

I said earlier my goal was to be able to supply as much power as the final ~1400 LEDs would take. I know this is ridiculous but christ it’ll be cool[4]. I estimate it will draw in the region of 200W, which I plan to deliver from a couple of macho remote control car batteries bucked down to 5V via two 20A Murata OKL/T-20-W12 non-isolated DC-DC converters. I’ve had a good experience with the little siblings of these Murata parts before on another project and you just can’t get 100W out of USB battery banks—even USB-C PD ones generally top out at less than that, and even if you found one that did you’d be losing a significant amount of charge going from the internal cell voltage up to 20V then back down to 5V. However I seriously do not recommend anyone else attempt this. It’s a ridiculous idea, it’s not particularly safe, and 3A @ 5V is part of the USB-C PD spec which, times two (with a split positive rail[5]), is way more than enough to be obnoxiously bright in any situation. It’s entirely a stunt. But if I can pull it off you’ll be able to see me from space.

While we’re talking about power I wanted to note another quirk of PixelBlaze I wasn’t expecting: FastLED has a really neat feature where it will dynamically, every frame, scale the brightness of the output down to fit inside your specified power limit. It’s an estimate based on the type of LEDs you use so it’s not exact but it’s very very handy, especially for wearables. If you know your batteries can only deliver X amount of current, you can ensure your patterns are as bright as they could be without going over that. This is something which is apparently not possible due to some aspect of the design of the internals of PixelBlaze.

Anyway, to do all this I’ll need to design a custom circuit board to mount the PixelBlaze, the Output Expander, the sensor board, two Murata DC-DC converters (with edge-plated castellations), a power bus capable of delivering 20A, fuses in case it can’t and some kind of enclosure for all the above that won’t melt or set me alight. And KiCad and I don’t get along.

So that’s the state of the project right now! Hopefully I’ll see you—or more likely, you’ll see me—at Burning Man 2024.

[1] Walking past one day I saw a heavy canvas strait jacket in the window. Absent the arms and with the addition of Velcro strips sewn laterally around, it was perfect.

[2] Neutralising the hook Velcro by closing it with a strip of the loop Velcro helped, but I still ended up getting tangled at the ends of it.

[3] I added a little bit of debounce logic in software and it’s not 100% reliable, but good enough. Maybe I just need to tweak the constants, or maybe debounce is better done in hardware.

[4] I know, I know, it will be the absolute opposite of cool—even maxing out at 4A the old one got pretty warm to wear.

[5] This is very important; people warned me but my first design, where I linked the outputs of multiple USB battery packs together, fried four of them before I listened.

#electronics #Pixelblaze #Leds #burning man #wearable art

Fuck you, Oral-B

I needed a new toothbrush. My gums are a bit screwed up and my wife’s cousin (who is a dentist) recommended I get one of the new Oral B “iO” models, because it would be good for the specific problem I have. But they’re expensive and so was the old Oral B I already had, so I couldn’t justify it until my existing one broke. Which it did quite suddenly, so yay! And I started researching.

The only two features I wanted were the vibration action intrinsic to the “iO” line and a travel case that charged via USB. A battery that lasted longer than about three days (as the old one did) would be good, but if I could charge via USB I already take an elaborate USB charging setup with me when I travel, so who cares.

There are seven current models in the line, the iO 3 through 10, ranging in price from about €40 to over €300 (!!!) for essentially the same device with extra features layered on at each price point. But the thing is, almost all of those features are useless. More “brushing modes”, colour screen, Bluetooth connectivity—all pointless for 95% of people, but they deliberately segment the market so if you want an actually useful feature like a travel case, or a travel charging case (different price points!), you have to spend a whole lot of money on “pretend value” you don’t want or need to get the one feature you do. And once you put an nRF52 (or whatever) microcontroller in these things it’s just a matter of software anyway and the marginal hardware BOM cost for most of these extra “features” is approximately €0.

The Oral B marketing websites deliberately obfuscate all of this, of course. None of them explain in real English words what the differences between the models are and on top of that it’s one of those horrible product categories that’s SEO’d out the wazoo so nobody else will explain it to you either. I found exactly one third-party website which went into any useful detail what the actual differences between the models were. And only from that one was I finally convinced I’d have to shell out €200 to get the one feature over the base model that I wanted, a USB travel charging case.

So with great reluctance, because I detest being scammed like this (especially when I can see the exact nature of the scam), I bit the bullet and paid €200 for an Oral B iO 9 “Special Edition”, which came with a travel charging case and a little bag that goes in which somehow made it “special”.

It arrived, I opened the box and found… what I assumed to be a USB-C travel case had a proprietary connector and cable with a hard-wired wall-wart. I was fucking livid. I had made the assumption that the only reasonable way this could possibly be designed would be for the case to have a USB-C socket—but no, because the product development team at Oral B are maliciously insane, they had implemented a proprietary connector hard wired to a two-pin Europlug wall-wart. This entirely defeats the fucking purpose. Have none of these people ever gone anywhere? Instead of a small USB cable which literally everyone in 2023 takes a charger for with them every time they travel, they expect me to take a separate cable, with its own wall-wart, plus a power socket pin-adapter for whatever country I was going to. Utterly user-hostile product design.

I contacted the retailer wanting to return this €200 piece of useless garbage under the statutory European 14 day purchase cooling-off period. But then I was told there was an exception for “hygiene articles” like toothbrushes and since I had broken the “safety seal” (the only way to collapse the marketing bullshit wave function and determine the deficient reality of the product) it didn’t apply, and I was stuck with it.

Then I got really fucking mad.

I looked closer at the wall-wart. In 3-point regulation-mandated flyspeck, it detailed an input voltage of 110-220V AC and an output of 12V DC at 0.4A. Hm. USB-C trigger cables are a thing… but on closer inspection, 12V isn’t actually an official part of the USB-C PD spec, so it might not work on all USB-C charging ports. But you can buy USB-A cables with 12V boost converters built in and 12V @ 0.4A is 4.8W which is within the USB-A spec. Two days and nine whole Euros later (for two!) I had the offending part in my hand. I snipped the proprietary Oral B connector off and, carefully having tested the polarity with a multimeter, wired it to the USB-A 12V boost cable (“solderless” butt connectors are cool.) Then I plugged it in to the charging case.

Fuck me, it worked first time. Perfectly.

So now I have an obviously useful thing Oral-B refused to sell me because they’d prefer to soak me for useless features rather than doing the pitifully simple engineering—I didn’t even need to use a god damned soldering iron—to build something actually useful that met their customers’ obvious needs.

(As a side-note, the rest of the product design is fucking awful too. There’s an accelerometer in there which makes it wait until you set it on its end before it plays a 20 second animation before showing you the current charge level. Pointless and annoying. And that end is really small on such a top-heavy device, so you have to make sure you balance it well on its normal charger to stop it toppling over onto the tiled floor literally everyone has in their bathroom. I hope you don’t have kids who think that colour screen is cool and knock your €200 device onto that tiled floor as they go to grab it! And hey, I’ve got a good idea, let’s take an item that you use when your hands are wet and make it out of smooth plastic so it’s really slippery. That’s a fucking brilliant product design decision that’s totally not a regression from the rubberised handle of the previous version. The smooth featureless membrane buttons you can’t find just by feel, that’s an improvement too! You morons.)

Fuck you, Oral B. And fuck your marketing-over-customer-needs focussed attitude and the horse it rode in on.

#rant #toothbrushes #hacking #electronics

Scale ruins everything

I have been thinking about this for years but only recently came to a nice pithy expression of it, so I'm writing it up now.

This is not to say everything gets worse when it gets slightly bigger, but after a certain point, scale ruins everything. From hamburger restaurants to retail stores to technology companies to countries: scale ruins everything.

Would you prefer McDonalds to In 'n' Out? Scale ruins everything.

Would you prefer genuine choice and competition at specialised retail outlets, or a retail monoculture? Scale ruins everything.

How's Facebook's vision of making "the world more open and connected" (emphasis mine) going?

You might not like how they run the place, but is Singapore's government functional and are they screwing up world politics? Compare the USA. Scale ruins everything.

Short of punitive progressive tax rates on companies over a certain size or revenue and a return to city states, I don't know what to do about it.

Industry Malaise

I'm feeling a little bit of malaise regarding the computer industry right now, I have to say. And I'm not the only one:

https://twitter.com/ctp/status/1098734532386148353

All over the place I see people who got their start programming with "view source" in the 2000s looking around at the state of web application development and thinking, "Hey wait a minute, this is a mess":

https://twitter.com/seldo/status/1098222731861012481

(That one might not be the best example but it's one that came across my tweeters this week)

On the native platform side, there's no joy either. Android development is all about proving how clever you are by being able to understand an RxJava codebase; commercial pressure means even if you wanted to nobody will fund a team to build a delightful native iOS app. Outside of games and massive VC-funded services there just isn't any appetite for mobile apps. So iOS conference talks are all "How to write Haskell in Swift".

Some dedicated one-person shops are slogging through on the desktop but if Electron hasn't killed the native Mac app, it's mortally wounded. Only Adobe and a couple of others are central enough to people's workflows to get away with charging big enough subscriptions to sustain a business.

Server-side, we're at one of those "end-of-history" points too. There's no such thing as The Cloud, it's just Amazon's computer. The scutwork of migrating everything to a PaaS (or better "serverless", if you believe @swardley) doesn't get you ahead, it's just keeping up. And it's not very interesting work after you've done it a couple of times.

Blockchain is over because it still doesn't have a use case apart from ripping people off, and deep learning is eternally five years away from being useful enough to not run over pedestrians. Weaponised social networks are destroying democracy. VR was a damp squib. AR is a classic solution in search of a problem (so far, at least.)

What's the next big thing? And not in the "js framework of the month" sense, I mean what's the next technological advancement that genuinely gives humans new capabilities?

Where is the puck going?

Fifteen years ago, Apple delivered a fast, good-looking, easy to use operating system with a solid Unix foundation that ran on great hardware. Developers flocked to it and evangelised Macs and OS X wholeheartedly to friends, family and colleagues. This toehold in the market was a significant contributor to Apple’s now near ubiquity outside the enterprise.

What if Apple’s developer tools developed a reputation for being slow, awkward, capriciously broken, unfixable—and getting worse, not better?

Looking forward to Xcode 7

I'm really looking forward to the Xcode 7 GM release, but maybe not for the reason you think.

I'm looking forward to it because I hold on to some shred of hope that the egregious bugs in Xcode 6.4 will be fixed. Like the one where it crashes every time I attempt to print a variable in the debugger. Like the test runner randomly deciding doesn't want to show me my test results. Like the iOS docset that is distributed with Xcode 6.4 (not, incidentally, a docset that was regenerated for iOS 8.4) missing property definitions when viewed in Swift-only mode. Like Xcode crashing every time I open the live view debugger in an assistant editor. Like me not receiving crash reports in iTunes Connect—ever, for any build of this project.

Every time I kvetch in public about the shoddy state of Apple's developer tools I get shouted at for being a big meany and don't I know that the whole Xcode team is only four starving orphans and an adorable kitten who are trying the best they can and… sigh. I'm not talking about them. I'm not even talking about Swift SourceKit crashes or any of that—Lattner and his team are doing an awesome job.

The problem I have is that the world's most valuable company is under-resourcing the teams that produce the tools that I rely on as a professional iOS developer. This wastes my patience and our clients' time and money. The "beleaguered" Apple of yore could get away with this, when the developer community was smaller and more forgiving. But in 2015 Apple owns a mature platform where serious work central to hundreds of thousands of businesses is being done by large teams on large projects with long time horizons. They don't get a pass anymore.

Yes I file radars. Yes I know who Fred Brooks is. I know this is not a simple problem to solve. But a company whose reputation is founded on producing better quality software is now the biggest company in the world. It should start behaving like it.

Stop building shitty web “apps”

Stop building shitty web “apps”.

It is impossible to build a cross-platform app as fast as a native app. Even if you succeeded, you would end up deep in the maddening “uncanny valley” of UI where your users get to play “guess what this custom control does?” and two finger swipe zooms instead of scrolls like it should. Building with the platform-supplied toolkits and libraries means you have to go out of your way to make those kinds of mistakes.

The original reasons web apps made sense generally don’t apply anymore. In 2015 you’re better off focussing on one platform (probably iOS) to prove your concept—if you get any traction, then spend your time and money building out on another. This way even if you do fail, you won’t be kept up at night wondering if the product was any good and it wasn’t just the shitty least-common-denominator implementation people hated.

“But Robert!”, you cry, “Widespread adoption of my product has significant network effects and I can’t afford to build three or four client implementations before my startup’s runway runs out!”

Well DON’T BLOODY DO THAT! If this describes your situation, you should be publishing a protocol, not building a product. I am sick to death of Silicon Valley vulture capital systematically enclosing the commons in order to capture 10s of billions of value for themselves instead of allowing open standards to unlock 1000s of billions of value for everyone.

Of course there is still a place for the web as it was originally conceived—as a vehicle for publishing structured, hyperlinked information, mostly text. Forcing users to deal with your slow, awkward and buggy re-implementation of their perfectly good client platform is a poor alternative to learning how to build proper native applications in the first place.

Web “apps” are 90s bank and insurance companies’ fault

It was the "Nobody got fired for buying IBM Microsoft" attitude of corporate IT departments that got us the Windows hemogony in the 90s. The security nightmare precipitated by the Microsoft monoculture (remember Word macro viruses?) led those same IT departments to lock plebs' desktops and networks down tight.

The Cambrian explosion of the web in the early/mid 2000s was in part an end-run around corporate security policies which made it impossible to get any interesting or useful software installed on your computer—you didn't have to install anything to use the web. But the locking down of the network meant everything got tunnelled over port 80 whether that was a good idea or not.

And this goes a long way to explaining why I'm sitting in a cafe in 2015 fighting broken web "apps" that use megabytes of ill-concieved javascript frameworks to incorrectly re-implement native platform behaviour and I can't push to Bitbucket because port 22 is blocked on the wifi.

RFCs not IPOs

There are many problems with the way we're doing one-to-one and one-to-many short message communication over the Internet right now, but making a bunch of slimy venture capitalists rich isn’t one of them. So try and understand what the real problems are before writing another VC-funded, walled-garden messaging platform:

If it’s not cryptographically secure, end-to-end, everyone from the NSA to 4chan is going to fuck with your users. This is not acceptable in 2015.

If it has investors, commercial pressure will force you to make the user experience shitty (see Twitter) or sell your users out to someone who will (see WhatsApp.) If you can’t find a bigger fool to sell to, you have to close down and the users are left stranded.

If it’s any kind of centralised (even federated) system it’s vulnerable to government, spook, corporate or hacker manipulation and shutdown, probably at the instant it’s most sorely needed.

By their very nature, proprietary, centralised, VC-funded, walled-garden platforms can not solve these problems. Even well-intentioned ones with pretty websites. Why is email is still going strong after 45 years? Ugly boring standards which allow anyone to write their own implementation and interoperate with everyone else on the Internet.

I love Twitter but I fear commercial pressure (see point 2 above) will soon force it to become something I don’t love or else go away entirely. I believe that in 2015 we have the capability to design and implement a protocol that will give us a secure, distributed, Twitter-like service with the side effect of making shitty proprietary walled-garden messaging platforms redundant.

I want a few core elements:

Identities are simply public keys, managed in a distributed web-of-trust system similar to keybase.io.

Strong, end-to-end cryptography for both authentication and privacy. Public messages you send are signed with your private key to authenticate their source and prove their integrity, private messages are also encrypted under the recipients’ public keys so they are secure in transit.

Completely distributed, peer-to-peer operation. Client software stores-and-forwards received messages, possibly earning some kind of proof-of-work credit to prevent “cheating” clients leeching or otherwise harming the network.

All of the above is documented in an RFC anyone can use to implement a client for their favourite platform—open or closed source, Free Software or proprietary.

I have never been part of a standards committee, nor am I an expert on the theory or practice of the necessary crypto. But I would very much like something like the above to exist.

And with a bit of luck, it might help usher in a new age of RFCs over IPOs.

“Are you getting it?”

Consider the sequence of events:

From the point at which Steve Jobs returns to Apple, the company begins minimising its developer ecosystem's dependence on external suppliers. Metrowerks CodeWarrior is deprecated in favour of Xcode; Xcode's underlying gcc compiler is switched out for LLVM, the PhD project of one Chris Lattner, now Apple's Director of Developer Tools.

Moore's law begins to break down generally while benchmarks such as MIPS per Watt become more important, especially in the context of battery-powered mobile devices.

Apple buys PA Semi, a chip design company specialising in low power RISC and ARM designs.

Apple's development environment gains features like Grand Central Dispatch and blocks, facilitating increased performance on multi-core processors for parallelizable tasks.

Apple releases the iPhone 5S powered by the in-house designed A7 system-on-a-chip. Containing 64-bit processor cores, it catches the rest of the mobile device industry flat-footed.

Apple announces Swift, a new multi-paradigm language interoperable with Objective-C but with many features that make functional programming easier. Writing functional code helps realise performance gains on multi-core architectures.

Apple casually drops another core into the top-of-the line iPad model, giving it a 40% performance improvement for multi-core tasks over the previous generation.

Can you see where this is going? Are you getting it yet?

Apple's plan for increasing performance in a post-Moore's Law world is multi-core. Swift is “stealth Lisp” so that the functional-style programming we're conditioned into doing will be able to take advantage of the massively parallel SoCs Apple will be embedding in their products by 2018. Coupled with the industry-leading chip design skill they have in-house, they're placing their products on a performance trajectory that will exponentially outpace the rest of the industry over the next few years.

Just wait and see what happens when they build their own fab.

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!

#technocolourdreamcoat burningman

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.

Trending Blogs

Recently Viewed Blogs

Frabjous Dei