Django/PYTHONPATH gotcha

Just picking up django again after a while away and had had some problems with the following error when running 'django-admin.py runserver --settings=mysite.settings'

Error: Could not import settings 'mysite.settings' (Is it on sys.path? Does it have syntax errors?): No module named mysite.settings

Google was not my friend as all of the returned results were to do with apache config etc

Turned out I'd simply forgotten to put the current working directory (.) in the PYTHONPATH (e.g export PYTHONPATH=.:$APPENGINEPATH:$APPENGINEPATH/lib/yaml/lib:$APPENGINEPATH/lib/webob:$APPENGINEPATH/lib/ipaddr:$APPENGINEPATH/lib/fancy_urllib

) doh!

Google App Script: Experiences in Cloudland

I'm a bit of a fan of Software as a Service and Google Apps. It seems to solve a lot of problems allowing me to work with bigger building blocks and to focus on solving domain specific problems rather than writing another document storage solution or emailer service. So the announcement earlier this year of the availability of Google App Script (GAS) caught my eye. GAS is server side javascript plus a stack of libraries and which forms part of the suite of tools making up Googles Apps. My first thoughts on seeing the introductory webcast were:

• This looks powerful - it's the glue between SaaS
• How do you test drive it?
• Is it just Spreadsheets and VBA for the cloud?
• Is it a quick win with lots of pain down the line?

My experience with javascript in the past has always been with code which hacks about with the DOM in a browser or, even worse, implements business logic in the UI. I had not appreciated how elegant and powerful it can be. GAS comes with some standard libraries to do things with google apps like send email, update calenders, create documents and build sites plus some low level stuff like http fetches, parse xml, consume soap services and build UI's. All this makes it a very compelling offering and one worth a try to put it through it's paces. There is one notable omission from the libraries and that is access to the google data services which meant that there was no easily available persistence mechanism.

The project to try GAS out was a simple site inspection application where an inspector can be allocated an appointment to inspect a premises, complete an online inspection report and a reviewer can look at the completed report and make additional comments before generating a summary. This project would exercise a few of the available libraries.

There were a few false starts to do with persitence. Trying to use a spreadsheet as a relational database (doh!) and using the simple key-value store in Big Table every script gets for free were both discounted early on. Also I discovered a couple of useful SaaS applications:

• SurveyGizmo which seemed to do everything we wanted to do from a inspection report UI perspective. it does not have any workflow but does have a decent XML based API. This removed the need for us to create our own inspection report builder.
• Cloudant which offered an instance of CouchDB (a RESTful document database) which allowed us to simply use the GAS Http Fetch libraries for persistence.

The approach I used was to use a script to build and display a UI for scheduling an inspection and send an email to the inspector containing a link to the report to be completed. The UI was displayed within an iframe of a page within a dedicated google site. There were also other pages containing iframes: one which displayed a list of surveys and their status (pending, awaiting review & reviewed) and another which displayed an individual survey response.

Experiences

In a conversation with a colleague I was pointed at an excellent book by Douglas Crockford called 'Javascript: The Good Parts' which turned out to be invaluable and which completely changed my perspective on javascript. Coupled with this I had also recently attended Software Craftsmanship 2010 at Bletchley Park during which I had attended a session entitled Understand a language better – Test Drive your own Unit Testing Framework by Michael Hunger which was a real eye opener for me and answered one of my original questions (Q: How do I test drive this, A: By writing the gasUnit test framework!). Reading the book, writing the test framework and using the excellent jslint all together made me feel much more comfortable coding and resulted in tested code with clear separation of concerns using MVC.

Despite my enthusiasm for javascript as a language I had a number of problems with the GAS:

UI libraries

• These are a scripting layer on top of the GWT and allow you to programatically build UI's.
• It is marked as experimental and it is not a full implementation of all the features of GWT. For instance styling seemed a little clunky and there was no way of rendering pure html.
• Both IE and FireFox threw errors for some of my scripts which rendered OK in Chrome - this is very worrying since one of the purposes of using GWT is to remove concerns about cross browser compatability.
• Pages also took an age to render (presumably because of the rendering javascript download and execution) but once loaded the interaction with the page was very responsive
• The page source looked as ugly as sin but have you looked at the page source for the google home page recently!
• I think some of my problems were more to do with the change in mindset from pages and http post/get to one based around an ajax based web application.

General

• Each script needs to be stand alone so it is not easy to reuse code. For example, in order to reuse the test framework code in each script I placed the framework in a Google Code SVN repository and pulled in the file using a fetch + eval. This worked OK but is not ideal, probably hinders performance and is considered evil by jslint.
• The script editor was amazing considering it is a browser based application. It seemed to cope with intermittent networks OK, recovered code following disconnects, was very responsive on a good network and produced a very fast red-green-refactor cycle when doing TDD. Debugging required tracing using the Logger library which worked OK. Refactoring and navigation is very primitive. The revision history for a script is not a full history (~ last 20) so is of limited value when making frequent changes.
• There doesn't seem to be a very active community - I posted a couple of general questions (well phrased I hope!) which were never answered.

All in all GAS worked very well. The UI library is still very beta and we decided not to use it as a solution at this point but will return to it at some point. It was a great tool for quickly prototyping a workflow without having to worry about servers or deployment. I still have some concerns about integrating this into a managed source control, build and release process - I don't want to be part of a 'deploy and fix' hackfest.

There will be a separate post on my experiences of javascript and of developing gasUnit.