Last Blog

The Nutri activity is complete.  So far, there have been 15 downloads.  We've submitted our poster, and we're almost finished with our presentation. 

The activity we submitted is very simple.  Our goal with this project was mainly to walk through the whole process of creating and publishing a Sugar activity, not so much to have a great activity with lots of great features.  Now that it's been published, I'd like to continue working on it so that it can be a really neat and helpful activity.  Initially, I'd like to refactor the code a little and make it more readable for future updates.  (This will also help me to become more familiar with the Python and PyGTK that we used since I wasn't as involved in this part of the project as others on my team.)  I'd also like to update the GUI a bit.  I think that just a few simple changes will make it look more Sugar-ish and kid-friendly. 

Overall, this was a fun project, and it has been so exciting to see the Nutri activity up on the Sugar Activities site.  I do wish we had divided up the work for the project more effectively.  If we each had our own portions to work on, we might have ended up with a better finished product.  Our last meeting (during which time we finished up the activity and submitted it) was the most productive because we each worked on a different aspect.  One person worked on our presentation.  I worked on submitting the activity, adding our code to Gitorious, and adding all the important information to the Nutri wiki.  Another person worked on our poster.  If we could have worked that efficiently during the whole semester, we could have had an even better activity.  Even so, I am very pleased with our work this semester.

Success!

Last time I blogged, we had our nutrition activity running on Sugar, but it wasn't filling the whole window.  After trying several different options, we finally found a command that makes the window open in fullscreen mode, and that worked.  The only problem was that there was no way to exit out of the activity.  For now, we just added an exit button.  In the future, it would be nice to add the Sugar-style toolbar which would have its own exit button.

There were still quite a few steps to getting our activity published on the Sugar Activities website.  We created a wiki from which you can download the activity.  It also contains a list of the features we would like to add to our activity in the future.  We added our source code to Gitorious since it is an open source project.  Then we submitted our activity to Sugar.  Our activity's profile can be found here. 

Today I had to go back into the activity's profile and add a few things that I missed yesterday.  I needed to add Alex as one of the authors, and our logo so it would show up on the profile page.  This proved to be somewhat difficult.  It took me awhile to even get to the place where I could edit this information, and when I got there, the links and buttons to add information weren't working.  I hopped onto the Sugar IRC channel, and asked if anyone had advice.  They did, and I was able to add the missing information.  That was a little exciting for me because it was the first time I had used the IRC (except when we were just messing around because we had to use it for a class assignment).

We also created a poster about the Nutri activity for Thursday's poster session.  I think it turned out pretty nice.

Coming Down to the Wire

Last week we successfully ran our nutrition program in the Sugar Emulator.  The program works fine except it shows up in a Ubuntu-looking window, not the standard Sugar window.  We think this is because our GUI is inside a window instead of a vbox.  The problem with simply changing to a vbox is that other components depend on the window.  There is some instruction on integrating the standard Sugar toolbars into an activity.  I think this might also help with our window problem.  After that, we will be able to submit our activity and create the wiki.

Roadblock

We are still trying to run our activity on the Sugar OS.  We've been reading different documentation that we think might help us.  Also, Austin emailed the developers' mailing list to see if we could get more help that way.  Hopefully we will get the activity working today since we are getting down to the last couple weeks of the semester.  We also need to start planning our presentation.  We're planning to meet up this weekend to get caught up.

Sugarizing

Our nutrition activity is ready to be sugarized!  We found the lost sugar activity manual that explains how to revise our program so that it works on the Sugar OS.  During our last meeting, we added the code that we thought was necessary, but it still doesn't work when we launch the activity in Sugar.  That will be our task today.  Once we have that working correctly, we can submit it to the Sugar Activity team for approval and write some information for our Wiki.  At that point, we will post a list of our desired features.  (The list is long because our program is very simple so far!)

Slowly but Surely ...

