integration – WildKnitter Codes

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!

Unraveling, without becoming unraveled…

I seem to be unraveling all my previous dilemmas. That mysterious Gosu code turns out to be block code. That still means nothing to me, but now at least I know where to look in the documentation to learn more. I’m also happy to report that frantically posting my query about the damned nested if statements to the Guidewire Community site paid off. I got two suggestions, and the “.add” to an array solution worked! Why I didn’t remember this from my Java class, I don’t know, as it’s similar logic. Sometimes it’s tough to connect what you’ve learned with the current mess in front of you.

In positively JOYOUS news, that ghastly defect user story that spawned ANOTHER defect user story, has finally passed QA and it in the release queue! I suspected this might happen, as I ran a few furtive SQL queries yesterday to check was I thought might be our QA tester’s payloads to the integrated system, and they all looked good. I swear, I’m so happy I could cry…sometimes I really feel like the life of a developer is a series of roller coaster rides—devastating lows followed by meteoric highs. It’s exhausting, but I’ll still take this over being a BA any day.

The new guy got his Java quandary sorted out. He needed version 121 for our Guidewire Studio, but tech support had installed a higher version. He’s now wading through my instructions on how to copy over a database to his local machine, while also trying to figure out his on-boarding HR tasks (signing up for benefits, taking various online courses in our ethics and sensitivity training, etc.). He’s also starting his moving process this weekend, to eventually end up at our southern hub. I can’t imagine attempting to pack and move while learning the ins and outs of a new job, but he appears to be managing it. Seeing as no one is actually physically working at any of our offices at this point, it’s going to remain to be seen when he can actually darken the door of the place. I hear it’s very nice…when you can actually go inside…

From Learning—to Showing—the Ropes!

So, another day, another WFH (working from home) adventure. Once upon a time, WFH was an exciting privilege, where you got to sip the tea that you leisurely made, ate oatmeal that DIDN’T come out of a microwave, and quietly did your work; meanwhile escaping all the chaos, gossip, and annoyance of the office. Now, it’s taken on a whole new meaning since EVERYONE is working from home, minus a few hundred at my company (“Can you hear me? You’re breaking up! I can’t see your screen. Is so-and-so joining the meeting? What was that again?”).

We have a new guy starting next week, and I’m going to have to help him get aclimated, which is going to be positively weird to do via remote control. Granted, the guy is in another state, so I would have had to work with him remotely anyway, but it’s the principle of the thing. Despite my grumbling, the exciting thing is that I’ve hit some sort of a new level in my development job. I’m actually being trusted to show a new developer the ropes! We sincerely hope I can remember how to get Guidewire Studio up and running for a brand-new person, not to mention Spring for our integration work (Java).

I’m also now being asked to do code reviews! I really didn’t think anyone would trust with that until at least my 1-year mark, but I’ve done quite a few now. It’s actually a good way to check someone else’s code and learn from it…as opposed to spending and entire DAY trying to figure out a defect found in QA (which is how I spent my entire day yesterday).

And, of course, I’ve been doing copious amounts of knitting and crocheting in our time of quarantine. I confess, the WIPs are hopelessly out of control. I’m working on:

An Annie’s Attic Crochet Striped Afghan Club project

A knitted mask, with an i-Cord from hell

A baby blanket ( you just KNOW someone is going to end this quarantine pregnant)

A Sophie’s Universe Crochet afghan (I’ll be working on this one until they put me 6-feet under)

A Mary Maxim Woodlands Striped crochet afghan

I know there’s another one, but I can’t remember it right now…

On that note, must get back to the old backlog, to see what my next adventure is!

TWILIGHT ZONE – Part Deux

Well, the recovery from my ghastly QA Epic Fail has been just as WEIRD as the original problem. First of all, when our BA mentioned “Criteria 1” he was talking about the main gist of the change — driver age was still getting populated with the age at the time of exposure creation and not the age at loss. I scoured the code in GitHub and the code my coworker added was just a bunch of loggers to troubleshoot HIS issue with his code, so that wouldn’t affect anything with my code.

