Tuesday, May 19, 2009

Grails and Flex

Inspired by Christophe Coenraets' and Mark Fisher's NEJUG talk Spring and Flex Integration, I decided to try out the Flex Scaffold Plugin with Grails 1.1. This blog entry represents my findings to date:
  • Even though the plugin version is only 0.1.1, the plugin itself seems very well prepared and documented. I was able to get the example up and running with very little effort. Not bad considering at this time, I do not know much Flex.
  • The plugin makes full use of the Grails Domain objects when doing a generate, but does not seem to take advantage of the dynamic scaffolding for prototyping.
  • The current version supports a handful of widget types which correspond to Flex components. These components are the same basic functionality which is present with the standard Grails. Only the Flex implementation of input, Data tables, Tab Navigator, and auto complete is soooo much nicer.
  • The 'generate-all-flex' script places what we would normally consider controller methods {save(), list(), etc. in a Service rather than a Controller class. It seems like most of the Spring/Flex combinations work off the Service classes, but using the controller class would have been more consistent with the grails approach and would make it easier for existing applications to migrate towards Flex.
  • One very nice feature of Grails is the ability to edit screens and controllers while Jetty is running and to quickly see the results of changes. Not so using Flex and Grails. If you wish to make a change to a Flex based screen it is necessary to run the "flex-tasks" script first and then restart Jetty.

All in all, I still think Flex is cool. Grails and the Grails Flex Scaffold plugin still looks easier to work with than Spring, BlazeDS, and Flex. But it is not as easy to use as plain old Grails 1.1. I think Ezequiel Martin Apfel, the author of this plugin deserves kudos for putting together this plugin, and cannot wait to see what improvements he has in store for the future.



Sunday, January 25, 2009

It's cheaper to spend on testing!

We all hear about the value of testing. The arguments sound so convincing. Write automated tests and you can find your bugs before QA, your customers will be happy, the cost of quality will go down. But then we close the blog page or put down the book on testing, go back to work and face the time pressures to get a release out. We tell ourselves tomorrow we will create the tests. When finally we get the time, our boss says "Don't waste your time coding tests, just focus on getting your code right!" She goes on to say; "I don't have the money nor the time to let you waste your time on automated testing. We can't maintain the code we have, so how will we manage also a huge base of test scripts?"

Well let me tell you a story about how testing early could have saved the day with a certain project. The software was encountering various problems which were sporadic. Normal signal user QA could find the source of the problem.

Whenever the product was deployed to production, the customers would report all sorts of weird messages. The system admin and product owner kept saying these error messages were attributable to the vendor's product failing under load.

So JMeter was brought out of the closet and the project team proceeded to record a couple of performance test scripts. While JMeter is not a regression nor functional testing tool, it does have some rudimentary functional testing features. Those features were used to verify the correct page was getting displayed. Sure enough within a couple of hours using the response assertion and duration assertions the team found the file handle leak and re-created all of those weird error messages. They even identified a couple of functional defects which no one else had identified yet. In turns out there were a couple of functional errors which were attributable to resource synchronization. By using JMeter to put the system under load instead of normal manual or automated processes, the team was able to see where and why the application was failing when deployed to production.

In just a couple of hours the team was able to get moving again. The team had been stalled for months. Everything else had been blamed, except for the original code; operating systems, integration servers, mainframes, etc. To be fair the projec team did find problems in all of these infrastructure areas, but the biggest problem was in the code.

The cost in lost opportunity, staffing costs, and vendor support costs could have paid for a lot of test scripts. A lot of time and money was wasted. But, the good news is that there is now real support for improved testing (functional and performance). The product owner is now all excited to get more tests created and to get a copy of JMeter on his desktop. This individual is even intrigued by continuous integration. So maybe the hassle and delays were worthwhile. Our product's future can be improved.

While the saying "Test early, test often" is true; what is also true is "some testing late, is better than no testing"

Wednesday, January 7, 2009

Captcha with Grails: ReCapcha versus the Acegi Captcha Controller

On the NEJUG website I was recently forced to add Captcha and some other logic to reduce the number of garbage entries for meeting event registrations. The site was getting a huge number of bounce back emails, which caused our hosting provider and some major free emailing services to get mad at us. After doing some data foresenics I found that one cause of the problem was random looking data for email addresses and names. To get back into the good graces with both the Hosting provider and the free emailing service, something had to be done, and the first thing which came to mind was to implement one of those Captcha inputs which are appearing all over the net.

Looking to take the simplest approach to resolving this problem, and seeing that Captcha was already present with the ACEGI Grails plugin we were already using, it seemed to make sense to just use it and avoid an additional set of libraries. So I spent an evening modifying all of the public facing input pages; it looked good! Then I tried to functionally test the CAPTCHA enabled pages...Yuch! What a mistake that was. I was tempted to just go in and change the CaptchaController source so my Webtest based test could access the Captcha value in session memory. But If I did that then I would have to update the Controller each time the ACEGI Grails plugin was updated. On so many fronts that seemed like a bad idea. Over a month later, and several bugs discovered by NEJUG members because of inadequate testing :(, I decided to try the Grails ReCaptcha plugin.

For those of you unfamiliar with ReCaptcha it is a set of APIs created by Carnegie Mellon SEI to provide Captcha support for web applications. Use of the ReCaptcha APIs is free, but you do have to create an account in order to get a public and private key which are necessary to invoke the ReCaptcha service. One other important thing to note, is use of ReCaptcha will cause your application to call the ReCaptcha service which could be an issue for those of you who do not like your applications to cross domain boundaries.

Honestly, at first glance ReCaptcha looked like a waste of time. The Captcha input box looked bulky and I really did not want to put a graphic icon on my pages saying "Stop Spam, Read Books"; even if I agreed with the general idea. There was slightly more coding and HTML Tags to call. BUT...it is possible to turn off ReCaptcha for development testing!!!!!! All of a sudden ReCaptcha won the comparison between the two Grails Captcha plugins. I immediately deployed ReCaptcha for the Registration page. ReCaptcha is also ADA Section 508(c) compatible! This means you will pass an accessibility test if you use ReCaptcha instead of many of the other Captcha implementations out there. In short, ReCaptcha user experience is easier for most users for two reasons; (1) the APIs can read the Captcha code on your computer's speaker, (2) you can select a different captcha if the current displayed one is unreadable. With these two features plus testability, I was sold with ReCaptcha!

Adding ReCaptcha support to your Grails based application is as simple as following the instructions on the Grails ReCaptcha plugin home page.

In short, the steps you will need to follow are:
  • Install the Grails Captcha Plugin with the command line instruction; grails install-plugin recaptcha

  • Create a ReCaptcha account.
  • Save the private and public keys for reference and use in your application.

  • Paste the private and public keys into the ReCapchaCongfig.groovy file provided with the plugin

  • Make certain that ReCaptcha is disabled ("enabled = false")for any environment in which you plan to do any functional or controller based testing. Unless of course you just want to see view the Captcha information on your web pages.

  • Modify your controller to call ("recaptchaService.verifyAnswer()") for any save/update style method which processes HTML form input. The plugin documentation has a good example for this step.

  • Your last step is to choose a skin and add the ReCaptcha GSP Tags as supplied and documented by the plugin.