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