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!

Spinning up the new guy!

…and we pause here to ask, WHY ON EARTH DIDN’T MY MENTOR KILL ME WHILE HE HAD THE CHANCE???

I jest…our new developer is a seasoned Gosu developer whom we’ve evidently hired via remote control, seeing as we’re still at DEFCOM 2, virus-wise. He’s currently out in a state two time zones away, but plans to relocate to our southern office. So far, I’ve managed to help him navigate our tech support site from hell. I reassured him that, yes! This site is supposed to be an improvement over the old one! (Can you feel the sarcasm just oozing from my pores?) I got all my accesses six months ago, so natch, in that time tech support has completely changed the ordering process on the site, which makes me look like a complete moron (“Now go to ‘Security Requests’ and…NO—looks like we’re not going to be doing that! Click over here, and…NO, not THAT one, evidently…”). It’s taken two bloody days to get him completely set up.

It then has (so far), taken two days to get him set up with Gosu, because a) something ghastly happened with his Java installation, and b) he’s unfamiliar with GitHub, having worked with SVN previously, so we’ve been having a crash course in GitHub that I am completely ill-equipped to teach. I still have to go to my mentor or our team for help with the messes I get myself into with GitHub.

This has been all while attempting to navigate my latest user story, which is proving to be quite ugly. I’m not sure what spawn of Satan decided on putting those weird \s (or \r or \a — take your pick) notations in Gosu code, but honestly, if you held a loaded gun to my head I STILL can’t tell you what they are for. The best I’ve been able to figure is that they are a shortcut for arrays or views, depending on if the Moon is full or Venus is aligned with Jupiter, or Scorpio is rising. Up to this point, I’ve been able to either cut and paste blocks of this mutant script and modify it slightly or ignore it altogether. However, my current story appears to need me to use this odd code to arrive at a field in a connecting file.

Also, I have a ghastly logic issue. I can’t seem to figure out how to write something where if condition a, b, c, and/or d are true, then fire off ALL their respective error messages. If none of these are true, then go to the next function. I’ve got it working where it sees a true condition and fires off the error message—wonderful! The problem is that the different error messages need to fire off if one of these conditions is true, 2 of them are true, 3, or all 4. Right now, it sees the FIRST true condition and throws that error message, but none of the others (which are also true). I discovered this when I ran it for all 4 being true. Every single fix I do results in ugly compiling errors.

I really need to get the new guy up and running so that perhaps he can help me out with some of this stuff…or at the very least suggest a good algorithm class…

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!

For some lucky recipient!

It’s been a while…

I apologize for the VERY long time between posts! The fact of the matter is I had no inkling of just how tough it was going to be to do a remote Java/Spring class in the middle of the bedlam that is our Covid-19 crisis, while also attempting to do regular work when emergencies arose. I spent one ENTIRE weekend I’m never getting back attempting to solve and fix some ghastly error I’d made in one of my user stories. Oddly enough, far from this being an issue, I actually got a kudos for being willing to work above and beyond to fix the problem. I sort of think that it might have been better had I NOT made the mistake in the first place, but I’m not going to argue!

The class was a big help in enabling me to better understand Java and Spring. It actually wasn’t as bad to do an online class as I thought it would be. If anything, it was good because I wasn’t having to drive home through traffic, set up everything again at home, and slog through homework for ages. I was able to get any homework done much sooner, as I was already in front of a screen.

At present, we are all still working from home. I can’t complain, as really, we have friends who have either a) lost their jobs, b) had a pay-cut, or c) have to keep working with the public, as they are essential. Our essential friend is now facing uncertainty, as one of her coworkers has tested positive. We have two friends now who have had the virus, but thankfully have beat it–it took three agonizing weeks, though. So, my paltry issues surrounding connectivity (a can of compressed air blown into the ethernet slots solved the issue), misunderstandings (“What did you say? Your headphones are cutting out again!”), figuring out the mask situation (mine homemade one was an epic FAIL), and ailing vehicles (fun fact: a 16-year-old car with a 7-year-old battery is going to crap out if you don’t drive it for ages on end) — all of this pales in comparison with everyone else’s struggles. That’s why I’m so ANNOYED at that insipid “We’re all in this together!” slogan. We’re just not, really.

But enough belly-aching. For the sake of my sanity, I’m going to try to blog on a more frequent basis. And hopefully come up with a better mask.

I’m a much better knitter than sewer!

Training Redux…the Home Edition

As we left off before, I was all set to embark on the wonderful world of Java at Home Office. I was going to get a mini-vacation from my everyday work existence, hobnobbing with the city-folk again at The Mothership, visiting the city birds on the walkway, while FINALLY getting some much needed Java training.

And then the Bubonic Plague hit.

I don’t mean to make light of the very serious ordeal we’ve all been living through. In fact, I learned that a friend of ours in Florida has been extremely ill with most of the symptoms of COVID-19, but the hospital wouldn’t test her because her symptoms didn’t exactly fit the profile. She’s been sick for about a week now, and we’re all praying for her recovery.

In light of our global emergency, my company has sent most of us home to do our work—this would be another subject for a whole other blog post (or, “why do all my retired friends now think I’m available all day, every day, to drop everything to look at cute Facebook videos???”). I was mentally prepared for my class to be canceled. I’ve been yet again struggling with the bloody GUnit testing, and figured I was destined for now to continuously hunt and peck through the scant resources I have for answers, while attempting to work through more user stories–all while driving my coworkers nuts with all my questions.

But no…they’ve decided to make the whole four week 8:00 – 3:00 class VIRTUAL.

I’m relieved that I’ll be able to get the (much, much, MUCH needed) training, but I’m a tad nervous about doing this via remote control, so to speak. What if my connection crashes? What if I can’t hear what’s being said? What if coworkers break through with IMs in the middle of my training? I have indicated to people that I’m not going to have availability during class time, but you never know what may happen. What if our lawn guy picks NOW to come do the spring cleanup, causing the kind of cacophanic DIN that’s capable of waking mummified remains?

I did elicit the advice of my librarian friend, who earned her master’s degree online. “Don’t procrastinate!” She advised. She told me online learning definitely takes more self-discipline than face-to-face. Also, she recommended getting up and walking around during any lectures, to stay awake.

So…the adventure begins tomorrow!

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…