Netbeans 6.5 + Grails

I'm not pleased with the apparent behavior of NetBeans 6.5 when creating a new Grails domain class. I'm unable to create a domain class anywhere other than the default package; the dialog keeps asking for a "valid class name":



This name works fine for creating a Groovy class, just not a Grails domain class. So, why won't the Grails support allow it?
 

UPDATE (2009-05-08): This seems to be straightened out in NetBeans 6.7 (beta).

XPath Voodoo

I had a use case for Canoo Web Test to verify the value of a table cell. In an attempt to obtain the value using an XPath query, I used the following expression:

//form[@id='myFormName']/table/tr[2]/td[2]

My test failed, reporting that this expression didn't return any value at all. I verified this was the correct path by looking at the XHTML source. It was only through inspecting the XHTML using the Firebug plugin for Firefox did I see a mystery <tbody> tag. I'm not sure at which point that gets injected, or even why. The injection appears to be a misinterpretation of XTHML 1.0 strict (the specified DOCTYPE). When I added the <tbody> tag to the XPath expression -- which I remind you is not in the XHTML source -- the test passed. Here is the working expression:

//form[@id='myFormName']/table/tbody/tr[2]/td[2]

I haven't figured out what I'm missing, yet.
 

Justice

Just today I saw the news that my friend's murderer was found guilty, with sentencing on the way.

I met Dewayne as an EVOC instructor and greatly enjoyed his company during the much-too-short time I got to spend with him. Dewayne's wonderfully affable disposition made him a joy to be around. He never seemed to be without a smile, but he was always ready to take care of business. Hard-working and friendly; Dewayne had these qualities in spades.

SGT Dewayne Graham was a great man, and I'm honored to have known him. I hope this verdict brings some small amount of comfort to his family, and I'm hopeful for swift and severe justice during sentencing.

UPDATE: On May 22, 2009, Dewayne's murderer was sentenced to death.
 

1,000 excuses

A good friend of mind said there were thousands of excuses to avoid exercising, but great reward in finding the reason to go ahead and exercise anyway.

Wise words that -- when followed -- always seem to make my day better.
 

It's here!

I've started in on "The Definitive Guide to Grails, 2nd Edition," by Graeme Rocher and Jeff Brown, after having just received it via post today. The Groovy/Grails combo never ceases to amaze me. The first couple chapters (as far as I've read, yet) are a simple introduction to the Grails platform, which cover starting up a rudimentary CRUD web application, complete with dynamic scaffolding for a couple related domain classes.

I'm anxiously looking forward to digging into more detail as I'm familiar with the material so far. Slow and steady wins the race, however, and I don't want to risk missing any updated juicy tidbits by skipping ahead.
 

Estimation error

"There's no point in being exact about something if you don't even know what you're talking about."
-- John von Neumann, as quoted in "Software Estimation" by Steve McConnell

 

Software Estimation: Demystifying the Black Art

At work, I just received "Software Estimation: Demystifying the Black Art," by Steve McConnell. I found his book "Code Complete" to be enlightening and practical, so I'm looking forward to reading what McConnell has to say about the art and science of software estimating. I'll be comparing the text to another favorite of mine; "Agile Estimating and Planning," by Mike Cohn.
 

The Definitive Guide to Grails, Second Edition

I'm anxiously awaiting The Definitive Guide to Grails, Second Edition to arrive by mail. I've been playing around with this framework and never cease to be amazed. I understand that other "RAD" web frameworks like Django and Rails probably offer similar features, but Grails' foundation of Groovy is especially attractive to me.

I'll try my best to be patient until TDGG2E shows up.
 

Hardest. Puzzle. Ever.

A hundred prisoners are each locked in a room with three pirates, one of whom will walk the plank in the morning. Each prisoner has 10 bottles of wine, one of which has been poisoned; and each pirate has 12 coins, one of which is counterfeit and weighs either more or less than a genuine coin. In the room is a single switch, which the prisoner may either leave as it is, or flip. Before being led into the rooms, the prisoners are all made to wear either a red hat or a blue hat; they can see all the other prisoners' hats, but not their own. Meanwhile, a six-digit prime number of monkeys multiply until their digits reverse, then all have to get across a river using a canoe that can hold at most two monkeys at a time. But half the monkeys always lie and the other half always tell the truth. Given that the Nth prisoner knows that one of the monkeys doesn't know that a pirate doesn't know the product of two numbers between 1 and 100 without knowing that the N+1th prisoner has flipped the switch in his room or not after having determined which bottle of wine was poisoned and what colour his hat is, what is the solution to this puzzle?

Heh.
 

Getting What You Want

"The indispensable first step to getting what you want is this: Decide what you want."
-- Ben Stein

This is soaring?

Yahoo!® Finance reports today that "Stocks Soar on Bank Rally." Not to rain on anyone's parade, but a 380-point bounce in the Dow after losing more than 50% of its market value since last October (a high of 14,093 to 6,547 yesterday) is not what I'd call "soaring," given the context.
 

