Categories
Google Maps Grails Groovy

Moving My Google Maps Mashup to Grails, part one

The Google Maps API is easy to use. The basic idea is to create a Map2 object (the former GMap2, now known as google.maps.Map2) and add Marker objects to it. The Marker objects then use InfoWindow objects to display all the information for that marker, which can either appear on load, or you can set up an event (like a click) to make the info display. I also like the Polyline objects, especially because you can make them follow geodesics.

While there are many good tutorials about Google Maps on the web, my favorite reference is Scott Davis’s book Google Maps API, v2. I purchased the eBook version at Pragmatic Programmer and really like it.

Since the API is in JavaScript, the key issue for me is how to get my location data into the code. It’s all in a database, but it’s also considered poor design to talk directly to a database from the view. When I wrote my app originally in Java, I did the normal process of building a data access layer in front of the database and then using a servlet to access it, turn the locations into Java objects, and then pass the whole lot to the view as request attributes. That’s all well and good, but of course JavaScript code can’t read Java objects directly.

Dave Crane has a good discussion of this issue in his book Ajax in Action. (Of course it’s a good discussion — everything in that book is good. :)) I recently also picked up his Prototype and Scriptaculous in Action book, and it too talked about the mismatch problem.

Crane lists the available options as

  • Content-centric, where the back-end code returns already-formatted HTML which a web page can render,
  • Script-centric, where actual JavaScript code is returned and executed by the browser, and
  • Data-centric, where the information is returned in some format that both sides can understand.

For my situation, the data-centric approach is really the only option. I’m not returning information that I want to render directly. My hope is for Google Maps to do all the rendering. For the same reason, I don’t want to return actual code, because that wouldn’t simplify anything.

I’m going with the data approach. Since JavaScript doesn’t understand either Java or Groovy objects, I need to select an intermediate format for the data. That also means I need to be able to generate the format from the Java or Groovy objects and then parse it in JavaScript.

As Crane points out, the major options are either XML or JSON.

I do remember back when XML was popular. I thought it was pretty cool, too, during that late 90’s and the first few years of this century. But XML gets parsed into DOM trees, and the DOM access API’s in JavaScript are bulky and cumbersome.

(But not as ugly as those in Java. I’ve always been amazed how badly Java interacts with XML, especially now that seemingly every business must, by law, build a service oriented architecture implementing web services.)

Groovy’s approach to XML is refreshingly easy, but again it doesn’t really help me here. I need to get my latitudes and longitudes into the constructor of Google’s LatLng class, which is what Marker uses to draw at a particular location.

The other intermediate format possibility is JSON. I really like JSON. It’s easy, short, and quite flexible. I wonder if JSON had been around when XML first became available if we’d all be using it instead.

Before I get to that, though, I have to mention another possibility that I actually used in my original implementation. There I relied on JSP tags, which generated JavaScript as though it was any other set of strings.

Assuming my courses all contain locations, and that each location has a latitude and a longitude, what I did was:


<c:forEach var="course" items="${courses}">
    loc = new google.maps.LatLng(
        "${course.location.latitude}","${course.location.longitude}");
    // etc...
</c:forEach>

and went on from there. The benefit to this approach is that I could access the courses directly as Java objects, using the normal dot notation to get where I needed to go.

The downside to this approach is that it makes for some truly ugly JavaScript. Note that I don’t have the word “var” in front of my (JavaScript) loc variable above. I can’t, because my <c:forEach> loop is going to generate a new copy of that line — and every other line in the loop — for every single course. I also didn’t try to store the values as I went along, which I suppose I could have done by declaring an array ahead of time, assigning each LatLng to an array at the “i”th index location, and manually incrementing the index. The effect is that I’m writing out each iteration of every loop.

I have to say, though, that the approach did work. I saved myself the difficulty of translating from Java objects to anything else, at the expense of repeating about a dozen lines of code over and over again for every course.

That can’t be the “right” way to go. Since I was porting to Grails anyway, I investigated what tools it (and, of course, Groovy) brought to the task.

Chapter 9 of Graeme Rocher’s book The Definitive Guide to Grails discusses the Grails tags available for Ajax applications. He goes through tags <g:remoteField>, <g:remoteLink>, and <g:formRemote> in some detail. Unfortunately for me, all three of those tags have an attribute called “update” which indicates which <div> element will contain the resulting data.

I don’t want to update a <div> element. I want numbers back.

Incidentally, in order to get a better sense of what was going on, I used those tags and looked at the resulting generated HTML. Not surprisingly, the tags all created Ajax.Updater calls in Prototype, my library of choice. What I wanted was an Ajax.Request, from whose results I could extract the text data and parse away.

