HydraulicLabs, simplified.
Today I totally simplified the way that HydraulicLabs will be presented, from a marketing standpoint. For several years I have relied on WordPress to be my blogging and web site backend, but no more. I have switched the HydraulicLabs site to use Jekyll, Haml, Bootstrap, and Sass. These are static template based tools, that simplify and more than anything secure my web site. I am able to author everything locally and send the static files up to my new server on Linode via RSYNC. Why would I do this? It’s really a matter of “why not?”. I like to dabble with new technology, languages and automation, so this set of tools is the perfect experiment. This is definitely a more manual process, but I am getting several Ruby scripts in place to parse my Haml templates, run the Jekyll conversion and then upload a new post up as soon as I drop it into the posts folder. I look to make this a set up that a client can use, making it as easy as creating a new file to create a blog post. I am sure that this base template will change over the next few weeks, as far as graphical feel, but I really want to keep it simple. To try to simplify how to use these tools, I will explain the process and role of each tool.
Twitter Bootstrap
I started by grabbing the new Bootstrap CSS library made public by the Twitter engineers. This is a (enter non appropriate exclamation here) fantastic set of CSS declarations that are designed to work with the majority of browsers, simplify layout, add cool features, etc. So I took the base example and started working from there, added the Jekyll properties where needed. I ended up with a set of Jekyll based templates that can be compiled into the main site.
Jekyll
I talked about Jekyll above, as they really came together at the same time. With Tom Preston-Werner’s Jekyll library you have a Ruby based static site generator that will create a website based off of templates and posts. Once you get Jekyll installed, your templates created and some posts written you simply call jekyll --server from the command line in your site’s root directory. This will launch a WEBrick instance at http://localhost:4000, where you can browse your new slick static website.
Haml
So here is where Haml comes in to play. By default Jekyll does not support Haml, which is a simplified markup replacement…in so many words you write elegant Haml script rather than fugly HTML. This allows you to quickly mock up your HTML templates, then run the Haml parser to generate HTML files from the Haml templates. Easy right? Actually it takes some getting used to, being as old as I am
Sass
Next up to add to the mix is Sass, a CSS3 extension. The gist is basically the same as Haml, writing a set of CSS templates, rather than writing CSS itself. This is just butter, because I frackin hate writing CSS. I will do a poor job at explaining Sass, so you can check it out and learn more at the link below.
Guard-Rake
Wrapping it all up with some automation sugar, I use Guard-Rake. Guard-Rake basically is a watcher that monitors my Haml folder for changes. I am still working through the total workflow, but right now I have my Haml templates auto generating Html on change, one less step for me on the build. I plan to eventually have a watch on the Haml to parse, and also on a new Jekyll post to drop, which will generate the site and RSYNC that hot mess up to my Linode server.
Guard-Rake example
So to wrap up, this may seem like a hell of a lot of work…and it really was, but just to learn the initial use of each tool. Now that I understand the flow, each tool’s role, and my workflow it makes so much sense. Compare the time to set up this set of tools to say trouble shooting a WordPress hack or injection and you won’t think twice about leaving WordPress/MySQL in the dust. Now think that you can have this setup sitting on GitHub and then deploy with Capistrano, then why would I ever want to log into a WordPress admin again. Where ever I am I can create a new post, drop it in the post directory, and deploy.