Day 24: Finale

The project has been completed, submitted, and accepted.  One can visit the Activity information page hosted on Sugar Lab's wiki or head on over to the Activity wiki page developed by our team.  At the time of writing this blog entry, our activity is categorized as 'experimental' and has 13 downloads.  Also, the other members of the team have been able to create a poster that summarizes the events taken in order to make this activity usable by the Sugar software that will be available on display tomorrow from 11:30am to 1:30pm.

We must now prepare a presentation for our final grade in CSCI 462, Software Engineering.  From fixing a bug in the software to developing our own Activity, we will be sure to report on all aspects of the project (including information about Sugar Labs founder, Walter Bender).

Day 23: Victory!

It's done... for the most part.  Megan found a quick function that allows the Activity to appear fullscreen and without  any of the 'windowed' features.  The only thing we need now is a way to quit the Activity by means of incorporating the Sugar toolbar or creating an exit button in the Activity that calls the PyGTK exit( ) function.  Since much of the headache is now over, we can begin to focus on the presentation aspect of the project.  We currently have an open office presentation hosted on RapidSVN in order for all team members to be able to add and make changes to the file.  We are beginning to see the end to this project, but that doesn't mean we will not continue to keep it alive.  While it doesn't have much functionality at the moment, we are able to leave it open for continued development.

On another note, we were able to configure our Activity's icon to be transparent and change color based on the color of the Sugar user's XO character.

At today's team meeting, we can try to submit the Activity for review by the Editor so that we can also begin creating the wiki page.

Day 22: Sugar App Fights Back

So, we have come across our first real roadblock in creating our Activity for the Sugar software, and it's not so much our coding as it is porting the program to the Sugar platform.  Currently, the Activity will appear for use in the Sugar emulator, but it comes in the form of a window.  We cannot have this happen because we are not sure that the XO laptops have a window feature, seeing as how all they run is the Sugar OS which incorporates any Activities into a single plane.

In analyzing the two files involved in porting the Activity, the Python and XML files, we have found a key piece which sets the Activity to be opened in a PyGTK window.  However, we need to find something that allows for the Activity to not only fill the entire screen like other published Activities, but also remove the 'windowed' view.  We feel a solution is just around the corner, so we'll hopefully have some positive news to share for the next post.

At today's team meeting I would also like to start on creating the presentation for our project.

Day 21: Pack it up, Ship it out

Packaging our Activity has proven to be more difficult than we thought.  We have read multiple wiki pages and compared our code to source code from example Activities to try and learn by example.  Since one of our worries is that we are forgetting to import a certain component in the Python file, I will have to try to diff the example file with our own in looking at just those pieces that do some form of importing.  I have also sent an e-mail to the sugar-devel mailing list to see if they can return to us a list of step-by-step instructions as to how to package the Activity into an .xo file format.

A couple of weeks ago we were able to get the project into a repository using RapidSVN (downloads available through this link), so any changes that may affect the file to "a point of no return" can be rolled back.  Every member of the team has a working copy checked out so that we all can try and create the solution to our packaging problem.  One note, our team member Jordan found that the .xo file format functions just like a zip file, and certain tools can merely extract or compact the associated Activity files.  Hopefully during our next meeting we will have the solution or at least I will get a response from the sugar-devel support.

Day 20: Status Report

Now that we have completed week 3 in our timeline, we are prepared to apply a checklist against a set of possible problems that we may run into in using the Activity.  This sort of testing should be relatively easy as the only user input is the number of Fists of the food group that he or she has eaten.  Also, user input is limited to the choice of number provided by PyGTK's combo box object in the form of a drop down list.  I will have to meet with the rest of the team to talk about any additional testing. 

