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

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.

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…

Work Days 42 & 43: Surely You Mock

I know…I’m combining TWO days in a row. In my defense, one could consider these two days to be a continuation of each other, as I’ve been in Gosu hell since yesterday. Unbeknownst to us, someone–in the interest of anonymity, we’re going to call him Earl–pushed a GUnit test (like JUnit tests, only for Gosu) that uses Easymock 4.0.1 out to the release branch. Fun fact: many of us are still on Easymock 3.1. I found this out the hard way when I needed to do a fix for the role user story, but was dead in the water when I got two compiler errors after creating my branch from the release branch.

Come to find out, this has been an ongoing drama of “Dynasty” proportions since December 5. For my younger readers, that would correspond to “Real Housewives of Beverly Hills-on-steriods” drama, like that chick screaming to the cat in all the memes.

Anyhoo…The initial alarm was raised in home office with–in the interest of anonymity we’ll call this fellow Gungho Carl. Gungho complained back on December 5 that he couldn’t compile. Gungho is actually a kickass developer of uber nerd cred, so if HE can’t compile, there’s something seriously WRONG. From there, for the next several days, there were a flurry of frantic emails back and forth with basically the known Gosu world within my company. The news eventually filtered down to our office in the sticks, and landed with my mentor. He’d only informed a few people about how to fix this (including Earl), as I don’t think he realized how many of us were still on 3.1.

Per his instructions, I updated to Easymock 4.0.1, fired up the server, and…drum roll…

I got 1,018 compiler errors!

As a temporary workaround, because I was really desperate to get my user story changes done and into GitHub, someone (The Alum) had me just modify the other guy’s GUnit test in my local machine to use a parameter in keeping with 3.1 (the test didn’t affect anything I did).

My mentor, who was NOT PLEASED with the workaround, helped me today to get updated with 4.0.1 correctly.

In other news, I was shown how to do Git commands from within Guidewire Studio! I haven’t created a branch from there yet, but I managed to add, commit, and push my changes. Very exciting.

I’m also happy to report that I just checked, and TWO of my user stories are now in the Release Path!

However, as of this writing, I still have MORE work to do on my role story. This is my favorite screw-up category called “Pam needs to learn to read.” I created my role, but apparently someone felt it needed to WORK. Go figure. To be continued tomorrow…

Work Day 33: Git-in’ Trouble…again

I swear, the most difficult part about being a developer is not so much the coding, but all the other stuff. Today, I managed to merge the tech story changes correctly and iron out the discrepancies by doing a side-by-side comparison of the code as it is now vs. how it was back when my coworker did the original patch. I managed to put his code in the right areas. I then did a boatload of before and after testing to make sure it worked. Fun fact: our February branch has 50 errors when you run all the GUnit tests. Of course, some of this may be due to a lack of data for certain lines of business. Thankfully, none of these apply to my changes.

I managed to checkout the branch and push my changes to GitHub. However, THIS time, three weird updates that had NOTHING to do with my updates went along for the ride! I’m not sure WHERE these came from. They appear to be other people’s changes. I’m not sure if these were already part of the branch or what the story is. No pun intended…

On a more positive note, my new sweater is coming along. However, I may need to make a LYS run tomorrow or the next day. I’m almost done with the body and will need #10 DPNs for the sleeves.

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.

Work Day 29: I’m just watching the wheels…

Sometimes, lately, I do feel like I’m living that John Lennon song…

Why on earth do people keep asking if I’m okay…if I’m adjusting to my new role…if I’m happy???

This week I’ve had, at last count, five people ask me how I’m doing. One of my BA coworkers said something to the effect of, “Oh, that’s right…you’re doing both now…” You know, in that judgmental tone of voice adopted by people who disapprove of bisexual people. I corrected her, “I’m actually NOT…I’m a developer now.” There was dead silence on the other end of the phone. “Oh…” Like I’d just told her that someone in the family died. .

