Developing Great Software

Sunday, November 28, 2010

I-Emote on Google AppEngine

I-Emote is a social Web application I am writing that allows users to create posts that can be associated with Web based content such as other Web sites and YouTube videos. Members can add their own comments and indicate they 'like' a post or comment.

Each member has their own profile page on which other members may view their latest posts as well as any personal information the member wishes to share. Profile pages also provide the means to subscribe to members' posts as well as unsubscribing.

When I set out to write I-Emote I did so as an academic study of what it takes to create a social Web site as well as target Google's cloud infrastructure - App Engine - and as such it is a work in progress; there are numerous features that it still lacks and that I am eager to implement such as email and SMS notifications, general message broadcasting and more member-centric features such as picture albums. I will eventually fill in the gaps as time permits. I intend to use what I have learned about writing a social Web site in other projects that I am and will be working on to provide them with some light weight social Web features such as commenting, fan-out and profile pages.

Below are a few screen shots that I hope you find interesting:

Thursday, November 18, 2010

Screenshots of Love My Vehicle On The Web

A number of years back I had written a desktop software package for tracking and managing the maintenance of vehicles and it was called Love My Vehicle. The software was well received and it managed to attract a rather large & loyal following of paid customers and had won numerous awards from various software rating groups as well as user groups. The application was written for Windows using Microsoft C++ and the MFC framework.

Many things have changed since I originally wrote that package. Most noticeably, the Web has become the preferred target for delivering services and value to customers. The Web's influence can be said to have changed the landscape of application development and delivery. Cloud based Web services have also contributed to the changing landscape by offering software developers the opportunity to deliver services to their customers without the need to invest in infrastructure and by also providing solutions for wide scalability and resiliency. Numerous cloud options now exist including Amazon's EC2 and Google's App Engine for which I have written numerous applications .

About six months ago one of my customers contacted me about migrating her licenses for Love My Vehicle to new computers her company had purchased. Unfortunately, I wasn't able to offer her any assistance because I had lost the source code to the application a few years back (which could serve as the subject for its own article). As a result I decided to create a modern version of the software targeting, of course, the Web and the cloud and as I already had practical hands on experience with App Engine I opted to target Google's cloud.

One of the early lesson I learned about targeting App Engine is that Google's limit on the amount of time allotted to each HTTP request severely limits what I can and cannot do on their servers. I learned that the best approach was to limit each request to retrieving and updating data only and to do all HTML rendering on the browser using Ajax and DOM manipulation. The added benefit of this approach is the RIA experience for the user.

The applications I already have written for App Engine all use Java and Groovy on the servers for processing Ajax requests and jQuery on the browser for DOM manipulation. The shortcoming to this approach is that client side development tends to be tedious and you lose the benefits provided by compilers and IDEs, especially catching coding errors early and code refactoring. I wondered what other options I had that would offer the same set of resources on the client that I had become accustomed to having on the server side of development. Enter Google's GWT.

GWT is Google's pure Java approach for developing rich internet applications (RIA) and it uses a novel approach of compiling Swing like Java code to native Javascript targeting IE, FF, Chrome and the Safari browsers. Using GWT lets you develop both your servlets and client side code in Java without having to give up your favorite IDE which in my case is Eclipse.

In the course of two months and coding in my spare time I have manged to be very productive using GWT. After studying and learning its "ins and outs" I have already managed to put together a nice little prototype of Love My Vehicle running on Google's App Engine cloud. This isn't a clone of the older application but rather a complete rewrite with new features and of course, Web based. Here's the link: Though early in its life cycle and sans source code for the original product, I am applying my knowledge of the original software's functionality to build out the new product which will support the popular 'freemium' subscription model. 

As I progress in adding and refining functionality I will post updates here. I also intend to write new articles specifically relating to its development that will also include GWT and App Engine.

Screen shots of early prototype

Updated 11/27/2010

Since posting the original article I've made numerous changes to some of the views and I've also implemented a couple of new views, all of which are included below. But first, allow me to make a few obvious but none the less important observations about application development in general.

One of the keys to successful development IMHO is the constant refinement of concepts and ideas. No matter how good a first implementation is there is always room for improvement. As concepts and ideas materialize and as the complexity of the application increases it is very important to review your implementations frequently, looking for ways to improve them. In addition, as development progresses you can sometimes find that you need to reuse an implementation but in its current state it is tightly bound to a single point of use.

IDE refactoring support makes this repetitive cycle of coding and refinement manageable and Eclipse, my preferred choice of IDE, shines in this area saving me literally hours compared to what it would have taken me to manually make all the modifications up to this point.

So, if your current IDE doesn't shine in its refactoring support look to upgrade to a better IDE. JetBrains, Eclipse and Netbeans all provide excellent support for refactoring code and of the 3 only JetBrains requires a paid license for non open source projects.

