In the last post I focused on deployment details of the new site. Today I will talk about the code itself – how it has changed and why.
Going into the v2.0 revisions I had three main goals for my code: 1.) Better readability and maintainability, 2.) Responsive Design, and 3.) SPEEEEED (really wanted to find a gif of Jeremy Clarkson from Top Gear saying this, but that turned out to be a utterly time consuming task).
Improved Readability and Maintainability
Even though I am the only one who works on my site, I often go months in between updates or looking at the code. When you’re looking at new code everyday (as I generally am), it is easy to forget the intention of certain blocks. If a problem arises, poorly structured code can make a trivial fix take hours of digging through jumbled functions. When I looked at some of my code from over two years ago, I felt my heart sink a bit and a rush of being overwhelmed by the prospect of changing anything. That is when I decided I needed to really clean it up – making incremental change more of a possibility and potentially allowing others to gain insight from looking at my code.
In Test Driven Development, we have a mantra “red, green, refactor”. This process means first you write a test that fails, then you write code to make that test pass and finally, you refactor your code to make it simpler, more elegant, more readable and more maintainable. In my first release of the site, I had reached the green phase. Now, with this release I have done some serious refactoring.
I’ve added fairly extensive comments to all the code. Right now, they are mostly to remind me of what is going on at any point in the code, but I hope to incrementally improve them so that anyone could look at a block and understand. Documentation has admittedly been a weakness of mine (I always want to run on to the next thing), but I have been working to do some documentation at the same time as I write the code. This strategy makes it incremental and a much less daunting task.
Mobile-First with Bootstrap
Bootstrap is a really fabulous tool created originally by a Twitter employee and later open-sourced for the benefit of the world. It makes developing responsive layouts as simple as adding classes to DOM elements. It employs a strategy called mobile-first which means it first loads a layout for the smallest device and then scales up for larger devices. The thinking here is that smaller devices usually have less bandwidth and computing power than their larger desktop counterparts. Though mobile-first is really a frame of mind rather than a specific technique, one way to start doing mobile-first is with min-width CSS media queries. These insure that first the styles for mobile are loaded and then, if the screen is larger, more specific styles are calculated.
In addition to an easy to use responsive layout, Bootstrap also provides a set of common layout components that make getting a site up and running take no time at all. Some of these components include navigation bars, headers, accordions, and carousels. Finally, for the more advanced user, Bootstrap comes with a few nifty auxiliary JS libraries including Affix.js, which I’m using to fix the side navigation to this page (if your screen is greater than 991 px wide). All around a great tool. There others out there that do something similar (I’ve actually heard really great things about the new Foundation 5), but I chose Bootstrap because I needed to get familiar with it for another project.
One issue I ran into with my responsive design was getting my images to play nice. Bootstrap has a native way scale images for different screen sizes, but I wanted my images to hard crop to a particular size at each breakpoint. For this, I used the very cool tool imgLiquid. It essentially makes the image the background of it’s parent. This way as the parent div is being re-sized, so is the image in the layout.
Speed and efficiency are always a priority when programming the web, but it was particularly important for me this go around because I am now on Heroku with a very finite amount of computing power. If I can manage to do things efficiently and not waste resources, I can stay at a minimum number of “dynos” and keep paying nothing.
Asset Minifying, Bundling and Caching
I originally was going to build a tool to do all this myself, but it turns out, I didn’t have to. I found a WordPress plugin, BWP Minify, that does all of this for me in a very clever way. First it uses a technique called Minifying to reduce the size of individual assets. This process deletes unnecessary whitespace, makes variable names shorter and generally compress a file to it’s smallest possible size. BWP Minify then takes all like assets (i.e. .css files) and combines them into one file and uses WordPress’s native script enqueue system to make sure dependencies are loaded in order. Finally, it stores this combined file in a cache folder that doesn’t need to be created again until one of the underlying assets has changed (which it does for you). This is a very cool tool and one I highly suggest you check out if you are a WordPress user.
In WordPress, this is actually incredibly easy. I used jQuery to disable the default functionality of a link click (a full page reload). Then I used the jQuery .load() function to load from the link’s href. The load function is very cool because you can append an element ID to the end of the url in order to only load the content of that element, which is what I wanted to do.
Revamping was a ton of fun and I learned a lot of valuable things along the way. If you have any more advice on things that I could improve, I would love to hear from you. Furthermore, if anything sounds interesting and you’d like to hear more, I obviously like talking about it way too much.