Sessions at DjangoCon US 2011 on Wednesday 7th September

What makes a package useful? What is it about certain packages that makes them must-haves for any project? I’ll go over topics like: purpose, structure, docs, tests, availability on PyPI and Github/Bitbucket, activity, and more. I will visit some of the most useful grids on djangopackages.com and highlight my top package picks, showing examples of what makes these top packages so great.

What makes a Django package usable? (10 min)

Purpose
Structure
Docs
Tests
Community
Modularity (pluggability)
Availability on PyPI
Availability on Github/Bitbucket
Activity
Code quality
Package evaluations (25 min)

Go to a Django Packages grid
Drill down into doc/code examples from winning packages to show what makes them so usable
Making your favorite project get onto my favorites list (5 min)

Here's a rough outline of what we have in mind:

POINTS OF COMPARISON:

Purpose
1. To paraphrase James Bennett, the smaller the scope and greater the focus of your app, the better it will be. Application logic can be tighter and patching/replacing the app is easier.
2. The package addresses a real need.

Structure

Docs
1. No docs means your app fails. I won't even look at it.
2. Doc strings do not suffice as documentation.
3. Bonus points awarded for using rtfd.org for documentation hosting.
4. If there are dependencies, you must make the requirements clear.
5. The installation steps should be bulletproof. I should be able to follow your install docs and have the package just work.

Tests
1. No tests means it is hard to do Python/Django/Dependency upgrades
2. No tests means the the code is unpredictable.

Community
1. When was the last contribution?
2. How many people are contributing?
3. Who is contributing?
4. Attribution of authors: every author and contributor should be credited. This shows that you're willing to go the extra mile for your package.

Modularity (pluggability)
1. Installation should be minimally invasive to the rest of your project.
2. Do not confuse pluggability with over-engineering for every generic use case.
3. Within your app, sub-modularity is great, e.g. different registration backends for django-registration

Availability on PyPI
1. Give your package proper version numbers and always have the latest release available on PyPI.

Version Control Hosting
1. If you aren't on Github or Bitbucket you don't exist. Nothing else has the visibility for Django developers.
2. Launchpad and SourceForge are much less popular
3. Google Project Hosting lacks an API, so no metrics can be gathered.

Code quality / Best practices
1. Code follows PEP-8?
2. Tries not to have too many variables set in settings.py?
3. Easy to plug in, INSTALLED_APPS = ‘foo’ preferred.
4. Naming of your app: should be django-something, should be descriptive

SHOWDOWNS:
Fundamentals that every project needs
Registration
Profiles
Blogs
Tagging

REST
Database migrations

TAKE-HOME BONUS:
A sheet of useful packages recommended by Django developers whose opinions we respect deeply.

Over the last few years RESTful APIs have become an integral part of many django projects. But some of the fundamental questions still remain unanswered. How do you decouple resources from models, formatting from definitions, authorization from authentication? How should you define resources? How do you handle pagination? Deliver facets? Prevent abuse? Implement versioning? Let's have a look.

Implementing RESTful APIs for django applications used to be the talk of the town. Eventually a few API frameworks emerged. Some were designed to provide a quick & easy path to implementation. Some focused on decoupling components as much as possible. At the same time, numerous blog posts were published and emails exchanged seeking/ pitching sound API concepts & best practices. Somehow till this date, there is arguably no single solution that addresses all of the major concepts/practices around designing & securing RESTful APIs. Why? What were the promises? What were the lies?

In this talk, an attempt is made in identifying these concepts/practices in light of recent experiences with a PBS Education Technology project. In designing a RESTful API, it is important to establish a relatively simple resource definition that is uniform across all resources, yet powerful enough to deliver errors, pagination, facets as well as data from attributes/ methods of various models/ instances. It is also desirable to have serialization formats decoupled from these definitions and delivered to consumers according to their preferences.

Securing the API is a complex task as well. Not all RESTful APIs are meant for public consumption. Yet it is necessary to make AJAX calls that might leave the API vulnerable and expose security patterns. This talk highlights why it is important to have decoupled authentication backends, why 2-legged-OAuth can be an excellent choice in protecting the API and how adding pre-approved tokens can help differentiate between user/ application specific calls.

Concepts/ best practices evolve over time. So should the API. Sometimes it is necessary to perform refactoring or optimization that alters the API significantly. In any case, establishing a path to versioning API components is a prudent choice. Here, the fundamentals are explored.

