Developing on Staxmanade

Custom Static Blog Generator - No Longer Using Octopress



In summary I left my Octopress blog behind quite a while ago, and this site has been statically generated with a custom tooling build up around gulpjs and node.

Some of the details...

After I migrated from Blogspot to Octopress I started running into workflow issues and other issues that turned me off from Octopress/Jekyll (at least for my own site).

It was also right around the time that GulpJS came out and I needed a project to play around with...

So I did what every developer does. I wrote my own.

Using Approvals.NodeJS to capture previous renderings of the Octopress generated version of, I was surprised at how quickly I ported my Octopress generated site to a new custom static site generator.

I'm not writing this to convince you to leave Octopress for anything (especially my home-grown tool), but felt compelled to get a blog post out describing some of the cool little features I've implemented.

Personal struggles with Octopress:

  • Octopress site generation was too SLOW for me. There's even a helper rake task that moves your posts to a temporary folder to exclude from generation when you want to quickly see the post you're working on generate fast, but this just bothered me from a fundamental level.
  • I'm not a Ruby developer and don't have the ability or desire to fork/maintain Jekyll or Octopress. I wanted to have something that I pretty much owned. (yea - that comes with a larger maintenance burden, but meh - I'm a developer and its part of the process)
  • Disliked that every time I rake gen_deploy I didn't know the exact code-diff that was changed since the previous version. I'd like to know exactly what files have changed and how they have changed before they get deployed. (again, there's probably a solution here, but didn't really care to dig deeper)
  • There's an issue on Windows where you end up mucking around with the codepage, which made working on things a bit of a headache.

So what did I end up with?

I now have a statically generated site all powered by gulp and a small library/command line tool I've thrown up here: Togglejs.

How is this better ~err~ different?

  • Regenerating my site only takes about 6 seconds (as opposed to the Octopress 30+)
  • I learned gulp, and node.js streams along the way.
  • Built by myself — which was a good for the learning experience.
  • Don't have to set the codepage to 65001 for Windows machines.
  • Series support.
    • I've implemented two different features for supporting a series. One allows me to control through YAML front matter posts and how they tie into a series topic. Another feature allows me to write out a series in a single markdown file, where I can specify a delimiter to split the articles up by. I may blog more about these in the future as they're a feature I've quite liked and was relatively easy to implement using my custom site generator.
  • Easy post tagging for a custom feed that gets cross-posted to
  • The tog is easy to extend with custom commands and has a number of pre-built commands already ready to go.

Since I've not put a huge amount of time into it - and I haven't exactly developed it to be a competitor to Octopress or other static site generators, it pretty much has just what I need it to have at the moment and not really anything more.

How is this worse?

  • I have to maintain it (this is both a blessing and a curse) - don't get the benefits of bug fixes by hundreds of contributors to Octopress.
  • I haven't yet ditched the Octopress theme, so that change will be coming at some point.
  • I don't have any automated process to deploying changes. So I can't just create a post on my phone, save to my repo and expect it to automatically show up online - but have ideas on how to do that.
  • My gulp watch is not working correctly and it's not yet wired up to livereload which would be a nice next step...


This is my site so it's all up to me to make it right...

It's been a pleasure to build this up and just a fun little project to hack on (as if all the other OSS projects I hack on aren't enough).

Updating git branches.


How to update a git branch OTHER than the one you're currently on.

git branch -f {branch-to-change} {commit-to-change-to}

I recently setup a C.I. server to automatically generate builds of an iOS application and upload to TestFlight. I don't want each and every push to master to trigger a new TestFlight build, so I configured my C.I. server to watch the release branch.

I was starting to dislike the switch branch dance to trigger a new build.

What I used to do:

# When I was on the master branch
git checkout release
git merge master
git push

When things start to hurt, look for a better alternative. And with Git, there is almost always a more efficient way.

After digging a bit, I found the answer.

git branch -f {branch-to-change} {commit-to-change-to}