With that little tidbit out of the way here are the screen shots I promised:

Screen shots of modified views from early prototype

Screen shots of recently added views from early prototype

Updated 12/5/2010

Since my last update I've done a lot more refactoring, made some improvements and changes to the the existing views, implemented the Parts, Fluids and Suppliers views and I've added one new view, Notifications, to the Manage sub menu. The data displayed in the following screen shots is bogus of course and is for testing purposes only, mainly to verify that my sorting routines are working correctly. Screen shots follow:

Updated 12/19/2010

Complex Web 2.0 pages are highly dynamic and require a lot of DOM manipulation for adding, removing, hiding and showing page elements in response to the user's actions; that's how they mimic desktop applications providing a similar rich user experience.

Love My Vehicle's Misc. Purchases View is one such example of a complex, highly dynamic page that responds to the user's actions by manipulating the DOM accordingly. The view supports the display of a document non editing view of a purchase which has numerous areas on which the user can click on to manipulate such purchase related items as purchase line items and sales tax.

For example, when the user clicks the Add Purchase Item button DOM manipulation is used to display an editor that allows the input of a purchase item. The user can save their input by clicking the editor's Save Purchase Item button or they can cancel the operation by clicking the editor's Cancel button. If they click the Save Purchase Item button the information they entered is first validated and if it is valid the DOM is again manipulated to display a document non editing view of the line item entry. If the information fails validation then the line item editor displays an error message which provides feedback to the user prompting them to correct the data.

The same line item editor also supports editing of an existing purchase line item which would be the case if the user is editing an existing purchase or a line item they previously entered in a new purchase.

Sales tax works similarly to the purchase line item editor supporting both a document non editing view and an editing view.

Whenever the users saves their data in either the line item editor or the sales tax editor the page recalculates the net and gross amounts for the purchase.

In the coming weeks I intend to publish an article dedicated to my approach to developing these types of highly dynamic pages and of course I will focus on using GWT to implement them. It is possible that this will be a multi part article as the topic requires a lot of detail and I think would be easier to consume if it wasn't all tossed out at you at one time.

I have added some screen shots below of the views that I described above as well as a screen shot of the Purchase view which shows a list of all purchases as well as showing a document view of the selected purchase.

I hope you have found this latest update interesting and as always, feel free to provide your feedback.

Have a very happy holiday and new year.

Updated 12/19/2010

In real life one rarely gets the opportunity to do things over but software development is an exception. After implementing the Purchase views I realized that I had failed to provide the user with a report view of a purchase. What do I mean when I say a report view? A report view is any view of data that when viewed looks like a well laid out report and as close to the real life document that it is supposed to represent. An invoice is an example of a report view with a header, line items, and a summary. A purchase is also an example and is very similar to an invoice in that it also has a header, line items and a summary.

Business applications, which Love My Vehicle really is when you get down to it, usually have to provide a lot of report views and implementing them is often time consuming because of the detail required to get the views to look like real documents. I made two passes at implementing the Purchase report view, one using a div only approach and one using tables. In the end I chose the tables approach because it was more straight forward and it allowed me to use GWT's excellent support for table row and cell generation.

The following is a screen shot of a Purchase report view. Besides providing the user with a report view of what a Purchase document should look like, it also provides the user with the ability to edit and delete the backing purchase data:

Wednesday, February 3, 2010

"Hey Larry"

As you probably know, Oracle has begun its consolidation of the assets it has obtained from its purchase of Sun Microsystems. Yesterday I received an email notifying me that Oracle has pulled the plug on You can interpret this as you see fit but in my opinion this is a mistake for a number of reasons, not least of which is the message it sends to developers.

So "Hey Larry" will be my channel for commenting on both the good and the not so good steps that Oracle takes in regard to those Sun assets which we developers have come to rely on. To start things off, here's the first "Hey Larry" entry...


Hey Larry,
I just heard that you are shutting down Why? You don't think it is an asset for developers to have a service as a resource? You don't value the good will a resource like generates with your developer community? What else are you going to "shutdown"? Netbeans, MySql, Java,, etc.? I was enthusiastic about the Oracle/Sun deal but I feared something like this would result. I guess my fears were justified. Hey Larry ... don't be a jerk with your developer community. It might come back to haunt ya!


Hey Larry,
I like what I heard in this web cast, especially what you are promising for Netbeans and Keeping the Netbeans devevelopment team intact is smart as is sharing between the 3 IDE platform groups

Hey Larry,
I just read your clarification regarding your plans for (see below) which I received yesterday. This will, I am sure, be very well received by your developer community. I can hear their collective sigh of relief. It doesn't matter why the 180 on but my naturally curious nature tells me that the negative reaction to your original announcement played 'something' of a role. That you listened and reevaluated and came to what can only be called a very smart decision demonstrates a resolve to embrace your developer community. Good move!