Rest of the talk presents how PBS Education Technology team enhanced django-piston to incorporate the ideas and suggestions mentioned above. Also consumer side practices and security implementations are demonstrated using code examples.

South is a useful tool in agile development environments, but learning to use it effectively can take some practice. In this demo-driven talk we'll walk through some common workflow examples, disect a couple pitfalls, and call out the relative strengths and weaknesses of South as a tool at each step. Finding South's sweet spot for your environment will give you the best results.

The talk is based on observations and lessons learned from a few years of using South on large projects, with different teams and team makeups (mixes of developers, creative staff, etc.), and common questions on IRC / mailing list.

The demos will move quickly; a working understanding of creating and applying South migrations will be assumed. We'll make changes to a sample project, sometimes get ourselves into trouble, and pull back the curtains to figure out the best approach.

While going through the demos we'll take opportunities to learn how to consider:

• Impact on invidual developers
• Impact on other teammates / staff
• Impact on development and deployment environments
• Whether South can represent your desired operation in a sane manner
• Long-term code maintenance
• Testing changes and undoing messes

One thing I've found is that different teams and developers have varying philosophies about managing South migration histories over time. We'll put these ideas into context and audience members should come away with a good feeling about how to best use South for their particular needs.

Chef, a popular configuration management tool, is gaining momentum in the Django community. Learn how to deploy Django sites using Chef, be they one server or a thousand.

Chef, a configuration management tool, is increasingly popular in the Django community. Many people have yet to take the plunge, and are still managing production systems exclusively through tools like Fabric or Buildout. In this talk I will quickly show the basics of building Chef recipes, both in general and a tour of the Django-and-Python-specific tools available. I will then walk through a suite of cookbooks built to deploy Packaginator as a production site in the cloud. If suitable wireless is available, I would like to do a live demonstration at the end, bringing up a new site from scratch.

Outline:

Introduction
- Chef basics
- Resources
- Actions
- Recipes
- Cookbooks
- Roles
- Search

Python cookbook
- Community site/cookbooks
- pip provider
- virtualenv provider

Django application recipe

Other misc cookbooks
- Postgres
- Redis

Packaginator cookbooks
- Application recipe
- Postgres master/slave
- Gunicorn
- Nginx
- HAProxy
- Redis
- Celery

Demo (pending wireless)

Q&A

Tastypie is one of a couple of frameworks for building APIs with Django. Isaac will go over some of the reasons you might pick Tastypie, and how to implement a Tastypie on top of an existing Django project.

Tastypie makes APIs. It is both straightforward, and powerful, once you know the basics of what it expects, and how it's structured.

This talk will introduce, as well as share a few tricks for less simple APIs.

Why does Django make it hard to have translated database contents? And what solutions are there to make it easier? And how can Django make multilingual database contents less of a pain?

Multilingual database contents are not an easy thing to accomplish in Django. While there are many projects out there helping you with this, they all have their good and bad sides. The reason for this is that Django does not really help a lot in this area. There are things though, Django could do to make this easier and for some use cases, the existing solutions are actually good enough. I would like to share my knowledge and experience in this field, having developed almost exclusively multilingual websites and having developed two projects to make this easier in Django.

Learn the questions to ask and the tools to use to spot performance problems in your application. We won't tell you how to scale your site, but we will show you how to locate the bottlenecks as they pop up.

Performance optimisation has always been a hot topic among the Django community, and as applications become more mature and larger companies adopt Django for high-traffic projects this issue will heat up even more. This talk will not focus on resolving performance/scalability issues but rather on discovering them. It will try to answer the following questions:

• How do you know where the worst problems are?
• When did the problem start, and what parts of your application are affected?
• How do you tell the difference between the giant performance monsters and the windmills that aren't really big problems at all?

This talk will not spell out a quick and easy 5-step method to alleviating all of your performance woes. It will, however, show you ways to measure your site’s performance over time and spot the real trouble areas as they occur. It’s vital to know both your application and your user well in order to create an effective test plan. We will discuss the importance of reliable performance measurement and realistic performance tests, and walk you through the tools we use to identify and track problems.

• Django Debug Toolbar - get internal information about what your application is doing
• Django Debug Logging - log Debug Toolbar statistics to the database and review details and aggregated summaries.
• Creating a cron job to run automated performance tests at regular intervals
• Jmeter for external tool to create load tests with high concurrency
• Integrating Jmeter with Jenkins using the performance plugin

