… or
What I’ve Learned from My Blogs
It was every Sunday afternoon for as far back as I can remember. After
we got home from church, after a sumptuous Sunday dinner of roast
beef, potatoes and carrots, after doing the dishes, after finding the
best among the rerunning Sunday afternoon movies, my mom would sit
down in the living room, pad of paper and pen in hand to write a
letter to her mother, my grandmother. I can only imagine she wrote
about the adventures and discoveries of her life like she still does
on her current blog.
When I went away to college, I wrote letters to my mom and dad. Not
every single Sunday. But often. On a visit to my parents a couple
years ago, my mother handed me a bulging gallon size plastic bag
stuffed full of papers. They were my letters. Over time, though, the
number of letters dwindled. And dwindled again. I just couldn’t keep
up with the Sunday schedule. And so, my first blog was born.
Blosxom — 8/2005
I’ll see if additional data is easy to add and then, I’ll put
pictures here.Perhaps my mom will have an easier time seeing these in
Blog format than in e-mail.
With these words, I opened a blog. But it wasn’t just a vehicle for
sending messages to my mother and avoiding the Sunday afternoon guilty
feeling that I should be writing a letter, buying a stamp and stuffing
an envelope. It was a learning tool.
Bloxsom was chosen to help me learn more
about one thing, PERL. Bloxsom is written in
PERL, a language in which I’d just finished a
project, tSmoke, and contributed to
Smokeping, a network latency
graphing tool. I learned a lot writing software in PERL. The most
meaningful thing was that PERL is one of those Write Only programming
languages. Meaningful in that I
found that the longer I didn’t write in PERL, the less likely I was to
remember what in the heck I intended.
The content on the Bloxsom blog was text with HTML snippets to markup,
or instructions for displayting the text. It is pretty simple and
pretty straightforward. Each entry was a single text file. No database
required.
About this time, I helped set up a collaboration tool for a group. I
discovered the power of the Wiki and in particular, OddMuse Wiki
software. OddMuse is pretty
cool and shares some features in common with Bloxsom. First of all
there is no back-end database, just text files. The markup is
different, it’s Creole, a common Wiki
markup language. One feature I liked about OddMuse was its descent
from a previous version of Perl blogging application called
Usemod. You"ve gotta love the
clever pun. Right?
I always had to be cognizant of that blog running in the background on
my computer. The Abyss Web Server
was always running on my computer, using up resources, chewing up
memory, spitting out blog posts. And there was always the off chance
that my mom would be looking for my blog when I rebooted. I decided I
needed to learn something else. That’s when I found Blojsom.
Blojsom — 6/2006
I upgraded my blogging platform in two ways. First of all, I thought
I’d use an enterprise-grade coding platform, you know, Java. Second, I
thought I’d find a way to run it on an available second machine – not
the best in the world, mind you, but available. After researching
blogging software, I came across
Blojsom both bills. At
that time, Blojsom was a reasonably new bit of code, written in Java
and provided as a .WAR (Web Application Archive) file for deployment
as a Java web application on a servlet container like
RESIN.
I liked Blojsom a lot. First of all, the data migration took no effort
at all. Blojsom, after all, was designed to use the same text format
as Bloxsom. Since there was no back-end server, I did not have to
worry about overloading the light weight “server.” And with Resin as
an underlying web server, I could learn a lot about how Java programs,
Java Server Pages (JSP) work. One still undone item on my to do list
asks me to “Write a How-To on Blojsom Plugins.” Someday. Maybe.
In February, 2006, I decided to upgrade the OddMuse wiki to something
a little more usable and with some additional security. After some
research I chose PMWiki. PMWiki didn’t use
the Creole markup, but a form of markup that favors writers over
readers, but was still similar enough that it was a straightfoward
migration. It did not require a back-end database either and allowed
plain text files. All of these features compensated for the fact that
I had to learn to use one more programming language,
PHP, to effectively operate it.
Wordpress, Yes, Wordpress — 8/2008
It was about late summer in Atlanta when I started getting regular
emails from my mother on odd Wednesday mornings telling me that my
blog was down. It would not have been nearly so stressful if it
weren’t for the fact that she is in the Central time zone and I am in
the Eastern time zone. So by the time she checked my blog, I was
already at work and my hands were tied! I spent a few weeks
troubleshooting and never found anything really wrong. Then, sure
enough, the very next Wednesday, I got another email and I finally
understood. You see, the blog was running on Resin web server which
was running as a service on a Windows XP machine (the not very
powerful, remember?). So the first Tuesday of every month, Microsoft
would push security updates to the computer and it would reboot… or
try to. I decided it was time to move to another platform. One that
didn’t depend on my Comcast account being active or the ability of a
Windows XP machine to automatically shut down a running Java service.
With Wordpress, I didn’t have to learn a new markup language, its
built-in editor took care of adding the appropriate HTML formatting.
better, Wordpress was hosted out there somewhere on the Internet. My
mom never had to alert me that my machine had failed a Microsoft patch
Tuesday reboot again. i could concentrate on the content and not on
the technology.
But then along came Twitter and Jaiku and Identica and Plurk and
FriendFeed. Naturally I wanted to notify all my “friends” that I’d
posted a clever tome, right? But how oh, how do I update them all? It
seemed a terrible quandry.
Along Comes Posterous — 2/2010
I started using Posterous in Spring, almost giddy that I could post to
all my social media simply by sending an email. The simplified
hosting, the ease of markup and the simplicity of editing are good
stuff. But outside the names of the plethora of social media, what was
I learning?
Side trip Down Markup Lane
All these endeavors had a common, underlying theme: the markup. The
purpose of markup was to tell a device how to display the content it
was showing off. I’d used several kinds of markup. My first
introduction to a markup language was the one built into the core of
Peachtext, the editing component of a word processing package
developed by Peachtree Software called Peachtext
5000
where I worked back in 1983. Then, the markup controlled not the font
decoration, font size or type face but how the text was physically
printed on paper. For example, bold facing was often achieved by
having the print head backspace and reprint the characters. If the
printer was capable of kerning
and proportional fonts, it would be slightly offset from the original
to really emphasize the boldface.
Apple’s MacIntosh permitted screens to display fancy fonts and this
new fangled HTML thing did the same thing. Heck you could even make
your text blink if you wanted to. But no does that. right? But HTML
doesn’t look very nice. In fact, it’s really hard to write in – at
least with old skool text editors like Peachtext and VIM. So John
Gruber came up with a method to use regular characters to take the
place of markup in a text file and convert it into HTML. He called it
Markdown. Clever, eh?
Of course this wasn’t the only attempt to make it easy to write
marked up text which could easily be converted into HTML.
Textile which, to be honest,
looks a lot more like Peachtext than Markdown does, is supposed to be
the “Humane web text generator” from Dean Allen. Of course, someone
came up with one called “Markdown Extra.” The grandfather of them all
is TeX(http://www.tug.org/texshowcase/) created by Donald Knuth. I’ve
recently stumbled on the one called
Showdown which lets you do the markup
conversion right inside your web browser.
Mythical Holy Grail: A Blog with No Home
What am I really looking for now? Well, now that’s a good question.
With the advent of tablets over laptops, my real desire is a blog with
no home.
I want to put my data on a cloud provider, access it from anywhere
using my tablet, my phone, my work computer, my home laptop or
whatever, then compile the source formatting into HTML and copy it
from the repository provider to a web server.
That’s kind of the goal of Jekyll
and its cousin Octopress. These allow you to
create a repository for your blog on your own computer, compile it to
static HTML pages, push it to GitHub
Pages– and publish it using their
facilities. It’s clever. Very clever. Calepin
takes this one step further, incorporating its anagram Markdown
conversion tool,
Pelican
written in Python to pull files from your
Dropbox account and publish them for you in
HTML. Even cleverer. I’ve posted a couple of delicious
items there myself. But I still have to
hook up my computer, some computer, to Dropbox. The
GitHub/Jekyll/OctoPress also really want you to create a “local”
repository. Meaning that if you don’t have access to your computer,
you can’t write.
Cloud9 – The Future
I’ve been using Cloud9 IDE to write some
software recently. It’s connected to GitHub out of the box. It’s not
hosted on my local system. So I effectively have a clever editor and
access to my GiHub account wherever I am. I have even
tested a Jekyll web page written solely
on Cloud9, and pushed to GitHub. Yes folks, there was no local storage
involved with this trick. My fingers never left my hands (or the
keyboard). Two other things keep me from moving to this technique.
The editing features at Cloud9 do not work with an iPad. At all. It’s
not like I haven’t asked. Nicely, even. It just doesn’t work. Sigh.
It’s free, what are you going to do? It’s not like it’s open source so
I could write my own interface. Oh, right. It
is. But then I’d have to host my
own instance of it, and defeat the whole purpose.
I’d really like to do a test post on Cloud9 so I could see the copy
before it gets published. But this would require me to be able to run
a script on Cloud9 and save the output as a file. That also doesn’t
work. But we’re close.
We’re almost there, mom! A cloud-based blog that I can update any
given Sunday (no matter what the football teams are doing) is right
around the corner. And what have I learned? It’s a lot of work to
publish a blog. The more work I can get the cloud to do, the better.
And even if it takes a lot of work to ge them to do it, it will be
worth it. Although some times, I feel like just getting out a pen and
paper and stuffing an envelope.
Oh, and just so you know… this is/was a test of how well Posterous
accepts Markdown.
Years ago I told my brother I’d make a website for him. My sister
beat me to it. While I was cleaning out my
2011 todo list I came across the
lingering promise. Right below it was another longstanding item the
desperately needed
cleaning out, Experiment with Jekyll on GitHub. Hmmmm… why not
combine the two of them?