Since the DGG book is getting a bit dated (already! I hope a good revision when Grails goes to 1.0 in October is already in the works), I checked the tag reference at the Grails web site. In addition to the above three tags, it also listed <g:remoteFunction> and <g:submitToRemote>, but neither of those were necessarily appropriate either.

The fact is, however, the data I need is already in the web page. It’s just in the form of a collection of instances of the Groovy classes called Course and Location, which are part of my domain model. All I need to do is to convert them to JSON and I’m off to the races.

Enter the Converters plug-in project for Grails, which is even built into Grails 0.6. The Converters plugin gives a convenient (according to the web site, YMMV) way to convert your “domain objects, maps, and lists to JSON or XML very quickly.”

The web page has examples on it, but I must admit I found them rather confusing. It’s entirely possible I’m missing something obvious. For example, I’m still not sure how it would help me to do a “render Course.get(0) as JSON” in a controller. I guess in my page I could set up a normal Ajax.Request myself to call an action implemented that way, but I’m not sure that’s they way the example is intended to be used.

I also got messed up when I tried to convert my collection to JSON, rather than a single object. The line above,

render Course.get(0) as JSON

works just fine, but

render courseList as JSON

throws exceptions. Eventually I wound up going to

render [crs:courseList] as JSON

which did the job, at the price of introducing a variable I don’t need. Today, though, I did some poking around on the Grails User mailing list archive at Nabble and found that

def data = courseList as Course[]
render data as JSON

might work instead, but I haven’t yet tried that out.

What I ultimately did was to go into my GSP page and use the converter’s encodeAsJSON() function. My page contains:


function initialize() {
    map = new google.maps.Map2($("map"));
    var homeJSON = ${Location.findByCityAndState('Marlborough','CT')
        .encodeAsJSON()};
    home = new google.maps.LatLng(homeJSON.latitude,homeJSON.longitude);
    map.setCenter(home, 4);

    // Transform the course list to a JSON object
    //  whose 'crs' property is the list of individual courses
    var coursesJSON = ${[crs:courseList].encodeAsJSON()};

    // Do the same with the locations
    var locsJSON = ${[locs:locationList].encodeAsJSON()};
    var courseArray = coursesJSON.crs;
    var locsArray = locsJSON.locs;

    processCourses(courseArray,locsArray);

    map.enableScrollWheelZoom();
    map.addControl(new google.maps.LargeMapControl());
    map.addControl(new google.maps.MapTypeControl());
    map.addControl(new google.maps.OverviewMapControl());
}
google.setOnLoadCallback(initialize);

That brings me to my other difficulty with using the JSON builder. My location objects are not normally embedded in my course GSP pages. I expected to get to the locations by traversing from the course to its location. The problem is, if you look at the generated JavaScript, the first Course object becomes

{
      "startDate": "2005-04-04 00:00:00.0",
      "title": "Intro Java with WSAD",
      "class": "Course",
      "endDate": "2005-04-08 00:00:00.0",
      "client": 1,
      "location": 1,
      "id": 1,
}

which means its location is just a foreign key value, not an actual object. I can’t traverse from Course to Location in JSON form. Since I want information from both objects (i.e., the Course title and dates, and the Location’s latitude and longitude), I had to make both sets of data available to my view.

(Also, note that the date is now firmly a string. I tried parsing it using JavaScript’s Date class, but no luck.)

That, at least, was easy. My CourseController.groovy class originally had


def list = {
    if(!params.max)params.max = 10
    [ courseList: Course.list( params )]
}

in it, and now it has


def list = {
    if(!params.max)params.max = 10
    [ courseList: Course.list( params ), locationList: Location.list() ]
}

I had to be sure not to pass the params argument to Location.list(), because while I want the course listing table to have pagination, I don’t know which locations I’m going to need for the courses so I have to send them all. It also forces me to traverse the relationship myself. In my processCourses function, I have


function processCourses(courseArray, locsArray) {
    // === Plot the markers ===
    for (var i = 0; i < courseArray.length; i++) {
        var c = courseArray[i];
        var loc = locsArray[c.location - 1];
        var latlng = new google.maps.LatLng(loc.latitude,loc.longitude);
        var label = "<b>" + c.title + "</b><br />" +
            "<em>" + loc.city + ", " + loc.state + "</em><br />" +
            c.startDate.split(' ')[0] + " -- " +
            c.endDate.split(' ')[0];

        var marker = createMarker(latlng, label);
        map.addOverlay(marker);

        var polylineOptions = {geodesic:true};
        var polyline = new google.maps.Polyline(new Array(home,latlng),
             "#ff0000",2,0.5,polylineOptions);
        map.addOverlay(polyline);
    }
}

and you can see that my location comes from selecting the proper element out of the locations array, based on the index value that comes from course.location. It’s not pretty, but it does seem to work.

