After not publishing these numbers for some time, several people encouraged me to do so again. The numbers coming from Dice have not been updated since I last collected them. I will begin updating those numbers again next month with the publication of the next TIOBE index.

Another thing that has prompted me to start tracking the numbers again was the assertion at the GR8 Conference in Copenhagen that Groovy was moving out of the early adopter stage and was entering the early majority stage. The numbers do not support the claim as much as I wish they did. See the Technology Adoption LifeCycle Wikipedia page for more information about why I find the claim suspect.

Note that I am looking at incorporating measures from LangPop into this recurring post. Feedback and other suggestions welcome.

The TIOBE Programming Community Index for Groovy
Month / Year	Rating	Change	Rank
06/2009	0.152%	+0.020%	36
05/2009	0.132%	-0.033%	41
04/2009	0.165%	+0.031%	36
03/2009	0.134%	+0.005%	42
02/2009	0.129%	-0.006%	40
01/2009	0.135%	--	38

Dice Keyword Search for Groovy and Grails
Month / Year	Groovy/Grails	Change	Grails	Change	Groovy	Change
02/2009	23	11	29	12	56	25
01/2009	12	--	17	--	31	--

Indeed Keyword Search for Groovy and Grails
Month / Year	Groovy/Grails	Change	Grails	Change	Groovy	Change
02/2009	89	18	110	-11	305	-80
01/2009	71	--	121	--	385	--

Results from the search engines should be considered carefully as the results are just the numbers returned from key word searches.

Part 1 of this series can be seen here.
Part 2 of this series can be seen here.

Preface and Chapter 2 - Managing Users with Scaffolding

Most developers realize early in their career that there are many ways to write an application that are essentially valid. Differing levels of knowledge of practices or of available tools and frameworks lead to different decisions. Likewise, greater knowledge of a domain likely means a more nuanced design. Then there is the ever present pressure to deliver a working application within a set of existing constraints that will force different decisions. Similarly, authors would likely make different choices in the way information is presented. Unlike Beginning Groovy and Grails and Grails In Action, Jon Dickinson chose not to present the user with a chapter on Groovy after the introductory chapter. Rather the intent seems to be "learn by example". I have to admit that I felt a bit uncomfortable with this, which I attribute to my already existing knowledge of Grails and the fear that a newbie would be lost or confused by what was left out. That said, just about all the Groovy tidbits to which the reader would be exposed in the chapter that he/she would likely not understand had some explanation. Coupling that with the knowledge that chapter four will explore Groovy in greater detail, my concerns may be unfounded.

The chapter starts off with a brief explanation of scaffolding, what purposes it serves and what expectations one should have for the created artifacts. This is important knowledge to share. It reinforces the idea that Grails provides a means for rapid exploration of the problem domain. After explaining that scaffolding is generated from the domain definitions the developer creates, he goes on to explain just scaffolding does in terms of providing actions and views.

We are then walked through the creation of our first domains, a User domain and a Role domain. Here Jon makes a statement I feel a bit misleading, "Domain classes constitute the domain model for the application. They are mapped directly to database tables by the Grails framework...". [emphasis mine] This is not exactly true, but is probably true enough for the novice. However, I believe the beginning Grails developer should be aware that there are circumstances where domains are not one-for-one equivalent to database tables, nor are attributes necessarily one-for-one. Perhaps this will be addressed in the later chapter on GORM. Jon also provides the excellent advice to of placing your Grails classes in a package. Grails by default creates all classes in the default package.

After the two domains are created, Jon leads us through creating controllers to enable scaffolding. He shows us how to create a controller through the grails command line command create-controller. We do this for both the User and the Role and we learn that both a controller class and a unit test class are created (unit tests were likewise created when the domains were created). A deeper discussion might have been warranted here to discuss the differences between create-controller and generate-controller. I can only surmise that his reasons for choosing the former to retain flexibility, to have a minimal implementation of controller logic for as long as possible while one prototypes the domain. I personally do the latter because I often find a need to start changing behavior early on. Being that the domain model is likely the most difficult aspect of the type of development for which Grails is targeted, his approach may be wiser. It is something I will integrate into my personal practice when I build my next Grails application.

The next section walks through constraint definition. Constraints, we are instructed that constraints, defined in the domain classes, serve three purposes: to perform basic validations of the data, to control the ordering in which the fields are displayed in our views, and to determine which input types are used when forms are rendered. The last is true precisely because we have yet to define any views and are just using the default views provided by the scaffolding. Jon provides us with a table of constraints that are available to the developer. Developers should have been cautioned, in my opinion, that some of the constraint definitions have an impact on table definitions, while others do not.

After defining constraints, the chapter turned to creating relationships between tables. Since there are only two domains present in the application thus far, he only demonstrates the creation of a one-to-many relationship between Role and User. The reader is somewhat mislead here by the suggestion that he must add several pieces of code to the Role class when only the statement static hasMany = [users:User] is necessary. I presume a competent developer would likely understand that neither the addition of the constraint, nor the addition of the toString method is necessary to the relationship definition. The toString method definition, by the way, has the unnecessary access modifier public specified. The default visibility of Groovy methods is public.

