A year ago I started developing a static blogging engine called Ristretto. It was written in Python, used markdown files as input, Jinja2 for templating, and generated static html files on my web server. Some weeks later, I migrated my main blog (zoia.org) and this blog from Wordpress to my new blogging platform.

Compared to writing in Wordpress, I enjoyed the new platform a lot. Over 2013 I kept adding functionality to Ristretto. At one point midyear, I rewrote part of the engine so that it read posts from a Dropbox account instead of the local folder. The engine, now running on the web server, generated the blog using the Dropbox API. Now I could write and publish from anywhere I could use a text editor and access my Dropbox account.

But reading files through the Dropbox API was slow. I had to implement some caching mechanism to speed things up. Other improvements followed… I changed the posts header structure (the post metadata) from my custom format to the more standard YAML, so posts could be easily ported to other blogging platforms if needed. I had to write some code around the RSS generator I was using (pyrss2gen) so it correctly embedded image urls in the RSS feed.

Spend your time writing, not tweaking your blogging platform

I’ve been happy blogging with Risttretto. But instead of spending more time writing, I was frequently trying to improving the code. And there were some shortcomings in the way I had implemented the engine that kept bothering me.

First, if a post contains images, the image files have to be uploaded manually to the web server. And you will have to figure out in advance the url that the images will have when the post is published, because the engine does no conversion of the url. (This also means that the images will not show in the post if previewed locally.)

Second, because of the way Ristretto is designed, the template files reside on the server and are not updated via Dropbox¹. Whenever I found a minor bug in my template, I usually fixed it directly on the server… but later forgot to sync the changes with my local copy.

And regenerating my two blogs, which have not so many posts, was still slow.

So, after some thought, I decided to migrate to another static blogging engine. Ristretto has been a nice experiment, but I want to spend more time writing articles, not rewriting yet-another-static-blog-generator.

Migrating to Pelican

I chose Pelican over Octopress or other engines like Nerve because I had read very positive reviews about the engine, and because It’s written in Python. I’m very comfortable deploying web apps in Python, and I wanted to minimize the time required to switch engines.

Dropbox synchronicity and the ability to write posts from anywhere was not negotiable. After some web research, I followed Joe Hewitt’s advice and created a separated Dropbox account for my blog, and then shared a folder in that account with my main Dropbox account. This shared folder is where posts, images, and template files resides, and where I write new posts.

I installed watcher to monitor the folder containing my posts, and launch Pelican to regenerate the blog any time a change is detected².

Converting my templates to Pelican templates was straightforward, because both Ristretto and Pelican use Jinja2. Only some variable name changes were required.

Migrating to Pelican was fast. Having my two blogs running on Pelican, including writing a small script in Python to migrate my old posts’s header structure to Pelican’s format, took me around four hours.

Cubr is a program by Chris Baker. You mix up a Rubik’s cube, show it to your computer’s webcam, and magically the cube begins to solve itself.

Nice article by the lengendary Michael Abrash: Why virtual isn’t real to your brain. Before delving into technical detail, he shares some reflections on how sharing information probably helped him early in his carrier land a job at Microsoft, then Id, and more recently at Valve.

Nowdays I develop mostly on OSX using Python. I am particularly fond of using virtualenv and virtualenvwrapper for keeping separate environments for each project, so that the system’s Python distribution does not get contaminated with the project dependencies. (This also helps in having a clear set of library dependencies when deploying the project to a production server.)

Some days ago, while trying to set up a development environment¹ for OpenERP v.7, I found that most of the OpenERP tutorials and manuals are centered on Linux, and only consider system-wide installation of the required libraries.

Here are the steps I followed to get OpenERP running on OSX 10.8.3.

1. Setup a virtualenv for your project

$ mkvirtualenv openerp-dev

2. Tell your environment which architecture you are compiling your modules for

(Without this line some modules with throw errors while installing.)

$ export ARCHFLAGS='-arch i386 -arch x86_64'

3. Install OpenERP dependencies

Most of the dependencies can be installed on your virtualenv using pip²:

$ pip install python-dateutil feedparser gdata \
python-ldap lxml mako python-openid \
psycopg2 Babel reportlab simplejson \
pytz vatnumber vobject python_webdav \
Werkzeug pyparsing==1.5.7 pydot \
PyYAML xlwt ZSI PIL

Other dependencies must be installed by hand.

pychart

Download PyChart from http://download.gna.org/pychart/PyChart-1.39.tar.gz and install it into your virtual environment:

$ wget http://download.gna.org/pychart/PyChart-1.39.tar.gz
$ tar xvfz PyChart-1.39.tar.gz
$ python setup.py build
$ python setup.py install

libxslt1

libxslt1 is included in the libxml2 library bindings for python. Download libxml2 from xmlsoft.org:

$ wget ftp://xmlsoft.org/libxml2/python/libxml2-python-2.6.11.tar.gz
$ tar xvfz libxml2-python-2.6.11.tar.gz
$ cd libxml2-python-2.6.11
$ python setup.py build
$ python setup.py install

4. Install OpenERP from launchpad

If you don’t have bazar installed in your Mac, you can do it easily using brew:

$ brew install bzr

Download OpenERP v7 server, addons and web addons from the development trunk of the OpenERP Project Group on launchpad using bazar (this can take some time):

$ bzr lp:openobject-server/7.0          #  Server
$ bzr branch lp:openobject-addons/7.0   #  Server addons
$ bzr branch lp:openerp-web/7.0         #  Web interface and addons

Change into the openerp-tools directory and use make to download OpenERP v7:

$ make init-v70
$ cd server

Install OpenERP into your Python environment. The setup script will pull automatically any missing dependencies.

$ python setup.py install

Start OpenERP server and instruct the server to create a sample configuration file for us. (The file will be named .openerp_serverrc and will be created in your user’s home directory.)

$ ./openerp-server -s

5. Change OpenERP’s configuration file to reflect you development setup

Using your favorite editor, open ~/.openerp_serverrc. The minimum changes required for OpenERP to start are:

PostgreSQL connection parameters

db_host = localhost    # (or an IP)
db_maxconn  = 64
db_name     = False     # don't need to specify a database name
db_password = your_db_user_password
db_port     = 5432
db_template = template1
db_user     = your_db_user

Server addons and web addons location

addons_path = /Users/(...)/openerp-tools/addons/,/Users/(...)/openerp-tools/web/addons/

Note that there are no spaces between paths, just a comma. (It took me some time to figure out why my paths were not being recognized by OpenERP.)

6. Start your OpenERP server using your configuration file

$ ./openerp-server -c /path/to/.openerp_serverrc

Launch your favorite browser and point to localhost:8069, and you should see the OpenERP login screen.

Thirteen years old Amy Mather explains how she got in programming, why she loves it, and her implementation of Conway’s Game of Life for the Raspberry Pi.