Per-App Cellular settings

Quick/useful post (hopefully).

I have a friend - let's call him David because that is in fact his name - who dabbles in iOS app development. As we're been friends for about thirty years or so I often gamely volunteer to test out whatever he's working on. Not every app actually makes it all the way to completion (and even then only a couple have made their way to the App Store), largely because he has another actual job and has the kind of work ethic that would make Thomas Edison look like he was just phoning it in every day.

iOS is great about memory management and graceful resource use on well-written apps. It's not so great when you're running a very rough approximation of an app, and your battery life and cellular data bill can reflect that accordingly. Quitting an app in iOS isn't a big deal, but it can be advantageous to prevent an app from using Cellular data. It takes a little digging around, but can be done thus:

First fire up the Settings app:

...then scroll down and selectively turn on/off cellular data for each app:

Et Voila! My friends Apps are way down the list and not revealed (to protect the innocent and also myself from the endless barrage of abuse that he'd doubtless hurl at me), but since tweaking those settings I've noticed some appreciable bumps in battery life that have made my role as a test subject a little easier...

Backblaze Q2 reliability

Ask a dozen IT folks what they recommend for internal storage and you'll probably hear a dozen different answers. Most of us have - at one time or another - been burned by one particular company more than another (I've had some truly horrendous luck with Seagate drives but others swear by 'em), so it's always fascinating to read some tangible, unbiased real-world breakdowns about drive models and reliability.

Backblaze (an online backup service that those same dozen IT folks will probably unanimously endorse) is - as far as I can tell - the only company who shares details of their storage infrastructure and the uptime/failure of their drives. It's well worth a read - they publish their current information on a quarterly basis, and it's always fascinating to check in and see what brands and models are holding up over time (and which aren't)

Certification Uncertainty

Seth and I have been lax in keeping up with our shots of late. We've been busy (which is a good thing) and thus only just got around to taking the El Capitan ACSP tests (which - while not bad - certainly isn't *great*). Neither of us has really been sweating that though; my certifications stretch back to 10.4 and his go even further back to 10.2, and one of our most significant office decorating problems is finding frames and wall space for all the certifications we've accrued over the last few years (currently twenty-nine, although there's also the matter of the six that are so old that we can't get copies any more).

Still, while it's fun to humblebrag about how well-qualified you are and to moan about how you don't have room for all your awards, there is a genuine issue looming. The way we were able to accrue all those certifications was by taking courses for both OS X client *and* OS X Server. The OS X client exam (the ACSP) is designed to demonstrate a high level of technical competency in the fundamentals of understanding and troubleshooting OS X. The OS X Server exam (the ACTC) built on that and delved into the Server product in a deeper and far more comprehensive manner.  The ACSP certification was a prerequisite of the ACTC, and if you had the two of them then it was pretty clear that you Knew What You Were Doing.

This was all very well until earlier this year, when Apple quietly phased out the ACTC test. Nobody I've talked to seems to have a concrete explanation for this; the best that I heard was straight from a fairly senior person at Apple who opined that in the spirit of openness there would be an effort to encourage different, wider ranges of qualifications and use those as a means of demonstrating expertise. That actually made a lot of sense, but so far that doesn't seem to have appeared in any tangible form.

What has appeared is the Server Essentials 10.11 course material and book - which is, in effect - everything that you would have expected out of the old ACTC certification materials. It's pretty rad, and while there's nothing massively different there from 10.10, it's a great book and does a good job of catching up the thousand and one small differences that Server 5.0 brought to the table. 

All that's needed is a certification to go with it. I don't really need any more certificates on the wall (see earlier whining re: frames and space), but it'd be nice to be able to have something to demonstrate that we've reached a proficiency in the server version of the operating system.

And so we wait...

Excess Baggage

I carry a bag around with me all day long that contains the following items:

1) Laptop

2) Notebook & pen

3) Water bottle

4) Business cards

5) Leather pouch full of cords

This - as far as I can tell - is pretty much par for the course for your average free-wheelin' IT consultant. The quest for the perfect bag is a minor obsession; I like messenger bags but I've never found the equal of the no-name brand ones I had about ten years ago, which were essentially nice Timbuk2 knockoffs that cost about fourteen bucks each.

