Rethinking My Strategy

Yesterday I had a few minutes while traveling to think about the swamp and I began to wonder whether I was fighting the wrong alligators.  I began to think it might be wiser to attack the more straightforward problems first and save the hazy one for last.  That way, I could make some real progress and feel better about my productivity rather than continuing to lament a lack thereof.

So I shelved PA2 for the moment because I would really like to see how the interface is expected to behave before I do any more.  I also decided to leave PA3 where it is for now because, although I have a decent start on it, I will need to design a clever test program to verify that different types of data actually can be read from the file.  So I decided to tackle PA4.  I wish I'd done this sooner, because after working on it for only a couple of hours last night, I was able to get a firm grasp of what needs to be done and I got the first three test categories of unit tests already working.

I may share some of my solution after I verify that it works for all of the tests.  For now, it's back to PA4.

Feeling Better About PA2

Thanks to the code that Keenan so generously shared, I'm feeling a bit better about PA2.  I now have a working doubly-linked list maintaining a set of heaps, and I'll soon be ready to start testing my allocations.  I still have to figure out the alignment thing, but I found a pretty good discussion of this issue in the game engine book so I'm sure I'll be able to handle it.

I must try harder to remember to keep up this blog.  It's too easy to let it slip through the cracks while trying to manage everything else that's going on.

Gonna continue trudging along now...

Falling Behind and Catching Up

Ugh!  My life is too busy for this class!  Extra projects from my boss, taking care of my baby son, a surprise visit from my mother, interviewing for publication, fulfilling my honor society duties, trying to stay on schedule with my capstone project plan, trying to figure out if it's even possible for me to participate in the Global Game Jam this year...it's just too much at once!

It's OK, I can do it.  I just need to focus on one thing at a time.  Finally today I got a chance to catch up on the lectures for this class, see what I've missed in the discussion forums, and get a handle on what needs to be done for the programming assignments.  It's not pretty, but it looks doable.

I have started on PA2 and PA3, but neither is very close to complete yet.  I plan to knock out one of them before I even start to touch PA4.  Juggling two of these things at a time is challenging enough.  I dare not take on three at once!

Alright, nose to the grindstone!  Go!

Farewell, PA1: A Poem

Farewell, annoying PA1.
Wish I could say that it's been fun.
I finished you early and did it with pride
Only to find the requirements lied.

The unit tests all failed with flair,
Expecting new methods I didn't put there.
My tests mostly worked by the assignment's decree,
But the automated version must disagree.

I skipped out on my job and stayed up all night,
Certain I'd find a solution that's right.
But now it's all done and the tests have all passed.
This lousy assignment can kiss my...something or other.

Big Lamentations Over PA1

So, a few days ago, I had the tree working beautifully.  Not everything had been tested thoroughly, but the requirements described in the assignment were verified and validated.  Children, siblings, recursion, and printing were working great, and I even managed to get all of the removal code working without a hitch.  From all that I could tell by the assignment description, it was finished.  Big happiness!

Then came the unit tests, which not only didn't match my interface, but also indicated that the design of my implementation was actually too good.  The unit tests actually required me to downgrade the quality of my design in order to make the tests pass.  It's painful, frustrating, and shameful.  I am not proud of some of the stupid things I've had to do just to get the tests to pass.  Big sadness.

There is one test that I cannot seem to pass no matter what.  There's a check in the unit tests to see if the root of a new tree is null.  Well, the assignment said that the root should not be removable, and my solution to this was to create a dummy root upon instantiation of the tree.  This way, the tree completely encapsulated the root and maintained complete control over it throughout its life.  The getRoot() function always returned the dummy root, which was always present and could not be deleted. No need to check for nulls and no worries about losing the entire tree in a memory leak.

I stand by the wisdom of this design as well as other aspects that I had to destroy for the sake of conformity.  But I can't find a way to make the unit tests pass because they expect the root to be null in a new tree.  If I make it null, then the whole thing crashes with access violations.  Big trouble.

What to do?  The assignment is officially past due and I'm stuck.  I think I just have to turn it in as-is.  I can't pull another all-nighter and still be able to perform at work tomorrow.  I've only had about eight hours of sleep in the last three days and I fear that it'll start to affect those who depend on me. Time to cut my losses, I think.  You can't win 'em all.

Perhaps tomorrow I'll start over on it and design it in the way the unit tests imply rather than the vague and incomplete specifications from the assignment write-up.  Better late than never, I suppose...even if the later version is worse than the earlier one.

Either that, or I'll start taking a look at PA2 and PA3, which I haven't even been able to read yet because I've been fighting with PA1.

Are we sure this is good experience for me?  Big skepticism.

Oh no! Fears Confirmed!

The fears I expressed in my last blog entry have been completely justified.  I got the requirements for PA1 implemented and working only to discover that my implementation does not match Keenan's unit test code.

