5 open-source Python/Django apps we love
The Python/Django duet is fantastic, everyone knows that. However it can be even more awesome with these apps:
1. South
This is an intelligent schema and data migration tool. If you don’t use it yet, you will want to after reading this post. Okay… but what it is exactly?
When you create a Django app, you are using the “syncdb” command. After a model changes you have to delete the whole database and run “syncdb,” or manually do SQL changes directly in the database. It’s even more tragic when you already have production data. Not so fun, right?
Enter our hero: “South.” Its main objectives are to provide a simple, stable and database-independent migration layer to prevent all the hassles schema changes bring to your Django applications over time.
Simple example
Let’s create a model in our “southtut” app:
|
1 2 3 |
class Knight(models.Model):
name = models.CharField(max_length=100)
of_the_round_table = models.BooleanField() |
Then let’s create our first migration:
$ ./manage.py schemamigration southtut --initial
Creating migrations directory at '/home/andrew/Programs/litret/southtut/migrations'...
Creating __init__.py in '/home/andrew/Programs/litret/southtut/migrations'...
+ Added model southtut.Knight
Created 0001_initial.py. You can now apply this migration with: ./manage.py migrate southtut
And apply our new migration:
$ ./manage.py migrate southtut
Running migrations for southtut:
- Migrating forwards to 0001_initial.
> southtut:0001_initial
- Loading initial data for southtut.
Very similar to “syncdb,” for now. But now time for magic! Let’s modify the model:
|
1 2 3 4 |
class Knight(models.Model):
name = models.CharField(max_length=100)
of_the_round_table = models.BooleanField()
dances_whenever_able = models.BooleanField() |
To apply these changes we have to run these two commands:
$ ./manage.py schemamigration southtut --auto
$ ./manage.py migrate southtut
And that’s all! All data is in place with the new structure.
Read more here: http://south.aeracode.org/
2. Fabric
Fabric is the second must have app. Fabric is a Python library and command-line tool for streamlining the use of SSH for application deployment or systems administration tasks.
It provides a basic suite of operations for executing local or remote shell commands (normally or via sudo) and uploading/downloading files, as well as auxiliary functionality such as prompting the running user for input, or aborting execution.
Small example:
You are working on a Django app locally. After you finish working, you commit all changes to a repository. Now you want to deploy all the changes to staging or production server. This is what it normally looks like:
- open new console
- connect with server via SSH
- run virtual environment (if any)
- install any new requirements
- pull all changes from repository
- run syncdb, migrations (if South is used)
- collect static files
- delete *.pyc files (to be sure)
- restart apache/nginx or whatever server you have using
- restart memcache
10 steps and we are ready. But… how about doing same thing using only one line? Simple — use Fabric. With the proper configuration of all these steps we can close in this line:
$ fab production launch
Here you can read more: http://fabfile.org
3. Django compressor
What we would like to achieve in our website:
- every file is downloaded from server only ONCE (every next time cache is used)
- only one CSS and JS file is downloaded
- client browser always knows what file is actual and what file should be downloaded again
All of that is possible with Django Compressor.
Django Compressor combines and compresses linked and inline Javascript or CSS in a Django template into cacheable static files by using the “compress” template tag.
Example:
|
1 2 3 4 5 |
{% load compress %}
{% compress css %}
{% endcompress %} |
Which would be rendered all in one file:
|
1 |
<link rel="stylesheet" href="/static/CACHE/css/optimized_file.css" type="text/css" media="screen"> |
More information here: https://github.com/jezdez/django_compressor
4. Tastypie
Sometimes we have to add an API to our application without the ability to modify the sources of that app. Tastypie is exactly what we need. It provides a convenient yet powerful and highly customizable abstraction for creating REST-style interfaces. It relies only on its own code and focuses on providing a REST-style API.
Let’s create a resource class for our model “Knight”:
|
1 2 3 4 5 6 7 |
from tastypie.resources import ModelResource
from southtut.models import Knight
class KnightResource(ModelResource):
class Meta:
queryset = Knight.objects.all()
resource_name = 'knight' |
Now we have to hook up a resource:
|
1 2 3 4 5 6 7 8 9 10 |
from django.conf.urls.defaults import *
from southtut.api import KnightResource
knight_resource = KnightResource()
urlpatterns = patterns('',
# ...
(r'^southtut/', include('southtut.urls')),
(r'^api/', include(knight_resource.urls)),
) |
And voila! We have set up our REST interface. Our resource is available at these urls:
http://127.0.0.1:8000/api/knight/?format=json
http://127.0.0.1:8000/api/knight/1/?format=json
http://127.0.0.1:8000/api/knight/schema/?format=json
etc...
Of course, this is only one simple example. For safety, Tastypie ships with the authorization class and many more.
More information: http://tastypieapi.org/
5. Easy thumbnails
There are many apps for thumbnails. However, this one is the simplest and most powerful I’ve ever seen. We only have to add ‘easy_thumbnails’ in INSTALLED_APPS.
It’s great for quick thumbnails in template usage:
|
1 2 |
{% load thumbnail %}
{% thumbnail [source] [size] [options] %} |
where:
- source must be a File object, usually an Image/FileField of a model instance,
- size in the format [width]x[height]
- list of options like sharpen, crop, and quality=90
And that’s all. The thumbnail is created dynamically (if it doesn’t exist) when the page is requested.
Of course, there is Model and Low Level usage too.
More information: https://github.com/SmileyChris/easy-thumbnails
Tagged compressor, django, fabric, open source, python, south, Tastypie, thumbnails, tivix | 1 Comment
Django Common App (Part 1)
Here at Tivix we’ve created a number of open source apps that are available for use.
In this post we’re going to talk specifically about the django-common app, which provides functionality commonly needed in a django application (in case it wasn’t obvious).
WWWRedirectMiddleware
WWWRedirectMiddleware redirects requests to make sure they are on the www subdomain or off the www subdomain, depending on your settings. Besides adding ‘django_common.middleware.WWWRedirectMiddleware‘ to MIDDLEWARE_CLASSES, you need to set DOMAIN_NAME in the settings, either with www or not. You need to also set IS_PROD to true, as you don’t want to redirect on localhost.
SSLRedirectMiddleware and NoSSLRedirectMiddleware
SSLRedirectMiddleware redirects requests to make sure that they are under https. NoSSLRedirectMiddleware makes sure they are under http.
ssl_required decorator
If you don’t need ssl across the entire site (you oftentimes don’t) you can simply use the ssl_required decorator on the specific view that requires https.
disable_for_loaddata decorator
This decorator is used to wrap signals instead of views. It disables signals from being fired when the loaddata command is run. See: https://code.djangoproject.com/ticket/8399
EmailBackend
The EmailBackend is an authentication backend that works like the default ‘django.contrib.auth.backends.ModelBackend‘ except it finds users by email instead of username. To use it simply add ‘django_common.auth_backends.EmailBackend‘ to AUTHENTICATION_BACKENDS in the settings.
These are just a few features available in the django_common app. Stay posted for more posts on the django_common app, but of course the best way to find out all the functionality is to check out the app itself!
Tagged django, open source, overview | Leave a comment
Responsive Web Design
We all know that mobile devices and tablet computers are experiencing explosive growth right now. So how do you make sure that a new website today looks as good on an Android phone and an iPad as it does on a large computer screen?
Responsive Design is the idea that development and design on the web today should fluidly respond to the user’s environment based on the device platform, orientation of the device, and the overall size of the screen.
When incorporating Responsive Design into a website there are some key things to consider. The site needs to be built inside of a flexible grid. This will account for the screen size of the device and render the site differently based on it. Any images used within the design need to be flexible as well. And be sure to enable different views for different behaviors using media queries.
Creating the site within a flexible grid will allow the layout of the website to change based on the size of the browser’s viewport. You can create this grid manually or use a pre-built framework such as Skeleton. Skeleton is a great framework already built to support responsive and mobile-friendly development.
The next piece to consider is what to do with the images you place in the design. Images will need to scale and move within the flexible grid to allow users to see them on all kinds of devices. There are several solutions for this, but here are two popular ways of adding flexibility to your images:
1. Use the CSS overflow property (overflow: hidden) to dynamically crop images as the size of the containers they are in shift and change. The “Berkshire Salon and Day Spa” is a beautiful example of images cropping or disappearing altogether to accommodate device width — try resizing your browser window, and notice how the design responds to the viewer’s new dimensions.
2. The use of the CSS max-width property is an easy fix. Set the <img> with a max-width of 100%. This will narrow and widen your image to the width of the device or browser size.
Lastly, utilize media queries via CSS3. This is nothing new to style sheets — defining what kind of media your style sheet will use has been around for quite some time. A stylesheet designed for printing websites on paper (print.css) will differ from your core style sheet. The same concept is used when defining style sheets for devices. For example, you could create a style sheet that will only be used on devices with a maximum width of 480 pixels:
|
1 |
<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px)" href="style.css" /> |
Basically what this is doing is checking to see if the device uses a screen (as opposed to, say, print or braille) and if the device’s screen has a width equal to or less than 480 pixels (for example, an iPhone held in its portrait orientation). If so, the page will be rendered using the CSS in the “style.css” style sheet. For some great information on media queries and responsive design check out this amazing article by Ethan Marcotte.
The recipe for responsive design is fairly simple, but it does require designers and developers to change their way of thinking to create for entirely new experiences and audiences. Nevertheless, it’s exciting to think of the new era we are entering, creating custom solutions for a wide range of users on a wide range of devices.
Tagged flexible, mobile, responsive design | Leave a comment