The Final Push is ON!

I must admit that working full time and juggling 2 classes has been a part of my life the past few years, but the end is in sight now--effective May 4th there will be only 2 semesters left!  I must say that the two team projects this semester has really been a learning experience for me.  With both teams we had to overcome our personal scheduling (work, school and personal commitments) to accomplish our teamwork.  As the semester went on, I saw improvement in our communication, task assignments and even saw us looking ahead to the next problem early at times.  I learned a lot and gained confidence from accomplishing what we set out to do and wonder what else we could have accomplished if it weren't for the constraints of time holding us back.

Our last meeting was dominated by our patch creation.  Of everything we did on this project, this is something that we know we could have done better with.  Since we tackled 5 bugs and several improvements (instead of 1 big one) we didn't really think about making our patches as we went--which we realize now that would have made our work much easier.  We had the documentation and comments in our commits to cirdles, so "diffing" and making the patches wasn't too involved, but did take longer than they would have if we'd have done them individually.  I think we were so excited each time we met our deadline that we thought of the patch process as being done and enthusiastically jumped into the next bug.  We decided that if we sent 1 patch covering everything that Nathaniel could discount our entire patch if he disliked even 1 part of the patch.  By sending patches for the individual improvements/bug fixes we are confident that most (if not all) of our work will be incorporated in the next git update of the game.

The last remaining project for us (in this class) is to finish our presentation, and prepare it for our presentation on May 3rd.  Carlynn has started our presentation and has it on our subversion page so we can each add our parts and make changes as needed.  We'll work on finding times to go through it together before the 3rd and work out any problems we see, and then focus on our responsibilities for our other classes.  With the final goal at hand, we will push forward to finish strong...and for me?  Well, "Summertime's calling me."

Approaching the END!

After a pretty intense semester my group and I are gearing up for the final push to the finish line.  I have to say that I am extremely pleased at our efforts and enjoyed working with everyone.  We accomplished everything we set out to do and I am confident that each of us has learned much in the process.  With our success in finishing the 5th bug on our list (and several improvements before that) I honestly believe that we have made a real contribution to Sugar Lab’s Lemonade Stand!

Next on our agenda is to get these different patches we created submitted for Nathaniel's approval and hopefully integrated into the official Lemonade Stand source.  We discussed this earlier and decided it was appropriate to send a different patch for each of our improvement/bug fixes so that he can accept them one by one--or if there is fix that we made that Nathaniel is not satisfied with, he can leave that one patch out without denying the others.  Getting these patches submitted--along with our rough draft of our presentation is our priority this week.

While I am relieved that the semester is coming to a close, I must admit that this course in particular became enjoyable when we changed our focus to Lemonade Stand.  Since it is such a new program, there were many different areas that definitely needed to be flushed out and quite a few bugs that had not been discovered.  Our earlier foray into RapidSMS was valuable--but since it was an established organization with MANY followers, it was very hard to figure out how we (with our experience) could contribute.  Lemonade Stand was perfect...it offered us many things we could immediately see as problems.  We could work on these problems while not having to worry that someone else (outside our group) would solve it before we did.  Hopefully we'll see all our hard work included in the next git release of Lemonade Stand!

The End is in Sight!!!!

After some discussion and experimentation to prove the argument my team and I feel that we have completed our goal on bug #4 and that what I originally perceived to be an associated bug really wasn’t.  Since the Lemonade Stand wiki really didn’t have documentation as to the rules of the game (before we corrected that at the beginning of this project) there was no indication of what currency combination was expected.  We feel that (as in real life transactions) it is acceptable to break the 2 smallest denominations when necessary.  Nathaniel wrote this code to keep players from using something like: Pennies: 200 instead of Dollars: 2. Since his code is focused on the dollars, quarters and dimes first; he intended the ability to exchange 5 pennies for a nickel or 2 nickels for a dime in certain circumstances.  With that in mind, we decided to further explain this on the Lemonade Stand wiki so the player will understand the process.

With that completed, we are now discussing ideas for our last bug (although I don’t see the time to work on it before Friday) and we plan to finish that one before Monday.  We also have discussed ideas on our presentation for this and also our game plan of submitting all our fixes to Lemonade Stand sometime next week.  For now…back to the code.

That is a Pesky 'Lil Bugger!

When dissecting bug #4 for a decent plan of attack, I focused on making a clean solution that would insert an additional message for the condition where a player entered the correct AMOUNT but not the correct combination of (fewest) coins.  Once I found my culprit (where the comparison was being made) and the destination of the event messages I was well on my way.  My group and I discussed on Thursday our ideas as to what we thought was the best way to handle it and I went off—with my rusty Python skills—and started working with it.  It didn’t take long to get what we had perceived to be the problem fixed and working as we had discussed.  I did have to create a new method that calculated if the "amount only" was correct--otherwise I was injecting a different comparison in a defined method.  Once I was satisfied my code was working correctly I went ahead and committed my fix so that everyone in my team could have a shot at it before the weekend took everyone’s attention. 

