January 2020 – WildKnitter Codes

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!!!!

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.

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…

Going Forward…

I’ve been pondering how to move forward with my blog. I know daily spleening about my ups and downs attempting to learn Java and JUnit testing are rather redundant and tedious. I may start blogging two or three times a week. If nothing else, I need extra time to finally make it through my Udemy course!

I’ve also been thinking about how to keep my JavaScript, HTML, Node.js, and CSS skills fresh. I ran into one of my fellow Code Academy classmates, and he mentioned needing to “use it or lose it.” It’s almost like a higher power was speaking directly to me. It’s interesting…our instructor has stressed the importance of having a side project, along with one’s coding at work. In fact, he explained that if you’re looking for a new job, the first thing employers want to see is what you have out on GitHub that you’re working on. I’ve asked around, though, and many developers at work have told me that there is no way in hell they ever have the spare time to do this–especially mothers with small children.

However, I think I have an idea, for something that might encompass keeping up my skills AND having fun with yarn. I’ve been googling. There are TONS of websites devoted to knitting pattern generators (knittingfool.com being one I’ve used), there don’t seem to be any crocheting pattern generators, other than for “graphgans,” which are afghans with a design or a picture on them. There are literally generators out there where you can scan in a picture of your dog and they will spit out a pattern (filet crochet, knitted, afghan crochet, single crochet, etc.) for you to make an afghan with Fido emblazoned on it. I’m thinking I could try a knitting generator, to get my feet wet; but I think I’d ultimately like to make a crochet sweater pattern generator. I’ve tried using ones for knitting, plugging in a crochet gauge instead, but the increases and decreases for crocheting are quite different, AND they’re different for different types of crochet stitches. I DO still have a domain name out there that I bought back when I did my first HTML/CSS project for class…

This could work…

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 49: Training and more training…

…or, am I EVER going to figure out all this stuff?

This morning we had another CodeAcademy continuing training session — this time for client-side JavaScript testing. We worked through Mocha and Jasmine examples, with our takeaway being to modify the code to add to the constructor, and experiment with different tests. While I can understand this kind of testing, I’m still struggling with my Java JUnit testing for my user story. I cannot get my JUnit test to work in Eclipse. In looking at it, and comparing to other JUnit tests in our code, I think I’m missing a few things, and oddly, my test isn’t “tracking”—I’m getting an error saying the class isn’t “found.” As it is, though, none of the JUnit tests are working for my setup, so my issues may run a bit deeper than just a few misplaced @Test indicators.

I decided to eat crow and work through a Pluralsight video on JUnit testing. I’m also going to try to make a push to work through more of the Udemy course, as they do cover JUnit testing further along in the course. I even bought a book on JUnit testing (Pragmatic Unit Testing in Java 8 with JUnit by Jeff Langr—God Bless Amazon…). Hopefully with all this and having my mentor help me out (I’m going to need help setting up Spring anyway), I’ll muddle through.

All this setup and testing for a few lines of code change…it’s just unbelievable!

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…

Workday #46: Spring Forward!

Since yesterday didn’t contain enough drama, I elected to multiply this tenfold by taking on a new user story. On the surface, it appears to be something I can handle–simply change the driver age for a commercial or personal auto claim so that the age is Age at Loss vs. Current Age so that it gets passed to our other system correctly. I waded into the integration code for Spring Batch in GitHub and I think I’ve narrowed down the issue to one method in one class. It appears to be an overloaded method, where if you only pass the date of birth parameter, you get the Current Age; however, if you pass the date of birth AND the date of loss parameters, you get the Age at Loss, which is what we’re after. I’ll have to scour all the code of course, to make sure, but I’m fairly certain that that’s all one would need to fix.

DOING this is going to be another matter. I have Eclipse installed on my work and home machines, and I’ve been working with it a bit it at home while doing the Udemy course; but I suspect it’s going to be a lot more complicated with our crazy GitHub branch system. I did try to follow the Spring Batch/Maven setup directions on the Wiki in our GitHub, but I can’t even get past Step One without being told I don’t have access to create a Maven User Token. No, I don’t know what that is, either, but right now it makes no difference, as I can’t create one.

I’m going to meet with my mentor on Monday, to hopefully figure all this out. The poor man, probably remembering the fiasco that was yesterday, put me off until Monday afternoon–probably sensing I’m going to need a lot of direction. My plan is to read over everything in advance, so I don’t waste his time.

Oh, I haven’t even gotten to the best part of the day. I hosed my new Guidewire 9.0.7 setup–as in, I accidentally DELETED the entire thing! I was attempting to be proactive by zipping up all the old files for 9.0.5 and deleting them, but in so doing I accidentally deleted the wrong files. On a more positive note, I really do have practice now installing a new version, and I even managed to connect the database correctly.