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:
- I just plain want to know, as fast as humanly possible.
- I’m terrified I’ll make a horrible mistake out of ignorance.
- 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.
- 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. 🙂
Leave a Reply