This leaves me with two issues that have kept me from putting my application on the web yet.

  1. By default, Grails applications let the user add, edit, and remove elements as well as list them. I have to add some login mechanism before I expose that functionality. 🙂 Jason Rudolph in his Getting Started with Grails book used an interceptor for that. I’ll no doubt start there.
  2. Rendering the course as a JSON object embeds all of its details inside the JavaScript.

That’s a much bigger problem. My course objects have references to clients and even to rates in them, and I’d just as soon not expose that to anyone capable of doing a “view source” on the page (security by obscurity, indeed). I’m not exactly sure how I’m going to handle that.

My first thought is to create some kind of “narrow” interface to course objects that would expose only the fields I need to show. I’m going to try creating a class called, say, CourseMapData, which will consist of


class CourseMapData {
    String title
    Date startDate
    Date endDate
    String city
    String state
    double longitude
    double latitude
}

which will be populated from a Course object and its associated Location, send that to the view and convert it to JSON. I think that will work, but it’ll mean adding a new Groovy class that isn’t technically a domain object from the Grails point of view. I haven’t done that before, so that’s a good learning opportunity. Of course, I’ll also have to put in a method to do the conversion, too, and that method isn’t exactly a controller action, so I’m not sure where it goes, either.

I guess that’s part of the problem with eliminating formal DAO classes. Grails supplies finders automatically, which is great. I loved being able to use Location.findByCityAndState() without having to write anything. But I would normally put my conversion method in the Course DAO, and now I’m not so sure what to do.

When I get those issues worked out, I’ll no doubt post a “part two” entry here.

Categories
Google Maps Grails

Moving My Google Maps Mashup to Grails, part zero

I’m not quite ready to make it live on the web yet, but I’ve just about finished porting my Google Maps mashup to Grails. In earlier posts I’ve discussed how I built a Google Maps mashup showing the names and locations of all the courses I’ve taught over the last three years.

In its earlier incarnation (still on the web here, though eventually that link is going to point to the Grails version), everything was written in straight Java. I stored the data in three database tables, which I accessed by using a service layer supported by Spring and a data access layer that used Hibernate via JPA. The page itself is just straight JSP, with the necessary JavaScript thrown in. The page is just read only, too; there’s no way to add new courses or modify existing ones.

The whole application is a natural for Grails, though. It’s essentially a web interface on some database tables, with a small domain model, some simple searching capabilities, and only a bit of business logic thrown in here and there. That makes it ideal for me to do as a learning activity. Even better, when I’m finished, I’ll have a nice web-based interface to a system where I can store my course information as I go along.

Pardon me while I digress into an interesting story. Years ago, my father decided he really wanted to learn how to sail. As was his wont, he threw himself into the subject, digging up every book he could find, talking to people he knew were sailors, and basically trying to learn the entire subject in zero time.

My father and I are generally quite different people, but we definitely share that characteristic. I’m not sure what drives him to obsess so deeply about whatever subject he gets interest in, but for me, I have a few motivations:

  1. I just plain want to know, as fast as humanly possible.
  2. I’m terrified I’ll make a horrible mistake out of ignorance.
  3. I really want to do whatever the activity is, right away, but I really, really don’t want to look foolish when I make normal beginner mistakes.
  4. Being able to do cool stuff is so much fun I want to show everybody else how to do it, too.

Number 4 is a big reason why I’m an instructor. Number 1 makes me horribly impatient, but highly motivated. Numbers 2 and 3 tend to get in the way a lot, but I’m working on that.

Anyway, when my father was deep in his learning phase about sailing, he met an experienced sailor who offered to take him on a trip on the Chesapeake Bay. They experienced a lot of very high winds and waves — certainly more than my father was expecting. Still, he asked tons of questions and learned a lot.

What his friend told him, though, was that at the time my father was a great “book” sailor. He knew a lot of theory, but didn’t yet have the practical experience necessary to make sense of it all. He certainly knew enough to get into trouble, but probably not enough to know how to get back out again.

I totally get that, too. When I get wrapped up in a new subject, I dig through what feels like tons of material in a very short time. I rapidly get to the point of being a good “book” sailor. The problem is that I always carry this deep-seated fear that I don’t really know what I’m doing. That feeling doesn’t go away until I actually do the things I’m learning about.

That’s something I often think of as the “instructor trap”. Instructors spend so much time teaching that they often don’t have the time or energy left for doing, and it’s the doing that makes all the difference. You can certainly take that too far — I personally believe that industry experience can be vastly overrated. I’ve known plenty of developers who may have spent twenty years developing, but as far as learning anything new goes, it might as well have been the same single year repeated twenty times. Still, if all you know is the book, you’re missing a lot.

The term I apply to that situation is the Ten Canonical Errors. I’ve used that term here, but not in a long time.

(Quick aside: what level of geek do you have to be to use the term “canonical” in a sentence? Worse, what level of geek do you have to be to come up with a term that actually includes the word “canonical”? Yikes. It’s a good think I’m basically in touch with my inner geek.)

