Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
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 … -
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. -
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
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 … -
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 … -
Celery with RabbitMQ 3.1.0 on Webfaction
A while ago Mark Liu wrote about setting up django-celery on a Webfaction host. I took the tutorial and matched it to the current version of RabbitMQ that is 3.1.0. Please read this article entirely before installing anything! Basically follow Mark's tutorial and install Erlang as well as RabbitMQ but use the current RabbitMQ binary *.tar.gz from the download page. Attention: Depending on what applications you are already running on Webfaction, the 256MB RAM plan may be insufficient to run Celery and RabbitMQ and Erlang. You can give it a try, for me it did not work, I added some more memory to my plan. Monitor your memory usage while installing. I'm using the following script to do so (replace the [username] with your username): # memory_top.sh # lists memory usage for given user every 5 seconds while true do ps -U [username] --no-headers -o rss | (tr '\n' +; echo 0) | bc sleep 5 done Do not configure rabbitmq-server and the rabbitmq-env file as written. Instead do the following (I extracted RabbitMQ to \$HOME/rabbitmq/rabbitmq_server-3.1.0 and will use this paths): Edit \$HOME/rabbitmq/rabbitmq_server-3.1.0/sbin/rabbitmq-defaults: ... # comment these lines: #CONFIG_FILE=${SYS_PREFIX}/etc/rabbitmq/rabbitmq #LOG_BASE=${SYS_PREFIX}/var/log/rabbitmq #MNESIA_BASE=${SYS_PREFIX}/var/lib/rabbitmq/mnesia # add these lines: CONFIG_FILE=/home/[username]/rabbitmq/rabbitmq_server-3.1.0/sbin/ LOG_BASE=/home/[username]/logs/user/rabbitmq # create this … -
Celery with RabbitMQ 3.1.0 on Webfaction
A while ago Mark Liu wrote about setting up django-celery on a Webfaction host. I took the tutorial and matched it to the current version of RabbitMQ that is 3.1.0. Please read this article entirely before installing anything! Basically follow Mark's tutorial and install Erlang as well as RabbitMQ but use the current RabbitMQ binary *.tar.gz from the download page. Attention: Depending on what applications you are already running on Webfaction, the 256MB RAM plan may be insufficient to run Celery and RabbitMQ and Erlang. You can give it a try, for me it did not work, I added some more memory to my plan. Monitor your memory usage while installing. I'm using the following script to do so (replace the [username] with your username): # memory_top.sh # lists memory usage for given user every 5 seconds while true do ps -U [username] --no-headers -o rss | (tr '\n' +; echo 0) | bc sleep 5 done Do not configure rabbitmq-server and the rabbitmq-env file as written. Instead do the following (I extracted RabbitMQ to \$HOME/rabbitmq/rabbitmq_server-3.1.0 and will use this paths): Edit \$HOME/rabbitmq/rabbitmq_server-3.1.0/sbin/rabbitmq-defaults: ... # comment these lines: #CONFIG_FILE=${SYS_PREFIX}/etc/rabbitmq/rabbitmq #LOG_BASE=${SYS_PREFIX}/var/log/rabbitmq #MNESIA_BASE=${SYS_PREFIX}/var/lib/rabbitmq/mnesia # add these lines: CONFIG_FILE=/home/[username]/rabbitmq/rabbitmq_server-3.1.0/sbin/ LOG_BASE=/home/[username]/logs/user/rabbitmq # create this … -
Celery with RabbitMQ 3.1.0 on Webfaction
A while ago Mark Liu wrote about setting up django-celery on a Webfaction host. I took the tutorial and matched it to the current version of RabbitMQ that is 3.1.0. Please read this article entirely before installing anything! Basically follow Mark's tutorial and install Erlang as well as RabbitMQ but use the current RabbitMQ binary *.tar.gz from the download page. Attention: Depending on what applications you are already running on Webfaction, the 256MB RAM plan may be insufficient to run Celery and RabbitMQ and Erlang. You can give it a try, for me it did not work, I added some more memory to my plan. Monitor your memory usage while installing. I'm using the following script to do so (replace the [username] with your username): # memory_top.sh # lists memory usage for given user every 5 seconds while true do ps -U [username] --no-headers -o rss | (tr '\n' +; echo 0) | bc sleep 5 done Do not configure rabbitmq-server and the rabbitmq-env file as written. Instead do the following (I extracted RabbitMQ to \$HOME/rabbitmq/rabbitmq_server-3.1.0 and will use this paths): Edit \$HOME/rabbitmq/rabbitmq_server-3.1.0/sbin/rabbitmq-defaults: ... # comment these lines: #CONFIG_FILE=${SYS_PREFIX}/etc/rabbitmq/rabbitmq #LOG_BASE=${SYS_PREFIX}/var/log/rabbitmq #MNESIA_BASE=${SYS_PREFIX}/var/lib/rabbitmq/mnesia # add these lines: CONFIG_FILE=/home/[username]/rabbitmq/rabbitmq_server-3.1.0/sbin/ LOG_BASE=/home/[username]/logs/user/rabbitmq # create this … -
Water software and python
Weird link I got from a colleague this evening: some Dutch ICT awards were awarded this week. The link is in Dutch, but trust me if I say that the two (to me) relevant awards were awarded to Python (as a fantastic computer language) and to hydrologic (a Dutch water+ict company, for their water software). For me, the weirdness is three-step process: Ok, an award for Python is nice! Almost all our (Nelen & Schuurmans) software is written in Python. And virtually all of it is open source. Just look at github: https://github.com/nens/ and especially https://github.com/lizardsystem/ . Lots of Python and Django. The water software award goes to a closed source Microsoft shop. We (Nelen & Schuurmans) are the perfect combination of water software and open source Python. We're a water consultancy company. And a successful one, too. Lots of great projects. Most of them centered around something called Lizard (http://lizard.net for the mostly-Dutch business language stuff, http://lizard.org for the English IT stuff). Lots of partners working on and with it. It is a real platform with every partner putting in ideas and expertise. Most of the actual programming happens at our place, to be fair, at the moment. But... … -
Django Fieldsets
HTML forms contain a construct called a ``fieldset``. These are generally used to segment a form: splitting a form into groups of fields that are logically grouped. Each fieldset may also have a legend. Django's forms have no concept of a fieldset natively, but with a bit of patching, we can make every django form capable of rendering itself using fieldsets, yet still be backwards compatible with non-fieldset-aware templates. Ideally, we would like to be able to render a form in a way similar to: {% highlight html %} {% raw %} {% for fieldset in form.fieldsets %} {{ fieldset.title }} {% for field in fieldset %} {{ field.label_tag }} {{ field }} {{ field.help_text }} {{ field.errors }} {% endfor %} {% endfor %} {% endraw %} {% endhighlight %} And, it would make sense to be able to declare a form's fieldsets in a manner such as: {% highlight python %} class MyForm(forms.Form): field1 = forms.BooleanField(required=False) field2 = forms.CharField() class Meta: fieldsets = ( ('Fieldset title', { 'fields': ('field1', 'field2') }), ) {% endhighlight %} This is similar to how fieldsets are declared in the django admin. We can't just simply create a subclass of ``forms.Form``, and do … -
Introducing Salmon
Click here to see this post in it's natural habitat and to watch and leave comments. Over the years, I’ve used a lot of server monitoring systems. Big enterprisey ones like Zabbix, Zenoss, and Hyperic, smaller ones like munin and monit, stuff in the middle like Graphite, and hosted solutions like New Relic. Throughout the search, I never found one that hit the sweet spot for me. They were either too complicated and required too much setup upfront or too limited in what they had to offer. Like any good developer frustrated with the tools available, I set off on building my own. The result (still in its infancy) is Salmon. Its aim is to be a simple, yet powerful (enough) server monitoring and alerting system. Salmon itself is a simple project, but takes advantage of some great open source libraries for much of its advanced functionality. Salt Salt is the new kid on the block for server configuration management (think Chef and Puppet). Billing it as a configuration management tool is underselling it though. It’s really a remote execution framework. I hadn’t wrapped my head around this until a chat with a few of the guys from SaltStack at … -
Introducing Salmon
Over the years, I’ve used a lot of server monitoring systems. Big enterprisey ones like Zabbix, Zenoss, and Hyperic, smaller ones like munin and monit, stuff in the middle like Graphite, and hosted solutions like New Relic. Throughout the search, I never found one that hit the sweet spot for me. They were either too complicated and required too much setup upfront or too limited in what they had to offer. Like any good developer frustrated with the tools available, I set off on building my own. The result (still in its infancy) is Salmon. Its aim is to be a simple, yet powerful (enough) server monitoring and alerting system. Salmon itself is a simple project, but takes advantage of some great open source libraries for much of its advanced functionality. Salt Salt is the new kid on the block for server configuration management (think Chef and Puppet). Billing it as a configuration management tool is underselling it though. It’s really a remote execution framework. I hadn’t wrapped my head around this until a chat with a few of the guys from SaltStack at PyCon this year. Salt is a perfect tool for stats collection on remote servers. It offers … -
Simple Job Queues with django_rq
Simple Job Queues with django_rq The de facto solution for job queues with background workers is Celery and RabbitMQ, but it is not the right fit for every project. RQ is an alternative to Celery, and while not as featureful, does provide a lightweight solution that makes it easy to ...
