Last day of Class... then finals!

On Tuesday, we met up to work on our presentation going over all of our work for this semester.  We each took a different part to cover.  My portion of the presentation will be about the bug that we submitted earlier on in the semester.  We've uploaded our presentation, and it can be found here.

Tomorrow is the last day of class.  I can't believe how quickly this semester has flown by.  Also, tomorrow is the poster session.  The poster is ready to go, and I'll be there from 11:30 - 1:30 (right about up until class tomorrow).  I'm hoping we'll find some people interested in our work this semester.

Overall, I'm very satisfied with what we've accomplished this semester.  Of course, Nutri isn't perfect (there's plenty of things that can be done to make it more user-friendly).  However, this will probably have to wait until after our presentation (along with finals and projects from other classes -- too many things going on at the moment).  I plan on working on Nutri after this semester is over.  I've really enjoyed working with Sugar as our open source project for this semester, and I think it's turned out to be a great learning experience for our team.

Almost Done!

This weekend, we made a ton of progress.  An overview of our progress can be found on our team wiki.

We met for almost 4 hours on Sunday, knocking out different tasks that needed to be done.  First of all, we finalized our first official version of Nutri.  We made a few minor tweaks to the image files (so that the activity displayed a little nicer).  After that was finished, Megan took the code and compiled it into the .XO file.

Megan also added our code to the Gitorious repository, which can be found here. This is where future development of Nutri will take place.  Using Git will enable us to work with any other developers that wish to contribute to Nutri, rather than Subversion (like we have throughout the semester).  This way we can still communicate with each other (meaning our team in class), along with other potential contributors.

The activity is now also posted on the sugar activities page!  This is very exciting to see our project actually becoming something that can be used by others.  I hope we'll get good feedback from users.  At the time of writing this, it looks like we already have 2 downloads (although that could just have been us testing it out...).  I'm interested to see how many downloads we get.

The wiki is now up and running! The wiki is where anyone can go to download the XO file, the source code to contribute, or to simply find out more information about Nutri.  Wiki's are the preferred form of documentation for Sugar activities.

Alex spent time working on our final presentation.  I'd rather not discuss too much detail about it on here, as it would give away too many surprises about our presentation.  But let's just say that our "plan" is proving to be a little more difficult than expected.  We may have to change a few things, but we'll see.  We do still have plenty of time to get our presentation together, I believe.

I spent most of my time on Sunday creating the poster for our group.  I was unaware that the poster was due at Noon on Monday, so I wanted to make sure that it was ready to go.  I printed out the poster today, and I'm very happy with it!  I think the poster session on Thursday will be interesting.  Hopefully we will catch interest of some people at the poster session.  I plan on brining my laptop to the session, just in case someone wishes to see the program itself (rather than just the poster).

Another Breakthrough for Nutri

During class on Tuesday, we've made great progress.  We've finally gotten Nutri to display in full screen!  No more windows displaying within sugar.  Also, we've gone ahead and updated our icon to match Sugar's standards.  Sugar requires that we use a black and white icon for our activity.  When an activity is loading in sugar, it changes colors to signify that something is happening.  We've updated the icon so that this takes place while the activity is loading.

What's left:

1.  When you open the activity, there's no way to quit it.  We still need to get the toolbar working, so that the user can end the activity and go back to the rest of the Sugar OS.

2.  Wiki.  We still need to create a wiki page for our activity.  The wiki will have our progress of the activity, bugs, new features, etc.  Of course, it will also describe the purpose of the activity, and how to use it.

3.  Presentation.  We need to start working on our final presentation for this class.  I believe Megan started putting together a powerpoint, but we need to work out more details.

We plan on meeting this weekend to work out all of these.  Overall, I'm very happy with our activity (which I think is now pretty much officially named Nutri).

More Progress

During class on Thursday, we had a major breakthrough with Nutri.  From my last blog post, I mentioned that we found an activity called Log that will help us figure out what the problem is when we try to run our code.  I wasn't that familiar with the code in the first place (Alex is most familiar with it), so I had her take a look at the errors being produced on Thursday.  Within minutes (after tinkering with our code), we finally got Nutri to open up successfully in the Sugar OS!

This was a big breakthrough for us, but there's still plenty to fix.  First of all, the activity didn't function properly when we tried changing things (like setting how many servings the user had, etc.).  Turns out that we lost a few necessary functions to make this work properly (I think Megan had removed them when we were trying to "Sugarize" our activity).  So once we fixed this (and made a few other minor incompatibility changes), Nutri functioned properly.  

The only other coding that is absolutely necessary for us to fix is the window.  Currently, the window within the Sugar OS displays as a separate window inside of Sugar.  This is obviously not ideal.  We want our program to look and feel just like any other activity in Sugar, so we need to figure out how to make our content fit properly in the Sugar window, and not a window of its own.  The Hello World tutorial we followed (along with other examples of sugar activities) use something called a GTK VBox as their outermost container of the Sugar App.  We tried changing ours to this, but it ends up breaking other parts of our code... so we're not sure if this is the solution.

