I have an old iMac that has been sitting unused upstairs for awhile, that I decided to finally get rid of. Before putting it on Craigslist, like any good computer owner, I wiped the drives and went to reinstall the most recent version of OS X/macOS that this old machine would support. In this case, this was El Capitan.

But when I went to install, I kept getting an error about the OS not being able to install. Popping the log window open, I found an entry called CSSMERR_TP_CERT_EXPIRED. This would seem to be a prime suspect.

If you have done and OS X/macOS development, especially any that predated the Mac App Store, you are probably aware of Sparkle. Even if you haven’t done any development, you have probably used Sparkle because it was basically the de facto method of providing update functionality in Mac Apps, and even to this day is still widely used on many apps distributed outside the official App Store.

Updates are distributed to applications by means of an “appcast”, an extension of the RSS specification containing information about updates. RSS itself is based on XML, which means you can build them just like you would build any other published document.

The problem comes when you start having a lot of updates in an appcast. Maintaining a large file can become difficult. But fortunately, using Jekyll collections, we can generate a single appcast using multiple files that are much easier to maintain. And, as an added bonus, we can use that same data to generate a download and changelog page from the same data.

I have a well-documented obsession with pretty URLs, and this extends even to my internal home network. I have way too much stuff bouncing around in my head to have to remember IP addresses when a domain name is much easier to remember.

LetsEncrypt launched to offer free SSL certificates to anyone, but the most crucial feature of their infrastructure, and one someone should have figured out before then, was scriptable automatically renewing certificates. Basically they validate you do in fact own the domain using automated methods, then issue you the new certificate. Thus, your certificates can be renewed on a schedule with no interaction from you.

Traditionally, they have done this by placing a file in the webroot and looking for that file before issuing the certificate (see my earlier blog post about Zero Downtime nginx Letsencrypt Certificate Renewals Without the nginx Plugin for more detail about this.)

But what happens when you want to issue an internal certificate? One for a service that is not accessible to the outside world, and thus, not visible using the webroot method? Well, it turns out there is a solution for that too!

Welcome to the new, freshly redesigned robpeck.com!

It’s amazing how you can become used to a design. It becomes like a warm coat. You love the predictability, you spent a lot of time getting the fonts right, getting the layour right, and everything is just perfect. That was the case with this site, that was pretty much exactly how it was way back when I migrated the site from Wordpress to Jekyll in 2013.

To put that into perspective, my daughter was not even a year old yet. Barack Obama was just one year into his second term, the iPhone 5S had just dropped a month earlier, the first 4K TVs were shown off at CES. A long time has passed.

And then the years pass. New devices and browsers appear. New technologies become available, and cruft builds up. In this case, a simple task of “I need to add a box to the site so that people will quit trying to use the comments for tech support and go to Github instead” became a full scale burn it down and start again redesign.

So, aside from the new design, what else has changed?

I am currently in the process of migrating a bunch of sites on this machine from Apache to nginx. Rather than take everything down and migrate it all at once, I wanted to do this incrementally. But that raises a question: how do you incrementally migrate site configs from one to the other on the same machine, since both servers will need to be running and listening on ports 80 and 443?

The solution I came up with was to move Apache to different ports (8080 and 4443) and to set the default nginx config to be a reverse proxy!

I love flying. Always have. Ever since my first flight as a kid, there was just something magical about getting into a giant metal bird and taking to the sky. I say was because it seems like, especially over the last decade or so, we have gone out of our way to make flying as miserable an experience as possible.

The “golden age” of air travel is long behind us and flying is now just a completely miserable experience. And it pains me to say that because I used to love flying. I loved airports, watching planes, feeling the potential of all the places you could go. But now, it is just an objectively awful experience.

It usually doesn’t take beginning macOS/iOS developers long to discover NotificationCenter and see it as the solution to every single problem of passing data around to different controllers. And NotificationCenter is great, but it has some downsides. Notably, it is very easy to introduce retain cycles (and memory leaks) unless you are very careful to track and free the listener when the object is released. This has bitten me on several occasions.

In general, excessive use of NotificationCenter ends up creating a difficult to maintain app where it is not entirely clear what is responding to what and where.

Quick post on how to install Letsencrypt certificates into nginx without using the official plugin. There may be some cases where you don’t want to use the official plugin (which until recently was still marked as “experimental.”) The concepts here could be theoretically applied to any webserver software.

Object oriented programming is great, but sometimes things don’t fit neatly into a superclass/subclass hierarchy. You may have a piece of code that would be needed in several contexts, but for technical reasons beyond your control you cannot merge them into a single hierarchy.

Some languages have the concept of multiple inheritence, where a subclass can specifically inherit from several parents. But this has it’s own set of problems. Many other languages, however, solve this through the use of traits or mixins. These allow us to have a set of methods that are basically copied into the object at compile time. This way they can be used anywhere they are needed.

Swift doesn’t have the concept of mixins or traits per se. But, starting with Swift 3, you can get very equivalent functionality using protocol default implementations.

Somewhat related to my previous post about responder chains, sometimes it is useful to be able to debug what all is in the responder chain at any given time. As a good rule of thumb, all ancestor views of a view are in that view’s responder chain, as well as (usually) the related controllers.