To close up, we’ll mention some of our favorite resources on handling the performance problems that you encounter during your testing. We’ll also provide links to other tools that you can use as part of your testing efforts. With this information at your disposal you can charge boldly through the meadow on your faithful Rocinante, attacking the real performance problems and leaving the windmills behind.

Documentation is normally held to be one of Django's strong points. Steve attempts to point out that even the best can stand improvement.

As someone who had to learn Django primarily from the documentation, the author was glad that the documentation existed, but it seemed to make assumptions of knowledge that weren't necessarily in his head at the time. It was therefore a frustrating enough experience to result in this talk, which looks at some of the ways that the Django documentation could be made more user-friendly and effective.

Considerations, best practices, tools, and more for front-end development in Django.

This talk will go over considerations and best practices for front-end development in Django and beyond. Ways to:

• Best build and organize your templates
• Tools to make your life easier and faster
• Optimize and test code
• Integrate and play well with the back-end
• Deliver the most shiny of web applications

This talk will go through the deployment system that we have built at Urban Airship. It will cover the process that allows us to automate our deployments, making it safe to deploy at any time. It's built on Fabric, Gunicorn, Virtualenv, Rsync, Supervisord, and Python. We end up with fully isolated environments for our services that are easy to manage.

This talk will cover how we do deployments. It is the first deployment system that I've been happy with, which says a lot. It is a system that we have been evolving over the last 6 months or so, and has made our developers lives a lot easier. There are a few different points that make it successful, as well as useful.

Interestingly, there is very little Django specific about this setup. It is how we deploy Django applications, but we also deploy flask and standard WSGI applications using the same framework. A slightly modified version of the code is also used to deploy our Java applications, so the tooling is genericly useful for more than just Django programmers

The talk will have 4 parts, that will cover the following:
- The process around Version Control that we use
- The tooling to deploy code
- The environment that the code gets deployed in to
- The process of deploying the code across all of our servers, a subset at a time

The first part is that we manage our source code in a specific fashion. It's a pretty standard git branching model, where we have a master branch that is the latest stable code. All on-going work is done on feature branches. Then we have a production branch that is what is currently in production. Each push to production is tagged with the date. Git allows us to keep a record of the history of development in one place.

Next, to actually handle the deployment of the code to the servers, we're using Fabric. To show the full power of the system, we might normally run a command like fab host:web-0 deploy:airship restart:airship monitor:airship. This is mostly abstracted out from people in the day to day use of the system. The deployment system has the following features:

• Updating source code checkouts
• Making VCS tags
• Deploying code
• Migrating the database
• Updating media files
• Restarting services
• Rolling back to the previous version
• Allowing the person deploying the ability to easier monitor logs/status of services
• One command "smart deploys"

The python environment that things are deployed into is a fully standardized setup using supervisord and gunicorn, along with a number of other helper utilities. It integrates into the init.d system on the host, so that normal management commands work. Each service that we deploy has it's own environment, which I'll go into more depth on.

Finally, We are also working on a system that will allow us to automatically health check deployments and automatically rollback the deployment if we are seeing elevated error rates. We handle deploying the code to a "canary" system first, then roll it out to half our servers, then the other half. This system is implemented currently at the prototype level, but should be in production use before the talk is given.

The open-source world is and always has been focused on code; attention and respect doled out in exchange for patches. As a result, many open-source projects want for design love but don't know how to secure it. We scare off potential contributors from the many fields beneath the aegis of “design”: user experience, user interfaces, usability, interaction design, information architects, graphic design, typography, and other roles assumed by the authors of our markup and styling.

Django can be a model citizen among open-source projects in changing these attitudes and coaxing contributors out of the woodwork—not just for the benefit of the framework, but for the constellation of 3rd party apps which make Django great. Other FOSS communities have made efforts that we can learn from, and the fight to change perceptions is less uphill than you might think.

This talk will cover:

• Misconceptions of “Design.” What is design, and what do designers do?
• A brief trip down memory lane, and how Django came to be relatively designer-friendly.
• “I don't get it: what is the BDesignFL role?”
• Process and tools: How can Django better engage designers, for core's benefit and for the benefit of your projects. How can we help these contributors get over the “suck” threshold?
• What parts of core are ripe for love from designers? What 3rd party projects?