Bill Roper's Journal

After a whole lot of work on my VM, I finally just deleted the directory that holds all of the configuration information for my JDeveloper and now it is working properly again. I suppose I should have tried that first.

We had a walkthrough of the new Windycon hotel today and are discussing various items of space allocation that we will settle eventually. Figuring out how to carve up a new set of rooms is always interesting. :)

Gretchen and I had new passport photos taken today, because we are just within the deadline for being able to renew our passports online. Those applications are now filed. This is more immediately useful for me than it is for Gretchen, as I have now paid for my FilkONtario membership and just need to book a hotel room. Sadly, the website wasn't working earlier tonight, so I'll just try again tomorrow.

Meanwhile, Capricon starts tomorrow. Because a full day of work is a good choice for me, I'll be showing up Friday with my dealer table. At an annoyingly early hour, but I have a panel at 1 PM and want to take a run at having the table set up when the dealer room is actually ready to open.

Wish me luck!

We have a lot of unit tests that are running fine in the JDeveloper environment that do *not* run in the build environment. This has been a source of a lot of frustration for my co-worker who has been trying to solve the problem so I set out to dig into it today.

The first thing I did was get him to confirm that the build wasn't doing anything acutely stupid, since there are multiple separate build steps that actually rely on each other in a loop. This is an annoying problem (and not correctable in any reasonable way), but you can check through the loop by hand and he did so and determined that my first guess was wrong. Oh, well.

Ok. If you can't use the debugger because the failures are in the Gradle build, you can always go old school. It was time to start modifying the code and putting in debugging statements to drop data to the console. And so I did.

I got the stack trace for the mysterious exception that was shutting down a large number of the failing unit tests and went to stare at the source. Eventually I realized that *someone* (and it may well have been me) had written a particularly stupid little class loader that will load one class in one environment and a different class in another environment -- say, for instance, when you are running your unit test in the build environment. And when the alternate class it is trying to load isn't in the build environment either *and* is the completely wrong class to be loading, well, you've hit the jackpot.

I quickly wrote the missing class to implement the interface, causing every method to throw a NotImplementedException. This was the right choice in this case, because the interface described how to talk to the database and none of the database code is present in this particular part of the build, so you can't get it to run the unit test. And now my Class Not Found exception turned into a NotImplementedException -- and I was already dropping the stack trace out so that I could see that I was attempting to load the access record.

Huh. Now the model that I was working with in this set of unit tests was one that I had initialized by hand and it normally works fine -- until you try loading a feature that requires an access record, which it then tries to load from the database, which is not present. I wrote a class to initialize the access record and tucked it into the model initialization routine and almost *everything* started running correctly.

Happy dance! Except there were still a few (like four) unit tests that were failing for some unknown reason. One of these was working with a tiny grid that I'd initialized in my tiny model. Other things were working correctly with the grid, so why wasn't this one?

I finally wrote a routine to dump the tiny grid to the console and discovered that none of the values that I'd tried to change in the grid were actually getting stored -- with the result that the unit test didn't find the expected values and promptly failed. I managed to find where the error codes were stored and they were all the same code, so I found all of the places that could give me that error code and stuck a debugging statement in, which eventually led me to the point of failure.

I was getting an exception when I tried to parse the input value of "160.1". The exception claimed that the character in the zero position was failing, but when I looked at the exception, I realized that I had cleverly just passed back a zero instead of looking to see which character in the string was the problem. Well, *that's* easily fixed. It's the character in the *third* position. It's the decimal point. Why do I believe that a decimal point is an illegal character? Could it have something to do with localization and assembling the set of valid characters based on the locale's decimal separator?

Yes. Yes, it could.

Gradle not only runs the unit tests in multiple threads, but it *reuses* threads. The LocaleTest switched a thread to the French locale, where the decimal separator is a comma, and didn't switch it back. It does now.

And suddenly, the rest of the unit tests started working. Well, except for one test where the correct files aren't present in the build environment. I commented that particular test back out as a problem for another day.

