This really isn't a Grails and Groovy topic, but thought I should pass it along. Justin Grammens has started a group for mobile phone development. This is what he said in a recent email:

Hey Bill,
I'm very enthused about mobile and the possibilities for applications and usefulness in the future! I'm very glad that you made the presentation and were able to attend!
Yes, I'm moving forward with getting the mobile group going. I'll keep you posted. If you are curious, not sure if you use twitter, but the groups is called Mobile Twin Cities. You can check us out at:

http://mobiletwincities.com/

Just got it setup today. Still have a lot of things to get going, but would love to see you come to one of the meeting if you are interested in the coming months.The most important things I'll be looking for in the coming weeks is:

1) Location. Anyone know a good location to meet?
2) Presentations. Know anyone interested in presenting?

We'll wing it and see where things go from here. Anyway, please pass the word out to people that this getting going and signup for any of the lists/groups. I have business travel next week, but I'm hoping to lock down a location and some presenters in the next month and hopefully can put together our first meeting soon.
Talk soon Bill and we'll be in touch.

And, yes, I am on twitter: bill_turner is the id.

According the site:

CloudCamp is an unconference where early adapters of Cloud Computing technologies exchange ideas. With the rapid change occurring in the industry, we need a place we can meet to share our experiences, challenges and solutions. At CloudCamp, you are encouraged you to share your thoughts in several open discussions, as we strive for the advancement of Cloud Computing. End users, IT professionals and vendors are all encouraged to participate.

You can find out more at http://www.cloudcamp.com/.

I've registered. I hope to see you there!

Regular readers will know that I am high on entrepreneurship, especially of the Micro-ISV variety. They will also know that one of the reasons I am high on Groovy and Grails is because of the ease with which a site can be built. Knowing about my interests, an acquaintance of mine, Justin Grammens of Localtone Radio fame, pointed me to an online book at 37Signals called Getting Real. I have not read this, yet, but thought I should share it with my audience. It seems to fit in well with other resources, such as the book Micro-ISV: From Vision To Reality by Bob Walsh, Joel Spolsky's The Business of Software and Dharmesh Shah's OnStartups (the corresponding LinkedIn group seems worthless to me, however). These are all great resources. If you will start, intend to start, work for, or intend to work for a software startup, these will help prepare you for the road ahead.

Here are two links to successful projects using Groovy and Grails at LinkedIn and Wired. These articles support my theory that those with a substantial java investment are likely to, and maybe better off, using Grails. Below is a telling quote from the Wired.com case study:

Application performance is a huge consideration. Because we were comfortable with the stack Grails is based on, we were confident in the performance we could get out of the platform. The performance we have seen from Grails has been extremely encouraging, especially against other rapid development frameworks, such as Ruby on Rails and Django. In my experience Grails runs much faster - and to speed up performance, we can always optimize the application by bringing functionality into Java. - Paul Fisher, Manager of Technology

The numbers as of this morning are:

The TIOBE Programming Community Index for February 2009 for Groovy: 0.129%, down from 0.135% the month before.
The Dice job postings for Groovy/Grails: 23, up from 12.
The Dice job postings for Grails: 29, up from 17.
The Dice job postings for Groovy: 56. up from 31.
The Indeed job postings for Groovy/Grails: 89, up from 71.
The Indeed job postings for Grails: 110, down from 121.
The Indeed job postings for Groovy: 305, down from 385.

The numbers are mixed, though I am encouraged by the Dice numbers, which I feel are the best indicator. The Tiobe numbers, being a very small percent, are likely to swing dramatically with just slight changes. The indeed numbers are confusing, though the number of postings listing both Groovy and Grails is probably the best indicator of the bunch.

See January's numbers here.

If you are interested, they can be found here.

There was a definite excitement running through the attendees of minnedemo last night. It felt like the spark of entrepreneurial spirit I feel whenever I am in San Francisco, or, to a lesser extent, felt while I lived in Munich, Germany. People were animated and jabbered away about possibilities. It was my first time at the event. I'll definitely attend again.

I was curious to see how many of the people there were actually using Groovy/Grails, especially in light of my previous observations. Alas, most of the people I spoke with were not developers, so did not get a good feel for this, though I do believe Groovy/Grails to be a wise choice for the Micro-ISV.

One conversation that came up repeatedly was the seeming lack of entrepreneurship in the Twin Cities (Minneapolis and St. Paul). Well, this is not exactly true, though there seems to be little in IT entrepreneurship in the area. I am hoping that as word spreads of this event that the new venture fire will grow. There is no reason for it not to. After all, this area already is strongly entrepreneurial in the biomedical/healthcare industry. January 26, 2009 issue of Newsweek, there was a list of the major metro areas with the largest share of select industries. In the manufacturing capitals list, Minneapolis/St. Paul was ranked first with a 21.8% share in the biomedical industry. LA was second with technology. Contrast that to the service capitals, New York City was number one in finance at 42.7% and San Jose was fifth with IT at 6.9%. According to this Marketwatch article Minneapolis-St. Paul, far and away, remains where it's at for business. And, on top of that, this is apparently a very literate city as well, ranking tops in the America's Most Literate Cities, 2008, tied with Seattle. So, why, when we have plenty of entrepreneurship going on in this area, it is a great place for business, and a large, well educated population, does it seem that we have such little IT start-up activity? I believe a lot of it has to do with the fact that 19 Fortune 500 companies are headquartered here. On a per capita basis, that is a very big number. With that many here, I believe a lot of very good talent gets sucked up into the corporate environments, which leads to a siloing effect, and people are not connecting. Minnedemo is a step in the right direction to encourage the creative juices.

