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.

Reflections of Posscon 2011

Posscon 2011 was definitely worth the travel time involved and I must admit that I really didn’t know what to expect when I arrived.  I actually got there around 7 on Friday morning and was shocked that they actually signed me in that early.  While walking around and checking out the booths, I was surprised to see several of the speakers already there.  Little did I know that being early really worked in my favor…while walking around I noticed Jim McCracken lurking around his and Neil Underwood’s booth from Thursday.  Jim told me that he was missing 2 very important bearings for his “Thing-O-Matic,” to which I quipped that he should simply replicate them.  He laughed and explained to me that this was not possible, “YET” and this led to a great conversation with him.  I volunteered to help get a table for his “Thing-O-Matic” display while getting the inside scoop on what the presentation was about…along with what specific parts were used for.  The bearings that he was missing were an important part of the unit that he had planned to have the attendees put together during the presentation—thus he had to change plans and brought in a working unit to show in action.  I am still baffled at how it works (with a single input of plastic wire “extruded” into the machine) but after seeing the Android holder the unit produced for John “Maddog” Hall I can’t dispute what I saw.

It was almost an hour of helping and asking questions of Jim, that Neil Underwood began setting up his display in the same room.  He overheard some of my conversation with Jim and before I knew it I was having a similar conversation with Neil as he was setting up his RepRap unit.  One thing was obvious from the beginning; Neil was extremely passionate about this technology.  He began telling me about speaking engagements, workshops, demonstrations, blogs/forums, etc…. that he engages in for the express purpose of getting the word about the RepRap (his is names Mendel).  To be honest, when I “googled” the Thing-O-Matic the other week, I never noticed anything about Neil’s passion—the RepRap.  Neil lamented the fact that there will never be any advisements on it because he said that “…it is the worst business model ever made.”  The reason for this is that if you buy (and assemble) this machine you’ll have no need to ever buy another one—and your friends can buy your replicated version from YOU and not the manufacturer.  While Neil freely admits that there is no money to be made in selling the RepRap, he is so passionate about it is because of the imagination it can unleash upon its owner.  He said that just seeing the kid’s (and adult’s) eyes as they realize what they can do with this machine is payment enough.  Before I knew it, it was already 9:30ish and I had missed the “Welcome and Overview,” but felt that I had learned more being around these two guys than I would have during the 9am session.

I attended the OpenOffice Challenge for my first session with David Both.  I did glean some information during the workshop that I thought was helpful.  For example, I didn’t realize the reason for “LibreOffice.”  David explained that this was a “fork” in the project that occurred because of some concerns over the direction that Oracle was taking OpenOffice.org (after they bought Sun Microsystems—the owner of OpenOffice.org).  The name OpenOffice.org” was also a big point in the workshop—that it is important to use the “OpenOffice.org” instead of just OpenOffice.  This is because a Japanese company has the copyright to the phrase “OpenOffice.”  We kind of left the OpenOffice.org for the majority of the workshop as other participants began asking questions about converting their office staff from Windows to Linux.  While the discussion was interesting, I was a little more interested in OpenOffice.org specifically and had hoped to learn more about the suite than the direction of the discussion took us.  David did explain to me that there is an open source equivalent of Microsoft Outlook and that is Evolution.  It is in not an OpenOffice.org package and he had no idea why they haven’t integrated on in their suite other than the fact that Evolution is already out there as open source.  I haven’t installed Evolution on my ubuntu box YET, but have looked at screenshots and it seems like something that I could make use of...so that’ll be on my “to-do” list after the semester when I actually have time to experiment with it.  As for things on the horizon, the best answer was the new transitions to be added to impress and what is happening with “LibreOffice.”

During the break I happened upon David Duggan and struck up a conversation with him.  After a few minutes at the lunch table I realized that we had several friends and acquaintances in common.  We both attended Midlands Technical College (different years), are friends with Dr. Chan and have “fond” memories of having Joe Greer for our two semesters of COBOL there.  He told me about GNU Cash and that it was an alternative to Microsoft Money…although I must admit my first impressions of GNU Cash is not too promising.  I may play around with it during the summer, but looks like I’ll be sticking with MS Money for a while yet.  Much of what David stressed as the advantages of open source over bought software was the “free” cost of the product, but more importantly is the support that is provided.  At lunch he recounted an experience that he had where his network was doing something extremely strange and that the organization spent several hours with him over the phone—the day after Christmas—to help him resolve his problem.  His workshop was interesting as well…he showed several open source products that appear to be great equivalents to Window’s platform software (most notable to me was Evolution and Gimp).

Overall it was a great event…well worth attending (especially at the college’s price!) and as I’ll still be here next year—God willing, the last 2 classes—I’ll look forward to attending again!

Planning the trip

Much of what yesterday and today has entailed surrounds final preparations for attending the convention tomorrow.  I’ve printed out pictures of the speakers that I’m hoping to ask questions of tomorrow in order to spot them easier.  I arranged my questions so that I can get the most out of however much time they have available (I don’t want to take up too much of their time).  I even scoped out the parking situation in relation to the convention center for tomorrow as well—although I didn’t see anywhere if there is a charge for parking (if not that’ll be a big change from the way Charleston does business).