The final section is about using the BootStrap class to load data into the database at startup. At this point in the book project, we are still using the pre-configured HSQLDB, an in memory database. Personally, I feel it is a best practice to avoid creating a physical database as long as possible. Thus, this is a practice I use extensively. Of course, if your project involves legacy tables, you will not have such luxury.

This is a chapter full of red meat for the aspiring Grails developer. Though we have only just begun, much has been learned about application development using Grails.

Part 1 of this series can be seen here.

Preface and Chapter 1 - Getting Started With Grails

The preface covers the usual subjects one would expect in a preface: an introduction by the author, what the book covers, who the book is for, and conventions and symbols used throught the book. There were a few small syntax issues that in no way detracted from understanding. My concern with this, though, is that if these simple syntax problems show up so early in the book, does this foreshadow editing issues in later chapters, especially where it is highly technical? The errata currently shows only one issue, and it, too, appears to be only a small typo.

Chapter 1 makes an argument for using Grails, one that is pointed to individuals developing websites using java technology. It makes no attempt to sway those using Rails, for example, to jump to Grails, nor does it compare Grails technology to other frameworks/technologies available. The argument boils down to helping developers provide value more quickly. This is acheived through six items: less configuration; faster setup; shorter develop/test cycles; consistent development environment; a web domain specific language (DSL), and fewer dependencies. None of these are argued exhaustively. No hardcore skeptic will be convinced, but, then, the person purchasing this book is probably already somewhat sold, has probably already heard similar arguments, and is now exploring Grails to see if the hype lives up to the promise.

From there, the book covers installation. Installation is dealt with quickly and with little detail, as it should be. A professional developer should be able to handle this easily on his/her own. I wouldn't be surprised if most readers of the book don't already have it installed before they read the book.

Creating an application is next. Again, creating applications is relatively trivial, but this is a necessary explanation for the Grails newbie if for no other reason than to provide explanations of the various directories that are created. Without having done anything than running the create-app script, he shows, too, that you have a working application by launching it from script run-app. Yes, it is an application that doesn't do anything, but it provides the framework for further development.

The chapter concludes with an overview that author will use throughout the remainder of the book, a team communication portal, and the technologies that will be included in the application.

I was asked by Packt Publishing to review Grails 1.1 Web Application Developement by Jon Dickinson. This is the first part in the series. You can download a sample chapter, Chapter 10: Managing Content through Tagging from the publisher's site.

As I read through the book, I will post additional entries and reference the previous entries. So, no matter where you come into this, you can read through all posts.

When reviewing any subject matter, one should be aware your own perspectives and biases. I have been working with Grails professionally for about six or seven months now. I have read several books in the Grails sphere: the freely available Getting Started With Grails by Jason Rudolph on InfoQ, which is hopelessly outdated, Beginning Groovy and Grails by Judd, Nusairat and Shingler, Grails in Action by Smith and Ledbrook, and Grails Persistence with GORM and GSQL, which I previously reviewed here. When I say I've read these books, I have not read any from cover to cover except for Grails Persistence. I am what Mortimer Adler defined as a syntopical reader. I read to gain an understanding of particular subjects and bounce from book to book as necessary (of course, I google, read blogs and mailing lists, too). This is especially true when I am working on a project using what is a new technology to me. The point of explaining this is so that you, the reader, have a better idea of where I am coming from. I am now at a point in my Grails knowledge that I would not likely seek out another introductory book. I definitely need to get into meatier, deeper explorations. That said, I believe I can maintain a relatively objective view of this book.

My next post will be about what I've read to date.

My last project collapsed suddenly, unfortunately. I now find myself looking for a new assignment. In the meantime I am working on a website for Lone Star Custom Pits and Grills, a pro bono project. Lone Star is a manufacturer of customized, mobile barbecue pits used for competitions and catering. This project is made a bit more difficult than others as the owner is in Houston and is on the road a lot delivering pits. Thus, my contact with him is somewhat limited and will likely slow the delivery time. Being a pro bono project, too, the work on this project takes a back seat to finding new employment and organizing the GR8 conference here in Minneapolis.

The first feature is to create a "Pit Builder". This will allow potential customers to choose the features and options they want on a pit. This is a largely straight-forward affair with most of the difficulty coming in the form of the Ajax and CSS than in anything in the domain. The only gotcha in the domain is that there is heirarchical relationship between several domains. For example, a smoking chamber IS A component. There are many sub-components. This, so far, has not caused any issue at all. Inheritance of grails domains is simple. Some form of management system will be created with the pit builder as well.

Along with the pit builder, the site look and feel will also have to revamped before rolling out the pit builder. After that is complete, we'll likely add a blog. There will likely be other features added as well.

Since this project is pro bono, I am much more able to discuss details and hope to blog about it here. I will also use this as a basis for other things, perhaps screencasts, etc.