The idea behind the Ten Canonical Errors is that every time I learn a technology, when I start to use it there will be at least ten mistakes I’ll make that will cost me hours if not days. It doesn’t matter how many books I’ve read or people I’ve talked to, I’m still going to get stuck over and over. It’s inevitable. No matter how much I try to avoid them, the mistakes are going to happen. It’s just part of the process, just an extremely aggravating part.

Here’s a JavaScript example. HTML is simple, right? There’s nothing to it. I used to thing JavaScript was easy, too, until I started digging into Ajax, but that’s not the error I made.

One day I was trying to do a simple “Google suggest” type of Ajax application, where the server provided suggestions each time I typed in a character. I wasn’t doing anything fancy. As I recall, I as just doing a simple variation on a book example. But no matter what I tried, the JavaScript wouldn’t work.

My error was that I put all the JavaScript in a separate file and called it from the web page. Not a problem, right? In my page, I had:

<script type="text/javascript" src="myscript.js" />

That nice, clean XML, because I put in the “/>” at the end. Unfortunately, even though the contained JavaScript was so simple it HAD to work, it wasn’t working.

Eventually (and it took a while), I discovered this little paragraph in the XHTML specification:

“Given an empty instance of an element whose content model is not EMPTY (for example, an empty title or paragraph) do not use the minimized form (e.g. use <p> </p> and not <p />).”

So guess what that means? I have to write

<script type="text/javascript" src="myscript.js"></script>

instead, because even though I don’t have anything between the open and close tags, the fact that it’s possible to have something between them means I’m not allowed to minimize the tag, even though that’s perfectly valid XML.

Grr. I can’t believe somebody decided that. I have no idea what they were thinking. Still, it didn’t matter how many books I read ahead of time, it was probably inevitable that I was going to miss that. The only good thing about making it was that I could then check one off in the Ten Canonical Errors column.

By this point in my career, though, I generally have a vague sense of how far along I am along the errors path. I’ll describe myself as about two errors in, or even as many as eight. I don’t think I ever consider myself past all ten, no matter how long I’ve been in the field. Still, if I can get past six or seven, I generally feel pretty comfortable using the technology, and I know that if a problem comes up I’ll eventually be able to figure it out.

These days I’d say I was around a 7 on Hibernate and JPA, maybe a 6 or 7 on Spring (it’s so big there are still so many things I haven’t done yet), maybe only a 4 or 5 on JSF, and certainly a 9 on basic Java and probably close to that on server side and advanced Java topics. I’ve been using this stuff for quite some time now.

On Groovy, though, I wouldn’t put myself beyond a 4 yet, though I’m making progress. I didn’t think I was much beyond a 2 on Grails, but the fact that it’s based on Groovy, Spring, and Hibernate means I’m learning fast.

In terms of time invested, I’ve been playing with Groovy since about January, so that’s most a year at this point. I’ve read the bulk of the Grails book, too, so I’m not completely unaware of how it works. Still, when I compare it to what I can do in Java, it’s easy to get intimidated. But Groovy is so much more fun, that the sheer enjoyment of using it keeps me going.

(The whole transition from Java to Groovy really helps me identify with my poor COBOL programmers in my Intro Java classes. That transition is brutal. Moving from Fortran to Java was very hard for me, too, but I made that transition way back in the mid 90’s.)

In the end, building my Grails version of my course mapping application took me less than a week, even though I could only work on it for a few hours after class each night. The bulk of that time has been on topics that had very little to do with Grails, too. I’ve been struggling the last couple of days with how to transform Groovy collections into JavaScript arrays (including the associations — it if was just a single class it would be easy) which I could then process for Google Maps. I think I have it working now, but it’s been quite a battle.

I was going to post that code here today, but it’s been a long day and this post has already gotten out of hand. Look for some good coding info starting tomorrow. 🙂

Categories
Grails Groovy

It’s hard to increment null

After watching Jason Rudolph build a Grails application around an existing, legacy database, I decided to see if I could do the same. My Google Maps application (see my earlier posts on the subject) gave me a reason to finally put my courses taught data into a database. I still need a way to insert new data into that database, in a more user-friendly way than typing raw SQL at the MySQL command line.

Of course, that’s an ideal application for Grails. The Grails scaffolding builds controllers and views that can display domain objects that map to database tables, update existing objects, and even insert new ones. At my stage of learning Grails, it’s very useful for me to let the automatic generators build the basic application and then gradually replace the scaffolding with code I like.

This is also a nice app to experiment with, because at the moment it’s got a whopping three tables in it. There are three obvious domain objects, too: Course, Client, and Location. I’ve also got two one-to-many relationships between them, in that a client has many courses, and a location also has many courses. Nice and simple, but at least more than just a Grails version of Hello, World.