Space is something that's always at a premium, so while I used to haul around a toolkit for all my assorted bits and pieces I've found it easier to replace that with the leather pouch. That works great, but the problem is that organization of the contents of said pouch is impossible, and I occasionally lose stuff. Nothing major; a USB-Ethernet dongle here, a spudger there, but there's definitely stuff attrition.

The trick, I've found, is to minimize the amount of stuff you carry around with you. Replace external USB drives with thumb drives that you keep on your keychain with your car keys and you'll never be able to drive off and leave something important behind. Trimming down the fat is the only way to stay efficient, which is why it's puzzling to me that Apple is reportedly ditching the headphone jack on the iPhone 7 and replacing it with a headphone to Lightning dongle.

They've done this before. Back when the original iPhone shipped you were obliged to find an adaptor if you wanted to use third-party headphones with your new iPhone; the recessed jack was perfectly-sized to fit the headphones that came with the phone but a fraction too narrow for anything else. The original headphones were - and there's no beating around the bush on this - crappy beyond belief and if you had big ugly ears like mine they were either going to fall out or have to be jammed in place uncomfortably. It was a design misstep that was quickly corrected, which is why it's puzzling to me that it's something that they're allegedly replicating for the new phone.

I've no doubt that the adaptor will come in the box, or that Apple will happily sell you a new one for - let's say - twenty bucks or so. That's fine, I suppose - twenty bucks is probably an outrage for what the thing actually costs but I figure enough people have twenty bucks that they can afford a replacement if they lose the adaptor. What isn't fine is that Apple is essentially requiring you to use an adaptor in order to use the product that they're selling you. It's a move that obviates the idea of working right out of the box and stands between the user and the rest of their gear.

It's a roadblock. Not a big one, nor an expensive or even poorly-designed one, but a roadblock nonetheless. I'm sure they'll ship Lightning-compatible headphones (although I'm deeply skeptical about whether there's any real improvement in sound quality) or that we'll all soon be embracing bluetooth going forward, but for now it just makes me sigh and shake my head. I may or may not ever own an iPhone 7 - after all, I upgraded from my iPhone 4 only because the thing died, and I'd go back to that size and form-factor in a heartbeat - but if I do then I know in my heart of hearts that the first thing I'll have to do is go and buy a bunch of adaptors, secure in the knowledge that they'll disappear and that I'll be unable to use my fancy new phone with my nice headphones without them.

One Billion.

"Cupertino, California July 27, 2016 - At an employee meeting in Cupertino this morning, CEO Tim Cook announced that Apple recently sold the billionth iPhone."

That's pretty remarkable for a product line that's only been in existence for nine years. Further, according to rough, back-of-a-napkin math Apple has about 110 million Mac sales under it's belt. Ever.

It's easy to see why Apple is evolving into more of a services and mobility company, and why technologies like profile management and concerns about security and transparency are moving to the forefront of what the company offers and where it's going.

MAC address changes on the Mac

Firstly, that should read "MAC address changes on the Mac". While this blog makes headings look super neat and keen, it does tend to CAPITALIZE EVERY THING which can be annoying.

Anyway, back to business. I have a client who does some sensitive work of a sensitive nature with a large California-based company in the services sector. They are, as one would suppose, sensitive about security to the point that their internal access tool for vendors requires installing an unpleasantly intrusive client-side app that not only checks credentials/authentication, but also scans the MAC address of each connecting machine and matches that against a database prior to allowing/refusing access. I'm not sure whether that genius or hamfisted evil. 

Either way, it's pretty impressive - but can create a problem if oh, I don't know, maybe you dropped your MacBook Air down a stairwell and it turned out to be sensitive to massive inertial damage. Which is exactly what happened. Thus, said client was now unable to remotely access the data she needed to get as her new Mac's MAC address was - as is the nature of these things - different to the old one. Her customer's Helpdesk weren't technically very helpful. They gave her A Ticket and said that they'd get back to her in a few days. Right.

ifconfig to the rescue. I love ifconfig. It's the general-purpose utility for controlling and monitoring the state of every I/O port on the Mac, and next to nettop is probably the most useful go-to tool for this kind of problem. It seemed natural that this would be the best place to look, and as ever it didn't disappoint.

