At the start of 2018, I decided I really wanted to start keeping a log of things I learn. I’ve always found teaching to be the best method for learning. You start off researching your topic until you know enough to consider yourself a subject matter expert. Then you teach it to someone. The company I work for provides a large amount of opportunity to put on Learning & Development classes, but that’s not how my goal came to be. When I decided my best outlet would be a blog, I was still employed by a retailer site selling rugs. It was a good job, if not very flexible. Solving interesting problems. There was plenty of fodder for blog content.
So I started, as with anything, researching. I was already familiar with wordpress and a couple of front-end frameworks. I made a couple of attempts at using wordpress as my CMS and build a Single Page Application from the content. It never felt comfortable. Even using NuxtJS, a great framework for getting up and going in VueJS, with it’s static site build process. Each time I attempted to use a webserver to build this, I found a lot to be desired. I guess I didn’t start with a clear set of requirements and so I stumbled around.
Attempt 1-ish
Like I said. The content was backed by Wordpress. The front-end was a custom VueJS single page application with emphasis on the directory structure. I didn’t even get the first post written as there were still so many technical hurdles to handle. This was my roadblock. Let us say I had the content written. Maybe 2 weeks worth of content ready to be published. My dilemma, I needed to design, build, and generate the site. I did know that I wanted it to be deployed statically. First big hurdle, I am not really a designer. This was basically my road block. I got caught up in the design and could not progress into the development phase.
Attempt 2
I still have not identified my biggest issue. I really thought it was content. This was months after the first attempt and I was getting more and more comfortable with providing my opinions as a speaker. It was a false sense of familiarity as I stepped into my second major attempt. This time, I removed wordpress. I wanted to get up and going even quicker and remove the web server requirement to hold my content. I decided I would use Prismic.io. I started an account, wrote my first article which I never published, and was off to the races. Again, I started with NuxtJS for the front-end. Then I fell into my technical hurdles. I wanted to have an automatic build pipeline. When I wrote content on Prismic, I wanted it to auto generate my blog. I also needed to start thinking about navigation and again, there was the design hurdle. I managed to get a decent post published but I did not like the design. Any code snippets were provided using pre tags and the site just felt heavy and dependent. There had to be a better way.
Before I jumped into attempt number 3 I started exploring other ways to hold content and publish it. My original thought for web hosting was going to be a continuous development and continuous deployment process to Amazon S3. It’s a process I am pretty familiar with. It still seemed like overkill. Secondly, I was not enjoying my Prismic.io experience. Building custom types and accounting for them in design was not feeling natural. I started looking for options, even thinking maybe I could just store the body of my posts in markdown files inside a Github repo. This seemed like a good idea and I checked the soundness of it with a more senior developer at my work. He validated the idea. Great, this was starting to sound like a plan.
I wanted to make sure my options were complete so I went hunting for other solutions. I discovered Hugo, a go static site generator. We use a lot of Go at my work. It’s something I could see myself diving into in the future. There was another big benefit, there is a ton of themes already written for Hugo and the content is already stored as markdown files. Page routing is already taken care of out of the box, and the site generates to html files without needing to include a ton of front-end dependencies.
Attempt 3 - The Winner
This is the solution I finally went with. I use Hugo as a platform to create and track my content. When I am ready to build, I set my latest article from draft: true to draft: false and run Hugo generate. What results is a new directory in my Hugo project that contains all of my articles and the main site. There are no further dependencies that need to be accounted for. The deployment process is still in the works. Presently, I initialize the public directory as a git repo and attach. This repo is actually avigil06.github.io from my personal Github. By using the github.io, I am able to publish my static site to Github Pages. It’s a pretty easy setup with a quick turn around. Lastly, any code snippets I decide to include are written to Codepen.io. This allows me to have runnable code inside my blog articles without needing to include them in my design and I have a place to track and edit them as I need to.
What does the future hold
As basic as this is, I would like to include some things in the future. My current writing process is inside of VIM. My first article is riddled with spelling and grammar errors. I would like to figure out a better way of writing my initializing, editing, and publishing my markdown files. As I said, Hugo is a static site generator, but it might be nice to back it with a live markdown editor application which allows for scheduled publishing and toggling between draft and public. If this is not possible, I will settle for exporting a markdown file from Bear and sending it through a script which creates the markdown file, and runs the Hugo generate command. Secondly, it would be great to back this with an automatic deployment script so I don’t have to manually add my Github repo to the public directory and pushed the content. In fact, dream state would be pushing the content to Amazon S3 and have a non-github pages domain. Lastly, I would love to also include a portfolio section to my site. I like to shop through designs on Dribbble and make the designs come to life. I have recently discovered a love for CSS and JavaScript animations. This is the kind of thing that I would like to show off inside the site instead of in a codepen.
If you enjoyed this article or you have any questions, you cannot leave me a comment on the comments below, because they don’t exist yet. I should probably get on that.