Tag: secondcareer

Work Day 35 (and 36): Snowed in!

I apologize for my long absence, but we’ve been innundated with what Channel 3 is calling STORM ABEL. I’ll leave it up to your imagination to visualize the crazy weather graphics and the general hysteria of the weather people who are essentially in their element this time of year. The only thing more existing for them is hurricane season or the occasional tornado we get once in a blue moon. Instead of blogging, I’ve been spending my non-work time shoveling snow and bringing in firewood. Okay, there may have been some knitting, too…

My user story is proving to be a bit trickier than I thought. Once again, the easiest part was the CODE. Figuring out where to put the code has been a bit more difficult. This is essentially an XML script that I’m going to need to put somewhere to be picked up. For this, I had to pick an id number for the role entry that appears NOWHERE else, in any environment—production or lower (thank heaven for SQL). To test, I had to upload the XML file into my local machine—Thankfully, my mentor helped me to figure out how to do this. I was skeptical about uploading some random file into the application, but it worked! The new role was created correctly in the application and I was able to assign it to a user. Now I have to figure out how to get it into GitHub for the next step in the process. According to my mentor, this is another one of those crazy instances where I’m going to have to just directly upload the file into the script repository under the release folder, albeit as a branch.

In non-programming news, I had a lovely Thanksgiving with my family. I also made my surreptitious trip to my local yarn store to get DPN size 10 needles to work on my sweater. Due to a shocking episode of naked peer pressure, I walked out of there with 11 skeins of Universal Yarn Uptown Worsted and the pattern book to make the “Sophie’s Universe” crocheted afghan. The owner of the LYS had a beautiful floor sample out and I just lost my mind…along with a complete stranger in the store and one of my best friends, who actually DROVE to the yarn store, just to see that I got the yarn and pattern book. I believe I mumbled something about perhaps making it for someone as a present, when my friend said, “NO! You need to KEEP this one!”

Oh, yes, I also managed to finish my sheep sweater!

Work Day 34: Happy Thanksgiving!

Very exciting…I have another user story! The other developer assures me that this is a fairly easy one, although he’s very experienced, so it remains to be seen what his idea of “easy” is. I’m basically supposed to create a role for our system. He’s going to go over where I need to make the change, etc. It sounds like I’ll be updating an XML file, so that shouldn’t be too difficult.

For my tech debt story, I finally figured out why I was seeing odd updates, along with mine in GitHub. It appears I was attempting to merge to the MASTER rather than to the release branch. Thanks to the wonders of Google, I figured out how to change this in the pull request. Now the “updates” are all mine.

My blog is going to be quiet for the next week or so. I’m taking the week of Thanksgiving off. I’m probably going to take some of the time to get caught up on my Udemy course, as I really find that’s been the best resource for learning Java. When our instructor went over the examples this week, it was easy for me to grasp them, as I’d already done a lot of work with the Udemy course and Tutorialspoint, which is another great site.

Most of all, I’m probably going to make a surreptitious trip to my local yarn store to get my DPN size 10 needles and work on my sweater. I’m going to wash and block the sheep sweater so that I can show it off to my relatives at Thanksgiving. I wish you all a Happy Thanksgiving!

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 32: Git-in’ Trouble…

Our Continuing Ed session was awesome today! Working from home enabled me to see the presentation much better on my large monitor. We covered Java and our instructor compared Java object-oriented code with JavaScript object-oriented code. Our takeaway exercise is to add fields to both sets where the fields are missing. It’s always good to have practical exercises to work on. I took copious amounts of notes to share with a fellow student who couldn’t attend today.

In other news, I lost my mind with #%*$^*# GitHub again. They opened up the February Release branch, so yours truly followed instructions for bringing in the branch…not entirely successful. I got some ghastly error in Git Bash saying there was “no such directory.” I think it said “no such directory anywhere” as if to imply nowhere on THIS PLANET. Following the Alum’s advice, I checked out the branch from Guidewire Studio instead, which worked. I applied the patch for my first user story. Oddly, one of the gs files added for my second user story was STILL out there, even though I’d switched branches and done a pull request. I checked, and the rest of the second user story code wasn’t there—just the new gs file. As I have the patch for that one, I deleted that gs out before committing my changes to GitHub. All seemed to work out well…UNTIL…

I checked the pull request and realized that somehow the gs WAS IN THE DAMNED BRANCH. Despite deleting it, the file had managed to hitch a ride on my first story commit! I was pondering possibly wiping out everything and doing a git clone to bring in a completely fresh copy of the branch to apply the patch again, when one of my coworkers made a suggestion.

“Delete it out of GitHub.”

Heh? After having it drilled into us in training that we’re NOT supposed to do that???

“Delete it out!” He insisted. He even sent me a screenshot showing the tiny garbage can icon on the GitHub screen.

As it turns out, the system prompts you to enter a reason for your actions, and notifications go out, so there’s a trail at least.