Well back to the grind, still sorting out the logic in bug #3 …getting there though.

Bugs and Possible New Feature

Thursday thru Sunday night was spent at Duke University Hospital looking after my mom following her surgery.  With most of our early bugs spoken for (and since it has been years since I’ve had to deal with python code) I’ve set out to discover the cause of our last 2 bugs.  I had little trouble finding 2 methods dealing with bug#3…although I am still working on understanding why they were written the way that were.  In the process of finding this code though,  I came across the difficulty levels and thought of another improvement that we can make…and that would be by adding this to the “help” box so that the player can actually see what difficulty level they are playing in.  We may not choose to undertake this because of time constraints, but I’ll mention this at our meeting today.

I still haven’t found the code dealing with the “error” message in bug#4, but honestly haven’t looked that deeply into it because we haven’t slated that one to be completed for another 2 weeks—so there is still plenty of time.  For now though, I’ll keep working on bug#3.

Team Post, Posscon and Chapter 9

Our team project is moving on without a hitch—we actually received an email from Nathaniel (the person in charge of Lemonade Stand) during Tuesday’s class, in which he gave us the go-ahead on what we are looking at doing.  Needless to say this is good news for us and a boost knowing we are on the right track.  As for myself, I had been trying to determine the best way to work with the code (since it is in python) and in my CSCI360 class we are using NetBeans—which I discovered has a Python plugin!  Originally I was using subversion with tortoisesvn in Windows but since I needed to test the code in Ubuntu I really wanted to have everything working in the same OS.  I spent a good part of the day yesterday working on this and was able to make everything work together…I was very happy!  I imported our project from our repository in Cirdles directly into my new NetBeans Python project, set up the subversion inside NetBeans and I was off and running.  Since we are only working on documentation this week (instead of code) I wasn’t too pushed, but wanted to get ahead of the game.

For my trip to the Posscon convention next Friday, I have chosen 4 speakers (in case I am not able to catch all 3) to ask questions of.  The first two are rather easy because I plan on attending their workshop and should be able to ask my questions—if nothing else in the question & answer portion of the workshop.   The other two are speakers of other Friday workshops, so hopefully they will be available at some point—whereas if I choose a speaker from a different day, they might not be there on Friday to ask.

David Both is the speaker of my morning workshop which is about Open Office.  One of the questions I have has a personal connection to me.  I am hooked on MS Outlook and as of yet, I have not seen a similar package in Open Office and I was wondering if one is in the works (or why not).  I am also interested in learning how they are able to mimic (and even bi-directionally use) Microsoft documents without drawing the legal ire of Microsoft.  A final thing that I am interested in learning is what is “on the horizon” for Open Office.

David Duggins will be the speaker of my afternoon workshop dealing with using open source software to start your business.  I’m sure this workshop will give me the business aspect of open source software, and in particular I’d like to find out from him what the best open source accounting software would be.  Over the years I have been patronizing MS Money—which is now been discontinued, so I’d be interested in something open source that might be maintained for many years to come.  I’d also be interested in learning why (since there is no cost to count off on my taxes) I should base my business on open source instead of off the shelf or built software (which I can deduct portions as business expenses).

Finally, I hope that I can catch either Jim McCracken or Neil Underwood who are speaking at a morning workshop dealing with 3-D printing and open hardware.  I kind of wanted to attend that shop to learn about “open hardware” and might swap if the Open Office workshop is too full.  I have never heard of “open hardware” so I would be asking the, what’s and how’s of that.  3-D printing is something that would be interesting to learn about as well…so “how can I use that” and “what are the costs involved” would be another area to question them about.  Finally there is the “Thing-O-Matic” that I am sure is the printer, but I’d be interested in learning what it is, who makes it and what it costs.

When dealing with chapter 9, it was by far the shortest assignment I’ve had to read yet.  While I can understand the concept of “releasing early and often,” I can also see a downside.  When rushing things to go live, you can introduce some unintended consequences that might have been discovered through more testing.  While quick and often releases can cover this, it also could mean more of these consequences or force the user to learn to do something a different way—or it could all go smoothly.  (I’m just being a realist looking at it from a user’s perspective)  Also, I’m not sure if our author was testing us but all of the links on this page were either dead or took me to a wiki type page that was empty—guess I should contact the author and tell him that someone was paying attention….he needs to release quickly again :)

Ready...Set...Go!

So after spending a week and a half discovering as much as possible about my team’s project, it is refreshing to finally have a game plan.  For some time, my team and I have been concerned as to how we could contribute to Sugar Labs for the remainder of the semester and now we have mapped it out.  We have updated our Ateam wiki to show this new timeline for our success.  We have chosen several areas that we CAN contribute to this project and gain some valuable experience in the process.

