The Perfect Blogging WorkflowPublished on:
I periodically talk about this site and how it is ran. Well after nine months my baby has gotten an upgrade. I’ll try and detail the programs that I use to render this site thorough enough to so that they can be followed and not be too tedious. Before getting started, it should be noted that I have a test web server and machine where the web site is built. These are two different machines and files from the development machine have to be copied to the test web server.
Let’s start with the basics. I still use jekyll, the static blog generator, to
turn my writing into web pages and for the form of site. The most tedious part
of jekyll is setting up how the site is to be generated. I have jekyll build
the site to
_site, this allows me to view the majority of the web site
unchanged. Any dynamic part of the site relying on the back-end written in WCF,
like comments, aren’t rendered correctly, but the impact is minimal.
What fixes this? Node. Those familiar with just the name and its recent appearance, might groan. Indeed when I told my boss from my first job, that the web application I had developed needed node to be able to ‘compile’, he became skeptical, doubtful, and had to be reassured that the application wasn’t running on top of node. It is only needed for development purposes, so don’t worry. I know it may seem to be overkill to download and install server software just to achieve a better workflow, but the end result is worth it. Trust me, no one hates software more than software engineers, so coming from me, you know that if the end wasn’t good, I wouldn’t have converted my entire website to the new workflow.
How does node fix this problem? Grunt. Grunt is an automation tool that runs
ontop of node and has allowed me to throw away the bash script in favor of a
method that ensures that transferring development to a new machine involves a
simple dependency resolution of
npm install --no-bin-links. The
--no-bin-links is needed due to the development machine being a virtual machine. Grunt
is the solution to all the problems posed above. I still am amazed that I can
point grunt to a directory of images on the jekyll server and resize them so
that their width are all exactly 720 pixels. Therefore in the source control I
have higher quality pictures just in case I change the width of my blog in the
future. Resizing of images and the automation of ftp deployment are the two
biggest advantages I found with grunt. Basically everything about this site is
now automated – all but the writing!
Here is the workflow:
- Have jekyll build the website
- Compile less files in the repository into css files
- Combine all the css files in the repository and output the result into the jekyll website
- Minify the resulting css
- Resize all banner images (using imagemagick) in the jekyll directory to a width of 720 pixels
- Copy all the files from the jekyll directory to the test web server
- FTP the jekyll site to the live site.
For minimization, I must mention that I have moved away from Google’s Closure Compiler and instead use UglifyJS via RequireJS Optimizer. The main reason is speed of compilation. As shown here, Closure is, on average, five times slower than Uglify, and if I’m going to be frequently testing my site, I don’t want to sit around waiting.
If you'd like to leave a comment, please email firstname.lastname@example.org