In Grails, it’s easiest to develop if you don’t already have a database. In a way, it’s ideal for domain-driven design, because you start with your domain objects and their relationships, and everything flows from there.

If I was starting from scratch, my domain classes (in Groovy) would look like:


class Client {
    int id
    String name

    static hasMany = [courses:Course]

    String toString() {
        return name
    }
}

for the Client, where the toString() override is so the relationship drop-down lists will be populated with just the name. Also, the hasMany closure establishes the relationship between Client and Course, at least on this end.

The Location class is


class Location {
    int id
    String city
    String state
    double latitude
    double longtitude

    static hasMany = [courses:Course]

    static constraints = {
        city(blank:false)
        state(blank:false)
        latitude()
        longitude()
    }

    String toString() {
        return "${city}, ${state}"
    }
}

The latitude and longitude fields are for the Google Maps application. The hasMany closure establishes the relationship between Location and Course. The constraints closure puts the various fields in the order listed, and ensures that neither city nor state can ever be empty. The resulting validation and highlighted error messages are part of the coolness Grails brings to the table.

Finally, the Course class is:


class Course {
    int id
    Date startDate
    Date endDate
    String title

    Location location
    Client client

    static belongsTo = [Client, Location]

    String toString() {
        return title
    }

    static constraints = {
        title(blank:false)
        startDate()
        endDate()
    }
}

The Course uses the belongsTo closure to establish the relationships in the other direction. The constraints closure is still mostly just for ordering; I imagine I’ll expand it later.

Now, if I didn’t have an existing database, I’d start with this, generate all the scaffolding, and let Grails create the database schema. The thing is, though, I already have the database schema, and some data to go in it.

As Jason showed, I could just let the Hibernate Tools reverse engineer mapping files from my schema. Then I could edit the mapping files to make the existing schema fit my domain classes.

Still, I thought I’d just edit the database to fit the Grails conventions (cue ominous music in the background). I’m doing this application as much to learn Grails as to solve my problem. Even better, I already have a Groovy script that can repopulate the tables if necessary using my existing DAO layer, currently written in Java with Spring and JPA.

The first change I made from my earlier schema was to make the table names singular instead of plural. The rest was fine (or so I thought). Each table had a primary key called id of type int. The course table has two foreign keys, each of which follows the naming convention (location_id and client_id). All of the column names map to the field names in the classes above, with camel case replaced by snake case (i.e., the startDate field maps to the start_date column).

Everything looked good, so I called the various Grails generators (grails create-app, grails create-domain-class, grails create-controller, and finally grails generate-scaffold) to see what happened.

As an aside, I also edited my DataSource.groovy file to point to my MySQL installation and to get rid of the dangerous “create-drop” capability. I didn’t want to overwrite the data by accident.

Unfortunately, I missed a detail. Grails doesn’t just add in a primary key field called id. It also expects a column called “version” in the database, of some integer type. This column is used for optimistic locking, so that if two people are editing a column at the same time, the one to commit first gets their changes written. The person who commits afterwards gets an error telling them that their data is stale, so they can’t commit until they refresh their data to the current values.

I don’t have version columns in my tables. Or, rather, I didn’t. I figured rather than drop everything, regenerate the tables and repopulate them from scratch, I could just execute “alter table” statements to add the new column to each of the three tables. I went ahead and did that.

The application then came up just as it should. I could see all the data, insert new rows, and delete the ones I inserted. Kewl. I spent some time editing the displays to order the data, make the views more visually appealing, and add functionality to search the courses by title and/or year (thanks to Jason’s great Getting Started With Grails book for all that).

What I couldn’t do, no matter what I tried, was to edit an existing object and have it successfully commit the changes. The web pages said that the changes were successful, so the save() method was supposedly returning true. The console didn’t show any errors, either. But nothing was changing in the database.

I really had to dig to figure that one out, but the Red Sox were losing and the Yankees were winning, so I kind of needed something to distract me anyway.

As it turned out the “grails shell” was the key. The Grails shell is a command-line script that allows you to write Groovy code that works with the existing domain classes. I loaded a course, modified its title, and tried to save it.

The resulting several hundred thousands of lines of the exception stack trace (Grails really can generate reams of lines of exceptions) somewhere had the word “version” in it.

I opened up a MySQL shell and looked at my data. Lo and behold, the version columns I added were there, and the data type was int, but of course all of the entries were null. Not zero, but null.

The optimistic lock tries to increment the value in that column. As it turns out, it’s hard to increment null.

The answer was to put zeros in all the version values. Everything worked just fine after that.

There’s a lot more I can and will do with this, but I have to admit, it was an excellent learning experience. It’s a bit daunting to know, however, that not having a version column meant that I almost had to switch to mapping files.

Categories
Grails