The first area deals with documentation as it pertains to game play.  Right now, the player is forced to figure out everything on their own…nothing to stipulate what keys does what or even the goals of the game, just to name a few.  We have several ideas as to how we’re going to go about improving that, and we want to tackle this first for several reasons.

The second area of our improvements deals with several bugs that we found.  These are obvious ones (like I mentioned in a previous blog) and really do need to be resolved for the player’s sake.  We chose several that we felt would be attainable in a reasonable period of time—especially since time is waning for this semester and have posted milestones for each of them.  Hopefully Nathaniel Case will be happy for our efforts in this endeavor.

The final area deals with a few additions to the game play.  Nathaniel had mentioned in his wiki that he was looking for several random events among other improvements.  What our ideas are with this area is to use random events to utilize some variables/game objects that he currently is not using.  Our additions would also increase the learning skills of the players with the ideas we have come up with.

So, overall I think we are on solid ground and ready to have fun.  So finally it is...."ready, set....go!"

Yet another bug discovered!

I must admit that I’ve had to spend lots of time the past 3 days securing transportation because of a major car breakdown; however, I did make some progress on ideas of our lemonade stand project.  I studied the code and that has helped me understand a little more of the game play/interface.  Although I have seen some additions we could make to the project (more random events, weather patterns and supply & demand issues) I still am more inclined to look into some of the bugs that stand out.  In fact, I found another one that I missed before….I don’t know how I didn’t notice it before, but on each “day” the player is presented with a daily journal, but no matter how you play it the game always starts at “Day: 2” (NEVER starts with Day: 1)

Looking forward to our next team meeting to compile what we have all discovered!

When Life Gives You Lemons, Make Lemonade

So my group and I started focusing on Lemonade Stand as our project to work on through the remainder of the semester.  In class Thursday, we were able to discover why our activity would not run as a stand alone activity.  The "engine" framework that the designer uses to run the activity was in a folder that was inside another folder...when we ran the command to initiate our activity, the program couldn't find the engine.  As a work around, we moved the contents of the inside folder into the "outer" folder and everything worked well.  A better solution for this is definitely one of the things that we are considering as being worthy of our attention.

After we got the game running, we immediately found that the user interface was entirely based on keystrokes—no mouse movements at all.  After a careful check through the README files, the wiki and the ever popular Google search, we found no instructions as to which keys did what.  It took time using the trial and error method to learn these, and to top it off there is no game play instructions for the user to read either.  This is yet another area we are considering as needing further improvements.

There are a few bugs that we have identified as well—in the game, the player is supposed to enter their profit for the day in certain categories (i.e., pennies, dollars, dimes, nickels, and quarters).  Suppose a player has earned two dollars and forty five cents in profit…the only input that the game accepts is dollars: 2, quarters: 1, dimes: 2 – any other combination, even if correct (i.e. dollars: 2, quarters: 1, nickels: 4) will tell the player that their input is incorrect.  Another bug is the pennies category…never is that used.  It is a category listed for the player, but the player is never put in a position to use pennies.  We could possibly use the “added events” that the developer is interested in being added to create possibilities where pennies could come into play.

There also APPEARS to be another bug, but I’m interested to see if my team has had the same results.  I’ve tried on several occasions to buy supplies…however, I intentionally bought more than I could afford.  What I noticed on these occasions is that it appears that the program allows me to buy the amounts I ordered even though I didn’t have enough money to pay for it.  While my “cash on hand” was zeroed out, I had “extra” supplies that I should not have been able to buy.  I’m curious to discover if I am overlooking something or if my team has had the same experience…since there is no documentation that may be another question for the developer…and quite possibly something else we could look at correcting.

There are a few other areas where we could improve the game play, but I’ll wait until our team meets again to put those up in the ether.  After Thursday’s success, I am feeling pretty confident that we chose the right activity to get involved in…all that remains now is a successful meeting—and some answers from the developer.

Updates Galore

Well I received an email Tuesday night from the planners of the Posscon convention letting me know that they would have Friday's schedule finalized by sometime Wednesday...and they were true to their word.  In fact, it looks like they've changed many of their workshops around.  From what I'm seeing now, it looks like I'll be attending the 9:45 workshop with David Both on "The Great Open-Office Challenge" and the 1:15 workshop with David Duggins on "Starting a Business on the Cheap Using Open Source."  I'll plan on coming up with some questions over spring break for these two speakers and probably 2 others (in case I am not able to chat with both of them) and list those questions in an upcoming blog.

My team and I are excited about focusing on Sugar Lab's Lemonade Stand for the remaining portion of the semester.  Each of us were able to build this add-on yesterday, but all of us are having an issue with getting it to execute.  There is a workaround that Jamie mentioned on Tuesday that she had found with her group's Sugar Lab's add-on experience, and we'll ask her about it in class today (and test it if time permits) to ensure we all have it working.  Being able to open the individual add-on without using Sugar Labs OS will be beneficial with our workspace, testing and possible conflicts (like Browse) that have already taken up enough of our time.

