Recently, I had a chance to worked on a mini web application project. The application is simple, where a user can upload a file captured by one of these nifty device, iButtons, and the information are charted out similar to the OneWireViewer desktop application.
A few years back when Google first came out with GAE/P, I toyed with it a bit, writing a simple (and ugly) bulletin board application. It was a good introductory experience, and PaaS idea looks promising. Unfortunately, my *real* work project went into crunch mode and I can no longer devote my time to study Python and Django framework on GAE/P.
Then Google came up with the Java Edition of GAE, which reinvigorate my interest in PaaS. With my background in Java, GAE/J is a nature choice to build my mini web charting application.
Although GAE/J was still in "Preview-Edition", it already came with a pretty decent eclipse plugin. I still remember the early days with GAE/P where I have to memorize command-lines in order to build, compile and run the local GAE/P environment to test. With this eclipse plugin, it freed up some of my brain cells to focus on the actual application development.
Armed with a sample data file, the first thing to do is to build a parser to read-in the file and transform it into a POJO data model which can be manipulated easily. Simple enough, no issues there.
Next up was to create the upload functionality. Apache Commons fileupload comes in handy. I follow the instruction available on their website and so far so good. The functionality works seamlessly on the local GAE environment (build on Jetty). After integrating the upload functionality and the parser, I have half the application completed in a few hours.
Lastly, the charting part. With my new found love for all things Google, I gave Google Chart API a spin. The concept of Google Chart is simple and elegant. It is a REST-ful API which you supply all the input to the src attribute of the <img> tag, and viola, you get a chart image back. Elegant yes, but not without its flaw. By simply looking at the API, the inherent limitation of the design became apparent. Since the <img> tag basically using a HTTP GET command, the payload of the API is limited by the inherent length of a URL!
You know how people say "Love is Blind"? Yes it is true. Even in the nerdy world of software development. Damn Google with its slick API and sexy looking charts. It is so hard to resist! With my new found love for all things Google, I ignored my intuition and solidered on.
Another hour or two, I have a local working prototype. Time to celebrate? ... Not yet. Let's upload the application and test it on the Cloud!
Being all things new and shiny, of course it did NOT work on the actual GAE/J cloud. Upon uploading a the test file, I get a nice big:
Internal Server Error
To be continued ...