I'd like to write a post about a project I've been working on for the past month or so. I've had a great time working on it and am excited to start putting it to use. The project is called flask-peewee -- it is a set of utilities that bridges the python microframework flask and the lightweight ORM peewee. It is packaged as a flask extension and comes with the following batteries included:
With the 0.3.0 release of django-relationships, I've made a couple backwards-incompatible changes which I thought I'd mention.
One of the problems mentioned by a couple people when I asked for suggestions on improving djangosnippets.org was the proliferation of tags. This is a well-known problem on sites that allow users to enter their own tags, where misspellings are frequent and its sometimes unclear whether a tag should be plural or singular.
To try and reduce the amount of different tags on djangosnippets I ended up using the jQuery UI autocomplete tools to provide users with hints when they enter tags for their snippets.
Describing some of the improvements made to the django snippets site over the past couple weeks and asking for user feedback on additional improvements they'd like to see.
After several months of running the task queue bundled with django-utils, I decided to re-evaluate certain aspects of the design. This post describes those changes.
Just a quick heads-up to anyone out there using django-completion, I've released a couple important updates this weekend and you may be interested in updating your checkouts. These changes are purely additive, so don't worry about having to update your own code.
There are three important updates:
I'd been scrounging around for a smallish project, when I happened on the idea of writing a spider with a simple web interface. I had recently released a task queue, so I wanted to incorporate that to do the actual crawling, while a django view served up the results as they arrived in the database. The end result is a new project I'm calling django-spider, you can check it out on GitHub. This post will discuss some of the aspects of the design.
It's quite common when building out a website to trigger actions during the normal request/response cycle that may be time-consuming. Examples of these actions might be:
I remember last year about this time my coworkers and I got pretty excited about Celery, a distributed task queue, that provided a really nice API for executing tasks out-of-process. Basically just decorate functions with the @task decorator and so long as everything is configured properly, they will execute out of process. Celery is an actively-developed project with great documentation and an incredibly rich feature-set, but all those features come with the added cost of lots of configuration and the need for integration with a number of projects (celery, django-celery, kombu, django-kombu, pyparsing, mailer).
I needed a lightweight task queue for some side-projects and rather than trying to integrate all the various celery dependencies (and pinning all the correct versions) I did what anyone would do: rolled my own.
I'm writing this post to introduce a new project I've released, django-generic-m2m, which as its name would indicate is a generic ManyToMany implementation for django models. The goal of this project was to provide a uniform API for both creating and querying generically-related content in a flexible manner. One use-case for this project would be creating semantic "tags" between diverse objects in the database.
