Software Language Roadmap

As many of you heard that Oracle is the process of purchasing Sun Microsystems (Sun) and many techies like myself are weary on what will ever happen to current IT standard technologies like Solaris OS, SPARC workstations, MySQL relational databases and most important to the Java Software language. Sun did a good job of maintaining the Java language which inturn has matured and is currently quite popular in the development community. I have to give kuddos to Sun where the language matured from a bulky and clunky language with Enterprise Java Beans (EJBs) to a more streamlined software language which has be refined to a fine consistency. I, however, think that the Java has reached its pinnacle and now it will slowly fade in the mist where other legacy buddies like COBOL, FORTRAN, PASCAL, LISP, etc, etc are waiting for it.

If you are a Chief Technology Officier (CTO) of any mid to large size enterprise, it is time to ask your planners to hash out a Software Language Roadmap which should address the following:

• What sorts of languages will peak in the next 2 years, 5 years and possible 10 years?
• What sorts of infrastructure will be needed to maintain applications with these languages?
• What will the cost of development of these applications?
• Will it impact current applications?

Enabling the IT component of business with Service Oriented Architecture (SOA) was promising since it offered a closer alignment to business processes, and the wonderful level of flexibility. Unfortunately flexibility brings numerous levels of abstraction and system integrators working with process analysts to develop these flexible services. During the enabling process, enterprises have realized that there is a cost associated to the degree of flexibility. Is flexibility worth the price? Next came the promise of Web 2.0! Web 1.0 allowed users to discover information using Web. Web 2.0 allows users to discover information and aggregate information for their personal uses. It also allowed users to disseminate their perspectives on the information (kinda like this blog). Enterprises see the promise however they are leary in giving their users the power to disseminate information with their perspectives across their networks. Currently businesses regulate their users on when and where they can blog if the users are allowed to blog. Currently the most promising thing Web 2.0 component in the business community is the Wiki. Wikis are usually viewed as organic knowledge bases which are maintained by the users. I personally don't see Blogs and Social Networks (sorry ASpace!) won't take off in an enterprise. So back to the drawing board and we need to ask ourselves, "What next?" As a developer and as an architect, I believe application development will be done in scripting languages like Ruby and Grails. They follow the concept that it takes alot less time to modify a baselined application then to build one from scratch. These languages also imply that these baselined applications have the right architectural foundations like built with design patterns, and loose coupling. They are script based language which allows developers to save alot time by skipping on the compile step. They also provide unit-testing capabilities. I have worked with Groovy on Grails quite a bit and I really like it. I am still learning Ruby. I also see close source companies like Microsoft and Adobe following this paradigm in their new ActionScript or .net specs. Every executive asks about security vulnerabilities with these languages and security is addressed as these languages mature. I wouldn't ask my developers to build my business applications in Groovy on Grails or on Ruby on Rails yet since they are still new but I would start drafting my java exit strategies. Don't let your enterprise get lost but plan your roadmap and stick to it.

Driving a Ferrari and getting Screwy with Groovy!!!

For the last few days, I have been trying to clean up and write new functionality for an existing e-commerce web site which has been written in Groovy on Grails. When I first played with Groovy on Grails, I was amazed at the simplicity at how straight forward web application are amazed. It like getting into a Ferrari, starting the ignition, release the hand brake, hit the gas pedal and let it fly. As you are driving the Ferrari, you realize that you don't know how to turn the Ferrari at 120 mph or do a donut in the snow in it. You then slow down the car and slowly get to know the car. You appreciate the contours of the car, the neat blue tooth capability and the simple ease on how the car handles. As you are appreciating and getting to know the Ferrari, you realize that you are loosing time and wonder if it is really worth it. In the end, mastering on how to drive the Ferrari is your greatest asset as far as going to new destinations.
You must be wondering how is Groovy on Grails and an expensive Ferrari are connected. The answer is that they are connected. To fully appreciate the neat features of Groovy on Grails, you have to sit with the language and get to know it over via your handy dandy IDE. Groovy on Grails may sound wonderful in the beginning however you realize that it is not that easy when you want to build custom functionality. I struggled with building form validation for fields which appear on web form but the data in these fields is not reflected in the database. Groovy on Grails may be a great language however it is like the dark ages in terms of documentation.
Anyway I figured all of my issues for this release and I also found a bug in the Groovy on Grails and a quick work around:

1. I have a UserAccount class which looks like this:

   
   class UserAccount implemments Serializable {
   
   String username
   String firstName
   Address address = new Address()
   
   static def constraints = {
   
   }
   }

2. I have a Address class which looks like this:

   
   class Address implements Serializable {
   static belongs =[user:UserAccount]
   
   String streetAddress
   String city
   
   static def constraints = {
   
   }
   
   }

3. I have a gsp file
   

I noticed that the textboxes for streetAddress and city didn't highlight in red when the textboxes had invalid data. To get around this issue, I wrote a simple JavaScript function which manually highlighted the textbox if the error message for the textbox is generated. This how ever didn't work (this is the bug). Here is what I had for highlighting the city textbox:

${hasErrors(bean: person?.address, field: 'city', 'errors')}'

This didn't work on its own and the Javascript didn't work. After spending some time with this bug, here is how I resolved:

${hasErrors(bean: person, field: 'city', 'errors')}'

This made the JavaScript to work properly. Hope it helps