She turned me into a Gnewt! I got better…

This is a project I’ve been working on for the past week or so. It’s live now, and I wanted to share the codebase. This post is more or less exactly the README from the GitHub repo bhs_sales, so head there if you want to get right to it.

Intro

The BHS Class of 2014 needs some money for prom. We came up with the idea of selling senior shirts as a fundraiser, but the process for organizing an order for ~300 people is incredibly complex and comes with the headaches of having to lend money to make an order, collecting money afterward, over-ordering, etc.

This is our solution: a Stripe-based marketplace to preorder shirts. This lets us record the name/size/selection of everyone who wants a shirt, and then aggregate that data later. Payments are processed through Stripe.

Technical Stuff

This is a Django project. It currently only has one application, “shirts.” Data is stored by default in SQLite, but that can be changed easily. Database migrations are handled through South.

I have included some deployment scripts, namely:

• Makefile
  • Provides automated deployment, but will require changing of paths
• hup_bhssales
  • Used in my git post-receive hook to restart the server process automatically when I push new changes to production
• bin/gunicorn_start
  • The script called by supervisord to start gunicorn — will also require changing of paths for custom deployment

Supervisor keeps a gunicorn instance running with a socket in /tmp. I have set up nginx to proxy_pass to that socket, more or less just like any other Django project.

Architecture

There are only two models. 1. StoreItem contains a name/description/summary/price of a certain item 2. Order contains the name of the customer, a timestamp, the purchase price (in case the price in the future changes), and the Stripe ID of the charge. The Stripe ID is optional — I’ve allowed a separate “in person” payment type.

When the order form is submitted, /charge will use the Stripe Checkout token to attempt to make the charge through Stripe. If it’s successful, an Order instance will be saved and the user redirected to a confirmation page. A public list of all orders is included.

The sizes are stored as a constant in shirts/models.py. I’m not sure this is the best way to do it.

Configuration

I have included my Dev configuration. I manage configurations using django-configurations. You’ll notice the end of settings.py tries to import all from local_settings.py. You’ll need to create a local_settings.py in the same format as settings.py, containing a:

class Production(Configuration):

Put your live Stripe keys in that configuration, without committing it to Git.

Also, run this in a venv. A requirements.txt is included.

Just something I found and thought was kind of cool. I’m currently working on a project that uses Django for its frontend, but eventually passes the user to a JavaScript frontend that talks to the Node.js / Redis backend with Socket.IO. I needed a way to store data in Redis whenever a specific Django model was saved. I looked up ‘Django + redis’ beforehand, but the existing projects seem to be mostly cache-oriented, and as far as I know Django doesn’t have a standard adapter for Redis. No worries — it’s all Python!

Django signals let you execute functions whenever a signal is emitted, but specifically in my case, when a model is saved. You can put your signals code anywhere, but I like to make a ‘signals.py’ in the app directory and then just add the line ‘import signals’ to the app’s __init__.py. I subscribed to the Django model saved and model deleted signals with functions that connect to Redis and add some of the relevant data to a hash. Hashes in Redis are very much like dicts in Python, and Andy McCurdy’s redis-py library allows you to pass dicts directly to the hmset function.

Here’s the relevant code (adapted for the example) in signals.py:

import redis
from django.db.models.signals import post_save, post_delete
from django.dispatch import receiver
from yourapp.models import YourModel

@receiver(post_save, sender=YourModel, dispatch_uid="yourmodel_create")
def addYourModelToRedis(sender, instance, **kwargs):
	r = redis.StrictRedis(host='localhost', port=6379, db=0)
	yourmodel_dict = {
		'uid': instance.user.id,
		'number1': instance.number_1,
		'number2': instance.number_2,
		'status': instance.status
	}
	r.hmset('yourmodel:' + instance.uniqueKey, yourmodel_dict)

@receiver(post_delete, sender=YourModel, dispatch_uid="yourmodel_delete")
def removeYourModelFromRedis(sender, instance, **kwargs):
	r = redis.StrictRedis(host='localhost', port=6379, db=0)
	r.delete('yourmodel:' + instance.uniqueKey)

The “dispatch_uid” parameter passed to the receiver decorator is intended to keep the signal from being acted upon more than once per save/deletion of a model. All the Django documentation says is to use a unique string; they don’t recommend that you use a specific format and it doesn’t seem to matter as long as it’s unique. Another thing to note is that the ‘instance’ parameter for my handler functions is specific to the post_save and post_delete signals. In general signal handlers are expected to take “sender” and “**kwargs.” However it’s safe to extract the ‘instance’ variable from **kwargs in the function definition when only being used for these specific signals. More information about signals and handling signals can be found in the Django documentation.