In my previous post, I complained of having errors where the messages were meaningless to me, even pointing in the wrong direction entirely. I've run into this more in my domain persistence tests than anywhere else. Like a good little Test Driven Developer, I generate my domain, then start updating the integration test before adding attributes or anything else to the domain. My persistence test will look something like:


Somewhere in the test/code loop, I will suddenly see an error that states:


A failure I can understand, but an error, no. Seeing this frequently enough, I realize that my object probably was not saved. The reason for not saving is not obvious. The stacktrace provides no answers. Well, after RTFMing and googling a bit, I came up with a better way to write the persistence test that will tell me when the object is not saved and the reason for it:


The if statement against the save of the first object will cause sysout to be written that can be viewed from test results html of the failing case via the System.out link at the bottom of the page. The above test was written to fail for this example. Viewing the link shows:


This probably should be written to use the fail method rather than a write to sysout. I'll leave that for the future.

The biggest problem I've had so far with developing has been finding good information. Grails is still quite young, just having reached 1.0 version in the middle of 2008. Many of the books and tutorials that one finds use deprecated methods or obsolete file references. The file references are annoying, though, so far, I have been able to figure out the replacement. The deprecated method issue is another thing. Deprecated methods do not seem to be flagged when the app is started (either from the run-app target or the test-app target). I have not found any file, log or otherwise, that alerts me to the issues. Yet, my tests fail. And, they fail for unexpected reasons that bear little resemblance to the actual reason.

History is replete with examples of superior technologies losing out in the marketplace to lesser technologies. Probably the most famous example of this in recent history was VHS over Beta, and, of course, there is the long time champ of the QWERTY keyboard over all other keyboards. This is not an argument about the superiority of Groovy/Grails over any other technology. All let others that are far more knowledgeable about various competing technologies to argue the technical merits.

In 1979, when I entered the IT field professionally, the IBM held 80% of the mainframe market. The minicomputer market was dominated by DEC, though not nearly as dominant. Similarly, COBOL was the principle language of about 80% of all developers. While the numbers changed over time, some more slowly than others, all three were dominant in the industry for many years. Part of the reason these changed slowly was the inherent conservatism of business. It is generally safer for the executive making the recommendation to choose the market leader. It also means there should be an abundance of technologist familiar with the tool set. What does this tell us about Groovy/Grails adoption? Java is the dominant language currently. The vast majority of projects under development are not greenfield projects, many will occur in an environment with an already sizable java investment. Since Groovy is more tightly coupled with java than what are usually considered the alternatives (Python and Ruby), the TIOBE Programming Community Index for January 2009 has java at more than 19%, while Python clocks in at 4.7% and Ruby at 3.1%, it seems likely that Groovy, and by association, Grails, will piggyback on the popularity on Java's success. It will be an easy choice for executives to make.

For a company, having multiple languages is an expensive luxury. It doesn't matter, either, that the languages and frameworks are open source. The company does not want to have to support multiple languages, each with its own idiosyncrasies, differences in build and deployment processes, and other redundant costs are targets for elimination. It has been my experience that just about every shop of any significant size has a number of legacy apps built using a technology that is in disfavor and is trying to eliminate. Another cost associated with this is the loss of morale amongst the developers whose language is no longer a significant in the development plans of the corporation leads to a loss of those people or retraining them. In the former case, the loss of knowledge means that others who are unfamiliar with the language, and likely don't want anything to do with the language, will be forced to support the applications. Not only are these developers less efficient, they are more likely to introduce bugs. Productivity spirals downward. Again, because Groovy is so tightly coupled with Java, there aren't nearly the concerns of multiple environments that there would be with other language/framework adoption. Developers should not feel demoralized, either. Groovy/Grails may not have the "coolness" factor of some other tool sets, it is still new and new is exciting. The cost of retraining should be minimal and can be done gradually. These factors would seem to strongly incent corporations, especially those with a significant Java portfolio, to adopt Groovy/Grails.

Similar to companies, there are drivers for adoption of Groovy/Grails as well. Corporations often pay little or not at all to re-train their staff. So, individuals are left to decide the best choices for themselves. First and foremost for most are the job market opportunities now or on the horizon. Undoubtedly many will do the analysis above and feel jumping on the Groovy/Grails bandwagon is only smart thinking. Few want to spend precious time away from family or otherwise give up their free time, nor spend their hard earned cash, without a payback. Another factor driving adoption by developers is the learning curve they will have to climb. Since a Java program can be groovified by simply changing the file extension from java to groovy, the learning curve is very gentle. All Java programmers are Groovy programmers; they just don't know it yet. This simple groovification makes it easy for developers to convince their managers to allow them to use Groovy/Grails. It is a win/win for all around.

For corporations, adopting Groovy/Grails will be a safe choice, one that leverages their existing investment, has a large pool of developers available, and has a relatively low cost of adoption. For individuals, it, too, leverages existing knowledge and skills in a way that few other technologies are able to do, should have the reward of a large and growing job market, is easy to learn, and they can convincingly argue for its adoption in the work place. The benefits of Groovy/Grails adoption by corporations and developers are too strong to ignore and should be taken seriously.