We continue to work on our Sugar activity in Python.  Since none of us is very familiar with Python and the PyGTK framework, it is a slow process.  Integrating the GUI elements with our data has been the trickiest part.  After simplifying our original plan several times, we have finally come up with a program that is ready to be sugarized. Once we have created our icon and bundled the program into an .XO package, we need to get our activity onto the Sugar Labs website so that it can be downloaded.  I think we will also have a page on the wiki where we can post some information about our activity, including features that we would like to add.  There was a very helpful FLOSS manual that spelled out the whole process (referenced in an earlier blog), but it is gone now.  I did find a way to submit our .XO package.  I'd really like to make sure we've included everything before we submit the activity to the review team.  We may email the development team to try to find that manual, or we may just try to submit the activity and hope we did everything correctly. 

POSSCON

I attended POSSCON on Friday.  There were 2 workshops sessions, each 2 hours long, as opposed to the many 45-minute sessions on the previous days.  In the car ride up to the conference, someone who attended the conference the day before talked about the 3D printer presentation.  I hadn't been interested in this topic when I saw it on the website, but I was more interested after hearing about it so I attended the workshop.  They showed us some free open source software that one can use to create 3D models to print on the printer.  They also set up tables with different components of the printer so that attendees could attempt to put one together.  The workshop was very interesting, but I would have liked to hear more about what they see as major future uses of 3D printers if they become a standard tool for households and businesses.

The second workshop I attended was on Drupal, which is an open source tool for creating large, complex websites.  I was fairly interested in this software, but was very disappointed in the presentation.  For the first hour and a half of the workshop, 2 guys talked through a PowerPoint presentation of Drupal.  The slides were all formatted the same:  bullet points in white text on a black background.  I would have appreciated a demonstration of Drupal and some of the websites that illustrate Drupal's unique abilities.  I tried to download Drupal while in the workshop so I could get a better idea of how it worked, but it seemed more involved than what I was willing to deal with just to test it out. 

I think that Thursday would have been a much better day to attend the conference.  There were more sessions available because they were shorter.  I thought the 2-hour sessions were too long.  I also think that many presenters didn't stick around for Friday.  Many of the booths were empty.  My classmates who attended on Thursday saw Walter Bender give a presentation on an XO laptop, and were able to chat with him after.

Overall, it was a good experience, but I wish I had been able to go on Thursday instead of Friday.

Project Progress

We are currently in Week 2 of our timeline for our Sugar Labs activity.  I think we are on schedule although the plan needs to be adjusted a little.  We at first thought that we wouldn't start coding in Python for a while, but then realized that we need to use some Python when designing the GUI.  The other change to our plan is that we probably won't be using a database as previously thought.  Instead, our data will be stored in Python lists.

Alex has made a lot of progress on the GUI using PyGTK and Glade.  Most of the code is in an XML file, but there is also a little Python.  There are a few changes that we'd like to make to the functionality, but it is a good start with a layout that we are pleased with. 

We have also spent some time talking through the algorithm that we think will work well to come up with a score between 1 and 100 (determined by what the user has eaten in a day).  We've decided to weigh each food group based on how many servings are recommended in a day.  Since there are 5 food groups, there is a potential for 20 points from each group.  The number of points for each serving, however, depends on how many servings are recommended from that group.  For example, since 6 servings of grain/bread items are recommended, each serving is worth 3.33 points.  So if a child eats exactly 6 servings of grains in a day, he/she will earn 20 points for the grain category.  Only 16.67 points would be awarded if the child only ate 5 servings.  If the child goes over the recommended servings, we will start subtracting from the total.  So eating 8 servings of grain would result in 13.33 points.  We realize that this is a very simple algorithm, but we think it will serve our purpose for now, and we can adjust it later if necessary.

Preparing for POSSCON

The Palmetto Open Source Software Conference is coming up next week.  I've got a couple of classes that I can't miss on Thursday so I'll only be attending the conference on Friday.  There's not a whole lot going on that day, but at least I'll get to experience some of it.  On Wednesday and Thursday, the sessions are shorter so there are more of them.  On Friday, there are only 2 sessions (workshops), and they are each 2 hours in length.

