Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
So long, djangosnippets, and thanks for all the fish
After two years of maintaining djangosnippets.org, I am pleased to announce that the guys from django-de are going to be taking over and you can expect to see some real improvements. Here is a quick list of things I was able to accomplish under my watch as well as the things I always meant to do but never got around to. Actually did Porting from ?? to modern django The version of djangosnippets I was handed had been written a number of years ago, early 2007 according to the whois record so I think it must have been django .96. The first thing I did was port the codebase to django 1.1. Search The full writeup can be found here, but tl;dr added solr, got many wins including search, "more like this", and ajax-y autocomplete. Discoverability One issue was discoverability -- many of the oldest snippets had the most upvotes or had been the most bookmarked, making it hard to find quality new code. I added date-based filtering to some of the list views to make it easier to find fresher content. Flagging The last thing I added was the ability for users to flag snippets as inappropriate or spam. … -
The sorry state of Python OAuth providers
This is one of those challenging posts to write. The people whose projects I'm going to describe have put in a lot of dedicated, hard work to overcome a challenging subject. Writing an OAuth consumer is a hard problem and writing an OAuth provider is an even harder problem. The efforts put in by the authors of these projects has been nothing short of incredible. The problem, however, is that the existing projects are not usable as-is, and need the support of the community in order to improve. The terrible thing is that this is a solved problem within our community. Python based projects are successfully implementing OAuth providers, and often using internally hacked versions of the efforts I'm about to describe. However, they aren't giving this back to the community. It might be that they want to protect their competitive edge, but I'm going to be nice and say that it's because their too busy to find time to send pull requests back. In any case, let me present our use case. For Consumer Notebook we want an API. We want to be able to track usernames, passwords, and the application using our API - which is the OAuth … -
The sorry state of Python OAuth providers
This is one of those challenging posts to write. The people whose projects I'm going to describe have put in a lot of dedicated, hard work to overcome a challenging subject. Writing an OAuth consumer is a hard problem and writing an OAuth provider is an even harder problem. The efforts put in by the authors of these projects has been nothing short of incredible. The problem, however, is that the existing projects are not usable as-is, and need the support of the community in order to improve. The terrible thing is that this is a solved problem within our community. Python based projects are successfully implementing OAuth providers, and often using internally hacked versions of the efforts I'm about to describe. However, they aren't giving this back to the community. It might be that they want to protect their competitive edge, but I'm going to be nice and say that it's because their too busy to find time to send pull requests back. In any case, let me present our use case. For Consumer Notebook we want an API. We want to be able to track usernames, passwords, and the application using our API - which is the OAuth … -
The Django community in 2012
In 2007, and again in 2009, I made an attempt to measure the size of the Django community. By popular request — okay, a couple people asked for it, whatever — let’s do this thing again. Users In 2007 and 2009, I shared three ways of looking at how many people are using Django: hits to the website, downloads of the Django tarball, and sites listed as “using Django.” So, here’s an overview of users, some notes on interpreting these numbers follow: -
Using LESS with Django
Lately, I’ve been working on creating a simplified work flow for my front end work here at Caktus. There are all sorts of new and helpful tools to optimize the creative process, allowing for faster iterations, and greater overall enjoyment. As with any new tool, there are a few options to choose from: LESS and ... -
Se buscan buenos programadores
Hi ha una frase que diu que "a Internet ningú saps que ets un ca". El mateix es pot dir actualment del llenguatge de programació que mou una plana o aplicació web, mentre la plana faci el que ha de fer, a l'usuari que l'està utilitzant no l'interessa el més mínim amb què està feta. Que avui en dia les planes acabin en php, asp, .do, no deixa de ser anecdòtic. Els bastiments de programació més moderns fins i tot amaguen amb què està feta la web a simple vista, a l'usuari no li cal la informació i potser estàs donant massa informació a algun visitant no desitjat. Aquest apunt ve arrel d'un post a bonillaware, titulat se buscan buenos programadores. El post és força intressant i l'oferta de feina crec que també, però allà faig una petita reflexió: no entenc com una companyia que va de cools pot fer un error tan de base com cercar bons programadors en un llenguatge concret. Bé, ho entenc si el que cerques no són bons programadors, sinó gent experimentada amb una tecnologia en concret. Vuit anys d'experiència no et converteixen en un bon programador en res. Si no has après el que … -
Release 0.7.0 beta 1
We just released LFS 0.7.0 beta 1. This is the next feature release of LFS. What's new? Added customer related taxes Added global image management Added django_compressor Added pluggable shipping price calculators Added pluggable order number generation Added calculation of base price Added product attachments Added more portlets: featured products, for sale products Aded SEO information for shop and pages Added portlets for pages Added type of quantity field Added context aware help for the management interface Improved pluggable product price calculators Improved pluggable payment processors Improved mails templates Information You can find more information and help on following locations: Documentation on PyPI Demo Releases on PyPI Source code on bitbucket.org and github. Google Group lfsproject on Twitter IRC -
Release 0.6.8
We just released LFS 0.6.8. This is a yet another bugfix release of the 0.6 branch. Changes Bugfix: fixed duplicate labels and invalid tags (Maciej Wisniowski) Bugfix: fixed calculation of topsellers when order items has no product (Maciej Wisniowski) Updated polish translations (Maciej Wisniowski) Updated german translations Information You can find more information and help on following locations: Documentation on PyPI Demo Releases on PyPI Source code on bitbucket.org and github. Google Group lfsproject on Twitter IRC -
Our Custom Mixins
UPDATE: We've released a Github repo and a PyPI package with our mixins. Feel free to fork and submit new ones through a pull-request. Let's just start out and say it, Class Based Views. Ooohhhh. Unfortunately the topic of class based views is thought of as somewhat of a dark art in the Django community. It doesn't help that the documentation is still lacking but I find a lot of people, especially on Reddit, refuse to use them. For whatever reason, it's a hard pill for some to swallow. Before DjangoCon 2011, we started playing with class-based views. At first they seemed like a nightmare and without decent docs, we got frustrated really quickly. Skip forward to today and I can't imagine writing old function-based views again. Some argue that the generic views are only for generic applications and that, somehow, their work is far too custom and complex to be handled in a generic class-based view. Based on my experience, 99% of the time, they would be wrong. We plan on covering generic class-based views extensively with GSWD. Today, I'd like to share some mixins we have cooked up, on a rather large client project, that have helped us … -
Welcome!
We are excited to finally launch the full website for this years DjangoCon Europe. Early bird registration as well as our call for papers is now open and we posted more details on our sponsoring packages.The early bird registration will run until the 31st of March, so sign up now! The call for paper will be until the 15th of April. -
Key-based cache expiration with Django
Last week, the team over at 37Signals wrote up an article on their newly implemented Key-based cache expiration system and it hit me: It's such a simple idea with obvious benefits, why hadn't I implemented a similar caching mechanism before? Being a Django user, the Rails code didn't make much sense to me but the concept certainly did - so here's my take on it with a quick Django example. -
Key-based cache expiration with Django
Last week, the team over at 37Signals wrote up an article on their newly implemented Key-based cache expiration system and it hit me: It's such a simple idea with obvious benefits, why hadn't I implemented a similar caching mechanism before? Being a Django user, the Rails code didn't make much sense to me but the concept certainly did - so here's my take on it with a quick Django example. Background I've just implemented this caching strategy for WhisperGifts for a re-launch that will go live in the next few weeks. We allow couples to publish an online gift list, then let people select items from that list. Pretty basic stuff, but rendering the gift list can require n+1 queries due to the way that my purchase data is kept. This hasn't been a big issue until now, when I've built new functionality and generally just extended things a bit. The cache strategy is so simple it's taken longer to write up here than it did to alter my existing codebase. My basic model is as follows: Registry, the top-level "collection" of items for each wedding. Item, of which there are many for each Registry Buyer, of which there are … -
Key-based cache expiration with Django
Last week, the team over at 37Signals wrote up an article on their newly implemented Key-based cache expiration system and it hit me: It's such a simple idea with obvious benefits, why hadn't I implemented a similar caching mechanism before? Being a Django user, the Rails code didn't make much … -
Generic Layouts in Crispy Forms
Just a quick tip and sanity check, today, about something I ran into with django-crispy-forms, the awesome new form library from Miguel Araujo. This morning, I converted the project we've been building for a client (currently some 1,700 or so files, counting templates, CSS, and icons) from django-uni-form to django-crispy-forms. It's a pretty painless transition, actually. Just do some find-and-replace across your files, basically changing any instance of uni- to crispy- (well, and form to forms), and you're good to go. Then, however, I wanted to convert two large forms that we have, which share 90% of their fields, to using the sharable Layout objects that django-crispy-forms gives us. Basically, the forms looked like this: class FirstForm(GenericAppFormForTheExample): ... def __init__(self, *args, **kwargs): ... self.helper = FormHelper() self.helper.layout = Layout( "field1", "field2", "special-field", [field3 through field20] class SecondForm(GenericAppFormForTheExample): ... def __init__(self, *args, **kwargs): ... self.helper = FormHelper() self.helper.layout = Layout( "field1", "field2", "special-field2", [field3 thorugh field20] Obviously that was a lot of repetition that we could cut out now that these inheritable layouts exist. By the way, I'm pretty sure this would have been possible in django-uni-form but likely not as friendly. First I started off by creating the shared resources. … -
You should Heroku
In mid-November me and my fiancee, Audrey Roy began our startup. We had been frustrated with trying to do on-line product research and came up with an idea to take the lessons learned from Django Packages / Open Comparison and apply them to a commercial effort. The result has been Consumer Notebook, and it's been a steadily growing success. We've been bootstrapping the project. That means supporting it with consulting and grinding away on it during our free time. That means 12-16 hour days of Python, Django, and Javascript coding, marketing, system administration, graphic design, communicating with users and vendors, and a thousand other tasks. Since we've had to explore new techniques for making things work on the backend and front end, that means we've needed to have a robust system that is trivial to deploy and certain to never go down. Which, of course, requires serious sys admin skills. The Big Problem I hate system administration work. Sys admin is boring. I find it tedious and dull. Devops doesn't make it easier/faster, it just makes it possible to do it at a large scale. Fortunately for me, my fiancee likes the sys admin side of things. However, she's got … -
You should Heroku
In mid-November me and my fiancee, Audrey Roy began our startup. We had been frustrated with trying to do on-line product research and came up with an idea to take the lessons learned from Django Packages / Open Comparison and apply them to a commercial effort. The result has been Consumer Notebook, and it's been a steadily growing success. We've been bootstrapping the project. That means supporting it with consulting and grinding away on it during our free time. That means 12-16 hour days of Python, Django, and Javascript coding, marketing, system administration, graphic design, communicating with users and vendors, and a thousand other tasks. Since we've had to explore new techniques for making things work on the backend and front end, that means we've needed to have a robust system that is trivial to deploy and certain to never go down. Which, of course, requires serious sys admin skills. The Big Problem I hate system administration work. Sys admin is boring. I find it tedious and dull. Devops doesn't make it easier/faster, it just makes it possible to do it at a large scale. Fortunately for me, my fiancee likes the sys admin side of things. However, she's got … -
15 Key Resources to Learn Django
Learning Python and Django is easy if you have the right resources at your fingertips. Coming from pretty much only having studied programming in school, I started working as a developer at Yipit with almost no web programming experience. In a little fewer than ten weeks, I’ve become comfortable navigating and making large changes to the whole Python/Django application code as well as contributing new features (interested in learning Django at Yipit? Join us!). While the learning process wasn’t gut-wrenching, I certainly ran into some hefty roadblocks that would have been almost insurmountable had coworkers not pointed me to the resources below: Comparing Python to Other Languages If you know another programming language already, you can easily leverage that knowledge by finding out the differences between Python and that other language, and then by focusing in on learning those differences. Python & Java – A Side by Side Comparison I knew enough Java already from college, and doing some quick reading online saved me a lot of time. I would highly recommend reading this article if you know Java already. It helped me form a mental road-map of what areas to focus on. Also, the Python wiki has a good … -
AJAX Autocomplete Search with Django and jQuery
Let's say you have some data that you want to autocomplete in a text field as the user types. This is what your Django model might look like if you were searching for drug names: from django.db import models class Drug(model.Model): rxcui = models.IntegerField() short_name = models.CharField(max_length=50) is_brand = models.IntegerField(max_length=1) It's very likely that your data is in a different format (csv or pipe delimited), like this: Rxcui|Short Name|Is Brand 1234 |Advil |1 So we need to import that data. A database copy command (postgres, mysql, sqlite) will not deal very nicely with our Django auto-incrementing keys, so we need to add the data using a django view, such as this: import csv from myproject.main.models import Drug def load_drugs3(file_path): "this loads drugs from pipe delimited file with headers" reader = csv.DictReader(file_path) for row in reader: drug = Drug(rxcui=row['Rxcui'], short_name=row['Short Name'], is_brand=row['Is Brand']) drug.save() Now load the django console and import the data: $ python manage.py shell $ from main.view import load_drugs $ load_drugs('/absolute/path/to/pipe/file.txt') Cool. Now we need to actually write the template where the search is. We'll use jQuery Autocomplete because that's what the cool kids do. Let's first import jQuery and jQueryUI in our base template: Now let's add … -
Change Request Workflow
Before we start, let me explain a bit about what the app we're covering here is. It's a geo-spatial database, basically, of Points of Interest (POIs) for housing communities that we developed for a client of ours (or, rather, are still developing). Users and editors can both enter Points into the database, which is PostgreSQL with PostGIS, and then they can be associated with any community. Obviosuly, though, that leads to the problem of Community A editing a POI and Community B showing that data without their knowledge, so we'd like to have an editor look at the changes first. That's the need that lead to our workflow. Models First, let's start with the models. class POIAbstract(LumberjackModel, models.Model): category = models.ForeignKey(Category, related_name="%(class)s_points") name = models.CharField(max_length=255) address = models.CharField(max_length=255) address2 = models.CharField(max_length=255, blank=True) city = models.CharField(max_length=100) state = USPostalCodeField() zip_code = models.CharField(max_length=10) phone = PhoneNumberField(blank=True, default="") url = models.URLField(blank=True, default="") point = models.PointField(blank=True, null=True, editable=False) objects = models.GeoManager() class Meta: abstract = True def __unicode__(self): return self.name @property def coords(self): """ Return tuple of lat,lng """ if self.point: return (self.point.get_coords()[1], self.point.get_coords()[0]) return (None, None) @property def full_address(self): """ Return a string of the full address """ addresses = [self.address, self.address2, self.city, … -
AJAX Autocomplete Search with Django and jQuery
-
AJAX Autocomplete Search with Django and jQuery
Let’s say you have some data that you want to autocomplete in a text field as the user types. This is what your Django model might look like if you were searching for drug names: 1 2 3 4 5 from django.db import models class Drug(model.Model): rxcui = models.IntegerField() short_name = models.CharField(max_length=50) is_brand = models.IntegerField(max_length=1) It’s very likely that your data is in a different format (csv or pipe delimited), like this: 1 2 Rxcui|Short Name|Is Brand 1234 |Advil |1 So we need to import that data. A database copy command (postgres, mysql, sqlite) will not deal very nicely with our Django auto-incrementing keys, so we need to add the data using a django view, such as this: 1 2 3 4 5 6 7 8 import csv from myproject.main.models import Drug def load_drugs(file_path): "this loads drugs from pipe delimited file with headers" reader = csv.DictReader(open(file_path)) for row in reader: drug = Drug(rxcui=row['Rxcui'], short_name=row['Short Name'], is_brand=row['Is Brand']) drug.save() Now load the django console and import the data: 1 2 3 $ python manage.py shell $ from main.view import load_drugs $ load_drugs('/absolute/path/to/pipe/file.txt') Cool. Now we need to actually write the template where the search is. We’ll use jQuery Autocomplete because that’s … -
AJAX Autocomplete Search with Django and jQuery
Let’s say you have some data that you want to autocomplete in a text field as the user types. This is what your Django model might look like if you were searching for drug names: 1 2 3 4 5 from django.db import models class Drug(model.Model): rxcui = models.IntegerField() short_name = models.CharField(max_length=50) is_brand = models.IntegerField(max_length=1) It’s very likely that your data is in a different format (csv or pipe delimited), like this: 1 2 Rxcui|Short Name|Is Brand 1234 |Advil |1 So we need to import that data. A database copy command (postgres, mysql, sqlite) will not deal very nicely with our Django auto-incrementing keys, so we need to add the data using a django view, such as this: 1 2 3 4 5 6 7 8 import csv from myproject.main.models import Drug def load_drugs(file_path): "this loads drugs from pipe delimited file with headers" reader = csv.DictReader(open(file_path)) for row in reader: drug = Drug(rxcui=row['Rxcui'], short_name=row['Short Name'], is_brand=row['Is Brand']) drug.save() Now load the django console and import the data: 1 2 3 $ python manage.py shell $ from main.view import load_drugs $ load_drugs('/absolute/path/to/pipe/file.txt') Cool. Now we need to actually write the template where the search is. We’ll use jQuery Autocomplete because that’s … -
Change Request Workflow
Before we start, let me explain a bit about what the app we're covering here is. It's a geo-spatial database, basically, of Points of Interest (POIs) for housing communities that we developed for a client of ours (or, rather, are still developing). Users and editors can both enter Points into the database, which is PostgreSQL with PostGIS, and then they can be associated with any community. Obviosuly, though, that leads to the problem of Community A editing a POI and Community B showing that data without their knowledge, so we'd like to have an editor look at the changes first. That's the need that lead to our workflow. Models First, let's start with the models. class POIAbstract(LumberjackModel, models.Model): category = models.ForeignKey(Category, related_name="%(class)s_points") name = models.CharField(max_length=255) address = models.CharField(max_length=255) address2 = models.CharField(max_length=255, blank=True) city = models.CharField(max_length=100) state = USPostalCodeField() zip_code = models.CharField(max_length=10) phone = PhoneNumberField(blank=True, default="") url = models.URLField(blank=True, default="") point = models.PointField(blank=True, null=True, editable=False) objects = models.GeoManager() class Meta: abstract = True def __unicode__(self): return self.name @property def coords(self): """ Return tuple of lat,lng """ if self.point: return (self.point.get_coords()[1], self.point.get_coords()[0]) return (None, None) @property def full_address(self): """ Return a string of the full address """ addresses = [self.address, self.address2, self.city, … -
Release 0.6.7
We just released LFS 0.6.7. This is a yet another bugfix release. Changes Bugfix: fixed displaying of manual topsellers (Maciej Wi?niowski) Bugfix: topsellers - avoid empty product_id for discounts (Maciej Wi?niowski) Bugfix: take care of variants for deliverability (Maciej Wi?niowski) Bugfix: fixed bug causing strange behaviour while creating variants (Maciej Wi?niowski) Bugfix: fixed product filtering for product management views; #issue 142 Bugfix: added csrf token to active-images-update-form Bugfix: fixed lfs_init for Postgres; issue #129 Added translations for filter buttons and fix for topseller positions (Maciej Wi?niowski) Updated polish translations (Maciej Wi?niowski) Updated german translations News: We have setup a GitHub mirror of LFS. The docs are running on our own domain now (still hosted on RTD) and have a new layout: http://docs.getlfs.com/ Information You can find more information and help on following locations: Documentation on PyPI Demo Releases on PyPI Source code on bitbucket.org and github. Google Group lfsproject on Twitter IRC -
Yet another tutorial for building a blog using Python and Django - Part 1
While I’m extremely fond of Perl for quick hacks and scripts, and have used PHP a fair amount for web development purposes (both on its own and with the CodeIgniter framework), there is one language I love above all others, and that’s Python. I’ve found that, when compared to PHP or Perl, at least for me, it’s a lot easier to “get into the zone” when programming in Python, the code I produce tends to be a lot more readable and easier to follow, and the interactive interpreter makes it really easy to figure out what’s going on in a way that just isn’t possible with PHP or Perl. Also, Python was always designed to be an object-oriented language, and IMHO has a better object model than either Perl or PHP. While it would be fair to say that Python doesn’t have a single web development framework that monopolises developer’s attention the way Rails does for Ruby programmers, Django is undoubtedly the best-known Python framework. It’s solid, easy to use, and has the best documentation of any web development framework I’ve ever seen (don’t get me wrong, CodeIgniter in particular has very good documentation, but Django’s is exceptional). In this …
