Rob Peck Observations on technology, leadership and life.

Internal Auto-Renewing LetsEncrypt Certificates

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!

A Fresh New Look

Welcome to the new, freshly redesigned!

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?

Incrementally Migrating from Apache to nginx

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!

Just Take The Train

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.

Hierarchies: Finding Parents, Children and Descendents using Swift

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.

Creating Traits or Mixins in Swift

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.

Debugging the Responder Chain in Swift

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.

The Responder Chain: Bubbling Events using NSResponder and UIResponder in Swift

The responder chain is one of those parts of macOS and iOS development that may seem a little strange if you have not done any GUI programming before. Briefly, a responder chain is a hierarichy of objects that can respond to events. So, for example, a click or a tap might be passed up the responder chain until something responds to the action.

But, the responder chain is more than just UI events. We can pass our own custom events up the responder chain as well!