Tag: logic

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…

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…

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…

Work Day 41: Making it official…

I’ve decided that I’m just not right in the head…remember that defect user story I was scoping out—the Penalty Payments from Hell? We were having our checkpoint this morning, and we were discussing backlog items. One person grabbed the Integration story (oh, DARN). That left my nemesis. Remind me never, ever again to jump in feet first during a lull in the meeting conversation. As no one else was leaping up and down for the payments defect story, YOURS TRULY decided to be plucky and volunteer to do it. Granted, I did indicate that I might need help, but in looking it over, I think I’m going to need a BOATLOAD of help. For one thing, l have no real way to duplicate the issue on my local machine, due to having no connection for checks. I think I’ll need to see if there’s some way to fake a check payment going through—otherwise, I’ll never see what’s happening with the button behavior.

Thankfully, the release date for this is March. I think my first plan of attack will be to go over this with our product owner and our BA, to make sure I’m understanding what I’m supposed to be fixing in the first place. I realize I probably should have come to that conclusion at 9:00 a.m. this morning, rather than at 5:00 p.m., after an entire day of trying to trace through tons of code in an attempt to understand the general process. The good news is that I think I’ve pinpointed where the roles and security get determined in the code…

One a more cheery note, I had my knitting group this evening, and I’m finally done with both sleeves and body of my sweater! I just have to now join everything for the yoke.

Day 56: Breaking it down…

After my little adventure last night where I almost permanently hosed my server, I decided to leave well enough alone for now and just go with the pages I’ve rendered so far. If we’re going to have to rewrite pages in Angular, I’d just as soon not have too much to convert. I do want to work on eventually converting them all, so that I can practice different types of server routing…Oh my God…I really AM turning into a nerd…

Today’s deeper dive into Angular was a bit better than yesterday, although I’m still not sure HOW we’re going to pull off rewriting our pages. I’ve been reading ahead and it STILL looks confusing. I’m hoping that as we go along it will become clearer. I get the concept of breaking things (the partials and views we have now) into components, but we’re launching into another round of divding things up further into routes, components, and providers (services). We did a few of these today and I STILL have no idea how to determine what goes into which type of file.

In other more exciting news, I believe I’ve figured out how to vary my nav bar using Handlebar conditions, depending on whether a user is logged in or not. My next step is to figure out how to pull this off for users who are admins, so that other users (a.k.a. the unwashed public) aren’t privy to the admin link.

Actually, after last night’s adventure, my next step is to go to bed!

Day 48: Deer in the Headlights

This was one of those days where I almost stormed out of the classroom. I had to remind myself that we only have a few more weeks before we’re going to be REALLY confused in our new jobs, and that this is probably a picnic in comparison…

There is something dreadful about learning things piecemeal, and then having to cobble it all together for an assignment—I know…just like real life. Today we combined login/registration screen logic, get and post logic, Node express, listing out file data, etc. into one site. The truly mind-bending thing was that we used Node Express Generator to spit out the scaffolding, and then we had to take all the bits and pieces we’ve learned this week and somehow apply them to this new format.

Among the disasters:

1. My site got completely hosed by the ****ing layout.hbs file. What was a normal-looking index page all of a sudden resembled some mutant atrocity. The only way I can describe it is that it looked like our cat Jack jumped on the keyboard in the middle of coding and then used his ass to press “save.” This particular issue turned out to be due to some random css code I’d somehow copied in by mistake for my login page formatting.

2. Partial hbs files are now unnecessary due to the aforementioned layout.hbs file. This has COMPLETELY wiped out the careful work I’d done previously dividing page contents into the partials. NOT THAT I’M RESENTFUL.

3. I also struggled over trying to figure out if I needed one script file or one per page, seeing as there was overlapping logic.

4. I compared notes with others, and think we all suffered from tiny gremlins scurrying away with what’s left of our brain cells, because many of us could not, for the life of us, remember how the hell we listed out fields into an unordered list, let alone how we previously did gets and posts in AJAX calls.

5. I personally kept getting confused over what went in server code and what went in regular front-end script code—especially since we’ve been introduced to routes, or as I like to call them, the bastard cousins of server script.

I’m hoping to gain more clarity tomorrow, as we have to combine everything into a Friday project that we aren’t starting until 1:00 p.m. The idea is to have NO actual html pages, except for bare-bones, as we have to use Postman (which I barely understand) to test the server code instead.