Go to see Grails, learn about Hibernate

Today I finally got to see the two Grails presentations by Jason Rudolph at No Fluff, Just Stuff. It’s not really an exaggeration to say I decided to attend the conference largely because I knew he’d be there. I like the NFJS conferences, but since I’m a one-person company, the “budget” for the conference comes right out of my pocket. I have to really want to go. Not only that, but for the past two years I’ve attended during the March session. It feels like a bit of a luxury to go twice in a given year, especially when many of the presentations in the fall overlap those from the spring.

But Jason was going to be there, and not only is he a real expert, he’s also a big part of the reason I’m involved with Groovy and Grails in the first place. I blogged about it a long time ago, but about a year ago I happened to be teaching a Spring class in Philadelphia. I happened to notice that the local Spring users group was hosting Jason, talking about this Grails thing I’d only heard about.

At the time I’d gone through my burst of enthusiasm and subsequent disappointment about Ruby on Rails. By that summer I’d come to the conclusion that Ruby was just too much and too different for me to make for a practical transition, not to mention the fact that I knew I wasn’t going to be able to follow their conventions and that was going to be a problem. Still, spending all that time digging into both Ruby and Rails taught me a ton. That was the first I’d heard about closures, for example. I also finally saw the power of a dynamic language, which ironically made me appreciate JavaScript for the first time, just in time for the Ajax revolution.

I guess you could say I was the perfect audience for Jason’s presentation. The fact that I could see all the Rails-like productivity gains and still be able to leverage all my Java experience was worth diamonds to me.

Today, he gave that introductory talk again, and followed up with a more advanced discussion of domain modeling with GORM, Grail’s Object-Relational Mapping framework. The introductory part was a nice refresher, but I was familiar with most of that material.

The advanced talk was very interesting, however. I needed to see how to work with an existing database schema, because that’s real life (despite what the Rails people seem to think). I knew in principle that since Grails just uses Hibernate under the hood, you could just fall back to Hibernate mappings to do whatever you needed. I’d never actually seen that in action, though.

But here was the surprising part. At one point Jason asked the audience if anyone had used the Hibernate Tools project to reverse engineer a database schema. I said I had, and I thought I had, but apparently I really missed the boat on that one.

I’ve tried the reverse engineering process inside an IDE. I originally tried it with MyEclipse, then I tried JBoss IDE. In both cases I felt like the wizard generated as much work for me as just writing the mapping files myself. I never seemed to get the hang of them. I hated seeing Java classes show up that had attributes like “userses” due to some naming convention. Since MyEclipse had content assist on the XML mapping files, it felt easier for me to just write the raw XML.

What Jason showed, however, was an intermediate step that hadn’t occurred to me. He didn’t go from the database schema all the way to the Java classes, which the wizards wanted me to do. Instead he used an Ant build to generate just the Hibernate mapping files and then edited them to suit his domain classes.

Imagine the sound of a light finally dawning. Here’s clue: Star Trek: the Original Series, first season episode “What Are Little Girls Made Of?”, quote by Ruk, the android left by the Old Ones:

“THAT was the equation! Existence! Survival … must … outweigh programming!”

In other words, I get it now.

I tried it with one of my own database schemas this evening, and of course it worked like a charm. I certainly don’t mind editing the resulting XML mapping files, and, even better, I can recommend the practice for clients who have dozens or hundreds of tables.

Thanks, Jason. 🙂 Now I can get back to really learning the framework.

Categories
Grails Groovy

Moving from Groovy to Grails

When I first heard about Ruby on Rails late in 2005, I got very excited about it and was eager to learn more. Over the Xmas/New-Years break I purchased both the so-called “pick-axe” book (Programming Ruby, by Dave Thomas) and the Agile Web Developer’s Guide to Rails (by Dave Thomas and David Heinemeier Hansson).

I tried plowing through the Rails book, but while the text is clear and well-written, I quickly realized that in order to make any real progress I needed to learn as much Ruby as I could. Learning both at the same time was just too much. I therefore went back to Ruby, and after making progress on that, I eventually dug into Rails again. Since my primary skills are Java, J2EE, and XML related, I couldn’t spend full time on those topics, but slowly made progress over the first few months of 2006.

Eventually, I abandoned that effort. I’ve talked about it here in earlier posts, but the short answer is that I came to believe the Ruby (and Rails, even more so) is really just a niche product. While both are very interesting and helped me learn a ton of new concepts (Ruby especially helped my JavaScript when I got to Ajax), I don’t believe that the industry is ready to abandon its considerable investment in Java technologies so it can start rewriting everything in Ruby. Add to that the fact that Rails is great if you’re starting from scratch but very annoying if you’re not (especially if you’re stuck with a legacy database that violates Rails conventions and even uses — horror of horrors — compound primary keys), and it just didn’t seem worth the effort.

