Although I haven't posted in several days, I have been busy-busy working on my object system. I've learned a lot just in these few days, and I am so happy with this new knowledge- I owe it a rave review;-) So here goes:
The day before yesterday, I spent all day programming my node and tree classes. Originally, I had stuck an empty main into my project just for the sake of getting it to compile, and did not create a test bed for any of my code. Instead, I went on and coded for hours, tweaking a method here and there and altering the flow of my entire program with a crazy domino effect...how unwise.
I knew the risks of what I was doing; in fact, it plagued me-- the thought of trying to eventually run this Frankenstein of a code. However, I kept telling myself that it was too far gone and I had already put so much work into it that re-writing it and testing would take too long. Later that night in class, Ed showed us a video on "Baby Steps" taken out of the move "What About Bob?" He described in detail, and even showed us an example, of how to work incrementally in tiny but significant steps. Coding a little and considering elusive edge conditions, then building and compiling. With the heavy use of print statement and console output, you could create a basic yet very useful test bed. Now I know, this sounds very logical and duh. But, how many of us programmers actually do that rather than jumping right in and coding a million things at once, only to have it break and be impossible to trace, resulting in many sleepless nights and headaches. Watching Ed do it, I realized that a lot of the pain was avoided not sheerly through experience or knowledge, but through caution and patience. I'd heard this before in other terms, but never seen it so successfully put to work. Cheesy or not, my new programming mantra is a quote from class:
"Always compile and build your work as you go. The 3 seconds extra that you spend saves you a lot more in debugging."
-Ed Keenan
That, and submitting small but significant steps of progress into Perforce looked to work wonders.
At the end of the day, I went home mentally exhausted and stressed out with no working code to show for it, once again telling my husband that I was dropping out of school (as usual). In the back of my mind though, I had a new spark of hope: the hope of Baby Steps.
-------------------------------------------------------
Now, on to yesterday. I came into the lab in the early afternoon, ready to try out these seemingly magical Baby Steps. I commented out the Tree .h and .cpp files in their entirety, commented out everything in my node .cpp except for my constructor, created a node in my main, wrote some print statements, and fired the rocket. Oh the beauty. This might sound utterly ridiculous to many, but the relief and satisfaction that I got out of seeing my code work, even if only in the smallest bit, was like a drug. I was hooked and set to work, repeating the process for every method. With each significant success, I'd submit my work to Perforce, happy as a duck in water.
I ended up changing a lot of my code, but the difference now was that I knew why I was changing it and if the changes would actually work. I debugged through problems much more easily, and this approach gave me the confidence and stamina to get a lot farther than I've ever gotten previously by just spewing out code like a dragon with heartburn.
Honestly, I highly, highly recommend this approach. To any coders out there who have heard this a million times and think its nonsense, I advise you to give it a shot. But a real one. Try it for a day. See how much farther you get and how much less pain it involves.
Last night, I went home happy as a clam with a lot more success-induced confidence than I had gained in the previous several days. I felt good. And today, I'm ready to rock this shit.
Wednesday, January 4, 2012
Continuing with the Object System
I continued working on the Object system today. After seeing Keenan's post on the forums regarding the node destroy, I went back and edited mine to account for its children and siblings. I haven't tested this yet as I am not finished with tree, and feel that it would take too long to write a stand alone test for this. Maybe I'm wrong though. I still don't always know the balance between testing and not testing, or in this case, knowing when to test.
I made my tree create which is now in charge of creating the root node. My destroy for tree is kind of crazy. I drew a small picture that doesn't express all of the potential situations very well and went off of this for my first run. I know that the logic is not all there yet as I was going off of my linear thoughts as I programmed. Tomorrow, I'll draw a nice tree out on the white board in the lab and walk through it, pointer by pointer. This should take care of more than the destroy, but rather the entire structure of my system.
I really hope that I'm on the right track with this. I feel good about it and like I'm ahead of where I'd normally be. I hope to be done well before the weekend and make this the pace for the rest of the quarter, but we will see! Tomorrow is a new day and a new opportunity to get this working as I intend! Also, no more Perforce issues thankfully;-) Hopefully, Keenan won't tell me that I'm missing a file on the day that it's due because I mis-clicked something though. Until I re-familiarize myself with it again, I'll have that little nagging concern in the back of my mind. Oh well, c'est la vie, you live and you learn.
I made my tree create which is now in charge of creating the root node. My destroy for tree is kind of crazy. I drew a small picture that doesn't express all of the potential situations very well and went off of this for my first run. I know that the logic is not all there yet as I was going off of my linear thoughts as I programmed. Tomorrow, I'll draw a nice tree out on the white board in the lab and walk through it, pointer by pointer. This should take care of more than the destroy, but rather the entire structure of my system.
I really hope that I'm on the right track with this. I feel good about it and like I'm ahead of where I'd normally be. I hope to be done well before the weekend and make this the pace for the rest of the quarter, but we will see! Tomorrow is a new day and a new opportunity to get this working as I intend! Also, no more Perforce issues thankfully;-) Hopefully, Keenan won't tell me that I'm missing a file on the day that it's due because I mis-clicked something though. Until I re-familiarize myself with it again, I'll have that little nagging concern in the back of my mind. Oh well, c'est la vie, you live and you learn.
Starting out with the Object System
So today, I finally got myself to start working on the Object System. After not programming for a little over a month, I kept pushing it under the blanket for fear of not remembering anything. Fortunately though (or at least in this case) programming is like riding a bike.
I wrote the node class and header for the tree class; ready to start implementing the latter. Thankfully, node builds! A good and hopeful start;-) I'm still a little confused about the tree's create method though. I know this sounds silly because you would think it does what its name suggests, but what exactly constitutes creating a tree? In the pseudo-code to call functionality that was distributed with the first assignment, the first call is to create a tree. Afterwards, it is destroyed, and then a node is inserted, so our tree now consists of:
a) 1 Node: the node that is inserted is the parent node and so we set it to be the root node and nullify its parent pointer?
or
b) 2 Nodes: the parent and a node that is now a child of that parent (this child is the inserted node). If case B is indeed the right approach, that assumes that create tree creates a root node and sets all of the info about the tree, like a constructor of sorts.
Actually, now that I have written this out and had this discussion with myself, it is starting to make more sense, and I am liking approach B. I already have my info struct set up and have a pointer to it in my tree class, so it lends itself well to this sort of implementation. I'll try it out later tonight or tomorrow and see! I have a feeling that this is the part of the coding process that will require a lot of diagramming.
I wrote the node class and header for the tree class; ready to start implementing the latter. Thankfully, node builds! A good and hopeful start;-) I'm still a little confused about the tree's create method though. I know this sounds silly because you would think it does what its name suggests, but what exactly constitutes creating a tree? In the pseudo-code to call functionality that was distributed with the first assignment, the first call is to create a tree. Afterwards, it is destroyed, and then a node is inserted, so our tree now consists of:
a) 1 Node: the node that is inserted is the parent node and so we set it to be the root node and nullify its parent pointer?
or
b) 2 Nodes: the parent and a node that is now a child of that parent (this child is the inserted node). If case B is indeed the right approach, that assumes that create tree creates a root node and sets all of the info about the tree, like a constructor of sorts.
Actually, now that I have written this out and had this discussion with myself, it is starting to make more sense, and I am liking approach B. I already have my info struct set up and have a pointer to it in my tree class, so it lends itself well to this sort of implementation. I'll try it out later tonight or tomorrow and see! I have a feeling that this is the part of the coding process that will require a lot of diagramming.
Subscribe to:
Posts (Atom)