Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Migració a postgres des de sqlite
Pels qui no ho sabíeu aquest blog corria damunt una base de dades sqlite3. La base de dades és prou ràpida per les necessitats d'un blog com aquest, però té un emperò considerable: consumeix molta memòria comparada amb un mysql o postgresql. Quan el blog duia una parell de setmanes amb visites que consultàven molts apunts, sqlite començava a cachejar i el consum de memòria de l'aplicació del blog es disparava fins als 160 Mb, mass si ho comparam amb altres aplicacions tant o més complexes que executant-se amb Postgresql estàven entre 30 i 50 Mb. El consum de Postgres és una altra cosa, però com que es reparteix millor entre les aplicacions el resultat final és un estalvi de memòria. El procés per passar d'sqlite3 a Postgres ha estat el següent: Feim un dump de les dades cap a json. Això es pot fer des de Django amb la comanda dumpdata, per exemple: python manage.py dumpdata contenttypes > dumps/contenttypes.json He fet dumps de sites, auth per la part d'usuaris, contenttypes, i després de tota la resta d'aplicacions que fa servir el blog. Cream la base de dades i l'usuari a Postgresql que farem servir, donant-li permisos de creació de … -
Lately
I have really gotten out of the habit of blogging and I hate that. It's not because I don't have anything to talk about. Quite the contrary -- a lot has been going on. I thought today would be a good chance to provide a recap of things I have been doing and thinking. StudioNow / AOL Back in January, the startup I have been working on since very close to it's beginning three, well almost four years ago now, was acquired by AOL. This has been the single best experience of my career. To build something from scratch that didn't exist before with a group of really smart folks and turn it into something valuable enough for someone else to purchase at a multiple that made everyone involved happy. I started off not knowing anything about Python, about ffmpeg, about video on the web, much less anything to do with cloud computing. Looking back at what we have accomplished technically, and I wouldn't have thought it possible or likely been able to fully grasp when first starting. I am now close to 6 months on the other side of the acquisition as a full time employee of AOL. I … -
Lately
I have really gotten out of the habit of blogging and I hate that. It's not because I don't have anything to talk about. Quite the contrary -- a lot has been going on. I thought today would be a good chance to provide a recap of things I have been doing and thinking. StudioNow / AOL Back in January, the startup I have been working on since very close to it's beginning three, well almost four years ago now, was acquired by AOL. This has been the single best experience of my career. To build something from scratch that didn't exist before with a group of really smart folks and turn it into something valuable enough for someone else to purchase at a multiple that made everyone involved happy. I started off not knowing anything about Python, about ffmpeg, about video on the web, much less anything to do with cloud computing. Looking back at what we have accomplished technically, and I wouldn't have thought it possible or likely been able to fully grasp when first starting. I am now close to 6 months on the other side of the acquisition as a full time employee of AOL. I … -
GSOC status report
I’ve been behind on the Summer of Code work. This week I started working on converting model tests, and converted 3 changes. I also submitted a patch clarifying the documentation (and help text) of the dumpdata command. I’ve been going more slowly than I should because I’ve had to read a lot of documentation about [...] -
Gracious E-Mail Bounce Handling in Django with Postmark
When a user signs up on your website with an invalid email address, how do you let them know? In most cases, the bounces go into the inbox of an admin who ignores them, or even worse they don't go into any monitored inbox. Recently I've started using a 3rd party for my email delivery, which has made dealing with bounced emails much easier both for me and my customers. Read on to see how I integrated Postmark's bounce API with Django, and implemented a user-friendly alert on DjangoSites.org when signup emails bounce. -
Gracious E-Mail Bounce Handling in Django with Postmark
Recently I've been on a quest to simplify the way I deliver my websites to my customers. Not that my customers know: the primary changes are relating to server monitoring, being proactive about a few things, and getting rid of elements that I don't understand. One of the things I really didn't understand that well and wanted to offload to somebody else was my email delivery. I already use a company called Tuffmail to handle my mailboxes (that is, for my actual email boxes - not email sent from within my Django applications) and I'm extremely happy with their service. I use and trust Tuffmail because I know I can't keep on top of everything I need to know to run SMTP and IMAP services properly and securely. The next step in my outsourcing process was to find a company to deliver email sent from within my Django applications. Until now I've been running a local Postfix server used for delivering mail but not receiving it, and for most emails that works fine. As websites grow, though, it becomes harder to manage what happens with bounced email and also to guarantee delivery - many email providers seem more than happy … -
Gracious E-Mail Bounce Handling in Django with Postmark
Recently I've been on a quest to simplify the way I deliver my websites to my customers. Not that my customers know: the primary changes are relating to server monitoring, being proactive about a few things, and getting rid of elements that I don't understand. One of the things I … -
Optimizing for Shared Hosting
Shared hosting, no matter how their packages are painted, have limits. Staying away from hogging too much CPU, memory, and other resources can ensure the longevity and performance of your shared hosting account. If you are just looking into how to build a site, or if you already have a very busy site on shared hosting, these guidelines can help you get the most out of your shared hosting account before making the switch to more expensive hosting. One of the goals in this post is to encourage "good neighbor" practices that will ensure you aren't disrupting fellow users on the server that hosts your account. This also ensures that you won't get any of these principles also apply to other types of hosting, but this is written with shared hosting in mind. Common bottlenecks With modern shared hosting, you generally have plenty of available disk space and bandwidth. The most common bottlenecks encountered by a site in shared hosting are CPU and databases. Memory usage is a less common bottleneck, but it can happen depending on how well or how poorly your site's code is written. On-the-fly page generation takes quite a bit of CPU compared to serving flat … -
Backwards compatibility
Backwards compatibility is pain sometimes: # We need backwards compatibility with code which spells it this way: # def my_view(): pass # my_view = cache_page(my_view, 123) # and this way: # my_view = cache_page(123)(my_view) # and this: # my_view = cache_page(my_view, 123, key_prefix="foo") # and this: # my_view = cache_page(123, key_prefix="foo")(my_view) # and possibly this way (?): # my_view = cache_page(123, my_view) -
Django 1.2.1 lançado
Django 1.2.1 lançado -
Django 1.2.1 lançado
Django 1.2.1 lançado -
Taskqueues in App Engine
App Engine has task queues as an experimental feature. There's nothing fancy here, it's just a way of queueing something up to be run later. We've probably all written a few queues in our time, the task queue is just a continuation of that. Add a URL to be executed a certain point and a scheduler will come along and try all the urls in the queue. For Arecibo we use this to do the post processing on an error. When an error comes into Arecibo we write it to the datastore quickly, we then add in one task queue that will: figure out the grouping, figure out any notifications, figure out the user agent (surprisingly a bit expensive). That post processing will be done async via the task. First thing that I noticed about the queue is that the development server doesn't run the task queue automatically meaning that all my unit tests failed. So here's a way to do it immediately if you are not in production: if os.environ.get('SERVER_SOFTWARE', '').startswith('Dev'): # send the signal, otherwise we have to clicking buttons # to process the queue send_signal(None, self.id) else: # enqueue the send notification # if development taskqueue.add(url=reverse("error-created", args=[self.id,])) … -
util
D’oh: django/contrib/admin/util.py django/contrib/admindocs/utils.py django/contrib/comments/views/utils.py django/contrib/formtools/utils.py django/contrib/gis/db/backends/util.py django/contrib/gis/tests/utils.py django/contrib/localflavor/it/util.py django/contrib/localflavor/se/utils.py django/contrib/localflavor/uy/util.py django/contrib/messages/utils.py django/core/files/utils.py django/core/mail/utils.py django/db/backends/util.py django/db/utils.py django/forms/util.py django/http/utils.py django/test/utils.py tests/regressiontests/forms/util.py -
Creating a Cacti Alternative
I want to replace cacti. I love graphs and information collation as much as the next guy, but I want something more and at the same time, something much less. I have recently finished my second year of a Computer Science course at the University of Nottingham, and thus it is time to start thinking [...] -
An inline image Django template filter
Adding image fields to a Django model is easy, thanks to the built-in ImageField class. Auto-resizing uploaded images is also a breeze, courtesy of sorl-thumbnail and its forks/variants. But what about embedding resized images inline within text content? This is a very common use case for bloggers, and it's a final step that seems to be missing in Django at the moment. Having recently migrated this site over from Drupal, my old blog posts had inline images embedded using image assist. Images could be inserted into an arbitrary spot within a text field by entering a token, with a syntax of [img_assist nid=123 ... ]. I wanted to be able to continue embedding images in roughly the same fashion, using a syntax as closely matching the old one as possible. So, I've written a simple template filter that parses a text block for tokens with a syntax of [thumbnail image-identifier], and that replaces every such token with the image matching the given identifier, resized according to a pre-determined width and height (by sorl-thumbnail), and formatted as an image tag with a caption underneath. The code for the filter is below. -
An inline image Django template filter
Adding image fields to a Django model is easy, thanks to the built-in ImageField class. Auto-resizing uploaded images is also a breeze, courtesy of sorl-thumbnail and its forks/variants. But what about embedding resized images inline within text content? This is a very common use case for bloggers, and it's a final step that seems to be missing in Django at the moment. Having recently migrated this site over from Drupal, my old blog posts had inline images embedded using image assist. Images could be inserted into an arbitrary spot within a text field by entering a token, with a syntax of [img_assist nid=123 ... ]. I wanted to be able to continue embedding images in roughly the same fashion, using a syntax as closely matching the old one as possible. So, I've written a simple template filter that parses a text block for tokens with a syntax of [thumbnail image-identifier], and that replaces every such token with the image matching the given identifier, resized according to a pre-determined width and height (by sorl-thumbnail), and formatted as an image tag with a caption underneath. The code for the filter is below. -
GSOC Status Report
So… I’ve been working on the summer of code project now for a bit. Hopefully I’ll be more productive next week, as this week was frustrating with non-SOC things. The main SOC things I did this week involved getting stuff set up to do more work next week. I spent a bunch of time setting [...] -
Backtrac Implementation – The Major Decisions
Thinking a lot about my 3rd year project, I've been considering how to implement a backup system based around a Django server. So far, I have reached the conclusion that the system will consist of three main parts: The Django server (yet to be named) The client daemon (backtracd) The backup library itself (backuplib) As [...] -
On Django And Migrations
On Django And Migrations. South author Andrew Godwin on the plans for migrations in Django. His excellent South migration library will be split in to two parts—one handling database abstraction, dependency resolution and history tracking and the other providing autodetection and the South user interface. The former will go in to Django proper, encouraging other migration libraries to share the same core abstractions. -
Class-based views and thread safety
I previously wrote about a thread-safety bug I encountered in writing a middleware object. I recently found a very similar situation in a class-based view I was modifying, and thought it was worth writing up what the problem was and how I solved it. Interestingly, there's a discussion going on in Django-developers at the moment on class-based views which touches on many of the same issues. By 'class-based view', I mean that rather than just being a function which is called from urls.py when the URL matches its pattern, this was a class with a __call__ method. In theory, that should work in exactly the same way as a function view - to Python, functions and callable objects are pretty much the same thing. One of the reasons that the controller was written as a class was that it had multiple utility methods that were called during the rendering process. To make it easier to pass data between the methods, various things were set as instance variables - self.item_id, self.key, and so on. However, the urlpattern for this view was defined like this: (r'^(?P<key>)/((?P<page>[^/]+)/)?', FormController()), which meant that it was instantiated just once per process: when the urls are first … -
On Django And Migrations
For at least a year now, people have been suggesting to me that South should be in Django core.I've always resisted, for good reason - not only because of South's relative immaturity at the time, but also because forcing a single solution would, I think, not be a good thing in general. (South, admittedly, has a few design issues, but it's all about tradeoffs.) However, last week at djangocon.eu, I revealed, in rapid-fire English (apologies to non-native speakers for that, we're working on time dilation) my Grand Plan for the future of South and Django migrations in general, one that seems to have the approval of at least a few members of Django core. The proposal is not, as some expected, to put South completely into Django core; instead, South will be split into two parts. One, the part that implements database abstraction, dependency resolution, and history tracking, would be put into Django itself. The other part - autodetection, model freezing, and so forth, will remain as South. (If you'd like more in-depth details of the split, see my post to django-developers.) The idea behind this is simple - take the parts of South that nearly any migration solution would … -
Appending the request URL to SQL statements in Django
Appending the request URL to SQL statements in Django. A clever frame-walking monkey-patch which pulls the most recent HttpRequest object out of the Python stack and adds the current request.path to each SQL query as an SQL comment, so you can see it in debugging tools such as slow query logs and the PostgreSQL “select * from pg_stat_activity” query. -
On Django And Migrations
For at least a year now, people have been suggesting to me that South should be in Django core. I've always resisted, for good reason - not only because of South's relative immaturity at the time, but also because forcing a single solution would, I think, not be a good thing in general. (South, admittedly, has a few design issues, but it's all about tradeoffs.) However, last week at djangocon.eu, I revealed, in rapid-fire English (apologies to non-native speakers for that, we're working on time dilation) my Grand Plan for the future of South and Django migrations in general, one that seems to have the approval of at least a few members of Django core. The proposal is not, as some expected, to put South completely into Django core; instead, South will be split into two parts. One, the part that implements database abstraction, dependency resolution, and history tracking, would be put into Django itself. The other part - autodetection, model freezing, and so forth, will remain as South. (If you'd like more in-depth details of the split, see my post to django-developers.) The idea behind this is simple - take the parts of South that nearly any migration solution … -
Class-based views and thread safety
I previously wrote about a thread-safety bug I encountered in writing a middleware object. I recently found a very similar situation in a class-based view I was modifying, and thought it was worth writing up what the problem was and how I solved it. Interestingly, there's a discussion going on in Django-developers at the moment on class-based views which touches on many of the same issues. By 'class-based view', I mean that rather than just being a function which is called from urls.py when the URL matches its pattern, this was a class with a __call__ method. In theory, that should work in exactly the same way as a function view - to Python, functions and callable objects are pretty much the same thing. One of the reasons that the controller was written as a class was that it had multiple utility methods that were called during the rendering process. To make it easier to pass data between the methods, various things were set as instance variables - self.item_id, self.key, and so on. However, the urlpattern for this view was defined like this: (r'^(?P<key>)/((?P<page>[^/]+)/)?', FormController()), which meant that it was instantiated just once per process: when the urls are first … -
Class-based views and thread safety
I previously wrote about a thread-safety bug I encountered in writing a middleware object. I recently found a very similar situation in a class-based view I was modifying, and thought it was worth writing up what the problem was and how I solved it. Interestingly, there's a discussion going on in Django-developers at the moment on class-based views which touches on many of the same issues. By 'class-based view', I mean that rather than just being a function which is called from urls.py when the URL matches its pattern, this was a class with a __call__ method. In theory, that should work in exactly the same way as a function view - to Python, functions and callable objects are pretty much the same thing. One of the reasons that the controller was written as a class was that it had multiple utility methods that were called during the rendering process. To make it easier to pass data between the methods, various things were set as instance variables - self.item_id, self.key, and so on. However, the urlpattern for this view was defined like this: (r'^(?P<key>)/((?P<page>[^/]+)/)?', FormController()), which meant that it was instantiated just once per process: when the urls are first …