It’s difficult to rein in your ideas and take baby steps when designing anything. The problem is compounded when you build something that is so well known - like a blog. This second post was quite a challenge for me from that perspective.

Features! Features! Features!

Now that I have multiple posts, I want to include the ability for a visitor to go back and forth between them. I also want to make sure that the most recent post is shown first on the home page.

Additionally, there are a few lines of code that I want to share in this post. Therfore, syntax highlighting is the third feature to surface.

Syntax Highlighting

I didn’t think too hard about what I was going to do here. Syntax highlighting is a problem that has been solved. Two notable libraries are SyntaxHighlighter and Prettify. But as you’ll soon notice, I didn’t use either. Or any other for that matter!

Because such tools exist, syntax highlighting is not a risky thing to implement. I had some larger problems that I needed to tackle, and I didn’t want to spend time spiking out syntax highlighters, which in turn would delay getting this content into your hands. It didn’t seem worth it considering all I have to show are a few lines of JavaScript!

So all I did was wrap the code in a code element. It separates the code from the surrounding content, and mimics what code looks like when you read a technical book. It’s an adequate solution for my young blog.

Show the Most Recent Post on Home Page

This one scared the heck out of me. I thought that this "given" of a feature would introduce the need for a database with a table that has a publish date and an ORM and a bunch of other server-side stuff that I really wasn’t ready to introduce. After about two seconds of wild-eyed hyperventilating, a simpler thought occurred to me: files! Yes, files have timestamps. Web servers are pretty good at serving up files. I would just need a little server side code to lookup the right file based on the route and…. And I got really puzzled. And sad. Although not near as many moving parts as the database approach, it’s still way too many to serve up one of only two files on my web site! I thought, what’s the simplest thing that could work, and I came up with this: 

  var posts = [“simplicity-challenged.html”, “geting-naked.html”];
  document.location.href = posts[0];

This code is inside of index.html. With each new blog post, I just need to add the filename to the front of the list, and the page refreshes with it. Now, you might ask me, Why an array? Why not just set the filename? You’re typing it in there anyway… That’s a good question, and the answer is below.

Some blogs keep appending posts to the main page. Some have a list of recent blogs in a sidebar. Some have “next” and “previous” links. And even though I’m not crazy about it, I opted for the links.

There are two reasons that I settled: - I believe I’ll need fancier navigation, but not until I get more posts. - I am by no means a UI expert, so the longer I put that off, the better!

Since I had a list of posts from the "Home Page" feature, implementing the links was really straightforward: 

var createLinkToPost = function(index, link){
  var post = posts[index];
  if(post){
    link.href = ‘http://’ + document.location.host + post;
  }
  else{
    link.style.display = ‘none’;
  }
};



currentIndex = posts.indexOf(document.location.pathname);
createLinkToPost(currentIndex + 1, document.getElementById(‘prevPost’));
createLinkToPost(currentIndex - 1, document.getElementById(‘nextPost’));

And at one point I thought I was going to need jQuery or knockout for this! How quickly we forget how to code…

Sidenote: After this work I realized that the simplest thing would have been to hard-code the links. Afterall, my posts are just static pages… But, I kept this solution anyway. You know, because I’m gonna need it.

Technical Hurdles

Each post in this blog is a standalone html page. Because of this, I am duplicating the entire layout and running the risk of introducing inconsistencies. Code duplication is evil and must be dealt with.

Although I know how to solve this problem using my server-side language of choice, I want to explore other options. For example, I may wish to experiment with a different server side technology, or see if I can get what I need from a client-side SPA framework. I don’t know much about the latter, but I think they can do what I need.

Taking on Some Debt

So I have choices. And the decision I make will likely be with me for a good while. So instead of rushing into a decision, I am going to consciously choose to defer solving the duplication problem. The astute reader will recognize this as technical debt. After watching Ward’s explanation (listen up at 3:30 of the video), you will understand that I am not using “technical debt” as an excuse to be sloppy - but rather to buy me the time I need to figure out the appropriate way to solve the problem.

I also did not write unit tests around the JavaScript. I fully intend to, but I am waiting for a view model to emerge.

A Retrospective

As programmers, we are inundated with the latest and greatest tools and chomp at the bit to put them into use. The urge to institute both client and server frameworks for this second post was great.

But I’m taking the development of this blog a little differently. I want to prove that I will need a framework - to justify it’s added complexity. This is the practice of Simple Design.

This approach is exercising a muscle that I haven’t been using often enough. It’s the muscle that says, take the baby steps. I talk with others about seeing the baby steps, but then play down the critical nature of them. It is important to not only see the steps, but to actually take the time to execute them. One by one. By doing so, you allow yourself to focus. Focus brings about creativity. And with the right mindset, simplicity will emerge.