Farewell Blogger…

Blogger provides an easy, integrated blogging service, but I have not been posting with anywhere near the frequency I had hoped for, and have recently started thinking of the reasons why this is. The list I cam up with includes:

• Page load times: To get syntax highlighting, a nice theme, etc., my posts have an incredible amount of download cruft.
• Editing Interface: While blogger’s WYSIWYG editor is fairly intuitive and the HTML editor is the appropriate power tool, I don’t like the fact I have to (1) be online, and (2) find a lot of situations where I want something in between a WYSIWYG and raw HTML.
• Offline Editing: Expanding on the above point, I travel a lot, and it would be great to be able to compose and view posts offline (like on a plane).
• Versioning/Backups: Blogger doesn’t allow for easily versioning of posts, which would be nice.

I essentially run a programming blog, and as such, I don’t need a lot of frills, bells or whistles. What I really want is text-based, powerful and configurable blog engine. Enter Jekyll.

Hello Jekyll and GitHub!

After a decent amount of research, I settled on Jekyll. Jekyll is a static website generator, written in Ruby, supporting Markdown, Liquid templates, and custom Liquid extensions.

There are many stories of folks moving successfully to Jekyll, and the feature set really hit my pain points:

• All Text: All files are text, and either configuration, markdown, template language, or whatnot.
• Versioned: It’s all source, so place your source under Git, and you’re ready to go.
• Offline: The whole site can be generated or locally served without and internet connection.
• Markdown: There are other pre-processing options, but I just went with Markdown, and it’s really nice and easy to write posts now without jumping back and forth from a WYSIWYG editor to straight HTML. I stay in Markdown and everything (mostly) ends up looking correct.
• Syntax Highlighting: Jekyll uses Pygments for source code highlighting, which is mostly pre-processed, and not an after-the-fact JavaScript processing step (which had previously been slowing down my Blogger site).
• GitHub Support: GitHub’s default document generator is Jekyll, and (separately) has full website support with CNAMEs. This provides an easy means of both site storage / versioning as well as the actual serving.

Introduction

The Python language does not natively provide enumerations. Rejected PEP 354 proposed a string-constructor-based enumeration, later provided as the separate enum package. The web is rife with various cookbook recipes and ad-hoc solutions – see, e.g., ActiveState and Stack Overflow.

Here is ConstantDict, one of my preferred enumeration patterns.

ConstantDict

This pattern (like most Python enumeration recipes) is quite simple and straightforward, so I’ll actually start with the enumeration class, and then discuss the merits / drawbacks after.

The enumeration class is as follows:

class ConstantDict(object):
    """An enumeration class."""
    _dict = None

    @classmethod
    def dict(cls):
        """Dictionary of all upper-case constants."""
        if cls._dict is None:
            val = lambda x: getattr(cls, x)
            cls._dict = dict(((c, val(c)) for c in dir(cls)
                             if c == c.upper()))
        return cls._dict

    def __contains__(self, value):
        return value in self.dict().values()

    def __iter__(self):
        for value in self.dict().values():
            yield value

Django settings construction and configuration is fairly straightforward. Configure Django and installed application settings, maybe add your own project-specific settings, and let Django take care of the rest. As long as you import settings from django.conf all the options and defaults are properly resolved into the ultimate settings object.

However, every so often I run across a situation where I wish the Django settings could do just a little bit more. Rather than try and wade into the depths of Django runtime configuration and risk mucking things up, the approach I take is to use a thin wrapper class around the already configured settings and pass through all calls directly.

What we essentially want is “pass through” wrapper class like:

from django.conf import settings as _settings

class Settings(object):
    """Thin settings wrapper."""

    def __init__(self, default_settings):
        """Initializer."""
        self.default_settings = default_settings

    def __getattr__(self, name):
        """Get setting."""
        return getattr(self.default_settings, name)

settings = Settings(_settings)

Fortunately, Django already has a slightly more complex version of this in the django.conf.UserSettingsHolder class, so we’ll use that instead. I usually have a common application in my Django projects and insert the settings wrapper as the common.settings or common.conf module.