Working the Code

Grails, Groovy, and the "Gotchas"

Groovy and Grails
Grails is an amazing Web application framework. It's great to see a dynamic language like Groovy executing in the JVM, leveraging APIs written in Java together with really exceptionally support for collections, due in part to Groovy's use of closures. In addition, Groovy is a language that seduces you to use Test Driven Design (TDD) - you just can't help yourself because it comes with support for unit testing and mock objects.

Grails carries over Groovy's advantages and uses the Rails paradigm of convention over configuration. Grails implementation also uses flexible, but solid, APIs for the implementation - Spring and Hibernate.

I just wrapped up an interesting project implemented in Grails. (Here comes the shameless plug - "as most projects are at The Code Works".) Now I have to say - I love using Grails. Development speed was really fast compared to a traditional JEE application. I could try out a prototype implementation of a piece of the application architecture without investing too much time - I really could develop using "throw away" code. Changes to any layer - view, controller, or domain classes were automatically compiled and deployed to the running server. I could see the effects of my changes immediately. It really was amazing to see how fast one could have a working version up and running in such a short period of time.

The Gotchas
I think Grails has a great future and while the present 1.0.1 version is good, I have found some "gotchas" that developers should be aware of until later versions of Grails resolve them.

Testing
The most disappointing gotcha is the current level of support for testing. Grails has three levels of testing - Unit, Integration, and Functional. Unit and integration testing come out of the box with Grails, while functional testing support can be added through the WebTest plug-in.

The unit testing implementation doesn't provide the "convention" part of the runtime environment. It doesn't know for example that a class named with the  "*Controller" convention should have methods and properties provided in the Grails runtime environment such as params, render, session, request, and response. The developer needs to provide a mock implementation of those runtime Controller methods.

One could be tempted to give up on unit testing and just use Grails integration testing support because the Grails development environment is so fast. Unfortunately, the start-up time for the Grails development environment is not that fast. If one were to execute a simple, single integration test, the development speed would be severely degraded. On my development machine, just the start-up of the Grails development environment took 15 seconds.

In addition, the integration test runtime does not handle for the AOP methods called before and after a Controller action is called - beforeInterceptor and afterInterceptor. (In the project I just completed I used the Aspect methods to implement client state management because the built-in state management API using WebFlows, is incomplete in the Grails 1.x version.)

Finally, the functional testing support provided by the Canoo WebTest plug-in was disappointing. The plug-in provided a 0.x version of WebTest that was too buggy to really use. In the end I used the 2.5.4 version of WebTest. I put the WebTest library in the Grails project, provided minimal integration by modifying the Grails project build.xml and  used the standard XML interface to call the API, instead of the Groovy interface.

Again, we're talking about a 1.x version of the Grails API. I feel certain that later versions will provide much better support for testing so that TDD will filter from Groovy through to Grails.

Prototype API

I was really eager to use the Prototype API for coding Javascript. It really is a great improvement over having to implement code to handle the vagaries of different browser implementations. The only gotcha here is that the integration into Grails is still a little shaky - there are some bugs in the code generated  by the Grails tags for the Ajax remote calls. In This is also the place to note that Grails 1.0.1 documentation is also incomplete or just plain wrong. I think it's time for an overhaul in the documentation.

Automatic compilation

The feature to auto-compile and deploy to a running server is great, but there are two items to be aware of. The first is that if you made a change and you don't notice any difference in the functionality of the application, it could be because the compilation failed, no change was made to the deployed application, but no notice will given, unless you set log4j debugging correctly. However, you WILL notice it the next time you try to run the application because you will get a compile error message and the server will not start-up. (At least you don't have to set the logging and then run the application to see the error!)

