- 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?
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.
- 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.
- 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.
- 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.