New Year, New Blog Setup!

Coinciding with the New Year ¹, I have decided to take a leap of faith. Starting with this post, I have overhauled my entire blog site and workflow. Hence the change in appearance. More details on the technical aspects will follow in a future post.

Same as it ever was

#

Note that I have endeavored to swing over all my old posts and keeping the slugs/URLs intact, so any bookmarked page should still be found. (Though some edits will likely still be required, due to changes in the backend setup. I also expect to tweak the theme used over time as well.)

One thing that is likely going to break are the RSS/ATOM feeds. This is due to the particular path to the feeds, again caused by the change in the backend setup.

Whether this will be a permanent change or not only time will tell.

If at first you don’t succeed…

#

This situation is much like at $job-1, where I iterated over various solutions to document our work, until I found one that “clicked” with our group. When I first started at my last job, documentation was an afterthought.

The first solution was to store documentation in static HTML files, which were served up on our local departmental server’s webserver. This, however, suffered the usual “bit rot” found in many documentation systems. The only people who knew HTML and wrote or updated anything were myself and my late boss. This meant that, over time, the documentation became less and less accurate or useful.

After getting into PHP (back circa 2000 when v4 first came out), I decided to spin up a wiki, in hopes that maybe this would work better. My end goal then (as it often is even today) was to minimize what I call “the friction” in workflows/software, finding or building solutions that were as easy/intuitive to use as possible. In this case I wanted to make it that everyone in our department could add/update documentation at will, without having to go through a lot of training/education/suffering.

So my second solution was to setup our departmental webserver with PHPv4 and MySQL, in order to run PHPWiki on it. I thought that if the only thing that my coworkers needed was a web browser to add/edit content, with no need to understand HTML/etc., maybe this would work.

It did not.

Sadly, in the end, not even my boss used this PHPWiki setup. So it was actually a step backwards and worse than the static HTML pages, where at least the two us used it. But I did not give up.

The point here is that we often try something and it does not work. That is ok. In fact, it is essential. The key thing is to TRY. Or more specifically, “If at first you don’t succeed, try try again.” Put another way,

It’s not how many times you get knocked down that count, it’s how many times you get back up. – George A. Custer

It is not whether something works or not. It is being able to acknowledge when it does not, learn from it, drop it, and move on.

Far more detrimental are things such as

• sunken cost fallacy, where you think “I spent so much time on this that we should just keep plugging away at it or it will all be a waste”, when, in fact, all you are doing is losing more time/effort on what you know does not work
• some misplaced sense of loyalty to some solution (for whatever reason) when it clearly is not working
• or worse, the inability to simply admit “I was wrong”. This, more than anything else, can have serious consequences.

So I simply kept pivoting, trying different options, until I finally found a solution that worked: DokuWiki. Yep, after a few failed attempts, I found a flat text file based Wiki solution that everyone in our group just seemed to latch onto. They found the editor much easier to work with. And most importantly, they not only created new documentation but also edited/updated existing documentation. Best of all: this solution was much simpler to not only install/configure, but also to backup/restore/work with offline.

While other Wikis often required some form of RDBMS (e.g., MySQL/MariaDB/PostgreSQL), DokuWiki used simple, flat, text files. This meant that even if the departmental webserver itself blew up, as long as we had zipped up the directory containing the Wiki itself, we could use something as simple as grep to search for information in an emergency.

How this relates

#

While the technical details will wait for another post, in short I found that my existing workflow for writing blog posts was not working as well for me as I had hoped. This overhaul is an attempt to see whether this new setup/workflow will suit my needs better. There is no “right” or “best” way in this, so much was whether it works for me or not.

More to come.