The second item is that auto-compile of domain classes will cause the Web application to restart, so if you have an application that utilizes the HttpSession (is there one nowadays that doesn't?), any current sessions will be lost.

Data-binding and Validation

This is truly a great feature of Grails. It is just so, so easy to bind the HttpRequest parameters to the domain classes in the controller that you'll have tears come to your eyes the first time you use it. Have a box of tissues next to you if you've been doing Web application development for a few years, you're gonna need 'em. The Grails tags to handle error presentation using the message.properties resources with easy to use i18n support are a joy too.

Here another helpful point - both data-binding and validation generate error messages that can be retrieved from the domain class, but not together! If you call for validation on a domain class that had data-binding errors, you'll lose the data-binding error messages. In my recent application, I had the controller return any data-binding error messages to the client for correction. Only after the client presented a request without data-binding errors did the controller proceed to validate the domain class according to the constraints.

Dynamic vs. static typing
Dynamic typing is bedrock of Groovy, without it, it's pretty limp. But this is definitely something that will bit you time and again in your development - believe me, I still have the bite marks from this last project to prove it! When you see a def statement in your code, make a test for it right away if you didn't have one already. Better yet, ask yourself why you have a def at all. If you don't need it, drop it.

Domain class hierarchy
Grails gives you GORM, Grails Object Relational Mapping using the Hibernate API as its base. It really cool because it's even easier to use than Hibernate's XML mapping. But here's something from my experience: GORM by default uses a Set in runtime for the hasMany relationship definition.  I strongly  recommend keeping in mind the possibility of explicitly using a List implementation. I came upon a problem when adding multiple new records to the "many" side of the domain relationship. My application had to allow the addition of multiple new records along with already existing records in the same view. A new record would have no unique id yet and if there were some data-binding or validation error in the new record fields, the error messages be difficult to relate to fields in the view. I solved it by explicitly using a List instead of the default Set. Now all records, new or existing, would have common unique id through the index in the list. I appended the list index onto the appropriate field names in the view and thereby related the view fields with the fields in the "many" domain classes.

Summary

I think Grails is a truly great Web development framework, despite its current version 1.0 issues. It's hard not to fall in love with it. I hope my experience described above will help others while they're having fun with Grails. I know I'll probably be saying in my next straight JEE Web application: "in Grails this came out of box".

References

Groovy Home

Grails Home

Spring Framework

Prototype

Canoo WebTest

Ruby

Churn or Burn - What happens to TDD at the integration testing level?

One of the tennets of Test Driven Development (link here to TDD book and articles) is making sure you have very short cycles of Test and Code cycles. There are a list of reasons why:

Short amounts of coding - smaller loss of time if code isn't used.
reveals problems earlier, less expensive to corrrect.
...
developer enthusiam

And while that seems fairly easy to do at the unit level, testing on the integration level is a whole different ballgame.
Problems at integration/system testing:
difficult to develop automated tests, causes
longer cycles
downward spiral: big damper on developer enthusiam, causes slower work time

Approaches:
TDD at system interface level before full system integration testing
Design build/deploy process first!

Use JEE applications on same server as example

TDD in the Enterprise: A supportive IDE

Test Driven Development (TDD) is a great methodology for developing applications. You work from the ground-up, designing and modifying your core classes through the code, and all the while you know nothing was broken along the way. Really fantastic. The problem is, everything else in your development environment is working against this approach. Your enterprise development typically consists of multiple development teams, a QA group, software configuration managers, system administrators, and IT budget administrators all working as harmoniously as possible, but each with different priorities and each exerting constraints upon the system architecture, development environment, and processes used to implement the application.

Over the course of my next articles regarding TDD, I'd like to suggest technologies and techniques to enable TDD despite the pressures surrounding the enterprise development group. In this article, I'll address an aspect of TDD technology missing in developer's immediate development environment - an IDE that encourages and supports TDD.

The Eclipse IDE seems like a good candidate to support TDD. A plugin could be development to support the process and views necessary to support TDD. Here is how I envision the TDD plug-in should work:

The "New TDD Project.." wizard would create for the developer an Eclipse project that includes: a unit test folder hierarchy (/test, /test/testsuites, /test/src), a default JUnit TestSuite called ProjectTestSuite, a source folder hierarchy (/src), and the default ProjectTestEnvironment (a TestEnvironment is used to determine the test classpath, JRE path, test properties, etc. that a TestSuite uses to executes its TestS.

A "New TDD Test..." Wizard to get the package and name of the Test class, Test classes it should extend, the name of the TestSuite it should belong to (ProjectTestSuite is the default), and the name of TestEnvironment to be used when the Test methods are executed. The new Test class will appear in the TDDTestEditor, with empy setup() and teardown() methods appearing.

The TDDTestEditor view performs the following:

• parse Test class source and marks referenced classes that are unknown to the TestEnvironment.


• highlight and Ctrl+? or a right click menu item upon a marked unknown class opens the "New Class" wizard.


• saving the Test class automatically compiles and executes the Test class, with the test results appearing in the TestResults view.


• saving the source class automatically compiles the source class and executes Tests associated with the source class.

The "New Test Environment..." wizard generates a TestEnvironment, containing the classpath, JRE, test properties, etc. required to execute a TestSuite.

The "New TestSuite..." wizard generates a TestSuite class including the TestS and TestEnvironment selected by the developer. If no TestEnvironment is given by the developer, than the default ProjectTestEnvironment is used.

That's it - an Eclipse plug-in that supports and encourages TDD. If you've seen an Eclipse plug-in or any other IDE that supports TDD, please let me know.

JEE Application Servers - A passing phase?

Terracotta has announced that they are putting their JVM clustering product under Open Source licensing. Clustering at the JVM level instead of the application level allows Java applications to be designed without any architectural consideration for clustering, middle-tier hardware failure, etc.

Placing their product under Open Source will likely bring wide-spread adoption considering the relative advantages. Coupling JVM level clustering with the Spring framework and other Open Source components traditionally supplied by commercial JEE Server products will place tremendous pressure upon companies like BEA.

The speed of prototype development will be greatly increased and can be done in parallel to designing the system architecture with a combination of:

• Spring to configure the business code and data tiers using only POJOs


• One of the emerging Java GUI scripting tools (such as F3, Groovy, Jython, etc)


• pen source JVM clustering

Do I sound excited? Definitely. I'm looking forward to these developments. I think companies can leverage these tools to provide even greater value to their business clients.

Here are some links for further reference:

• Spring Clustering with Terracotta


• Terracotta


• Springframework


• F3 - a Java GUI scripting tool under development at Sun and soon to be released)
  
  

Spring into Rapid Client-Server Application Prototypes

One of the great features of Spring is the ability to configure the method of accessing business code layer. This feature can be used to provide a path to earlier prototyping of the client interaction with the server (read "business code").

Spring's high configurability can allow you to develop your client-server app first as a desktop application and later migrate the business code over to an application server. Let's take a small example of how Spring let you do that.

Here's your client side code to get information about a user:

public class Main {

  ....

  public static main(String[] args) {

     ApplicationContext appContext = new ClassPathXmlApplication("spring.config.xml");

     IUserInfoService userInfoService = (IUserInfoService) appContext.getBean("UserInfoService");

     String userName = userInfoService.getName();

     String userLocation = userInfoService.getLocation();

     ....

}

In the early stages of application design, configure the Spring context to use the straight business code
POJO:

    <bean id="UserInfoService" class="com.tcwi.app.UserDetails"/>

Later, after all the system architecture requirements are understood and the server side environment is ready, it's time for the client to access the business code in EJBs on the server:

    <bean id="UserInfoService" 

        class="org.springframework.ejb.access.SimpleRemoteStatelessSessionProxyFactoryBean"

        lazy-init="true" singleton="true">

        <property name="businessInterface">

            <value>com.tcwi.app.IUserInfoService</value>

        </property>

        <property name="jndiName">

            <value>ejb/UserInfoService</value>

        </property>

        <property name="jndiTemplate">

            <ref bean="JndiTemplate"/>

        </property>

    </bean>

    <bean id="JndiTemplate" class="org.springframework.jndi.JndiTemplate" 

        lazy-init="true" singleton="true">

        <property name="environment">

            <props>

                <prop key="java.naming.factory.initial">com.some.appserver.ContextFactory</prop>

                <prop key="java.naming.provider.url">t3://localhost:7001</prop>

            </props>

        </property>

    </bean>

Without explaining any of the Spring configuration XML, notice the one great thing about this - NO changes to the client code. By making sure we use the Dependency Injection pattern, Spring took care of everything: the EJB looks like a local POJO to the client code. To accomplish this, we used the Spring API support for accessing EJBs: the remote Stateless Session EJB proxy and JndiTemplate beans to get access to the UserInfoService EJB on the server side and present it to the client as a plain local POJO.

While past the scope of this article, database access can be configured in the same way to allow for initial use of Derby and later configured to access the data from an enterprise database server.

The ramifications of a configurable business tier are truly amazing:

• Business domain objects are always coded a POJOs.


• Business code can be developed independently of the system environment they will operate in. In fact, the business code can be developed using the Test-Driven Development approach because the system architecture elements have been removed from the equation.


• Application prototyping can begin in parallel to system architecture design.


• Applications can be configured at deploy time to execute different environments without affecting any of the code. All code views objects as local objects.


• Layers of the traditional approach to JEE application design have been removed that were needed to support remote access.

Get to know Spring and let it put some flexibility back into to your application development

Links for further reading:

• Dependency Injection


• Spring Framework


• Test Driven Development


• Derby

SQL Period Workdays Calculator

Ever needed to calculate the number of workdays over a given period of time? Here's an interesting implementation of an algorithm written in SQL. Why SQL you ask? Well, it doesn't have to be in SQL. However, I'm working on a project that uses SQL to retrieve info for insertion to an html form. (Sound familiar? Yeah, like 90% of web application implementations do that!) The projects MVC consists of a controlling PHP page using a PHP class as the model for retrieving data and a Smarty template for the view. Rather than having the controller calculate the workdays and insert an additional column in the records retrieved from the model, I incorporated the workday calculation as a column into the SQL used by the model.

Pros:

1. Keeps model and controller clean - each sticks to its job and doesn't have to do any "glue" code.

2. Unlikely performance hit - after all, why should PHP date functions be any slower or faster than a database server (and why not leave performance optimization to database software that is _definitely_ optimized for performance?)

3. A technical puzzle. I searched for a complete workday calculator algorithm and didn't find one. Developing the algorithm and then implementing it in SQL was even more interest.

Cons:

1. Boy, is it hard to head-parse the SQL statement and understand it. (Fortunately, I wrote the alogrithm as text comments to help).

2. Debugging is a bit of a pain. Debugging SQL is not as intuitive as debugging code.

Here is the algorithm (Let me know if you find any errors!):

total_days - weekend_days = available_days

//which expands to:

total_days - ( (floor(total_days/7)*2) + weekend_days_in_remaining_days ) = available_days

//which expands to:

total_days - ( (floor(total_days/7)*2) + ( if (total_days - remaining_days = 0,0,if (start_day = 1,1,if (start_day + remaining_days >8,2,if (start_day+remaining_days>7,1,0))))) = available_days

Here's the SQL implementation with a start date and end date already plugged in:

SELECT SEC_TO_TIME(
(
DATEDIFF( '2006-05-30', '2006-05-01' ) +1 ) -

(

(FLOOR(

(DATEDIFF( '2006-05-30', '2006-05-01' ) +1 ) /7) *2

) +

(

IF ( (DATEDIFF( '2006-05-30', '2006-05-01' ) +1 ) -

(FLOOR((DATEDIFF( '2006-05-30', '2006-05-01' ) +1 ) /7)*7)=0,0,

IF( DAYOFWEEK( '2006-05-01' ) = 1, 1,

/*else*/ IF ( DAYOFWEEK( '2006-05-01' ) + ( (DATEDIFF( '2006-05-30', '2006-05-01' ) + 1 ) - ( (FLOOR( (DATEDIFF( '2006-05-30', '2006-05-01' ) +1 ) /7)*7) ) )>8, 2,

/*else*/ IF ( DAYOFWEEK( '2006-05-01' ) + ( (DATEDIFF( '2006-05-30', '2006-05-01' ) + 1 ) - ( (FLOOR( (DATEDIFF( '2006-05-30', '2006-05-01' ) +1 ) /7)*7) ) )>7, 1,

/*else*/ 0))))

)

)

)*8*60*60

))

)

I'd be interested in getting references on the Net to a complete algorithm that already exists.