I also became rather disenchanted with the arrogance and even haughtiness of the Rails team, from DHH on down. I liked that they violated accepted conventional wisdom and made it work, but I got really tired of the superior attitude and unwillingness to acknowledge that not everyone has the freedom or interest in doing everything their way. In the end, I decided that (1) Ruby is totally cool and can do almost anything (see Enterprise Integration with Ruby and Ruby Cookbook), and (2) Rails has a lot of great ideas, but neither was really my future.

In the fall of 2006, I then had the great opportunity of attending a talk by Jason Rudolph, who is a committer on the Grails project. Grails, as it sounds, is a framework rather analogous to Rails, based on the Groovy language. The cool part, though, is that Groovy code compiles directly to the JDK, so it cleanly interoperates with existing Java classes. Grails itself uses Groovy in many places, but really gets its power by leveraging existing, well-established Java projects like Spring and Hibernate.

In other words, Groovy and Grails are perfect for me. I’ve therefore been trying to absorb them off-and-on for the past six months or so. It’s hard to dedicate contiguous blocks of time to them, but I keep plugging away at them. From my Ruby experience, I decided that the real key was to learn Groovy before trying to absorb Grails. Therefore, I purchased Groovy in Action (by Dierk Koenig and others) and The Definitive Guide to Grails (by Graeme Rocher), and also acquired Jason Rudolph’s book Getting Started with Grails. That latter book has gotten dated very quickly, but is still a lot of fun.

I’ve mentioned it here many times, but Groovy is seriously cool. In fact, pretty much every Java developer I’ve shown it to gets excited about it. Even silly, trivial things are great.

For example, to make a Java POJO that will be an entity in a database somewhere, I have to write a class like:

public class Employee {

  private int id;
  private String name;
  private double salary;

  // ... other attributes as necessary ...

  public Employee() {}

  public Employee(int id, String name) {
    this.id = id;
    this.name = name;
  }

  // ... other constructors as necessary ...

  public int getId() { return id; }

  public void setId(int id) { this.id = id; }

  // ... all of the other getters and setters ...

  // ... overrides of equals(), hashCode(), and toString() ...

}

That’s a fair amount of code for what is essentially a trivial data structure. Even though Eclipse can generate much of that for me, it’s still rather tedious and verbose, especially when you compare it to the analogous Groovy bean:

class Employee {
  int id
  String name
  // ... other properties ...
}

That’s it. Not only don’t I need any semicolons (trivial, I know, but still kind of cool), but the attributes are assumed to be private, any required public getters and setters show up whenever I access or set a property, and any constructors I might need are already there, too. Truly sweet.

I can populate my Employee instance as easily as

Employee fred = new Employee()
fred.id = 1
fred.name = "Fred Flintstone"
// ... etc ...

which uses the public setter methods even though it looks like I’m accessing private properties. Actually, there’s an easier way.

Employee fred = new Employee(id:1, name:"Fred Flintstone", ...)

where I’m using Groovy map properties to populate the attributes, even though I didn’t write a constructor at all.

I can also do it this way:

def values = [id:1, name:"Fred Flintstone",...]
Employee fred = new Employee()
values.each {  key, value ->
  fred.setProperty("$key",value)
}

which looks Ruby-like and is also pretty cool. That’s still too complicated, though. I can also do this:

def values = ... // as above
Employee fred = new Employee()
fred.properties = values

That’s better, but I can even do:

def values = ... // as above
Employee fred = new Employee(values)

using the map directly. The best part is that I can even write the Employee class in Java and populate in a Groovy script much the same way. How cool is that?

Groovy therefore simplifies Java dramatically. Its dynamic typing makes coding much simpler, too. Groovy is attractive for its Java simplifications, but once you dig into it, its closure support is exciting, but builders are simply incredible. There’s nothing better than being able to build an XML document by writing

def  builder = new groovy.xml.MarkupBuilder
builder.employee (id:fred.id) {
  name fred.name
  // ... other instance variables ...
}

which automatically creates an XML file with all the tags, attributes, and text values automagically inserted. That’s unbelievably sweet.

On my current trip down here to Atlanta, though, I decided I’d finally read enough Groovy, even though I’m far from good at it. It was time to start digging into Grails again.

Grails is still evolving quickly, so every book I have is effectively out of date. Still, what I’ve seen is fantastic. I can’t wait to learn more, and, even better, start building some real sites with it. I’m also eagerly awaiting the Grails 1.0 release, tentatively scheduled for October.

I’d write more about it, but this post has already gone on way too long. Still, the more I learn the more enjoyable the whole thing is. It’s been a while since I felt that way about a programming language.

Categories
Grails

Paired Programming works, sometimes

