Wed, 13 Mar 2019

Replacing the battery in a mid-2012 Retina MBP

— SjG @ 8:17 pm

I bought my MBP back in September of 2012, and it’s been the best machine I’ve ever owned. Named Apotheosis, it’s quiet, powerful, good battery life, and all that. It’s been through four or five iterations of MacOS, and still runs fast. It’s got old-school USB 3 ports, an SD card reader, and the mag-safe connector. In short, the only thing I could hope to improve it would be more storage.

Of late, however, it’s been exhibiting power issues. It will log itself out, or spontaneously go to sleep and not wake up without external power. I reset the System Management Controller (SMC) by the arcane ritual of holding down Shift, Control, and Option on the left side of the keyboard, then holding down the power button for 10 seconds. No luck.

Then, there’s some minor issues with the screen; small areas that look almost like fungus in the display. From what I’ve read, this has affected a lot of older Retina displays, but in my case it’s more an annoyance than a serious problem. Still, given these two issues, I thought perhaps it’s time to upgrade. After all, the machine’s over six years old.

Looking at the new MacBooks and MacBook Pros, though, I can’t find anything that would be satisfactory. Certainly nothing at a price-point that I feel like paying. I’m not a big fan of the new keyboards, and if you want to put a lot of storage (i.e., 2TB) in a machine, Apple really makes you pay. Resolved, then, try to get more years out of Apotheosis. Apple no longer services this model, and the indy/Authorized dealers wanted $500 to replace the battery. That seemed high to me.

Other World Computing has a replacement battery kit for $85. I ordered it, and it arrived overnight! In big red letters, they warn that “Professional Installation Highly Recommended” but people like me don’t pay any attention to such things.

Back cover removed

The kit comes complete with Torx screwdrivers specifically for the MBP, including the (in)famous “pentalobe” driver.

They also supply a step-by-step video for the process. This is a really outstanding instructional video. It shows everything in perfect detail. Things which sound simple in words (e.g., “unclip the connector”) are often not so clear when staring at the physical object. But watching each step makes it very simple.

That being said, they estimated two hours to do the process, and it took me more like three. Part of that was my obsessive disassembly process which I’ve perfected over the years. It involves lots of post-it notes, with little drawings and sticky tape that I use to make sure I can reassemble things correctly. In this case, the video would have been sufficient, but old habits die hard. And, frankly, this is a good habit.

Even thought OWC makes this a straightforward process, Apple certainly didn’t intend it to be. You have to remove the speakers to really get at the battery. To get the speakers out, you basically have to remove all the guts:

Ready for battery removal
All The Innards… haruspices take note

The kit includes a gnarly solvent that helps dissove the adhesive holding the battery in place. This is the worst part of the process, although they provide gloves and eye protection to make it a safer process.

Once the machine was back together, I went through a full charge/discharge cycle, and it’s seemed quite stable. There are some weird minor discrepancies. For example, while writing this post and doing some other odd chores, I’ve been unplugged. The menu bar battery gauge tells me I’m at 81%, while CoconutBattery tells me I’m at 77.6%.

With any luck, this repair will help me keep Apotheosis up and running for a few more years!

Wed, 2 Jan 2019

Using Makefiles for Teensy Development on Mac OS

— SjG @ 9:24 am

Even if you don’t want to use the Arduino IDE for building your application, or want to do fancy things that only the evil, convoluted syntax of Makefiles can provide, you can do Teensy development on the Mac from the command line. While there are a lot of guides out there on how to do it, I hadn’t seen a complete step-by-step set of instructions.

So with no further ado, here are the steps for building Teensy applications on Mac OS using the Makefiles and the mighty command line.

  1. Download the Arduino IDE from and install it.
  2. Download Teensyduino from and install it.
  3. Download a “basic project template” for Teensy. The original is at but I’ve been using the fork at which has been updated more recently and uses the Teensy CLI Loader for uploading to the device.
  4. Update the Makefile to set your Teensy model
  5. Type make to build, or make upload to install on your Teensy

If you’re wanting to monitor the serial console of your Teensy over USB, install a terminal program like CoolTerm. Alternatively, if you use Homebrew or MacPorts you can use a console-based terminal program like minicom. Once the USB connector is plugged in, your Teensy will show up as something like /dev/cu.usbmodem45504901. The communications settings will be 115200 baud, 8 bit, no parity, 1 stop bit.

Tue, 1 Jan 2019

WordPress Editors

— SjG @ 11:18 am

I have WordPress automatically updating itself and its plugins using a cron job that uses the magical Word Press CLI. Overall, I’m pretty happy with it. But then, one day, the latest version installed, and my “editing experience” has gone to the new Gutenberg editor.

Now, like all creatures of habit, my first response was “what?!” As I’ve written before, I resist changing things that are otherwise perfectly functional. But then I thought it was an opportunity to work on maintaining that brain plasticity and build some new neural connections. Instead of immediately installing the plugin that allows me to keep the old editor, I’d give the new one a try.

Initially, it did not go well.

I saw the new interface, but the little button to add blocks was grayed out. A single “Title” field and “Text” area appeared, and I could enter data into them, but I couldn’t add new blocks. The javascripty-pop-ups didn’t.

So I looked at the JavaScript console, expecting to see an error from a misloaded source file or some bug. Nothing. I clicked around the interface like an increasingly frustrated monkey for a while, and got nowhere.

Turning to the interwebs for support, I didn’t see much that was helpful. This thread and this one both talked about issues and solutions, none of which seemed to apply. My server is sending proper headers, I don’t have any weird plugins, etc. I checked my user profiles, and they were set to use “Visual Editor.”

It was this last item that was indeed the culprit, though. Unchecking the “Use Visual Editor” and saving my profile, then rechecking the “Use Visual Editor” checkbox and saving my profile fixed things. How fucking annoying. Get out of the car, get back in the car.

