Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
The tools of choice
Well, we have decided which tools we are going to use for our semester project. The winners are: Eclipse with the following plugins: PyDev (For python Development) Subclipse (For SVN connectivity) And for our development framework (after a period of uncertainty): Django was the clear winner. PostgreSQL will be our DBMS. Eventually we’ll configure the Apache HTTP Server to work with mod_wsgi for Apache-Python interpretation. Shortly I’ll post on how to get all those working nice together. Until then. -
Scratching Django-Compact for Django-Compress
Last week I talked about a project I had started to build called, django-compact, whose goal it was to provide a build process for all the various CSS and Javascript files in a given project. I was quickly notified in via Will Larson on Twitter that I should checkout django-compress. I did. To say that I was following the same approach would be an understatement. Furthermore, this project was much further along than I was. I spent the better part of this morning getting a subsection of my project wired up to use it and am well satisfied. There was a small additional feature I wanted to add, so I forked the project and made the additions. I feel like the changes are non-breaking and generally useful and therefore hope to get them pushed upstream. The feature in question involves being able to have multiple MEDIA_URLs for different outputs. I call them PREFIXes. My approach was to patch the media_url function in compress.utils to accept defaulted argument called prefix. If prefix exists in a non-empty state, then it concatenates itself with the url argument, otherwise it concatenates with the settings.MEDIA_URL setting. Upstream in render_common I look for a dictionary key … -
Scratching Django-Compact for Django-Compress
Last week I talked about a project I had started to build called, django-compact, whose goal it was to provide a build process for all the various CSS and Javascript files in a given project. I was quickly notified in via Will Larson on Twitter that I should checkout django-compress. I did. To say that I was following the same approach would be an understatement. Furthermore, this project was much further along than I was. I spent the better part of this morning getting a subsection of my project wired up to use it and am well satisfied. There was a small additional feature I wanted to add, so I forked the project and made the additions. I feel like the changes are non-breaking and generally useful and therefore hope to get them pushed upstream. The feature in question involves being able to have multiple MEDIA_URLs for different outputs. I call them PREFIXes. My approach was to patch the media_url function in compress.utils to accept defaulted argument called prefix. If prefix exists in a non-empty state, then it concatenates itself with the url argument, otherwise it concatenates with the settings.MEDIA_URL setting. Upstream in render_common I look for a dictionary key … -
Adding a simple WYSIWYM Markdown editor to your models
I'm a Markdown fan. Period. Since I first discovered it some years ago, I've been using it for storing all my "output-to-HTML" texts. Blango, the blog engine I wrote for this site, uses Markdown for post contents. As I've said, I really like Markdown, but typing (and sometimes escaping) all those *[]() gets boring from time to time. I've been looking for something like a WYSIWYG editor for some time, but none of the available choices seemed good enough for me. However, I recently stumbled upon WMD. So, what's WMD and why should I care? In the author's own words: So WMD is something new: a Wysiwym Markdown editor. Wysiwym stands for What You See Is What You Mean. WMD produces clean semantic HTML, leaving presentation details like fonts and colors up to style sheets. But you're not left in the dark about cosmetics; as you type, WMD's live preview shows you exactly what your text will look like after the current styles have been applied. Markdown is a simple markup language that's as easy to read and write as plain-text email. WMD uses Markdown as an input format, converting it into HTML behind the scenes. You can also mix … -
Ottawa Python Authors Group Meeting
The Ottawa Python Authors Group is having a meeting tomorrow (Monday) and Michael Soulier will be presenting talks on concurrency in Django, and an Introduction to Git. It has been a while since the last meeting and this promises to be a good one. -
Templayer 1.5.1 Released
This release fixes a number of bugs in the 1.5 release: Templayer Home Page Download Tarball -
Three New Debian Django Packages
Recently my employer, credativ UK1 have been kind enough to allow me to spend some time working on Debian packaging from some Django apps we've started using internally. Chris Lamb was kind enough to sponsor the upload of these packages. Django developers, this means that if you are running a Debian GNU/Linux machine2, you can type: apt-get install python-django-<app name> and you will have it installed for all users on the system. You won't need to mess around with any Python packaging systems, or modify your environment to be able to use them. So, what are the packages and why are we using them? django-tinymce django-tinymce is a Django app providing integration with TinyMCE, a pure JavaScript rich text editor. It provides a widget that can be used within forms, and can also easily be used within views. It integrates with django-filebrowser, which I will mention below. django-cms integrates with django-tinymce to provide a rich text editor for pages within it. As our website content will have to be maintained by people who may have little or no experience with HTML (or Markdown or anything else that isn't Word), this is obviously desirable. django-filebrowser django-filebrowser is a Django app that … -
Añadir encoding UTF-8 a nuestros archivos .py
Esto es una pequeña ayuda para aquellos que empiezan con Python/Django. A menudo utilizamos variables o comentarios en nuestro código python que tienen caracteres acentuados u otros que no son ASCII. Estos caracteres causan errores de sintaxis como el siguiente: SyntaxError: Non-ASCII character '\xc3' in file /proyecto/app1/models.py on line 5, but no encoding declared; Para solucionarlo nos basta con definir el encoding a utilizar insertando la siguiente línea de texto al comienzo de nuestro archivo .py: # -*- encoding: utf-8 -*- Con esto estaremos especificando que nuestro archivo .py está codificado en UTF-8. La codificación UTF-8 bastará en la mayoría de los casos pero también puedes utilizar otras codificaciones. Aquí tienes más información respecto a este tema. -
Slow Django Requests
So I've had a slice with slicehost for about a year and a half now. I love all the things I can do with my very own relatively cheap server on the Internet. I started out with a 256 slice, and then I talked my wife into upgrading to a 512. I kept putting more things on my server because it was so convenient, and fun to have a 100% static IP on the internet. I've started running my own mail server, and slowly I've been moving all my personal sites to Django. I even host a website on my slice for a small fee. After a little while, I was curious as to why all my Django apps seemed to run so slowly. I don't use my own website very often, so I didn't notice the slowness creeping in. Running top revealed that I was using all of the ram on my 512 slice, and I had about half a gig in swap. I won't be able to talk my wife into moving to yet another price double on my slice, so I decided to try to combat this problem with smarts rather than money. Django apps seemed to … -
Representar campos con choices en nuestras plantillas
Cuando usamos un campo con diferentes opciones (choices) en nuestro modelo utilizamos una lista de elementos cada uno con el valor real que se almacenará en la base de datos seguido por la representación legible del dato. Un ejemplo es el siguiente modelo ... Suponiendo que tenemos una plantilla que recibe un objeto Artista en la variable {{ artista }} normalmente accedemos al valor de sus campos mediante {{ artista.campo }}. Pero al estar usando choices con {{ artista.estilo }} obtendremos el valor almacenado en la base de datos en vez de su representación legible definida en ESTILOS_CHOICES. ¿Cómo acceder a la forma legible del dato? ... -
Instalar PIL en Mac OS X Leopard 10.5.6
Al instalar Django en Mac OS X, si utilizamos ImageField en nuestros modelos necesitaremos PIL (Python Imaging Library), la librería de tratamiento de imágenes para Python. Tras probar con distintos métodos que no han tenido éxito he encontrado un post que explica de una forma sencilla cómo hacerlo. Estos son los pasos a seguir. -
Django-Compact Updates
Getting back into the swing of things on django-compact today: Today's Commits Got concatenation working for both js and css Added minification support via YUI Compressor This second item in the list leads me to a question about best practices when creating a re-distributable Django app. Minification support is an optional flag passed at run time to build your css/js: ./manage.py compact --minify If specified, it will run the concatenated files through the YUI Compressor minifier. Since this tool is java based, and not python :(, I decided to include the jar file in a lib folder under the application folder. I then created a module called yui.py and encapsulated the shell out via Popen in a python class called Compressor. This does assume that the java executable is in your path and is of a version greater than 1.4 (YUI Compressor requires at least 1.4). The question I have is, is there a best practice of where and when to include binaries such as this? I feel that this is pretty clean in that I construct the path to the jar dynamically at run time so i don't assume any particular install location. I could do more up front … -
Django-Compact Updates
Getting back into the swing of things on django-compact today: Today's Commits Got concatenation working for both js and css Added minification support via YUI Compressor This second item in the list leads me to a question about best practices when creating a re-distributable Django app. Minification support is an optional flag passed at run time to build your css/js: ./manage.py compact --minify If specified, it will run the concatenated files through the YUI Compressor minifier. Since this tool is java based, and not python :(, I decided to include the jar file in a lib folder under the application folder. I then created a module called yui.py and encapsulated the shell out via Popen in a python class called Compressor. This does assume that the java executable is in your path and is of a version greater than 1.4 (YUI Compressor requires at least 1.4). The question I have is, is there a best practice of where and when to include binaries such as this? I feel that this is pretty clean in that I construct the path to the jar dynamically at run time so i don't assume any particular install location. I could do more up front … -
My Latest Project: BackTrac Backup System
My life has been pretty busy as of late, mostly with a new project I am working on called BackTrac. I am developing a network backup solution, written entirely in Python - using the Django framework as a front-end web interface.This came at quite a good time, as I've been asked to give a presentation [...] -
Numeric IP field for Django
Some time ago I needed to add an IP field to my model with more records (some hundred thousands). I was going to just add Django's IPAddressField, but I realized that it stores the data as text on the database, and I didn't like the idea.Basically, and IP address is just 4 bytes of data, but it's text representation can use between 7 and 15 bytes. That's not a big different when your model will have few rows, but it's a different when you'll have a huge set of IP addresses, and specially if you want to join tables by it.The only inconvenient of storing the IPs as numbers is that are not human readable if you want to check them directly to database.So, here you have my code that can be used as a replacement of IPAddressField:import IPy from django.db import modelsfrom django import formsfrom django.utils.translation import ugettext as _def _ip_to_int(ip): return IPy.IP(ip).ipdef _int_to_ip(numeric_ip): return IPy.IP(numeric_ip).strNormal()class IPFormField(forms.fields.Field): def clean(self, value): try: _ip_to_int(value) except ValueError: raise forms.ValidationError, \ _('You must provide a valid IP address') return super(IPFormField, self).clean(value)class IPField(models.fields.PositiveIntegerField): ''' IP field for django for storing IPs as integers on database (Django's field IPAddressField stores them as text) ''' __metaclass__ … -
Creating Django Management Commands
Creating a website with Django is great fun, but eventually you’ll need to write a tool to clean up you data, expire old users or one of the myriad of other administration tasks that are involved with running a website. You’ll be very used to using manage.py to create your database and to run your [...] -
Welcome Jacob Kaplan-Moss
I'm very pleased to announce that Jacob Kaplan-Moss has joined Revolution Systems to head up a new line of services around the ever growing Django web development framework. First up are commercial Django Support Plans, but look for more Django related offerings in the near future. Jacob has been a good friend of mine since before Django was even released.  It was a pleasure to work with him at our previous day jobs and I'm very excited for the future ahead.  Not only is he obviously an authority on Django, he's an amazing developer and generally an expert on all things tech. Jacob and Adrian are both great examples of how to lead an Open Source project and grow a real community around it.By offering Django Support packages we hope to help adoption of Django in the business world, which helps grow the community at large.   -
Easier field translation with django-transmeta
django-transmeta is a new project that provides django field translations in a simpler way than existing ones like django-multilingual and transdb.The basis of that simplicity is creating a field in the database table for every translation, so internally we'll have something like:CREATE TABLE app_model ( [...] myfield_en varchar, myfield_ca varchar, [...]);where "en" and "ca" are the languages in our application (English and Catalan in this case).For the developer, translating a model is as simple as adding a metaclass to the model, and specify the fields to translate in its Meta class:from transmeta import TransMetaclass MyModel(models.Model): __metaclass__ = TransMeta name = models.CharField(max_length=64) description = models.TextField() price = models.FloatField() class Meta: translate = ('name', 'description', )Even with this project is still as tricky as transdb and multilingual, its main goal is being really really simple, for its design, for developers, and its code (that mainly it's about 120 lines of code). It also breaks some limitations of transdb (its most simple predecessor IMHO) like translating non-text fields.I also want to mention that I just discovered a new project for translating model fields, named django-modeltranslation, that looks cool, but I don't like the (admin like) registering way to set translatable fields (too much complicated). -
It's time for a change
It’s the era of change, I suppose… Starting today I’m joining Frank Wiles – a good friend and fellow Lawrencian – at his consulting firm, Revolution Systems, LLC. I’m really excited to be working with Frank: he’s a great guy, and a crazy-smart developer and sysadmin. Together, we’re going to be offering professional Django support to companies who need a Django expert on staff, but can’t afford someone full-time. The Django community is terrific; those who are comfortable with the IRC/mailing list support venue can get great assistance that way. -
Django Brasil no Twitter
Agora os artigos coletados pelo agregador de feeds da comunidade serão publicados no Twitter, isso graças à colaboração do djangonauta Arthur Furlan (valeu Arthur, a comunidade agradece!). Então, quem deseja acompanhar a comunidade brasileira de Django pelo Twitter, inscreva-se no @djangobrasil. E se você ainda não possui seu blog cadastrado em nosso agregador de feeds, envie para nós o link para o feed da tag (ou categoria) "Django". Colaborações com código para o site são muito apreciadas e estamos precisamos de mais. Se interessar, acesse a página do projeto. -
Revisiting long running processes in Django
So in my last post on this topic I discussed different ways to handle the problem of running code that wold otherwise cripple your web server, by pushing them off to another process. It was mentioned that there may be other ways to attack the problem, either through Python threads or Django’s signals. This post is a review of those two suggestions. Django’s signals I’ll attack the simpler option first, since the response to whether this solution is viable takes all of one word: no. Signals are not asynchronous by nature and therefore they do not work as a solution to the problem. It is true that you can setup signals to work asynchronously, but you’d have to employ one of the methods discussed to handle that. So if you were to use signals to handle some asynchronous work then all they would really be doing is changing the layout of that code. You’d still need something else to actually handle the asynchronous work. I’ll offer up a simple example of how signal code looks just for completeness. There are three pieces to signals. 1.The signal itself 2.The sending of the signal 3.The listeners of the signal 1. Setting up … -
Full Django Serializers - Part II
In the first part of this article I covered the excludes and extras options to the Wad of Stuff serializer. In this article I introduce the relations option.RelationsThe Wad of Stuff serializers allow you to follow and serialize related fields of a model to any depth you wish. This is why it is considered a "full serializer" as opposed to Django's built-in serializers that only return the related -
Fast Caching with Django and Nginx
I've been toying with optimizing the caching on my blog recently – for my own interest (this humble blog doesn't get all that much traffic). All the same, any speed improvements will only mean snappier page-loads and greater capacity to handle a slashdotting, or similar. I discovered that Nginx has a memcached module that can serve pages directly from memcached without touching the file-system, or a downstream web-app. Which makes for very fast response times. To get it working, you need to set a cache key named with the url of the page, and the value to the HTML. Alas, this means that it would not work with Django's caching mechanism due to the way Django caches unique pages based on the contents of the request header. -
Fast Caching with Django and Nginx
I've been toying with optimizing the caching on my blog recently – for my own interest (this humble blog doesn't get all that much traffic). All the same, any speed improvements will only mean snappier page-loads and greater capacity to handle a slashdotting, or similar. I discovered that Nginx has a memcached module that can serve pages directly from memcached without touching the file-system, or a downstream web-app. Which makes for very fast response times. To get it working, you need to set a cache key named with the url of the page, and the value to the HTML. Alas, this means that it would not work with Django's caching mechanism due to the way Django caches unique pages based on the contents of the request header. Still, the promise of serving up cached pages without even touching Django was most tempting. So I took the cache middleware from Django and butchered it so that it created a simple enough cache key for Nginx to handle. Here's the code that generates a cache key, given a request: def get_cache_key(request, key_prefix=None): if key_prefix is None: key_prefix = settings.CACHE_MIDDLEWARE_KEY_PREFIX cache_key = '%s.%s' % (key_prefix, request.path) return cache_key The following snippet, taken from … -
Django, MySQL & UTF-8
Last week I finally decided to switch my hosting service from MediaTemple to SliceHost. I have been postponing this move for almost a year, since I simply didn’t have the time to redeploy ten separate domains and move all their e-mail accounts. But, in a moment of foolishness, I cancelled my MediaTemple account and opened a brand new SliceHost one with Ubuntu 8.04 - little did I know what I was getting myself into… Actually, the move was pretty painless. MediaTemple’s insistence on using CentOS has been putting me off for the past couple of years, and redeploying my Django sites basically meant changing a few lines in my Fabric deployment scripts. I had been forwarding all my mail to separate Gmail accounts for a while now, so I ended up opening a Google for Domains account and that was ready as well, after some DNS setup. The only problem I faced was with MySQL, as I had expected. I never use MySQL for new projects anymore, Postgres provides a much more robust and consistent solution. However, my MediaTemple service didn’t have a PostgreSQL server, so all my Django projects had to run on MySQL. I did mysqldumps on the …
