Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Ember application structure
Ember.js applications are divided into multiple files and folders. All of which makes sense when we get to know what is where, so lets take a look on Ember application structure. -
Setting up ember-cli development environment with ember 2.1
In a series of tutorials starting with this one I'll try to showcase ember.js framework for building fronted web applications. As a backend there will be Django Rest Frameowork and more. As times change and JavaScript frameworks don't just download to your static folder I'll start with setting up Ember.js development environment with ember-cli. -
We need less powerful languages
Many systems boast of being ‘powerful’, and it sounds difficult to argue that this is a bad thing. Almost everyone who uses the word assumes that it is always a good thing. The thesis of this post is that in many cases we need less powerful languages and systems. Before I get going, I should say first of all that very little in this post is original. The train of thought behind it was set off by reading Hofstadter's book Gödel, Escher, Bach — an Eternal Golden Braid which helped me pull together various things in my own thinking where I've seen the principle in action. Philip Wadler's post on the rule of least power was also formative, and most of all I've also taken a lot from the content of this video from a Scala conference about everything that is wrong with Scala, which makes the following fairly central point: Every increase in expressiveness brings an increased burden on all who care to understand the message. My aim is simply to illustrate this point using examples that might be more accessible to the Python community than the internals of a Scala compiler. I also need a word about definitions. … -
MIT uses Evennia!
Evennia was recently used as a test bed to train an AI system to attempt to play a MUD as a human would - by only reading and understanding the text on the screen. Researchers at MIT (Massachusetts Institute of Technology) recently presented the paper Language understanding for Text-based games using Deep reinforcement learning (PDF) at a conference on natural language processing. A summary is in the MIT press release.I was contacted by these fine folks some time ago so I knew they had plans to use Evennia for their research. It's great to see they now have an article out on it! Evennia devs are also mentioned in the acknowledgements - so something for the Evennia dev community to be proud of! MUDs are tricky The main complication for an AI playing a MUD is that the computer has no access to the actual game state but must try to surmise how well it's doing only from the text given (same as a human would). The researchers compare the results from a range of deep-learning neural network algorithm that they train to play. To test their AI, the researchers first used Evennia to build a simple training "Home World": … -
How to send Jabber (XMPP) messages from Django
Did you ever want to have a simple Django notification bot? An intranet one which just sends you (or someone you tell it to) Jabber messages when certain events occur? So did I. Please, welcome: django-jabber. -
How to send Jabber (XMPP) messages from Django
Did you ever want to have a simple Django notification bot? An intranet one which just sends you (or someone you tell it to) Jabber messages when certain events occur? So did I. Please, welcome: django-jabber. -
Tip: How to get a single object`s value with Django ORM
There are times when you want to get a single field of a single object in the database. For example, just get the headline of the blog post #1, not fetching it’s body. How do you do it in a usual way? >>> BlogPost.objects.only('headline').get(pk=1).headline 'Hello world' # Or maybe even this way: >>> BlogPost.objects.values('headline').filter(pk=1)[0]['headline'] 'Hello world' Recently I’ve stumbled upon a shorter one: -
Tip: How to get a single object`s value with Django ORM
There are times when you want to get a single field of a single object in the database. For example, just get the headline of the blog post #1, not fetching it’s body. How do you do it in a usual way? >>> BlogPost.objects.only('headline').get(pk=1).headline 'Hello world' # Or maybe even this way: >>> BlogPost.objects.values('headline').filter(pk=1)[0]['headline'] 'Hello world' Recently I’ve stumbled upon a shorter one: -
When you shouldn’t use the Django admin
In case you’ve thought I detest django.contrib.admin — by no means. Actually it’s one of the Django’s greatest features, I really love it. In most cases. Here’s a real life story. We’ve had to quickly put up the first version of an intranet claim tracking system, and one of our developers was just crazy about the Django admin… So why not, we’ve got along with the stock interface as the primary one for ... -
When you shouldn’t use the Django admin
In case you’ve thought I detest django.contrib.admin — by no means. Actually it’s one of the Django’s greatest features, I really love it. In most cases. Here’s a real life story. We’ve had to quickly put up the first version of an intranet claim tracking system, and one of our developers was just crazy about the Django admin… So why not, we’ve got along with the stock interface as the primary one for ... -
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. Here are my requirements: Fairly simple to run on initial server deploy, initial development environment setup, and when starting a test run. Does not risk overwriting changes that are made to records in the live database after they're initially created. Not too hard to update from the current live data, so that future new deploys etc get the latest data Copes well as models evolve, because they will Well supported by Django Not too great a performance impact on testing Here are some of the approaches that I've tried. Fixtures Fixtures are how Django used to recommend loading initial data. Pros: It's fairly easy to update the fixtures as the "initial" data evolves - e.g. you've added more options in your live server, and want to preserve them in the initial data, so just do another dumpdata. Fixtures don't slow down test startup if they're … -
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: 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: 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: 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: 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: 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: 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 …