I’ve used DocPad for small personal projects and for larger sites at work. I enjoy it’s API and it does what it advertises as a static site generator written in Node that allows for easy extending via plugins.

I also love Grunt. It is another Node based tool that allows for easy task based builds. It has built-in support for linting, concatanation, minification and more.

I forked the DocPad HTML5 Boilerplate repo and added Grunt to it. The fork uses Grunt to take the default CSS and JS files included in the HTML5 Boilerplate and minifying and concatenate them and include them in the DocPad layout. Nothing groundbreaking I know, but I wanted to create a quick example repo of all these things in action since it was difficult to find all the bits and pieces of information required to make these two work together harmoniously.

I edited the Readme of the fork to explain what I changed and how it works, so check that out for all the details. Also leave an issue there or a comment here if you have any questions or anything is wrong.

TL;DR

DocPad + Grunt in action.

Writing this to save for posterity on the blog since it is only in a gist currently.

The Problem

There is a pretty big site that we have at work (1000+ pages probably) and I needed to find all the links in the site to a certain page and see what the query string parameters were for those links.

Each query string could have multiple keys and values, and all I needed was a unique array for all the values for each key.

Click around some internal links on this blog. You’ll notice that on supported browsers this blog no longer uses full page refreshes. Instead the content of the next page is grabbed with AJAX, parsed on the client-side*, and then inserted into the proper content node. While that is being done, instead of using hashbangs to save the state, I’m using the HTML5 history API.

Be on the lookout over at the Tag Soup blog on Monday as I will be doing a full write-up on this for Tag Soup’s 30 Day Challenge.

*Note: I understand that this isn’t the best way to do it since we are sending the full page content over the wire, but only using part of it. A better solution would be to have Jekyll generate separate html files for just the content of each page.

Apparently, everyone knows that setTimeout console bombs are the best. I didn’t until my friend Tony Camp showed me but now I can see the light and I’m never going back. This is something that I whipped up so you can throw it in the console of your best friend (or enemy) and try to give them a seizure. Everyone wins.

A friend of mine told me a few weeks ago that he wanted to make a Chrome plugin to display Pitchfork album scores on Rdio album pages. This seemed like an interesting idea to me, and I wanted to take a stab at the JavaScript for it. The following is a rundown of my thought process while researching the problem and the end result.

Being new to the world of Ruby (and obviously Jekyll), I thought a good initial learning experience would be to write a liquid tag for Jekyll to display an Instagram photo. I finished up a decent enough version of the code, and it’s actually in use over at lukelov.es to display all my Instagrams. Check out this page for a complete example of what the finished product looks like.

It is a simple liquid tag which takes one parameter, the ID of a media item from Instagram. The code then fetches the media item using Instagram’s ruby gem, and writes a bunch of relevant HTML to the page.

Octopress has been cloned and I now have my first Jekyll blog (and first ever blog).

This will be dedicated to code with a little facial hair thrown in for good measure.