Fixing missing headers in macOS Mojave Beta (10.14 Beta)

Apple recently released the beta version of the next major version of macOS, codenamed Mojave, that introduced new features such as a system-wide dark mode, desktop stacks, improved file and metadata viewing, and more. If you're anything like me and can tolerate a few non-critical bugs, you have installed this when it first came out. If this is you, you might be also be familiar with the Xcode changes that are introduced that have a tendency to break dependent systems such as parts of Homebrew until fixes are introduced.

The release of Xcode 10 beta is no different, as this time Apple has introduced a particularly onerous change by moving the Xcode Command Line Tools system headers from their usual spot in /usr/include/ into the macOS SDK, which has the much longer path of /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include

For me, this only manifested when trying to run pip and pip being unable to find the needed zlib header:



If you are trying to run pip, or any other utility is looking for a system header in /usr/include, navigate to the following path and install the .pkg file inside:

/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

If you're indeed having trouble with pip via Homebrew as I was, you may need to reinstall python/pip with brew reinstall python as it's bundled together and may be copying or caching the zlib header elsewhere, as installing the above package did nothing to resolve the issue until after reinstallation.

This is intended to allow legacy software (read: "current software" as of this writing) to continue to function while they transition to using the macOS SDK. In case you're wondering, this information can found on the third page of the Xcode 10 beta release notes.

Setting up this feed

When I set out to create this simple personal site a few days ago, I knew I wanted the blog and gallery to be "built-in", staying on the same page without redirecting to another service/subdomain. Given that problem, three quick solutions come to mind:

1. Use a CMS such as Wordpress, Ghost, Django, etc.
2. Build a simple back-end service that supports the bare minimum I wanted
3. Use a hosted platform with a lower-complexity API

Although Wordpress and others are good, time-tested options with lots of support, right off the bat I knew they were overkill for what I wanted and can often be more trouble to setup and theme correctly than if you were to start from scratch. No-go. Building a back-end service was tempting, though it would've escalated the complexity by an order of magnitude and require a greater time investment, so I ended up at option #3. All I knew was that I wanted something that didn't require a complex authentication flow such as OAuth since these would be public items anyway.

I decided to start with the gallery, and some cursory Google searches found me browsing the Picasa Web Albums Data API, which appeared to be just what I needed: An easy auth (or no auth in this case) service that allows me to pull photos from a public, hosted album. To top it off, I found a small Angular library with a directive and service for pulling those public photos -- success! Turns out, all you need to do is issue a GET request to the Picasa service with your userId and albumId, which you can get by checking the Network requests for that album on the actual Picasa platform (see below). After that, the query parameters provided all the configuration I needed. I used Masonry to tile up the photos and with zero configuration (seriously, there's no controller for the gallery state!) and very little styling, I was good to go. The end result was responsive and good looking with a very minimal code footprint. See your yourself!

You can also get your userId from your public Google+ profile!

Blogging turned out to be much a similar matter. I explored some blogging platforms such as Medium and others, though their APIs were either overly-complex or non-existent. Blogger, a no-frills blogging platform ironically also run by Google, unsurprisingly turned out to be very similar to the Picasa API with just as awesome documentation. This one required auth, though only an API key when retrieving public blog information as opposed to an OAuth flow for private data. I re-used the same service/directive setup used by the Picasa component and changed it slightly to work with Blogger. Once again, there was no controller-specific code needed and everything was kept very simple, the result of which you are reading right now.

I still need to work out a couple of issues such as the initial page render of the gallery or the mystery of the missing prevPageToken in version 3 of the Blogger API but those remain for another day.