Tag: developer

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…

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.

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!