In any case, I’m getting used to Gutenberg. I can’t say I like it more or less than the previous editor.

Wed, 8 Aug 2018

Building Kannel 1.4.5 under CentOS 7.5

— SjG @ 1:05 pm

Well, it’s been a few years since I’ve had to build Kannel (see Compiling Kannel under CentOS 7.0), and a server migration required that I figure it out again.

You can find discussions on why Bison v.3.0 or later, standard with modern versions of Linux, prevents compilation from succeeding. Some discussions provide workarounds that I couldn’t make work.

Here’s how I downgraded Bison and built a working Kannel 1.4.5 binary on CentOS 7.5:

$ cd /usr/local/kannel
$ wget --no-check-certificate
$ tar xzvf gateway-1.4.5.tar.gz
$ cd gateway-1.4.5
$ sudo yum downgrade bison
$ sudo ./configure --prefix=/usr/local/kannel --disable-wap --enable-start-stop-daemon
$ sudo make
$ sudo make install

In that downgrade step, Bison was rolled back to version 2.7-4.el7. If you’re doing this at some indeterminate time in the future, the downgrade may be to a 3.x version, in which case you’ll want to downgrade until you’re at a 2.7.x version (also, if you’re at some indeterminate time in the future, simply check your watch and it will be roughly determinate again).

Sun, 20 May 2018

Moving away from Aperture

— SjG @ 7:39 pm

I’ve finally moved away from Aperture.

I thought I’d share a few thoughts.

Back in the day, when I was still largely shooting film and occasionally scanning prints or negatives, I organzied things by directories. I’d have descriptive names like “hike_at_paseo_miramar”. Over time, this became unweildy, and I had the startlingly brilliant and utterly original idea of organizing by date as well, so I had a directory the looked like:

-> 1997-08-02
-> 1997-08-04-pasadena
-> 1998
—> 1998-02-01-hike
—> 1998-02-07-beach

You can see the problem. I found I could keep this going by using Adobe Bridge, but I needed a better system. For a while, I organized my pictures on a web server with a cobbled-together collection of perl programs. That was manageable for about two months. Eventually, I tracked down some novel software to organize photos: iView Media Pro. It used the now-familiar idiom of folders (which represented physically where they were on the disk), virtual albums for grouping, and keywords.

iView was great until it wasn’t. The company didn’t have the resources to support it to the degree it needed, and occasional bugs (like the one that wiped out keywords for a few thousand pictures) were frustrating. When the product was sold and the team migrated to Microsoft, I figured it was time to move on. I went with Apple’s $300 “Professional” product: Aperture.

I had to write some code to export my keywords and organization from iView into Aperture, but that left me with a system that worked. It served me well for ten years. For the last two of those years, a cloud hung over me. Apple end-of-lifed the product, and, while it continues to run, did not get any new features or bug-fixes. With each new version of Mac OS, there was the risk that I’d no longer be able to run it.

I did a trial of Capture One, and was impressed with the RAW processing and the workflow. Where it failed for me, though, was in the cataloging. At this point, I had about 55,000 photos in my catalog. Because I like to have them all “with me” at all times, I kept my library on my notebook. I realize this is a strange requirement for most people, but I like the ability to bring up a collection of pictures from a given trip or a given event when I get together with someone else who participated.

Capture One had a hard time keeping up with that many photos. I considered breaking the catalog into separate, smaller collections, but was still resistant to any little impediment to finding the picture I want at a given moment. Ironically, Phase One, the company who creates/sells Capture One has acquired iView Media Pro from Microsoft somewhere along the line. I contemplated moving back to it, but realized I’d need to get that, plus a RAW-processing package, etc, and decided against it.

The 10,000 ton elephant in the room, of course, is Adobe Lightroom. It dominates the photo processing/organizing space. I didn’t want to move to it because of the software subscription model. I don’t want to be beholden to Adobe for all eternity.

Still, after trials of several products, I have been forced to surrender. Lightroom is the only product I could find that worked as well as Aperture.

Lightroom will import Aperture libraries, but the non-destructive editing from Aperture does not come across. Some adjustments might, a lot of metadata will, but those painstaking edits do not. I invested in ApertureExporter, which helps the export process by building a copy of the catalog, and creating extra copies of edited images where it “bakes in” the changes. So you’re left with the original (in case you wish to re-edit), and a JPG or TIFF version with all your changes. I left to run all night, and the result was a nice clean export.

Importing into Lightroom was not difficult. It was interesting to see all the cores of the CPU go to nearly 100% utilization while LR generated previews. I opted for large previews (typical screen resolution). This allows me to have the versions to show off to people (as I mentioned above) while keeping the originals on an external drive that may or may not be attached at any given moment. LR has something called “smart” previews that you can even edit while offline. I didn’t think it made sense for me, but I may revisit this decision later.

I was graciously given a nice tutorial on the basics of using Lightroom by Tomas Fjetland, which helped get me up to speed.

Some observations. Some things in Lightroom are much easier than in Aperture. Lens correction is a single click, instead of requiring a separate plugin. Some things in Lightroom are harder. Having separate panels that you have to switch through for “Library” functions (cataloging and managing keywords) and “Developing” (adjustments and edits) seems unnecessary, especially as the switch doesn’t really result in more efficient use of screen real-estate. Tagging keywords requires a lot more clicking. An auto-completed keyword requires one hit of the return key to accept the auto-completion, and a second hit to apply it to the image.

I’m still pretty slow at the editing tools, and the paradigms are not identical. All that old muscle memory in my fingers is slow to retrain. Overall, I’m pleased with some of the results I’m getting, but it will still be a while before I’m as quick or adept at Lightroom. No doubt I’ll revisit this posting at some later date.