...And Pretty Soon You're Talking About Real Money

Global Financial Assets Lost $50 Trillion Last Year, ADB Says
 

Theory vs. Practice

"The difference between theory and practice is smaller in theory than in practice."
-- Unattributed
 

Bigger than a breadbox

What a trillion dollars looks like.
 

"Holidays The Healthy Way" Weight Loss Challenge

Recently at work, we had a "weight loss challenge" that started in early December and ran through February 13, 2009. With the expert help of my live-in chef and nutritionist (aka, Terri), I won the competition by a healthy margin. I started at ~208 pounds and finished the competition around 176, losing around 32 pounds (a little over 15% of my total body weight) in ten weeks. The big secret to my success was watching what I eat and exercising regularly. I know that's not a particularly revolutionary idea, but it's one many of us - that is, me - seem to struggle with. For the most part, however, once I paid close attention to what I ate and how much exercise I did week-to-week, the process managed itself.

The goal now is to keep working on converting fat to muscle and not fall back into bad habits. :)

Update: "Days Difference" with Joda

The more I play with the Joda Time API, the more I like it. Revisiting the "calculating difference in days" problem, here's the Joda/Groovy equivalent:

import org.joda.time.LocalDate
import static org.joda.time.Days.*

date1 = new LocalDate(2008, 3, 10)
date2 = new LocalDate(2008, 3, 12)
assert 2 == daysBetween(date1, date2).days

What's not to like? :o)

 

DGG Confusion #1 (among many to come, I'm sure)

I'm working my way through The Definitive Guide to Grails. Chapter 6 covers testing, and I'm a bit stuck on the GroovyMock example in listing 6-9. I'm using Grails 1.0.2, and as entered*, the test fails with "No call to 'getParams' expected at this point. Still 1 call(s) to 'redirect' expected." I tried demanding a call to getParams, but that leads down a path of yet more confusing errors.

So, I'll keep beating my head against it for a while, and hopefully post back with some results.

*

void testUpdateNotFound() {
 def bc
 def mock = new MockFor(BookmarkController)
 mock.demand.redirect { Map params ->
     assert params.action == bc.edit
 }
 mock.use {
     bc = new BookmarkController()
     bc.params.id = 5
     bc.update.call()
 }
}

[UPDATE] Nothing that a little Googling won't help, and I'm happy to know I'm not just insane (well, at least not with this particular problem). I'm using version 1.5.1, and according to a bug report, Groovy's MockFor is a bit squiffy in versions 1.5.1 and 1.5.4. Unfortunately, the bug's still open, so I'll have to pass over that part of the book for now. I can do that in good conscience. :o)

[UPDATE #2] This works with Groovy 1.5.6 (with "method pointers"):

import groovy.mock.interceptor.*

class BookmarkController {
    def update = { redirect("value from original") }
    def redirect = { println "Original class: $it" }
}

class BookmarkTests extends GroovyTestCase {
    void testUpdate() {
        def bc
        def mock = new MockFor(BookmarkController)
        mock.demand.redirect { println "Mock class: $it" }
        mock.use {
            bc = new BookmarkController() 
            bc.&update.call()
        }
    }
}

new BookmarkController().&update.call()
new BookmarkTests().testUpdate()

...but I'm not sure that does much for DGG Listing 6-9. Hmph.
 

Confusion

On two occasions I have been asked, – "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

-- Charles Babbage, English mathematician, philosopher, and mechanical engineer

 

Calculate Difference in Days

Java has no built-in "give me the difference in days" API methods. One commonly-suggested solution is to get the difference in milliseconds between two dates and, using the number of milliseconds in a day, determine the number of days. Unfortunately, daylight savings time creates some problems with this method, as the following Groovy script demonstrates:

#! /usr/bin/groovy

df = new java.text.SimpleDateFormat('yyyy-MM-dd')

// These dates cross DST...
startDate = df.parse('2007-03-10')
endDate = df.parse('2007-03-12')

expectedDifferenceInDays = 2

// Here's the problem with millis:
millisInADay = 1000 * 60 * 60 * 24
differenceInMillis = endDate.time - startDate.time
actualDifferenceInDays = differenceInMillis / millisInADay

assert expectedDifferenceInDays != actualDifferenceInDays
assert actualDifferenceInDays < expectedDifferenceInDays

Here's a more straightforward solution using Java's Calendar API:

#! /usr/bin/groovy

df = new java.text.SimpleDateFormat('yyyy-MM-dd')

// These dates cross DST...
startDate = df.parse('2007-03-10')
endDate = df.parse('2007-03-12')

expectedDifferenceInDays = 2

calendar = Calendar.instance
calendar.time = startDate
actualDifferenceInDays = 0
while (calendar.time.before(endDate)) {
    actualDifferenceInDays++
    calendar.add(Calendar.DATE, 1)
}
assert expectedDifferenceInDays == actualDifferenceInDays

Note that what constitutes "a day" is subject to interpretation... :o)

Write simple code

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
-- attributed to Brian Kernighan