I am also getting ready for week 5 trying to find out how to get a wiki page published and placed on the site with the other Activities.  We also need to know how to bundle our Activity in order to transfer it to the Sugar platform.  The Sugar Labs wiki describes "packaging activities in self-contained bundles [to allow] easy sharing, installation, removal, and backup."  So, we need to make sure we meet all these requirements in order for proper use of the Activity and the ability to send it to other Sugar platforms that do not already have the activity.  This is a process of interaction amongst the XO laptops, where the child without the Activity will receive it upon using something similar to a shared environment (an example that comes to my mind is the use of Windows' Sharepoint).

Day 19: In the Thick of It

We are now halfway into our scheduled work plan finishing up the GUI and getting ready to write the code that will constitute the algorithm for computing the user's 'health score'.  When we divided tasks among ourselves a couple weeks earlier, we did not know the length of time to which each task was realized.  As of now, we no longer need the use of a database to store the food groups and other possible attributes and their values, so Jordan is now able to research how to import the Activity into the Sugar software with the help of the tutorial we all followed in beginning this project.  Megan has come up with the algorithm that will calculate the health score, but as I said earlier, we are not ready to code it just yet.  Our concern at the moment is helping Alex with the GUI (primarily with finding out how to get the input values from the combo boxes and selection drop-down menus), a task that has required the most attention so far.

A little drawback like this does not mean we are not on schedule, in fact, we are right on time with providing each deliverable as specified by our timeline.  Flux Capacitors plans to make a great first activity for use with the Sugar software!

Day 18: POSSCON

The open source conference in Columbia was a great experience for a student like me getting ready to graduate and trying to find an interesting company that uses database technologies.  One such company, BackType, makes use of database and data mining technologies in dealing with large data systems.  The speaker for BackType, Nathan Marz, was able to explain the eight properties of large data systems as follows:

1. Robust
2. Low latency reads and updates
3. Scalable (horizontally, adding more machines as the data size grows)
4. General (abstracting whenever possible)
5. Extensible (able to add new features)
6. Ad-hoc analysis (this is where the data mining comes into play)
7. Minimal maintenance
8. Debuggable

Marz also described dividing the system into two layers, the batch and speed layers.  Using a tool called Hadoop, one is able to create this structure and use message passing and filters to create incremental algorithms that check for false positives in creating batch views.  Although the batch layer is slow with high latency and high throughput, it contains the master copy.  The speed layer compensates for this by utilizing more complex algorithms and transient data (meaning that the data is discarded from the speed layer once it is passed to the batch layer).  In a sense, the two layers both gather data only to merge it all together to create a real-time view.  The databases associated with containing the data are mostly Read/Write databases and not the widely used relational databases that I have always worked with.  However, one can still use MySQL, for example, to query the database.  Backups, as well as full recoveries, can be done using the batch layer while the speed layer continues to append more data to it's log.

I was also able to sit down with two teachers from another school and a representative from Oracle.  I learned about Oracle's diverse range of software products, as the representative was saying one could find Oracle just about anywhere there is IT.  We also got into a discussion over the usefulness of Virtual Box, something I currently use to host a SQL Server 2008 server on Windows Server 2003.  The representative was very appreciative of the complements we had to say about the product.  The two teachers had mentioned an idea to make the software communicate with other instances of Virtual Box.  I only know about a feature in Virtual Box to communicate with the host computer, but not other instances.

As for our project, we have been able to simplify the problem by removing an inner portion to the linear regression equation.  Currently, we need only to calculate the weight of each food group for use in the linear regression equation.  Alex, with her skills using PyGTK, was able to reflect this change in the GUI in presenting it to us.

Day 17: Road Work Ahead

While preparing for POSSCON, and a possible chance to meet Walter Bender (one of the lead developers of the Sugar software), we are also laying the foundation in completing a new Sugar Activity.  Our team member Alex has presented us with a GUI she built using Glade, a program that utilizes PyGTK and XML to produce things like combo boxes and allows for data entry into categories.  We also suggested the possibility of including class diagrams in the documentation, but we have not come across the need for many so the number of diagrams will be fairly small.

We also started to think more about the algorithm involved in calculating the score of the user's diet.  I mentioned using a regression formula the week before, because the calculation involves a weighted sum.  With more research, I found the answer to be just that, straight-line linear regression.  In our case, the variables are as follows:

• weight = the weight of each food group (according to a food pyramid TBD) = (Servings of Group) / (Total Servings)
• numServings = the user will pick a number of servings of a certain food group they have eaten (Alex currently has the measurement of Fists)
• foodGroupScore = sum(weight_n * numServings_n)  --> where n corresponds to a specific food group as selected by the user

Still, there is a level deeper that may be ignored in this calculation in including the impact each food in each food category has in determining the suggested number of servings of that food group because it is already given by the food pyramid of choice.

Day 16: Preparing for POSSCON

In preparation for Thursday, March 24 POSSCON events, I have come up with the following questions for selected presenters:

1. Early in the morning is the introduction to the event, have to make sure I grab a guide of some kind.
2. Chris Hinkley has a 15 minute track on web hosting addressing the application layer.  I want to ask what kinds of logic should be implanted in the database layer.
3. John Mertec will be talking about deploying easy PHP application security, so I want to ask what he has in mind for such things concerning database driven websites.
4. Immediately following his presentation is Nathan Marz in building large data systems.  I want to see if his designs are similar in the ways in which SQL Server deals with splitting pages of data in order to create a new node and more space.
5. Afterwards, there are a couple of leadership tracks in data governance and becoming efficient in a business.  I might have to just listen to their presentations to see if I have any relevant questions.

 There is a lot to learn here, and unfortunately I will not be able to get to some of the concurrent events.  This is a schedule for what I have picked to be the most interesting and career specific for me.  On a side note, there are plenty of Linux organizations attending the event, so I am glad to have some experience using Ubuntu because I just might see some use instances during the presentations.

As for our project, I have related the documentation and other resources mentioned in Day 15 to my team members, and now we are creating the algorithm that will calculate the score on the health meter for our Sugar activity.

Day 15: Back on Track

After some well deserved time off and tranquility, we can now get back to working on our project.  I forgot to provide the link to the Sugar Labs API, it is the following:

http://api.sugarlabs.org/

The folder epydocs/ contains a table of contents listing the modules and their corresponding classes, functions, and variables.  The folder puppets/ is something I'm still not familiar with in that it also contains the same elements as in epydocs/, but for a different set of modules.  One such module I noticed in particular is the use of MySQL and PHP to create database driven websites, something those students in CSCI 332 have done before.  Lastly, the folder sphinx/ contains a table of contents for all of Sugar's documentation, listing the source for how to build an activity and import graphics (lucky us!).

Intermission

Although the team has adjourned for Spring Break, we have divided up some tasks for research and development in the continuation of our project.  I am currently researching Sugar's library of Python methods in trying to become familiar with some of the important pieces for use in creating our activity.

Day 14: The Game Plan

After submitting our fix to modify a couple of Python files in the Sugar code base, we gathered yesterday to discuss the course of the team's efforts for the rest of our time together during this semester.  I do not think anyone in the group wanted to write test cases, since it would be a repeat performance of the projects we had completed in CSCI 362.  Instead, we decided on developing software in the form of creating an activity for the Sugar environment.  Our team member, Megan, pointed us in the right direction by finding Sugar's Wikipedia page on how to create an activity.  This step by step guide shows one how to create a simple activity by giving the reader the code needed in order to perform the setup operations.

Towards the bottom of the page, there is a command to install the compressed activity in the .xo format as follows:

sugar-install-bundle HelloWorld.xo

I mentioned earlier the use of the Surf.xo activity recommended over Sugar's Browse feature.  I installed it using the command above, replacing HelloWorld.xo with Surf-115.xo.  I received a successful completion in the terminal window and noticed the activity appear in the Sugar environment, but upon using the activity to search the Web, it failed and returned me to the start-up screen.  However, in using a USB to transfer the program to the Sugar emulator, the program would respond well upon use.  I'll investigate further to see if the problem is a matter of placing the file in a particular location in order to use the command appropriately.

Getting back to our timeline, we have created some initial tasks to divide amongst ourselves for creating an activity that will present nutrition facts to children in the U.S.  There is a similar activity available for kids in Uruguay, click here.  So far, we have planned:

• A GUI
• Algorithms to calculate a percentage of "healthiness"
• A database that interacts with the GUI

Day 13: Need a Patch Stat!

Today's task was a fruitful experience in using the diff command in a Unix shell to compare a couple of example files.  This simple command proved to be "very powerful" (something Dr. Manaris seems to say about all the Unix commands we have learned in Operating Systems).  In reading TOS Chapter 7, our team can now formally submit a patch to the Sugar software with our changes involving the removal of white space and the new line character (i.e. \n) from the username field.  In using the diff command on my desktop PC running Ubuntu 10.04, I was able to see the changes in the two files printed to the terminal.  Comparing directories produced the same results, but with a larger listing showing multiple changes in different files.

Creating a patch file seems like the way to go in getting our fix committed to the code base.  Something like the following should do the trick while in the directory containing the files:

patch < model.patch window.patch

I went a little further to discover how to create the same effect in MS-DOS.  As it turns out, there is the same single command, fc, that takes two files, compares them, and outputs the results to the terminal.  I do not like to think that this command prompt has died, but it has not surfaced in my academic learning.  But, maybe that's just the point, I am to learn Unix and to discover MS-DOS.  One thing I noticed, the fc command is unable to compare two Microsoft Word documents, possibly because of all the specialized formatting in the background of every document.  Simple text files created using Notepad use the ANSI Encoding attribute, so they can be used appropriately when comparing the files.

Day 12: First Submission

After staying ahead of schedule for about a week, we were finally ready to submit our fix.  Our team member, Megan, adjusted some of the white space in the code that would have worked otherwise, but since Python is sensitive with things like its indents, it was causing the program to crash while messing with the input box for the user name.  We are currently waiting for a response from the developers to see if they will accept the fix, or possibly recommend some additional alterations of their own.

Since it seems I cannot post the files themselves that we modified for the fix, I can only say the following were affected:

• window.py
• model.py

Day 11: CS Symposium

Today's event was the 5th Alumni Symposium for the Computer Science Department at the College of Charleston.  We all sat down to listen to a "3 minute madness" presentation by each of the presenters.  Between the information presented by each person, I was hearing the same concepts taught to us by the Software Engineering courses.  There was much to do about the proper gathering of requirements and communication among people involved in a software project.

It was refreshing to hear about what these representatives look for in a qualified candidate in hiring someone for  a position in their companies.  The fact that one need not know everything there is about computer science in the general sense, but rather know the specifics of selected pieces in order to acquire the job wanted, is the idea I try to follow.  I actually became interested in the database side of things in CS, and I am taking up a Microsoft Certification course to be a DBA starting March 2nd of this year.  In the end, I consider the Symposium to have been a great experience for all the CS students to get an idea of how their skills will be applied at the job of their choice.

Day 10: Target Unconfirmed?

We have now decided on a bug for our team's project to pursue in hopes of resolving an issue with ticket #2485.  The link leads to a description of the bug, telling interested users about an Unconfirmed bug(?) where students using the Sugar software were able to enter leading and trailing white space before entering a username.  Our team member Jordan has already come upon a solution to the problem; since the code is written in Python, we will use the .strip() command to shrink the username to the remaining text.

Just after e-mailing the developers about this potential problem, Walter Bender, one of the lead developers, replied both in a comment to the bug and in an e-mail to the developers list:

"Be careful here: some students are using the name field to input a multi-line emoticon graphic as their name. I don't worry too much about white-space in single-line names, but it could matter in a multi-line name."

An emoticon (i.e. the smiley face graphics commonly seen in forums) does present a problem in using the .strip() Python command.  Any options in the .strip(<option>) command are for characters only.  Somehow, these students have been able to place graphics into the supposed text-only box and we need a solution as to how to either remove the use of emoticons or convert the graphic to its text equivalent (that way the .strip() command can remove the white space present in multiple lines).

Day 9: Bug Problem

I just completed another activity assigned to the class as a way to introduce ourselves to the bug tracking side of software development.  This activity involved navigating the bug tracker in order to create an understanding of our project's layout in terms of tracking bugs.  I found the oldest bug to have a ticket number of #17, assigned the status of assigned, and given a milestone as to when the bug was discovered (in this case, at v0.86).

The bug itself is causing a problem with the Sugar emulator used to test and develop the code.  Upon reading the history and some of the comments made about the bug, it seems it is a cross-functional instance where Xephyr is turning off access control because the "Sugar-Emulator uses the '-ac' flag in the Xephyr command line."  This just means other programs can run via a USB drive or some other forms of I/O and take over without the ability to kill them while the Sugar code is in execution.

Creating an account in the bug tracker, so we can get notifications of future bugs, is as easy as signing up for an e-mail account.  Simply click the Register link at the top of the page and enter the essential information.

Submitting a bug report has been something I have known how to do since my experience with Relic's games.  Their system is well organized, in that if the program crashes, a Bug Report pops up and allows the user to enter the information to better understand the problem.  Upon reading TOS, Chapter 6, I now know a standard by which to submit a bug in order to get the proper response to which it deserves ("Never underestimate the power of attention").

As far as reproducing a bug, I have come across a case where the instructions to reproduce the bug are given in the comments!  They are the following for ticket #297:

• Use Browse
• hover slowly over a link until the cursor changes
• the pointing finger should be at the position you were hovering - but it is already over half of the lin

In my reproduction of this bug I have experienced no form of failure.  I read on to find that the issue had been resolved with a patch for some instances/distributions (including my own).  It was suggested that the bug be moved from a status of blocker to critical for the remaining distributions.

In the end, this activity brought about a change in life for me, in terms of performing a proper bug investigation and submission.

Day 8: Practice Build

Today's task was similar to the previous day's events.  We had an activity that allowed us to retrieve and build the source code of a simple project as an example for future use.  However, our team had already done this step in the development of our project with Sugar.  The activity required us to check out the latest version of Freeciv (a game) using Subversion and the terminal commands:

svn co svn://svn.gna.org/svn/freeciv/trunk freeciv
svn update (in the Freeciv directory)

This process was similar to that of getting the source code for Sugar, in that we received a clone of the source from the repository and issued the same update command in order to acquire the latest version.  The next step in the activity with Freeciv differed from that in building Sugar.  Instead of getting any of the dependencies manually, like in the activity, Ubuntu recognized any packages outstanding that were required for the Sugar code and installed them alongside the code during the installation process ("This is where Linux distributions shine" TOS).

See the link in the Day 7 post for the instructions on how to install and build the Sugar code.

Day 7: Get the Source, Get the Build

Saturday's meeting:

Today we had the chance to install the Sugar application on Ubuntu.  First, we installed the application using the following command in Ubuntu's terminal:

sudo apt-get install sugar

Second, after installation we had no clue where the application was located in the File System, so we searched for about a half hour.  To our surprise, the application runs as another session in Ubuntu, or in other words instead of using the default GNOME session, one needs to switch to the Sugar session while at the log in screen in order to run the application.  Lastly, one needs to download some activities to run in Sugar, the most useful being the Surf browser activity because the Sugar documentation for installation had recommended this browser as it is the only one that cooperates with the system.

As far as getting the source code and building Sugar our team member, Megan, found the gold mine in terms of useful documentation.  The following wiki, sugar-jhbuild, gives a detailed description of the installation process. 

Day 6: Subversion is Upon Us!

The next task for the whole class of students to tackle was the installation and understanding of Subversion, a version management system we are going to use in conjunction with our team projects.  I decided to download the tool from CollabNet (2000), which offers detailed support for how to use the system for newcomers like me.  In reading the first several chapters of Version Control with Subversion, I have come to understand the first steps in deploying the system on my machines.  I experimented further to find out how to create my first repository, which I plan to use for the team project.

Chapter 2 proved to be the most helpful at this point, as I needed to know how to get files into the repositories after establishing them on a newly created server.  What is nice about CollabNet's layout of the file hierarchy is that it conforms to the books recommendations of /trunk, /branches, and /tags.

Another interesting note, the idea of Subversion providing locks on files that are currently being used is similar to the idea of two-phase locking that I learned about in CSCI 332 for database management systems.  It's nice to see the same ideas deployed in other areas of software, even though my interests are mostly concerned with the database side of things.

Day 5: Initial Dive

Our first group meeting outside of class was held at Taco Boy to develop a report on the Sugar Labs project.  Environments outside of the classroom provide for a chance to socialize and perform the Norming stage of team development.  Our research during that time lead us to devise a structure of the report for the project.  We were able to divide tasks to each team member in order to give a piece of the report at the next class meeting.

My task was to gather together all the components necessary to install a running version of the Sugar software and its Activities.  I was unable to successfully create such an environment on a Windows platform, however, I did manage to create one on Ubuntu using the following components:

• Ubuntu Software Center - search 'sugar' in the text box, then download the emulator
• Ubuntu - an open source platform used to supportthe Sugar software
• Xephyr - turns a window into a framebuffer/VOD

At first use of the software, I had already noticed some bugs (some on the part of the component used as the framebuffer, Xephyr).

Click here for a list of available OSs and their instructions for installation.

Day 4: A Bazaar Reading

The reading on Cathedral and the Bazaar was a review for me from CSCI 392.  It was refreshing to look back upon the numbered key points once again and reflect upon how they have applied to CSCI 362: Software Engineering and will, of course, apply to CSCI 462.  Eric S. Raymond's comments on the importance of documentation, effective security (no pseudo-safety measures), great programming, the treatment of co-developers, and citing work from other contributors will forever remain an active effort.

Also, today the entire team had their first experience joining an IRC client and professional mailing list (listserv) for our selection of Sugar Labs.  We decided to join the development listserv, and immediately after joining our e-mails were populated with around 12 messages concerning development of the Sugar 'Activities' and porting certain components to the XO laptop that this software adheres to.

Day 3: A Choice...

Today, it was cloudy and almost rainy, our group presented the three choices for our semester project.  It all came down to Sugar Labs as the prime contender, seeing as how OLPC was actually an organization using the software from Sugar Labs on their laptops and interest dwindled on our third choice, Open Office.

See the team wiki for a summary of each project.

Day 2: Judgment Day

The choice had been made for the final 3!  All choices involved helping the kids.  In fact, the One Laptop Per Child organization actually had the same projects available from Sugar Labs, seeing as how they used their software on the laptops they produced.  OLPC's mission statement is to deploy durable laptops targeting children (roughly in elementary schools) in certain areas of the world in order for them to create a foundation of learning.  The software from Sugar Labs is intended to teach kids to learn learning; that is, teach them the process of learning and share their knowledge with others so that it may grow.

Also, I read Ch.1-2 of TOS.  I learned about the important characteristics of a team member in developing open source software.  The ideas from these two chapters are in agreement with those expressed in The Cathedral and the Bazaar in emphasizing the importance of creating a team environment.  The treatment of co-developers is important in order for them to feel like contributing to the progress of any software project.

Day 1

Our first task for the semester-long group project was to form into groups and undergo the Forming stage of team development.  We had an exercise that allowed us to introduce ourselves, create a team name, and set roles for the team members.  Luckily, I had already become familiar with my team members as we have already had other classes together.  I became the reporter for the group and am looking forward to continuing the update process on our team wiki and this blog.