A site I was browsing (I think it was Slashdot) linked me to a blog with a massive post entitled “Good Agile, Bad Agile”.  The author (Steve Yegge) works for Google — and how cool is that — and he’s writing about some of the good experiences he’s had with Agile programming techniques, which he freely admits he normally condemned.

Now, despite the fact that I’ve never been a full-time employee at a software development house, I do have a fair amount of software development experience.  Most of it came at United Technologies Research Center.  For those who don’t know, that’s the parent company of Pratt & Whitney Aircraft engines, Otis elevators, Carrier air conditioners, and lots more.  In short, their an engineering company, and software is done only to enable other activities, rather than as an end unto itself.   Bottom line is, most people there don’t have a clue about software; they’re much more interested in the engineering or control models they’re building.

Since I left the company in 2000, I’ve been mostly involved in teaching software development training classes, first for a training company and now as an independent.  Every once in a while I’ll get called upon to talk about the process of developing software.  The last time was at a chapter meeting of our local PMI (project management institute) group.

As an aside, my experience suggests that PMP professionals (those bold individuals who pay Rita Mulcahy big bucks for her certification book and then survive the exam) don’t understand the difference between managing regular projects and managing software projects.  For a PMP, a project is like building a house or arranging a conference.  There are lots of details and interacting parties, many resources that need to be coordinated, risks to be identified and plans to be formulated, and so on.  The thing is, though, it’s not like nobody’s ever built a house before.  It’s not like people don’t arrange conferences all the time.  The issue for them is more one of efficiency and effectiveness, rather than whether the project is even possible in the first place.

That’s software, of course.  We never build the same thing twice.  I suppose as a consultant I could go from company to company doing the same basic job over and over.  To choose a current example with lots of buzz words, maybe I could help companies convert their existing systems to web services as part of an overall Service Oriented Architecture running on an Enterprise Service Bus, even incorporating WebSphere Portal Server as part of the project.

(Pardon me for a moment; I just got vaguely nauseous.  Too many buzzwords in one sentence.  There, I’m better now.)

Even with a general category, though, every company is different, every system is different, every project is different, and in software the differences can be so vast that it feels like you’re starting over every time.

The agile community, especially the Extreme Programming (XP) community, has always had a great appeal to me.  That’s because their approach feels like the way I develop software, which, I must admit, is more like having the code congeal rather than being designed.  I’m never quite sure what the code is going to look like until I’ve written it, and XP sees that as a good thing, as long as you build lots of test cases around it that you run all the time.

In this particular article, however, one of the comments that jumped out at me is the author’s derisive attitude about paired programming.  Since this blog entry is already getting long, let me just say a word or two about that and leave the rest for later.

The principle behind paired programming isn’t really what  Mr. Yegge claims.  I’m sure he has much more experience than I do and he’s been wildly successful at it, or he wouldn’t work for Google in the first place.  On the other hand, one thing that immediately emerges from his blog is that he’s also a lot more cynical than I am, and that’s saying something.

Anyway, paired programming isn’t just adding more people to a development project, but since only two chairs fit at a computer, we’ll just do it two at a time.  The idea is that while one person is coding, the other is thinking about test cases, or the overall architecture, or just being an “audio debugger”.  Then they switch.

When I was a the research center, I was once involved in a project that was extremely late (shocking, I know, but there it is).  There were half a dozen people on the team, but only two of us were doing the actual coding.  I vaguely recall that we were putting a TCL/TK interface on an engineering system, which meant Java and Fortran on the back end.

(Hint: Never do that.)

I knew Java and Fortran and some of the engineering details, and the other guy knew the requirements inside and out and how to deal with the TCL/TK stuff.  To our astonishment, our manager did not cancel the project when the money ran out and we hadn’t delivered anything.  Instead, he essentially locked us in an office and told us to work together for a week and only come out when we were finished.

Here’s the scary part: that week was probably one of the most productive of my entire life.  We made decisions, prototyped them, abandoned bad approaches, redesigned the software and ultimately created something that was marginally acceptable but miles ahead of what we had when we started.  We did what would later be called paired programming at its finest.  I couldn’t believe how productive we were once we got past the initial start up efforts.  I also don’t ever remember being that tired after work.
The upshot is, I happen to believe in paired programming, but not totally.  I don’t think I could  maintain that kind of intensity on a daily basis, nor do I believe I could be productive paired with just anybody.  It couldn’t just be thrown together on a daily basis and watch the magic happen.

I wish I could say that from that point on my coworker and I worked together on a regular basis and became absolute stars, but such was not to be.  Instead I wound up on a horrible CORBA project in C++ with four project managers that never agreed on anything, but that’s another story, not to mention a series of ugly nightmares.

I think I’ll comment here periodically about the software development process, but the short answer is to check out the explanation of agile development in Martin Fowler’s UML Distilled book and follow up with the rest of his essays.  As anyone can tell you, he totally rocks.