Writing Blogs out of Boredom

Yes, blogs. Not blog posts. We’ll get into that in a second.
This entire thing is also really unpolished, but I probably won’t ever find the motivation to make it better. Keep that in mind, and don’t expect too much.

Introduction

More often than not, we find ourselves bored. The modern world, brimming with excitement, variety, colors, lights, and stimuli, fails to entertain us. We could have anything, but we want nothing. While this is certainly a serious issue that merits pages upon pages of psychological and even philosophical discussion, it won’t be our topic for today. Today, we’re looking at the other side of the digital age. Those rare occurences where you have nothing, but would take anything.
Okay, maybe not quite, but let’s go with that.

A few weeks ago, I found myself on a rather lengthy train trip. No books, close to no reception, no one to talk to. Just me, a bag of clothes, and a laptop without internet. [1]
So I did what every sane person would do. I programmed something. Not because I really needed it, but because it kept me busy, and hey, maybe someone someday might get some use out of it. As has become the norm for me, I wanted to do something that was in some way new or unknown to me. In this case, template rendering and persistent storage in Go.

[1] Incidentally, I’m on a train right now. No books, no reception, just a laptop with… you get the gist.
Although there is a moderately attractive girl sitting not too far from me this time.
She just seems awfully immersed into her MacBook, and I don’t want to interrupt her.
Also >Apple

The idea of the blog is quite simple, and I don’t feel bad admitting that I took inspiration from a friend who had designated channels on his discord server that were used as micro blogs by different users. One channel per user. Mimicking that, I created a simple database schema that would store a message, an author, and a timestamp.[2] The template would then query the last 50 entries from that database and display them on the website like an IRC log.

And that was the frontend done.
This is what it looked like, in case you’re curious.

[2] Of course, an auto-incrementing ID was also added, but that’s not really relevant here.

What, Why, How?

The reality is that the frontend was the very last part I implemented, but I already had a general idea, and explaining it first makes more sense to an outsider. Some of you might also be thinking

“What do you mean »the frontend was done«? You can’t publish anything on that blog.”

You see, almost everything is optional. Sure, you might want to publish something, but do you really need a dedicated page for that? As long as the server knows who you are and what you want to write (and that you have the permissions to do so), it’s fine. Implementing a login page in the frontend seemed a bit overkill, and requiring you to copy-paste a token into a password field for every line that you want to publish is also inconvenient at best.
And why would we want that anyway?

The Best UI There Is…

There is a very good article about terminals and what we can learn from them when designing UIs. However, in our efforts to make UIs that are _ at least in some regards _ like a terminal, we shouldn’t forget that some UIs might as well be terminals.
And so I did the only logical thing. I implemented an endpoint that opens a port and listens for POST requests containing a JSON.
That way, publishing can be automated with a simple shell script that uses curl to send the requests.[3]

function publish {
    curl your_blog.com/add -d "{\"content\": \"$line\", \"Secret\": \"your_password\", \"author\": \"kageru\"}" -H "Content-Type: application/json"
}

read line
while [[ ! -z "$line" ]]; do
    publish "$line"
    read line
done

This simple script will continue to read lines from STDIN (i. e. whatever you type before pressing return) and publish them as individual entries on the blog. It exits if you enter an empty line.

Now tell me, did you really need a website with a full HTML form for that?

[3] Did I mention this only works on *nix? Though you could probably create a very similar script in PowerShell.

…Sometimes

I won’t deny that this is ugly in a few ways.
Having your password stored in plain text in a shell script like this is certainly a huge security flaw, but since no real harm can be done here (all messages are HTML escaped, so no malicious content could be embedded in the website by an attacker), I consider this an acceptable solution for what it is _ a proof of concept that was created because I was bored on a train. Just like I am now, as I’m writing this. The way the backend handles the requests is also anything but beautiful, but it does the job surprisingly well (if, like me, you only want a single user). You don’t even need a separate config file to store your password because the hash is in the source code and compiled into the binary.
Isn’t this a great example of how time constraints and spontaneous solutions can make software terrible? This is why, when a developer tells you he will need 3 months, you don’t force him to do it in 3 weeks.

Anyway, I think that’s it. I don’t know if this will be interesting, entertaining, enlightening, or whatever to anyone, but even if it doesn’t, it still kept me busy for the past hour. I still have almost two hours ahead of me, but I’ll find a way to keep myself entertained.

The girl I mentioned earlier stashed away her MacBook, but it looks like she’s going to get off the train soon. Tough luck.

Leave a comment



29. Nov 2018 um 23:46 by Aicha

Mildly entertaining. The MacBook girl subplot was great, though.