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.