Why did I chose to build my site using Jekyll? I asked myself that question about 2 months back and I decided to switch from using Jekyll to Wordpress. Not a choice I am proud of… or a choice I would suggest for anyone else. Wordpress has it’s place and many people really like it, but it does not fit into my personal setup or workflow.
The main reasons I chose Jekyll :
- statically generated content
- no database to worry about (connectivity, backup, etc.)
- minimal maintenance
- github (enough said)
- free (or at least it can be. I have too many private repos, so mine is $7/month)
- I am sure I will think a couple more… I will include those in the following text.
I am not going to walk you through how I setup the site. I am going to walk you through my daily process of using Jekyll/Github in order to capture my thoughts and ideas in blog format. If you are a frequent visitor to my site, you will notice I like to keep the content fresh and always changing. I try not to drastically change the look and feel. I am always frustrated when I am used to seeing something a certain way and someone continually changes the appearance.
I chose Jekyll, mainly because it is associated with Github, which I am already using on a daily cadence. As a developer type (or at least that is what I like to be considered, I am sure others will laugh at my statement) I like the idea of maintaining my content and site appearance as version controlled text. I am using Jekyll as the platform to generate my static website. The key aspect is the ability to create new versions without the fear of losing data and the ability to revert to previous versions very easily.
Ok… here is my daily process for writing new content.
Write the Post
The writing of a new post is simultaneously the easiest and hardest part of this process. The easy part, creating a new post, adding front-matter and committing. The hard part, coming up with quality content. I will assume you can handle the quality content part of the blogging process.
I attempt to keep the same front-matter attributes for each post. The values of each attribute are very possibly different, but the attributes remain the same.
- layout : almost always ‘single’
- title : you should always have one of these
- excerpt : I like to include a short description… it shows in certain places on the site
- tags : I try to keep the list short, but I like tags in order to group posts/pages
- comments : true
- published : true
- header: teaser: an image file located within the /images folder
I always test everything locally before pushing content to Github. Use the following line to start the Jekyll server.
bundle exec jekyll serve --config _config.yml,_config.dev.yml --verbose --trace
- –config CONFIG_FILE[,CONFIG_FILE2,…] –config can accept a comma separated list of config files. Each subsequent configuration file will override any previous configuration files. In my case, the ‘dev’ config file is second in the list and therefore will override the main config. This allows me to override values like ‘host’ while testing locally.
- -V, –verbose Print verbose output.
- -t, –trace Show the full backtrace when an error occurs
After starting the server, you should see output resembling the following image.
Push to a Branch
I always start each post writing process with the creation of a new branch within Git. I use this process while writing code and it just feels natural to me. I like the ability to maintain multiple branches simultaneously and the ability to push in the order that presents itself. Not every post is created at the same pace as others. I could use the front-matter attribute, ‘published’, but I prefer to keep work in branches instead.
Merge PR when ready to release
When a post is ready and the new content has been pushed to the remote of the repository, I can easily merge a given PR into the ‘master’ branch. The process of merging the branch into the ‘master’ makes the content immediately available for general consumption.