Feeling satisfied I then went back and played the game with the express purpose of testing it (kind of hard because the game injects random events that play havoc with those profits—making me have to wait for it to give me the figures that I needed to test…so I just played and documented my input values at each turn.  After a while I came up upon some combinations that slipped through the cracks…for example, if you had a profit of $8.05 the code won’t allow you to use…Dollars: 8 and Pennies: 5 because it is looking for Dollars: 8 and Nickels: 1…..however, if you have something like $9.80…you can fool the game by typing in…Dollars: 9, Quarters: 3 and Pennies: 5 and it will accept the amount.  While this is the correct amount, to satisfy the fewest coins principle it should have been Nickels: 1 instead of Pennies: 5.  What I discovered is that if  you have an amount that uses 2 of the 3 top coins (dollars, quarters or dimes) then you can cheat and use 2 nickels OR 1 nickel and 5 pennies to make a dime or 10 pennies to make a dime, etc....but if you have something using like 50 cents or $1.10 it won't let you cheat

I’m not sure where to go from here…I have not been able to decipher how he is figuring out the calculation of “fewest coins possible” which is really slowing down my progress.  I am satisfied with the solution that I have to our bug, but it appears to me that we have uncovered a different bug in the process.  We’ll discuss it at out meeting time today…maybe we should contact Nathaniel to see if it is something he intended or not (to be able to exchange nickels or pennies in certain circumstances)…anyway it is something to think about anyway.  Overall I’m not too disappointed, but would rather have had every transaction as fewest coins possible or every transaction accept the correct amount…but that’s just me.

Progress and Success are a Welcome Sight!

At the start of class Tuesday, we were basically done with bug #3 although there was one little detail we wanted to add.  With our modifications the code no longer allows for the idea of overspending for supplies—and stays on the current screen forcing the player to enter a supply order they could afford; however, there wasn’t any notification of the problem.  We wanted the player to be notified that they were trying to order more supplies than they had cash for—so the player could correct their error.  I had a hunch that a particular method (draw_help) in the gui portion of the code would be where the message would need to be added, but was unsure how to use the “help” message in this instance (since help is usually visible until the ‘h’ key is pressed) where it would immediately come up when the player made this mistake.  Francis changed a ‘status’ variable in a different method to account for my message in the help method and we were in business.  Now when the player attempts to do like our government and spend more than they have, their order is cleared and a message pops up telling them of this mistake—and they aren’t allowed to leave the screen until they make an order that they can afford—too bad it is not that simple for our dimwits in Washington!

The preliminary pass on bug #4 has me feeling confident that a solution is almost at hand.  This bug is more of an error in message reporting than anything else.  If the player puts in the correct “fewest coins possible” as their answer, the profits are then added to their account—a correct response to that scenario.  If the player puts in the wrong amount…ie $4.35 when they only made $4 then they are told they entered the amount in incorrectly—again a correct response to the scenario.  The problem lies in the middle scenario—the player enters the correct amount BUT uses the wrong combination of dollars and coins (ie…4 dollars, 2 dimes and 1 nickel as opposed to 4 dollars and 1 quarter) they get the same incorrect amount message.  So far I’ve found the variable that keeps up with the amount of current profit and the variable that keeps up with the breakdown of the dollars/coins the player entered.  My next step is to search the python api to see if there is something there that I can use to add these numbers up separately and compare that with the amount of profit for the day.  Then I’ll add a condition after the correct scenario that tests for this circumstance—which if true will yield a different—more descriptive message to the player; and of course the last condition will fall to the already written incorrect amount error.  Well back to the code!

Overcoming Bug #3

Breaking up the problems with bug 3 of our project (the one which allowed the player to purchase more supplies than cash on hand) was a priority.  It didn’t take long to discover where the problem was and with a little effort I wrote a small method that accumulates the cost of supplies that the player WANTS to order and passes that value back to the method dealing with the purchasing of supplies.  I then used an IF statement that allowed the game play to resume when the player HAS enough money to purchase the supplies that they wanted to order.  The ELSE portion was where I hit a snag…I couldn’t figure out a way to keep the player on the “order supplies” screen until the comparison proved TRUE.  The existing “draw” method in the gui called everything that needed to be drawn, and the “draw_store” would not work independently; however, Francis figured out a way to overcome this and it does seem to solve the problem.  I spent a good hour this morning trying it and everything appears to work as it should.  He wrote an extra case in the gui class that allows for this circumstance and we are all happy!  I still would like to make a notification pop up that would tell the player that they tried to order more supplies than they had money to buy—we’ll see what we come up with at our meeting later on today.

Bitter Lemons

After running in circles for awhile with my unfamiliarity of python I did finally have some success determining what is going on with how Lemonade stand calculates the items purchased.  (and after breaking the code royally, I really appreciated the ability to checkout a clean version with subversion!)  It appears to be written to check each individual item 1^st; instead of totaling all 3 items and then checking that against the amount of available cash.  A player may or may not overspend until the 3^rd item…in any case no error message is given to explain this problem.  So, that means a little more work than just working with a variable or two...looks like I’m going to work on pseudo coding a method (again my python is rusty) that will total and check this condition first...if indeed this is the desired solution—will find that out in a few  hours.