Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
django-readonly-site
Ever wanted to keep your site online, but shut some parts of it (such as the checkout, or the signup page) down for database maintenance or other such reasons? I've just pushed a little helper app to GitHub, which I've previously extracted from WhisperGifts. It's called django-readonly-site and is available in PyPi now. -
django-readonly-site
Ever wanted to keep your site online, but shut some parts of it (such as the checkout, or the signup page) down for database maintenance or other such reasons? I've just pushed a little helper app to GitHub, which I've previously extracted from WhisperGifts. It's called django-readonly-site and is available in PyPi now. -
django-readonly-site
Occasionally I need to take WhisperGifts offline, but still show some parts of the site to users. This has included some system changes that require the site to be non-functional for a little while (such as doing a deployment with a bunch of backwards-incompatible changes, or large database migrations) and for server moves, whilst waiting for DNS changes to propogate. To do this, I wrote a little library that I could toggle within my Django settings. I've just pulled it out of the WhisperGifts codebase, and django-readonly-site is now available on GitHub. I think it's pretty simple to use. Install it with pip install django-readonly-site, add readonly to your Django projects' settings.INSTALLED_APPS, and set settings.SITE_READ_ONLY = True. More options are available to keep parts of your site online, see the README for more details. By keeping parts of your site online (such as the homepage, about us page, and in my case a customers' registry listing) you can provide a transitional experience to users, while the database-intensive and high-integrity parts of the site (such as signup, account management, and checkout) are taken offline with a polite "Sorry, we're temporarily unavailable" message. Just after I had to quickly move to Rackspace … -
django-readonly-site
Occasionally I need to take WhisperGifts offline, but still show some parts of the site to users. This has included some system changes that require the site to be non-functional for a little while (such as doing a deployment with a bunch of backwards-incompatible changes, or large database migrations) and … -
EuroPython Intro to Django Workshop
We (myself and Audrey Roy) have been asked to fill in a tutorial session at EuroPython 2013 on the afternoon July 3rd! Therefore, it is my honor to announce our EuroPython Intro to Django Workshop! (see the bottom of this article for registration instructions) Workshop Description Bring your laptops and join the authors of Two Scoops of Django for a hands-on Django workshop. We'll build a real, working site from the ground up, using the upcoming Django 1.6 and covering Python 2.7/3.3. We'll cover as much as we can get through, including but not limited to: Python and Django setup Project creation App creation models The Django admin UI Views Migrations with South User image uploads New user registration Basic forms Basic internationalization Prerequisites Attendees will need their own laptops. We'll cover installation, but if you can come with the following already installed you'll enjoy workshop more: Really encouraged: Python 3.3 or Python 2.7 Really encouraged: virtualenv Really encouraged: pip If you are familiar with virtualenv, please have an instance created with the following already installed: git+git://github.com/django/django.git@1.6b1 Pillow==2.0.0 South==0.8.1 django-bootstrap-registration==0.1.2 django-braces==1.0.0 django-crispy-forms==1.3.2 django-reg==1.0.1 Registration Details Date: July 3, 2013 Time: 14:30 - 18:30 Track: Pizza Napoli Instructors: Daniel Greenfeld and … -
EuroPython Intro to Django Workshop
We (myself and Audrey Roy) have been asked to fill in a tutorial session at EuroPython 2013 on the afternoon July 3rd! Therefore, it is my honor to announce our EuroPython Intro to Django Workshop! (see the bottom of this article for registration instructions) Workshop Description Bring your laptops and join the authors of Two Scoops of Django for a hands-on Django workshop. We'll build a real, working site from the ground up, using the upcoming Django 1.6 and covering Python 2.7/3.3. We'll cover as much as we can get through, including but not limited to: Python and Django setup Project creation App creation models The Django admin UI Views Migrations with South User image uploads New user registration Basic forms Basic internationalization Prerequisites Attendees will need their own laptops. We'll cover installation, but if you can come with the following already installed you'll enjoy workshop more: Really encouraged: Python 3.3 or Python 2.7 Really encouraged: virtualenv Really encouraged: pip If you are familiar with virtualenv, please have an instance created with the following already installed: git+git://github.com/django/django.git@1.6b1 Pillow==2.0.0 South==0.8.1 django-bootstrap-registration==0.1.2 django-braces==1.0.0 django-crispy-forms==1.3.2 django-reg==1.0.1 Registration Details Date: July 3, 2013 Time: 14:30 - 18:30 Track: Pizza Napoli Instructors: Daniel Greenfeld and … -
Floyd-Warshall ‘s All Pair Shortest Path Algorithm
In the previous two posts, I explained two different algorithms to find the shortest path in the graph. In this post I will define another very simple yet important problem in Graph Theory. Its called the “All Pair Shortest Path” problem. Given a graph G, as a set of vertices V and directed weighted edges E, the aim of the problem is to find the cost of shortest path between every pair of vertices. Cost of a shortest path is defined as the sum of the edge weights in the shortest paths. At first sight this problem might look really hard to approach. But the following theorem will make this one of the easiest to approach and especially code it. Theroem: If A represents the adjacency matrix of the graph, then for an integer k<=|V| , the (i,j) entry in the matrix A^k , gives the shortest path of length atmost k, between i and j in the original graph. This above theorem can be easily proved using induction on k. I will leave that as a simple exercise. From the theorem, all that is left to find is the matrix A^n. A trivial way to compute this would be … -
Palestra GeoDjango no FISL
Geodjango Vou apresentar uma palestra sobre GeoDjango no primeiro dia do FISL. Resumo da palestra: Utilizando apenas soluções livres, é possível criar um sistema completo de informações geográficas (SIG/GIS), incluindo mapas (OpenStreetMap/Mapbox), banco de dados geográfico (PostGIS) e um framework web completo como o Django. Essa palestra detalha como integrar essas soluções para processamento de informações geográficas para exibir áreas e plotagens no mapa e territórios. Conteúdo: O Django possui uma biblioteca excelente para trabalhar com informações geográficas, trata-se do GeoDjango, que está bem estável, maduro e já vem integrado ao core do Django. Em conjunto com ele, o PostgreSQL possui uma extensão chamada PostGIS, capaz de criar um banco de dados geográfico e realizar cálculos diretamente via SQL. Para enriquecer mais o cenário de soluções livres, o OpenStreetMap é capaz de exibir belos mapas em alternativa ao Google Maps. É possível modificar os ’tiles’ usando o Mapbox, para mapas estilizados e camadas customizadas. Essa palestra tem como objetivo explicar alguns conceitos geográficos, detalhar o uso do PostGIS, como criar um projeto geográfico no Django e como integrar a solução ao OpenStreetMap. O resultado final será uma aplicação funcional, capaz de exibir polígonos, áreas, território e pontos no mapa, além … -
Limiting choices in a ModelAdmin list_filter
So, you need to limit choices, because the list of related choices is too long? Then do NOT use limit_choices_to parameter on the ForeignKey! Why? Because you risk having options missing in your forms, deleting relations unknowingly. For instance, consider that you have the following case, expressed in pseudo code: ModelClass.related_instance = models.ForeignKey(MyRelatedModel, limit_choices_to = {'active': True}, blank=True, null=True) object = &lt;ModelClass instance&gt; object.related_instance = &lt;MyRelatedModel instance&gt; object.related_instance.active = False If you edit object, you will see an admin form where <MyRelatedModel instance> is not selectable! Hence, you will risk editing and loosing data without knowing it. So your best bet is to stop using limit_choices_to and instead define a filter. Luckily, it’s quite easy. It’s not beautiful, though, since admin.filters.RelatedFieldListFilter does not offer a method to overwrite. Here is an example: class RelatedFilter(admin.filters.RelatedFieldListFilter): def __init__(self, *args, **kwargs): super(RelatedFilter, self).__init__(*args, **kwargs) self.lookup_choices = [ (x.id, x) for x in models.RelatedModel.objects.filter(status='active') ] class MyModelAdmin(admin.ModelAdmin): list_filter = (('related_field', RelatedFilter), 'other_related_field') -
Prim’s Algorithm
In the last post, I defined a spanning tree and gave an algorithm called the ‘Kruskal’s Algorithm’. In this post, I am going to describe another algorithm that also helps in computing the minimum spanning tree of a graph. This algorithm is called the ‘Prim’s Algorithm’ . The basic intuition behind the algorithm goes as follows: Firstly, every vertex should be reachable from every other vertex for it to be a tree. So we will try to build the tree by adding one vertex after another into the connected component. Since we want a “minimum” such tree, we will use the edge between the new vertex and the old component, that is of the minimum weight. This intuition is formalized below as an algorithm: Set ConnectedSet = Pick a random vertex v of vertex set Set ToBeAddedSet = set of vertices except vertex v Set ListOfBridgeEdges = Set of Edges while ToBeAddedSet not empty: - Select the minimum edge e from the ListOfBridgeEdges such that it has exactly one end in ConnectedSet - Add the other end of e to the ConnectedSet and remove it from the ToBeAddedSet Let us now analyze the complexity of the above algorithm: 1) The … -
Debugging Python code in a browser with wdb debugger
wdb is a nice Python debugger running as a server and capable of launching debug session in your browser. It can handle simple scripts, web apps (Tornado, Flask or Django based and alike) as well as other multithread and multiprocess programs. It's easy to use and not much configuration is required. -
"People don’t buy what you do they buy why you do it" -...
"People don’t buy what you do they buy why you do it" - Simon Sinek -
Mercurial Mirror For Django 1.6 branch
Django has another branch, and we have another mirror. Today Django 1.6 beta 1 was released, and that seemed a good day to start the 1.6 mirror. So here it is, next to the other mirrors on my bitbucket account: https://bitbucket.org/orzel/django-1.6-production/ -
You Should Be Using Nginx + UWSGI
After lots of experimentation (between disqus.com and getsentry.com), I think we can safely say we’ve decided on a pretty solid best practice for squeezing the most peformance out of your web boxes. I am going to convince you that nginx + uwsgi is the best, and only way you should be serving … -
You Should Be Using Nginx + UWSGI
After lots of experimentation (between disqus.com and getsentry.com), I content with saying that uwsgi should be the standard in the Python world. Combine it with nginx and you're able to get a lot of (relative) performance out of your threaded (or not) Python web application. Update: Ignori... -
You Should Be Using Nginx + UWSGI
After lots of experimentation (between disqus.com and getsentry.com), I’m content with saying that uwsgi should be the standard in the Python world. Combine it with nginx and you’re able to get a lot of (relative) performance out of your threaded (or not) Python web application. Update: Ignoring... -
MEDIA_ROOT and Django Tests
If you’ve ever written a test for a view or model with associated uploaded files you might have noticed a small problem with those files hanging around after the tests are complete. Since version 1.3, Django won’t delete the files associated with your model instances when they are deleted. `Some work-arounds for this issue `_ involve writing a custom delete for your model or using a post_delete signal handler. But even with those in place the files would not be deleted during tests because the model instances are not explicitly deleted at the end of the test case. Instead, Django simply rolls back the transaction and the delete method is never called nor are the signals fired. This can be quite an annoyance when running the tests repeatedly and watching your ``MEDIA_ROOT`` (or worse your S3 bucket) fill up with garbage data. More than annoyance, this introduces something you always want to avoid in unittests: global state. One way to avoid this problem is to take a similar approach to how Django manages the database. That is, each time you run the tests, create a new ``MEDIA_ROOT`` and when the tests finish tear it down. This can all be done … -
Clean Install of Postgres and Django on Ubuntu
In the debate between databases, the Django community has time and time again shown a preference for Postgres. I was lucky enough to have started with Postgres from the beginning (with the brief exception of sqlite for the tutorial). However sometimes I still run into problems when I have to set up a new server and forget how to configure Postgres, mainly with respect to user authentication. So I've come up with some concise instructions for getting a clean Ubuntu install running with Postgres 9.1, Django 1.5, and psycopg2. Packages Postgres The database! Pretty obvious that this is needed! postgresql-server-dev-9.1 A debian package needed to compile the python database adapter (psycopg2) python-dev Python header files which are also needed to compile psycopg2 python-pip A Python package installer, works well with virtual environments and version pinning psycopg2 A Postgres database adapter for Python Django Our favorite Python web framework! Installation Command sudo apt-get install postgresql postgresql-server-dev-9.1 python-dev python-pip sudo pip install Django psycopg2 Note that the postgresql-server-dev package has a version on it, this should match your postgresql version Configuring Postgres Now create a user to access the database with and create an empty database for Django to use later. First, … -
Starting Jinja2
Jinja2 is a great templating language based on Django's templating engine. It has some great features, and is more performant. This video shows you how to get started with it in your projects today.Watch Now... -
Announcing django-pastedeploy-settings: A Maintainable Way to Define Django Settings
We're happy to announce the first beta release of django-pastedeploy-settings, a more maintainable way to define and override Django settings. Its features include:Simple, Python-free configuration files. The format used is INI because configuration files should be declarative, not scripts.Settings can be inherited. For example, you can define your base settings in your project’s repository, while overriding some from a separate file outside your repository.Setting values are defined with JSON.Variable substitution, allowing you to define a value once and reuse it in different settings.Integration with Buildout, so that you can expose your Django settings to Buildout parts.Integration with Nose, so that you can easily set the settings to be used by your test suites.Under the hood, this library uses Paste Deployment, a widely-used system which has the sole purpose of enabling developers and sysadmins to configure WSGI applications (like Django) and WSGI servers.In spite of this being a beta release, and the first release of this library, its code is based on twod.wsgi v1, a library which we've been maintaining and using in production for over 3 years.ExampleYou can keep the following file in your project’s repository:# base.ini[DEFAULT]django_settings_module = your_django_project.settings[app:main]use = egg:django-pastedeploy-settingsDATABASES = { "default": { "ENGINE": "django.db.backends.sqlite3", "NAME": "%(sqlite_db_path)s", } }And … -
Announcing django-pastedeploy-settings: A Maintainable Way to Define Django Settings
We're happy to announce the first beta release of django-pastedeploy-settings, a more maintainable way to define and override Django settings. Its features include: Simple, Python-free configuration files. The format used is INI because configuration files should be declarative, not scripts. Settings can be inherited. For example, you can define your base settings in your project’s repository, while overriding some from a separate file outside your repository. Setting values are defined with JSON. Variable substitution, allowing you to define a value once and reuse it in different settings. Integration with Buildout, so that you can expose your Django settings to Buildout parts. Integration with Nose, so that you can easily set the settings to be used by your test suites.Under the hood, this library uses Paste Deployment, a widely-used system which has the sole purpose of enabling developers and sysadmins to configure WSGI applications (like Django) and WSGI servers. In spite of this being the first public release of this library, its code is based on twod.wsgi v1, a library which we've been maintaining and using in production for over 3 years. Example You can keep the following file in your project’s repository: # base.ini [DEFAULT] django_settings_module = your_django_project.settings [app:main] use = … -
Getting Paid in Django with Pin Payments
For a long time, it's been tough to accept payments online in Australia. Of course we had PayPal, but we never got any great tools like Stripe, like our peers in the US. Recently, Pin Payments started as an "Australian version of Stripe". They're still getting started, but they're open for business - so I wrote a small Django library called django-pinpayments to make it easier to use Pin within your Django app. -
Getting Paid in Django with Pin Payments
For a long time, it's been tough to accept payments online in Australia. Of course we had PayPal, but we never got any great tools like Stripe, like our peers in the US. Recently, Pin Payments started as an "Australian version of Stripe". They're still getting started, but they're open for business - so I wrote a small Django library called django-pinpayments to make it easier to use Pin within your Django app. -
Getting Paid in Django with Pin Payments
Payments in Australia are controlled by the so-called "big four" banks, and it's been difficult for a long time for startups to get merchant facilities to process credit cards online. Accounts cost hundreds of dollars per month, with high transaction costs and minimum transaction volumes thrown in. We watched with teary eyes as companies such as Stripe launched and made it easy for developers to process credit cards, and kept struggling with the PayPal "API" with hope that one day we'd see Stripe in Australia. I was excited, then, to see that Pin Payments have just publicly launched in Australia. They're currently offering a $9/month account fee, which isn't free but it's certainly ideal for small companies. After June 2013 this will jump to $50/month, so it seems to make sense to sign up now if you've got any medium-term plans. Like Stripe, Pin offer a JavaScript Library for processing payments on your page without ever handling credit card details. This makes it much quicker and easier to implement. Because I process payments in multiple places on WhisperGifts, I needed a reusable way to render the payment form and process the payment in a worker queue. The resulting code has … -
Getting Paid in Django with Pin Payments
Payments in Australia are controlled by the so-called "big four" banks, and it's been difficult for a long time for startups to get merchant facilities to process credit cards online. Accounts cost hundreds of dollars per month, with high transaction costs and minimum transaction volumes thrown in. We watched with …