I have the ugly feeling that I’m not going to have a weekend…

Day 40: Frenemies…

More work on the capstone project today. I’ve just about got everything done except for all the validations. I got burned by my old friend “Is it a value? Is is a number? Is it a string???” (I really need to work this out before the final assessment…) I also was paid a visit by my best friend “Scope”. This is not the same thing as a waterfall project “scope-creep,” but rather the “I have no bloody idea where to put the damned variable” scope. Oh, I also met up with my new bestie “we need to use the CORRECT API” as opposed to the one that returns the entire damned data file.

With friends like these, One really doesn’t need enemies…

On a more cheerful note, I came home a restful evening with a woolier scope…I’m happy to report I’m at the shoulders and hope to get the neck done this weekend.

Day 39: I think I can…I think I can…

The big project is coming along! I’ve managed to figure out most of the pages, except for the team edit page, which I should be able to finish tomorrow. I figured out the AJAX command to delete a member, which means I should be able to delete a team. I actually got functionality up and running where, when I create a new team, the server code grabs the new team data and stringifies it. In my page code, the data is then parsed to isolate the team ID. From there, I attach it to the URL to bring over to the team details page. This means you can create a new team, and then are immediately directed to your new team’s details page, where you can start adding members. I sent what I did to the rest of the class so that they could do this, too.

I then spent a good half hour in GitHub Hell, as I made the fatal mistake of switching branches (I was in the wrong one) without pushing what I had done first—which of course was what I just described above. Luckily, I had documented it all in my notes, so I was able to do everything over again. However, I somehow ended up with GitHub conflicts which I didn’t resolve correctly. The only way around it was to do a Git Pull—which, of course was going to hose EVERYTHING I’d just done with my team ID URLSearchParams. Thinking quickly, I copied my entire project to another directory on my C: drive, did the Git Pull, and then copied everything back into my project and pushed it again. This time, it FINALLY pushed to my repo successfully. PHEW!

Day 26: For the love of God, PROOFREAD!!!

This has been entire day of Pam needs to learn to read…

Today we had a day of learning Ajax calls and event handlers. I also had a weird day of things not working due to:

1. typos (“it’s readyState, NOT readState”) I was desperately searching for half an hour for this issue, until my desk neighbor happened to glance at my code.

2. ghastly errors in reading a file, until the instructor pointed out that I was attempting to read an array file that was in fact NOT an array file. I’d copied the wrong url link! AND…

3. My personal favorite—the misplaced semicolon. It took coming home, eating dinner, then going back to the code to see that I hadn’t ended the onreadystatechange correctly. Once I moved the semicolon, my job ran without a hitch.

As much as these brain-farts are always hysterical, it makes me nuts to miss things so easily avoided. I suppose it does beat completely missing the entire concept of how to write the function!

Day 22: Lost in the DOM…

Day 22: Lost in the DOM…

This was just one of those days. It began well enough…I was understanding everything, and the first exercises went well. Then the **** hit the fan. I do realize that a huge part of what we do concerns interacting with the browser and the DOM; but I swear, at times I really miss our beginning labs, when all we did was code and run in the Code Runner console. The worst dread on earth is when you try to run your code, NOTHING HAPPENS, and then you have to hit F12 in the browser. Whenever I see that dreadful flaming red type, flashing angry error messages across the console, I always want to scream at the top of my lungs, “Dear God, WHAT FRESH HELL IS THIS???” Then I remember that I’m old enough have parented the vast majority of my fellow students, and that it would probably be undignified to cry and throw things.

Today, I spent a good part of the afternoon with the bloody F12 console. We’re doing some god-awful routine where we have to take a substr of similar <img> ids (image1, image2, image3) to get the numbers on the ends (1, 2, 3). Then we have to concatenate the “para” part of the paragraph <p> ids (para1, para2, para3) to these like some nightmare from Frankenstein, and — I’m not making this up — take the alt attributes of the img tags and shove that alt text into the <p> html.

I think it was after the 12th time I tried to make this work that I decided I really needed to knit…

I know…all the ghastly code is going to be waiting for me in the morning. On the other hand, I got a mental health break, and my little intarsia sheep are really coming along!