Tag: coder

Work Day 40: The Meaning (or Query) of Life…

I decided I was sick of not knowing what the heck was lurking inside my local machine test data. When I first set up my Guidewire Studio, the Alum had me copy test data from our network drive, and for my three user stories I pretty much hunted and pecked for suitable test claims by making do with the application’s UI search. Don’t get me wrong—the UI search is fine for a claim handler to look up info for a particular claimant. However, it is not designed for a looney developer to spit out every single claim record containing a penalty payment (yes, I’m still looking at that story—there are no official takers for it yet).

I checked the Gosu Reference Guide and found a whole chapter on querying. It was a bit of trial and error, but I managed to use the Gosu “Scratchpad” to churn out every claim record in my test data! I also managed to churn out transaction data, but I ran out of time. Tomorrow I’m going to try to find specific types of transactions. It looks like there is more basic claimant data than actual transactions. At least now I can easily search for the type of data I need. I’ll have to figure out how to save the individual queries. I’m not sure if they’re the same file extension as other Gosu programs or not.

There’s nothing like discovering a new programming language skill to make you feel like Einstein.

Work Day 39: Developing Envy…

I recently found out that one of my fellow Code Academy graduates is now working with Gosu, too. Someone mentioned that he might call me, looking for info, which I was fine with, of course. Long story short, he contacted me, but to ask where I was with the exams.

Exams?

Yes, you guessed it. HIS department is already having him do self-study courses for Guidewire and he’s already taken the first exam. So, far from being able to help him, he’s further along than I am. I swallowed all the pride I had and mentioned that perhaps it would make sense to contact another fellow grad who’s working with Gosu and who was a tech lead, so I’m pretty sure he’s probably light years ahead by now.

“Oh sure!” He exclaimed. “He knows EVERYTHING!”

I asked my boss about more training, and he’s planning to send me, just as soon as the department can scare up X number of people for a class. I told him I’d be fine with the self-study route, if they can’t. It was news to him that there was a self-study course, so he said he’d look into it, but most likely he’ll be sending me to a regular Guidewire class next quarter.

I’m trying not to be dismayed over how far behind I feel. I know I really shouldn’t compare. After all, the whole point about making this sharp detour in my professional trajectory was to be happy in my work. So far, my team is very happy with me, too, so…so what if a few people from class are a bit ahead of me? One person was a tech lead, so that was a given that he’d be ahead, and the other guy honestly should just bag our company and go work for NASA–that’s how bright he is.

I still feel envious, though…

Work Day 38: Where did the day go?

This is one of those days where I’m not really sure what I did, but I spent a long time doing it. It all started when I decided to check out two MONSTER user stories we have in the backlog. I suspect we are probably going to split them eventually, but for now I decided to see if I could understand what needs to be done. I’ll give you the Reader’s Digest version—NO.

One story deals with integration which, if you held a loaded gun to my head, I couldn’t tell you jack about. On a data level, I can tell you what happens, and even what time of day the different files travel back and forth between systems, but I have no idea about how the code works.

The other story deals with the resurrection of my old nemesis penalty payments. In the interest of anonymity, I won’t call them by my system’s very familiar code name (and we won’t go into the bad names I’ve called them for years). As a BA, I struggled with understanding the ins and outs, the bee-bopping of these payments from one system to another, when they’re added or subtracted from different values, when they aren’t accounted for at all—as well as their bastard cousins the REVERSE penalty payments. These are all treated very differently than other transactions. This particular defect user story appears to deal with some ghastly error the adjusters are having where they try to change the monetary type of the payment and the system loses its mind and decides to not pay the penalty amount to the claimant—or is it that it pays them again? Honestly, I really thought that once I became a developer and could see into the code, that this quagmire would make sense, but NO. For one thing, I haven’t quite ascertained WHERE to look for the code that governs all this…I’ve found the PCF files, but that’s it so far.

And then it was 6:00 p.m.

Work Day 37: Admin Antics…

More GitHub hell today. The good news is that I got a code review and my code was approved! The bad news is that I had to get my code to the master branch for the release, which of course I couldn’t do, as I don’t have the authority. My code reviewer moved my code to the right location. I also had to create several more files for EACH environment we are going to need to update.

THEN…as instructed, I sent an email to our Test Environment Team, providing a link and explaining that I needed them to suck up my file into their vortex and plunk it into the next applicable Environment. This, of course, couldn’t be easy. My mentor asked, “Did you open an environmental ticket?” Sure enough, by the time I got back to my desk, I had a terse email telling me that I needed to open up a ticket. I found a random ticket in the system like my request, copied the basic verbiage to my ticket, and sent it off.

THEN…come to find out, there is ANOTHER document one needs to fill out when one adds any Admin data to the system. This document, of course, didn’t exist under the release folder for us yet, so I found an old one under another release, copied the format, added my role entry, and put it out onto SharePoint for the rest of my team to use for their release updates.

I’m not entirely sure I’m done filling out documents…it’s only Wednesday. I’m taking copious notes, so that I’ll know what to do next time I have to update any application data that requires a script.

AGAIN…the actual coding part of this took maybe 10 minutes of my time. I’m pretty sure I’ve spent more time flossing my teeth…

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…