Tag: frustration

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.

User Story TWILIGHT ZONE…

I’m sorry to inform the masses that I’ve had my first user story QA FAIL. It happened with my Spring Batch jobs. Our BA, who’s testing my story, informed me via Rally that “Criteria 1 failed.” I’m not sure if that’s the first scenario in the user story; or he’s referring to the main criteria, where driver age needs to be the Date of Loss and NOT the age at the time of the exposure date or the current date age. Honestly, I tested the bejesus out of this thing in JUnit testing, and once we pushed it to the test environment I did more testing and checked to see that the correct age was making it to the outbound file—the damned thing WORKED, without a doubt.

I’m not sure what happened. I checked GitHub and there was some sort of change in one of the jobs I altered—tomorrow I have to figure out what the change was, who changed it, and when it was changed. I know one of our other developers had an issue where his code wasn’t working, either, and it was in the SAME job—now whether the change is affecting me or his change to FIX his issue is affecting me, I’m not sure. Previously, I ran his JUnit tests along with mine before I pushed my changed code and neither of our changes had an issue then. Weirdly, whatever changed didn’t alter my actual code change—it’s still in GitHub. If my code didn’t change, then the only thing I can think of is that perhaps someone altered/redefined date of loss in some way…

Unless I can figure this out by eyeballing it, I’m probably going to have to bring the entire March branch into my local and debug to see where the error pops. Maddening.

Merge and Purge!

This was one of those days where you think you know what’s going on…and then someone speaks up and all of a sudden you’re COMPLETELY at sea.

After my triumphant completion of my user story, I pushed the code to GitHub and submitted a pull request to my coworker, who is doing my code review. Life was GOOD, until he explained at our daily checkpoint that he couldn’t merge my code due to “conflicts.”  

Heh?  The last I’d checked, everything was fine with my code, and I was able to do a pull request.  Silly me—I’d confused doing a pull request with someone actually being able to merge my code with the release branch.  After the meeting, and after having given blood this morning (the vampires were merciful…I’m only a little bit dizzy and woozy this time) I checked my pull request in GitHub again.  And yes…this is another instance of “Pam needs to learn to read.”  Underneath that nice green “Requested” checkmark I’d been so excited to see, there was a big ugly message informing me that there were conflicts.  I delved into this and realized that when I’d pushed my request, I hadn’t done a refresh from the release branch.  In the meantime, between when I’d checked out the code and done my push, my other coworker had pushed HIS changes to two of the same jobs I’d modified.  Thankfully, I’d saved out my changes, so I refreshed my branch with the release branch, bringing in his changes.  I modified the code with my changes, retested the JUnit tests again, and then pushed the two modified files out to my branch on GitHub.  I’m not sure if I’m supposed to do another pull request or what, so I’m meeting with my coworker tomorrow morning at the crack of down (yes, he’s the one in India) to get some assistance in the matter.

I hope to SOMEDAY understand GitHub…

On a more positive note, I am working on another user story.  I’m very proud of myself, as initially this looked like a completely impossible change that I’d never figure out.  Upon delving into the code, though, I quickly figured out that I only needed to change two classes.  One change uses a series of “else if” statements, which I wasn’t quite sure of how to code—I know how to do this in JavaScript and Java, but I wasn’t sure of Gosu, and I certainly wasn’t going to ask anyone.  Asking how to code an “If-Then” statement or its bastard cousin the “If-Then-Else” or the “Else-Ifs” is probably grounds for someone taking away your company-issued computer, and possibly your lunch money.  All kidding aside, I was too embarrassed to ask, so I ended up scouring the code until I found a similar example and copied that format.  The rest of it I relied on the Guidewire Studio hints to push me in the right direction. It really is amazing how well the application helps you out.  My next task is to try to set up my GUnit tests for this.

But first I must go take some iron and go to bed…

HappyDanceHappyDanceHappyDance!!!!

I DID it!!! I finally figured out what I was doing wrong with the JUnit testing. There is a line of code at the beginning of the test for a field that says “contextData.” Initially, it appeared to be some sort of memo or reference. As I’d exhausted every other option this week, short of Voodoo chants, I checked the field again and…I was wrong! Far from being a “memo field,” the code is actually used to pull in the data elements that have been changed in the payload. So, in my instance, I needed to add Date of Birth, Loss Date, and Driver Age to this string, separated by pipes, so that these are be accounted for in the test.