Reading over chapter 8, I thought it would be yet another brow beating rendition of the importance of documentation; while it did have lots to say on the importance and proper ways of documentation, I learned of several new tools that I never heard of before.  First, Beautiful Soup is a parser that is totally new to me.  From what I gathered from that portion of the reading, it can be used to parse digital files such as documents and web pages.  It is slower than other parsers, but can be customized and even set to parse only a part of the file if desired.  It is well worth another look and some playing around with later.  The rest of 8.1 really focused on documentation...as I expected.  There were suggestions and examples pointing to the importance of clear documentation.

8.2 is going to be an interesting assignment and I thought that I'd spend some time looking at the wiki and IRC functions that will be a bit clunky at first.  In hindsight, I probably should have installed the IRC feature on my box--seeing as I can't use my laptop at work, and we can't install anything on government computers.  I did spend some time with wiki just to make sure that I could create a new wiki, create new pages and link to them from the main page in a timely fashion--since we will only have about an hour for the project today.  While I am still not sure how the best way to go about working this project in class, if I have no problems getting the IRC to work then I think that I'll be fine.

8.3 through 8.8 dealt with documentation, technical writing and ways to use documentation and technical writing to gain a positive reputation in the FOSS community.  (I did think it funny that in 8.6 they used the "waterfall method" to creating documentation--which is probably an acceptable use of this method, but over the past 2 semesters we have seen how it is not the best method to use in designing a system) 

Project & Posscon

Much of the past few days has surrounded our group project and details of the Posscon convention.  After another weekend spend re-installing Ubuntu and Sugar Labs yet another time, I have come to the realization that "Browse" is unattainable.  I created a snapshot in my VB before I started experimenting with their suggestions only to find that their modifications (not only wouldn't get browse to work, but also) would not allow my activities to open in Sugar Lab as before.  So I roll back my changes at my snapshot only to discover that my activities still would not open.  No matter what I tried, nothing worked and I was forced to start over yet again.  So after a few expletives I vowed to forget about "browse."  This meant that our project for the remainder of the semester cannot deal with that cursed activity, so we all started looking at different activities within Sugar Labs.  I know that several of us like "Lemonade Stand" as it offers some possibilities to work on, and there are also runners up that I like as well "Poll 27," and "Visual Match 28" to name a few.  We'll be meeting later on to nail down a particular activity.

With that done I started focusing on which speakers that I'd like to ask some questions...and then I ran into trouble.  I'll have to work Wednesday and Thursday, so the only day that I can attend is on Friday...the problem is, that they have 8 workshops listed for that day but they have not listed who the speakers will be for that day.  I did see 1 workshop that I'm particularly interested in: "Starting a Business on the Cheap Using Open Source" and another that might be interesting to me: "OpenOffice."  I did contact them about the missing info and will be waiting for their reply.  As for the 3rd possible person (if the two speakers in my workshops aren't available) I'd like to chat with, I was thinking that Janet Claggett might be my 1st choice because she works in the IT field--what I'm most interested in.  Mel Chua would also be interesting because of her hacking abilities and that is interesting to me as well.  Perhaps the last person on my list would be Dr. David Wheeler because of his software security expertise.

Reworking Chapter 7

I had already made it through most of chapter 7 assignments over the weekend--well at least up to the problem one  in 7.8 with very little issues.  I was already rather familiar with diff from last semester and using it as described in 7.2 & 7.4 gave me the results that I expected it would.  I got tripped up a little in 7.5 with the subversion aspect of it, but I was able to back up and make sense of my error and move toward where I would eventually get stuck.  No it was not the patches in 7.6 or 7.7--which we've already finished, but with 7.8.  First of all, I was totally confused with the instructions.  After reading it several times, I looked through several of my classmate's blogs and saw that I was not the only one.  The whole first sentence throws me and the way I understand it, I'm supposed to have a file named "bar" with some data in it; then my patch file creates a file named "foo" which will have a copy of the contents in "bar."  I worked on this angle, but didn't have any success.  I could have two files "foo" and "bar" with contents in them and can combine them with the patch (and diff them of course) but really never was able to do what I think 7.8 is asking me to.  I'll pay close attention today to how other's handled this problem!

Patch Convention

Working through chapter 7 was interesting...and the major command "diff" was something that I was familiar with.  We used diff last semester when comparing our oracles with the newly created output to determine if there was a difference between the two.  It was nice to already have a foundation to build on with this.  Everything went along well with the experiments until I hit the “patches generated with subversion” section.  (Actually that went ok once I got a handle on it)  I toyed around within my subversion server until I was able to duplicate the results…an interesting experiment to be sure!

On our group note, Francis created our patch this past Thursday and we submitted it right away (we really wanted to be the ones to finish what we started) to the Sugar Lab’s bug tracker.  We were all pleasantly surprised when we received our email from them yesterday showing that the patch had been accepted and the bug was now closed.  While we are still enjoying our successful moment, we also have been working on ideas for the remaining of the semester.  If all goes well, we should have an agreement on that within another day or so….then we will all be looking forward to creating the next patch!

