Tag: springbatch

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.

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!

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 19: A Class Act

On Friday, I did some more work with coderbyte. I figured out how to take each of the exercises and make some standalone Java classes. It gave me a bit more insight into how the syntax works. I tried to figure out how to take these same exercises and create them in Gosu, but that was one big goose egg. The Gosu Reference Guide is almost impossible to follow when it comes to looking up how to do a certain type of function/method. I do want to ultimately crack this, though, so that I can understand Gosu better. Unfortunately, Gosu is not a language where you can google your way to a solution. The entire thing is locked down tighter than Fort Knox.

I was going to watch the Pluralsight Spring Batch video, but I didn’t. I do still need to understand how that whole process works, if I’m going to be able to function on my team. We do have a lot of user stores that deal with integration.

On a more exciting note, my Saturday was spent at the New England Fiber Festival!

https://www.easternstatesexposition.com/events/2019/fiberfestival

We had a fantastic time! I confess there were yarn purchases. I bought eight skeins of stunningly beautiful yarn to make a sweater for myself. I picked a simple pattern that a) will look good on me, and b) will be a no-brainer to work on as I spend my upcoming months cracking code.

SW Merino – Bulky

%100 Superwash Merino

108 yds

Hand Dyed – “Brew”

www.yarnhygge.com

Work Day 18: Exercisin’ Java

I’m happy to report our instructor sent us a very cool site to do Java exercises:

https://coderbyte.com/challenges

It’s a bit less intimidating than codingbat. I managed to do quite a few of the exercises. I saved all of them, with tons of comments, so that I have a ready reference of the different types of functions. One of my side projects is going to be to see if I can write these same types of functions using Gosu. Speaking of Gosu, I did some experimenting for the first time with the code on my local machine. Not much of anything happened, but at least I took the risk. I was going to go hog-wild and do something mad like deleting a button, but that seemed somehow wrong. At the very least, I think I’m finally at a point where I can at least try out a small user story (low, low, LOW down in the list, and something no one will flip out over if it’s not done in a timely manner). I may need to figure out Spring Batch first, but I suppose I could try to do both.

You know, I’m really hoping that a year from now I’ll read this and roar with laughter over how far I’ve come by that point.

Work Day 17: Back to School!

…but all the other kids are WAY ahead of me.

Our first continuing ed session with our instructor was abbreviated. He’s having computer issues, so we mainly walked high-level through the object-oriented JavaScript code he’s got out in GitHub. We’re supposed to review this, and try to run it on our machines before our next session—later on, we’ll be doing more involved work, I’m sure. It looks like I’m going to have to get Node.js loaded onto my work laptop, as we’ll be using that. I’m not sure how well that’s going to interact with the rest of the apps on my computer. I think I’m going to ask my mentor and The Alum for their thoughts. I could possibly just do all the continuing ed work on my home laptop to be on the safe side…I’m going to load a copy of his GitHub code there anyway.

We also spent a good deal of time going over how we all are doing in our new jobs. Some people are doing very well, as either a) they don’t need Java, and/or b) they have people they can shadow. I’m at a standstill, as I’m still learning Java and Gosu, which is going GLACIALLY slowly. Honestly, I’m getting the most bang for my buck from the Udemy course at home, but it’s not very fast-paced. Some people in class have had good success using the online CodeAcademy site. I’m tempted to check it out, but realistically, between Udemy, Tutorialspoint, Pluralsight (zzzz…), studying our current code, and trying to learn Gosu (and somewhere in here I have to learn Spring Batch), I think I have enough going on. If I try to add one more learning tool, I’m pretty sure my head is going to explode.

This afternoon, a good friend pointed out that I should give myself a break. If nothing else, I’ve only had a decent work laptop on which to do ANYTHING for a short time now.

I hate feeling useless, though.

Work Day 14: A little help from my friends…

Another day of wading through more tutorials and documentation. The Gosu Reference Guide, at over 400 pages, is the War & Peace of software documentation. I did find examples that one can try out in the Gosu Scratchpad, which I’m going to try tomorrow. I do need to figure out how I ended up with FIVE copies of scratchpad in Guidewire Studio, and how to get rid of them.

I grilled more people on where the devil documentation is for how the Gosu jobs hang together and which are used for what, but every SINGLE person I quizzed, including developers I greatly respect, all had the same answer — there is none. One just has to “figure it out.”

I may have to start writing some documentation, if for no other reason than to preserve my own sanity.

In the meantime, after said respected developers gave me their two cents, they did help me out. One went over our GitHub Wiki with me, and even encouraged me to submit corrections for the wiki concerning the developer setup (after struggling through the process a few days ago, and figuring out certain things the hard way, I had a few suggestions). Another sent me links for further documentation on our Spring Batch process. He even sat down with me and showed me how to set up Eclipse. The Spring Batch Integration jobs are actually set up with a bit more rhyme and reason as to what they are and which integration system they’re tied to, so I’m hoping those might be easier to understand…

The best part was that he me introduced to Tutorialspoint. He showed me the tutorial they have for Spring Batch, but I also found their one for Java! https://www.tutorialspoint.com/java/index.htm. I started reading through it and it has exercises. I managed to do the first few.

One day I hope to eventually code real stuff…Mr. GitHub Wiki assured me that “No one is going to let you code yet.” Apparently, the idea is that once I have a better understanding of Java and Gosu, then I’ll most likely pair-program or shadow someone at first, or perhaps do a small user story.

I suppose it’s only fair, seeing as I’ve (according to HR) only been on the job 7 business days…