A lot of developer cycles are spent discussing the benefits of YAGNI and KISS. On the surface it would seem that there is an army of righteous developers fighting against the demons of over-engineering and maximum complexity. And despite our valiant battles, despite all the books and blog posts and rallying calls from respected technology professionals, the demons are still churning out bloated, impossible to maintain code.

I’ll let you in on a little secret. We are the enemy. Not just the guy who sits next to you, or the guy that churned out mess of code and then left the company. You are the problem. I am the problem. The enemy is us.

Yes, we can all agree in principle that complexity is bad and simplicity is good. The problem is that complexity is completely subjective. Maybe you misjudge or were misinformed about how likely it is that a certain feature will be needed. Maybe you thought of some brilliant solution and you want to leave it as a placeholder in case you need to come back to it later (or so others can see how clever you are). Maybe you don’t want to do it the cheap way because you’re afraid others will snicker at your solution. Maybe you’re afraid a simple solution will lead to longer development times later on. Maybe your definition of simplicity is skewed. Whatever the case, no one sets out to over-complicate a piece of code. And yet it happens time and time again.

There are rules of thumb that can be followed. But what it boils down to is always discipline. It’s not easy to simplify. It sometimes feels wrong. But I’ve never looked at working code and cursed because it was too simple. I’m not even sure it’s possible for working code to be too simple. But it sure as hell easy for it to be too complex.

So why is over-engineering is like snoring? Because no one thinks they do it. And yet somehow there is a market for snoring relief aides.

In my first post about SSL integration on my site, I discussed how I came to a decision about a certificate issuer. I chose DigiCert, and have been very happy with them. One great bonus was their extensive list of instructions for setting up the certs on almost any web server known to man. So even though Part II of this series was intended to be about installation, I think DigiCert has that covered. Their instructions for nginx were spot on, so I wouldn’t be able to add anything meaningful to them anyway.

But buying and installing the certificate is a little different than using it. This post will focus on how I integrated the certificate into the site and what additional nginx configuration I had to make to support that strategy.

After kicking it around for a while I realized I really have 2 options. I can either convert the entire site to use https or convert as few pages as possible (e.g. just the login and register pages). The argument for a limited use of https is that all else being equal, the web server will require a little more CPU to encrypt/decrypt the https traffic. This is apparently an issue particularly with nginx as even the creator has said it can drag down performance for high-traffic sites. Since I’m not expecting Amazon-level traffic, this wasn’t as big a deal to me.

Another argument for limiting the use of https is that some low-cost CDNs, such as Amazon CouldFront, don’t support https traffic. This was a concern for me. I will eventually want to move my images, screencasts, stylesheets, and JS files to a CDN, so the fewer https pages I have the less of an issue this would be.

Related to this, some posts I read claimed that browsers will refuse to cache images, CSS, and scripts if they came across https. In my testing with Charles in Firefox and IE on Windows I did not experience that. In other words, any files that could be cached by the brower were cached. Yes, it was a limited test, but it covers a lot of the target base of my app. I believe either this used to be the case and no longer is or it’s one of those old wive’s tales that people just assume is the case but have never really taken the time to test.

I saw a couple of benefits for using https for the whole site. The first was that it simplified my application architecture. For instance, say you have a login page that’s intended to be served over https but it includes a common header image that’s present on all pages. That image has to also be served over https on the login page or the user will get a popup warning message that the page contains both secure and insecure content. That message is at least annoying if not scary to some users, so it’s best to avoid it by ensuring that the image is served up via https. But that means you may have a situation where you have 2 copies of that image so that it can be served up by both https and http. Or your configuration might become more complex in order to support 2 virtual servers pointing at the same image file on disk. Either way it’s a complicating factor that I wasn’t thrilled about wasting time on. If the entire site is served over https this issue goes away.

Secondly, it would be easier to configure than having only some pages be served via https. For instance, let’s say the login page is https. If someone asks for that page via http, the server should be nice and redirect them to https. But for almost all other pages it should allow regular http requests to process normally. These exceptions are easy to handle for one or two pages, but for more than a couple that quickly becomes difficult to manage effectively.

Lastly, my application is targeted at kids in the 10 to 15 years old range. For me, the more security the better. As with any site that relies on cookies to identify logged in users, it’s theoretically possible to hijack someone’s session via the cookie value, and if that were to happen it would lead to some seriously bad press for me. Again, if the entire site is accessed over https this issue goes away.

So as you can probably guess, I decided to serve the entire site over https. The big question I haven’t answered here is what effects this had on performance. I’ll discuss that the final installment in this series. But for those also using nginx, below is an excerpt of the config changes I made to support this. It should be self-explanatory, but leave me a comment if you need any help through it.

# non-secure site - send all requests to https
server {

        server_name www.mysite.com mysite.com;
        listen 80;

        location / {
           rewrite ^/(.*)$ https://www.mysite.com/$1 permanent;
        }
}

# secure site
server {

        server_name www.mysite.com mysite.com;

        listen 443;
        ssl on;
        ssl_certificate /path/to/pem/file;
        ssl_certificate_key /path/to/key/file;
        .....
}

One of the things I love about being a software developer is the fractal nature of our work. When we design a system we are almost always taking some piece of the universe and attempting to deconstruct it and model it so that it can run inside a computer. Examples of good (or bad) design are all around us, and our work demands that we draw on these examples to create a working piece of software. And software itself is nothing more than a bunch of bits and registers and some electricity that’s pretending to be more than the sum of its parts.

So I found myself reading Coders at Work on the 8:06 train the other day. I don’t usually catch the 8:06. The 8:06 is a double-decker train. And watching the conductor come through to collect our tickets I realized he represented a real-world example of a mutex.

This day there was only 1 conductor for both levels of the double-decker. It dawned on me that it would be very easy for someone to avoid having to pay by hanging out in the upper level and waiting for the conductor to collect the tickets from the lower level, then sneaking down to the lower level while the conductor moves to the upper level.

The lone conductor represented a flawed algorithm. There was no lock on the resource (exit door = I/O stream?). Adding another conductor could solve the leakage problem and lock the resource. But that would limit (or serialize) the free flow of passengers to and from the car.

I could probably go on exaggerating this example for while but I think you probably get the point.