Bill Roper's Journal

I had managed to exhume one of the necessary pieces of information using my superior Google-fu, so Gretchen was able to get on the phone with our financial advisor today and clean up one of the long-standing bits of financial business that needed to be taken care of. The right incantation was spoken and now all the various wheels are in motion so that the clean up will happen.

We are, of course, waiting to see if anything blows up in the process. :)

Speaking of things that blow up in the process...

So I'm writing a new feature at work where I'm using some of my older code to allow me to extract the data that I need to answer a lot of questions. It's actually working pretty well, but I got into a situation this afternoon where I was getting a null pointer exception. Ok, I had the data that I could pass in to clear up that null reference, so let's just initialize things and let them run normally.

A cascade of null pointer exceptions followed for a different object, because I had also passed in a null for the period identifier instead of the well-known (in this environment) "this is not a valid period" identifier. I added null checks. I added a lot of null checks.

And then I went back to my code and passed in the well-known "this is not a valid period" identifier instead of a null reference. Because suspenders *and* belt, right?

It's working correctly now.

After way too long trying to find a serialization error at work over the last two days (and finding a number of them; just not the one that I was looking for), I finally got bright enough to remember that the JDeveloper editor will allow you to split the window and look at the same file at two different line numbers. Lining up the inbound and outbound serialization code opposite each other made the error a *lot* easier to spot.

It would have been easier if the error had never been put in, but these things happen.

I have turned the corner on the great refactoring job I'm doing at work. The UI is mostly doing the right things, so now it's just a matter of driving out the glitches from the refactoring.

I'm hoping to finish this up on Monday. I am, of course, an optimist...

I actually don't so much mind refactoring code, as long as I am doing something that will improve the code base. For instance, today I worked with one of my colleagues to convert a reference to a particular class to a reference to a shared interface implementation. This was good, because now anyone else who has the same problem will be able to implement the method on the interface and get the behavior that they want.

And then there is the refactoring that is just cleaning up after other people who have introduced references to other libraries in classes that simply shouldn't be using those libraries. This is much *less* fun.

At least the end is in sight.

And today was back to work (and school) after a two-week break. There were varying degrees of success.

On the other hand, I finally threw up my hands and stopped trying to add a remove method to my Java iterator built on top of my unifying interface layer. Instead, I've coded things using a different approach to what I'm doing.

I've managed to cobble together a first unit test to throw against the wall that found a couple of different (and one pre-existing) bugs and have fixed those. Now that the framework's in place, I should be able to write a lot more test cases fairly quickly to make sure that there aren't more bugs or, if there are, that I can fix them. :)

I have become fond of unit testing...

I have been fixing a silly number of bugs in the last couple of days.

One of the bugs that I am fixing right now is one that I thought was going to be a horrible amount of work. It turns out that I can fix it rather simply, which I found out after digging through the code.

I just can't *test* the fix, for reasons having to do with Microsoft Excel's lousy handling of COM memory and garbage collection in .NET.

So I am checking in the fix and passing it along to someone who has installed the 32-bit version of Excel, which seems to do a better job of garbage collection than the 64-bit version. That's not what I would have expected, but it is what appears to be true.

Some problems are just annoying.

I have fixed a great many bugs this week.

Right now, I'm looking at the debris in our Visual Studio 2019 port. The COM handling machinery there seems a bit idiosyncratic, but it's possible to work around those eccentricities once you find them. I'm doing bulk corrections and it seems to be stable.

But I've found some code in our UI layer that I really don't like. I think I can fix it in a day and then we'll see if some of the idiosyncrasies in *our* code will be good enough to go away.

I cleaned up a bunch of crufty, slow code in our user interface layer over the last week and checked the changes in today. There are still some more places that can be cleaned up, but I took care of a lot of the low-hanging fruit.

Don't Write Inefficient Code.

This suggests, perhaps, that I have watched too many episodes of "Don't" during the pandemic. However, I spent the afternoon cleaning up some really inefficient code in one of our modules this afternoon. I'm not sure exactly how much impact it will have -- we'll know more about that when it gets into testing.

But it will help. I had explained much earlier how to make at least some of these fixes. They were never made.

Until now.

Don't. Write. Inefficient. Code.

*sigh*

This afternoon was spent refactoring someone else's code. I think it's helped, but I need to find out where the other bottlenecks are hiding. Maybe they'll turn up tomorrow.