So to trigger a new build from master I can just:

git branch -f release master
git push origin release

Or wrap that in a Gulp task gulp tf. And with CommandAllThings I can now type rake tf, or grunt tf or gulp tf and they all trigger a new build to come out of TestFlight.

Or if you wanted to skip moving your local branch, you could just update the remote branch directly.

git push origin local_branch:remote_branch

So my workflow would look more like

git push origin master:release

Happy Automation!

Introducing CommandAllThings


I'd like to introduce a simple little tool/(set of scripts) I threw together last weekend called CommandAllThings.

Some background

Do you use any command line build tools like GulpJS, GruntJS, Rake, etc?

I leverage these tools in many projects, both at work and on my own projects. I recently noticed that the muscle memory I've developed was slowing me down as I switch between projects and inadvertently use the wrong tool in the wrong project.

When working on one project all day and typing rake test throughout the day, then switching to another project not using rake I found myself still typing rake test even though I needed to type gulp test, or grunt build. This really messes with my flow. All I wanted to do was test or build the current project.

So I created CommandAllThings.

What is it?

In short, it's a very simple abstraction on top of your usual task runners like GulpJS, GruntJS, rake, etc that allows you to accidentally type the wrong tool and still accomplish the desired task with the right tool.

By using aliases in either PowerShell or Bash we can route, rake, gulp, grunt, etc to CommandAllThings which will inspect the current directory, determine the correct tool and execute your task(s) with the correct tool.

This is great. Now when I type in the wrong command rake test in a gulp project, I don't get slapped in the face with an error saying "cannot find a rakefile." Instead I continue on my way like I knew what I was doing.

example screenshot of commandAllThings

Does it only work on Windows or on the Mac?

At the moment it works on both.

  • For Windows I have an implementation in Powershell.
  • For the Mac you can alias to a Bash script.

Download at GitHub!

Check it out!

What's next?

I'd like to look at adding other tools to the list. You can check out the project for other task runners I know about. And if you have any thoughts on how to detect the other types, drop me a note in the issues (or consider sending over a pull request).

I'd also love to get some feedback on how to best or more easily get this into peoples's development environment. For now it's pretty manual and since it's all about your profile, a bit personal, so probably a good thing that it's not automatically installed.

Happy Commanding!

Migrating from BlogSpot to Octopress - Part 9 - What's left?


warning I've migrated away from Octopress and this site is now built using ToggleJS with a custom GulpJS file. warning

This article is Part 9 of 9 in a series about Migrating from BlogSpot to Octopress.

Now that I've migrated to Octopress, I'm in the process of finding my new blogging flow.

I'm currently editing markdown post drafts in a DropBox folder. I have been leveraging some of the following tools to write MarkDown.

My worry is that some of these don't have the best spell-check support - so here's hoping I double-check my work along the way :P.

Migrating from BlogSpot to Octopress - Part 8 - Redirect Atom/RSS in FeedBurner


warning I've migrated away from Octopress and this site is now built using ToggleJS with a custom GulpJS file. warning

This article is Part 8 of 9 in a series about Migrating from BlogSpot to Octopress.

This one is quick and easy.

I noticed that my original RSS feed was 302 redirecting to

