Developing web applications in python is a pleasure because there are so many tools available, similarly testing in django is also a pleasure because it takes and builds upon standard python testing libraries.

Unit Testing

Choices

At the start there are two real choices in python unit testing; doctest or unittest.

I am not sure why but doctests always seem a little disorganised for me. I have seen them used successfully in the real world and even used them in smaller scripts but unittest is the direction chosen for p3docs.

I find them easier to maintain and I also find it useful to have a good separation between the test code and the module code, it stops me from ‘peeking’ at the code and swaying my decisions on the test code – mental blackboxing.

Getting nosey

Nose is a great way to extend unittest as projects grow, it offers several extra tricks and a few shortcuts, in my opinion it is hard to go back once you have used it.

Django testing

Django has great support for testing out of the box,but in my experience it quickly starts to fall short as projects get larger.

I already noted how much I like Nose and it is simple to integrate nose with django thanks to django-nose.  After a very short setup you can run nosetests inside or outside django.

Load Testing

Whilst p3docs is never intended to have extremely heavy loads it is always good to be aware of its’ capacity.  I recently met with a friend who suffered an accidental javascript DOS attack on his servers and had to restrict and scale accordingly.  The most interesting thing for me was how this company did not have even a basic baseline for the load they could handle. If you don’t know where you are today how can you plan for tomorrow?

P3docs does not need the complexity of a fine tool like Mechanize due to the niche market it is in at the current moment, so a great benchmarking tool is pylot.

Using this you can get a feel for how much load the default configuration can take and create a baseline for improvement.

So, when trying to do a fast image for a page on the p3docs website I always find myself reaching for the mac-only OmniGraffle. It is not perfect and it is rather expensive for what it does, but it is the fastest way that I have found to produce a good looking vector image and render it to a PNG that I have found.

If you only need a few images you can probably get away with the 14-day trial, then if you choose to use it, purchase it when the app is making money.

Some people dislike static testing (or checking as I prefer to call it). The key point is that you do not have to act on the advice these tools give you, it is enough to be aware of the output and to be sure that you have made an informed decision when you ignore it.

Developing web applications in python and django there are some obvious tools some less obvious ones, remember most of them are opinionated and they are not always right.

Below is a list of tools I use for checking.

• HTML
  • W3C validator
• Javascript
  • JSHint
• CSS
  • CSS Lint
• python
  • pep8
  • pylint
  • Clonedigger
• django
  • django-lint
• Other
  • SLOCCount

I wrap most of these in fabric tasks and use them in my build process.

Thankfully, the tools are much better now, but, it still amazes me how few businesses do it. In the past 5 years I have not worked for a company that have internationalisation already in-place in their code.

One of the things that p3docs has done is focus on internationalisation from the start, with all possible strings marked for it.

It takes a few extra lines of code but I believe it is worth it (it also becomes a habit very fast and one stops thinking about the process).

To bring this message home, I was visiting an old friend yesterday who has a successful and rapidly growing software business:

Upon arrival at his office he was working on retrofitting his applicaion with Japanese, a market he had not foreseen. Instead of just passing the language files off to a translator he was having to search the entire codebase for translation strings.

For p3docs I selected bazaar because:

• I am used to it and comfortable with it
• It is written in python so it is relatively portable and I can inspect the code if necessary
• Unlike many VCS systems it allows me to save empty directories

Setting up the development directory

Based on the assumptions.

    bzr init-repo --trees ~/Development/p3docs
    cd ~/Development/p3docs
    bzr init
    bzr ignore .DS_Store
    bzr ignore .project
    bzr ignore *.pyc
    bzr ignore *.pyo

There are many version control systems out there and most of them are free.
It does not really matter which one you choose, just choose and use one.

It occurred to me how important it is to look after your IP.
Looking after it tends to be expensive, however as a startup if we just think about evidencing it we can take a few very cost-effective steps.

Here is how I do it:

The short version:

1. Make a backup on a DVD/CD of a checkout from your version control
2. Mail it to yourself

The long version:

1. Create a backup of the development sources
   • Perform a clean checkout from your VCS of the current version.
   • Make a note of the version identifier
   • Compress and encrypt the version to save space and protect it from prying eyes
2. Create a CD/DVD
   • Copy the compressed backup to a blank CD/DVD
   • Name the CD/DVD “p3docs_backup”
   • Label the disk in permanent marker with “p3docs Backup” at the top
   • Label the disk in permanent marker with the date “yyyy/mm/dd” and version identifier”V.xxx.” at the bottom
3. Mail the CD/DVD
   • Address a padded envelope to your home/office/backup address and insert the disk
   • Write the date “yyyy/mm/dd”, the version identifier “Rev.xxx.”and your signature across the seal of the envelope
   • Apply a piece of clear tape over the seal of the envelope and the writing
   • Add a stamp.
   • Mail the package

Automating the process

Fabric Task

I use fabric to automate most of my python tasks, so a simple task in my fabfile carries out most of the steps.

env.repo_dir = '/path/to/repository/'
env.bak_dir = '/path/to/backup/'
env.pwd = 'password'
env.version = 0

@task
def ip_backup():
import os

with settings(warn_only=True):
    os.mkdir(env.bak_dir)
    local('bzr checkout {0} {1}'.format(env.repo_dir, env.bak_dir))
    with lcd(env.bak_dir):
        env.revno = local('bzr revno', capture=True)
        local('zip -r -p "{0}" {1}p3docs_backup_rev{2}.zip p3docs'.format(env.pwd,
        env.bak_dir,env.revno, capture=True)

Reminding Yourself

I like to do this once a month, so I set a reminder in my calendar to mail it, my mac sends me mail and nags me to do it.

It does not have to be the “final” name, a simple “working” name is good enough and the final name will often come out in the process.

My technique was to come up with a handful of ideas and then research them on the web to make sure that they:

• are not already in use
• are not already trademarked
• do not have bad connotations
• do not have a bad reputation now or in the past
• are available for registering

At the end of this “p3docs” stood out as a name that fulfilled the above criteria. The next stage was to register the name as a domain and to tie it to several services.

Spending the minimum amount of money was an important factor, so I made a couple of decisions:

• register the “p3docs.com” domain to secure it. My first and only investment so far, (10 Euros)
• use a free blogging site rather than setting up a dedicated server
• use a free email service rather than a dedicated email address

With this done, the final stage was to secure the identity with prominent services, setting up accounts with the username “p3docs”:

• Twitter
• Facebook
• Google
• WordPress.com (for this blog)
• Skype

The services that you register with depend on the resources you will use, or plan to use. You should grab them all now.

In the process I hope to document:

• decisions made (and eventually the outcomes)
• procedures employed (and eventually the outcomes)
• tools used
• useful snippets of code
• general thoughts on anything related to the development process

Note:

It is possible that you are reading this after the experiment has been concluded, either successfully or unsuccessfully and this site may no longer be being updated.