It still felt sort of…naughty… 😈

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 30: Patching things up…

Okay, what was that I said last week about my tech debt story being a “learning opportunity”? Something to that effect? The good news: the story was completed by our former coworker, and the only reason that it never went to production was that no one had the capacity to test it, as it requires extensive regression testing. The bad news? The story was completed MONTHS ago, and some of the code has changed since then. I created a branch off our December branch, followed all my notes in applying the patch…and came up with “conflicts” in one of the jobs I was trying to update. After peering at the code, comparing, and figuring out which code was new since the story completion in July, I managed to narrow it down to a few lines that needed to be added to the “completed” story. I tried again…and again (I hit the wrong button and ended up reverting things back, so had to try again).

Fun fact! In Guidewire, if you try to reapply a patch, it doesn’t overlay. It REPEATS! Imagine my surprise when I then tried to fire up the GUnit test for the job the story is meant to fix, and got big honking compiling errors. The error came up as some mumbo-jumbo I couldn’t quite understand, until I looked at error line numbers and realized the code was some of the new code, and it was the SAME code, three times over. I checked everything else and every line of code added to the jobs was repeating three times.

After resetting everything and trying again, I finally managed to apply the patch and the newer code correctly. Before you ask, I did create a new patch with all the story updates and post-July updates. Everything appears to check out, but I still have to run ALL the GUnit tests to test everything, with and without the changes. Luckily, I’ve had some practice at this…

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.

Work Day 27: Continuing Ed…

…or, attempting to remember my JavaScript.

Today we had our first in-depth continuing ed session with our Code Academy instructor. He’s going forward with more JavaScript instruction, but he’s introducing us to Object-Oriented programming concepts which we can hopefully apply to our respective language quagmires. I was skeptical at first, but JavaScript OOP does seem to be similar to Java and Gosu OOP. My only beef is that, doing this via Skype, I couldn’t see our instructor’s double-display very well on my work monitors. He was demonstrating running different jobs, which I couldn’t see, while I was frantically trying to remember HOW (I finally remembered to “NPM Install”—DUH). It looks like I’m going to have a lot of W3 School reviewing to do to fully understand everything. I may just work from home on class days from now on—I have a large monitor that SMOKES my work ones. Also, there will be less background noise to contend with. Today, near my cube there was some sort of meet-and-greet going on that was getting rather loud.

Fun fact: There IS a difference between a code inspection and a code review! The code inspection is actually a function in Guidewire (Menu—Analyze—>Inspect Code…). I did this and managed to uncover some issues that had nothing to do with my changes. One issue had to do with PCF methods that really should be classes—this is more of a tech debt issue. We won’t mention the fact that <code> in a PCF should be separate, anyway. It’s the same blasphemy as having inline code in HTML. As my elderly Uncle Jim used to say, “It just isn’t DONE!” I asked about the errors, and our Tech Lead explained that I should just include screenshots with some notes explaining my findings, and let the code reviewer determine what is and isn’t an issue. I think this is the Tech Lead equivalent of “Don’t worry your pretty little head about a thing!” Although our Tech Lead is a woman and very nice, so I’m sure she didn’t mean it like that…I think…

The good news is that my boss, who was on copy for the code review request, is ecstatic that I’ve actually done some real work, as opposed to peering at documentation, doing exercises, and falling asleep in front of Pluralsight videos.

Work Day 26: GUnit testing hell, part 2…

…but there was light at the end of the tunnel.

My mentor explained that sometimes the GUnit errors have nothing to do with one’s code change, as you’re testing the entire code base, with other people’s code changes. He had me back out my changes (luckily I’d done a patch, plus took copious notes on what I changed), rerun the GUnit test, put my changes back IN again, rerun the GUnit test AGAIN, to see if the errors are due to issues in general or due to my code changes. Why I didn’t think to do this myself, I don’t know, but that’s probably why they pay him the big bucks to be a Tech Lead. Sure enough, the errors were the SAME, so my changes didn’t cause them.

Now I just have to figure out what the difference is between a “code inspection” and a “code review.” I emailed our tech lead, asking if I needed to provide anything else in order to get a code review. Apparently, I need a code inspection before the code review. Call me silly, but I thought these were one in the same…I scoured documentation for old user stories but there is no there there. The ones I found say “Code Inspection: non-applicable.”

On a more cheery note, my name made our division Town Hall meeting! Once for having 30 years with my company, and once for graduating Code Academy, along with all my other fellow graduates. Very exciting—I can’t think I’ve EVER rated a mention at the town hall meeting. Granted, my name appeared on a PowerPoint slide, but still, it’s really exciting to be acknowledged for something for which I’ve worked hard. Several people came up to congratulate me…for the 30 years. I’m not sure why they were more impressed that I’ve survived 30 years at the company rather than having survived coding boot camp, but I thanked them.