So I went to where I was already logged in (due to being auth'd with google/blogger) and from their I selected my feed and chose Edit Feed Details where I could put in my new RSS feed to

After doing this, I noticed 3 of my previously posted blogs show-up-again, but I can live with that.

Now you've hopefully migrated your blog's RSS subscribers automatically without loosing any.

Migrating from BlogSpot to Octopress - Part 7 - Setup a Custom Domain


warning I've migrated away from Octopress and this site is now built using ToggleJS with a custom GulpJS file. warning

This article is Part 7 of 9 in a series about Migrating from BlogSpot to Octopress.

To host your blog for free by GitHub, you are not required to buy a custom domain so this is an optional step, but one I took.

The reason I have a complete post on this topic is primarily to say that I was able to accomplish this while not even at my desk.

While out waiting for my daughter to complete practice, I sat on my iPhone and was able to not only buy the domain name but I also configured the CNAME on GitHub. By the time I got home from my daughters practice, I could hit my blog through the new domain Exciting!

You can use this post for a quick and simple walk through.

Migrating from BlogSpot to Octopress - Part 6 - 301 Redirect Old Posts to New Location


warning I've migrated away from Octopress and this site is now built using ToggleJS with a custom GulpJS file. warning

This article is Part 6 of 9 in a series about Migrating from BlogSpot to Octopress.

So far we have mostly delt with getting the old blog content into our new Octopress blog. In this post I'll talk about how I setup automatic redirection from the old blog to the new blog.

Sorry, this post gets a little long, mostly because there is lots evolved, and I took some time to explain it along the way.

So, I'm not an SEO expert or even novice, and I hope the steps I took below actually gave me my end goal. I think they did, but let's not get ahead of ourselves. If you have any feedback, please drop me a line in the comments or in a github issue for this blog.

Reasons for redirection:

  • I'd like people to arrive at my new site even if they followed a link to the old BlogSpot location and get all the benefits of the new site (new theme, broken links fixed, etc)
  • The whole reason I did this was to 'migrate' not, start fresh.

I probably won't ever delete my blog due to outside blogs, articles and sites that have linked to posts I've made in the past, but at least they will end up at my new blog.

Goals for the redirection.

  • Users who click on a link to the old blog should redirect successfully to the new site.

  • I would love it if Google and other search engines could follow a 301 Moved Permanently redirection with the hopes that my old blog's search rankings would carry over to my new blog.

    DISCLAIMER: Given the steps in the post, I'm not 100% confident that this goal was accomplished, but I think it may have worked (maybe, possibly, ???)

Now, while I'm not 100% confident my search rankings carried over, I'm fairly confident that Google found out about my new blog because after just 2 days of the below steps being implemented, Google had already indexed the new site.

What's involved for redirection?

  1. Tell BlogSpot to redirect each post at to the new location.
  2. Handle that redirection on the Octopress side.

There are a number of posts out there that describe how to accomplish this with WordPress or other blogs that can host a dynamic server side component. However with Octopress or other statically generated sites we don't have as easy a time. I belive this has more to do with the lack of programmability on the BlogSpot side (or my lack of knowledge of how far you can go with it on their side) than the static-ness of our Octopress blog.

Let's get into why this wasn't as straight forward.

If you look at how to redirect from a BlogSpot blog to say WordPress you'll see that they are basically passing the FULL original url EX: to a server-side component, where it can dynamically translate that into the correct 301 redirect response needed for each page.

The problem we have is the BlogSpot template tags are limited. They don't provide a relative blog url parameter which would have made it easy. Instead they provide only the full URL <$BlogItemURL$> which we can't use on our static site.

The direction I took was to use the <$BlogItemNumber$> which is like a really long id value, leverage the Jekyll alias generator and end up doing two redirects.

  1. from -><$BlogItemNumber$>
  2. then from<$BlogItemNumber$> ->

On the Octopress side we are going to leverage the alias plugin. Once that's installed, we need to update all of our blog posts to add in the 'alias' that will point to th e/blog/{really_long_id}. My scripting hammer isPowerShell*(sorry if you're reading this on a mac - hey, maybe [Pash]( can help you if you're not on Windows)* and I wrote the below script to help in the task. Even if you don't knowPowerShell`, take a moment to read the comments in the code to get an idea of what it is doing.

In summary, the above code is:

  1. Parsing the blogger xml
  2. Extracting the post url (slug) and BlogSpot blog id
  3. Matching each post with a post in our Octopress _posts that we recently exported
  4. And injecting an alias: /blog/{id} into the header YAML

Look in your blogger xml for a sample ID, it looks like


What we care about is the BigNumber after the "". This is the id used in the above script to generate our new /blog/<BitNumber> alias url.

If you completed the above and run rake generate and rake preview, test out that your redirections are correct.

After I completed this and on my blog, should redirect me to an actual post.

Once you're happy with your Octopress's blogger redirections, SHIP IT. Publish them to your blog and test them out on gihub rake gen_deploy.

Now that we have our static site redirecting the special /blog/{id} url's, we can go back to BlogSpot and update our template to redirect to our static site.

I used the below template (note search/replace your domain etc) before dropping this into your site.

Update Blogger template to redirect.

  1. Go back to your BlogSpot admin page and select the Template tab.
  2. On the lower right you may have to select (forgetting the exact text - but something like) Revert to classic template
  3. Modify the below template for your own site.

This will change all pages/posts on your old BlogSpot site (even your home page). You can now go test it out - see that it hopefully transitions you from your blogger site -> to the new static redirect - and then to your final post location. It happens so fast I sometimes don't see the middle/transition page.

Note: I had to run through this a few times before I got it right so be careful doing this (especially if you have a popular blog as it may interrupt users at the current time). I'm not that cool, so my blog could handle some downtime :P

Migrating from BlogSpot to Octopress - Part 5 - Fix Links


warning I've migrated away from Octopress and this site is now built using ToggleJS with a custom GulpJS file. warning

This article is Part 5 of 9 in a series about Migrating from BlogSpot to Octopress.

Once you've ported your content into Octopress there were several steps I used to fixup links. The two types of links I cared about at this stage were:

  1. Cross-Post links (where I referenced one of my other posts)
  2. Broken links.

Cross post links

I used a text editor and some command line magic to search for and replace it with /blog/ so that my cross-referencing posts could link to a relative version of the blog instead of the full blogspot domain.

Depending on how you configure your permalinks you may need to do some more link manipulation. I had to search .html at the end of my cross-referencign posts and be sure to delete it since my old reference would look like

but now should link to


If you're on Windows and not interested in figuring out a PowerShell or other command to quickly search and replace, a friend of mine Tim Greenfield has a great utility GUI tool for easy search and replace.

I don't recall exactly what I did, I think I either used sed or a python command on my Mac for the initial search/replace. I'll let you figure out the rest of how to get that task done.

Fix broken links

Once you're done fixing up cross-post links, we want to make sure we didn't mess anything up, and while we're at it, fix any old or out-dated links.

One great feature of Octopress is that we can run the site locally and use a spider tool to search for broken links. Run rake generate and rake preview locally to browse your site.

I used the Integrity link checker on my Mac to search the http://localhost:4000 site locally. There are lots of these tools out there, so feel free to use what you feel happy with.

This was a great exercise. Not only debugging any oopsies from the above cross-post fixup step, but allowed me to find any external links to blogs/images/etc that were out of date. I wasn't able to fix up all of my external links, but that's the way of the web unfortunately. I haven't done it yet, but have consider going back and linking the out-dated links to a version out on the Way Back Machine.

Migrating from BlogSpot to Octopress - Part 4 - Import Content into Octopress


warning I've migrated away from Octopress and this site is now built using ToggleJS with a custom GulpJS file. warning

This article is Part 4 of 9 in a series about Migrating from BlogSpot to Octopress.

In the previous post I discussed how to export your blog content from BlogSpot. Now that you have all of your content into a single .xml file, we need to translate that into the files and format that Octopress blog expects.

Translate export xml to Octopress posts

Thanks to a ruby script found in a gist, it's fairly easy to get going provided you are able to leverage all the gem dependencies with your installation of ruby. On Windows this is tricky although fortunately there are tools like yari to help out.

  1. Download and save one of these gists somewhere and call it BloggerImporter.rb
  • Note: there are a number of forks of the script - if one doesn't work, browse other changes and see if something fits your needs.
  1. From the command line go to a temporary folder and execute

    ruby {pathToImporterFile}/BloggerImporter.rb '{PathToBloggerExport}/blog-03-19-2014.xml'

    When I tried it on my windows machine I received the following error. Sorry Windows folks, I don't have answers for every scenario here - I just jumped over to my Mac and tried again. I remember first trying this like a year ago and ran down a similar rat-hole trying to get this dependency to work which is probably why I didn't port it back then. I'm sure it's possible, but wasn't worth my time (since it works on my mac and was a one-time task).

    C:/Ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- nokogiri (LoadE
            from C:/Ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
            from BloggerImporter.rb:2:in `<main>'

    (One possible issue noted by a colleague: the ruby script requires a gem, Nokigiri, which is not supported on Windows by Ruby 2 at the time of this writing. This can be circumvented by either reinstalling Ruby 1.9.3 or by leveraging a tool like yari which allows you to pick the version of Ruby you wish to leverage with a script - a helpful StackOverflow answer exists here.)

  2. You should now you have your content.

    After you've run the BloggerImporter.rb command you should have at least two folders in your temporary folder.

    ~/code/temp> ls
    _drafts     _posts    BloggerImporter.rb

    I didn't end up caring about anything in my _drafts folder, but the _posts folder is full of gold. This contains all of your exported content now broken out into a separate file per post in the form of {year}-{month}-{day}-{title}.html.

  3. Copy this content into the Octopress blog folder under source/_posts/

  4. At this point you've successfully ported your content into your Octopress blog. Make sure you take tiny steps and git commit... the changes you care about along the way...

  5. Use rake generate and rake preview to see if it worked.

  6. If your preview looks right use rake deploy to put your changes on github.

Hopefully it all worked out and you're looking at your new Octopress blog with your old content all there. If I recall when I went through this process, there was one HTML file that Jekyll had issues compiling. I probably just modified the post or deleted somethign that wasn't necessary (I can't recall anymore) but it was quick to work through.

side note: When I initially tried getting Disqus to work after this and had trouble. Turned out this was because in the YAML metadata in each post comments: false :)

Migrating from BlogSpot to Octopress - Part 3 - Export BlogSpot Content


warning I've migrated away from Octopress and this site is now built using ToggleJS with a custom GulpJS file. warning

This article is Part 3 of 9 in a series about Migrating from BlogSpot to Octopress.

Thanks to Google for allowing us to export our own content and providing an easy way to get it all in one download. If we had to go manually read each item in an atom feed or web scrape the content off of a web page, this small series would be more like a novel...

Steps to export content.

  1. Log in to your [ admin portal
  2. Go to the Settings tab
  3. Select the Other option under Settings
  4. Under Blog tools select Export blog
  5. Save the file somewhere safe so we can refer to it later

Blogger Settings

What's in this export file?

This file contains the raw content and metadata around each of your blog posts. You won't get any of your images, but all of your original blog images are probably hosted on external sites. This is next on my list of things to add to the port-list (and will possibly extend this series even more). I would like to download each of my images locally, save them to my Octopress git repo and update my posts to link to the local versions of the images (but that's lower on the priority).

Here is a snippet of a single entry from the exported file. In later posts we'll delv deeper into this to extract metadata an setup redirection from BlogSpot to our new blog.

Sample Entry from Blogspot Export File

    <category scheme='' term=''/>
    <title type='text'>Format your .Net exceptions to see the StackTrace.</title>
    <content type='html'>&lt;h4&gt;TL;DR&lt;/h4&gt;  &lt;p&gt;Check out a dinky little &lt;a href="" target="_blank"&gt;Exception Message Beautifier&lt;/a&gt; site I threw together so you can quickly format .net exception messages and easily see the StackTrace.&lt;/p&gt;  &lt;p&gt;&amp;#160;&lt;/p&gt;  &lt;h4&gt;Go to the site: &lt;a href="" target="_blank"&gt;&lt;font size="4"&gt;CLICK HERE&lt;/font&gt;&lt;/a&gt;&lt;/h4&gt;  &lt;p&gt;&amp;#160;&lt;/p&gt;  &lt;h4&gt;Background&lt;/h4&gt;  &lt;p&gt;Over the years, I’ve worked on projects where application exceptions were saved to a SQL database. When querying the logs in Visual Studio or in Sql Management Studio’s table view, I would get a result-set that would not let me copy/paste and review the StackTrace easily. The tool always seemed to leave out the new line characters just like below.&lt;/p&gt;  &lt;blockquote&gt;   &lt;pre&gt;System.Exception: Hello Exception!   at TestExceptionGenerator.Spike.GetException() in c:\Code\personal\DotNetExceptionMessageFormatter\TestExceptionGenerator\Spike.cs:line 22   at TestExceptionGenerator.Spike.b__0() in c:\Code\personal\DotNetExceptionMessageFormatter\TestExceptionGenerator\Spike.cs:line 13   at TestExceptionGenerator.Extensions.GetExceptionString(Action action) in c:\Code\personal\DotNetExceptionMessageFormatter\TestExceptionGenerator\Spike.cs:line 34&lt;/pre&gt;&lt;br /&gt;&lt;/blockquote&gt;&lt;br /&gt;&lt;br /&gt;&lt;p&gt;&amp;#160;&lt;/p&gt;&lt;br /&gt;&lt;br /&gt;&lt;p&gt;Now, I know there are ways to get around this, like exporting to CSV, or setting up the query results to return in text view instead of table view. However, when you’re in the heat of tracking down a bug and don’t feel like you have time to find the settings dialog or open up you’re a text editor like &lt;a href="" target="_blank"&gt;NotePad++&lt;/a&gt; and enter a search/replace as I show below over and over with each exception message you review.&lt;/p&gt;&lt;br /&gt;&lt;br /&gt;&lt;p&gt;&lt;a href=""&gt;&lt;img title="image" style="border-left-width: 0px; border-right-width: 0px; background-image: none; border-bottom-width: 0px; float: none; padding-top: 0px; padding-left: 0px; margin-left: auto; display: block; padding-right: 0px; border-top-width: 0px; margin-right: auto" border="0" alt="image" src="" width="443" height="286" /&gt;&lt;/a&gt;&lt;/p&gt;&lt;br /&gt;&lt;br /&gt;&lt;p&gt;Just so I could see an exception that looked more like:&lt;/p&gt;&lt;br /&gt;&lt;br /&gt;&lt;blockquote&gt;&lt;br /&gt;  &lt;p&gt;System.Exception: Hello Exception! &lt;br /&gt;    &lt;br /&gt;&amp;#160;&amp;#160; at TestExceptionGenerator.Spike.GetException() in …&amp;lt;cut off for brevity&amp;gt; &lt;br /&gt;&lt;br /&gt;    &lt;br /&gt;&amp;#160;&amp;#160; at TestExceptionGenerator.Spike.b__0() in …&amp;lt;cut off for brevity&amp;gt; &lt;br /&gt;&lt;br /&gt;    &lt;br /&gt;&amp;#160;&amp;#160; at TestExceptionGenerator.Extensions.GetExceptionString(Action action) in …&amp;#160;&amp;#160; &lt;/p&gt;&lt;br /&gt;&lt;/blockquote&gt;&lt;br /&gt;&lt;br /&gt;&lt;p&gt;I finally buckled down and threw together a tool for this. &lt;/p&gt;&lt;br /&gt;&lt;br /&gt;&lt;h3&gt;You can check go check out &lt;a href="" target="_blank"&gt;Exception Message Beautifier&lt;/a&gt; where you can see the sample below.&lt;/h3&gt;&lt;br /&gt;&lt;br /&gt;&lt;p&gt;&amp;#160;&lt;/p&gt;&lt;br /&gt;&lt;br /&gt;&lt;p&gt;&lt;a href=""&gt;&lt;img title="image" style="border-left-width: 0px; border-right-width: 0px; background-image: none; border-bottom-width: 0px; float: none; padding-top: 0px; padding-left: 0px; margin-left: auto; display: block; padding-right: 0px; border-top-width: 0px; margin-right: auto" border="0" alt="image" src="" width="689" height="354" /&gt;&lt;/a&gt;&lt;/p&gt;&lt;br /&gt;&lt;br /&gt;&lt;p&gt;&amp;#160;&lt;/p&gt;&lt;br /&gt;&lt;br /&gt;&lt;h4&gt;I’d like to thank.&lt;/h4&gt;&lt;br /&gt;&lt;br /&gt;&lt;p&gt;Below are a list of tools/resources I leveraged to put the site together relatively quickly over the weekend.&lt;/p&gt;&lt;br /&gt;&lt;br /&gt;&lt;ul&gt;&lt;br /&gt;  &lt;li&gt;&lt;a href="" target="_blank"&gt;;/a&gt; where I first prototyped/built my site before porting it into the GitHub pages. &lt;/li&gt;&lt;br /&gt;&lt;br /&gt;  &lt;li&gt;&lt;a href="" target="_blank"&gt;GitHub&lt;/a&gt; for providing us with &lt;a href="" target="_blank"&gt;GitHub Pages&lt;/a&gt;. Made this site a piece of cake to setup. &lt;/li&gt;&lt;br /&gt;&lt;br /&gt;  &lt;li&gt;&lt;a href="" target="_blank"&gt;Approvals.NodeJS&lt;/a&gt; – easily test/verify output. (&lt;em&gt;Disclaimer – I created this nodejs port of &lt;a href="" target="_blank"&gt;Approvals&lt;/a&gt; for fun a while back and didn’t get around to throwing some polish on the library till now, where I was able to &lt;a href="" target="_blank"&gt;dog-food&lt;/a&gt; it&lt;/em&gt;) &lt;img class="wlEmoticon wlEmoticon-smile" style="border-top-style: none; border-bottom-style: none; border-right-style: none; border-left-style: none" alt="Smile" src="" /&gt; &lt;/li&gt;&lt;br /&gt;&lt;br /&gt;  &lt;li&gt;&lt;a href="" target="_blank"&gt;AngularJS&lt;/a&gt; (a bit overkill for this site, OK TOTAL OVERKILL, but was simple, easy, makes my JS very little, and will allow for easy growth down the road if it needs to.) &lt;/li&gt;&lt;br /&gt;&lt;br /&gt;  &lt;li&gt;&lt;a href="" target="_blank"&gt;Google CDN&lt;/a&gt; for hosting AngularJS &lt;/li&gt;&lt;br /&gt;&lt;br /&gt;  &lt;li&gt;&lt;a href="" target="_blank"&gt;Google Analytics&lt;/a&gt; (so I can see if anyone cares) &lt;/li&gt;&lt;br /&gt;&lt;/ul&gt;&lt;br /&gt;&lt;br /&gt;&lt;ul&gt;If you take a look, find a bug. Submit a GitHub issue and/or a pull request. Or if you find it useful, feel free to let me know.&lt;/ul&gt;&lt;br /&gt;&lt;br /&gt;&lt;ul&gt;Enjoy!&lt;/ul&gt;  </content>
    <link rel='replies' type='application/atom+xml' href='' title='Post Comments'/>
    <link rel='replies' type='text/html' href=';postID=7515836382847059837' title='0 Comments'/>
    <link rel='edit' type='application/atom+xml' href=''/>
    <link rel='self' type='application/atom+xml' href=''/>
    <link rel='alternate' type='text/html' href='' title='Format your .Net exceptions to see the StackTrace.'/>
      <name>Jason Jarrett</name>
      <email>[email protected]</email>
      <gd:image rel='' width='32' height='32' src='//'/>
    <media:thumbnail xmlns:media='' url='' height='72' width='72'/>

Migrating from BlogSpot to Octopress - Part 2 - Setup Octopress


warning I've migrated away from Octopress and this site is now built using ToggleJS with a custom GulpJS file. warning

This article is Part 2 of 9 in a series about Migrating from BlogSpot to Octopress.

Luckily for all of us, this post will be short as the Octopress Setup guide is a great place to start. Only additions I have to add are that I've set this up on both a Mac and a Windows 8 machine.

I had to execute the rake setup_github_pages[repo] on both machines. I should probably look under the abstraction and understand a little deeper - but I'll have to save that for later. For now I have work to do...

On my Mac:

  • Things worked out quite smoothly on the Mac.
  • This is where I ran my initial import of the blog (see later posts in the series).

On my Windows 8 machine:

  • This environment seemed harder to get going
  • The hardest part on Windows 8 was getting the right combination of ruby, ruby dev kit, and various other dependencies installed. The dependencies for Octopress installation are compatible with later versions of Ruby but the gems needed for blog import are only supported in Ruby 1.9.3 at the time of this writing. Since I don't use Ruby on Windows for anything else, I eventually ended up uninstalling all versions I'd previously had (including cleaning up any environment path variables). Re-installing just what I needed and eventually got it working. Another route is to use Scott Muc's yari which allows you to toggle the version of Ruby that you're using.
  • Thanks to this post to get started on the windows. Some steps I excluded since I'd alredy setup the blog initially on my Mac.

Now I can use the power of git to manage my website and blog and I can leverage whatever development tools I would like depending on the platform. If you are new to Octopress it is helpful to study the documentation and structure of the files within your cloned repository. The first thing to note is that you have two branches in the repository: the source branch contains the Ruby scripts and utilities you will use to generate your blog content. The master branch is where your published content will live. The second thing to note is that while you can do the git integrations yourself for deploying the blog, it is best to stick to the RAKE task for deploying your content. This will automate copying your content to the _deploy subdirectory and pushing the update to the master branch.

Migrating from BlogSpot to Octopress - Part 1 - Introduction


warning I've migrated away from Octopress and this site is now built using ToggleJS with a custom GulpJS file. warning

After hosting my blog on for over 5 years, it was time to move.

As someone with the development background I have and constantly growing knowledge of the web, it always bugged me that my blog was hosted on BlogSpot.

When I first started blogging over 5 years ago, it was a great starter site. Free, simple, easy to configure and it was a great place to throw content up with very little friction. But my desire to write posts using Markdown, host my content on a site where I felt like I had complete control, and lets face it, I just wanted a codebase I could tinker with and throw up coding experiments.

I recently completed migration of my site to its new location here on which is graciously being hosted for free by GitHub.

If you currently have a blog on BlogSpot/Blogger and are interested in migrating to Octopress or any other blog, the following series of posts may be of use.

This article is Part 1 of 9 in a series about Migrating from BlogSpot to Octopress.

rake, psake, grunt, gulp, jake, make, cake, brunch, ant, bash, maven, or fabric. as long as you putOnAHelmet

A standard task I began placing in my projects lately is one that easily integrates with my build tool of choice (rake, psake, etc…) and when run, installs a git pre-commit hook into my local copy of the repo that will run tests before code is committ. I’ve fancied calling the task putOnAHelmet.

Come checkout a small little github repo I started to keep track of various versions of this and feel free to open an issue or send a pull request with another one!

I don’t want to get into details about pre-commit hooks and how you should author them in this post (maybe we can expand the language in the repo’s readme…). You can also check out other writings… But one of the biggest problems I have with them is gits in-ability to easily keep track of pre-commit hooks much like it can with the rest of the projects source.

Now it’s true that different people need the ability to customize these, but a general “running of tests” before committing is a great first step and I’ve found these set of tasks the easiest way to carry them from repo to repo.

Hope others find this useful!

Happy committing!