My long-suffering coworker who’s been helping me out (let’s call him Mentor #2) had me bring the March Branch into my local (I KNEW this was going to happen), take the payload from our BA’s claim, and plop it into my JUnit test to see which age would appear.

To back this up a bit, the payloads created by our process, that are fed into the integration jobs, have changed format. I was able to escape using these last time by using an older claim for my JUnit tests—no such luck this time, as our BA had created this new claim just for his testing. I had several false starts where the damn JUnit test just didn’t work with the new payload format. Mentor #2 had to dial in for a meeting, so left me to my own devices, telling me to keep trying. After cursing and swearing that the damned payload was a bust, and that he had NO IDEA what he was talking about, and why on earth did they have to change the damned format, and…

…and then I saw it. Yours truly forgot to change the JUnit code to use the claim and policy for the BA’s claim—mine was still in there. Once I fixed this, the JUnit test ran like a Swiss watch…and wouldn’t you know, the correct age popped out! So, the issue wasn’t my code. Seeing that our BA originally created his claim February 4, I decided to take a chance that this might have been a system glitch—especially seeing as my coworker had had his code issue around the same time. Following the QA test scenarios, I created two more claims from the UI. This morning, I checked the final payload that goes to the next system, and again…I got the correct age.

SO, what happened? My tech lead believes it may be due to our BA running his tests before the test Spring Batch cycle ran, but my code was there on January 27 and worked just fine. I checked the output for the Spring Batch Build for Monday and the result said “UNSTABLE,” so perhaps something happened that effected our code.

For now, I’m going to lay low…but I think I’m going to need to keep running my tests every time this code hits a new test region and production.

Fun with JUnits

…or, why I’m pretty sure I’m grayer than I used to be…if I wasn’t in fact hiding my gray. 😈

The good news is that I’ve had a crash course in working with Spring Batch and I’m now a veritable expert in operating the debugger. I also now understand (somewhat) where to get the data for the payload by running only a few SQL queries against the test data from the UI and using the resultant payload for our JUnit tests. This is definitely a step up from my attempts to get data last week by running multiple queries and cutting and pasting all the information!

Monday, my coworker spend an hour of his life he’s never getting back showing me all this, while attempting to help me with the payload for my testing. The payload still isn’t exactly what one might call stable. I tested with and without my code change and thankfully that’s not the issue–I would have run screaming into the night if it was.

Sadly, I’m going to have to have him help me further, as I ran all the SQL queries I was supposed to to get my new example, but I’m not ending up with the same file format that our JUnit job requires. I’m not quite sure WHERE my coworker found the information, but I don’t think I quite have it.

The adventure continues…

Work Day 50: Seeing light at the end of the tunnel…

…that we really hope isn’t the on-coming train!

I’m making slow, but steady progress on my JUnit issue…if you count “finally finding the right people to consult” as progress. My poor, long-suffering mentor is inundated with work for the upcoming release, so he’s tossed the ball back into my team’s court (you know it’s bad when I’m resorting to sports analogies). One of my team members figured out part of my issue. I definitely had no access to get a Nexus Repo Key for that Maven step for setting up Spring Batch. The good news is that I put in a tech support request, and I got access to get one—miraculously in one day! At that point, I was totally fried, so I’m going to attempt to do this tomorrow.

This brings me to the bad news. The other person on my team who’s helping me…he’s in India. Yours Truly is going to get into work at the crack of dawn tomorrow morning to be ready to talk to him at 8:00 am. As much as I’m very grateful to him, this is going to cut into my morning yarn time! In addition to my sock-knitting, I’m also crocheting the Sophie’s Universe Afghan, which requires early morning quiet time, in order for me to concentrate. It’s one of those maddening patterns where, even though I’ve had oodles of years in crocheting experience, I’m still frogging back practically every row, due to being hopelessly off in stitch count. I’m only a few rows in, so far!

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…

Work Day 41: Making it official…

I’ve decided that I’m just not right in the head…remember that defect user story I was scoping out—the Penalty Payments from Hell? We were having our checkpoint this morning, and we were discussing backlog items. One person grabbed the Integration story (oh, DARN). That left my nemesis. Remind me never, ever again to jump in feet first during a lull in the meeting conversation. As no one else was leaping up and down for the payments defect story, YOURS TRULY decided to be plucky and volunteer to do it. Granted, I did indicate that I might need help, but in looking it over, I think I’m going to need a BOATLOAD of help. For one thing, l have no real way to duplicate the issue on my local machine, due to having no connection for checks. I think I’ll need to see if there’s some way to fake a check payment going through—otherwise, I’ll never see what’s happening with the button behavior.

Thankfully, the release date for this is March. I think my first plan of attack will be to go over this with our product owner and our BA, to make sure I’m understanding what I’m supposed to be fixing in the first place. I realize I probably should have come to that conclusion at 9:00 a.m. this morning, rather than at 5:00 p.m., after an entire day of trying to trace through tons of code in an attempt to understand the general process. The good news is that I think I’ve pinpointed where the roles and security get determined in the code…

One a more cheery note, I had my knitting group this evening, and I’m finally done with both sleeves and body of my sweater! I just have to now join everything for the yoke.

Work Day 38: Where did the day go?

This is one of those days where I’m not really sure what I did, but I spent a long time doing it. It all started when I decided to check out two MONSTER user stories we have in the backlog. I suspect we are probably going to split them eventually, but for now I decided to see if I could understand what needs to be done. I’ll give you the Reader’s Digest version—NO.

One story deals with integration which, if you held a loaded gun to my head, I couldn’t tell you jack about. On a data level, I can tell you what happens, and even what time of day the different files travel back and forth between systems, but I have no idea about how the code works.

The other story deals with the resurrection of my old nemesis penalty payments. In the interest of anonymity, I won’t call them by my system’s very familiar code name (and we won’t go into the bad names I’ve called them for years). As a BA, I struggled with understanding the ins and outs, the bee-bopping of these payments from one system to another, when they’re added or subtracted from different values, when they aren’t accounted for at all—as well as their bastard cousins the REVERSE penalty payments. These are all treated very differently than other transactions. This particular defect user story appears to deal with some ghastly error the adjusters are having where they try to change the monetary type of the payment and the system loses its mind and decides to not pay the penalty amount to the claimant—or is it that it pays them again? Honestly, I really thought that once I became a developer and could see into the code, that this quagmire would make sense, but NO. For one thing, I haven’t quite ascertained WHERE to look for the code that governs all this…I’ve found the PCF files, but that’s it so far.

And then it was 6:00 p.m.