Sugar Lab's Features and Quirks

Much of what I've done this week (aside from the research paper I've been attempting to tackle) is to spend time exploring the different features that Sugar Labs offers.  I didn't realize until the other day that there are add-ons aside from the core offerings.  I had assumed that games were accessed under one of these core features that I had not explored yet; however, my experience from Freeciv has taught me to avoid contaminating my Sugar Lab's workspace...I've had quite enough experience installing Ubuntu and building the code for Sugar Labs already this semester.  It was interesting to know though...maybe after the semester is over and no harm can come to my project, I might consider exploring some of those add-ons.

Of all the standard features that come with Sugar Labs, Browse drives me crazy.  Although it does not have any bearing on the area that our project has us focused on, Browse simply will not work on our Ubuntu boxes.  The best we can determine is that one of the dependencies for Browse is an OLDER version than what comes with Ubuntu.  Browse does not recognize the newer version and Ubuntu gives you errors if you try to install the older version of the dependency.  Since we already have much to do, it doesn't make sense to keep beating this issue....but it is annoying!

Exploring Features of Sugar Labs

Last week was refreshing...the bug that Stephanie found had not been submitted before so we were able to get in on that process from the beginning.  We spent the time to create a model ticket (as we had learned from our bug tracker exercise) and carefully worded each step.  Once we were satisfied, we submitted our ticket and waited...which didn't take long to get a response.  The first email came probably 3 hours from an admin and the "acceptance" of our ticket came in less than 2 hours after that--so we are all happy.  The fix should be straightforward and we'll move on from this with a little confidence and experience under out belts.

For today, I'm looking forward to attending the Alumni Symposium...although I can't be there before normal class time because I don't get off work until 1...but I'll sneak in hopefully around 1:30 (depending on traffic and parking getting there).

Trudging forward

Our group is finally recovering and getting back on track only a week after our Freeciv disaster.  This tragedy came just as we were starting to catch up (after switching projects) and were in the process of taking aim at bugs.  Now, while there is still one issue with Ubuntu yet to be resolved it seems that our team is again on solid ground—or at least we have a firm foothold of where we’re supposed to be.  At our last meeting, Stephanie brought up a potential bug that she had noticed (that was not listed in the bug tracker) and everyone agreed that it appeared to be a valid avenue to pursue.  None of us have been able to find this bug in any of the already listed bugs in Sugar Lab’s bug tracker—so not only do we have a bug that we can tackle, but it is one that hasn’t been reported before.  Now with our boxes finally somewhat stable, our source code built, and a solid direction to turn our attention towards, it appears that we’re ready to move ahead.

There is only one sad realization that I have had to accept this week.  I like using the virtual box for operating systems that I really don't want on my machine, and I was looking forward to figuring out the full screen add-on.  Since my group and I have been so busy putting out fires with our project I just couldn't justify investing the time in figuring out how to make my virtual box run in full screen.  Once I had ubuntu re-installed on my virtual box (for the umpteenth time it seems) and Sugar Labs built & running, I made a snapshot and began my attempt at installing the software required.  With very little effort I was pleased at the results of seeing my virtual box fill the screen--like it did when I had the dual boot system.  Then came what I was afraid of....when I ran the command to open up Sugar Labs, their emulator failed to open.  After looking it up and trying some suggestions I began to realize that it just wasn't worth the effort.  Evidently the Sugar Lab's emulator has a problem with the stretching that the Virtual Box does to make everything run full screen.  So, thankfully I reverted to my snapshot and everything runs as before (learned my lesson from Freeciv).  I also found a trick that does help when I run Sugar Labs in my box.  When I run the Sugar Lab's command, I can add dimensions for it to run in.  This allows me to force it to run in a smaller window than my box--allowing me to see what Sugar Labs was showing but my screen setting wouldn’t allow me to see.

So now we’ll settle down and tackle this bug and hopefully have a pleasant experience (especially after such a rocky start).

Continuing last post

Well I thought that I would sit down today and continue with the assignment from where I left off last.  So I go through and read Ubuntu's triage page and thought I would give this part of the assignment a try.  So first I went to set up an account with Ubuntu and waited a while for an approval.  What I didn't realize was how long it would take to receive my 6-digit confirmation code to actually submit anything (over 2hrs later and still no response) unlike the speedy response from the Sugar Labs bugs account.  While I waited, I went to their untriaged bug page to get a feel for what they had.

Ok...this was no where as clean as Sugar lab's page.  To start with, there were 23,600+ untriaged bugs--way more than Sugar Labs.  The next thing that struck me was that there were some with 3 word summaries (too little) and whole paragraphs (some of these you could feel the writer's emotions--and my little experience with ubuntu has cause me to empathize with them), but the format that the board has keeps things in an orderly fashion.  They must be assigned a ticket number automatically (makes it easier to come back to) and all those I looked at had use cases, platforms used, dependencies installed (and in some cases screenshots) all of which are very useful!  I even found one that related to a problem that I had...ticket#714688 I needed that Evolution plug-in for my phone to sync with Evolution, but when I couldn't get it to work I gave up & continued to sync with windows.

