Skip to main content

Why ed(1)?

As the weirdo behind the somewhat tongue-in-cheek @ed1conf account I'm occasionally asked "Why ed(1)?" Hopefully some of my reasons for learning & using ed(1) can pique your interest in taking the time to get to know this little piece of history.

Read more…

Installing & Configuring Nikola


This assumes that you have installed which isolates this installation from other projects you may have installed locally.

Create a virtual environment

bash$ mkvirtualenv myenv
This command creates a new virtual environment named "myenv". You can choose any name you like as long as it makes sense to you. Because I use this virtual environment for Nikola, I unimaginatively call mine "nikola". Once the command has completed, virtualenvwrapper automatically puts you in that virtual environment as shown by the prefix "(myenv)".

Optionally integrating shell completion

Adding shell completion is optional, but a nice addition that Nikola provides. The following two commands enable Nikola-specific tab-completion when you activate your virtual environment, and disable it when you deactivate the virtual environment.

(myenv)bash$ nikola tabcompletion --shell bash --hardcode-tasks >> "${VIRTUAL_ENV}/bin/postactivate"
(myenv)bash$ echo "complete -r nikola" >> "${VIRTUAL_ENV}/bin/predeactivate"

If you use zsh instead of bash, you can specify "--shell zsh" instead of "--shell bash".

Deactivating the virtual environment

(myenv)bash$ deactivate
This exits the virtual environment you created. Alternatively, you can just quit your command shell using "exit". During initial setup, you can skip this step, as you'll just need to reactivate the virtual environment to install Nikola.

Reactivating the virtual environment

bash$ workon myenv
This will activate the "myenv" environment again, as well as put the environment-name indicator in your prompt. If you didn't deactivate the virtual environment using deactivate, then you won't need to reactivate your virtual environment.

Install Nikola

(myenv)bash$ pip install Nikola
Inside your virtual environment (as shown by the environment-name inside parentheses before your usual prompt), this uses pip to fetch the latest version of Nikola and install it. This brings in a number of dependencies, some of which may need to be compiled. As such, if you don't have a compiler installed on your machine, you'll want to do that before this step.

Create a new blog

(myenv)bash$ cd /path/to/your/blog
(myenv)bash$ nikola init myblog
You can choose a name that you like for the folder instead of "myblog" (or similarly boring reasons, I named mine "blog"). This creates a folder called /path/to/your/blog/myblog in which your content, templates, cache, and output will go. It also prompts you for the name of your site, the main author's name, the main author's email address, a description of the site, the root URL for the site (which should end with a trailing slash such as ""), the languages you intend to use, your time zone, and which comment system you want to use (if any).


Nikola's configuration takes place in "/path/to/your/blog/myblog/". Opening this file in your favorite text editor, you'll notice that the answers you gave during the "nikola init" process appear as the values to various settings within this file.

By default, Nikola expects markup to be reST but I prefer the straight-forward nature of HTML. So my first stop was to add HTML as a processed language. By putting it first in the list, it becomes the default for new_post which saves me from forgetting to specify the template as "-f html" every time I generate a new post. To do this, I modified the "POSTS = (…)" and "PAGES = (…)" to include the following lines:

    ("posts/*.html", "posts", "post.tmpl"),
    ("posts/*.rst", "posts", "post.tmpl"),
    ("posts/*.txt", "posts", "post.tmpl"),
    ("stories/*.html", "posts", "post.tmpl"),
    ("stories/*.rst", "stories", "story.tmpl"),
    ("stories/*.txt", "stories", "story.tmpl"),

I want to have my templates contain additional metadata fields for author (allowing me to easily override this for guest posts) and category. To do this, I found the comment containing ADDITIONAL_METADATA and added the following lines:

    "author": BLOG_AUTHOR, # default to me
    "category": "uncategorized",

I also customized the CONTENT_FOOTER to show a minimal copyright notice:

    Contents © {date}
    <a href="mailto:{email}">{author}</a>

To round out some personal preferences, I explored the Nikola handbook and added the following settings in their respective places:

SOCIAL_BUTTONS_CODE = "" # I don't want social buttons
COPY_SOURCES = SHOW_SOURCELINK = False # not very useful with HTML fragments
USE_BUNDLES = False # may change this later

Finally, I wanted to enable automated deployment of my blog to my web-hosting service. To deploy without needing to enter the password for my hosting service, I set up SSH keys and used ssh-copy-id to push the public key up to my server. With that in place, I adjusted the (formerly empty) list of commands DEPLOY_COMMANDS .

    "rsync -avr --delete output/ {login}@{host}:{path}".format(

This allows me to deploy by simply issuing "nikola deploy".

With Nikola installed and configured to my liking, it's time to go write some blog posts.

Why Nikola?

Why a static site generator over a dynamic blog engine?

  • I prefer to work in raw HTML because I've been doing it for years, and the markup is readable. For some reason, Markdown, Textile, and reST drive me nuts—mostly because it's easy for me to enter things I don't intend as markup, and when I want to do complex markup, I have to look up the obscure syntax in the documentation. Every. Single. Time.

    Most of the blogging engines (such as Wordpress and Drupal ) do allow for directly entering raw HTML, but it always feels like I'm fighting against the grain. Every time I go to compose a post, I have to toggle into a special "HTML entry" mode. One wrong turn and some of the engines will "sanitize" my HTML, reformatting everything. A blogging engine should treat my content as sacred and never try to second-guess (or reformat) what I want.

  • To deploy these dynamic blog engines, it requires a server with the ability to run code (usually PHP but some used mod_perl, mod_python, or mod_cgibin) and a backing database such as MySQL. Granted, you can find free and low-cost hosting that provides simple PHP/MySQL access, so this isn't a huge hurdle, but it does place additional restrictions on which services you can use.
  • Some of the cheap/free shared-hosting plans put so many hosts co-located on the same hardware that performance becomes an issue—both database processing and the engine's processing. With a static site generator, there is very little overhead in serving static pages.
  • The more dynamic components in play, the more likely it is that vulnerabilities lurk due to the extra exposure. With a static site, far fewer parts are in motion to be attacked so I don't worry about vulnerabilities in PHP, Wordpress, or MySQL.
  • Many of the blog engines don't support versioning of the content. I can keep my static site content under revision control with git, Mercurial, Subversion, or a multitude of others.

Why Nikola rather than the other static site generators?

I compared several static site generators, both using a static site generator comparison site and my own testing. Top contenders included the following:

As I tested them, I started to develop a list of criteria that mattered to me:

  • As a Python developer, I had a bias towards those built in Python. It allows me to poke around under the hood, create patches when I find things I want to change, and gain a deeper understanding of how things worked in the event I hit edge cases.
  • Documentation mattered. Several projects had documentation that was incomplete, hard to navigate, or required JavaScript (which prevented the docs from working nicely on one of my e-readers).
  • Additionally, some projects seem less than active in their development. According to the static site generator comparison site, some hadn't been updated in months or years while others have had sustained, ongoing development.
  • Most importantly, I wanted the ability to compose in HTML fragments rather than being forced to use Markdown, Textile, or reST.
  • So I ended up settling on Nikola as it's developed in Python, allows me to use HTML fragments, has thorough documentation, and is actively developed.