So now I have a decision to make.  Do I change and simplify my implementation to match Keenan's, or do I take the easy way out and build some sort of adapter between his expected interface and my implementation?

It makes me sick that I'm having this dilemma the night before the assignment is due.  But it's OK.  I'm going to take the adapter approach and see where it gets me.  Surely there is some way that I get my PCSNode to peacefully coexist with Keenan's...right?

I'll  have to devise implementations for things like setChild and setSibling.  My code has no such methods, nor did it require them to get the job done. These methods weren't even hinted at in the assignment writeup so I did not anticipate them in the test code. I think I can figure out a way to implement setSibling by inserting a node just after the node the method was called on.  I guess setChild will insert a new node at the beginning of the list of a node's children.  I guess.

I feel a bit dismayed. I correctly suspected that last night's relief would be short lived.  Once again, I am a sad little coder.  :(

In the Eye of a Storm, Perhaps

At the start of the day, I was a sad little coder.  None of my remove or destroy methods were working.  They would either throw unhandled exceptions or they would simply have no effect.  Some careful debugging and a few rough sketches on scratch paper exposed the problem.  (Yes, one singular logic problem in one pesky little function.)

Look! I removed node I and it took G and J along with it, as it should. Also, you can see that the sibling function works. But is the level count correct? Should we be counting the root?

So now, as far as I can tell, all methods in all classes are working.  However, this is only the findings of my own testing, about which I have some serious reservations.

• My testing is certainly less thorough than Professor Keenan's, and I haven't tried using his unit tests yet. The messages on the discussion boards make it sound like I'll be facing trouble when I try to integrate the unit test code.
• In order to implement proper recursion, I had to modify several of the method signatures from what the PA1 assignment write-up specified. I'm afraid of what might happen if they're not compatible with Keenan's test code.
• I made assumptions about how some functions should work, like whether they should print recursively, and whether the root counts as a level. I don't know how heavily this will be weighed in the grading if I turn out to be wrong.
• I haven't verified beyond a doubt that there are no memory leaks.

I haven't slept much lately, so I'm calling it a night for now.  I'm ending on a high note believing that I have fulfilled all of the requirements for PA1, but in the back of my mind, I fear what the future may bring.  I may just be in the eye of the PA1 storm.

Goodnight!  Sleep tight!  Don't let the software bugs byte!

Almost Done With PA1

Hey, that rhymes!

Anyway...yes, I'm almost done with PA1.  I have precisely recreated the sample tree that Professor Keenan gave us in the handout.  I've been experimenting with different ways to show the tree structure in text form, and the best one I've come up with look like this:

It's just like Keenan's example.  It just doesn't look like it.

Other than maybe improving the appearance of my output, these are the tasks remaining before I call it done:

1. Finish implementing the PCSInfo calculations.
2. Do more thorough unit tests of all classes and methods.
3. Document the final solution.

PA1 -- So Far, So Good

I've been working on PA1 for a few days now and it's coming along pretty well.  At this point, I have the tree being created and displayed correctly as a result of a depth-first recursive traversal, so hopefully most of the battle is behind me now.  I still have to test the cleanup code and get the info calculations implemented, but I'm reasonably certain that I know how I'm going to accomplish that.

As for the designs I posted the other day, I had to make some minor adjustments once I got into the implementation details, but for the most part, it is the second approach I described. I'll follow up with another post on that later once I have everything working.

I hope everyone is doing well!

Programming Assignment 1: PCS Tree

PA1 has been assigned. I've taken a couple of days to let it simmer on the back burner for a bit, and I've come up with two possible ways to do this.

Approach #1

My first solution is to use the Composite Pattern, which is appropriate for many tree applications.  Here's the breakdown for this solution.

• PCSTree: The tree as a single unit that encapsulates a pointer to a PCSComponent root node.
• PCSComponent: An abstract class to be extended into leaf nodes as well as composite nodes.
• PCSNode: A leaf on the PCS tree. Extends PCSComponent.
• PCSComposite: A node that encapsulates a PCSList. Extends PCSComponent.
• PCSList: A linked list of PCSComponent objects.

Here's a partial class diagram of this solution.

Approach #2

My second approach is a less elegant but simpler version of the first.  Since all nodes in this system are technically the exact same data type, it didn't seem to make sense to distinguish between them the way the Composite Pattern does.  Instead, PCSNode can just encapsulate PCSList, and if its list is empty, that simply means it's a leaf.

Here's a class diagram.

I'm going for the second approach.  I'll let you know how it goes.

Getting Started in GAM475

Ready for some game engine programming?  Yeah!

Well...I think so, anyway.  This will be quite a different beast from my pet MHFramework engine, but the experience will be extremely valuable.  I'll become a better game developer because of it, regardless of what happens.

OK, let's rock!