Trading securities is a dangerous game. It can be difficult to develop a strategy and stick to it in the face of an emotional marketplace that stampedes from one extreme to the other. Sticking to a trading strategy takes time, discipline and serious balls far beyond the capacity of most human beings.

One way rise above the impediments is to encode your strategy into an algorithm and instruct a machine to execute that strategy for you. You can still freak out and pull the plug at any time, but until you do, machines can execute your strategy without hesitation or emotion. Just the exercise of encoding potential trading strategies into machine instructions is enough to spot problems and potential weaknesses.

Continue reading »

Inspired by Justin Lilly, I spent some time looking at various ways of running python web applications with an eye to performance. Nicholas Piël has done some great work testing and documenting many of them. Gevent looks like a great option as does CherryPy, but uWSGI caught my eye because it provides an nginx module and I’m already running lots of nginx. Since its fairly new, my stock nginx from the Ubuntu Karmic repository doesn’t come with uWSGI, but compiling it in is trivial.

So I’ve added uwsgi and nginx + uwsgi to my launchpad ppa for anyone out there who’d like to give it a spin on Karmic. My initial impressions are very positive. If you want to try it out, you can add my ppa to your apt sources and simply run:

sudo apt-get install nginx uwsgi

Continue reading »

Django logo I’ve been working on a project using django, and I’ve got some great things to say about it. I also have some nasty things to say. I’m currently prototyping, which means the databases I work with get destroyed and recreated regularly. I normally have a set of test data that should always be present in the system. Database fixtures to the rescue!

The django documentation has a nice section on database fixtures and how to deal with them properly. You can even give your fixtures a special name (initial_data), and the syncdb command will automatically load your initial fixtures for you. The first thing that really struck me about these fixtures is the fact that you have to reference your model for every database row. Why not divide the fixtures into sections so you only have to type it out once? The fixtures could really benefit from that type of context.

The second thing I noticed, after typing out all my fixtures in YAML format, is that django claims to support YAML format, but doesn’t actually check for an initial_data.yml (or initial_data.yaml) file. That’s a big disappointment. Now am I supposed to translate that file back into xml or json? It picks up files with those names perfectly fine.

Continue reading »