Why every developer should write a blog

It’s unavoidable at some point, if not on a regular basis, that as a developer you will need to produce some type of content in written form to share with your team or others. Since clear and concise technical writing takes practice, it makes sense that you should make a proactive effort to practice your writing. Writing a blog is a perfect (and easy, low or no cost) opportunity to get some practice.

There’s plenty more reasons however why blogging is beneficial and useful for all developers. In no particular order, here’s a list of reasons why you should be blogging:

Note Taking

Technology in software development changes and evolves fast. Chances are you came across at least one thing new over the past couple of days, and if it’s not going to be something you’re going to use on a regular basis, it helps to keep notes that you can refer back to at some point in the future. I can remember that I came across something similar a few months back even if I can’t remember the exact details, so creating a short one pager with some notes to refer back to later is incredibly useful.

Sometimes I also keep notes on the approach I took to solve a problem if it was something that took several steps. If I come across the same problem again several months from now, I’d rather refer back to my notes than working it out from scratch again. If the problem or the steps to solve it were interesting or I think may be interesting to others, I usually capture these steps as a blog post and share on my blog.

Collecting Snippets of useful code

Depending on what the information is, I vary how I capture the information. If it’s something that would be useful to capture as step by step in instructions with additional explanations and details, I usually capture these as a blog entry. If it’s something I don’t want to publicaly share, I sometimes create private posts that are not shared, or keep them separate in a notebook in Evernote.

If it’s a snippet of useful code, for simple, short lines of code I collect snippets using Github’s Gist (here’s a link to my public Gists as example of what I keep there), or for longer worked examples I create a project on GitHub and commit a code example there (the majority of my projects on GitHub are code examples where I was looking at something new and put together a worked example as part of learning whatever that new thing was – you can can take a look at the type of thing I keep on GitHub here).

Sharing Lessons Learnt with Others

The majority of time when I search for info on how to use a new library or framework, the most useful content that I find is usually an article written by a developer who worked through the steps on how to use something.

That content would not be there online unless that other developer took time to create the content and share. The great thing about the internet for software development is that content is easy to find if you Google, but that content would not be there unless those people took the time to write and share in the first place. If you have something to share, even if you think it’s obscure or might not be useful, there’s always someone else who is working on something similar, and they might be struggling to work something out – help out your fellow developers and share your knowledge.

Every developer has something they’ve worked on that would be useful to another developer trying to learn and get up to speed on that same thing. Even if you’re a new developer with a few months experience, you still have lessons you’ve learnt from your own experiences that would be useful to another developer with less (or even more) experience following their own skills development path.

Next steps: From NGINX WordPress and MySQL running on Docker, to Kubernetes

This website running this blog has been running in Docker containers on a small-ish 4GB VPS for the past 9 months pretty much issue free. You can follow by journey to migrate this site to Docker in posts here and here.

Since I’ve been spending time recently getting up to speed with Kubernetes, the next logic step would be to deploy to a Kubernetes cluster, which would give me an opportunity to find out what it takes to run Kubernetes. I’ve looked at managed offerings on Google and AWS, but the cost for a few small personal projects is a little more than I want to spend.

I have a 8GB VPS ready to go, so far installed with Docker and Kubernetes running as a single node cluster, and I’m starting to plan my strategy for migrating to this new server. The first thing I’ve been thinking about is whether I should take my existing Docker images and just deploy to Kubernetes as is. Where I’ve got stuck so far is I don’t know enough about how to run NGINX with WordPress and MySQL in multiple pods, so I think I might install the WordPress Chart using Helm and for the time being not worry about how to do this myself.

The next thing I’ve been looking at is how to configure an Ingress to access different deployed services via different urls. I’ve been looking at setting up Traefik as the Ingress Controller to do this, and will be sharing a post about that config shortly. What I’m interested in is being able to deploy a number of different projects, including my WordPress site, and have them accessed via different urls, and it looks like Traefik will handle this fine.

I plan on writing some further posts as I make this transition over the next couple of weeks.

Moving my nginx+mysql WordPress VPS native install to Docker containers on a KVM VPS

My WordPress blog that you’re reading right now is running on nginx and MySQL installed on a cheap OpenVZ VPS. I’ve been running on a $2.50 VPS from Virmach for the past 6 months or so and been very happy with the service. I spent a bunch of time tweaking the nginx and MySQL config params to run in < 512MB, which it does comfortably, but nginx and MySQL are both installed directly on the Ubuntu VM instance and it would be great of I could make this setup more easily movable between cloud providers (or even to have a local copy of the setup for testing, vs the live site).

I’ve been spending a lot of time playing with Docker and Kubernetes, so it seems logical that I should move the site into containers and then this will allow me to explore other deployment options.

Migration Steps – find a KVM VPS

As far as I know you can’t install Docker in an OpenVZ virtualized VPS container, so first step I need to move to a KVM based VPS so I can install Docker (and possibly Kubernetes). I’ve been shopping the deals on lowendbox.com and there’s plenty of reasonably deals for around $5/month for various combinations of 2 to 4GB RAM and 2 to 4 vCPU.

Dockerize nginx, MySQL and WordPress

I’ve been playing with this already. I’ve picked up my own combo of favorite/useful WordPress plugins, so I’ll probably share a generic set of Dockerfiles and then leave it up to anyone if they want to use them to customize your own WordPress install in the container.

Configure a local dev/test environment Docker setup vs production environment Docker setup on my VPS

This makes a lot of sense and is a benefit of using containers. This will allow me to test my config locally, and then push to my production node. I’ve been looking at using Rancher to help with this, but still got lots to learn.

More updates to come as my project progresses.

WordPress Permalink formats

Having just moved my WordPress blog to OpenShift, it’s amazing how many settings apparently I had tweaked and customized on my previous site. I just followed a Google search link to one of my own posts and got a 404, and realized that the link format to my posts had changed.

I used to have links like /year/month/day/postname and now only URLs that looked like ?p=number. The first format is one of the Permalink formats. You can customize this in Settings/Permalinks. More info here.