challenge – WildKnitter Codes

Looking back and looking forward

The new Code Academy class is now two weeks in. They’re getting one more week than we did to complete their first projects. Also, this is one more week for the students to decide if this path is for them, and conversely for the instructors to determine who continues on with the program. I can’t decide if they’re lucky for the extra time or not so lucky, as they have one more week to agonize over whether they made the cut. Spoiler alert: other than early drop-outs, we all made the cut, as did the class before, so I don’t think they have much to worry about, if they put in the work.

I have been reflecting on what, back then, would have been good to know about the role I have now…

1. Unless you’re on some outlier team, you will LIVE the production release schedule. In training, I think we got a 1-hour overview of a typical release process. Luckily, I understood how this works from my days as a BA. However, I had NO IDEA how important it was going to be to understand all the phases, dates, and what I needed to do for each phase, especially the run-up to that crucial “Hard-Freeze” date. Trust me, you do not want to have to make any changes past that date. Your product owner will NOT be happy about having to put in a code-unlock request because of something you didn’t account for that came up in a last-minute QA check.

2. You will definitely need to understand how to test. Years ago, as a BA, I’d rail and scream when we tested a change and it didn’t work. “Don’t these people even TEST???” I’d complain to whomever would listen. I didn’t get just how hard it is to test code from one’s local using limited data. I’ve had to give myself a crash-course in updating, deleting, and creating data on the back end using SQL just to get enough data to cover the bare minimum I need to test a user story. Whatever language you end up using in your new role, I highly recommending that you become extremely familiar with whatever testing tools are available to you. I’ve shared ad nauseum about my struggles with GUnit and JUnit testing, but I’m slowing getting the hang of this kind of testing (coworkers, STOP LAUGHING!).

3. Speaking of user stories, we are pretty much all an Agile/Scrum organization now. Once upon a time, we were Waterfall which I LOATHED, both as a mainframe developer and as a BA. We all marched toward a project production date (which had changed four times) with faulty outcomes, because we just HAD to make that date—which, of course, would get changed again, due to some outside constraint. I find Agile to be better, because it’s much more flexible, and you get immediate feedback on what you’ve created so far. Instead of the dreaded “Day 2” project, you get to make adjustments and bug fixes in the next sprint. My Agile team works Kanban, which is geared toward more of a production environment—we are technically “maintenance” so this works beautifully for us. Once you get to your new team, and if they don’t bring it up, ask about Agile training.

4. Don’t be afraid to speak up if you’re having difficulties. Your team is going to be forewarned that you are a junior developer and will need some assistance. You will have a mentor to help you with basic coding issues—mine has been a God-send.

5. Eventually, you are going to be in a position to help someone else. Remember all the help that your long-suffering coworkers and mentor have given you and do your damnedest to be of assistance.

6. If you’re really stressed, walk away. Go to lunch, take a walk, disconnect from the coding for a bit. Your upcoming instructor Dana is going to tell you to do that, and when she does—listen and do it! Yesterday, I was at my wit’s end over some damned “500” errors I kept getting when running a SOAP UI project with my local machine to test my code (another one of those nifty testing tools to become familiar with…if I weren’t married, I go kiss the creator of SOAP UI—it’s the best!). Anyway, as luck would have it, I had to leave because I had a doctor’s appointment 30 minutes away, which gave me a good long break from the task at hand. After I returned, I looked at the code again and the SOAP UI results, and figured out the issue. I hadn’t brought in code that another developer had committed to GitHub that morning. Also, my SOAP UI project hadn’t refreshed for some reason. The logs showed updates from a previous version of my code. Once I remedied all this, I was able to run my code with no issues!

To sum it up, my new job has been hard, but definitely worth it. There were unforeseen challenges, but I’ve been able to persevere with the help of many incredible people. To the new class, keep plugging away, both in class and in your new jobs, and you will succeed!

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!

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…

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 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 Day 44: Wrapping it up…

…only a WEEK left to shop!!!

I’m about to be off for the rest of the year, so today was a day of frantically wrapping everything up at work. With a coworker’s help, I managed to solve my role story issue—I even crossed the big frontier of modifying a CLASS…with a new FUNCTION! Okay, he had to help me write it correctly in Gosu, but I did manage to figure out where it would go and what it would need to do. I even managed to avoid a tech-debt situation by putting the code in a class rather than in the pcf.

I don’t want to lose the knowledge I’ve gained, so in addition to my frantic holiday shopping (yes, I’m one of those people who runs out at the last minute), I’m also planning to spend time every day on my Udemy Java course, and reviewing the Gosu documentation.

Oh, and of course there is important knitting and crocheting to be done! I’m making progress on the sweater I’m planning to wear for Christmas.

img_1405-1

Work Day 41: Making it official…

I’ve decided that I’m just not right in the head…remember that defect user story I was scoping out—the Penalty Payments from Hell? We were having our checkpoint this morning, and we were discussing backlog items. One person grabbed the Integration story (oh, DARN). That left my nemesis. Remind me never, ever again to jump in feet first during a lull in the meeting conversation. As no one else was leaping up and down for the payments defect story, YOURS TRULY decided to be plucky and volunteer to do it. Granted, I did indicate that I might need help, but in looking it over, I think I’m going to need a BOATLOAD of help. For one thing, l have no real way to duplicate the issue on my local machine, due to having no connection for checks. I think I’ll need to see if there’s some way to fake a check payment going through—otherwise, I’ll never see what’s happening with the button behavior.

Thankfully, the release date for this is March. I think my first plan of attack will be to go over this with our product owner and our BA, to make sure I’m understanding what I’m supposed to be fixing in the first place. I realize I probably should have come to that conclusion at 9:00 a.m. this morning, rather than at 5:00 p.m., after an entire day of trying to trace through tons of code in an attempt to understand the general process. The good news is that I think I’ve pinpointed where the roles and security get determined in the code…

One a more cheery note, I had my knitting group this evening, and I’m finally done with both sleeves and body of my sweater! I just have to now join everything for the yoke.

Work Day 31: That thing from WAY back there…

Today was one of those days where I spend AGES trying to figure out where I went wrong with a GUnit test—this was the infamous “All Items” test. For some oddball reason, although the specific GUnit test I’m fixing was fine, the entire shebang had errors up the ying-yang. Basically, out of over 1000+ tests, only about 30 tests passed! I tried backing out my tech debt story code and reran the entire thing, and AGAIN, I had multiple errors.

Then I remembered. Back when we were setting up Guidewire, the Alum had me comment out some code in the build.gradle file after I’d brought in the November branch, before I fired up Guidewire (the code is apply plugin: ‘com.guidewire.cust-dist-deprecated-tasks’). Once I’d done that, I had to uncomment the code before firing up the server.

I realized that I had checked out a new branch (December) for this story. On a whim, I closed out of everything, commented out the plugin code, fired up Guidewire, and then uncommented it again before running the “All Items” test. Sure enough, that seems to have done the trick! The test without my code ran fine, albeit with 50 errors this time around (people have added tests since November). I need to now bring my code back in and run everything again, but I think I’m going to shut everything down and start anew like last time, to make sure.

As it is, I think I may need to adjust the code. For one of the jobs there have been many updates since June, and I think at least one block of the fix is a repeat of something that was added in later. I may try to run it first and then if I get errors, I’ll attempt to fix what I think is off.

Tomorrow is another Continuing Ed session with our Instructor. I’m attempting to cram in the reading from last week, review what we did, and review the info for tomorrow. Miraculously, he’s going to be going over some Java code. I’m not sure what little elf whispered in his ear to arrange this, but I’ll take it.