Our assignment during POSSCON is to try to meet 3 speakers that we had chosen beforehand.  My first choice of all the speakers is Walter Bender.  He is the founder of Sugar Labs, and I would love to have the opportunity to talk with him about our group's planned activity and any advice he has.  Also, he is interesting to me because his experience with open source is with humanitarian efforts.  This is something I can see myself becoming more involved in once I'm finished with school.  At the conference, he will be on a panel of executives speaking about the future of open source.  Hopefully he will still be around on Friday.

Of the 4 workshops offered at 9:45 on Friday, I've narrowed my choice down to 2.  One workshop is about open source CRM software (presented by John Mertic, Sr. Software Engineer of SugarCRM), and the other is about OpenOffice (presented by David Both).  Both topics are interesting to me, but I will have to do a little more research before I decide.  Whichever I go to, I would like to meet that presenter and ask some questions.

For the 1:15 workshop, I will either attend the History of Linux (presented by John Hall) or Starting a Business on the Cheap Using Open Source (presented by David Duggins).  I've done some reading on the History of Linux so I think this workshop would be interesting, especially now that I have some experience with Linux and more knowledge of operating systems in general.  I'm not planning to start a business, but I do think it would be interesting to see what open source software that is available that Duggins thinks would be beneficial to businesses.

Besides POSSCON, I will also be attending the Check-IT-Out conference in Waxhaw, NC (south of Charlotte) this Friday and Saturday.  (I've actually been having a hard time keeping straight which conference is on which weekend in my head.)  This conference will focus on the software, etc. involved in supporting Bible translation efforts around the world (mostly Wycliffe Bible Translators).  It will be held at the JAARS facility. 

I'm very excited to know more about what this organization does and the software they produce.  I'd also really like to know what volunteer opportunities are available.  This seems like the perfect situation for open source.  I'm curious to find out if any of their work is open source, and if not, if they have considered it.  I think that I will gain some insight at this conference that will help me to ask more meaningful questions at POSSCON about how open source could be incorporated into Bible translation software.

Timeline

The Flux Capacitors have come up with a timeline for our Sugar Activity:

Week 1:  Design, diagrams
Week 2:  Create database and algorithm
Week 3:  Implementing design in Python and SQLite
Week 4:  Assess our progress and adjust plan accordingly
Week 5:  Sugarize and publish activity; create wiki page on Sugar Labs site
Week 6:  Handle any outstanding issues and present project to class

We believe these are realistic goals and that we'll be able to learn a lot in the process.  Besides coming up with a timeline, we've also decided that each member of our team should be an expert in one area of the project.  Although we all will help with each part, only one person will be responsible for doing extensive research on the topic.  Our areas of expertise will be:

Jordan:  Databases (SQLite)
Alex:  GUI design and graphics
Austin:  Sugar API, Python
Megan:  Nutrition content, algorithm

Now the Fun Begins

My team (Flux Capacitors) has been considering working on a new activity for Sugar Labs as our project for the rest of the semester.  We decided to each tackle the Hello World tutorial on the Sugar wiki to see if we thought this was a realistic goal.  For the most part, we were all successful and decided to move forward on our plans for the project.

Our activity will help to teach children about having a balanced diet by eating appropriate servings of food each day from the different food groups.  The activity will be a daily journal they can keep that will tell them how healthy their combination of foods was, and make suggestions of what they can eat that will help them score higher.  To begin with, there will be simple drop-down menus to choose the different foods they ate during the day.  The algorithm will analyze their combination of food servings and come up with a score (probably between 1 and 100).  A "health-o-meter" (or some other meter) will display the score for their entries.  We hope to make the meter fun with sounds, graphics, and/or comments.

The activity will also give some suggestions about what other food groups they should include in their diet to make a higher score.  It will also tell them why that food group is important and how it can improve their health.

We've come up with several of the main tasks that we will need to complete, especially at the beginning of this project.  We plan to use an SQLite database to keep track of all of the different foods and their groups.  We have also learned that the graphics for Sugar activities should be in SVG format, and they recommend using Inkscape.  This is another new tool that we will have to invest a little time in learning.  Since we're also designing the activity, we'll have to research the different food groups and the recommended servings so we can come up with a good algorithm for determining the daily score.  Once we get to the point that our activity is working in Python, we'll need to "sugarize" the project using the Sugar libraries and commit it to the Git repository.  (Initially, I assume we'll just keep our project on the 462playground in the CIRDLES server using Subversion.)

******

Status of the Android App

I've finished working through most of the tutorials on the Android Developers' site.  I met with my friend (my "client") who has the idea for the app, and we came up with a simple plan for the first version of the app.  I've drawn some simple diagrams of the classes I'll need for the app (only 3 for right now) and the layouts for the input and output screens (only 2 for now).  I've realized that I need a little more info about how this app should work.  My plan is to email some different input scenarios to my friend so he can let me know what his desired output would be.  This will help me to better design the algorithm/query.

I'm somewhat familiar with writing SQL statements to query the database (SQLite for this app), but I am learning how to interact with the database using Java (specifically, how to use the data in the queries in my program).  I've started coding a little bit.  I re-used some of the database helper code from the tutorials that I think will apply to this app.  I've also started coding some of the GUI, based on other tutorials on the Android site.  I bought an Android App Development book that has a lot of information about layouts that should be helpful.

Patches

In chapter 7 of the Teaching Open Source book, we are learning how to create, submit, and incorporate patches.  We are currently in the process of submitting our bug fix to the Sugar Labs project so this is timely. 

The first exercise was to note the differences when the -u option was used and not used in the patch command.  Here are the 2 commands and their outputs:

[megan.weaver@stono ~]$ diff hello.c.punct hello.c
6c6
<    printf("Hello, World.\n");
---
>    printf("Hello, World!\n");

[megan.weaver@stono ~]$ diff -u hello.c.punct hello.c
--- hello.c.punct       2011-02-23 13:11:09.000000000 -0500
+++ hello.c     2011-02-23 13:11:35.000000000 -0500
@@ -3,6 +3,6 @@
 #include <stdio.h>
 int main() {
-   printf("Hello, World.\n");
+   printf("Hello, World!\n");
    return 0;
 }
The -u command shows a lot more information in the output.

In the next exercise, we changed a file in core utilities and created a patch file from the differences.  The change was to the echo.c file.  The change resulted in the echoed string being reverse.

Fixing Our Bug

What seemed like a relatively simple bug to fix turned out to be a little complicated.  The person who posted the bug suggested that any white space before and after the user's name should be trimmed.  We emailed the developers' list to let them know that we were interested in tackling the bug, and to ask them where we could find the code. 

Bringing this issue to their attention caused quite a string of emails about how making this change could negatively affect some users.  There are some users who choose to add white space in their user name to make a picture (emoticon).  We sort of understood the issue, but I wanted to make sure that we could duplicate this type of user name so that we could test our fix on those situations.  We followed a link in one of the developers' emails to a blog that included a picture of the multi line user names so we could see what it looked like.  Then it took a while to actually implement one.  It's not actually possible to type a new line character into that field.  We were finally able to make it work by typing the multi line emoticon into the Write activity and then pasting it into the user name field.

Once we were able to reproduce the situation, we could attempt to fix the problem.  We assumed that when first creating an account, a user would only enter a name with no special characters or new lines.  In this file, we simply trimmed (strip()) the name before saving it.  Once logged into Sugar, the user has the option of changing their name in Settings.  In this file, we check to see if any of the characters were a new line character.  If that were true, we wouldn't strip the white space.  If it were false, we assumed it was just a normal name that only included letters so we stripped the white space.

The Sugar Labs wiki didn't give instructions for submitting a bug fix.  To learn more about this process, Jordan emailed the developers' list again and attached the 2 files that we changed.  I think he received a reply stating that they agreed with our changes.  Not sure yet what will be done with them.

A New Adventure...

Tuesday was the annual CS Alumni Symposium.  There were about 9 alum present who told us a little about their current jobs/projects, gave us some advice for preparing for jobs, and answered questions.  The most helpful thing I came away with was that it is very important to be working on some project(s) outside of school. 

I was a little discouraged because I haven't done any outside projects.  I haven't even had an internship.  At first, I thought maybe I could get more involved in the Sugar Labs project.  Then I remembered that a friend of mine asked (a while ago) if I would be interested in working on a website that he and his clients could use for his business.  At the time, I felt a little overwhelmed and didn't see how I could possibly accomplish the task.  Now, I do have some more time (since I'm not working this semester), and feel like I have learned enough since then that it would be possible.  I contacted him yesterday and asked if he would be interested in an Android app (and maybe a similar website later).  I have more interest in learning how to develop an Android app and think it would be less of an undertaking.  He thought that was a great idea and we plan to meet to discuss his requirements within the next week.

In the meantime, I have installed all the necessary tools to develop an app, and I'm working on the tutorials on the Android Developers' site.  So far, I've written the "Hello, Android" app.  It took a while to get the Android Emulator working, but I finally have my "Hello, Android" app running!

In this project, I'm hoping to use the design skills I'm using in my Software Architecture and Design course, get some more Java experience, and have a better understanding of a software project from start to finish.  I'm also thinking we'll need to have some sort of database involved for what he wants.  Though I've worked with databases and sequel statements before, it will be good to learn how to integrate a database into the program.

Thinking about this application for my friend has also given me an idea for a Sugar Labs activity.  I think it's something that could be simple enough to implement and release before the end of the semester, and then we could add functionality later on if we'd like to continue with it.  I'm going to present the idea to my team next time we meet.

Bug #2485

We selected bug #2485.  This is an issue either when a user first signs up for a Sugar user account, or when a user updates his/her user name in the settings.  Greenfeld created this ticket because he believes the user name should be trimmed if there are leading or trailing spaces. 

We found the bug by emailing the developers' mailing list and simply asking.  At first we had tried a search in the code, but our search returned many results, and we didn't really have a good idea of what words to search for.  It was much easier just to ask, and the developers were very responsive. 

It was fairly easy to fix the bug in the code once we found it (in the two different files).  Then we rebuilt the project and ran it to make sure it changed what we were intending. 

Although our bug seemed straightforward and easy to fix, the contributors on the mailing list brought up some issues and potential negatives effects that this fix might cause.  We think that there is a compromise for fixing this bug (i.e., in the initial setting but not in the update settings section).  In order to test the bug, we'll need to learn more about creating a user account with a "fancy name" since that is the feature that might be affected by changing the code.

Tracking Bugs

The Sugar Labs project uses Trac, "an enhanced wiki and issue tracking system for software development projects," which includes a bug tracking feature.  I was able to search for all open bugs and then sort them by Ticket #.  (I assumed tickets are assigned sequentially and would be in date order.)  The oldest I found was Ticket #17, which was opened on 11/12/08.  Apparently there was a problem with access control when using the Sugar Emulator.  From the description given, it sounded like an easy fix to make, but as I read further comments on the bug, several people tried and were unsuccessful at fixing the problem.  I also noticed that the bug was also reported on Ubuntu's Sugar issue tracking system.  It seems that the bug was fixed and the status changed to closed on that system.  I think that this bug is no longer a problem, but it was never changed to closed on the Sugar tracking system.  The status is still "New."

Creating an account on the Sugar Labs bug tracking system was very easy.  I guess they welcome comments and help from anyone willing to use and work with Sugar.

The bug my team has started working on is Ticket #2485.  It seems to be more of a feature that user "greenfeld" thinks should be included rather than a defect.  The issue is that a user can enter spaces before or after the user name, and the program does not automatically trim the extra spaces.  This bug was easy enough to reproduce using the Sugar Emulator.  There doesn't seem to be any information missing in the description since it is a pretty simple issue. 

The most recent "New" bugs I could find were all entered by m_anish within the last day or so.  Apparently Walter Bender looks at new bugs because he commented on several of these entries in the last hour.  Most of his comments revealed that he was unable to reproduce the reported bug.  When we asked about the bug that we would like to work on, Walter and others replied with concerns about changing the code in question.  It might affect other functionality.  Walter also added this concern to the ticket.

Freeciv

Got a bit of a late start on this task because of Ubuntu issues (again).  This is the second time I have somehow disabled my Ubuntu installation by running the Update Manager.  I think I will ignore it when it pops up from now on. 

Once I was able to uninstall and re-install Ubuntu, I started the process of getting the code and building Freeciv.  The TOS book spelled out the instructions in detail, but apparently they are for Fedora, not Ubuntu.  This didn't cause too much of a problem because most of the differences were easy to find by searching for them on Google.  I was able to figure out several of the more difficult ones thanks to my classmates' blogs (Brittany Johnson and Bobby Strickland). 

Part of the lesson in chapter 5 of the TOS book was that "Sometimes you follow all the instructions, and it still doesn't work."  This chapter walks through the instructions for building Freeciv and points out where information is missing and how to go about finding it.  I found it interesting that even the TOS book seemed to have left out some information when trying to teach about it so we had to improvise.  Good learning experience. 

Sugar Update:
About a week ago, we found a bug that we thought we could tackle.  After doing some searches in the many files of code, we sent an email to the developers' mailing list in hopes that someone could tell us right where the code we needed to look at was located.  Several people responded quickly (including Walter Bender, co-founder of OLPC), and we were able to fix the bug in class and build/run with the changes to see the difference.  That was an exciting moment for us! 

I'm not sure if they will let us check the code back in.  I assume there is some sort of screening process before they let just anyone work on the code and commit changes to the repository. 

Another important lesson from this was the possible side effects of fixing this bug.  Several developers responded with concerns that changing the code might negatively affect the use of "fancy names".  Something that we assumed was relatively straight-forward and simple affects other functionality that we didn't even know about. 

Building and Installing Sugar

Thanks to the great documentation on the wiki (http://wiki.sugarlabs.org/go/Development_Team/Jhbuild), this assignment was not too difficult, once I had Ubuntu set up on  my computer.  I had Ubuntu at one point, but I uninstalled it because the Sugar Emulator (that is available in the Ubuntu Software Center), messed up my mouse functionality.  When I tried to re-install Ubuntu, I kept getting an error message that I did not have permission to download the file.  I was at the CofC Computer Science Lab at that time (Saturday afternoon), and eventually realized that the network there was blocking the install.  When Ubuntu wouldn't work, I tried to install Fedora instead, thinking that might be a better match for Sugar anyway, since Sugar on a Stick is based on Fedora.  What I learned is that Ubuntu is much easier for beginners to install.  Fedora requires you to set up your partitions manually for the dual boot mode.  I was hesitant about this, not wanting to erase all my Windows files, and I eventually gave up because I couldn't get it to work. 

I have learned a valuable lesson with these projects (projects in which I don't really know what I'm doing, and I'm just learning what I can along the way).  When I get to the point of extreme frustration and irritability, it's best to leave the project for a little while and come back to it later when I'm in a better frame of mind.  And so I left the project alone for the rest of the evening and decided to tackle it on Sunday.

In the meantime, I was thinking about the different posts I had read on the wiki.  I remembered reading about sugar-jhbuild in the FLOSS Manual for creating activities.  At the time, I didn't think much about it because the author did not recommend using this method.  In thinking about it further, though, he wasn't recommending it because his audience was wanting to run a version of sugar in which they could test their activities.  Our goal at this point was not to simply run sugar, but to get the source, build it and then run it. 

So I found the instructions on the wiki (above) for using sugar-jhbuild.  The instructions were straightforward (all executed from command line) but took a while to execute (at least a half hour).  I have Ubuntu version 10.04, and the instructions point out that only version 9.10 is supported.  I didn't want to uninstall and re-install Ubuntu again (that would be 4 times, actually), so I decided to try it on my version (hoping that maybe the wiki just hadn't been updated recently).  The build seemed to work fine, except there were many errors that I chose to ignore when given the option.  (I assume these had something to do with using the unsupprted Ubuntu version.)  When I ran the program, it seemed to work fine, except that none of the activities worked (probably because of the errors I ignored). 

There's also a package called "sweets" that is used for developing the core of Sugar.  We'd like to look into that a little more to see if that will be a better route for us.

I am pleased with our progress so far.  The bug that we are considering has to do with the user's login, and I think we have what we need to work on that.  We would still like to get the activities working so we can explore those source packages as well. 

Version Control

Our topic for today's class is version control.  We saw the need for this kind of system when we worked on our project last semester in 362.  My team's project, Sugar Labs, uses GIT for their version control, but I'm sure what we learn in class about Subversion will help with GIT as well.

Our assignment for today was to download Subversion and experiment with it.  I started out with a CollabNet version of Subversion.  I must have missed something because when I tried to open it, nothing happened.  I was re-routed to a web page that was non-existent.  Then, when I tried to use Python for a different project, I got a run-time error because it tried to open the Python version that comes with Subversion.  I un-installed Subversion, and Python worked.

This morning, I decided to try a different version of Subversion.  I had heard of Tortoise, so I tried that one.  It seems to work fine, so far.  I plan to work with it a little more and interact with the 462playground on the CIRDLES server.

More Sugar...

We continue to learn more about the Sugar Labs project and try to figure out how we will be able to work on it.  For our class presentation, we researched the history of the project and some of its main members.  The open source community is very intriguing to me.  I see some of these names pop up in the mailing list emails I'm receiving and don't think much about them.  Then after doing a little research (it's not hard to find their blogs and web pages), they become interesting people who have contributed a whole lot to this and other projects. 

We still haven't nailed down what we'd like to do to contribute to the project.  I think our first step is going to be getting a hold of the source code and figuring out how to fix one of the reported bugs.  From there, we will have a better idea of what we're getting ourselves into.

It's been a little frustrating trying to get into the actual OS and activities so we can see how it works.  I've downloaded Sugar on a Stick several times.  It seems to work once, and then I can't get back in so I must re-install the program on my flash drive.  Since that wasn't working so well, I decided to download Ubuntu and try the Sugar Emulator that is available in the Software Center.  I was able to get to the Sugar desktop, but there weren't many activities, and the mouse wasn't working very well (kept trying to grab when I wanted to click).  And then when I closed the Emulator, my mouse was still not working in the rest of Ubuntu.  I think there are several other routes that I haven't tried yet.  I've been reading a FLOSS manual for Sugar, and I'm hoping it will give me some direction.

Blog #3

My team has officially chosen to use Sugar Labs for our term project.  I've been trying to download Sugar on a Stick (SoaS) so that I can see how the activities work.  Also, I think we'll eventually be developing on SoaS.  (Not quite sure about that yet.)  I was able to download the newest version of SoaS (Mango Lassi) and had it working several days ago, but it shut down when I tried one of the activities (with the snake icon).  Hopefully I can't get it running again this weekend.

We were able to join the IRC channel for newbies and test it out a little.  Tonight there is a meeting on one of the IRCs.  I'm going to join it for a little to see what kinds of things they talk about in these meetings.

We joined the mailing list for the development team.  There is a lot of traffic on the mailing list, and I think I might unsubscribe for a while because I've been getting 20+ emails per day. 

Raymond presents some interesting ideas about open source projects and how to handle them so they are successful.  A lot of his ideas center around realizing the importance of everyone involved, from the best coders to the users who don't know anything about code.  All of these different people can catch bugs and contribute new ideas to the project.  Another important aspect is working together and accepting criticism and better ideas that may be different from yours. 

Sugar Labs

Our team (Flux Capacitators) has tentatively decided to work on the Sugar Labs project.  It is a spin-off of the One Laptop per Child (OLPC) program.  The project consists of activities that run on the OLPC XO-1 netbook.  I think this will be a great project for us to get involved with because it seems very well-organized and well-documented.  They also seem to be very willing to help students get involved in projects.  Many of their bugs and ideas for new features are labeled are labeled "easy" so that students who are just getting started with open source can easily get involved.  The tough part about this project will be sorting through all of the documentation and determining what we want to work on.  I think a good first step would be to work on one of the easier to fix bugs.  This will help us get familiar with the code and the scope of the project.  Ultimately, I think our group would really like to add a feature or work on a new activity.

My First Blog

This is my first blog!

I signed up for POSSCON today.  No problems.  I would like to attend both days of the conference, but I will have to make sure I can miss my non-computer science courses on those days.