Blog

Posts about django

Django Settings Parity: You're Doing It Wrong

Posted by Peter Baumgartner on February 15, 2013. Filed under django

A common paradigm in Django is to create different settings files for different environments (local, production, staging, etc.). Everyone has their own opinion on how to set these up (see ours here), that’s not what this post is about. Instead, I’d like to point out the inherent danger in this technique and how to prevent shooting yourself in the foot.

When setting up an environment-specific settings file, each setting should be looked at as an untestable point-of-failure. Have you ever found yourself saying, “...but it worked fine on {staging, my machine, etc.}”? This is a problem of parity and it starts with your settings files. Just because you can change all your settings between environments, it doesn’t mean you should. Use restraint. Make your settings as close as possible between environments and examine every divergence to make sure it is absolutely necessary (inheriting from a common base ...

View comments View full post

Introduction to Django Selenium Testing

Posted by Marco Louro on November 2, 2012. Filed under code, django

If you’ve never heard of Selenium, put simply, it’s a tool that allows you to create tests that are run in the browser and interact with your UI in the same way as if you were manually testing your website or app. It’s the de-facto standard to test complex Web UI interactions that usually involve a heavy use of JavaScript, and that’s probably the main use-case for it. Other than that, we also use it sometimes as a helper tool for cross-browser design (CSS) testing by running Selenium tests through different browsers and taking screenshots or recording videos.

Selenium’s been around for a long time now, and is available in various programming languages, but up until Django 1.4 came along you couldn’t have your Selenium tests (easily) integrated with your Django test suite. Since then, a new class named LiveServerTestCase, that your Selenium ...

View comments View full post

Load Testing with JMeter: Part 3 - Replaying Apache Logs

Posted by Brandon Konkle on September 19, 2012. Filed under django

A while ago, I wrote a couple of blog entries about load testing with JMeter (Part 1 and Part 2). I promised a third entry covering how to use JMeter to replay Apache logs and roughly recreate production load, but I never followed through with it. Today, I intend to rectify this grievous error.

Parsing your Apache Logs

There is more than one way to do this, but my preferred method is to use a simple Python script to do some filtering of the Apache log file you want to use and to output the desired urls as a tidy CSV file. I am using the ‘apachelog’ module for this (also available as a gist):

#!/usr/bin/env python
"""
Requires apachelog.  `pip install apachelog`
"""
from __future__ import with_statement
import apachelog
import csv
import re
import sys
from optparse import OptionParser

STATUS_CODE = '%>s'
REQUEST = '%r'
USER_AGENT = '%{User-Agent}i'

MEDIA_RE = re.compile ...

View comments View full post

Backbone.js for Django Developers

Posted by Peter Baumgartner on June 5, 2012. Filed under django, javascript

Our new product Ginger relies heavily on Backbone.js for most of the client-side functionality (you can read about our full web-stack here). Our JavaScript guru Marco built the initial prototype and then was pulled away by client work. I reluctantly filled in, but my background is primarily in Django. My JavaScript experience was minimal (primarily stitching together jQuery plugins to get the desired effect).

After a month or two of being submersed in Backbone, I’ve seen the light and am now relatively competent. When I got started I was completely lost. Here are some things that probably would have helped me back then. Whenever possible, I’ve linked to the source of the Backbone Todo example for code samples.

Terminology

In many ways, Backbone and Django are similar. They’re both MVC-like, but some of the terminology they use is different. Here’s a quick map:

  • Backbone ...

View comments View full post

Four Libs Good, Two Libs Better

Posted by Brian Luft on May 24, 2012. Filed under django

[with apologies to Mr. Orwell]

I’ve noticed a subtle shift in how we approach building up new sites over the last couple of years. Our approach to site construction used to favor collecting open source apps and gluing them together in order to build up scaffolding quickly and to reuse the efforts of others. This is still a prominent part of how we operate, but we also don’t automatically reach for an app just because one exists—even ones we know are high quality.

In the past, pip requirements with dozens of dependencies was common for larger sites. These days we tend to use a lot more discretion before adding an entry to those files. While reusable apps can seem to offer productivity gains by providing the base for a feature with minimal effort, there can be a lot of hidden time costs that only surface intermittently throughout ...

View comments View full post

On Fixtures and Factories

Posted by Brian Luft on May 3, 2012. Filed under django

We’ve made it a general rule to move away from relying on fixtures in our projects. The main reasons are:

  • Fixtures are fragile. They often break when the schema changes or even worse they appear to work but introduce subtle bugs.
  • Extra work is sometimes needed in order to make fixtures portable (for example defining natural keys).
  • Processing large fixtures can be very slow, which slows down installation and testing cycles.
  • Other smart people in the community are recommending the same approach.

We look for good tools that are usually classified as either data generation or fixture factory. We’ve had some success with django-whatever and wanted to share a few tips. Some of the benefits of django-whatever:

  • Generating one or many instances of a Model can be done in a line or two of code.
  • Easy to handle things like non-standard primary keys or recursive relationships
  • Using a ...

View comments View full post

Ginger Tech Stack

Posted by Peter Baumgartner on April 23, 2012. Filed under django, ginger

For our latest product, Ginger, we wanted to marry the real-time functionality we needed with the traditional Django stack we know and love. After some false starts and falling on our faces in the beginning, we ended with a stack we’re happy with and think will serve us well moving forward.

Back-end

This is our bread-and-butter. It’s Django and PostgreSQL running with Gunicorn behind Nginx. The biggest difference between this and your typical Django site is that it mainly serves as a REST API consumed by the front-end. We are using traditional Django views in a few places like login, logout, and user profiles, but the rest of the views are handled by the front-end.

Using Django, we were able to quickly build the nuts-and-bolts parts of our site that didn’t require any special real-time functionality. A few of the important libraries we’re using:

View comments View full post

Quick Django Class Based View Decorator

Posted by Vláďa Macek on January 30, 2012. Filed under django, pro tip

The recommended way to add decorators such as login_required to class based views in Django is a bit verbose. Here’s a little metaclass-producing function you may find handy:

def DecoratedDispatchMethod(actual_decorator):
    """
    If you want to decorate the Class-based View with, say, login_required,
    the recommended way is this:

        @method_decorator(login_required)
        def dispatch(self, *args, **kwargs):
            return super(MyProtectedView, self).dispatch(*args, **kwargs)

    To avoid the need of writing this ugly code again and again, one can use
    this as a metaclass of the class that needs to be protected with a decorator.

        class MyProtectedView(...):
            __metaclass__ = DecoratedDispatchMethod(login_required)
            ...
    """
    class CBVMetaclass(type):
        def __init__(cls, name, bases, attrs):
            type.__init__(cls, name, bases, attrs)
            cls.dispatch = method_decorator(actual_decorator)(cls.dispatch)
    return CBVMetaclass

View comments View full post

Django Caching in the Real World: Part 1

Posted by Yann Malet on December 27, 2011. Filed under django

When you develop a sizable content heavy web site you quickly learn, hopefully not the hard way, that caching is a very important piece of your infrastructure. The database servers are the typical bottleneck in high volume website.

Common wisdom in such cases is to reduce database queries with caching instead of hitting the database on every request. This is a good approach, and even seems relatively simple on the surface, but you will quickly discover that the devil is hidden in the details. There is no one right way to do it.

One of the most famous quotes1 about Computer Science clearly states it:

There are only two hard things in Computer Science: cache invalidation and naming things.

The best approach is very application dependent; one-size does not fit all. What we are going to describe are the results of a succession of trade-offs that worked well for ...

View comments View full post

Latest Work and New Client Availability

Posted by Peter Baumgartner on November 15, 2011. Filed under company news, django, portfolio

It’s been a while since we’ve posted anything here about Lincoln Loop, so it’s time for a quick update.

In short, we’ve been hard at work. In addition to having multiple speakers at DjangoCon, and starting work on an internal project, our team also launched two big client development projects:

  • GamesRadar is a high-traffic gaming review site with lots of social features
  • Evite Postmark is a web application for building premium online invitations and correspondences

With these two big initiatives launched, for the first time in almost a year, our team has availability for new client work.

We’re now on the lookout for the next great project to take on. Our ideal project would be one that lets us focus on our strong points: remote development, in an agile manner, using Django and Python. We typically look for long-term engagements (more than 3 months) that ...

View comments View full post

Load Testing with JMeter: Part 2 - Headless Testing and Jenkins Integration

Posted by Brandon Konkle on October 12, 2011. Filed under django

The Headless Horseman (Running JMeter in No-GUI Mode)

The Headless Horseman

If you read Part 1 of my JMeter series, you now know how to create a JMeter performance test with as much complexity as you need to hit every part of your application and push it to its limits. As mentioned at the end of the post, though, when running your test plan from your local machine you are often limited by bandwidth. The test plan may not be able to fully stress your application because it can’t transfer data fast enough for all of your concurrent connections. To really push your application hard, you need to run your load test from the same local network that your application runs within.

If you’re testing your staging or production infrastructure, you could run JMeter from a dev server within the same network. If you’re on a cloud platform, you could ...

View comments View full post

Load Testing with JMeter: Part 1 - Getting Started

Posted by Brandon Konkle on September 21, 2011. Filed under django

Last week, Yann Malet and I gave a talk at DjangoCon about using performance analysis to spot bottlenecks in your application. Because of the somewhat broad scope of the talk, we were only able to briefly introduce the tools we use and how we use them. Over the next several weeks, we plan to dive a little deeper into some of those tools here on our blog.

To start off, I’m going to go over our JMeter setup in much more detail. It is a very powerful tool capable of complex load tests, but it is very unfriendly to new users and the documentation is not ideal. I’ll go over the basics and cover a couple of tricky things like how to authenticate, and simulating Ajax requests. This information is presented with Django in mind, but should apply to any framework you’re working with.

Load Testing

Load ...

View comments View full post

Get your (arcade) game on!

Posted by Peter Baumgartner on September 5, 2011. Filed under django

We love the Django community and to show our thanks, we’re throwing a private party Wednesday night for DjangoCon attendees. After dinner (9-11pm), come on down to Ground Kontrol, Portland’s favorite classic arcade. We’ll have an open bar (while supplies last) and free gaming on their 90+ arcade games. Come on by, say hi and have a drink on us while you play the classics like Donkey Kong, Frogger, and Asteroids!

Ground Kontrol is at 511 NW Couch only 0.5 miles (0.8 km) from the conference hotel and is easily accessible by foot or via the MAX Green Line. They’ve only got room for ~120 people, so come early to make sure you get in!

View comments View full post

Disabling South Migrations

Posted by Brian Luft on July 18, 2011. Filed under django

It is often handy to disable (either temporarily or permanently) South migrations for an app. “Disable” in this context means preventing an app’s migrations from being executed so that the app is managed via syncdb while in this state. A couple scenarios where this could be useful:

  1. An app’s migrations are failing somewhere and a developer is stuck trying to install the full schema. It may be in that developer’s interest to just get back to a working state as quickly as possible – especially if someone else is maintaining that app.
  2. A third-party dependency package ships with migrations. There is often little benefit to running the migrations for a third-party package, and occasionally the migrations won’t apply cleanly if the author doesn’t test the full migration history regularly.

As an example, the django-cms project ships with several dozen migrations. While the authors work hard to ...

View comments View full post

Resetting Your South Migrations

Posted by Brian Luft on June 20, 2011. Filed under django

Why?

A common question from South users is how to reset the migrations back to an initial state. The reasons for doing this are often related to the number of migrations growing steadily over the life of the project. You’ve probably noticed that tests and parts of your workflow are bogging down while waiting for a bunch of migrations to run. In practice it is rare that you’ll have a need to roll back to an early version of a model that is potentially dozens of migrations back in history. Therefore, the idea of resetting your South migrations is worth examining when deciding how to manage your project history long-term.

An important consideration is whether or not you control all environments where your app will be deployed. For example, if you are maintaining or planning to release a public open source project, resetting migrations is rarely going to ...

View comments View full post

Custom Filters in the Django Admin

Posted by Yann Malet on January 11, 2011. Filed under django

A few weeks ago Django’s team revealed a data leakage bug in the admin application that affects an extremely interesting and undocumented feature. A user that has access to a change_list page of an object in the admin interface can filter this list by adding some parameters in the URL. Django will parse them and filter the queryset using the given criteria. Before this security fix you could use this feature out of the box and there was no control over the criteria that were passed by the user. Information outside of an admin user’s permission could leak.

In order to avoid this a new method called lookup_allowed has been added to the ModelAdmin. By default this method restricts the lookup to what is declared in list_filter or date_hierarchy. As with most things in Django, you can easily override this function in the subclass of ModelAdmin to allow ...

View comments View full post

Using Proxy Models to Customize the Django Admin

Posted by Yann Malet on December 16, 2010. Filed under django

Fellow Lincoln Looper, Martin Mahner, posted an excellent write up on how to use proxy models to separate staff and user accounts in Django’s admin. We frequently have a need for this in client projects, but people don’t often consider proxy models for this functionality. Here’s another scenario we came across recently where they came in useful.

Background

Proxy Models were introduced in Django 1.1. The official documentation describes their usage, comparing and contrasting them with Model inheritance. One fact the official documentation does not explicitely state is that django won’t let you register multiple ModelAdmins to the same Model. This is where proxy models can come to the rescue.

Example

Consider a newsroom application with articles that must be categorized into sections:

#models.py
from django.db import models

class Section(models.Model)
    name = models.CharField(max_length=90)
    slug = models.SlugField(max_length=90)
    # ... More ...

View comments View full post

Tracking Application Response Time with Nginx

Posted by Vláďa Macek on November 9, 2010. Filed under django, sysadmin

Recently we noticed some intermittent slow downs with our Gondola sites and wanted to track down the source of the issue. Our sites are all Django projects served by Apache/mod_wsgi behind an Nginx frontend proxy. Nginx’s upstream module makes the process of logging response times trivial with its upstream_response_time variable.

I added this block to /etc/nginx/nginx.conf to define a new log format timed_combined which captures some additional data in our logs:

log_format timed_combined '$remote_addr - $remote_user [$time_local]  '
    '"$request" $status $body_bytes_sent '
    '"$http_referer" "$http_user_agent" '
    '$request_time $upstream_response_time $pipe';

This is the default combined format1 with the three variables appended to it.

  • request_time This shows how long Nginx dealt with the request
  • upstream_response_time Gives us the time it took our upstream server (in this case Apache/mod_wsgi) to respond
  • pipe Shows 'p’ in case the request was pipelined.

Next we modify our access_log directives to use the new format ...

View comments View full post

We're Hiring!

Posted by Peter Baumgartner on September 20, 2010. Filed under django

We’re looking for a Django developer to join our team. With the impending departure of Armin Ronacher to finish his degree, we’re going to be at least one developer short this Fall. We’re looking for somebody who can jump right in and start contributing, primarily as a back-end Python/Django developer.

We’re a distributed company, so location does not matter. We like to hire managers of one and prefer people who are active in the Django open source community.

Initially, this will be a full-time (or as close as possible) contract position. If things work out, we’ve got a workload that can keep you around indefinitely. If you are interested, send an email to info@lincolnloop.com and include the following:

  • your resume or LinkedIn profile
  • links to open source code you’ve developed
  • your hourly rate

View comments View full post

Django 1.1 Testing and Debugging Book Review

Posted by Peter Baumgartner on June 16, 2010. Filed under django, review

Django 1.1 Testing and Debugging

I just finished reading the copy of Django 1.1 Testing and Debugging by Karen M. Tracey provided to us for review by Packt Publishing. For those of you who don’t know, Karen is a core developer of Django and her knowledge and experience in the framework shines through in this book.

This is a great book for people who want to transition from being a hobbyist tinkering on Django sites to professional developers. It will be a lot to digest for a newcomer to Django and might not contain much new information if you’ve been working with Django for a while (and writing tests for your code). The book covers:

  • doctests vs. unit tests
  • integrating external tools like Nose, Coverage, and Twill
  • debugging with logging, Django Debug Toolbar, and pdb
  • how to get help from the Django community and file bugs
  • troubleshooting Apache/mod_wsgi deployments

Even though ...

View comments View full post

Gondola for Real Estate Launch

Posted by Peter Baumgartner on May 24, 2010. Filed under company news, django, gondola

I’m pleased to announce that Gondola for Real Estate, our GeoDjango-backed real estate CMS is publicly accepting new customers. A couple weeks ago, we quietly re-launched gondolacms.com with some details about the platform and what it has to offer, as well as some sites that have been built on it over the last few months.

History

A couple of years ago, we were building websites for some local real estate agents and realized that what they wanted couldn’t be shoehorned into the popular CMS frameworks available at the time. Somewhat reluctantly, we set out to reinvent a CMS that met their needs written in Django. Eventually, the client-specific bits were extracted and Gondola was created. It has been under the radar for the last few months while we tweaked the system with a small group of early adopters and it is to the point now where we ...

View comments View full post

Lincoln Loop Development Sprints and Limited Time Discount

Posted by Peter Baumgartner on May 18, 2010. Filed under company news, django

Today, we are launching a new offering at Lincoln Loop, development services paid by the sprint. Previously, our typical engagements involved a (sometimes lengthy) discovery, estimation, and bidding process. Lately, however, people have been asking us to jump in with both feet and help them get started immediately. For those people, we think paying for services on a sprint-by-sprint basis will be a great option.

At the beginning of every sprint, you’ll provide us with a prioritized list of user stories, features, or tasks that are to be completed. Our team then dives into the project for a 2 week long focused burst of work. Our goal is to complete as much of that list as possible in the time allotted for the sprint. For development work, that means fully-tested features ready for production. During the sprint, we can provide not only our expertise in Python and Django, but ...

View comments View full post

Installing GeoDjango Dependencies with Homebrew

Posted April 30, 2010. Filed under django

Homebrew seems to be the hot new package manager for OS X, so while setting up a new system last night, I figured I’d see how it handled installing all the external libraries required for GeoDjango. The answer I quickly found out was, “extremely well.” Here are the steps:

$ brew update # make sure all your formulae are up to date
$ brew install postgis # this will handle installing postgres, geos, proj4, and postgis
$ brew install gdal

That’s it. Three (two if you don’t count the update) steps to GeoDjango goodness. Color me impressed.

View comments View full post

Django 1.0 Template Development Book Review

Posted by Peter Baumgartner on October 15, 2009. Filed under django, review

Packt Publishing was nice enough to send us a copy of Django 1.0 Template Development by Scott Newman for review recently. I get most of my technical information via the web, so picking up a technical book was a nice change of pace. This is a well written and enjoyable read for people looking to learn a little more about Django than what is provided in the Django tutorial.

Based on the title, I expected a thorough write-up of the template system for front-end developers. With the way Django was designed, template developers need little, if any, knowledge of Python and what goes on under the hood with Django requests. I was surprised, however, to see that pure front-end (HTML/CSS/JavaScript) developers were not the target audience of this book:

This book is for web developers and template authors who want to fully understand and utilize the Django ...

View comments View full post

Easy Fabric Deployment, Part 2: Multiple Committers and the Dreaded Umask

Posted October 7, 2009. Filed under code, django

In part 1, we showed how we use Fabric to update and deploy Django sites to our development server with a single command. This works great when you only have one developer pushing changes to the server, but what happens when multiple committers need to update the development server?

Linux File Permissions

Typically, the default permissions for newly created files are readable by everyone and writable by the owner (644 or -rw-r--r--). These permissions are determined by the processes umask, with the default being 022. Since we want multiple committers to be able to write to files on our development server, we need to change that to 002, creating group-writable files (664 or -rw-rw-r--).

The standard way to do this is to add the line umask 002 to /etc/profile. While that works great for interactive shells, it does not get called on non-interactive shells (the kind that Fabric ...

View comments View full post

Easy Fabric Deployment, Part 1: Git/Mercurial and SSH

Posted by Peter Baumgartner on September 22, 2009. Filed under code, django

We’re firm believers in the practices described by the Continuous Integration method of software engineering. Among those are:

  • Maintain a code repository
  • Automate the build
  • Automate deployment

We use git for our code repositories and Fabric to automate our build/deployment process. The tiny bit of overhead it take to write out a Fabric script pays off very quickly against the tedium and error-prone practice of manually building/deploying. In building our “fabfile”, we encountered a couple of issues that took a little head-scratching to work out.

Git and SSH Keys

Git, like Mercurial and others, confirms your credentials via an private/public key pair when used over SSH. We use gitosis to manage our private repositories, so managing everyone’s keys isn’t much of an issue. The problem comes when developers need to start pulling the repository on different machines. Our developers all push to a central ...

View comments View full post

Using Django Inside the Tornado Web Server

Posted by Yann Malet on September 15, 2009. Filed under code, django

Inspired by Eric Florenzano’s talk, Using Django in Non-Standard Ways (slides in PDF) at DjangoCon and the announcement of Tornado (tornadoweb.org), I decided to try building a small application using the Django Form library and Django ORM inside Tornado. The process proved easier than I expected, especially with Russell Keith-Magee being able to provide guidance on demand.

Step 1: Create Your Database

While Russell explained that it should be possible to get commands like syncdb running outside of a traditional Django project, it was outside the scope of this small experiment. Instead, I created a Sqlite database manually. For those of you that have forgotten how to do this, this will get you started:

# sqlite3 dev.db

sqlite> CREATE TABLE message (id integer primary key, subject varchar(30), content varchar(250));
sqlite> insert into message values(1, 'subject', 'cool stuff');
sqlite> SELECT * from message;

Step 2: Write Your ...

View comments View full post

Customizing the Django Admin at EuroDjangoCon 2009

Posted by Peter Baumgartner on June 22, 2009. Filed under django, presentation

Last month, Lincoln Loop gave a talk at EuroDjangoCon about customizing the Django admin interface. After presenting some of the admin customizations we had done on Gondola, I had a bunch of people get in touch with me asking me to do a write-up about how it was done. After about 8 months of heel-dragging, I finally took the time to do it in presentation form.

Our talk was divided into two parts. First our User Experience Director, Michael, gave an overview of user interface design and why it is important, pulling examples from some real-world interfaces. Comparing the default Django admin to a custom built application specific interface was an intentional cheap-shot to get people to think outside-the-box when working with the admin. Our argument was that it is possible to recreate any of the example interfaces while still leveraging some of the power baked into django.contrib.admin ...

View comments View full post

Django Best Practices

Posted by Peter Baumgartner on April 9, 2009. Filed under django

This post got a bit long-winded, skip to the project announcment if you prefer.

One of the things I love about Python and Django is the philosophy that there is one obvious way to do things. Standards make it easy to dive into other people’s code and figure out what is going on pretty quickly. As with anything under active development, however, those standards are subject to change over time. What was best practice for building sites with Django 0.91 is significantly different than building sites with Django 1.0. Better tools and more experience allow us to refine our processes over time into a set of best practices. While both Python and Django are very well documented, much of the experience and wisdom that is outside the scope of the official documentation is not.

Blogs are Bad for Documentation

Most of this information lives scattered across blogs ...

View comments View full post

Satchmo Screencast

Posted by Peter Baumgartner on December 23, 2008. Filed under django, screencast

Satchmo is an amazing E-Commerce engine built on top of Django. After struggling in the past with difficult packages like ZenCart and OSCommerce, Satchmo’s ease of customization make it a joy to work with.

Unfortunately, all the features can make the administration interface a bit daunting at first glance. I created a screencast to help shop owners get started with the process of adding products and product variations in Satchmo. I’m using the latest release as of this writing (0.8.1).

View comments View full post

Simple & Easy Deployment with Fabric and Virtualenv

Posted December 7, 2008. Filed under django, gondola

In the process of prepping Gondola CMS for public consumption, we’ve grown from having a developer (me), to having a development team. One pain point that quickly arose was the amount of time it took for new developers to setup a local development environment. In addition to our source code, the project depends on nearly a dozen other Django apps and Python packages. Initially, we simply tracked the requirements in a text file, but it required a lot of manual work to get them downloaded and installed.

Necessity is the Mother of Invention

Of course, this problem has been tackled many, many times before1. As I looked into what was out there, my first thought was that most of the existing options were far too complex for our needs. If I didn’t grok a system after clicking around the docs for 10 minutes or so, I moved ...

View comments View full post

On Static Media and Django

Posted November 13, 2008. Filed under django

We all know not to serve static media (images, CSS, Javascript, etc.) in production directly from Django. Thankfully, Django gives us some nice settings like MEDIA_URL and MEDIA_ROOT to make serving them a lot less painless. Lately, however, I’ve come to realize that these settings shouldn’t really apply to all static media.

Not All Static Media Is Created Equal

Static media really comes in two flavors. Media that is part of your site like your stylesheets and user generated media or files that are uploaded to the site once it is live. We don’t want to serve all this media from the same place for a couple of reasons:

  1. Our source checkouts shouldn’t be crufted up by stuff our users are uploading
  2. User generated content and source code should live in two different places on the filesystem

We could fix the first problem with some .gitignore ...

View comments View full post

Serving Django Projects (Revisited)

Posted September 22, 2008. Filed under django

After reading the comments on my last post on the subject, I realized there was definitely some room for improvement in my strategy. This is take two of the original post.

Problems

My original strategy had a couple of downfalls:

  • Poisoning the Python Path

I was adding directories to the Python Path that weren’t Python. This raised the chance of namespace collision and just wasn’t a very clean way to do things.
  • No project source repository

I was still storing all my source files in one big folder. Tracking which project is using what was more difficult than it needed to be.

Solutions

The first step to recovery was forgetting about sharing libraries between projects altogether. In theory it sounds great, in practice it was cumbersome to manage. My directory structure now looks like this:

|-domain1.com
|--apache
|---django.wsgi
|--src
|---domain1_project_src
|---third_party_repo1
|---third_party_repo2

This is much cleaner ...

View comments View full post

Introduction to Gondola

Posted September 19, 2008. Filed under django, gondola

Gondola is our content management system built on top of Django. I briefly showed it off during my DjangoCon Lightning Talk, but have been wanting to give it a proper screencast for a while. Here’s an introduction:

A few common questions I don’t tackle in the screencast:

  • Is this an open source project?

As of right now, no. I do plan on spinning off a few bits as open source over time. In fact, the WYSIWYG editor is already on Google Code as django-admin-uploads. Unfortunately it hasn’t been synced up with our in-house code in a while and isn’t working on 1.0. We’ll get that updated at some point in the near future.
  • How much will it cost?

I haven’t settled on a pricing structure yet, but I want it to be affordable for small businesses.
  • What version of Django are you running ...

View comments View full post

My Lightning Talk from DjangoCon 2008

Posted September 18, 2008. Filed under django, presentation, trailmapping

DjangoCon was an amazing conference all around. I met some great people and learned a lot. I also had the opportunity to get up on stage and present some of the things I’ve been working on here. I was really nervous and after seeing how well prepared the presenters before me were, I had doubts about my plan to go on stage and wing it. I spoke about Trailmapping and Gondola the CMS I’ve been working on.

Afterwards, I was blown away by the number of compliments I received. A few people told me they thought my talk was the best of the bunch which was really encouraging. To everyone that reached out, all I can say is thanks; it meant a lot. I’m inspired to carve out some more time to blog about the things I’m working on, specifically Django admin customization and jQuery.

Well ...

View comments View full post

Managing Django Projects on Your Server with Style

Posted August 28, 2008. Filed under django

This article is outdated, you’ll find an updated article here.

A friend is in the process of setting up a new slice at everbody’s favorite VPS provider Slicehost and asked for some advice. I use MySQL, Nginx & Apache/mod_wsgi on Ubuntu to serve Django. I think Slicehost’s Articles are awesome and a great place to get help you get everything installed and running, so for this article, I’ll focus on some personal preferences regarding directory structure and repo management.

One of the biggest difficulties I’ve had to tackle lately is the rapid progress of Django. I have a number of client sites hosted on my slice and have had to freeze them at certain times when backwards incompatible changes come along. My original approach made this really messy, because I only accounted for having one copy of any given third party repo, symlinked from /usr/local/src to my Python site-packages directory. My new approach ...

View comments View full post

Building a Community Site with Django in 40 Hours or Less

Posted July 20, 2008. Filed under django, trailmapping

All the recent hub bub about 1 week and 1 day application development, motivated me to see how quickly I could launch a website for myself. I, like many developers, struggle with building and releasing personal sites. Ask a web developer and they’re likely to tell you about a couple of sites they started and never finished. Time is always an issue, but the bigger problems are striving for perfection prior to launch and always holding out for that one “killer” feature. As time goes on, interest in the project wanes until it finally gets shelved.

The Plan

Prior to development, I set a few goals for myself:

  1. Launching quickly was priority number one. I set a goal of 3 days.
  2. Use as much existing code as possible. Even if it wasn’t a perfect fit, if it was functional, use it.
  3. Optimize later.
  4. Stop scope/feature creep at ...

View comments View full post

Django Newforms Admin Merged to Trunk

Posted July 18, 2008. Filed under django

This was a huge feat. Congrats guys! 1.0 here we come.

View comments View full post

Django for Hire

Posted June 26, 2008. Filed under company news, django

Lincoln Loop has been in “head down” mode for the last couple months. In addition to being knee deep in client projects, we have grown from a one-man development studio to a full-fledged Django development shop/consultancy. We are proud to announce that Lincoln Loop is the first (that we know of) company focusing solely on Django application development. Our development team is currently five strong and oozing with talent. Each member contributes to the community in blog posts or open source add-ons; a few of us have contributed code to Django itself. More on our dev team in the near future.

We went through the typical growing pains during the transition, but the kinks are worked out and we can officially say that we are open for business. Django projects big and small, send them our way. Our devs can handle nearly anything.

  • New Django projects based on your ...

View comments View full post

Getting RequestContext in Your Templates

Posted May 10, 2008. Filed under code, django

Lately, we’ve been taking over projects from people who began building their first site in Django, but either got in over their head or just found they didn’t have the time to continue. As I review the existing code, the first issue I typically see is using the render_to_response shortcut without including the RequestContext, preventing context processors from being used in the templates. The standard symptom is when people can’t access MEDIA_URL in their templates.

Here are a few ways to add RequestContext to your templates.

Option #1: Adding RequestContext to render_to_response

The Django documentation recommends passing RequestContext as an argument to render_to_response like this:

from django.shortcuts import render_to_response
from django.template import RequestContext

def my_view(request):
    # View code here...
    return render_to_response('my_template.html',
                              my_data_dictionary,
                              context_instance=RequestContext(request))

This works, but as you can see, it adds a fair amount of repetitive code to your views ...

View comments View full post

Google App Engine First Impressions

Posted April 8, 2008. Filed under code, django

For those of you that have been hiding under a rock for the last 12 hours, App Engine is Google’s answer to Amazon Web Services. While it is less flexible in some senses (you don’t have a complete OS at your disposal), it does provide tighter integration for web applications and even includes a (somewhat crippled) version of Django out of the box.

I’m pretty excited about this mainly because I’m not a big fan of server administration, so I took a couple hours this morning to test it out. Here are some quick notes:

The Good

The ...

View comments View full post

Reusable Django Apps and Forking

Posted April 4, 2008. Filed under code, django

One of the things that drew me towards Django was the idea of being able to create reusable applications that would sit on my PYTHONPATH instead of copied across multiple sites. Coming from WordPress, the constant security updates that required me to revisit old projects began to drive me mad.

Trouble in Paradise

With some real world Django experience under my belt, I find myself re-using apps all the time, but not how I originally expected. A fair amount of my client work comes from building content management systems, so I started out building a generic app like flatpages but more extendable and a blogging app. I dropped them in my PYTHONPATH and started adding them to INSTALLED_APPS on my projects.

Over time, they evolved and improved, but they started to handcuff me. I started thinking things like, “This would be a great feature for Project X, but it would ...

View comments View full post

Serving Django via CherryPy

Posted March 25, 2008. Filed under code, django

Download django-cpserver Now at GitHub

Background

A few months ago, I got sick of trying to deploy Django sites on my cPanel server and got a VPS at Slicehost. Thanks to SuperJared, setting up Apache/mod_python behind an Nginx frontend was a snap.

I started deploying and migrating sites to the new server and kept an eye on my server resources via Munin. I had about 10 sites running on a 1GB Slice, but the Apache processes were hogging all the RAM. Restarting Apache would bring memory usage down to around 500MB, but within a couple of hours, it would be using all my available RAM, with individual proceesses using as much as 120MB.

I started asking questions and trying different options including mod_wsgi, verifying projects weren’t in debug mode, etc. Nothing made a difference.

CherryPy to the Rescue

I came across Loic d’Anterroches’ script to run Django ...

View comments View full post

Django FormMail Clone

Posted March 14, 2008. Filed under code, django

Here’s a little nugget I just posted to Django Snippets. It emulates the behavior of an old Perl script I used way back when, FormMail.pl.

I often find myself needing to build a form whose contents get emailed to the site owner(s). This class let’s you call form.notify() on any form that is a subclass of it to have the fields ordered and sent in a plain text email to all users that are flagged as staff.

from django import newforms as forms
from django.contrib.auth.models import User
from django.contrib.sites.models import Site
from django.core.mail import send_mail

class FormMail(forms.Form):
    def notify(self):
        """
        Sends an email to all members of the staff with ordered list of fields
        and values for any form that subclasses FormMail
        """
        site_name = Site.objects.get_current().name
        form_name = self.__class__.__name__
        subject = '%s %s Submission ...

View comments View full post

Better Use of Newforms

Posted March 13, 2008. Filed under code, django

The newforms library is a huge time-saver, but when I first started using it, I still found myself writing tedious repetitve code to get it to function how I wanted. While I could get away with it on smaller sites, I recently built a site with some big forms on it and decided to improve my process.

HTML Rendering

First off, {{ form }} or {{ form.as_p }}, rarely cut it in real world apps. We need to be able to customize our forms to improve the layout or add extra information. I started using inclusion tags to render the form fields and labels. Here is my trivial inclusion tag:

@register.inclusion_tag('_display_field.html')
def display_field(field, alt_label=''):
    """
    Print HTML for a newform field. 
    Optionally, a label can be supplied that overrides the default label generated for the form.
    
    Example:
    {% display_field form.my_field "My New Label" %}
    """

    if alt_label:
        field.label = alt_label
    return { 'field ...

View comments View full post

Cash Offers Fast Site

Posted March 10, 2008. Filed under django, portfolio

We recently built and launched CashOffersFast.com. It gives people an easy, no-risk way to put their home up for sale. Pre-qualified investors can then make anonymous bids on any home listed with the site.

We worked very closely with the owner of the site to convert his concept into a working web application. From the initial concept, we identified the minimal set of features necessary for the site to function, then took an iterative approach to quickly deliver those features. This allowed the owner to use our working copy for presenting the site to potential investors while we were in the middle of the development cycle.

The site is built in Django and was designed by Derek at ashwebmedia.

View comments View full post

Lincoln Loop Version 2

Posted March 7, 2008. Filed under company news, django

I’ve been wanting to update my website for quite a while. It got to the point that I wasn’t referring people to my old site because it had become such a poor representation of what Lincoln Loop has evolved into. I’ve also been bottling up a bunch of blogging I want to do about Django for the same reasons.

I set my sights on relaunching before this weekend and my first trip to SXSW. Since I’ll probably do more industry schmoozing there than I have in all the time I’ve been freelancing, I wanted to make sure I had a site I was proud to show off. While the site is still rough around the edges, it is done enough that I am comfortable putting it into production. Once I settle back in, I’m hoping to use this site as a platform to become ...

View comments View full post

Prudential Steamboat Realty

Posted September 28, 2007. Filed under django, portfolio

A few weeks ago, I released Prudential Steamboat Realty’s new site into the wild. It is my first (but not last) large site built in Django to go live. As usual, ashwebmedia did a great job on redesigning the site and building the user interface.

Prudential gave me the opportunity to scrap their existing property search and build a new one from the ground up. When I’d used local real estate searches in the past, I found them to be pretty poor from a design and user interface standpoint. I took my insight as an end-user along with Prudential’s input to create a more pleasant search experience for their visitors. The initial feedback we have received has been very positive.

In order to keep the search easy to use while still giving “power-users” access to lots of options, I used quite a bit of unobtrusive JavaScript (via ...

View comments View full post

Goodbye WordPress, I'm Leaving You

Posted August 31, 2007. Filed under django, wordpress

WordPress, you seemed perfect at first. You saved me lots of development time, seemed to have a plugin for everything I needed, and a user interface that was easy for anybody to use.

The honeymoon has worn off though. It seems more and more that while you come close, you and your plugins rarely meet my needs. I’ve wasted countless hours fighting to make you do things you just weren’t built to do.

And then there were the upgrades, oh the upgrades. It seemed like every other week I needed to install a new upgrade to make sure you were safe. With every upgrade, I had to make sure the countless plugins you required were all compatible. It all just feels like wasted time now.

I’ve been seeing someone else for a few months now and while it seemed like a harmless fling at first, it has ...

View comments View full post