I want to go through a quick run down of the commands I needed to run to make
this site happen, excluding of course, configuring a github account. First
I installed a static page generator called pelican:
$ sudo pip install pelican typogrify markdown
$ mkdir blog; cd blog
$ git init
Then after copying in a theme I liked from the community, I ran a couple
commands from the documentation to generate completely standalone html files,
ready to be uploaded to a web server. Even better I used a git submodule for
the output and uploaded the html straight to github for hosting, as follows:
$ cd output
$ git init
$ git add . && git commit -am "Adding html output"
$ git remote add github firstname.lastname@example.org:myusername/myusername.github.io.git
$ git push github master
And just like that the web site is live and ready to go. Its amazing that the
hard work and dedication of volunteers, plus an awesome company like github,
is able to make this so painless. It allows anyone to publish a good looking
website fast. All you need to understand is some command line tools and the
services they connect to.
And to keep things nice and organised (or unnecessarily complex, depending on your like of submodules), I did the following:
$ cd ../ # Go back to the root repository
$ git submodule add output
$ git add output
$ git commit -am "Added output as a submodule"
I have been watching the technologies behind web development mutate and
flourish as a technically savvy user for many years, only recently have
I taken an interest in the immense amount of work that is required to make
a good site.
Something that is aesthetically pleasing on various screen sizes, everything
from large monitors to tiny high resolution mobile phone screens. Different
platforms, browsers, plugins effect the fonts you know will work, the scripts
you can run, but it still needs to be usable on all of them.
So when I looked at setting up a quick website where I could make posts like
these I wasn't sure where to begin. On the one hand you have free services
like tumblr, blogger, wordpress and on the other hand you write
the HTML and CSS/HTML by hand and get it up on to an FTP site. Of course there
are a mind-boggling number of methods between the two extremes, the one that
stuck out for me was Jekyll.
Before I get into that, I should explain why I avoided the free services.
Admittedly, I do like some of the themes offered and I don't mind reading blog
posts on these sites. Generally the layout, color choices and so on are sane.
However, you are giving a third party total access to the content, with no
easy way to manage it from a local computer. The key is that the service is
handling pretty much everything, you actually type the content right into the
Without this ability to keep a local and independent copy on a local machine,
you lose the assurance that you will always be able to move your data to
another site. Of course it would be pretty unlikely that a reputable service
would leave you without a method of migrating your data, its just there is no
So anyways back to Jekyll. Jekyll is a static web-site generator, you give it
the content you want to publish in an easy to compose form (something like
markdown or asciidoc) and it produces all the necessary html and css files to
make up a very competent web-site. Whats more is that the site doesn't rely on
anything but the files it has generated, you don't require a database
connection or any other server-side logic. You can just upload the files to an
FTP site and you're done.
Except that I didn't use Jekyll to build this site, its just that Jekyll is
the first one I tried and understood, but it proceeded more flexibility and
configuration right from the start than I wanted to deal with. With that said,
you can do some pretty amazing things with Jekyll, the key being that you can
edit the templates that are used to convert your content into HTML very
I used a similar too called Pelican, which performs the same task, but
provides a more complete environment right from the start. The key to all of
this is that I was able to produce a very good looking site, which can be
completely independent of any third party while knowing very little about web
development itself. Its a very empowering realisation.
The trick was knowing how to use the command line to make these tools work,
there are no gui's to automate the process of looking at the configuration
files and its much easier to clone the tools repository (and even publish to
a server) from the command line.
Whenever issues arose, I was able to look at the error messages output
when I tried to launch a local instance of the development server used for
previewing the site locally because they're just output to the standard error
of the terminal.
There are comments.