Category Archives: General

Radiohead

I caught Radiohead at TD Garden last night; they played a really great set:

  1. Daydreaming
  2. Desert Island Disk
  3. Ful Stop
  4. 2 + 2 = 5
  5. Myxomatosis
  6. All I Need
  7. Videotape
  8. No Surprises
  9. Everything in Its Right Place
  10. Bloom
  11. Separator
  12. Reckoner
  13. The National Anthem
  14. How to Disappear Completely
  15. You and Whose Army?
  16. There There
  17. Street Spirit (Fade Out)
  18. Optimistic
  19. Nude
  20. The Numbers
  21. Lotus Flower
  22. Fake Plastic Trees
  23. Idioteque
  24. Exit Music (for a Film)
  25. Karma Police

iOS FLAC Playback

With the release of the iPhone 8 and iPhone X, Apple added support for FLAC playback. Kirk McElhearn wrote:

But I looked at the iPhone 7 tech specs, and it also says that it supports FLAC, so maybe Apple just means that the files can be read by third-party apps. If FLAC were natively supported on last year’s phone, a lot of people would have heard about it. I think that this has something to do with iOS 11. Because I looked on an older version of the iPhone 7 tech specs page (via the Wayback Machine), and FLAC support is not mentioned.

I maintain an app that plays back local files, and as of the initial release of iOS 11, I couldn’t find an API for facilitating playback of FLAC files. I asked on Stack Overflow; the question received a fair amount of traffic, but no clues.

The other day, I realized that my app is able to playback FLAC files with no changes to my code. It appears that, as of iOS 11.2, the isPlayable property of AVAsset returns true when backed by a FLAC file.

It’s nice to see that Apple has made this functionality available to third-party apps with no extra complexity.

homebridge-camera-rpi

With the recently released homebridge-nest-cam plugin, my old Dropcam has new life in HomeKit. This, combined with Steve Troughton-Smith’s tweets about the Pi Zero W, has sparked a desire to setup additional HomeKit cameras.

I ordered a Pi Zero W Camera Pack, and set about following Wojtek Pietrusiewicz’s instructions for configuring it with homebridge-camera-rpi.

It was easy to get the Pi connected to the network, but I ran into trouble when I needed to install ffmpeg. I couldn’t get it working, and based on some comments, I think it may be fairly difficult to install. I’m speculating that something changed between the Rasbian Stretch image of November 2017 and the image of March 2018.

Instead, I used the pre-built image of homebridge-camera-rpi. After using Etcher to flash the image onto my microSD card, the only modifications I made were to the /wpa_supplicant/wpa_supplicant-wlan0.conf file to add my network SSID and passkey, and to tweak the settings of the plugin in /homebridge-camera-rpi.conf.json.

With that, I was able to see the Pi on the network (via Lanscan), and add it in the Home app.

Home App Screenshot

Transporter Desktop on High Sierra

If anyone out there is still using the File Transporter system, there’s a compatibility issue with High Sierra. The last version available via the official update channel is 4.2.12, but there’s a patch for version 4.2.18 available from their support site. This restores access to the Transporter Library.

This issue reminded me that support for this system ended in September, 2017, so I’m on borrowed time. I just upgraded to the 2TB storage plan on iCloud, so I may test migrating the data I have on the File Transporter into iCloud… but that seems risky.

Python 2.7 via Homebrew

I missed the memo, but back in January Homebrew announced that as of version 1.5, python would be upgraded to use Python 3.x. This change went live on March 1, and I noticed it over the weekend while tinkering with Homebridge.

While I was rebuilding Homebridge with the latest version of Node.js, I kept banging into node-gyp errors having to do with using Python 3.x. I’m not alone, though there is already a pull request to fix this issue.

For the time being, I’ve made two changes to please node-gyp:

  1. Forced a link of the new python@2 keg1:

    brew link python@2 -f
    
  2. Added the following to my ~/.bash_profile, so that python will point at python2:

    export PATH="/usr/local/opt/python@2/libexec/bin:$PATH"
    

I think I’ll revert the second change once the node-gyp issue is resolved, to begin forcing myself to use Python 3.x.


EditorConfig

Yesterday, I lamented the limitations of BBEdit’s Dropbox sync:

I wish there was a way to sync language-specific settings for BBEdit via Dropbox.

Specifically, I wanted to sync my soft-wrap settings for Markdown files. My main need for this is in editing the text files that drive this blog1. Yes, this is a trivial problem; it’s one checkbox in BBEdit’s Preferences Pane. It would be easy to recreate on both of my computers. It would be easier still if the preference would sync.

