Starting over with the blog

In This Article

A long time ago..

Nearly 10 years ago now, I started using a domain (securenic.net) that I had laying around for basic blogging. To be more honest, I used that domain to host blogging software, but never really blogged much. I moved around several dynamic self hosted blogging tools, which was distracting and time consuming, but it didn't produce much written content.

There was s9y, then self-hosted Wordpress, but they were a lot of work to maintain.

Then I tried Ghost and it was almost what I wanted. I finally had time to write some posts. But Ghost was getting a bit of a mess to maintain. It also seemed to be heading in the direction all partially successful blogging tools do, chasing the aspirational web shopfront builders.

I just wanted to write.

So now I'm on Jekyll on a new domain. I wrote a post on my initial thoughts of Jekyll when I moved and I'm really liking the simplicity of the tool set. I know I've killed whatever SEO I'd established with my previous domain, but I don't really care much right now. I'm consolidating what domains I have and what I use them for. This was always the domain I intended to use for my personal public opinions, so it's about time I migrated all my posts here.

A new theme

I started using Lanyon with Jekyll, but even after extensive modifications, I just didn't quite like its style. It was a great theme and it was far easier to start with. I also learned a lot about Jekyll because Lanyon was so lean. Moving to a more full featured theme like minimal mistakes is a little easier as a result. I doubt I would have stuck with minimal mistakes if I'd not already tried and worked with a much simpler theme.

A new publishing workflow

I started to think about changing how I deploy content to my server even as I moved my old blog articles over to Jekyll. I'd initially set up a test web server, which hosted all the jekyll scaffolding as well as the built content. I then pushed the production content to my external host. Since I didn't need to worry about dynamic content, I reasoned that I could simply push my production content on a regular schedule. But this approach doesn't let me write content anywhere else. Jekyll was designed to sit on github to be editable from any client and I'd managed to cripple that flexibility.

Two repositories

I want my working content to sit in one repository, which I could then edit as I pleased. I want the built site to sit in another repository, because it was this that would be pushed to my web server. I wanted as little extraneous material pushed to my host as possible. This reduces the likelihood of revealing draft content or build meta data which could leak information I don't want shared.

So now my workflow looks like this:

  1. Write content or edit site config
  2. Merge changes to content repository in github
  3. Generate _site using jekyll build. I use bundle but the sequence is unchanged to using jekyll alone.
  4. Merge changes to site repository in github
  5. Deploy _site to web server

Step 5 is regularly scheduled and is consistent with my general automation practice of pushing configuration and content from a secure source. No management or content updating is done on the web host at all. {: .notice--info}

More Content?

So far the change has been a little distracting, but I'm already seeing that I'm not wasting as much time fiddling with the back end of my blog. So getting some posts out will be much easier.

I already have a few posts ready on how I go about securing this site. It's the reason I'm still self hosting, even if I'm trying my best to reduce the overall commitment to the back end. Be sure to check out those posts when I publish them! In the spirit of minimal effort, I'll be writing about how you can achieve maximum security with minimum effort.