Tag: eclipse

Updated the blog! Cue the code!

I know I haven’t been as prolific as usual lately…I blame our Agile team’s project. Normally, we deal with enhancements and fixes, which frankly I LOVE. I started out my mainframe programming life back in 1992 dealing with production and enhancements, so I’m quite comfortable “in that space” as they say in corporate-speak. However, our team has taken on a rather larger enhancement, which is frankly more of a project—they’re just not calling it that. Several agile teams and departments are involved in this. I know, in the long run, this will be good, as it involves a new integration with our system, so I’m getting to see how integrations are set up.

The bad part is that we are all working on our stories at the same time, so in the case of my current user story I’ve been having to code off to the side in a Notepad++ document, with the idea that I will be adding my function once the Util class is created. There is really no way to tell if what I’m writing will even WORK. I’m one of those people who needs those visual cues in the Guidewire Studio app (or Spring/Eclipse, if I’m coding in Java) to guide me. You know, “normal” print if everything is kosher and ANGRY RED if there’s an issue. I’m not used to coding blind. I’m sure, once I get more experience, I’ll find this easier, but right now it’s maddening. I’ve also been working on a GUnit test for this, which has been the seventh circle of hell. I think I’ve managed to find some existing GUnit tests that are close to what I’ll be needing, but AGAIN, I need to be able actually run this SOMEWHERE.

I’m also still working with the new guy. The latest thing is that I need to help him upload some Admin Scripts into GitHub for his user story…this is a clear-cut case of the blind leading the blind. I have a sneaking suspicion that my boss is suggesting I help him with all this different things as a way of getting me more familiar with different tasks. I’ve done exactly ONE of these previously, so this is going to be entertaining, to say the very least.

Thank heavens for long weekends…May you all have a wonderful Memorial Day weekend! I for one, plan to catch up on all my knitting and crocheting, which has been woefully neglected this week!

Work Day 48: My new toy!

I can’t remember if I’ve mentioned it, but back when I was frantically trying to make ClaimCenter 9.0.7 work on my local machine, one of the things I had to do was to hook up my database. As I was adding in the drive path into the configuration file and the h2 jar file, I discovered something wonderful. To test the database connection, one clicks on the h2 jar file, and then clicks “Test Connection.” If “Test Successful” pops up, then you’re good. Now, you’d hit “Connect.” WELL…when I did this, a SQL window popped up, with all the data files listed, such as you’d see for the test and production Oracle environments in Oracle SQL. For hoo-has, I experimented and plugged in one of my production queries, minus the “gwcc” prefix, and IT WORKED! I now have a way other than the Gosu Scratchpad to query my local database to see what it contains! I proceeded to try all my queries and they all worked. The only ones that don’t are the integration ones, as that information wouldn’t be under this schema.

Speaking of integration, I found out that our integration repository for March won’t be out until next week. In the meantime, I’ve still been trying to familiarize myself with Spring Batch. One of my coworkers, who deserves a medal in sainthood, was trying to show me how to create JTests for my integration code change…he was saved by his ride arriving to pick him up. While it was somewhat confusing, I think I got the gist of what he was showing me, so I’m going to continue on with it tomorrow.

Work Day 47: Well, I THOUGHT I was brilliant…

Remember my great stroke of genius in discovering I’d only need to add one argument to pass to that one method to fix the driver age being passed to our other system?

There’s good news and bad news. The good news is that my mentor helped me determine the correct version of the integration repository to clone to make my changes (short answer: it doesn’t exist yet for the March release). He helped me with my Eclipse setup, so that I can eventually make my change—for now, I’m using the older repository code for this purpose. Creating a patch in Eclipse is similar to creating one in Guidewire Studio.

The bad news is that my ingenious idea to add one argument to pass into the method was a bust. I added my change in Eclipse only have have all sorts of angry little red Xs and other ugly notations pop up. Come to find out, I hadn’t thought to DEFINE the loss date field that gets passed with date of birth. Choking down my rising hysteria, I saw how date of birth was defined, and then I scoured the class until I found loss date defined somewhere else in a similar manner. I copied that code over to the code that calls the method and all the angry little squiggles went away! Whether or not this actually will work remains to be seen. Once the March repository becomes available I’m going to hook everything up and test by entering some claims into my local UI and see if they pass correctly through the integration process.

Okay, that’s how I imagine it’s going to go. I’m sure the reality is going to 12 times more complicated than that. For one thing, I have to make this change work for five different scenarios. Also, I’m casually using the expression “hook up” for a process that’s defined over 11 pages of documentation.

My poor mentor is going to deserve a medal for this…or at the very least hazard pay…