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

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!

Unraveling, without becoming unraveled…

I seem to be unraveling all my previous dilemmas. That mysterious Gosu code turns out to be block code. That still means nothing to me, but now at least I know where to look in the documentation to learn more. I’m also happy to report that frantically posting my query about the damned nested if statements to the Guidewire Community site paid off. I got two suggestions, and the “.add” to an array solution worked! Why I didn’t remember this from my Java class, I don’t know, as it’s similar logic. Sometimes it’s tough to connect what you’ve learned with the current mess in front of you.

In positively JOYOUS news, that ghastly defect user story that spawned ANOTHER defect user story, has finally passed QA and it in the release queue! I suspected this might happen, as I ran a few furtive SQL queries yesterday to check was I thought might be our QA tester’s payloads to the integrated system, and they all looked good. I swear, I’m so happy I could cry…sometimes I really feel like the life of a developer is a series of roller coaster rides—devastating lows followed by meteoric highs. It’s exhausting, but I’ll still take this over being a BA any day.

The new guy got his Java quandary sorted out. He needed version 121 for our Guidewire Studio, but tech support had installed a higher version. He’s now wading through my instructions on how to copy over a database to his local machine, while also trying to figure out his on-boarding HR tasks (signing up for benefits, taking various online courses in our ethics and sensitivity training, etc.). He’s also starting his moving process this weekend, to eventually end up at our southern hub. I can’t imagine attempting to pack and move while learning the ins and outs of a new job, but he appears to be managing it. Seeing as no one is actually physically working at any of our offices at this point, it’s going to remain to be seen when he can actually darken the door of the place. I hear it’s very nice…when you can actually go inside…

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…

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!

You’re on all the TVs!

…or, my 15 minutes of fame.

A very BIZARRE thing has happened at my company in the past month. They are about to start up another Code Academy class for 2020, and they’ve just put out the notice on our Intranet site — with Yours Truly as the cover girl.

Perhaps I should back up. About a month ago, three of us alums from last year’s class were asked to come to Home Office (The Mothership) to have photos taken to shill for the new Code Academy campaign. We got down there and discovered that, far from being a few photos, this was to be a whole photo shoot! They had us walking around the building, carrying our laptops, looking like we were on our way somewhere important. We were coached, “Talk! Just like you would in any other everyday exchange!” I turned to the other two and said, “I don’t know about you, but our meetings are all Skype…we don’t walk ANYWHERE.” They has us sit at a desk, like we were working. They had us sitting around one of those collaborative tables, as if we were discussing something of great import—again, FAR from anyone’s reality. Any of my collaborations take place with people in Chennai at 8:00 am via Skype, or with people in the building at our desks, with someone inevitably teetering on one of those ridiculous padded filing cabinets that are supposed to double as a chair. We did all have fun with the photo shoot, and I was fairly certain my two much younger fellow alums were going to be the focus of the campaign.

But, noooo…

A few days ago, someone from another Agile team came up to me and announced, “We have a bet!” I looked at her…perhaps a bet over exactly when I’m going to self-implode from my ongoing GUnit testing cluster****? She got out her phone and showed me a picture she’d snapped. “Is this you? You’re on all the TVs in the building!” I looked and there was what had to be the worst picture anyone has ever taken of me, sitting at the desk pretending to work. She continued, “We were confused as to whether or not it was you, because that’s not your desk!” I raced down to the TV by the elevator and sure enough, there I was, large as life! I checked the Intranet site and there was an equally hideous picture of me with one of the alums. She, at least, looked good. I’m not sure what’s worse—that I looked every minute of my 55 years, or that they didn’t get all the detail of the hand-knit sheep sweater I was wearing—that one I knit all through Code Academy, to preserve my sanity.

Since then, I’ve had complete strangers stop me in the hallway, exclaiming, “Oh my God, it’s you! Your picture is EVERYWHERE!” The good thing about this is that I’ve also had people ask me about the Code Academy program. I’ve been able to give them an overview of the program and tell them that it was a fantastic experience, and that I’m very happy now that I’m a developer. Hopefully all this was worth it, and there will be a lot of applicants this year.

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…