Starting a new blog

Posted by on 24 February 2018

I'm constantly learning new things. I'm a Frontend Engineer by trade and that space is constantly evolving. I've always liked the idea of blogging, but I've never really done much of it. Part of the reason is that I really like my editor (Emacs). I don't like the idea of typing a bunch of text into a textarea as in for a blog post for a couple of reasons. First, it doesn't have vim bindings. I can barely type anymore if vim bindings are not present. Secondly, I have actually lost form data before due to session timeouts and such so I just don't like typing large amounts of text into forms. I was excited the other day to find a Chrome addon that handles both of these concerns called Atomic Chrome. I've decided I would like to start blogging about things that I learn about from day to day. My hope is that I can help someone else that may be learning the same thing. Secondly I'm hoping that as I go you guys can help me fill in the gaps if I'm off track.

Choosing which platform upon which to build any sort of web application is no small feat in 2018, and a blog platform is no less overwhelming. Wordpress is the obvious choice, but what about something like Medium? I considered all of these before I decided to role my own. It basically boiled down to two things. I really enjoy building stuff, and if I'm going to write a blog post I'd like to do so from the comfort of my own editor, not some textarea provided by some platform.

If you thought deciding on which blogging platform was a difficult choice, it has nothing on choosing to roll your own thing from scratch! Here are just a couple of questions you have to answer:

  • Where will you host it?
  • Obviously there will be a UI, but what about a backend?
  • If you choose to have a backend, what language will it be in?
  • While we're on the backend, will you use a database?
  • Will it be a relational database or an object store?
  • Will you use a framework of some sort or roll something from scratch...if a framework which one?
  • On the frontend, will you use a framework or roll it from scratch?

I had some simple requirements for my blog. First, I wanted to be able to use my own editor (current Emacs in Evil mode). Secondly I didn't want to have to deal with a backend. I didn't get away from this entirely, but I don't have a proper admin site. I have a couple of scripts that I use to publish my posts and its all working pretty great. I'm a UI developer by trade, I don't do any backend stuff at work. However I kind of needed a backend for this because I wanted to store my posts in a database. I chose a relational database because I want to eventually setup tags and that requires a relation. I'm sure that kind of thing can be done in an object store these days but call me old fashioned, I feel like a relational database is the right tool for this kind of job.

Here are the choices I ended up making to build my own blogging platform:

  • CodeStar
  • LoopBack
  • Postgres SQL
  • React

I know there are several platforms out there that provide a good chunk of this functionality and are ready to go out of the box. One that I found that I tried and really liked for the frontend part at least is Next.js. Next.js has a philosophy that works really well. They wanted web development to work like it did back in the (pre-framework) php days. That is files actually mapped to routes. When made a file on disk, say foo.php, you could easily route to that in your browser, http://example.com/foo.php. A similar mapping exists in Next.js. You can make a file say, foo.js, and it will map to http://example.com/foo. There is something to be said for this type of simplicity. Sometimes I think we tend to make things overly complex. While these platforms are great, for me, I just wanted to try and build my own thing. I get two benefits from this. First I'll learn something, maybe just a little, but maybe a lot. Secondly it will give me something to write about :)

So in v1 of this new blogging platform I've created my workflow goes something like this.

  1. ./dev
  2. ./task/new-post
  3. edit new-post
  4. ./task/publish.js
  5. git commit
  6. git push

So what does all of that do? ./dev is a tmux script. Did I tell you I love the command line? Lots of people like various panes (think split windows), I prefer separate windows (think tabs) for different things. So my script creates 5 windows, 0) Server, 1) TestServer, 2) Client, 3) TestClient 4) Zsh.

#! /bin/sh
tmux has-session -t Zolmok
    if [ $? != 0 ] then
tmux new-session -s Zolmok -n Server -d
    # create moar windows
    tmux new-window -t Zolmok:1 -n TestServer
    tmux new-window -t Zolmok:2 -n Client
    tmux new-window -t Zolmok:3 -n TestClient
    tmux new-window -t Zolmok:4 -n Zsh

    # run the server in the first window
    tmux send-keys -t Zolmok:0.0 :cd ~/dev/Zolmok && source env && npm start: C-m
    # run the server tests in the second window
    tmux send-keys -t Zolmok:1.0 :cd ~/dev/Zolmok && npm test: C-m
    # run the client in the third window
    tmux send-keys -t Zolmok:2.0 :cd ~/dev/Zolmok/frontend && npm start: C-m
    # run the client tests in the fourth window
    tmux send-keys -t Zolmok:3.0 :cd ~/dev/Zolmok/frontend && npm run test:client: C-m
    # just get to the proper path in the last window
    tmux send-keys -t Zolmok:4.0 :cd ~/dev/Zolmok: C-m
    # select the server window and pane
    tmux select-window -t Zolmok:0.0
fi
tmux attach -t Zolmok

The first thing it does is check to see if a tmux session named "Zolmok" already exists. If it does it attaches to that session, if it does not, then it builds the session.

new-post looks in the post directory and determines what the next post id will be and copies over a template from which I'll use to create the next post. I came up with an id system that uses 6 digits, so 000000, 000001, 000002, etc... as directory names. The template that is copied over contains exactly 2 files, index.html and meta.json. index.html is where I'll type up the post, and meta.json contains various attributes about the post like title, tags (not implemented yet) summary, card-image (image used on the list of posts), a publish flag, etc...

I'll then edit the index.html file until I'm happy with it at which point I set the publish flag to true in its meta.json file. I then run the publish.js script which will walk the post directory looking for meta.json files that have the publish flag set to true. If it is true it tries to figure out if it is a new post, if so, push the index.html and it's various properties from the meta.json into the database. If not then it tries to figure out if any changes have been made to either the post itself or it's meta data, if so push those changes to the database. Then I do a git commit followed by git push at which point everything "should" be live.

It's not perfect...yet, lol, but I really enjoyed building it. I also have several more features in mind that I would like to add like an auto-refresher to automatically refresh the browser as I'm writing my post. I hope this is the first post of many and I hope that you learn with me and help me to learn more as well.

Tags: #javascript

Categories: #technology