In an effort to get information out to the Kenai community quickly, while trying to manage the integration of our two companies, I think we did a poor job at communicating our plans for to you. I would like to remedy that now.

Our strategy is simple. We don't believe it makes sense to continue investing in multiple hosted development sites that are basically doing the same thing. Our plan is to shut down and focus our efforts on as the hosted development community.

We are in the process of migrating to the kenai technology. This means that any project currently hosted on will be able to continue as you are on We are still working out the technical details, but the goal is to make this migration as seamless as possible for the current projects.

So in the meantime I suggest that you stay put on and let us work through the details and get back to you later this month.

Thanks for your feedback and patience.

-Ted Farrell
Oracle Corporation
Hey Larry,
Congratulations on winning back America's Cup. Outstanding!

Saturday, January 9, 2010

Grails On The Google's App Engine - Grope... bump... ouch!

I thought I'd comment on some of my experiences using Grails on Google's App Engine. I am new to the App Engine and it is quite different from the typical environment provided by Java web servers. For example, it only provides limited Java support and there is no SQL database, only BigTable. Poor or missing documentation just compounds the difficulty. It is like feeling your way around in the dark - there are a lot of things you are going to bump in to. So occasionally I will update my 'bumps' here and maybe save you some of the bruises.

Yesterday, for example, I hit a snag building an application running the grails command app-engine. This was a new problem. The app had been built and run successfully prior to this. The only difference is that I added a new domain class, a new controller and a few new views to support the new domain class to the project. The ant task that the Google App Engine SDK provides in the file config\user\ant-macros.xml was blowing up in the Datanucleus Enhancement phase because the parameter it created to feed to the enhancer included all the classes in the war and its length exceeded the max path length allowed by Windows. I finally got around the problem by modifying the ant script to only include the application's domain objects and I was able to build and run the project again. The problem here is that this isn't documented and it literally took me hours to find a blog post that provided the solution.

By the way, my environment is set up to use Grails 1.1.1 and not the latest 1.2 because the app-engine plugin doesn't yet support it. I am using GORM-Jpa as well.

GORM-Jpa plugin is another point of frustration. It claims to provide dynamic finder support but in reality it only provides a very limited subset. The experience of determining what finders it actually supports is again like groping around in the dark. What I have learned so far is to limit my queries with .findWhere queries which suffice for a majority of my queries. For fringe cases I have also resorted to JPQL which I was happy to find that GORM-Jpa supports. These take the form of <DomainObject>.findAll("SELECT o FROM <DomainObject> o WHERE o.x like :search",[search:'a%'] as an example. Again, no documentation and this discovery took considerable trial and error until I got it to work.

Developing for the App Engine with Grails is very fragile. A lot of things that you just take for granted in Grails just do not work or work differently. This is in part due to the immaturity of the Java App Engine api as well as Grails App Engine support. I hope to see both mature rapidly :) And thank heavens for Netbeans' Grails support. I'd have gotten nowhere fast if it weren't for Netbeans' ability to debug Grails apps.
So, if you have any gems you'd care to share on Grails on Google App Engine please do it here. It might save me and many others some bruises as well. And, likewise, I will share with you what I learn as I grope my way around in the darkness of Grails and Google App Engine.

Grope... bump... ouch! Grope... bump... ouch! ...

2/16/2010 Update

I probably should have posted this sooner but I have given up with Grail on AppEngine and switched to Gaelyk which was purposely designed to be light weight and run on top of Google's AppEngine. It doesn't have all the bells and wistles that Grails has but you really don't need them for AppEngine. JDO/JPA just gets in the way and really doesn't fit with the BigTable database so why use it. Gaelyk comes with some very nice wrappers for Google's cloud apis and are extremely easy to work with. Startup times for Grails apps on AppEngine are horrendous and unacceptable whereas Gaelyk apps don't suffer the same startup latency. And the best thing about Gaelyk is that it is Groovy which means you still have access to litterally thousands of open source libraries at your disposal. Grails on AppEngine is like trying to run a Rolls Royce in a Nascar race where Gaelyk on AppEngine is like a speedy agile little sports car. Gaelyk support is fantastic. Guillaume Laforge, who is the Groovy project manager and head of groovy development at SpringSource is one of Gaelyk's primary developers. He is very committed to the project and I have found him to be extremely responsive to emails posted on the Gaelyk users group.

So the bottom lines my friends is this, if you are writing an app for a typical servelet environment then go with Grails. It is a fabulous framework. But forget about it on AppEngine, it just doesn't fit.

About Me

My photo
New York, NY, United States
Software Developer