Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
A Quick Introduction to Backbone
Who Uses Backbone? airbnb, newsblur, disqus, hulu, basecamp, stripe, irccloud, trello, … Why? http://backbonejs.org/#FAQ-why-backbone It is not a framework Backbone is an MVP (Model View Presenter) javascript library that, unlike Django, is extremely light in its use of conventions. Frameworks are commonly seen as fully-working applications that run your code, as opposed to libraries, where you import their code and run it yourself. Backbone falls solidly into the latter category and it’s only through the use of the Router class that it starts to take some control back. Also included are View, Model and Collection (of Models), and Events, all of which can be used as completely standalone components and often are used this way alongside other frameworks. This means that if you use backbone, you will have much more flexibility for creating something unusual and being master of your project’s destiny, but on the other hand you’ll be faced with writing a lot of the glue code yourself, as well as forming many of the conventions. Dependencies Backbone is built upon jQuery and underscore. While these two libraries have some overlap, they mostly perform separate functions; jQuery is a DOM manipulation tool that handles the abstractions of various browser … -
Initial Data in Django
I’ve struggled to find an ideal way to load initial data for Django projects. By “initial data,” I’m referring to the kind of data that you need on a new system for it to be functional, but could change later. These are largely lists of possible choices, such as time zones, countries, or crayon colors. -
Speeding up a Django web site without touching the code
I’ve recently been tweaking my server setup for a Django 1.3 web site with the goal of making it a bit faster. Of course, there is a lot of speed to gain by improving e.g. the number of database queries needed to render a web page, but the server setup also has an effect on the web site performance. This is a log of my findings. All measurements have been done using the ab tool from Apache using the arguments -n 200 -c 20, which means that each case have been tested with 20 concurrent requests up to 200 requests in total. The tests was run from another machine than the web server, with around 45ms RTT to the server. This is not a scientific measurement, but good enough to let me quickly test my assumptions on what increases or decreases performance. The Django app isn’t particularly optimized in itself, so I don’t care much about the low number of requests per second (req/s) that it manages to process. The main point here is the relative improvement with each change to the server setup. The baseline setup is a Linode 1024 VPS (Referral link: I get USD 20 off my … -
Comics v2.2.0 released with Django 1.5 support
Version 2.2.0 of my comics aggregator is now released. It features a general upgrade of dependencies, including the move from Django 1.4 to Django 1.5, and a lot of updates to comic crawlers. The Django upgrade was completed months ago and it’s been running my Comics instance since, so it’s about time to get it released before Django 1.6 arrives in a month or two. Regarding the crawler updates, it’s a bit sad to see that many of the crawlers have been broken for months without me or anybody else noticing, but it’s hard to catch some content lacking in the middle of a firehose of similar content. I guess I’ll have to make it a monthly task to look through the crawler status page of my Comics instance and do patch releases with updated crawlers. Check out the project docs for more information about Comics and this release in particular. -
Comics v2.3.0 released with better mobile support
Version 2.3.0 of my comics aggregator is now released. As always, dependencies have been updated, including the routine Django upgrade from Django 1.5 to 1.6, just in time for the upcoming 1.7 release. The largest change this time around is the move from Bootstrap 2 to 3, which includes a refreshed, flatter design and lots of tweaking to make Comics both look good and work nicely on mobile devices, something it didn’t use to do. The dependency overview at requires.io has been a great motivation for doing some maintenance work on Comics. The only dependency left outdated is django-registration, as 1.0 moves to class-based views, which requires some larger changes to my customizations. Thus, the upgrade of django-registration has been deferred together with the related upgrade of my vendorized copy of django-invitation. Most, if not all, of the other dependencies seems to support Python 3 now, though some lack the right Trove classifiers in their PyPI registration, so they are not correctly labeled by requires.io. I found an open pull request for cssmin and a recent commit for django-compressor adding the missing Trove classifiers. I’ve also done my part to improve the Python 3 metadata by sending a pull request … -
Comics v2.2.0 released with Django 1.5 support
Version 2.2.0 of my comics aggregator is now released. It features a general upgrade of dependencies, including the move from Django 1.4 to Django 1.5, and a lot of updates to comic crawlers. The Django upgrade was completed months ago and it’s been running my Comics instance since, so it’s about time to get it released before Django 1.6 arrives in a month or two. Regarding the crawler updates, it’s a bit sad to see that many of the crawlers have been broken for months without me or anybody else noticing, but it’s hard to catch some content lacking in the middle of a firehose of similar content. I guess I’ll have to make it a monthly task to look through the crawler status page of my Comics instance and do patch releases with updated crawlers. Check out the project docs for more information about Comics and this release in particular. -
Comics v2.3.0 released with better mobile support
Version 2.3.0 of my comics aggregator is now released. As always, dependencies have been updated, including the routine Django upgrade from Django 1.5 to 1.6, just in time for the upcoming 1.7 release. The largest change this time around is the move from Bootstrap 2 to 3, which includes a refreshed, flatter design and lots of tweaking to make Comics both look good and work nicely on mobile devices, something it didn’t use to do. The dependency overview at requires.io has been a great motivation for doing some maintenance work on Comics. The only dependency left outdated is django-registration, as 1.0 moves to class-based views, which requires some larger changes to my customizations. Thus, the upgrade of django-registration has been deferred together with the related upgrade of my vendorized copy of django-invitation. Most, if not all, of the other dependencies seems to support Python 3 now, though some lack the right Trove classifiers in their PyPI registration, so they are not correctly labeled by requires.io. I found an open pull request for cssmin and a recent commit for django-compressor adding the missing Trove classifiers. I’ve also done my part to improve the Python 3 metadata by sending a pull request … -
Django under the hood: documentation workshop - Mikey Ariel
(One of my summaries of a talk at the 2015 django under the hood conference). Documentation used to be an afterthought of software delivery. Now it is a key component of the success of a software project. Content strategy Originally it is a marketing term. Which is fine, as documentation is an important part of your project's marketing! The core is asking the right questions (even is the answer is simple). Who are my readers? Sounds like a simple question. But... are your readers advanced users? Or beginners? Do you need "persona-based" documentation, so documentation for specific groups ("admins", "developers", etc)? What do my readers want to know? Often your readers need context before they can understand reference documentation. Do you need an end-to-end tutorial? Or just explanations? Does the textual content need to be enhanced with video or diagrams, for instance? When do my readers need the content? Installation documentation right at the beginning to get started? A reference guide when you're already working with it? Tutorials for learning it? "When" also relates to "when do I need/want to update the documentation?" Where do my readers consume the content? Do you need a "man" page? Embedded help in your … -
Django under the hood: expressions - Josh Smeaton
(One of my summaries of a talk at the 2015 django under the hood conference). Josh Smeaton is a django core developer after his work on expressions. What already existed for a long time in django are F expressions. There are used to send a computation to the database. A self-contained parcel of SQL. Like "take the price field and add the shipping costs to it". Later aggregations were added. It is a bit the same, as it is "just a bit of sql" that gets send to the database. Expressions in django are now much more refined. Multiple database backend support. Deep integration in the ORM to make writing expressions yourself in django easier. It almost makes .extra() and .raw() obsolete. .raw() is for writing an entire query in SQL. For those corner cases where you need to do weird tricks that the ORM doesn't support. .extra() is for appending bits of SQL to the rest of your django query. It is evil and should go away. Both are escape hatches that are hardly ever needed. One problem with them is that they are database backend specific. Some examples of where you can use expressions: .create(... username=Lower(username)) .annotate(tital=F('price') + … -
Django under the hood: documentation systems - Eric Holscher
(One of my summaries of a talk at the 2015 django under the hood conference). Note by Reinout: I hope all the examples are rendered OK as I'm writing this blog with... sphinx and restructured text :-) Eric Holscher started https://readthedocs.org/ a few years ago during a "django dash" weekend. That site is widely used and even gave rise to "write the docs" conferences and a community around technical writing. Readthedocs and also the django documentation uses sphinx. A documentation system? It is not just a single documentation page on one item. It is documentation for a whole project. Sphinx extends RST (restructured text) with additions for documenting software. It also adds semantic meaning. Lot of documentation is written in markdown nowadays. A link to pep8 in markdown would be a simple link to pep8 on the internet. In sphinx/rst it could be: Check out :pep:`8` He becomes sad if he sees documentation written in markdown. "Read the docs" is build on "sphinx" is build on "docutils" is build on "restructured text". Here are some of the internal concepts of RST: A reader reads input. A parser takes the input and actually turns it into a "Doctree". RST is the … -
Django under the hood: Django security - Florian Apolloner
(One of my summaries of a talk at the 2015 django under the hood conference). Florian Apolloner talks about django security. Django security, so it won't be about attacks against the SSL protocol as those are outside of django. (But do look at https://www.ssllabs.com/ssltest/). In case you think you've found a security bug in django: look at https://djangoproject.com/security and only contact security@djangoproject.com. Don't report such a bug publicly, as that makes it much harder to make and distribute a proper fix. Regarding security: look at the owasp top 10 list of the most common found vulnerabilities in websites. SQL/SMTP/OS injections Basic rule: don't ever trust user input. Everything the user can input into your web interface is to be treated as dangerous. select * from auth_user where username=%s is easy to exploit if you inject a username string inputted by the user directly. If you use django, you don't run much risk as django does the good thing internally regarding escaping. Defense in layers is best. If you limit the parameter to an integer in your url patterns and select users by id instead of a string, you already prevent many problems. The same goes for OS interaction. Use Django … -
Django under the hood: files in Django - James Aylett
(One of my summaries of a talk at the 2015 django under the hood conference). James Aylett talks about files in django. You've got Files in python. Django build its own abstraction on top of it. File, ImageFile. Separate ones for use in tests. UploadedFile ("behaves something like a file object", it mentions in the documentation...). There are temporary file and memory variants. Custom upload handlers. forms.FileField. It might not be perfect, but it works. Files in the ORM: what gets stored in the database is a path to a file, the file is stored on the filesystem. If you store an ImageField, you can query the width and the height of the image. You're better off storing the width and height in the database, though, as otherwise the image has to be read from disk on every request. "Files are stored on the filesystem"? They are stored in settings.MEDIA_ROOT by default. Storing is done by a storage backend. You can replace it to get different behaviour. You can use a different storage backend by configuring it in the settings file. Or you can override it on a field-by-field basis. Different storage backends? You can store data in amazon S3, … -
Django under the hood: keynote - Russell Keith-Magee
(One of my summaries of a talk at the 2015 django under the hood conference). Russell Keith-Magee started by showing a lot of commit messages to show Django's history. There are weird and humoristic ones in them. Many having to do with Malcolm Tredennick. Like Malcolm' insistence on auto-escaping in templates to make it safe. And removal of white space at the end of lines. Stories about bugs that only surfaced on the first day of the month if UTC had not yet rolled over. And only if the previous month had 31 days... Oh, and a set of commits done by a person that was convicted to community service! There was a fine collection of weird problems. "Fixed #16809 -- Forced MySQL to behave like a database". Now we come to the present. There are some technical threats like real-time and async code. Technical challenges can be met. There is a bigger risk, though: the social aspect. The low hanging fruit in django has all been solved. What is left to do is really hard big problems. Often, only core committers do that kind of work. But those are the ones that already do a lot of work. We … -
Django under the hood: twisted and django - Amber Brown
(One of my summaries of a talk at the 2015 django under the hood conference). Amber Brown is a Twisted core developer. This talk's summary will be: >>> Django == good True >>> Twisted == good True And everything will be better if we work together. Synchronous and asynchronous. Synchronous code is code that returns inline. Asynchronous code is code that returns something possibly at a different time. The extra complication is that IO is often blocking. Twisted is asynchronous. Regular python code like socket.write() is blocking. Twisted has its own socket that calls python's behind the scenes. In user code, you should only use twisted's version: then your code is async and it isn't blocking on IO. At the core there's always something that tries to read/write data. But we normally work at a higher level. So there are protocols that we actually use that are build upon the lower-level read/write connection. A lot of the async code works with callbacks. You call a function and pass in a second function that gets called with the result when the first function is ready. Twisted uses it often like this: >>> deferred = Deferred() >>> deferred.addCallback(lambda t: t+1) <Deferred at … -
Django under the hood: Django CMS and the ORM - Iacopo Spalletti
(One of my summaries of a talk at the 2015 django under the hood conference). Iacopo Spalletti is one of the core developers of django CMS. Django CMS was invited to give a talk because it is a big Django application. So it can tell us what's the good, the bad and the ugly about Django from their perspective. Django CMS is a good django citizen. It integrates with other django apps. It provides features to other applications. It glues applications together. It handles unstructured content using "pages". Django is upgradable. It takes some work, but it is doable and not very painful. Similarly django CMS. The basis of django CMS is the Page and a tree hierarchy in which those pages are placed. And of course a template to render it. Django CMS is multilingual at the core, so everything is translatable. A title is a separate Title object. Similarly the actual content. And so on. Django CMS uses a lot of django features. Of the 14k lines, 3k are in the admin and 2k in the models, for instance. And 1k lines in the template tags: that is a lot. It is a central part of django CMS … -
Django under the hood: HTTP in Django - Jakob Kaplan-Moss
(One of my summaries of a talk at the 2015 django under the hood conference). Jakob Kaplan-Moss talks about one of the oldest parts of Django: http. So: actually talking to the internet :-) Old old old code, so it needs explaining. HTTP in Django means Django's request/response cycle. Let's start with a very simple view: def my_view(request): return HttpResonse("it works!") What happens behind the scenes? Actually a lot. Django is a framework. The difference between a framework and a library is that a framework calls your code. Instead of your program calling a library. So Django is in control. Django works with WSGI. So you have some WSGI server that wants to run an application. The application is in your my_app.wsgi.py file. Which calls get_wsgi_application() in django.core.wsgi. Which does some django.setup() and an __init__() of a wsgi_object in the WSGIHandler/BaseHandler. In the end a wsgi_object goes back towards the WSGI server. It is important that django.setup() is called very early. This sets up the ORM, for instance. So most of the setup has happened before your own code is called. Jakob wants to focus a bit of time on an extension point that's often missed: you can write your … -
Django under the hood: how the Django admin works - Ola Sitarska
(One of my summaries of a talk at the 2015 django under the hood conference). Ola Sitarska gave a higher-level talk about the django admin at the recent Cardiff djangocon. She loves the django admin. The django admin hasn't seen any big updates for the last 8 years. It just works and it works well and it is stable. Until django 1.9: there's a new visual skin for the admin. Check it out! (She showed a screenshot later on in the presentation: yes, it looks great!) There are three main parts to the django admin: AdminSite, ModelAdmin, ChangeList. The AdminSite encapsulates an instance of the django admin application. You don't need to do admin.autodiscover() anymore as it is called automatically by Django now that django has a signal for when an app is loaded. For the admin app, it fires off autodiscover(). Autodiscover finds all your models and extracts information about them. Including the admin.py customization/configuration. This ends up as a list of admin URLs. Note: you can have multiple admins with different configurations in case you have a need for two completely differently configured admin sites. Some of the things you can customize on an adminsite are the site_title … -
Intensive Django Training with the US Air Force
Last week Audrey Roy Greenfeld and I had the privilege of teaching the US Air Force's 91st Cyberspace Operations Squadron the finer details of how to build, test, and deploy Django web applications. It was a challenging, exciting experience for us as instructors. We've taught numerous Python and Django trainings over the years under Cartwheel Web , but this was the first time we taught as Two Scoops Academy using our new system of instruction. The environment that the 91st Cyberspace Operations Squadron works in is heavily isolated from the internet. What this means is that until technology or information is approved, it is unavailable to the software developers. While they can access Google, Stack Overflow, and Read the Docs, reading the source on GitHub is something they do at home, not on the job. This means they really need to understand their material. Our experience with their team (already competent in other programming tools) was that they were bright, focused, and willing to learn. The class included material on: Python, PEP8, PEP20, object oriented programming Django and related best practices Class-based views, ModelForms, and Forms Using third-party Python/Django components Bootstrapping projects with Cookiecutter and Cookiecutter-Django PostgreSQL, pgAdmin III, and … -
Intensive Django Training with the US Air Force
Last week Audrey Roy Greenfeld and I had the privilege of teaching the US Air Force's 91st Cyberspace Operations Squadron the finer details of how to build, test, and deploy Django web applications. It was a challenging, exciting experience for us as instructors. We've taught numerous Python and Django trainings over the years under Cartwheel Web , but this was the first time we taught as Two Scoops Academy using our new system of instruction. The environment that the 91st Network Warfare Squadron works in is heavily isolated from the internet. What this means is that until technology or information is approved, it is unavailable to the software developers. While they can access Google, Stack Overflow, and Read the Docs, reading the source on GitHub is something they do at home, not on the job. This means they really need to understand their material. Our experience with their team (already competent in other programming tools) was that they were bright, focused, and willing to learn. The class included material on: Python, PEP8, PEP20, object oriented programming Django and related best practices Class-based views, ModelForms, and Forms Using third-party Python/Django components Bootstrapping projects with Cookiecutter and Cookiecutter-Django PostgreSQL, pgAdmin III, and … -
Intensive Django Training with the US Air Force
Last week Audrey Roy Greenfeld and I had the privilege of teaching the US Air Force's 91st Cyberspace Operations Squadron the finer details of how to build, test, and deploy Django web applications. It was a challenging, exciting experience for us as instructors. We've taught numerous Python and Django trainings over the years under Cartwheel Web , but this was the first time we taught as Two Scoops Academy using our new system of instruction. The environment that the 91st Cyberspace Operations Squadron works in is heavily isolated from the internet. What this means is that until technology or information is approved, it is unavailable to the software developers. While they can access Google, Stack Overflow, and Read the Docs, reading the source on GitHub is something they do at home, not on the job. This means they really need to understand their material. Our experience with their team (already competent in other programming tools) was that they were bright, focused, and willing to learn. The class included material on: Python, PEP8, PEP20, object oriented programming Django and related best practices Class-based views, ModelForms, and Forms Using third-party Python/Django components Bootstrapping projects with Cookiecutter and Cookiecutter-Django PostgreSQL, pgAdmin III, and … -
Understanding *args and **kwargs
args and kwargs are hard. They are confusing, and tricky when you are learning python. Even experienced developers can be tripped up by them. Learn how to expand and collapse lists and dictionaries for args and kwargs.Watch Now... -
Testing django admin search_fields
In the django admin you can add search fields. Very handy! You get a search field at the top of your admin page to quickly filter the results. Here's an example: class InvitationAdmin(admin.ModelAdmin): model = models.Invitation list_display = ['email', 'name', 'is_activated', 'activated_on'] search_fields = ['name', 'email'] See the django documentation. There is a mistake I often make: adding a foreignkey field in the search_fields list! Let's take the standard django book/author example. You have a Book and an Author model. Book has a foreignkey to Author. On the admin page that lists the books you want to have a search box. Not only for book titles, but you also want to search on authors' names and get their books. Easy: class BookAdmin(admin.ModelAdmin): model = models.Book list_display = ['title', 'isbn', 'num_pages', 'author'] search_fields = ['title, 'author'] Let's try it out in the admin. Oops: Traceback (most recent call last): ... TypeError: Related Field got invalid lookup: icontains You have to point at a proper texually-searchable field instead of directly to a model (via a ForeignKey field). It is easy to fix: class BookAdmin(admin.ModelAdmin): ... search_fields = ['title, 'author__name'] I've written a very simple test that tests all my ModelAdmin's search_fields: from … -
Open Sourcing SmartElect: Libya's SMS Voter Registration System
We are proud to say that, with the Libyan High National Elections Commission (HNEC) and consultative support from the United Nations Support Mission to Libya, we have open sourced their elections management platform today under a permissive Apache 2.0 license. Open sourcing means other governments and organizations can freely adopt and adapt the elections tools which cover nine functional areas. The tools range from SMS voter registration, the first of its kind, to bulk alerts to voters and call center support software. You can learn more at our brand new SmartElect homepage. This is the cumulation of two years of work, so we’re incredibly excited to share SmartElect with the rest of the world. -
Introducing Flask Editable Site
I'd like to humbly present Flask Editable Site, a template for building a small marketing web site in Flask where all content is live editable. Here's a demo of the app in action. Text and image block editing with Flask Editable Site. The aim of this app is to demonstrate that, with the help of modern JS libraries, and with some well-thought-out server-side snippets, it's now perfectly possible to "bake in" live in-place editing for virtually every content element in a typical brochureware site. This app is not a CMS. On the contrary, think of it as a proof-of-concept alternative to a CMS. An alternative where there's no "admin area", there's no "editing mode", and there's no "preview button". There's only direct manipulation. "Template" means that this is a sample app. It comes with a bunch of models that work out-of-the-box (e.g. text content block, image content block, gallery item, event). However, these are just a starting point: you can and should define your own models when building a real site. Same with the front-end templates: the home page layout and the CSS styles are just examples. -
A simple script to update a DB migration in Django 1.7+
During the development of a Django model on your local machine is it often necessary to refine the most recent migration to cope with updates to the model, without polluting the migrations of the app with a new migration for each local update. South had the update flag for the schemamigration command, but I didn’t find a similar functionality in the Django builtin makemigrations command introduced in Django 1.7. So I put togheter a simple bash script to automate the process. #!/bin/bash if [ -z $1 ]; then echo "Usage: $0 app_label" exit 1 fi app=$1 # this is the name of the app where we want to update the last migration # get the list of known migrations for the app migrations=(`./manage.py showmigrations $app | awk '{print $2}' | tail -2`) if [ ${#migrations[@]} == 1 ]; then # there is just one migration in the list # here we are updating the initial migration previous_migration=zero current_migration=${migrations[0]} # should be 0001_initial else # there is more than one migration in the list # get the previous one to go back to # and the current one to update previous_migration=${migrations[0]} current_migration=${migrations[1]} fi # go back to the previous migration ./manage.py …