As a result, I’m FINALLY returning data, and the correct data to boot! I need to write up more JUnit tests for different scenarios, but at least I now understand how these particular ones work.

I also participated in a fire drill today—okay, it was more like a full-on 5-alarm blaze. Our BA (you remember him—the poor bastard who inherited all my work when I went off to Code Academy last July) found out that one of the user stories for his other agile group tanked in regression-testing. The developer who worked on it is offshore and was one of the many who was off for Pongal. It was my boss’ idea to put me on this as a learning experience, with the other developers. We all checked different things to see why this wasn’t working. My task was to scour the past release’s code for anything to do with the logic that was broken, and then compare to see what was overlooked and/or changed by the user story code in this release.

THEN, it occurred to me…I asked our BA, “What exactly DID the error message say?” I searched our GitHub repository for the exact wording, and FOUND it! The odd error message came from one of the new Gosu rules (.gr file) the user story added. I did my best to figure out what on earth the code meant that led up to it throwing an error. The other developers had in the meantime found other odd things to do with the test environment, so hopefully between all of us the group can determine how to fix the issue.

I have to say it was very exciting to discover that I can in fact troubleshoot code I had nothing to do with writing, and understand it! This is pretty good, in that I’m hopeless at troubleshooting knitting and crocheting mistakes for people when I didn’t personally create the article.

Now back to the JUnits! I’m hoping for a peaceful Friday to complete them…

HappyDanceHappyDanceHappyDance!!!!

I DID it!!! I finally figured out what I was doing wrong with the JUnit testing. There is a line of code at the beginning of the test for a field that says “contextData.” Initially, it appeared to be some sort of memo or reference. As I’d exhausted every other option this week, short of Voodoo chants, I checked the field again and…I was wrong! Far from being a “memo field,” the code is actually used to pull in the data elements that have been changed in the payload. So, in my instance, I needed to add Date of Birth, Loss Date, and Driver Age to this string, separated by pipes, so that these are be accounted for in the test.

As a result, I’m FINALLY returning data, and the correct data to boot! I need to write up more JUnit tests for different scenarios, but at least I now understand how these particular ones work.

I also participated in a fire drill today—okay, it was more like a full-on 5-alarm blaze. Our BA (you remember him—the poor bastard who inherited all my work when I went off to Code Academy last July) found out that one of the user stories for his other agile group tanked in regression-testing. The developer who worked on it is offshore and was one of the many who was off for Pongal. It was my boss’ idea to put me on this as a learning experience, with the other developers. We all checked different things to see why this wasn’t working. My task was to scour the past release’s code for anything to do with the logic that was broken, and then compare to see what was overlooked and/or changed by the user story code in this release.

THEN, it occurred to me…I asked our BA, “What exactly DID the error message say?” I searched our GitHub repository for the exact wording, and FOUND it! The odd error message came from one of the new Gosu rules (.gr file) the user story added. I did my best to figure out what on earth the code meant that led up to it throwing an error. The other developers had in the meantime found other odd things to do with the test environment, so hopefully between all of us the group can determine how to fix the issue.

I have to say it was very exciting to discover that I can in fact troubleshoot code I had nothing to do with writing, and understand it! This is pretty good, in that I’m hopeless at troubleshooting knitting and crocheting mistakes for people when I didn’t personally create the article.

Now back to the JUnits! I’m hoping for a peaceful Friday to complete them…

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 45: Back in the Saddle Again!

…but what on earth are my passwords???

It was a very nice holiday break marked by good times with our family and friends, a few cleaning projects, finishing knitting projects, endless cookie-baking, and five extra pounds I need to get rid off. Alas—what with all the preparations, festivities, tinkering with new gadgets I got for presents—I only got in ONE Udemy Java course session. The good news is that I hadn’t forgotten anything, so I’m hopeful that once I get past the 3,456 emails in my inbox, that I’ll be able to be somewhat functional.

