Blog

We’ve been working on a bulk uploader tool for our online and live auction products. This provides a really convenient way to upload lots en-masse  from a spreadsheet as well as providing a way to bulk manage images for the lots.

We’ve put together a video which demonstrates the following features:

• Importing and uploading multiple lots from a spreadsheet up to the online auction website
• Editing lots within the bulk uploader – changing description text, lot titles, allocating auctions, categories and changing reserves, opening bids and increments.
• Managing individual images for each lot – adding and removing
• Drag and drop images from the desktop to individual lots.
• Auto-allocating images to individual lots.
• Auto allocating of images from the desktop to the entire auction en-masse.

If you wish to find out more about the bulk uploader then please do get in touch with us.

Virtualenv is one of several tools that all good Python developers should know. It lets you run several Python applications side-by-side, each with their own Python libraries installed. That’s a godsend when you have several projects running on the same server, that update at different rates. It also means you know you are free to upgrade the libraries for one project, without having to worry about backwards incompatible changes breaking otherwise unrelated projects. In short it helps keep you sane!

Since mod_python has become inactive, mod_wsgi is the preferred way to get a Django site running under Apache. With mod_wsgi you have a .wsgi file to run the app. It’s just regular Python, with a different file extension. This means it’s easy to use virtualenv with a Django site running with mod_wsgi.

I tend to create a virtualenv inside the main folder of my projects:

    $ cd my-django-project
    $ virtualenv --no-site-packages .

This creates the folders bin, lib (as well as a few others).

Starting with the notes on Virtual Environments on the mod_wsgi wiki, my generic .wsgi file searches in the lib folder for the virtualenv’s site-packages and adds it to the Python path. In this way no hard-coded/absolute paths are needed. As long as the virtualenv is setup in the same manor this .wsgi should work:

import os
import site
import sys

# Remember original sys.path.
prev_sys_path = list(sys.path) 

# we add currently directory to path and change to it
pwd = os.path.dirname(os.path.abspath(__file__))
os.chdir(pwd)
sys.path = [pwd] + sys.path

# find the site-packages within the local virtualenv
for python_dir in os.listdir('lib'):
    site_packages_dir = os.path.join('lib', python_dir, 'site-packages')
    if os.path.exists(site_packages_dir):
        site.addsitedir(os.path.abspath(site_packages_dir))

# Reorder sys.path so new directories at the front.
new_sys_path = []
for item in list(sys.path):
    if item not in prev_sys_path:
        new_sys_path.append(item)
        sys.path.remove(item)
sys.path[:0] = new_sys_path

# now start django
from django.core.handlers.wsgi import WSGIHandler
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
application = WSGIHandler()

This also means you can use the same file for a staging environment or a local Apache dev server. Anyway thought it was something useful to share.

Following on from our announcement that we have put together an demonstration site for our live internet auction webcasting software, we have now put together a video screencast demonstrating how the auction software works.

You can see the video here:

The video takes you through the key functional areas of the platform showing how the following work:

1. How the online bidder makes bids in the platform.
2. How the auction house backroom staff transcribe bids from the live auctioneer in to the auction platform.
3. How the auction admin staff proxy the bids from the online bidders to the auctioneer through confirming them on the scribe console.
4. How lots are ended.
5. A explanation of how the real time messaging system can be used to make system wide announcements.
6. How the users can ask auction house staff questions, and then how the auction staff can post private answers to thopse questions.
7. How to suspend bidding.

We have found that this helps provide a definitive display of how our software operates. Whilst users would usually use one side of the system rather than the other this interleaved approach illustrates the actual process as an auction progresses. In the future we will be putting more video screencasts together on our auction software You Tube channel, so please check back later for more.

Part of the benefit of using the web framework Django is the plethora of apps and code available for it. The core Django framework is stable, well written and well documented, but just as importantly has an active community.

We’ve been doing more Django development at Sensible Development of late and decided it’s time to try and give back to the Django community. So we are open-sourcing two Django apps. One app (django-publish) is for adding a “publisher workflow” to Django. It’s been quietly available on github for a while. However it’s the second app that will be discussed here.

Django Sendfile is a very simple app. It has a small focus – to make serving large files in Django easier.

Generally speaking in Django it is recommended to offload the serving of media files to the webserver (e.g. Apache). This frees up Django from doing such mundane work. However this also means that Django can’t get involved. We can’t check permissions from a database for example. So if we have had some large PDF files that we only want to make available to people who have logged, then it is tempting to check the permissions in Django and then serve the file from Django too. This might not be too bad if the files are small, but for larger files things will start to slow down.

So wouldn’t it be great if Django could handle checking permissions, but could then hand over the actual file to the webserver to deal with? Well it’s a pretty common to want to do this, so there are several ways this can be done.

• X-Sendfile – via Lighthttpd or
• Internal redirects via mod_wsgi
• X-Accel-Redirect via ngnix

These are obviously all dependant on the server you are running, but more or less do the same thing.

During development though you don’t always want to run a full webserver. So it’s a bit annoying if you then can’t test files downloads.

If you’re a good developer you’ll have some way of abstracting this, so most of your code won’t need to know how you are handling downloads. We needed to create this abstraction and as it’s pretty simple it seemed silly not to share it with the world.

Django Sendfile provides a single function sendfile which you can use to trigger your webserver to send the contents of a file:

from sendfile import sendfile

# send myfile.pdf to user
return sendfile(request, '/home/john/myfile.pdf')

# send myfile.pdf as an attachment (with name myfile.pdf)
return sendfile(request, '/home/john/myfile.pdf', attachment=True)

# send myfile.pdf as an attachment with a different name
return sendfile(request, '/home/john/myfile.pdf', attachment=True, attachment_filename='full-name.pdf')

Your code only needs to worry about calling sendfile and then you can just configure the relevant backend as you need to. There are currently three configurable backends:

• development – just for development of course
• x-sendfile
• wsgi

It wouldn’t be hard to add a backend for nginx too and we probably will in the future.

There’s more detail in the README at the django-sendfile repository on github.

One of the things we are often asked is whether our platform can be used for broadcasting live auctions. Until very recently we have had to say no. However over the summer we were lucky enough to get the opportunity to develop feature in this direction and we have now put this all together in a live auction demonstration website.

One of the things we have found quite challenging in demonstrating this to potential customers to try and cover all bases in enough depth. So we have produced a set of slides to accompany the demo, which should very quickly show what the live auction platform can do. We have embedded the slides in this post and they are with our others slides over on Slideshare.

They key elements the slide show are as follows:

1. The key features of the live auction module
2. How the lots transition from queuing to be auctioned to live auction
3. How the auction administrator enters bids from the room in to the website
4. How the online bidders take part in the auction
5. The auctioneer console
6. Real time instant messaging between auctioneer and online bidders
7. How announcements such declaring winners and scheduling breaks can be handled.

In a nutshell the live auction module provides the tools with which auctioneers can broadcast the auction one lot at a time to bidders on their website. This means the auctioneer scribe or administrator enters the bids in to the system as the auctioneer calls them. When online bidders make bids the scribe informs the auctioneer of the bid and then approves them. This keeps the website in tune with the auction in the room.

The auction adminstrator can enter bids using the keypad and we can customise this to make it capable of using short cut buttons on the console. Once the lot is complete the admin closes the lot and brings up the next one. The online bidders then see the old lot close and the next one transition from the “Upcoming Lots” to the “Current Auction Item”. This all happens in the browser without any need for any special software or plugins.

If you wish to have a play with the demo website then have a look at the live auction website and perhaps look at the slide show which provides links and logins for the different roles – both bidder and auction scribe/admin.