Writing a Blog Generator

I’ve been reading through the Structure and Interpretation of Computer Programs a fair bit these past few weeks and it’s got me thinking about program design and the “shapes” of programs quite a bit. I was itching to apply this perspective on programming to something concrete, so I began thinking about what my next project might be. As I was reviewing some of my fellow Viking Code School cohort members’ personal websites, I found one. One of them had used a service called Jekyll to generate their blog, and I decided to visit it’s documentation to see if it was possible for me to recreate my own version given my current skill level. Indeed it was, so over the past week I’ve spent my time creating an application that mirrors Jekyll’s functionality as closely as I can manage.

Essentially, what Jekyll does is take the user’s blog posts as input, and then return ready-to-publish HTML and CSS files as output. It includes some auxiliary features, but that’s the core of it.

I decided up front to base my high-level design decisions off my own knowledge instead of just mirroring how Jekyll did it. I’m happy I set this stipulation because it ultimately forced me to push myself. Then again, I had a pretty good idea of what the project would likely require. It was a little like I had all of the pieces to the puzzle, I just needed to figure out how to fit them together. For instance, I knew that I could create reusable html templates with ruby’s erb class and I also knew that my ruby skills were good enough to handle any string formatting that might be necessary. So I set out to make a blog generator, confident that with my previous experience and a little bit of google-fu to glue everything together, I could produce something worth using.

Putting it all together

My first task involved creating some ruby scripts capable of reading in blog posts from a supplied “posts” directory. This phase of the process gave me a chance to become pretty familiar with ruby’s IO and File Classes. This was pretty exciting to me because IO is a kind of milestone if you think about it. It’s the bridge between the sort of “black-box” approach when you’re only writing ruby scripts and a more involved one when you begin to interface with the rest of the computer.

From IO, I moved on to creating the erb templates that would serve to present the information that my ruby scripts so graciously gathered for them. These were fairly straightfoward, save for one major detail concerning how to go about actually passing data from scripts to templates. After doing a little research, I decided that YAML would serve my purposes. YAML is a recursive acronym for “YAML Ain’t Markup Language.” It is used to “serialize” data down into the YAML format which can then be written to and read back from a file at which time it can be “de-serialized” into its original form. I’m still not convinced this is the best way to pass information from a ruby file to an erb file, but it’s the best I’ve found so far and overall, it’s worked fairly well.

And so with that last piece of the puzzle, I was able to put it all together into something resembling a usable piece of software! There are still some areas that I’d like to refactor once I get the chance, like the way posts are required to be formatted before they can be read into the ruby scripts. Currently, the user must format posts in a “pseudo-HTML” fashion, e.g. headers are wrapped in <h1></h1> tags, post dates in <p class=”date”></p> tags and so on.

The finished product

Since implementing it this way I’ve gone back and looked at the way Jekyll decided to address it. Jekyll uses something called YAML Frontmatter, that allows you to specify how you want your posts formatted. I think this is more appropriate because it doesn’t assume the user knows HTML, thus making a for a friendlier application.

Looking Back

As for ways I intend to refine my code-writing in the future, tests are chief among them. Throughout the writing of my blog generator I employed a sort of run-in-erb, run-in-production cycle when ironing out bugs. This was pretty inefficient, and even while I was doing it, I knew that writing tests would be a superior approach. Unfortunately, I haven’t taken the time out to learn Rspec cold, though I’m sure we’ll cover it thoroughly once Viking Code School begins.

Overall I’m really happy I did this project. Going from idea to production ready code feels great, especially since I did it without too much outside guidance. Ultimately, this is how it’s done on the job, so I’m happy that I’m getting some relevant experience now.

If you’d like to check out the project you can find the repo over here.