There are a few options for client-side code highlighting. Highlight.js is one of the most popular, and it’s super easy to integrate into your site. Let’s do it! Compared to Server Side I usually default to server-side code highlighting. It puts the complexity of code highlighting in the build phase and keeps the runtime simple. The most popular server-side option is pygments. I have used this for many years. Unfortunately, in my latest conversion to hugo, I realized that the support for server-side highlighting was not good.
Once you get a bunch of data that you want to put on your site, it’s common to reach for a database. Then you’ll write an app that consumes that database and renders a dynamic site. What if, instead, you could create a static site from that data. What would that buy you? Dynamic Database If you have a dynamic site backed by a database (eg, postgres), you’ll have some good and some bad.
Continuous delivery allows for you to release often what you are always developing. This is even possible on a static site where we might not be hiding in-development features but content and visual styles. Here is a strategy for doing that, executing in Hugo. Feature Toggles Main line development is a joy. It’s often good to avoid the long-lived, meandering paths of feature branches. In order to stay in the master branch, you need to keep it always ready to deploy.
Several weeks ago, I decided it was time for me to move on from Octopress. It’s given me a good run. But there were a couple of causes that pushed me over the edge. My experience has been good with a few pains in the conversion. Outgrowing Octopress The most fundamental and important reason for me converting from Octopress is that it was getting slow to build my site. I’d write an article, run rake generate, and it’d take (anecdotally) 45 seconds.