Greenshift 022: Letting The Bug Hunt Begin

So before my week-long trip, we left off in kind of a bad spot. The final relationship was not working correctly even though the initial implementation was fleshed out and bugs from edge cases were popping up in the other relationships. Although it may have appeared that we were getting close to finishing this initial phase of work, it turns out that in programming your work is never done.

So for the next few days I'm going to be going through some of these issues and figuring out some of these problems. This painful process is called debugging. In debugging, we'll scan and explore different lines of code to pinpoint errors and then correct them. And unless you get lucky, this process is usually somewhat long and painful.

The first thing that I did was to modify the view interface to label each relationship 1-5 and by initializing each result to a String with the value "nil" rather than using a null reference. These changes allow us to see which relationships are misbehaving and which are behaving correctly. We see the code that implements these changes below:

Next, I started up the server and opened up the view in my Firefox browser to see the initial results of the updated user interface:

We only get two results from our relationships which isn't great. But now we can see that Relationships #1 (Most Recent Post of Author) and Relationship #4 (Most Recent Resteem) return nil. And this behavior is correct since I haven't posted on my main account in a long time and the last person I resteemed hasn't either.

But we get nothing from our final relationship. This indicates that we have found a bug that is causing abnormal behavior. But as it turns out, there are actually two bugs that I found that both would have created issues with the final product:

1. Inverted Inequality
2. Misspelled Variable Name

The first bug was located when I compared the stored greatest contribution to the voting weight. The inequality was backwards. We would only grab a permlink when a weight was below 0 since we initialized contribution to 0. Thus, the greatest contributing upvote (a positive weight) would never be assigned to the final result.

The second bug was the one that was actually causing the issue with the view shown above. Because the variable was misspelled in the controller, the variable called in the view always held a null pointer. Thus, the reason we didn't see anything as opposed to "nil".

After fixing these two relatively simple bugs, we get the following results on the webpage:

And that's exactly what we want. An article which has received the greatest overall contribution that I have voted on using my main account. But now that we have fixed our relationship, we're not quite done yet. As we discovered last time, we're still next correctly filtering posts from comments and that's what I'm going to cover next time.