…these were my thoughts BEFORE I got back to work and discovered we’ve gone from ClaimCenter 9.0.5 to 9.0.7. The email went out last week, when most people were out for Christmas. I had to update Guidewire, add in code for my two user stories (story #3 was usurped in my absence, due to requirement changes), retest them, and push everything out to GitHub for a code review again — for FRIDAY. It took until 2:30 pm just to have 9.0.7 fully functional in my local. My only consolation was that I wasn’t alone—other people had a ghastly time attempting the change. I took copious notes for the next time we have to go up a version, including additions to my ongoing error file, where I note down all the errors I’ve encountered so far and how to resolve them.

And a Happy New Year to you, too!

Work Days 42 & 43: Surely You Mock

I know…I’m combining TWO days in a row. In my defense, one could consider these two days to be a continuation of each other, as I’ve been in Gosu hell since yesterday. Unbeknownst to us, someone–in the interest of anonymity, we’re going to call him Earl–pushed a GUnit test (like JUnit tests, only for Gosu) that uses Easymock 4.0.1 out to the release branch. Fun fact: many of us are still on Easymock 3.1. I found this out the hard way when I needed to do a fix for the role user story, but was dead in the water when I got two compiler errors after creating my branch from the release branch.

Come to find out, this has been an ongoing drama of “Dynasty” proportions since December 5. For my younger readers, that would correspond to “Real Housewives of Beverly Hills-on-steriods” drama, like that chick screaming to the cat in all the memes.

Anyhoo…The initial alarm was raised in home office with–in the interest of anonymity we’ll call this fellow Gungho Carl. Gungho complained back on December 5 that he couldn’t compile. Gungho is actually a kickass developer of uber nerd cred, so if HE can’t compile, there’s something seriously WRONG. From there, for the next several days, there were a flurry of frantic emails back and forth with basically the known Gosu world within my company. The news eventually filtered down to our office in the sticks, and landed with my mentor. He’d only informed a few people about how to fix this (including Earl), as I don’t think he realized how many of us were still on 3.1.

Per his instructions, I updated to Easymock 4.0.1, fired up the server, and…drum roll…

I got 1,018 compiler errors!

As a temporary workaround, because I was really desperate to get my user story changes done and into GitHub, someone (The Alum) had me just modify the other guy’s GUnit test in my local machine to use a parameter in keeping with 3.1 (the test didn’t affect anything I did).

My mentor, who was NOT PLEASED with the workaround, helped me today to get updated with 4.0.1 correctly.

In other news, I was shown how to do Git commands from within Guidewire Studio! I haven’t created a branch from there yet, but I managed to add, commit, and push my changes. Very exciting.

I’m also happy to report that I just checked, and TWO of my user stories are now in the Release Path!

However, as of this writing, I still have MORE work to do on my role story. This is my favorite screw-up category called “Pam needs to learn to read.” I created my role, but apparently someone felt it needed to WORK. Go figure. To be continued tomorrow…

Work Day 39: Developing Envy…

I recently found out that one of my fellow Code Academy graduates is now working with Gosu, too. Someone mentioned that he might call me, looking for info, which I was fine with, of course. Long story short, he contacted me, but to ask where I was with the exams.

Exams?

Yes, you guessed it. HIS department is already having him do self-study courses for Guidewire and he’s already taken the first exam. So, far from being able to help him, he’s further along than I am. I swallowed all the pride I had and mentioned that perhaps it would make sense to contact another fellow grad who’s working with Gosu and who was a tech lead, so I’m pretty sure he’s probably light years ahead by now.

“Oh sure!” He exclaimed. “He knows EVERYTHING!”

I asked my boss about more training, and he’s planning to send me, just as soon as the department can scare up X number of people for a class. I told him I’d be fine with the self-study route, if they can’t. It was news to him that there was a self-study course, so he said he’d look into it, but most likely he’ll be sending me to a regular Guidewire class next quarter.

I’m trying not to be dismayed over how far behind I feel. I know I really shouldn’t compare. After all, the whole point about making this sharp detour in my professional trajectory was to be happy in my work. So far, my team is very happy with me, too, so…so what if a few people from class are a bit ahead of me? One person was a tech lead, so that was a given that he’d be ahead, and the other guy honestly should just bag our company and go work for NASA–that’s how bright he is.

I still feel envious, though…