Using Rake, Pow, and TextExpander for Project Templates
TL;DR: I made a Rakefile to automate the creation of a project template that pulls fresh copies of either Twitter Bootstrap or the HTML5 Boilerplate from GitHub. I serve the template’s HTML with Pow, and I use TextExpander fills to generate boilerplate snippets.
Over the years, I’ve put together a number of project templates, each containing its own set of default HTML, CSS, and JavaScript that I would—invariably—abandon. Each would start off with the best intentions, but I’d fail to routinely update them. They’d grow stale, my workflow would change, and I’d start again.
This cycle repeated itself again recently as I started to move back to Web development in my spare time. Wanting to try out some responsive design techniques, I grabbed a copy of the HTML5 Boilerplate project, tweaked it, added some media queries, and posted it to GitHub. I deleted the repository yesterday because I realized that keeping my template in sync with the HTML5 Boilerplate’s releases would be tedious. Thinking about the problem differently, I turned to Rake, and I’m pretty happy with the results.
Workflow
These days, when I start a project, shortly after some sketching but before I even think about what back-end technology will be powering the site, I focus on building the interface using plain old HTML. My default directory structure looks like this:

I like to use CoffeeScript with Jitter, so I include directories named /coffee and /js. Everything else is pretty straight-forward: /css for CSS, /images for images, and a /resources directory for storing things like PSD files, icon sets, and other project-specific clutter. Finally, the /docs directory is for annotated CoffeeScript documentation that’s generated with Docco.
I create an empty file called application.coffee in the /coffee directory, which ends up compiled to application.js in the /js directory. I also include an empty application.css file in the /css directory. Finally, I toss in an empty index.html file.
If I use a framework like the HTML5 Boilerplate project or Twitter Bootstrap, I download the package and place the project’s various assets into the appropriate directories. The HTML5 Boilerplate’s index.html becomes the default index file when I use that project.
With all of the files in place, I initialize an empty Git repository and start cranking out code. But there’s an easier way.
Rake
This file handles all of the above for me by providing three command-line options.
$> rake newblank
This creates the blank project directory structure and a handful of empty files as outlined in the Workflow section above (complete with a Git repository).
$> rake newhtml5
This clones a copy of the HTML5 Boilerplate project, places its files in the proper directories, and creates a new Git repository.
$> rake newtwitter
This clones a copy of the Twitter Bootstrap project, moves the JavaScript and image assets into the proper directories, compiles the .less files into a single CSS file, runs a quick find-and-replace on the compiled CSS to change references to ../img into ../images because I’m tightly wound and like to name my images directory /images, and creates a new Git repository.
To use it, create a directory for your project and place the contents of this Gist into a file in that directory. Name the file Rakefile. Then, cd into your project’s directory and run one of the above commands.
Advantages
I don’t have to keep my template in sync with changes to projects I use (e.g., the HTML5 Boilerplate project). I don’t have to keep a blank project template full of empty files and directories lying around that will grow stale and require maintenance. I always get the latest HTML5 Boilerplate and Bootstrap code when starting a new project. Everything’s boiled down to one file that’s far easier to maintain and tweak as my needs change. And if a new set of fancy boilerplate comes out, all I have to do is write a new Rake task to add it to my arsenal.
Pow
You can use Pow to serve the flat HTML files you create using any of the templates that are generated by this Rakefile.
Create a directory for your project, and then create a public directory inside your new project’s directory. Place a copy of the Rakefile in the public directory. It should look like this:

cd into the public directory, and run one of the commands to generate the template structure. Then—just like you would with any other Pow-based project—create a link to your project’s directory (not the public directory, but the root project directory) in ~/.pow. For more info on using Pow, see the user’s manual.
Yes, you could just open your plain old HTML files in a browser without having Pow serve them, but using Pow lets you avoid addressing your assets (images, JS, CSS) with relative paths. You won’t have to go through your code and change all the relative paths to full paths once you’re ready to turn your templates into production code.
TextExpander
I love TextExpander, and I use it to fill a gap that’s left by generating blank files with no template code in them. For example, I like my default application.coffee file to include the following header:
# Project Name v1.0
# (c) 2012 Company Name
# http://projecturl.com
# Load the application once the DOM is ready using a `jQuery.ready` shortcut.
$ ->
This block turns into a very pretty header when I run Docco to create my documentation, and it sets the application up to work with jQuery. I created a TextExpander fill to generate this header. The fill, which is triggered when I type coffeehead, prompts me to enter the project name, version, company name, and project URL. For more info on how fills work, see this video by the venerable Merlin Mann.
I have a similar fill that creates the header for my CSS files, which looks like this:
/*
Project Name v1.0
(c) 2012 Company Name
http://projecturl.com
*/
/* Header
--------------------------------------------- */
This one’s triggered when I type csshead. It’s very similar to the CoffeeScript header. Another fill creates CSS section breaks by prompting me for the name of the section when I type csssec:
/* Section
--------------------------------------------- */
If you have TextExpander and want to try these snippets for yourself, you can download a copy of them here.
Bonus: Docco
Don’t delete the Rakefile when you’re done generating a new project! It provides a task for creating annotated documentation for your CoffeeScript:
$> rake doc
Run that command, and then check the contents of the /docs directory.
Requirements
I’ll be honest; I lost track of all of the software that’s required to make this work. You’ll need Ruby and Rake and Git to get started. To compile the .less files that come with the Twitter Bootstrap project, you’ll need Node.js and NPM. Once you have NPM installed, you’ll need to install the less package. You can also install CoffeeScript and Docco with NPM; Docco also recommends installing Pygments for syntax highlighting. If I missed any other requirements, please let me know in the comments.
Xcode4 has some learning to do with regard to Git. Switching branches causes it to freak out, sometimes in a major way (as seen above). Also, it’d help if Apple would make it instantiate a Git repository with a sane .gitignore file as well. The above error was caused when I created a .gitignore entry for xcuserdata files. Here’s my default iOS .gitignore file:
Learning Git
Version control software is wonderful. Tedious, sometimes difficult to grasp, but wonderful. I’ve used CVS and Subversion, but my go-to these days is Git.
Git isn’t just normal version control, though. It’s a distributed version control system, which makes it more complex, yet more flexible. But what really makes Git intimidating is that—unless you want to use a clunky UI—you use it from the command line.1
Lucky for you, the folks at Edgecase have put together a great Git tutorial called Git Immersion. Each module of the 53-module course builds on the last, teaching you the ins and outs of Git. The modules are short, and the entire tutorial can be done in one sitting. If you’re interested in learning how to use Git, this is an excellent way to pick it up without spending a dime.
I originally learned Git through an article on Tim Lucas’ blog called Setting Up a New Remote Git Repository. Sadly, the article is now offline. But! I was happy to find that Tim archived it as a Gist on Github (Thanks, Tim!).2 This tutorial got me up-and-running in minutes. At the end, he recommends checking out this Git Guide over on SourceMage, which includes a collection of real-world Git usage examples.
Finally, keep an eye on Github’s Twitter account. They occasionally offer training, and Twitter is the first place you’ll hear about it.
Go, learn, and then get a Github account so you can fork software with the rest of us.
-
As of this writing, most of the graphical user interfaces for Git leave much to be desired. This could change in the future, but I wouldn’t hold my breath. That said, Kaleidoscope is a beautiful way to do file comparisons if you run into conflicts. ↩
-
Github is a site dedicated to social coding. All of the code hosted on Github is maintained using—you guessed it—Git. Git owes a lot of its success to the community established by Github. Well, that, and the fact that Linux nerds glommed onto Git early since it was written by Linus Torvalds, the creator of Linux. ↩