And then I pulled out all of the spurious debugging code that I'd put in. I kept the grid printing code around though.

You never can tell when you're going to need it. :)

Or to quote one of my songs:

"I want to be old. I want to be wise.
I want to be just a little bit smarter than all those younger guys."

Amazing what you can learn from experience.

You take three days off and what do you get?

A big gosh darned bug, that's what.

I am sorting through this mess, which seems mostly to be the result of a failure of understanding. We'll see if I've solved it in just a minute.

I have to get K down to the bus that departs at noon tomorrow, as break is going to be over as of Monday for both of us. (Although I'll be taking time off at the end of the week to go to GAFilk...)

While off from work, I have devised a clever (?) scheme that may sort out some of the problems that the UI team is having with caching models in our updated environment. We'll have a meeting first thing Monday morning and I'll find out whether the scheme satisfies them or not.

Gretchen has been valiantly trying to get all of the dishes washed in the absence of a working dishwasher. This has been a game of three dishes forward, two dishes back. She is *so* close to the end of the queue here. But the new dishwasher will arrive on Monday according to the schedule and at some time between 6:30 and 10:30 AM. The 6:30 estimate seems unlikely, but if they are loaded by 6 AM and we are the first stop, not impossible. Gretchen is not looking forward to this timing, but I'm back at work, so she is in charge...

I have several things that I'm hoping to finish tomorrow, some of which are more necessary than others. I note that I *still* haven't managed to get the GAFilk quilt hung, but we *did* take down the Christmas tree today. Normally, we would leave it up until January 6th, but that is Tuesday, which is shortly before I depart for GAFilk and *after* K has returned to Ball State, so the tree is now out by the curb and the ornaments put away.

But the first order of business is to get K on that bus back to school, because I do not want to be driving to Muncie tomorrow. :)

I think I have finished cleaning things up at work for a while and need to get some fresh things to work on. :)

I am gradually catching up on things, both at home and at work.

The problem is that as I catch up on one thing, another thing comes careening down the track.

The good news is that we went out to dinner with friends tonight and had some good conversation. And the chance to talk to someone who is not one of my coworkers is a fine thing!

Success! Yesterday's design was written timely and accepted today.

Now, let's go build something. :)

Today was disjointed, partially because I was recovering from yesterday's trip and fall. I've got a bit of soreness in the right wrist, which is not unusual, because I'm acutely right-handed in a number of ways and use that hand to push myself up from my desk chair. I am pushing more carefully than usual today. :)

But nothing too bad seems to have resulted from hitting the deck, so we're going to count this as a win and a cautionary tale. As part of the win, I have put away the remaining parts from the baby gate install in case they are ever needed for something else, which means that the big piece of unneeded gate extender is no longer on the bedroom floor. (It was out of the way, but nevertheless...)

Progress was made at work today, which is also good. And I had the chance to go down into the studio and play around with things a bit more in the wake of yesterday's install. Everything continues to work well, so that's a good thing.

Calvin the Dog got some training in "the living room is part of the house" today. We'll see how that goes.

The week before OVFF is really not the time to have meetings downtown on Tuesday and Wednesday. But that's the way that the schedule worked out, so...

To add to the general entertainment, Julie had a root canal today. Calvin had his last lesson of puppy school and has graduated. More training is likely in order, but it's progress.

And the new CDs are tucked into inventory and the van is packed, save for our luggage.

I should really feel better about this, but it's being a bit of a treadmill. It will be better when we hit the road. :)

Day one of my two days of Loop meetings is over and I am fabulously tired. This is because I not only had to get up annoyingly early to catch a train, but I slept badly for a variety of reasons.

But the meetings went well, so that makes it worthwhile.

I will keep telling myself that when I have to get up early again tomorrow.

Thursday, I am going to sleep.

And then Friday I am going to get up early so we can get to OVFF on time.

Whee!