Tag: database

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 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 23: Holy Cow…It WORKS!

This morning, after peering at files, searching for fo:table-layout=“auto”, tracing through all our code to see how a PDF export is triggered, scouring for ANY reference to Apache FOP (fun fact: FOP stands for Formatting Objects Processor) errors, I did a Google search on the specific error again and hit upon a reference about the columns widths needing to be specified. I check the two grids and THAT WAS THE DIFFERENCE. The grid that worked for the PDF export had column widths specified. The other grid had some specified, but not all. Once I added column widths and wrapLabel=“true” the PDF generated!

Now I just have to figure out how to unit-test. I did one test for one type of business and everything worked out perfectly. I’m having a devil of a time trying to test other business types due to the test data on my local machine being LAME. No other business type appears to have fully-fleshed-out claims with reserves and payment transactions to test for my change. If I could figure out how to query the db files for my local machine, I could get a better idea of what data is actually available.

The Alum suggested perhaps creating a “patch” for my coding changes, and then trying to figure out how to connect to one of the lower environments, employing my patch. I was confused back at “patch,” never mind the rest of that sentence.

And don’t even MENTION that dreaded “GUnit” test…

On a non-coding note, I’ve begun casting on for my new sweater! I still have to wash and block the sheep sweater I’ve been working on all summer. It’s probably going to be next Spring before I finish the new sweater, but at least it will be a nice, easy project to do during my continuing coding education saga.