Without having my access code, there wasn't much that the system would allow me to do other than look through them--even marking one as a duplicate required a login.  So I picked a few and quickly did in notepad what I would  have done on their forms (well as best as I could have) just to get a feel for it.  Maybe sometime later today they'll actually send me an access code...of course with my feelings on ubuntu maybe they shouldn't :)

Recovering from Freeciv & beginning new assignment

I really had to laugh when starting this reading—bugs was a poignant topic after working on the Freeciv problem earlier in the week—not for what the assignment was about, but for what it caused.  Other members of my group had a worse experience in terms of the damage it inflicted on their machines so I really should not complain.  Evidently Freeciv must have changed some dependencies or settings because some of the functions of our build that were working—now were broken.  So the most important lesson that I learned from this experience, was to create a quarantine box for any work that is due outside the purview of our project…no sense in adding work that I’ve previously completed to an already hectic schedule!

Back to the bugs….well the second part of our assignment (finding out how to set up a bug-tracker account) was extremely easy—thanks to Sugar Lab’s well organized wiki.  It was prominently displayed on their wiki—which only asked for me to create a username/password and to provide an email address in case I ever needed to reset the password.  This new “access” didn’t really change what I saw before, but presented it differently.  It showed where bugs had been assigned (without having to delve into the ticket) and ordered the tickets a little differently.

The first part of our assignment was to find the oldest bug that Sugar Labs has; well there are actually 3 of them at 2 years (no specific date given on the ticket only a general time frame) and all of these 3 are actually more of “enhancements” than bugs; for example, ticket #405 “Insufficient feedback on pressing of Keep button in non-optimal viewing conditions.”  This is only relevant to certain types of monitors (XO and SoaS with LCD screens) where a bit of a glare can cause the user to inadvertently hit the wrong button causing their harm to the project they were working on.  Bug #405 is one of the few tickets that do not have a lot of feedback posted and I think it just isn’t a priority.  I would assume with this only affecting a very limited number of monitors that it is hardly worth the effort to explore—(and to reproduce the “bug” one would have to have the specific type of monitor) which are two reasons I would  give as to why it has been around for 2 years.

Recreating a bug (the third part of our assignment) was the easiest of all.  Bug ticket #1997 states that “Read fails to start if Hal is not installed.”  I know for a fact that all my dependencies have been installed and Sugar Labs source code was successfully built on my box.  When I attempt to open “Read” it flashes then gives the message “Read failed to start.”  I read a little more in the ticket (updated 19 hours ago) that a patch for this problem has been created, but is waiting on approval from the activity maintainer before it can be integrated.  Hmm…a long approval process maybe?

The last part of the assignment is to work on triaging 5 new bugs.  After reading what goes into triaging, it would be too simple to take those from Sugar Lab’s site…they appear to already be organized and defined well beyond my abilities.  I went to the links for GNOME, Fedora and Ubuntu and think that’ll be where I start.  In fact since my disdain for Ubuntu is growing daily, I’ll make an account there and see how that turns out—there should be PLENTY of bugs for this OS.  I’ll work on that tomorrow…after at least a couple of hours sleep!

Both Builds Successful!!

Well there are several promising successes since my last update; the first being that Sugar Labs has been successfully built.  We stayed after class as a team and worked on getting the code installed on our machines...so far we have 2 of our 4 boxes running Sugar Labs, and we are confident that we can replicate it on our other two boxes.  I must say that I really like using the virtual box...it allows me to keep my windows environment up (instead of having to reboot several times each day to sync my phone to outlook--wonderful!) while still doing what I have to do in a different OS.  This wasn't the reason for using it, but (other than having to waste so much time setting ubuntu back up after its crash) it has been a worthwile endevor.  Just for fun I installed Debian virtually as well--had some password issues that Clay helped me overcome--although I still haven't been able to spend enough time to get Sugar Labs on it too (there are some hated dependency problems there too) but maybe over the weekend I'll get some time to tinker with it--just to have a backup in case ubuntu decides to crap out again.

Anyway, I started working through the Freeciv problem from our book and like the concept.  I always learn better doing things--especially with a model to follow or when there is help close by when I get overwhelmingly stuck.  So, I start following the directions and quickly realize that there are subtle differences in commands from linux to ubuntu; for example, in the early steps I was instructed use yum install....but in ubuntu (at the root) we use sudo apt-get install (or without the sudo if not something to be installed at the root).  I also noticed that some of the dependencies had names that were different in Ubuntu as well.  Overall I only got stuck once and after some much needed sleep I was able to overcome that road block as well.  Did kinda feel a little deflated afterwards when there weren't enough "human" players to see what happens.  I also gained a little more appreciation of windows in this too...I realize they install lots of things you don't always need, but chasing down all those dependencies can be time consuming and mentally taxing (but to each his/her own).

