Website updated, finally!
Saturday, April 09, 2022
It’s been a long time coming, but coobird.net has seen it’s biggest update in more than a decade! Well, content-wise, very little has changed, aside from removing a few sections relying on Java applets which no longer are supported by most it not all browsers today.
In today’s post, I’ll get into the background of why it has taken so long to change anything on coobird.net.
History of the site
coobird.net first appeared on the WWW in 2005 when I was still a university student. I wanted to have my own website for a long time and finally bit the bullet and signed up for shared hosting.
Back then, I was writing the site in a text editor1 because I had time and wanted full-control of the content.
« Note to self: Find any screenshots of an older version of the site, because the Internet Archives doesn’t have them. 😛 »
I was proud of writing lean, clean pages and style sheets. In my opinion, automatically generated HTML and CSS from content management systems (CMS) weren’t great. Inconsistent formatting, lots of extraneous blocks, sometimes not employing proper use of style sheets. I went as far as writing well-formed pages and style sheets by running them through XHTML 1.1 and CSS validation service offered by the W3C.
But I knew that spending time to write well-formed websites by hand wasn’t scalable, so I was seeking solutions for revamping the website.
Attempts at revamping the site
There have been efforts on and off to revamp coobird.net. However, it would generally come to a halt due to scope-creep.
Back around 2009, I started to work on a full-blown CMS using Django2. I wanted to edit articles in both English and Japanese, so I created models accordingly. Here’s a snippet from the model class for articles. Note how articles had bodies with differing languages as a first-class concept.
class ArticleBody(models.Model): LANGUAGE_CHOICES = (settings.__getattr__('SUPPORTED_LANGUAGES')) localized_title = models.CharField(max_length=200) # ... language = models.CharField(max_length=40, choices=LANGUAGE_CHOICES) text = models.TextField() # ... class Article(models.Model): title = models.CharField(max_length=200) # ... body = models.ManyToManyField(ArticleBody) # ...
Since I was writing a CMS for myself, I wanted it to be customized to meet my needs. As mentioned earlier, reducing effort to write articles was a priority, so an attempt was made to integrate TinyMCE.
But then, Stack Overflow happened.
After being completed sucked into the gamification of the site, I found writing in Markdown was very pleasant.3
At some point, Stack Overflow started offering a live-preview of questions and answers in browser using an editor called WMD. So, WMD was incorporated into the admin interface to edit articles.
Next thing to consider was hosting. The shared hosting service did not support Python, which Django uses. For hosting, I signed up for a VPS that eventually was acquired by Rackspace. But I never got around to deploying the application because it was only partially complete. Furthermore, I had to consider the security aspects of having a web application on the Web. Add to that the resource consumption angle because, hey, what happens if my site makes it BIG.
There we go. Scope creep killed the revamp attempts.
Concerns of backwards compatibility
And for a while, coobird.net has basically been static.
No new projects were added, even though I continued to work on several side projects. I’ve had the itch to write about those, but “it’s just not the right format” has always been getting in the way.
Add to that the concerns about backwards compatibility. The W3C was saying that Cool URIs don’t change and made it sound like changing URLs was akin to blasphemy. This added to the burden of trying to come up a “better way” to publish coobird.net
And a decade has gone by without any updates…
Dr. Jekyll or: How I Learned to Stop Worrying and Love the Static Site Generator
Let’s face it.
My website is not anything mission critical, changing URLs isn’t going to cause anyone any problems. Nor does it serve many people or super important content. Changing URLs of existing pages isn’t going to cause the sun stop shining.4 Let’s move on and set up a framework to allow me to write more content.
A few months pack, I decided to use Jekyll, a static site generator, to rebuild coobird.net Static site generation eliminates all the problems associated with maintaining a web application. No extra things to think about; it’s just static files that need to deployed to the web server.
And here we are. A revamped coobird.net, where I can focus on editing content, and stop worrying about the other details. Now, all I need to do is write up pages in Markdown and push those changes.
This is before Django reached 1.0. I still have a tarball of 0.96.2 in the backup directory, not so aptly named “current” 😛 ↩
It shouldn’t come as a surprise that I’m writing this site in Markdown right now. 😉 ↩
That said, the majority of contents from the previous iteration of the site still reside at the same URLs. ↩