We met again this weekend (on Sunday) to try and fix this.  Unfortunately, we didn't have much success.  Alex wasn't able to attend the meeting, so hopefully once we get with her on our further progress, we should be able to overcome this issue.  Once this is resolved (I'm assuming this will be by tomorrow -- at the latest by Thursday), we'll still be on track.  The only thing we'll need to do before we present will be to create our Wiki page, and send in our activity to (hopefully) be approved.  

Nutri Progress

Since Tuesday, we've made some great progress.  During class on Tuesday, we began following this guide that Alex pointed out -- a PyGTK to Sugar tutorial.  This guide showed us an example set of code where someone converted a GTK-based python program into a "Sugarized" version that can be run within Sugar.  This activity helped us figure out what was necessary to convert a GTK-based application into a "Sugarized" activity.  Unfortunately, the guide didn't actually have the source code available for us to compare side by side with ours.  They did, however, provide the .xo file (the Sugar Activity file that can be run within Sugar).  After doing a little research, I realized that .xo files are simply just .zip files but renamed.  So we can easily view the source code of the .xo file simply by saying:

unzip filename.xo

This gave me the contents of the activity for me to better compare our activity to the tutorial's activity.  After comparing and making more changes to our code, I went ahead and tried running our activity in Sugar.  Still no luck.

Making minor changes to the code without getting any feedback from Sugar was going to make it almost impossible for us to figure out what's going wrong, so I searched for a new way to go about "Sugarizing" our activity.  In search of a way to debug our program (within Sugar), I found a very useful activity called Log.  This guide pointed me in the direction of Log.  Log is a Sugar Activity that will display a log file about any activity that is run within Sugar.  So once our activity crashes, we can pull up the Log activity to see why the activity failed to run properly.

While we still haven't gotten the activity to actually run within Sugar yet, this is excellent progress.  Now we actually have a way to figure out why our activity is crashing.  It shouldn't be much longer now before our activity is working properly within Sugar.

Activity Progress

More activity progress:

I'm still trying to get the Activity to work within the Sugar Environment.  On Thursday, I continued following this guide to help me "Sugarize" our pygtk application into a Sugar Activity.  I've gotten the activity to show up in the Activity list (within the OS), but when I launch it, it doesn't display properly.

Megan was using this guide to try and "Sugarize" our activity.  This guide shows major differences in code when converting from a PyGTK application to a "Sugarized" version.  We printed out the code to compare the major differences:

PyGTK Version:

class ReadEtexts():

def main(self, file_path):

Sugar Version:

from sugar.activity import activity
from sugar.graphics import style

class ReadEtextsActivity(activity.Activity):

I think I've made all the differences necessary to "Sugarize" Nutri (the current name given to our Activity).  However, it still doesn't seem to give me any positive result.  Unfortunately, it doesn't seem like Sugar has any form of Debug mode (or even a way for me to know what error is occurring when the Activity launches), it simply says that the Activity failed to start.  I'll keep looking into why this isn't working.  Luckily, I think we're a bit a head of the game anyways, so we have time to work this out.  If I don't get passed this issue by tomorrow, I'll pop my head into the IRC chat and see if anyone can offer some help.

Activity Progress

Since our last class meeting we've made some great progress on the activity.  For starters, in class we were able to finally get the drop-down menu to populate with the data that the user selects. It doesn't sound like it would be that difficult, but it was giving us some trouble.  Since we're now able to get the information from the drop-down box, the next step is to implement the algorithm.

Megan and Austin have been working on the algorithm that we will use to calculate the user's heath status.  Alex took the algorithm and implemented it into our code.  Before, we were unable to really test the algorithm, since we couldn't get any data from the drop-down's.  Now, the algorithm works properly and we're able to retrieve and update the user's Health meter.

My role (at least in this stage of our development) is to figure out the process of converting application over to the Sugar OS.  Currently, our app runs via python directly (in its own separate window).  My goal for this weekend is to take Alex's code and merge it into a working Sugar App.

Other things to do:

1.  Create documentation.  The Sugar community's documentation basically consists of wiki pages.  We need to create a wiki page for our activity's progress.  Some things we can put on here are current bugs, features, feature suggestions, release notes, etc.  Documentation will be useful for anyone else who might be interested in contributing and making changes in the future.

2.  Expand on functionality.  Since our first presentation for the class, we were told to try and get a prototype out as quick as possible, and doing so has caused us to cut back more and more on our functionality (just to get something out ASAP).  So, now that we have something that works (for the most part), we can spend the rest of the semester working on new features and enhancements.  This works out really well for us, because our "goal" for the end of the semester can change.  If we have time to implement more new features, then of course we will.  If time doesn't allow us to create numerous features throughout the remainder of the semester, then we at least will have a completed and polished activity.

Overall, I'm very pleased with our current progress of the Activity.

POSSCON Review

POSSCON turned out to be quite an exciting event (especially Thursday).  It didn't go exactly how I had planned, but all-in-all things went well.  I didn't meet everyone that I planned on meeting, but I met others in place of those who I planned on meeting.

Thursday was the most exciting day of the conference.  There were plenty of people there (both in the audience, and on stage).  On Thursday I met three people:

1.  Walter Bender -  Walter's presentation was probably my favorite of all.  He showed off the Sugar OS on his own OLPC.  In fact, he did his entire presentation using his Sugar Laptop (using Turtle Art -- which acted as his presentation method instead of using the traditional Powerpoint slides).  He really tried to convince the audience that using Sugar really helps kids "learn how to learn" in a number of different ways.  He showed off a few of Sugar's best activities to the audience, and how they all help the students learn.
After his presentation, I (and most of the Sugar-based teams in our class) introduced ourselves to Walter. I told him about our ideas for the nutrition-based activity, and immediately he offered some suggestions for us.  He told us about how the OLPC laptops have a webcam built in, and that we should consider trying to use object recognition to gather our data.  I think this may be a little over our heads (especially for the next month...), but it is an excellent idea nonetheless.  This could definitely be something that we can mention on our Wiki page that we make soon.

2.  David Duggins - David gave an interesting presentation about how to use open source software in place of proprietary software.  This ranged from operating systems, to word processors, and of course to programming languages.  The talk was short, but still very informative.
After the presentation, I talked to him about PHP development.  My question for him was about the advantages of using PHP over Microsoft's .NET development.  I explained how .NET development offers a very object-oriented feel for designing web pages, while PHP makes you dynamically write your code using (what I think are kind of ugly) "echo" statements.  I've never found an easier way to write PHP applications, and I was asking him for suggestions.  Unfortunately, he didn't really seem to provide me with a good answer... just to look around for possible libraries that may offer this level of abstraction that I'm looking for.

After hearing this, I've started messing around with the possibility of creating my own open-source PHP library.  I might try and tackle this over the summer and put it up on the web.  Who knows though.

3.  Neil Underwood - Neil was around POSSCON throughout the entire event showing off his 3D printer.  The 3D printer was a pretty hot item throughout the event, and for a good reason too.  The 3D printer was pretty neat -- they showed off the ability to create almost anything you wanted using this device.  The printer itself was even self-replicating -- you could create your own printers using this printer!  I talked to Neil, and asked him if it were possible to copy an object, and then print it out.  He showed me his 3D scanner that he had in his bag, which would let you do just that.  A good example of this would be if my cellphone cover was starting to fall apart:  I could literally scan it with this 3D scanner, then create myself as many new cellphone covers as I'd like!  The idea sounds pretty neat, and it's completely open source.  I took one of their business cards.  Maybe I'll look into creating my own 3D printer this summer if I'm bored.

Anyways, POSSCON turned out to be a great event and I'm glad I was able to go both days.

Plans for POSSCON & Our Activity's Progress

Tomorrow will be my first of two days at POSSCON, and I'm very excited for the event.  Just a quick overview again of who I plan on meeting over Thursday/Friday:

Walter Bender - Founder of SugarLabs
Speaking @ 1:15 - 2:00 PM on Thursday
Topic: Using & Modifying the Sugar Platform



John Metric - SugarCRM
Speaking @ 9:45 AM - 11:45 AM on Friday
Topic:  SugarCRM:  Your Next Business Application






Dave Stokes: MySQL Manager
Not speaking?  Oh well.  I'll still try and meet him at some point.







Sebastian Dziallas:  Sugar on a Stick
Another Sugar developer!  I'll be sure to meet him and find out something
interesting.







My planned Schedule:

Thursday:
10:00 AM - 10:45 AM: Web Hosting - Knocking out Application Layer & Open Source Threat
11:00 AM - 11:45 AM: Open Source Gaming (or maybe the Hidden Costs of Closed Source Software)
1:15 PM - 2:00 PM: Learning to Learn: Using & Modifying the Sugar Platform
2:15 PM - 3:00 PM: The Secrets of Building Real Time Big Data Systems
3:15 PM - 4:00 PM: Starting and Running a Business on-the-cheap with Open Source
4:10 PM - 4:50 PM: Open Source Communications with Asterisk

Friday:
9:45 AM - 11:45 AM: SugarCRM: Your Next Business Application
1:15 PM - 3:15 PM: The History of Linux

Overall, I'm very excited to see how the next two days are going to turn out.



Activity Progress:
During class on Tuesday, we made some significant changes to our project.  We've decided to go with an even simpler design.  We got rid of the Combo-boxes (traditionally known as a drop-down box).   We've instead just replaced them with text so that the user can simply put how many servings of each food category they've had for the day.  We will most likely expand on this as time goes by, but I think for now it's best to start out simple and just get something accomplished.  Once we've gotten a handle on the project as a whole, we will (hopefully) have enough time to go ahead and improve on things.  We still need to implement an algorithm that gets the user's Health meter for the day, but Megan came up with a general idea for the algorithm.  That will be the next task we will strive for this weekend after POSSCON.

POSSCON/Activity Progress

POSSCON is approaching fast, and I'm excited for the event.  One thing I had not noticed last week is that Walter Bender (the founder of Sugar Labs) will be attending POSSCON!  This is pretty exciting, considering that we are currently working on a new Activity for Sugar.  I must've overlooked this because he is (unfortunately) not speaking on Thursday or Friday.  He will be speaking on Wednesday.  However, at some point our team (Flux Capacitors) will have to meet him and share our ideas (and hopefully progress) for the activity.

Our progress:

Since Tuesday, we've made quite a change in our Game Plan (after hearing what Dr. Bowring and the class had to say about our timeline).  We were told to get started on a prototype for our activity ASAP, to help us make sure that it is feasible and so that we don't left behind.  Of course, we are going to try to make our goals as simple as we can, and build on the activity as we go (for as much as time allows us to).  So far, we've made great progress.  Alex has been able to put together a Python application that uses PyGTK (for our interface -- and is widely supported within the Sugar OS).  We've been able to set up drop-down boxes that contain lists of food groups.  At first, we were having trouble getting the food groups to associate with a second drop down box (i.e. The user selects "Meats", then continues to select "Chicken" as the type of meat).  However we've been able to get the secondary drop-down boxes to populate with data once the first box has been selected.

Some things for us to do soon:

1.  Organize the data.  We need to make sure that all of our data (Food groups, and sub-categories) is sorted, and easily accessible.

2.  Create the algorithm.  This is probably the most difficult task.  We need to construct an algorithm that grabs data from the user's selected drop-down boxes (and the number of servings).

Preparing for POSSCON

POSSCON is approaching fast, and I've taken some time to figure out what I'd like to do for the days that I spend there.  I replied to the email sent to us to confirm that I'm attending, and I will be attending for both Thursday and Friday.

I realize now that when I emailed them in reply, I said that I would be going for the Education track.  However after looking over the website in detail, I think I'm going to stick to mostly the technical sessions. Currently, I've been wrapped up in web development, so hearing about FireHost's Web Hosting, PHP applications, and MySQL server development are the most appealing to me.

SQL is one of my favorite programming languages, and I've gained some experience using MSSQL, but  very little with MySQL.  I'll probably want to speak with Dave Stokes (the Community Manager for MySQL).  I'm sure he'll have some interesting things to say.

Thursday:

Most of my web development has been server side programming (using Microsoft's .NET framework along with MSSQL), but I've had little experience with PHP in the database class offered here at CofC.  I would like to know more about PHP (mostly because I want to tackle a web project of my own this summer -- and I would love to take the free route).  I'm sure John Metric (Software Engineer for SugarCRM) will have some great things to say during his session at 1:15 on Thursday.  I'll be sure to come up with some questions for him after hearing what he has to say.

Although I don't consider myself much of a gamer anymore, I'm still somewhat interested in gaming.  I've never had any experience with any game programming (except for a few small games back during Programming I here at CofC).  I'll be sure to attend the open source gaming talk at 10:45 on Thursday.  I'm sure I'll come up with some questions for John Diamond (the speaker of this presentation).


Friday:
Depending on how Thursday goes (and what I tend to like the most), I'll make my decision on which workshops to attend.  At the moment, I would probably go with John Metric's "Your Next Business Application" at 9:45.  The history of Linux also sounds quite interesting, so I'll probably be attending John Hall's "History of Linux" workshop at 1:15.

The Game Plan

Before Spring Break, we met up during class on Thursday to discuss our Game Plan for the rest of the semester.  After our previous meet on Monday, we had a general idea for the rest of the semester, but we finalized things more on Thursday.  Here's our Game Plan for the rest of the semester for our Nutrition Sugar Activity (at the moment it still does not have a name):

Week 1:
-Create Class Diagrams
-Create Database design (Tables and Procedures)
-GUI Mockup

Week 2:
-Data Entry for Database (We plan to use SQL Lite for our Activity)
-Algorithm structure (For determining the user's Healthiness)

Week 3:
-Implementing our design into Python and SQL Lite
-Integrating SQL Lite into the Activity

Week 4:
-Check our Progress (and continue programming if necessary)
-Testing (and make changes that are necessary)

Week 5:
-Create Wiki Page for our Activity
-Publish the Activity to SugarLabs

Week 6:
-Pull together any loose ends & suggestions from the Sugar Community

Our group has decided to divide up the work (at least as a starting point) in a manner that that lets the most experienced person in a given language or technology will begin working in that field.  I have the most experience with SQL Databases out of the group, so I'm going to start with SQL lite.  We'll all be making individual contributions to each part (and of course offer suggestions to each other), but this at least gives us somewhere to start working on our project and a way for us to continue working on something on our own time when we're not meeting together.

All in all, I think we have a great road map for the rest of the semester.  I'm concerned with our ability to stay on track (as with most computer science projects) during the next six weeks.

The importance of documentation

After reading TOS Chapter 8, I've found a few things most interesting and important:

1.  Importance of code commenting.  Commenting doesn't just help me understand what's happening when I go back through the code months later.  More importantly, it helps others who may look at this code have an idea where to start when looking over the code.  Employers are probably most interested in programmers that practice detailed commenting, because it helps the company progress further faster in the long run.

2.  Importance of technical writing.  In my experience thus far, I've already created up to 80 page long documents that go into detail about designing software, and I have an idea of how important it is to keep these documents living.  When going into the process of actually implementing the software, the documentation is a great place for me to look back onto, just to make sure I'm following the "plan".  With thorough documentation, you can think deeply about issues that may arise during the implementation process.  This helps you plan again against any possible issues, and helps make the implementation process less painful and straight-forward.

3.  Keeping documents updated.  It's very important to keep a document "living", following the "waterfall" method.  If you've completed a document and have gone onto implementation, there will most likely be changes in implementation that weren't accounted for at the documentation stage.  It is important to document these changes, so that the next person who comes along can still follow the documentation.  Otherwise, comparing documentation and the actual implementation may appear confusing to a newcomer.

4.  Collaborating on documentation.  Having more than one person work on the same document can prove very useful.  Almost like "pair programming", when two people get together and discuss a design for a software project, it helps create a broader view of how the software will work.  Having a detailed discussion about a project will help the designers think more deeply about what needs to happen -- which helps prevent issues in the long run.

For our project, we will absolutely be creating some detailed documentation for our design.  I know that in the long run, it will prove to be very useful and help us save time.

What's next?

During class on Thursday, we made our decision on what we would like to accomplish for the rest of the semester.  We've decided to create a nutrition-based activity for Sugar.  This would require us to learn how to create an activity on our own, and we weren't positive whether or not this would be a feasible task for this semester.  For the weekend, we decided that it would be a good idea for each of us to attempt to try creating a Hello World activity in Sugar.

On Friday night, I was able to successfully compile and run a Hello World activity on my version of Sugar.  I followed this guide to do so, and sent the information onto the other team members to try out.  After a little work, it seems that everyone was able to do this (not perfectly, but I'd say close enough).  Since we were able to complete this within a couple hours, I think it's safe to say that our idea is a reachable one.

The idea (at the moment) is to create an activity where the user will enter in what they've eaten for the day, and the system will return a rating on how well the user has balanced their nutrition for the day.  This would be a great tool for younger kids, and would help them learn how to keep a well-balanced diet.  We've talked a little about what each of our responsibilities are going to be as well.  Responsibilities include the following:

1.  Database design - We think we're going to use SQLite
2.  GUI
3.  Algorithm design - for the rating system

We're very early in developing ideas for the project at the moment, so some things will most likely change as we look more into detail about designing the activity.  I have a bit of experiences, so I will most likely start out by spending time designing data tables for our activity.

In general, I think this is a great idea for our project.  While it could turn out to be a heavy workload for us, the greatest thing about creating our own work is that we can set the bar where we need to.  Of course, we will try to create reasonable goals throughout the semester.  However if things work out well (and we've met our goals), we could very easily expand them (by adding new features, etc.).  I'm excited about the project and I'm ready to get to work.

Experience using diff

Using the diff tutorial in TOS Chapter 7 turned out to be really useful.  At first, we were stuck on how to go about formally submitting our bug fix for the string trimming problem.  It turns out that Sugar uses these exact same practices that TOS teaches to create a patch.


7.2:
Some things I've noticed about diff:

1.  It provides a very detailed report on the difference between the two provided (creation date, line differences, what's being added and removed, etc.).
2.  The -u command displays all lines that remain unchanged after using diff.  Not using -u only displays the lines that are different between the two files.

7.8:
This was a fairly simple exercise.  Here's the steps I took to complete it:
1.  Created a file called foo.txt and a file bar.txt.
2.  I left the file 'foo' blank, and wrote "This is a test." in the file bar.txt
3.  I used this command: diff -u bar.txt foo.txt > foo.patch

The contents of the file bar.txt are placed into foo.txt.

7.9:
Following 7.9 gave me a good idea how to go about applying what I've done for our own project in Sugar.    I changed the lines of code that it asked (to create a reverse ordering of the output), and created a patch for it.

To do this, i followed these instructions:
1.  Created a copy of the file using this:  cp echo.c echo.c.reverse
2.  Opened Gedit  and modified the code of echo.c as it has instructed.
3.  Created a patch for the file using this:  diff -u src/echo.c.reverse src/echo.c > echo-reverse.output.patch

To test the changes, I used "./configure" to build the project, and "make" to created all of the out files that can be run.  After running echo, it prints "reversed this is".


Some notes about our team:

We've come to a decision about our ideas for the rest of the semester, and we're all in agreement on creating a nutrition activity.  Our goal for the weekend is for each of us to create a hello world activity, and make sure that we're able to do this successfully.  If we're able to complete this by the weekend, I think that will be fair judgement on how difficult it would be for us to complete activity by the end of the semester.

Submitting Our Bug

We've had a pretty successful experience (so far) with submitting our fix for the name spacing issue.  After class on Thursday, Megan managed to get the code to work successfully.  Our code does the following two things:

1.  When the user initially creates an account, the changes we've made trim any white space to the left and right of the user's name.  Before our changes, the white space would have remained on the left and right side of the user's entry when creating the name.

2.  When the user edits their name, the changes we've made will trim any white space to the left and right of the user's name, only if the user doesn't have any newline characters in the name.  Before our changes, the white space would have remained on the left and right side of the user's entry when editing the name.

The comments made about our initial talk with the developers led us to include change #2.  The developers noted that some users like to have multi-line names (that usually make some sort of picture).  Trimming the space off the left and right sides would've made the names not display how those users would prefer them to.  Since we check for the newline character, this is still an option for those users.

Today I submitted our fix to the development team, and telling them the solution we came up with in an email.  I described the approach we took, and Walter replied saying that this was a reasonable approach to take.

For the future:

We've talked a little bit about what our plan is for the remainder of the semester.  Megan mentioned the idea of creating our own simple activity.  I think this would be a great idea, as long as it's a reasonable task.  Creating an entire activity from scratch sounds hard at first, but there are plenty of guides and tutorials available for us to get started.

Alumni Symposium

On Tuesday, the Alumni Symposium turned out to be a great event for Computer Science majors, or even just students that were interested in Computer Science.  There were about 10 different speakers that talked for about three minutes about their personal job experience after graduating at CofC.

Some of the speakers talked about what they look for in people that apply at their companies.  The general consensus was that employers look for people that don't just have strong experience in specific programming languages (or strong skills, etc.) in Computer Science, but mostly what we spend time doing outside of the classroom.  They really like to hear about personal projects (related to programming or software development) that we've worked on in our own time.  This seems to be important to employers, because it shows that we are really interested in the field of Computer Science.

After the speakers finished, the room was opened into a question and answer session that any students had for the alumni.  There were some interesting questions going around.  Some people asked about what types of things that their employers look for when hiring.  Another hot topic was cloud computing, and its importance in the future of the Computer Science.  Everyone seemed to have their own opinions about cloud computing, and how big of a toll it will take on the future.  

With the addition of free food (which is my personal favorite), the Alumni Symposium turned out to be a great event, and I'll be sure to attend next year (as a Senior).

Bug Progress

During our presentation on Thursday, the consensus for us was to find out how to properly create multiple-line names.  Not long after our presentation (during the time left over from class), we made excellent progress.  Megan figured out how to create multiple-line names.  This helped us better understand what Walter was saying about how our fix could potentially mess up names of users that have multiple lines.  Once we tested this out, it all made sense.  Now the tricky part was to figure out a work-around.  With the time remaining in class, we all gathered together to look at what our possibilities were.  We're left with two options:

1.  Implement our current fix only on initial creation of the user's name, that way they can still edit their names later.
2.  Implement a more sophisticated fix that will allow the user to have multiple-lined names, both on creation of the user account, and when editing the account.

Of course we would like to opt for the second solution, that way no user's of sugar will ever be able to tell the difference in what we've done.  We spent some time on Thursday trying to figure out a possible algorithm to address this fix, but we knew we would need to spend more time on it this weekend.  On Friday, I set up a folder for our group on Subversion, and I uploaded the current changes I made for our bug.

Yesterday (Sunday), our team met up for about two hours to try and make some more progress on this bug.  To start, I made sure that everyone was able to access subversion successfully, and get the code that we had when we left off, and it seems that everyone was able to get the code successfully.  We continued working on the bug, and made some progress.  After we had left on Thursday, we were unable to open the About Me section (the place where you enter the name), because it seems that the code did not compile successfully.  We were able to properly compile the code, but then seemed to be stuck in some sort of infinite loop.  After reviewing our code multiple times, I was able to successfully update the user name, but it seems that it wasn't properly recognizing the multi-line characters.  Since this isn't due just yet, we decided to call it a night and pick this up again later this week when we're able to meet.

Presenting our Bug Report

While we thought we had a handle on how to fix our bug, we've gone through some recent considerations on how to properly address it. The first thing that has come to light is that certain Sugar users like to make their names in a way that takes up multiple lines.  We still need to figure out a way to properly address this.

Here are the options that we explored and plan to present:

1.  To cut of the extra space on each side of the string on both initial launch, and when editing the user's name.
2.  To cut of the extra space on each side of the string only when the user enters in their name for the first time.

I plan to present the bug to class directly from my machine, so that we can view and discuss the changes that take affect after applying our current "fix" for the bug.

For the future:  We still need to figure out how to properly address the multi-line names.  First, we need to figure out how they are created.  Once we understand the process of creating the name, we will be able to provide a better solution to the problem.

Bugs, bugs, and more bugs.

6.4:
Here is the bug that we've been working on.  When the user enters in a profile name for their account during setup, the field currently does not trim any spaces entered on the left or right side.  This occurs during the initial setup of setting up the profile name, or if the user decides to edit it later.

This bug has been sitting around for about 3 months, and I have a decent idea why.  We sent an email to the development team asking where to get started on this bug, and they pointed us in the right direction.  Walter Bender wrote back within minutes pointing us to where we can fix this.  Minutes after, others began replying, and arguing whether or not this was actually a bug, or if it was more of a feature.  They argued that the user should be able to enter in spaces in their name if they prefer to.  The main reason this bug is because the community is unsure how to handle it.

6.5:
I've created an account on the Sugar Lab's bug tracker.

6.6: Bug report
This bug can be reproduced in two ways:
A.  Initial creation of the user account, following these steps.
1.  User launches the Sugar OS for the first time.
2.  The user is prompted to enter in a name.
3.  The user enters in text in the Name field, and puts spaces before or after the desired name.
4.  The user clicks the check sign, and continues to set up the Sugar OS for the first time.
5.  The user clicks on their main Sugar icon, then clicks on their name.
6.  The user clicks on My Settings, then About Me.
7.  The user clicks within the name text field, and finds space to the left and right of the desired name.

B.  Editing the user account name.
1.  The user opens the Sugar OS.
2.  The user clicks on their main Sugar icon, then clicks on their name.
3.  The user clicks on My Settings, then About Me.
4.  The user clicks within the name text field, and enters space to the left and right of their name.
5.  The user clicks the check mark to save the changes.
6.  The user clicks About Me again, then clicks within the Name field and finds space to the left and right of their name.

6.7:
Bug Triage:
SugarLab's bug tracker is organized into three priorities:  Low, Minor, Normal,  High, Major, and Immediate.
Bug #2564:  This bug has to do with the simplicity of backing up and restoring files in the Sugar OS.  While this bug is important, it may not be the most pressing one to complete, since most users aren't going to be backing up files often, especially kids.  I would say that this should be prioritized as Normal.
Bug #2352:  This bug is about documentation that is missing from Patchwork.  While it is important to keep documentation updated for programmers to use as a guide, it's definitely not a critical problem that would effect the user's experience.  I'd say this is a Low priority bug.
Bug #2227:  This bug contains a detailed log of an error thrown when trying to launch a Sugar OS component called XoPhoto.  I would argue that this is either a High, or Major priority bug, because the component is completely unusable by certain users.  While the component may not be used by a high number of users, it is still important because the users that are affected cannot use the software at all.
Bug #1741:  This bug is a complaint about the absence of a detailed report of a connection error when integrating a Jabber server in the Sugar OS.  The error given does not provide the user with any useful information about what the problem might be.  I'd say this is a Normal, maybe Low priority bug.
Bug #1936:  This bug talks about the Sugar OS datastore, which is a component that can be very large depending on the amount activities and other components installed in the Sugar OS.  When the datastore has a high amount of data, it returns an error, which is provided in the bug report.  This could potentially be a big problem if a high number of users have a lot of data stored in the Sugar OS.  This would be a High or Major priority bug.


Side note:  I finally remembered to sign up for the Alumni Symposium next week.

Freeciv experience

The experience I had with Freeciv in TOS chapter 5 was very helpful.  Too bad I didn't go through it earlier this weekend however, because it is essentially the same sort of thing I've been dealing with in SugarLabs.  The guide through the Freeciv installation teaches us how complex these projects can be.  There are a ton of sources, packages, files, extensions, etc. that need to be in place in order for things to build properly.  Taking the time to make sure that you've properly added all of the required dependencies for a project is very important, and can save you a lot of time in the long run.

Some of the processes I went through in Freeciv were a bit confusing at first.  Freeciv keeps referencing "yum" to download packages, but in Ubuntu we use "apt-get".  There were also some subtle differences in package names that Freeciv referred us to, but searching for the packages in the Ubuntu Software Center allowed me to figure out which ones I needed.  Also, there were quite a few packages it asked to install that my version of Ubuntu seemed to already have in place.  

The next phase of Freeciv was "make".  Make seems to be the building of the entire Freeciv project.  Running make required us to install a c++ compiler.  The one that Freeciv referenced didn't work, but it seems that Ubuntu also already has one built in called "libstdc++6".  Generally, most of the error messages that I would get weren't always the same as the ones documented by Freeciv, but finding the solution wasn't too hard.

Once this was completed, I was expecting to feel some sort of accomplishment for gathering all of the packages/files successfully, but it seems there wasn't any sort of "Congratulations" for getting here.  Seems that the main goal of this assignment was simply to have an idea of how to successfully build a project that has a handful of dependencies.

Some Sugar-related stuff:

I've gotten all of the packages that were throwing errors previously in my jhbuild for sugar to work.  The activities seem to work properly now, and I'm able to build the project.

The next step will be getting ourselves set up with subversion this weekend, along with trying to figure out how to get started with the bug we're going to address.

sudo apt-get install more_sleep

After our class on Thursday I spent probably 4 hours or so trying to get Ubuntu on my computer, and I was finally successful!  So far I really like it.  It looks and feels a lot like OSX, but the fact that it's an Open Source Developed project makes it more exciting in a way.  It's really cool to know that Open Source projects can really be successful, and I hope that our team this semester can really make a dent in an Activity for Sugar Labs.


So, we all met for about 4 hours on Saturday to see where we were all at as far as getting our development environment up and running.  I started out just playing with the Sugar OS interface.  You can install Sugar in Ubuntu by going to the Ubuntu Software Center, and typing in Sugar.  After playing around with the OS to get a feel for it, I went ahead and started looking into setting up our development environment in Ubuntu.


First, I downloaded Eclipse.  Eclipse has a Python plugin called Pydev, which will allow us to edit Python files.  There's also a plugin for git called Egit, and another plugin for Subversion called Subclipse.  I've installed all three of these to my version of Eclipse.


The next step was to get the code, and build it.  This was probably the most difficult process yet.  I think it's a bit more complicated process for us since we aren't just dealing with an application, but actually an Operating System.  Building an OS and running just sounds a bit more difficult to me.  SugarLabs has a few different guides about actually getting, building, and running the code.  However, none of them seemed to be that clear.  I looked at a few different guides on setting it up while we met on Saturday:
http://en.flossmanuals.net/ActivitiesGuideSugar/SetUpDevEnvironment
http://wiki.sugarlabs.org/go/Activity_Team/Getting_Involved


After a few hours of trying to figure out how to set up the development environment, we split up and went home for the day.
Linux seems to make the user work directly in Unix quite a bit more than I'm used to, but I'm starting to like it.  You know you've spent a lot of time doing something when you start dreaming about it.  After I went to bed last night, I was literally dreaming about typing Unix commands.  After we left Saturday, I spent some time trying to figure out how to set this up some more.  I found a guide on SugarLabs' website talking about jhbuild.  Jhbuild let me download the source code directly (after installing the required dependencies).  Once downloaded, I can start editing the python files.  If I were ready to start testing out any changes I make, all I have to do is open Terminal and type the following commands:
./sugar-jhbuild build   (This builds the project.)
./sugar-jhbuild run sugar-emulator (This runs the virtual Sugar OS and lets me test out any changes I make).

Just to be sure that this is in fact the best way for me to begin developing, I went onto the IRC chat for SugarLabs, and asked a couple of questions. They were very quick to respond, and very helpful. They told me to try using Sweets, which is similar to jhbuild. After downloading Sweets, it seems to be a very similar process. I can build/run the Sugar OS using the following commands: 
sweets -ff make sweet (Builds the project)  
sweets sugar:emulator (Launches the emulator)  
I'm not entirely sure which is the better route to go, but I suppose time will tell. We've started looking at bugs. The bug we're most interested in has to do with setting up the user's profile name. If the user puts a space before or after their name, the space should be cut off, but currently it leaves the space in front of their name. This should be an easy bug for us to start with.


One more thing: I also was able to install the Subversion server using apache in Ubuntu following this very simple guide.
sudo apt-get install subversion libapache2-svn - installs subversion.
svnadmin create /svntest - created a subversion test directory at my root folder.
sudo htpasswd -c /etc/subversion/passwd jordan - creates my login/password.
once this was created, I can log in using the following command: svn co http://10.0.0.1/svn

It prompts me for my username/password combo, and lets me in. Assuming that I could give out my IP address to an external user, I think I'd be able to log into the server.

Day Five

Well, it's late.  In the last two days I've spent about 9 hours at least trying to get Ubuntu installed on my Mac.  First I find out that my Mac's disc drive is dead, so I've been trying to find a workaround.  I really do not want to run Ubuntu in a virtual machine, I'd much prefer to partition my hard drive so that I can boot directly into Ubuntu.  Turns out that my disk drive can't be partitioned just yet, Disk Utility keeps telling me that "some files can't be moved", so I'm either going to have to reformat (and reinstall OSX first), or if I'm lucky I'll be able to get away with just repairing the disk.

The reason I've been dedicating so much time to it is because I know I'm going to need it once we get going with SugarLabs, and I really want to set up a development environment that I'm comfortable with.  Linux is the absolute best options when it comes to developing for the Sugar OS.  I really would like to follow this guide in setting up my environment, but first I need to get Ubuntu running.  Also, I'm kind of excited about it because I've never really used Linux before, and I want to know what it's like.

As far as Subversion goes, I just spent some time setting it up on the OSX side of my Mac.  Things went well.  I started out using a tutorial here that uses Terminal to connect to Subversion, but I wanted an easier way.  I found a program called Versions that lets me use a GUI for subversion.  The setup was simple: pointed it to the correct URL, my login, and password.  Once in, I'm able to create folders and upload files as I please.  I can check in and out files without any issues so far.  I've used other version control systems (mostly Microsoft's TFS at work), so I would say I'm somewhat familiar with checking code in/out.  The app that I'm running has some sort of trial I think, but I'm not too worried about it because I will eventually set up Subversion again once I'm in Linux.

TOS Chapter 4 goes through the basics of dealing with Subversion at the command line.  I went ahead and tried connecting to subversion with Terminal, and I was able to check out the code pretty easily:
svn checkout https://cirdles.cs.cofc.edu/repos/462playground/

Once I start using Subversion in Linux, I may need to become more familiar with the commands rather than using a GUI, although I would prefer to try and make things as easy as possible.  If I can, I would like to use a GUI-based Subversion client, like this.

Well, it's 2 AM, and I'm in the process of putting the OSX install disc onto a flash drive so that I can reformat my hard drive.  It might be a long night.

Day Four

Today we had a class discussion about a few different topics.  To start, each team went around and discussed our current progress about making a connection with the open source community.  We told the class about our experience with SugarLabs.  We were able connect to SugarLabs' IRC channel, and join their development mailing list.  The development mailing list sends out roughly 20 emails a day which is somewhat overwhelming, but at least we know that the community is active.  Their IRC is embedded directly into their website, and they have a ton of different  channels (including a "newbie" channel -- which is where we started out).  They also have a complete history of every conversation that's existed throughout their IRC chat rooms, which is very convenient.  

The next topic was about our reflections on the Cathedral and the Bazaar.  Everyone went around and made comments about interesting topics/ideas that were discussed in the readings.

Our team just finished meeting up tonight about our full report that we need to give on Tuesday.  Meeting at Taco Boy was an excellent idea, much more exciting than the usual places (JC Long or the library).  Good food makes the meeting much more relaxing and enjoyable, and feel less like work.  Our report will be posted on the group's wiki by class time on Tuesday.  Alex created a document collecting our ideas on the full report, while we all contributed things to add to the report.  

For the majority of the time at the meeting, I focused on trying to get a head start on how our development environment will work, and what exactly we would like to do to contribute to the project.  SugarLabs is a Linux-based operating system that runs on a USB stick that they like to call "Sugar on a Stick".  Anyone can download it and begin using it whenever, however I'm still hung up on the best way to set up an efficient development environment.  For example, if I were to change a few lines of code, I want to arrange the easiest way for me to test these changes on the Sugar OS.  Since it runs on a USB stick, it sounds like it may be a more complicated process to get to since we can't develop directly in this OS.  This would require developing in OSX (or Windows, Linux, etc.), and then possibly compiling/restarting the machine in the new environment to test out the changes... not exactly my ideal environment.  

I found their source code and downloaded it onto my machine.  Turns out they use a version control system called GIT.  Since we'll be using Subversion for our class, looks like we'll have to keep track of both.  We'll only really need to worry about GIT to get the latest version of the projects, and to publish any changes we make (probably towards the end of the semester).  For the most part, we'll probably be dealing with Subversion.

Details about how we'll develop aside, the best way to get started will be to work on a bug.  It'll help us get a feel for the code and to the development process.  Further down the road, the team would like to focus on creating/modifying what SugarLabs calls "Activities" - the learning-based games that the users play within the Sugar OS.

Day Three

On the third day, we got to deliver to the class our top three candidates for our Open Source project choice this semester.  I started off by speaking about our third choice: Open Office for Kids.  We decided not to go with Open Office for Kids, because it seemed that it would be difficult to communicate with the community (considering that most of the developers were French).  SugarLabs was our number one choice by far (and it turns our we're not the only group), and I'm very excited about jumping into the development process.

For the next half of class, we spent some time looking into more detail about SugarLabs.  We managed to join the IRC chat just to get a feel for how that works.  We also found out about a weekly meeting for SugarLabs on Thursday nights, so tomorrow night we will all be joining the IRC chat to see what's going on.  We also found the mailing list on their website for developers, so we went ahead and signed up for that as well.

The Cathedral and the Bazaar was an interesting read.  Throughout the reading, Raymond lists small tips for Open Source software, coming his experiences as a programmer over the last 25-30 years.  Here's some of the tips that I found most useful:


"Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging."  -  With Open Source software, if you keep the user invested in your product, they will most likely be more interested in helping continue the software development process (fixing bugs, new features, etc.).

"Release early. Release often. And listen to your customers." -  Listening to the customer is very important, because most of the time the customer has a lot to say.  I can say from personal experience (working at Hawkes Learning Systems), that the customer always likes to give their two cents about our product (whether it be new features to release, or things they don't like -- any feedback is good).

"To solve an interesting problem, start by finding a problem that is interesting to you." - This is very true, and is also why we decided to go with SugarLabs for our project.  Doing something that you want to do makes the process feel less like a job and more like an enjoyable experience to learn from.

Overall, Raymond has a lot of great things to say about Open Source Software in the Cathedral and the Bazaar.

Day Two

On the second day of class, we were thrown right into the Open Source projects and were told to pick the top 3.  There were so many options available (ranging from developing a music player like iTunes, to working on parts of an open source operating system for kids).  While the list of options seemed endless, our team quickly narrowed it down to the following three options:

1.  SugarLabs
2.  One Laptop per Child
3.  Open Office for Kids

The main reason we narrowed it down to these three was simple:  easy to get involved, and there's a lot of work to be done.  As a homework assignment, we decided to divide up the work by each of us looking a little deeper into one of the top 3 open source projects, and to report our findings on Tuesday to make our final decision.  My responsibility was Open Office for Kids, and here's what I found:

Pro's:
- Available for development on all operating systems.
- Seems to be an active project -- recent contributions from other developers.

Con's:
- C++ -- not exactly my favorite, but I suppose I could use the experience.
- Not much documentation to get started easily.
- Most contributors speak French (which will make it difficult to get in contact on IRC... considering that none of us are fluent).

Overall, I don't think this will be the top choice.  The impression that I got on Thursday was that our team was pretty much set on SugarLabs.

SugarLabs is the best option because it makes it really easy for us to start out.  They have plenty of great documentation to follow (guides to follow, etc.) to help us get moving quickly.  The community seems very active, and is open to new developers.  What stands out the most is that SugarLabs is basically an environment for us to hopefully develop (start and finish) our own learning-based game for kids, using the existing operating system and API's that the community has to offer.  In a way, it would be like developing an app for the iPhone or Android, but maybe a little less complex.

The idea mentioned in chapter two of TOS made an interesting point when it talked about "Contributor Mountain".  Most people aren't driven to Open Source Software just by the sheer act of wanting to participate, but more because they see changes that can be made that can help improve the software.  When someone spots a bug, an active user will (at the very least) inform someone about it.  A more proactive user may even decide to take action themselves in fixing the problem, and Open Source Software allows us to have that capability -- to always actively make changes that will positively affect the software's development.

First Day

What was supposed to be the second day of school ended up being the first (by some miracle -- I really needed that extra day).  Software Engineering Practicum was the perfect start to the new semester.  It turns out that I'm the new kid in this class, since I had Boetje for CSCI 362 the year before.  Seems that everyone else is already very familiar with working with each other, but the CS department is small enough that I already know most of the people here.

I'm very satisfied with the group that I'm in.  Alex and I already know each other from work, and I met Megan last semester in a previous class.  While Austin is the newest person to me, I know we've had classes together before.

We managed to decide on roles for our group pretty quickly.  Alex is the group leader, Megan is the spokesperson, Austin is the writer, and I'm the chief programmer/liaison.  My role consists of two major things:

1) Observing all the code checked in by each team member, making sure that each contributor's work compiles, and that the code maintains a consistent and readable format.

2) When communicating with the Open Source community, I'll be the one in charge of maintaing our code, communicating with other developers (in IRC chat, etc.), and making sure any work that we publish to the Open Source project is the best it can be.

While the roles worked out well for everyone, we did take quite a bit longer to come up with a name for our group. After roughly 10 minutes of googling a name, we finally decided on The Flux Capacitors. Can't go wrong with a Back to the Future reference I suppose.

All-in-all, day one of this class turned out great, and I'm excited to see where this semester is going to take the team and myself.

As for the readings, I agree with what is said in the first chapter.  Creating your own "Senior Project" for programming isn't really the best practice for the field of Computer Science.  Being thrown into a real programming project is not only more meaningful (since there will most likely be users that will actually use the program), but it provides students a way to understand the entire process of development -- by throwing students into a much larger task, much like one that would be seen from a future employer.

Conformation for POSSCON: Transaction ID: RKCHWVVPPL, Order Number: 10000247