Reasons for me to hate Ubuntu

So, I get settled in to download and build the source code for our new project and wouldn't you know it Ubuntu crashes.  It was so bad that I couldn't even boot into the Linux based system.  So, I do a clean install--knowing it'll wipe out my work from last semester and guess what?  Yep, the install fails!  So, I wiped it clean and went a different route...I'd heard of installing OS's in a virtual box so I figured it was my time to invest in learning that.  I failed the first time because the virtual box didn't like the 64-bit Ubuntu exe that I downloaded (dumb because I have a 64 bit box...who knows?) so I try again by downloading the 32 bit version and it installed without a hitch.  I spent about another hour doing the updates and making a few changes.  Once I got back to the project at hand (our source code) I come across some interesting information...it is only supported on version 9.1  (which as you can probably guess by now, what I installed was their latest 10.1)  I started to install 9.1 virtually as well, then I read further...even 9.1 won't allow the emulator to work because of a broken security configuration.  After muttering a few "inconsiderate" words to my project I set out to see what it is actually supposed to run on.  The best option appeared to be Debian, so off I go again downloading and installing yet another OS today.

Since we ran into issues with rapidSMS, my group and I have chosen to tackle a different problem...this time on an area of Sugar Labs that will not be similar with the other two groups working on it.  Since it is such a large project with many different flavors to look into, we're still in the process of narrowing down what fits us best.  So, I did join this version of their IRC chat, because it doesn't require additional software to be installed (which will allow me to access it at work).  I joined one of the mailing lists (bugs) because I thought that would help in our next assignment of finding a suitable bug to attack; however, there are several mailing lists and I figure we'll be on a few of them before this is over.

Debian install took forever but was a rather straightforward install and FINALLY, I get back to my original project some 6 hours ago!  After following their directions for Debian install by the letter, I made it all the way to the build command and keep getting the error "Refusing to run as root." (its getting rather hard now not to spell out why I like Windows better than this!)  So my problem is...after hours of frustration and time lost, the only thing that I can show for my efforts is the fact that my box has 3 operating systems (one great one--Windows) one fixed and 2 virtual OS's.  Maybe tomorrow after catching up on the work I didn't get done today, I'll find some time to devote to this endevor again :(

Success!

TortoiseSVN ROCKS!  With less than 10 minutes of time spent downloading, installing and rebooting my box, I was already in business.  The only foul up I had, was that I originally linked the space I set up on my box to the URL we were given--instead of the ....cirdles.....playground/test.  This was easily corrected and I am now able to upload, checkout, make changes, revert to a previous version, commit my file, etc...  I toyed around a little bit and found out what "blame" did...cool!  Like I mentioned earlier, I learned how to revert to a previous version of my file, renamed it, tested using the "diff" function...all in all it was much smoother than NetBeans or SubCommander!

Next up was to start setting up my personal server.  What I thought would be the most effective use of my time was to test VisualSVN since others had success with it.  Again, I had no problems installing it; however, it was a little tricky to set up, but NOTHING like what I was dealing with on Wednesday/Thursday!!  I spent the better part of another hour just trying things I was a little hesitant of trying on the group side (like locking and branching) just to get an understanding of how it works.  I also (among other things) tested setting up permissions so that only I could edit something...interesting.  Just like on our "playground," I am able to do all the things to my repository (on my server) also...cool, I might have some uses for this later.

Overall my experience with TortoiseSVN and VisualSVN was great...of course it’s always great when it works right?  I only wish that I would have started on this path instead of wasting the time I spent on the other path!  Next step will be getting and building the source code for our project…sounds like a Saturday job!

Addendum: TortoiseSVN ROCKS!!!!!

Its not subversion it was a downright disruption of my day!

The first part of my project was uneventful. Logging into our cirdles “playground” was straightforward and completed without any problems at all. The real problem was, “what do I do here?” I could view and edit, but had no way of uploading my own content to the repository. I had done some checking and discovered that Subversion was already installed on my box when I installed Ubuntu.

After some searching (and scratching what hair I have left) I was guided toward the realization that I needed a client to accomplish task at hand. I initially tried NetBeans and had no problems setting up the connection with our repository but was unsuccessful in getting it to work for me. Next I found Subcommander (which only needed to be installed though the Synaptic Package Manager) that is showing promise. I was actually able to sync my local box with the repository but when I tried to “commit” my own files, I wasn't able to see them in our “playground.”

I'm sure I am overlooking something and will try again tomorrow before asking for help. Netbeans will probably be what I will use, but it would be good to know a couple of ways to put subversion to work. I was a little disappointed that I didn't get to the source code today...completely ran out of time and other work took priority...now I'll have to try to get it done over the weekend instead of getting ahead.

Research and Planning

Most of what has been done since Thursday has been looking into the history of rapidSMS and trying to get any leads into how we can contribute to the project.  The project has only been around since 2008—although no one has a definitive date as to when its inception actually began.  It was not too hard to find out that graduate students from Columbia University developed this with funding provided by UNICEF.  The first use of the rapidSMS framework was (and is still in use) in the Malaw project and since then, rapidSMS has been used in projects encompassing six different countries!