I had a one-on-one with our tech lead today, and again…”How are you doing? Is there anything I can do for you?” I suspect this was a result of that crazy call yesterday when they found out that I’d run 1008 GUnit tests I didn’t need to, and was a bit fuzzy about complicated GitHub procedures. The good news is our offshore guy finished my code review and approved it, so I was able to tell her that. I also picked out another user story, which sounds ballsy, I know, but there’s a method to my madness. Our former team member partially completed it before he left and it’s a tech debt story. I figure this is a serious opportunity to learn from someone and figure out how to modify actual Gosu code at the same time—the quintessential case of “Copying off Tim’s Homework”…

My boss asked me the other day how I’m doing, but in his case I think he’s just excited for me. Also, seeing as the company has made a major investment in me, I suspect people above him desperately want to see it pay off.

My favorite was my friend at the gym. I call her “the old lady,” but she’s probably around my age. “What the hell is coding? Why do you want to do THAT? Why aren’t you just retiring?”

Honestly, am I happy? I am grateful each and every day that I no longer drive to work, sit in the car in the parking lot, and just DREAD going in the building. Every day is a new adventure. I swear, the company trained me and are paying me money to have a good time every day, solving interesting problems. It’s like an entire day of Sudoku and crosswords, only with a nifty computer that can churn through an entire suite of tests in an hour (even though I wasn’t supposed to do those).

Am I okay? I won the freakin’ LOTTERY!

Work Day 28: I wasn’t supposed to do that?

…or “When you assume…”

Our offshore developer did my code review. He got back to me with some points he wanted to explain. As it was early, our tech lead arranged a call for the three of us. May we pause to say here that going over code with other developers is WAY easier than having tall, towering arguments with six business people on whether or not they want the words “Total Cost” capitalized in a report or not.

After I explained the amount of “deletions” (my changes for the word wraps and width limits seemed to show up as deletes and adds), he walked me through creating a branch from GitHub to apply my patch. I hadn’t done this yet, as my change isn’t being released until February. Instead, I’d cloned the November Release repo to do my changes and created a patch. He explained that I could at least check out a branch for now and push my changes there, without affecting anything in the main release branch, as long as we get rid of it before the December release. That way, he can properly review everything I did. I know what you’re thinking—did you learn nothing in boot camp? Yes, we used GitHub extensively in Code Academy, but we were dealing with a master and maybe five branches, at most. The company GitHub is IMMENSE with many, many repositories for many departments, that have many branches, where you make branches from branches for user stories. You honestly need a Dramamine before you attempt to sign in to look at it.

He asked where my GUnit test and coverage report were—or at the very least the screenshots. I showed him where this was in the documentation, and he pointed out that I still needed a coverage report. Thank God I didn’t have the webcam on because I’m sure my eyes bugged out like a squirrel about to be rendered semi roadkill. He patiently explained how to create this in Guidewire—it was simply a matter of clicking an icon. My cat Jack could manage it, if he had opposable thumbs.

And THEN, he saw the dropdown where I’d run my GUnit test earlier.

“You ran…all the tests?”

I explained that I’d followed the company GitHub Wiki instructions to the letter.

“You ran ALL the tests???”

Come to find out, I was only supposed to run tests pertaining to my code.

“Is that why it took over an hour to run?” Honestly, the entire process was three hours of my life I’m never getting back again.

It gets funnier. He looked at my code again and said, “and since you only changed the pcf files, and not any classes or methods, you really didn’t need to run a GUnit test at all.” I pointed out the one class test I thought pertained, but there was no actual change to that class, and it didn’t directly affect my two pcf file sections, so it was out of scope.

We left off there, so that the poor guy (being 10 1/2 hours ahead) could go home and go to bed. I thanked him profusely and hung up. He hung up the phone and I’m sure either howled with laughter over the crazy lady who thought she had to run the ENTIRE block of 1,008 GUnit tests for two tiny list view pcf changes, or fell into a dead faint.

My boss, who’s still on a high from me doing actual work now, thought the whole thing was hilarious.