It turned out that spoofing a MAC address was terribly, terribly easy. Note: you can spoof a MAC address but you can't actually change it in hardware. To spoof it, all you have to do is use ifconfig to identify the interface that you want to spoof on (usually just en0) and then:

sudo ifconfig en0 ether a1:a2:a3:a4:a5:a6

Et, as they say, voila. As far as the server/client tool was concerned the new MacBook Air shared the same MAC address as the old MacBook Air, and she was back in business. Now there was just the matter of pulling all the other data off of the old destroyed MacBook...



When it comes to loading and working with with third party APIs for your car, it kind of goes without saying that there are some caveats to be considered. For one thing, Tesla's servers don't take kindly to being spammed into oblivion if your computer decides to be a Chatty Cathy - if you're sending a ton of requests on a constant basis then that'll put a load on the servers, and they'll probably respond by blocking your IP address. Secondly, you're tinkering and tampering with a big, heavy, complicated and expensive machine, so consider what you're doing and don't decide that it'd be neat if you could heat your house by cranking the temperature up on the heater and leaving all the doors open or something equally asinine. You should exercise common sense regarding activities that might reduce the efficacy of the battery or other systems of the car.

Also remember that if you're tinkering with the locks and remote starting the car then you're also practically rolling out the red carpet for someone to steal your car. It's perfectly possible for me to be in my office and remotely unlock the car and start it up so that any passerby could just get into the thing and drive it away. I don't do that because that would be dumb, and I'd hope that nobody else would either.

With that out of the way, let's get on to the good stuff.

You'll need some kind of environment that'll allow you to access the REST API. There are some ways of doing it in Python (which is very tempting), but the simplest method is to use a Javascript runtime like nodejs. That can be downloaded from

Once that's installed you'll use the npm to install the Tesla tools, thus:

Sudo npm install -g teslams

Every time you query Tesla's servers you need some kind of authorization. On the car (and on the official client) that's handled with an oauth token, but the simplest way to handle authentication in this case is to just use the raw credentials. Yes, I know it's a bad idea. 

There are a bunch of commands built into the API and there's good documentation out there about what it all does (see here for a good rundown). Each requires a -u username and a -p password flag. I don't really want to be able to unlock the car or flash the lights, but it might be nice to have a simple way to see how much charge is in the thing, so I added this line to my .profile (credentials changed for obvious reasons):

alias charge='chargebar -u -p mysupersecretpassword'

Firing up Terminal and typing in "charge" gets me this:

...which is pretty neat. Now I just have to find the time to get that data periodically pulled down into a .json file so that I could throw it up on something like Panic's StatusBoard...


I bought a Tesla Model S a couple of years ago, and have only recently started shutting up about it. This has been a herculean effort all things considered because it's absolutely the most incredible piece of tech I've ever owned. Sure, the iPhone is pretty remarkable and you can make a lot of solid arguments about the value of the personal computer of your choice, but can those things make you giggle like a five year-old on a regular basis as you mash the accelerator down and feel gravity put its hand on your face and push? No.

Also, it's pretty and well-designed and comfortable and roomy and... I'm doing it again.

As it's a nice modern car with all the bells and whistles and connectivity that you could hope for, it's also stuffed with gadgets and gizmos that report who you are, where you're going and what you're doing. Every time someone crashes their Tesla and claims that Autopilot made them do it Tesla invariably releases a statement an hour or two later to the effect that they looked at the data from the car and can definitively prove that the person had their hands on the wheel or just hit the accelerator instead of the brake. They're able to do that because the car continuously records speed, location, altitude, temperature, what systems are engaged and disengaged and reports that all back to Tesla's servers. It would be creepy if it wasn't so neat.

And if it wasn't open. You see, the really neat thing about that data is that it's not just locked away for Tesla's own digestion and enjoyment; while the official Tesla API is still under lock and key there are plenty of other ways to get at that data. There are a few excellent iOS apps that will give you access to the controls of your car (some allowing things like Summon, which will wake your car up and make it drive to you), and a couple of excellent third-party Mac apps that will allow you to look at and control some of the more elementary functions of your car, such as VisibleTesla

What I'm after, however, is something faster and more command-line accessible, so I'm going to spend the next couple of posts running through what's required to get quick access to some essential information and functions through the Terminal on OS X. 

Of course, if I mess it up then it's not like I'll brick my car. At least, I really hope not...