The most challenging problem to date is to determine exactly what or where we can contribute to this project.  Since it is a framework, there is the option of building something that uses it—but after a few weeks with Ryzom last semester, that is a scary thought.  We did get an interesting response from a member of the rapidSMS Google group that sounds promising…so we’ll struggle with this problem some more.

In the meantime I thought that I’d get the source and attempt to build the code on my box; however, I hit a snag when I booted back into ubuntu and was reminded that (for some unknown reason) the ubuntu wireless drivers will not allow me to connect to my apartment's router.  It works fine at school, so instead of downloading in windows and attempting to shift from ubuntu to windows and back again, I'll just wait until tomorrow when I can work on it at school.

A peek into the past

Well it's a good thing that I didn't try to fit "The Cathedral and the Bazaar" reading into my day yesterday...I definitely would not have finished it and be in any state of mind to reflect on it!  Mr. Raymond put a lot of information into this work--a pretty fair amount of technical information too--which introduced the impact of Linux on the computing world as he journeyed us back in time to his foray into working on (and eventually taking the reins of) an open source project that interested himself.

Raymond was an accomplished programmer who simply wanted a software package that allowed him to have more control over his email--and before long he was not only contributing to an existing OSS project, but would eventually take the project over and rename it to encompass his contributions to it.  I'm not sure that I would have gone to all that trouble--I surely don't have the time to even consider something like that at this point in my life--but it is a good thing that people like him do.  It would be hard to comprehend what life would be like were it not for those who invest their lives towards solving a plethora of problems.

I definitely liked his use of "cathedral" and "bazaar," and must admit that I wasn't sure what that would be referring to--and he actually explained that EARLY on.  The idea that the coding style of a bazaar (or a conglomerate of people working on many different things at once on a project that happily accepted and implemented most of their ideas) would be more effective than a cathedral style (a system of only a few "holy" people reverently working together on the project) seems impossible; however, (as Raymond points out) Linux has proven its point.

To be honest it was hard to vigorously digest his technical information, but he made it as interesting as possible.  I also liked his references by Dr. Brooks--I remember his articles from last semester and the timely announcement of Netscape becoming an open sourced project (I feel old now...I remember that happening) although I must admit that back then I didn't really understand the significance of that.  Perhaps the only complaint I would have over the article though....I did like the XHTML format (moving from page to page seamlessly) but I must admit that after a while I wondered "how long is this?"  It was a good article/short story but after a while I won't lie...I was glad to see the bibliography and acknowledgements pages :)

Moving Forward

Today we finalized our team project (which will be the RapidSMS project) and we will be spending the rest of this semester working with it.  It should be an interesting project but perhaps the most important hurdle of determining what particular aspect of it that we really want to focus on is looming ahead.  I was able to easily join the IRC for RapidSMS, which was surprisingly easy to do (I was even able to add a custom link from my blog to it as well—see the bottom of this page).  Since IRC is also a new venue for me, I am not sure if I am overlooking something because I really don't see any "traffic" or chatter on the IRC.  At the present time there are only 4 other people signed in (besides myself) and I honestly don't see any interaction between them or anything there to do other than to "chat" with them.  I'll check back later on that one!

I also successfully joined their Google group with NO problems.  You actually had to be approved for membership by filling out a short form and giving your reasons for wanting to join (probably to keep out bots or something) and it took less than 20 minutes for them to send my "acceptance to the group" email.  Once arriving at the group's main page it is obvious that LOTS of communication goes on here!  With just some simple browsing around I'm seeing a variety of issues discussed on this page—it should be helpful, more on that too later.  I went ahead and placed that link on my blog page as well so I won’t have to bookmark it (see top right corner).

I still have to read “The Cathedral and the Bazarr” but probably won’t get to that until tomorrow—so that’ll give me something to add then.

Taking Shape

I did like that today each group was able to spend time hashing out ideas on which FOSS projects our group would be most interested in contributing to.  I felt it was productive and believe that any of the 3 projects we're looking into would make for an interesting experience for us.

RapidSMS would have us working with cell phone's SMS technology for the purposes of helping people plan & communicate in disasters and other desperate situations.  OO4K would present the opportunity to work with "office" software that is designed to be used by kids.  IfPeople uses a vast "toolbox" that enables its customers to put the WWW to work for them in the most efficient manner.

We still have a few days to investigate our top picks, which will be what is on tab the next few days!

Back to the millstone

After an enjoyable 4 weeks it is time once again to start pulling the stone a little closer to the finish line.  I haven’t made the time to do a blog before so this will be my first experience at that…a similar truism could be said for my use of wikis, so I expect a few bumps along the way.

We formed our team today in class and started the arduous process of determining good meeting times.  Hoping to spend some quality time tomorrow looking into our project possibilities….but for tonight, it is time to make a serious start at reading Chapters 1 & 2!