Every true hacker has their own unique technical setup for writing their blog. And picking the right tool for that is often so much more exciting than producing actual content. That’s why I decided to follow an advice I’ve read years ago: author a few posts first and then decide what the setup should be.

I have so much stuff in my head every day that I feel like writing about but over the past 1.5 years I only managed to produce four posts. So I outlined the major pain points and decided to start a little project that would enable me to satisfy my desired quota. I’m very curious to see if it’ll help me become a better writer.

Prose

Two years ago I was very into using Neovim and writing my notes in Markdown. So naturally I wanted a service that would fit this ecosystem. At first I considered using Jekyll and Hugo but wanted to avoid hosting and writing custom configuration. After some time I encountered an amazing yet unconventional service: prose (part of pico.sh). I could write posts in Markdown locally, copy them to a remote server and they’d be automatically listed. I didn’t have to set up any config, theme, etc. Perfect for a start.

The blog I wrote using this can be found at jupblb.prose.sh. It has the following issues:

  1. I enjoyed the original style a bit more than what’s currently used. It’s possible to modify CSS but there is no support for themes.
  2. Over time I came to a conclusion that my code editor should not be used for writing prose. There are a few reasons for that:
  • Proportional font is better suited to writing and reading regular text.
  • When writing in Markdown I am operating on two documents simultaneously: the source file and the rendered HTML. I would much prefer to use something more WYSIWYG in that case. And while solutions such as Typora exist, nothing comes close to the classic word processors such as MS Word.
  • When I feel like writing about something, I don’t want to go through opening my terminal, changing directory to the blog, opening Neovim, writing changes and then running scp to sync it with the service state. Not to mention all the distractions on the way, such as updating the system or editor configuration.
  1. I wish publishing was done automatically.

Docblog

I’m a software engineer and most of my time is spent on writing or reading internal documents. The company I work at uses Google Docs. So it’s an obvious choice for a text editor for my posts. But what then? How to publish it properly?

Google Docs have “Publish to web” functionality built in. I could just build an index with links to all the relevant documents and call it a day. There are a few problems with that approach:

  1. The ugly heading at the top of the website:
  2. I’d have to write, host and update an index page with all the posts myself.
  3. I’d also need to add support for RSS, somehow.

It feels like too much work to achieve a mediocre result. But another important observation is that it’s possible to export a document to HTML. Popular static site generators can ingest such files[1] to produce a nicely looking website with an RSS feed. This is what Docblog is about.

Docblog is a command line tool that lists Google Docs belonging to a specific Google Drive directory and dumps them to HTML files along with related assets, which can be easily published.

It also has one other important functionality. It stores metadata of all posts inside a Google Sheet where it can be manually edited. This allows changing post’s date and description. And, as a bonus, the description may be automatically generated by AI.

This website is hosted using GitHub Pages. I wrote a simple scheduled GitHub Action that repeatedly runs docblog and pushes any changes to the git repository, which in turn triggers build and deployment of the content.

I don’t need to write any code or open my terminal to publish a new post or change one’s description. I can just leave a browser tab opened and write a paragraph every now and then when I have an opportunity to do so. There are still a few rough edges (like spacing between the footnote and the rest of this document) but they should disappear over time.

The original document that contains this blog post can be found here: Google Doc.

[1] After all, HTML can be almost freely used inside a Markdown document.