Moved everything from blogger.com to "here" (https://slott56.github.io).

What did I learn?

BLUF

  1. Don't use WYSIWYG editors. Always use plain text markup.
  2. Think about your categories and tags.
  3. Links rot.
  4. Have a data model and tooling to process entries.

History

Back in the early '00's (up to 2003 or so) blogging was Rocket Science. Consider that https://boingboing.net started to be an online blog in January 2000.

Back then, you needed hosting. And blogging software.

Hosting wasn't as easy as signing up with https://www.a2hosting.com. A2 hosting didn't exist until 2001. Back then it was complicated and expensive. Not for the faint of heart.

Apple offered iBlog which they would host for you on one of their domains like http://homepage.mac.com or some such. See iBlog.

Big. Mistake. (See Big Mistakes, below.)

From about 2004 to 2006 (maybe) there was service called "Bloki", which offered blogging and forum capabilities. That was super-helpful because you could edit on-line.

Big. Mistake. (See Big Mistakes, below.)

By 2008, iBlog had run its course. See iBlog Buggy... Since Leopard's release... No fixes in sight..

By 2009, it appears that I must have consolidated my content onto https://blogspot.com. Which got merged with https://blogger.com at some point later in life. (It's hard to tell, but there were blogspot references scattered through the internal links.)

Why Move?

If https://blogger.com isn't broken, why change?

There aren't any good reasons. Only a few weak reasons.

  1. I have a personal blog, which is not on blogger. It, too, had a long, complex history that went from Apple's iWeb to Sandvox until Sandvox stopped working, forcing me to consolidate into Pelican. See https://itmaybeahack.com/TeamRedCruising2/index.html.
  2. I had been following some folks who were starting blogs, and they didn't like Pelican. They seemed to really like did like Hugo.
  3. In researching Hugo, I found out about how https://github.io can host content, like a blog, with relatively little real work. Mostly git commit and git push.
  4. I'm over on-line editing. I'm retired, living on a boat, and I travel a lot. I need to edit off-line. Creating and staging blog posts for the future is fun, but requires me to save notes, and then create posts when I have connectivity, staging them for future release.

These add up to "move to https://slott56.github.io".

Big Mistakes

There was one big mistake that manifested itself two ways.

WYSIWYG -- What You See Is What You Get.

Some secondary mistakes involve the way that blogger lacked categories. It was "simply" a list of posts.

Finally, I needed to address "link rot".

WYSIWYG Is Evil

Any purely visual editor is a burning dumpster fire of weirdly inconsistent content that happens to look right, but is actually wrong.

Writing involves three separate issues:

  1. The words chosen.
  2. The semantics of the words.
  3. The presentation to highlight the semantics.

For example, we write code in a distinct font. The word code has distinct semantics, it's in a programming language, and gets a distinct font to reveal that.

We emphasize things with a style change. We might write foreign words or phrases in a separate style.

In some cases, we're forced to overload styles. We might use bold for an AOA (Abbreviation or Acronym). And we also use it for emphasis and for Chapter Titles.

HTML has many semantic categories available as markup. We can use <abbr>ABBR</abbr> to denote an abbreviation. The style sheet may render this in bold (or not, maybe in red.)

Here's the problem:

WYSIWYG editors conceal the semantics, and only reveal the markup.

While it's not impossible to check semantics, it's hard.

You can bold something and it looks fine.

But it should have been a Section Heading, not simply bold.

You can't tell.

Offline editors and proprietary file formats exacerbate the problem. The content is very difficult to recover.

In Apple's case, the files were all XML and could be read.

Newer products use Snappy compression and Protobuf, which is relentlessly evil.

Categories Are Hard

The iBlog posts had categories.

The Blogspot/Blogger posts didn't have categories.

I think categories are useful.

Now what?

I have to categorize about 1,000 blog posts.

This becomes a kind of K-nn problem. Locate the tags and find the most popular category.

Tooling

Some old iBlog entries were in XML. I converted these to RST without exposing an intermediate data model. Not good.

The blogger posts were exported in ATOM notation, a distinct XML format.

What's common?

class Feed:
    ...

class Entry:
    ...

class Post(Entry):
    ...

class Page(Entry):
    ...

A model like this lets a feed contain entries.

This unified model can be parsed from RST or XML, and then small scripts (and Jupyter notebooks) can tweak the content to make it consistent.

And, no, I doubt I'll publish any of the tools I used. It was all one-time hackery.