Blurring Static And Dynamic Blogs

Static Blogging

I've discussed the pros and cons about static blogging many times before. In summary, the cons are that, well that your blog is static. No surprise there.

Fortunately, there are ways to push the limits of static blogging so that it is not quite so static.

Website Hosting

Unless you are self-hosting your Octopress or Jekyll blog, you are using another site to host your blog. I host mine on Github. They have a web server running 24x7 to host it. But that's not my problem. I just use their (free) services.

I understand that website hosting isn't a terribly exciting example of stretching the bubble of static blogging, but it is an example nonetheless. Dynamic blogs require specialized software running on their hosting computer to work. Static blogs tend to be able to run on generic web servers but there still must be a web server or there's no blog.

JavaScript Helps

Out of the box, Octopress comes with some features to show your most recent tweets as well as recent activity within your Github repositories. This is dynamic data that Octopress implements with some JavaScript.

Just to be clear, by dynamic data I mean that the data displayed on the page may change without a republication of the blog. I am not necessarily referring to a scrolling widget or something. Just dynamic data.

Conversely, JavaScript can be used to dynamically display static data. That is, data that is embedded in the source of the web page. Being that the data is embedded in the page's source at or before publication time, it is assuredly static data.

But client-side JavaScript (ie: JavaScript running in the user's browser) has its limits. For example, if you want to send a tweet whenever you add a new blog entry, client-side JavaScript is going to have a hard time at it.

Octopress Is Pretty Great

Jekyll Overview

I have simply fallen in love with Octopress. I think I mentioned previously that Octopress is an auto-configuration tool wrapped around Jekyll. And Jekyll is the technology behind Github pages. As such, if you use Jekyll for your blogging platform, you can preview your blog locally, push it to Github, and let Github do all the page serving.

This isn't actually as much work for the Github servers as you may think. Jekyll is a static blogging system with no CMS support. A static blog needs to be compiled whenever content is modified, but once compiled, the only thing the server needs to do is serve the pages. Dynamic blogging systems such as Wordpress and Joomla are programs that run on the server and work interactively with the web server to produce each page.

Configuration

Octopress's biggest addition to Jekyll is that it automagically configures Jekyll for you. I have found that configuring Jekyll is a bit of a pain. Jekyll decided to trade easy configuration for flexibility. This is a common decision in applications and one I can't really argue with.

My First Ruby Project

The Project

Typically, even my pet projects have a specific goal in mind. I don't write a spec for my personal projects, there's just a, maybe slightly fuzzy, goal. Generally I want something that will be useful. I'll work on a project until:

• The project does everything I hoped for. Maybe even more!
  
• I run out of spare time to work on it. This doesn't happen as often as you may imagine. I really enjoy coding. So, after a tiring day of coding at the office, I come home to relax and work on one of my pet projects. If it was any different, then I have no right to call my blog My Geekdom.
  
• I decide that I did a poor job picking a pet project as they're supposed to be fun and this projects isn't. So long!
  
• I get stuck such that proceeding will require more effort than I feel it's worth. That said, hopefully I learned something working on the project.
  

But, unlike my typical pet projects, my goal with my new project is rather amorphous. I want to analyze some data. At time of writing this, I have just shy of 5K records totally 181MB of data.

Leaving the details for a later posting, each record is a snapshot of the state of my Mac OS X computer. I've been collecting, and am continuing to collect, samples every five minutes since the beginning of March. At least every five minutes that my computer isn't sleeping or hanging.

I decided to collect the samples because I was getting downright frustrated with the performance of Mozilla's Firefox browser. For reasons that are off-topic for this posting, I feel a strong interest in making sure that Firefox continues to be successful.

For years I thought Firefox was the bomb. Starting about 9-12 months ago I started to notice that Firefox was routinely using all the resources on my computer. This concerned me because Google's Chrome browser was starting to have enough functionality to be a primary browser.

Being that I wanted Firefox to stay competitive, I decided to try to stay with it. As Mozilla changed their release model, I started to use Aurora and Firefox Beta and provide lots of feedback. The newer versions also seemed to consume a more reasonable amount of my computer's resources. Being that the Firefox team was working hard at fixing performance problems, especially memory leaks, I stayed with Firefox. (See Reference: Articles About Firefox's Memory Leaks And Repair Efforts for information about FF's memory leaks.)

Org-Mode + t Makes Tweeting Easy

Update 2012-06-04 Mon 00:57

You can download the code from its Github repository.

Motivation

After yesterday's ranting about Octopress, it occurred to me that while I now own the content of my blog postings, I don't own the content of my tweets. I'm sure that there's some way to convince Twitter to give me my tweets, but why should I rely on them to store my tweets.

The obvious answer is that my tweets should be created on my computer and then sent to Twitter.

It should be noted that I'm not interested in implementing a full Twitter client. There are more than enough of those. I'm interested in having my tweets, or at least the bulk of my tweets, in a simple and easily accessible format.

The Answer Must Be Cheap

While I want to author and store my tweets locally, it is not a high priority task for me. Whatever solution I come up with must add little or no overhead to my tweeting workflow, must be simple to implement, and cannot require ongoing tinkering to keep working.

Being that my relationship with Org Mode is rather simple: The more I learn about it the more of my life I want to be based on Org Mode. Org Mode just seems to make everything easier. So I decided to use Org Mode for the author, publication, and storage of my tweets. The system I'm describing has these properties:

• It took me just a few hours to design, implement, test, and begin using it for tweeting.
  
• Besides not adding overhead to my tweeting, it has made tweeting dramatically simpler.
  
• The entire implementation is a single file of elisp that is 120 lines long. 50 of those lines are standard Emacs header comments that are automatically created. The implementation, along with its documentation, is only 70 lines long. While a small code base isn't one of my goals, not needing ongoing tinkering is. It is hard to imagine that 70 lines of code will require too much tinkering.