Most readers of this blog would be interested in the technical details of the site.
Automatic Blog Machine is a django application hosted on Amazon’s cloud infrastructure. The project has evolved over several years various scripts that I had been using to personally manage some of my websites.
There were a number of pain points in the development and lessons learned.
The most difficult part of the coding was integrating with PayPal. It was also probably one of the more innovative parts from a sales/marketing perspective. I used the django-paypal app to handle the dirty work but it was really the signup process that I thought worked out really well.
For signups the sales page presents an account creation form. This form will create an inactive user account and then redirects the user to the paypal site to complete the purchase. When they finish the purchase paypal sends an ipn POST request back to the site which activates the account. This allows me to create some commitment and consistency in the buying process which should (in theory) boost conversions.
PayPal’s API is a bit of a mess and testing it is somewhat difficult. I’m looking forward to seeing what the guys at Stripe have to offer to compete.
There were a few weeks during development after I ramped up the number of sites that were being managed where the entire website was deathly slow. Because there are a number of python processes that are scheduled to run through cron it wasn’t easy to see which job was causing the bottleneck.
Eventually I discovered that one of the major cuprits was the use of print statements in the code. A lot of the older code was logging with prints to standard out and then redirecting to a file. This was good enough when they were a lot simpler and I was running them manually from the commandline. Switching to use python logging made a massive difference.
The coding, thanks to Python and Django took almost no time.
Because I was the only developer on this project I was able to work in a way that probably wouldn’t work well for a team.
All the code I was working on was kept in a DropBox folder – this allowed me to have access to the latest changes across all the computers I might use.
I used Fabric to deploy both the code and the media files. Static media files were hosted on Amazon S3. The code was committed to a private code repository on bitbucket and then remotely pulled to the server. This seemed to workout really well and made deployments very easy and quick to do.
Virtualenv and pip also were a great help for managing the libraries and python versions across the computers I have.
Don’t forget about some of the nice things that users need. Just an hour after launch I realized that I wasn’t sending welcome emails and I was hiding the link to the login page. So the first few people I had to manually send them a message for how to login. Somewhat embarrassing.
Spend some time thinking about how best to organize the templates. As the project I started to find I was doing a lot more copy/paste and it resulted in some minor bugs where pages had missing links. And resulted in having probably a few more files than were really necessary for base templates that were 90% identical.
Much of the work done on this happens in scripts that are scheduled to run – there’s no webpage getting hit so errors are not visible when going through the site. It was really helpful to have those scripts set up so that errors created emails with stack traces – that allowed me to quickly track down some lingering problems.
Definitely would recommend using python and django to anyone doing web application projects. It’s really a pleasure to use. As a developer though I totally underestimated the time it takes to get the UI just right, and think of all the various pages and emails that are required to go out.