DEV Community 👩‍💻👨‍💻

Cover image for How I Write Blog Posts These Days
David Wickes
David Wickes

Posted on

How I Write Blog Posts These Days

I read

and realised that I was doing things in a sufficiently different way to John to warrant a separate post. So, in some vague order, here's how I write a post for Dev.to and my own blog.

1. Editor: Vim

I write my Markdown in Vim. Or Emacs in Evil mode, which is just Vim emulation in Emacs.

Why? Well, I find the manipulation of text - any text - really quick and easy in Vim. Moving paragraphs, changing words, deleting sentences - Vim is aware of the structure of natural language, which makes using it to edit blog posts easy. But that's my experience which is coloured from having used it since the beginning of my career. You either like Vim or you don't - it's really not that important.

Why use Emacs and not just Vim? It just depends on whether I've got a terminal or Emacs open.

2. Format: Markdown

Markdown is both wonderful and terrible. Wonderful as it's everywhere, is human readable, is human writable, and supports the structures you want to use for technical writing - i.e. code blocks. Terrible because there is no standard - the HTML you'll get out of the other end of a parser is not consistent between parsers.

Think this isn't too much trouble? I have to join all the lines in a paragraph to a single line when I'm posting on Dev.to as the Markdown parser treats all the line breaks in a paragraph as hard breaks.1

It's this inconsistency parsers that makes me avoid (or at least not rely on) Markdown linters and previewers. I tend to wait until the post is near finished before I see what it looks like with stage 5 (see below).

Still, the benefits outweigh the drawbacks and so Markdown it is.

3. Grammar and Spelling: aspell, style and diction

Markdown posts like this can be sent to aspell, a handy interactive and extensible spellchecker. Good editor integration for aspell exists in both Vim and Emacs.

style and diction are a pair of tools that check for grammar mistakes and readability. diction picks up on clichés, doubled-words and potential misspellings. It's sometimes wrong but it gets you thinking about whether you could word things better and so makes an excellent starting point.

style describes how readable your document is through a series of scores - Flesch-Kinkaid for instance. It's interesting information.

4. Storage: Public GitHub

I keep my posts on GitHub. If someone spots a mistake then at least this way they can open a pull request.

5. My Site: Static Site + GitHub Pages

I've been using GitHub Pages to host my blog as a static site since forever. It's an easy enough hosting solution and you can use it with any number of static site generators to turn your Markdown into HTML.

I wrote my own static site generator because I found every one I tried a little too busy for my liking. It's still too busy for my liking and I reckon it could be scrapped in favour of Pandoc and a few Bash scripts as glue, but it was fun to write. I wouldn't use it if I were you.

There's also some MathJax in there for the posts I wrote about Lambda calculus which is overkill as I'm not a mathematician and it just adds a load of JavaScript to the page. But it's pretty so 🤷‍♀️.

I have a horrible bash script to publish the blog, and it looks like this when it's published:

my blog

I like the colour orange.

6. Add to Dev.to: Copy and Paste

Hey, it works.2

7. Dev.to Cover Picture: Moses

My personal site has no place for cover images, but Dev.to does and so I feel obliged to put something there.

What I write can come across as an angry old man coming down from a mountain to shout at everyone to stop worshipping false idols,3 so a picture of Moses always makes an approprite Dev.to cover image. Usually something involving smashing tablets and looking angry, but this time I've been a bit more peaceful and so it's The Finding of Moses by Lawrence Alma-Tadema.


  1. Would be annoying if it wasn't for Vim's vip J

  2. Also made more exciting by Vim: :% y + 

  3. At least that's what the score from style says. 

Top comments (18)

Collapse
 
learnbyexample profile image
Sundeep

yay, most of it is similar to my workflow :)

I tried so-simple for GitHub pages, and I am more than okay with it so far

I need to change a few things for front matter (been lazy enough to not automate, maybe someday) between GitHub pages and Dev.to, and I always use preview as sanity check - like have I forgotten some change, rendering (found two bugs so far), etc

will check out style and diction, feels like it will be helpful

Collapse
 
aspittel profile image
Ali Spittel

This is awesome -- I am installing style and diction right now -- what a cool tool

Collapse
 
grahamlyons profile image
Graham Lyons

Yeah, I'd never heard of those before but I'll definitely try them out.

Collapse
 
gypsydave5 profile image
David Wickes

Glad you like it Ali!

Collapse
 
grahamlyons profile image
Graham Lyons

I have a similar workflow. I use Vim almost exclusively but I do switch to VS Code for the Markdown preview - I didn't realise there was no standard for it though.

I often use the spell checking in Vim: :set spell! to toggle on/off. I often have to :h spell to remember all the commands but z= on a word brings up a list of suggestions and ]s moves to the next bad word.

I have written my own site a few times but switched to Jekyll a year or two ago because the less of my own code hanging around doing stuff the better and any features I want are just a Gem away.

Collapse
 
gypsydave5 profile image
David Wickes

I have written my own site a few times but switched to Jekyll a year or two ago

This made me laugh as I switched from Jekyll to writing my own site a year or two ago. I think it was the Liquid tags that did it - found the syntax confusing and occasionally magical.

TBH I still think I could do it all with Pandoc and a few scripts, but I CBA to work it out right now.

I often have to :h spell

Always.

Collapse
 
nestedsoftware profile image
Nested Software

@mortoray I see that there are several people who may want to use your mdl thing!

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

I'm working on it. It's almost far enough to do all my posts -- exception the latex bits.

Collapse
 
gypsydave5 profile image
David Wickes

Will now have to read your posts about writing a Markdown parser - thanks!

Collapse
 
micahriggan profile image
Micah Riggan

Very cool! I'm also blogging with vim + github. Made an MR on your githubs for some links on your main readme that weren't working for me

I've been trying out 100% markdown with the github static pages and then copy and pasting to dev.to.

Could you say more about what :%y+ does?

I've been :!pbcopy on my mac to copy out, but I have a feeling your thing does that too, without clearing all the text?

Collapse
 
gypsydave5 profile image
David Wickes

Could you say more about what :%y+ does?

SURE!

  • : - start command mode
  • % - with the whole buffer...
  • y - yank it to...
  • + - the register called +.

The register + is the system clipboard.

Collapse
 
micahriggan profile image
Micah Riggan

Thanks for the explanation! Registers are on of the vim things I haven't fully incorporated into my workflow

Collapse
 
siddharthshyniben profile image
Siddharth

I'm thinking of doing something similar, but my only question is: How do you manage drafts? Do you push them to GitHub or do something else?

Some comments may only be visible to logged-in visitors. Sign in to view all comments.

Timeless DEV post...

Git Concepts I Wish I Knew Years Ago

The most used technology by developers is not Javascript.

It's not Python or HTML.

It hardly even gets mentioned in interviews or listed as a pre-requisite for jobs.

I'm talking about Git and version control of course.

One does not simply learn git