@daiwei replied on Micro.blog with an interesting idea:

If you know where the settings you want to synchronise are stored, simply copy that file(s) to where you want them on Dropbox, and symlink it/them?

I haven’t tried this, and I’m afraid of what might happen if I were to have BBEdit open on both computers at the same time. Maybe I’d just end up with conflicted copy files from Dropbox, but BBEdit’s release notes specifically call this out as unsupported:

The system does not support relocation of the core preferences data file (~/Library/Preferences/com.barebones.bbedit.plist), so you won’t be able to synchronize preference settings.

The BBEdit support team replied to me on Twitter, and offered a solution I was completely unfamiliar with:

Apparently, BBEdit natively supports EditorConfig files. EditorConfig files are used to enforce consistent configurations across editors for a given project, and they’re fairly widely supported. While soft-wrap settings aren’t part of the core properties, BBEdit has defined BBEdit-specific keys, including x-soft-wrap-text, x-soft-wrap-mode, and x-soft-wrap-limit.

Based on this, I created an .editorconfig file in the root directory of the files for this blog, that only contains one key:

# EditorConfig is awesome: http://EditorConfig.org

# top-most EditorConfig file
root = true

# Soft-wrap every markdown file (in BBEdit only)
[*.md]
x-soft-wrap-text: 1

Now, if I ever forget to enable soft-wrap as a language-specific setting in BBEdit on a new machine, this file will override the global setting and enable soft-wrapping. I’ll still have to deal with this for files in other directories, but this will cover 90% of my use cases.


  1. I’m still publishing this site using Dr. Drang’s WP-MD tools. 

Thoughts on Publishing a Workflow

I published a Workflow.app Workflow a while back, and I was surprised to learn that, before the app is ‘accepted’ for publication, the Workflow team may edit your workflow.

The Workflow team confirmed this on Twitter:

This has been on my mind for a while, and my feelings are still conflicted:

  • They didn’t tell me that they made changes, but the workflow is still attributed to me when you access it. This feels like a misrepresentation of my work.
  • They actually improved the workflow slightly, and I’ve benefited from these improvements.

While I’m glad they improved it, I think they should have given me the right of refusal regarding accepting their changes, or at a minimum notified me that they were making changes. In this case, I would have accepted them, but I’m not sure that I always would.

Leaving Crashplan

Back in August, Crashplan announced they were leaving the consumer business. This is disappointing to me because I’ve had a family plan subscription for five years. Their service bailed me out when we had an apartment fire that destroyed our computers.

Michael Tsai has a great roundup of the community’s response, and the consensus opinion seems to be that BackBlaze is the best option for most people. For me, though, BackBlaze would be a substantial increase in price, since they don’t offer a family plan.

Over the five years I subscribed to Crashplan, I spent an average of $99/year1 for unlimited storage space for up to ten computers. I only ever connected seven computers to the service, and they ranged in space requirements from 1.4 GB to 3.7 TB; in total, my cost worked out to $0.0016 per month per GB.

I’ve been considering my options:

  • I can stay on Crashplan. On their small business plan, the cost becomes $10/month/computer, for a total of $840/year (although they’re offering 75% off for a year, so $210 for the next twelve months).
  • I can switch to BackBlaze. To connect those seven computers would cost $420/year; this is still a substantial increase.
  • I could try a more DIY solution, using Arq to backup to B2. Their price is $0.005/GB/month; this would cost me $304/year.

What I’ve settled on is a combination of the above. If I exclude the one computer with 3.7 TB of data, I can backup the other six computers to B2 for $82/year. For one year, I can continue backing up the large computer to Crashplan for $30/year ($2.50/month), for a total of $112/year2. This is the lowest cost option I’ve seen, and keeps the price increase to a minimum.

After the first year, I’ll likely switch the large computer over to BackBlaze, since it will be half the cost (at $5/month) of staying on Crashplan Small Business (at $10/month). That will bring my annual costs to around $140/year.

This is a fairly substantial price hike, but the value of cloud backups is well worth this price increase. However, having been burned once, I’d avoid Crashplan at all costs if I were considering solutions for a small business.


  1. The list price was $150/year, but I would extend my subscription when they had sales. 

  2. The tipping point is 500 GB; a computer larger than that is cheaper to store on Crashplan for $2.50/month, smaller than that is cheaper to store on B2.