PS: Ubuntu Desktop Recorder

Hey everybody, as I was working on my portion of the ATeam's presentation I came across this fun tool and thought I would share it with you.  Ubuntu has several programs that will allow you to record a video of your desktop, or simply a portion of your desktop.  The one I used will even allow you to narrate.  Our team found this useful for preparing a demonstration of our program to show you, our classmates, while helping us be efficient with our time.  No awkward shifting between workspaces and having the display get mixed up for us!  If you'd like to check this out, you have two options:  

1. Find the software and figure it out for yourself
2. Visit the howtogeek and follow their instructions

This really is a fun little program to play with. I just wish I'd found it before finals week of my last semester! It would have been great for presentations along the way! Best of luck everyone!

Why, Ubuntu? Why?

For the second semester in a row, during the last week of classes my Ubuntu system has encountered boot problems.  I don't know if it has a self-destruct program that is triggered by the user's need level or what, but it's kind of annoying.  On the bright side (trying to make lemonade from my lemons, here...) I did get to learn about using Netbeans subversion tools and about the Windows command terminal.

Since I had created the patches for our code on the Ubuntu system, but had not yet uploaded them to our subversion repository, I had to do it all over again.  However, I did not want to take the time to re-configure my Ubuntu drive, so I decided that it was time to tackle this problem from Windows!  Another team member, Shannon Fox, had started using Netbeans on his machine to access our repository, so I decided to do the same.  That seemed to work pretty well, but I couldn't figure out Netbeans's diff function.  It was time to brave the command terminal.

So I told my computer to run cmd and a terminal opened.  I'd done that before, so no huge victory there, but I wasn't sure if the subversion commands were the same.  I decided to type 'svn help' and see what happened.  Just like in Ubuntu, I got a listing of the different commands I could use and thankfully they were the same.  I proceeded to recreate my patches and add them to our repository using the windows terminal and voila - lemonade! :)

I think my only real disappointment in this venture was that I was unable to run the LemonadeStand game from windows.  It would give me an error because it could not find pygame, which was a dependency that I think comes installed (or easily installed) in Ubuntu.  I'm sure I can find the solution for Windows, but I haven't yet.  I would love it if I could because then I could share this game with my sister, a 4th grade teacher, and her class might be able to have fun with it!  I suppose that can be my first personal project of the post-graduation summer!

Also, as irritating as it was to recreate the patches, I'm very thankful for the realization that I am quite comfortable opening the command-line terminal and working from there.  It may seem silly, but I was always so impressed with my dad when he would use the terminal to do something or fix it.  It's almost like an affirmation that I am indeed equipped with the resources to succeed as a computer scientist.  I certainly don't know everything, but I do know my tools to find out more and so it is time to say once again, "Hello, World!"

Number Five is NOT alive!

Anybody ever see Short Circuit?  I used to love that movie and whenever I think the phrase "number five" and think of that little guy saying "Number Five is alive!"  Only in this case I'm referring to a bug that has been successfully squashed! No more Bug #5!

Bug #5 was more of a confusion to the user than anything else.  According to the wiki, each day of the game consisted of:

1. Going to the store in the morning
2. Selling lemonade
3. Closing shop for the night and entering the day's activities and profits into the log

The program did all these things, but it updated the log's day after going to the store.  So, for example, at the beginning of the game, it would begin the log with Day 1.  Then the user would visit the store, buy supplies, and all of a sudden the log says it is Day 2 and records the user's purchases and profits under the Day 2 heading.  Confusing? I think so, and so did the rest of the team.

We found the place in the code where it processes the day's logic and the night logic.  At first I thought that moving the day incrementer to the night logic instead of the day logic would fix the problem, but it didn't.  After a bit of confusion we realized that the problem was that the daily log displayed yesterday's activities under the current day - and that did not make sense.  So we played a little bit more and figured out that the problem was not in the logic at all, but in the displaying of information.  We turned away from the Main file and investigated the GUI file and sure enough we found the code where it added new values to the log.  At this point we simply changed the day value to day - 1, so that the log displays yesterday's entry.  We also modified it so that on the first day the log shows a welcome message instead of "Day 0."

I was really excited about this success because this was the first bug that I beat my teammates to the solution!  For the last several bugs by the time my to-do list reaches LemonadeStand, I've received emails from my team saying that they found, fixed, and committed the bug.  I've been so thankful for a team that I can rely and trust to share the work, so please don't think I'm complaining about it.  I've simply felt like I wasn't keeping up with my contributions.  Anyway, this was a big victory for me because I was able to find and commit the solution.

And so we had success - except for one little thing.  Now the game play seemed confusing because there was nowhere to indicate what the current day was.  As we looked at the activity wiki we realized that their picture showed the current day with the day's weather, but that feature seemed to have been removed since the picture was posted.  We decided that it was worthwhile to add it back in and so appended a message to that block.

And now we are done!  We have completed the bugs! Of course, we also just realized that we've only been committing our code t our subversion server and not to the project...oops!  Our solution is to create several patch files based on our bugs and submit each of them.  Guess that is our work for this week!

4 Down, 1 To Go!

NOTE: This blog is to catch you up on last week's events.

Just a quick summary on what happened with Lemonade Stand Bug #4.  This bug was the check to calculate the user's profit and entering that value using the fewest coins possible.  What we discovered after we thought we had fixed it, was that it actually does not require the absolute fewest coins possible.  We then thought that this was a bug in the original creator's logic, but upon further investigation and testing, we realized that the game was actually working to simulate real life.

Here's how it works: Each amount of money can be created using the absolute fewest amount of coins.  For example, say you've earned $3.05.  Using the fewest denominations, that is 3 dollars and 1 nickel.  What the game then allows is for one unit of the smallest denomination to be exchanged for even smaller denominations.  So that nickel can be correctly entered as 5 pennies.  Using a different amount, if you earned $4.20, that should be 4 dollars and 2 dimes.  However, one of those dimes can be exchanged for 2 nickels.  Then, one of those nickels can be exchanged for 5 pennies.  We decided that it was actually very good that the simulated real life this way, so we left it as is.  The only problem was the confusion based on the instructions, so our decision was to edit the LemonadeStand wiki page to include this information.

Then we moved on to Bug #5...we're getting close!

Tricky Tricky Bug

So, it turns out that Bug#4 is a bit trickier than we thought.  Bug #4 is a problem with how the Lemonade Stand game requires the user to enter their profit.  The game wants the user to enter the amount using the fewest coins possible and originally reported an incorrect amount if this condition was not met.  Our team thought this was confusing so we wanted to create multiple error messages - one if an incorrect amount was entered and another if the correct amount was entered, but not using the fewest coins possible.  Shannon and Francis were able to find the section of code where this needed to be fixed and even fixed it.  This was no easy task, but with some perseverance it was done and it was done by our self-imposed deadline.  However, that is where things got tricky...

Following the best practices taught here at CofC, Shannon began thoroughly testing his solution and discovered that while the code he wrote was good, the original code confirming that the correct amount was entered with the fewest coins possible was wrong!  It only requires the three largest denominations (dollar, quarter, dime) to be 'correct.'  Beyond that, the user may enter any valid combination of nickels and pennies to complete the amount.

As I've been considering that problem, it occurs to me that maybe this is not an error, but was actually done intentionally.  This more closely models real life as a cashier may run out of certain denominations of dollars and coins.  It makes some sense that the game would require the larger denominations to be correct in order to prevent the user from simply entering the amount in pennies or dimes or quarters.  I hope this afternoon in class to discuss this with the team and if we decide to enforce absolute fewest coins possible, then hopefully we can figure out the necessary change.

An Encouraging Honor

Greetings from a new member of UPE! This week I was initiated into the Upsilon Pi Epsilon Honor Society for the Computing and Information Sciences.  It was such an honor to be accepted into this organization.  I first heard about UPE last year and was interested in joining, but had not yet completed enough units in my computer science curriculum at College of Charleston to be considered.  When my teachers told me this semester that I qualified I was so excited!

My husband was so proud of me, too. He has been so supportive through these last two years while I completed this program.  He is also a member of Tau Beta Pi, the Engineering Honor Society, so he recognizes what an accomplishment it is.

The ceremony on Tuesday was kind of fun.  It was very brief, simple, and full of tradition.  I was very honored to be congratulated and welcomed by so many of my professors, as well.  It is so encouraging to know that they believe in my skills as a computer scientist, especially as I begin to feel so overwhelmed with the end of the semester.  I want so badly to finish strong, but sometimes I am so tired - I know I can't push myself as hard as I have in the past and my brain definitely is not working as smoothly as it did even a few weeks ago.  I guess I'll just keep doing the best I can and take what comes. 

Connectivity...Yay Apple!

While the A-Team has continued to make progress on our Lemonade Stand project, there are many other places you an read about what we've done (Start by checking out the team wiki!). Since I had a slightly unusual technology experience this weekend, I'd like to share that with you instead.

On Sunday afternoon my husband came downtown with me to do homework.  He brought his Macbook Pro and planned on connecting to the wireless service.  Unfortunately, I had forgotten that you have to go through a lovely formal network setup process here at CofC - you cannot simply log in to the wireless.  Of course, the directions to set up the network are online, so they are easily accessible, if you are connected to the internet.  The poor guy struggled to connect for quite a while because he didn't want to interrupt my meeting.  We finally got him connected (although one set of the online instructions for Macs was incorrect) and he was able to continue doing his work.

The real fun started when we got home - he could still see our home network, but was unable to connect! We quickly deduced that it was not a network problem, since my computer connected, my phone connected, and our Wii connected just fine.  As the new resident computer expert in our home (yeah right!) I took on the challenge of fixing it.  I started looking at all the different settings and discovered that the AirPort Express hosting our network had a different ID than the AirPort detected as containing our network! Then I noticed the little red dot next to airport symbol and realized that it should be green!  Conclusion: somehow the computer was not recognizing our AirPort - it was still recognizing the school's AirPort.

So how was I supposed to make it find our AirPort? I began searching for help and found a lot of discussions that seemed promising at first, but turned out to be very different issues.  Also, there was a lot of support for AirPort Extreme issues, a different Apple product, but not much for the AirPort Express.  I finally found a diagnostic tool in the network settings and as that tool began to run, the problem fixed itself.

Since I still don't know how it was fixed, I can only claim a partial victory, but it is my first victory on a Mac, so I'm quite pleased! I love that I at least know what to look for in order to solve technology problems!

Programming Addiction

Sorry, no clever titles today.  I haven't personally done much this last week in relation to our project.  Instead, I've been catching up on some other work and then two days realizing and pondering the hazardous addiction of programming.

I believe I've mentioned that my dad is a computer programmer.  Growing up I remember that sometimes he would stay up really late working on a project.  When we would interrupt him to say goodnight he was always surprised that it was time for us to be going to bed.  As I grew up I thought maybe that was one of those "one-track mind" things, but as I have continually been reminded during my studies here at the College of Charleston, it is simply the addiction of programming.

I believe this addiction is something any programmer can relate to.  Maybe you don't always need to be programming, but once you start a project it is amazingly difficult to walk away.  I had two programming assignments that needed to be done this weekend, both of which were experiences of growing and stretching my abilities.  I actually enjoyed working on them for the most part.  Trying to understand why a few things weren't working in a C-language program was not so fun, but the rest of it was.  However, the hazards of the ability to get lost in a program and have no concept of time are realized the next day, or in my case, the next several days.

When I began my projects I fully intended to get up and take a short walk every hour, or at least every 90 minutes.  I knew this was important for me to do because of a back injury I had a few years ago.  For the most part my back is better, but it tends to flare up again if I sit at a computer for too long.  Add pregnancy back pain on top of that and movement becomes absolutely crucial to my survival.  However, about 30 minutes into my assignments I lost all awareness of the passage of time (and hunger, which is really something considering that I'm 5 months pregnant!).  The only thing that would bring me back to reality was my husband's interruptions, but even those couldn't pull me away from my computer for long.

On to the hazards: immobility and pain.  I unfortunately had to miss the last few days of class because of back pain and exhaustion.  I'm getting back on track with a renewed sense of urgency to NOT sit for more than an hour and a half and making sure I take time to stretch my back, but recovery is a lot slower without the medication I was able to take before.  And on that note...It is time for a walk.

For a humorous look at pain, check out Brian Regan...

POSSCON Presents Possibilities

Let me begin by saying that POSSCON was fantastic! This was the first professional conference that I have attended, though I've been behind the scenes for several.  As I had stated in my first post about POSSCON, I was pretty nervous about the day, figuring that not many of my classmates would be interested in the same sessions that I was and about introducing myself to complete strangers.  It was definitely outside of my comfort zone, but it turned out to be rather fun!

The first breakout session I attended was led by Allen Tucker, of Bowdoin College. He was one of the people who started the HFOSS Project to get college students involved with open source software.  To be honest, I chose to attend this session simply because it was in the Education track, but as I listened to his presentation I was so glad that I had!  He spoke about a few different projects that were of particular interest to me because of my experience with non-profit organizations.  The first is the Sahana project, which is a disaster management software.  He didn't go into much detail about that, but sparked my interest and I hope to investigate it further this summer after graduation.  The second was the Ronald McDonald House (RMH) Homebase project, a web-based volunteer scheduler!  This project was actually one of Dr. Tucker's projects, so he had more to say about it.  This is really something that I'd like to get into because I had started working on the basics of a similar MySQL database for a class project.  I know that there is a great need for this kind of software among non-profits because the available software is either inadequate or beyond their budget.  I spoke with Dr. Tucker about Homebase briefly after his session and he was eager to work with me, which was very encouraging!

After that boost of confidence I was far more ready to speak with other presenters.  I got to speak with Walter Bender and ask some of my questions about OLPC.  I even spoke with some of the 3D Printing guys during one of the breaks.  And the last session I attended was the Data Governance Imperative with Steve Sarsfield.  Although this session was barely attended (only about three people, including myself), this was by far my favorite!  As acting DBA at my last job, I dealt with poorly collected and organized data on a daily basis, struggling to clean up thousands of entries and motivate change among my colleagues.  Steve Sarsfield works at talend*, one of the conference's sponsors.  They have created an open source solution, several really, to take care of data cleanup, integration, analysis, etc.  I actually plan to get his book and read it, and I may also be interested in working with someone at my old job and Mr. Sarsfield to set them up with this program.  I at least really want to look into it. 

At the end of the day, I guess it's a good thing that I'm not looking for work.  Sticking with these open source projects would provide a way for me stay involved with the CS community, keep developing my skills, and work from anywhere with as much or as little time as I have to be involved - giving my the exact level of flexibility I need as I become a mother and move across the country!  I'm so excited about these possibilities and now just need to remember to contact the people I met and get through the semester.  Here we go!

How To Make Lemonade

This week the A-Team was working on some documentation issues, both within the game for the user and on the activity's wiki.  For the most part this was a good first step: simple, but rewarding.

We divided up the tasks between the team pretty well, and having our code up on subversion is so helpful!  One of the first steps was done by Carlynn Carter, who created a new welcome screen for us that included the name of the activity and it looks great!  I know she had some frustrations in that project, but you can read her blog to find out more about it. 

As we worked we found that a solution to one of our problems was mysteriously implemented.  Previously, there were no instructions about how to play the game, what keys to press, or what things to watch out for - things you would normally find in a 'help' section.  Since we had struggled with this we decided it was important to add.  As we were familiarizing ourselves with the code and updating from svn we saw that all of a sudden help messages appeared on every screen in the game!  We initially thought that an absent team member had made giant leaps of success, but he denies any knowledge of it!  Where this change came from is still under investigation.  While this did give us a huge step forward, it was still not implemented in the best way, in our opinion, so we continued studying the source code and Francis Ani created a way to make these messages appear or disappear by pressing the 'h' key.  Success again!

I took responsibility for updating the activity's wiki page.  This may seem very simple, but since I am not overly familiar with formatting within a wiki, it was a bit challenging.  There are still some other improvements I would like to make to the wiki, but as my week begins to overwhelm me and it is only Monday, I'm choosing to prioritize my work. 

I am still very pleased with our progress this week and feel that I have a better understanding of the time commitment that needs to be made each week to keep up with our schedule.  It will definitely be challenging, but I still believe we can do it, especially if our team communication continues as well as it has so far!

POSSCON 2011

I'm starting to get excited about POSSCON.  This will be my first computer science related professional conference, so I'm also a little bit nervous.  I'm also somewhat thankful for the requirement to meet and talk with some of the presenters.  I know that I'm too timid to do this if I wasn't being nudged, but I also know that it will make the experience more rewarding and beneficial.  I've also been realizing again just how important it is to learn these basic networking skills.

One of the things that is encouraging to me is that Walter Bender, one of the co-founders of One Laptop Per Child and involved with SugarLabs, will be there.  In case you're new to my blog, I am participating in the SugarLabs HFOSS project by contributing to a new activity called Lemonade Stand.  In addition to talking with Mr. Bender about SugarLabs and the activities, I'm also interested in OLPC, specifically its implementation in Africa and in general in rural areas of developing countries.  I've spent some time in Tanzania and Swaziland and to be completely honest, I don't understand how a laptop is going to fix things in either of those education systems.  Technology requires power, which is not always available in these schools.  The project has obviously been successful in certain locations, so I'm interested in how some of these basic obstacles have been overcome.

Another speaker I'm interested in speaking with is Deb Bryant.  She works in the Open Source Lab at Oregon State University and will be making a presentation on Open Source in Government.  This is something that is of particular interest to me because my husband is in the Navy and I have watched him suffer through poorly developed and maintained tools which he is required to use.  I didn't realize that the government was willing to work with open source, especially considering how Windows-centric their current software is and how Linux-centric open source work seems to be.  I'm hoping to talk with her about what is currently being done and where to find these types of projects.  Since I may not be working in my first year after graduation, this might be an interesting place to stay involved and continue developing my skills.

As I continued my research about the speakers I found someone else who will be presenting about a certain interest of mine: Steve Sarsfield.  He will be talking about data governance - a subject I have a hard time explaining, but which I believe is invaluable to the success of any enterprise.  My last job was essentially as a DBA, which gave me a lot of experience dealing with poor data collection and maintenance.  When I joined the organization there was a lot of data clean-up necessary and there were not good practices in place for collecting good data.  This problem may not be exactly what he is addressing, but it seems related to me.  His bio actually refers to him as a blogger, so I am hoping to find his blog and do some reading before POSSCON so that I can be better prepared, both in what to expect and in my questions.

"I love it when a plan comes together..."

Ok, maybe I'm claiming Hannibal Smith's line a little bit early, but the plan itself has come together...it's just not implemented successfully yet!  As the A-Team, we have decided what contributions we are going to make to the Lemonade Stand activity and when we think they should be completed (see our timeline here).  I was quite pleased with how easily this came together.  As we all played with the activity we kept finding more little improvements we could make or bugs we could fix, so we quickly came up with a list of tasks, actually more than we could do in the next six weeks!  We discussed our priorities and timetable and voila - a schedule was made!  I think we owe a lot of this simplicity to the youth of the activity.

We've also made contact with the activity owner, Nathaniel about our plans.  We had contacted him a few weeks ago and had a quick response from him.  He seems very helpful and eager to see this activity grow and improve.  In our plans we had several questions about what we interpreted as bugs or weaknesses of the program, so our latest contact with him is asking for a lot of clarification on these issues.  I expect a response in the next day or two, since our questions were a bit extensive.  I don't expect that this delay will slow down our progress at all since our first steps are more related to documentation, which he has already welcomed! 

As a team we still have to decide how we will divide the labor.  I think we will all collaborate on the work, but maybe rotate responsibility for submissions.  That will allow each of us to have the experience and to get credit in the Sugar community.

I am so happy to say that I am still optimistic about the work this far into the semester.  More than that, I am excited! I really like the Lemonade Stand game and think it has a lot of potential to be a great tool!  I am so glad to be a part of it!

Subversion and the Lemonade Stand

So, this last week as I pondered the things I needed to do to catch up in this class, I realized that the A-Team had never uploaded our FOSS project source code to the subversion repository!  I think we as a team got caught up in doing the work and just forgot about working with subversion, but now that we know what specific activity we will be working with I decided it was time to commit it to the 462Playground.

It was actually kind of fun to go back and play with subversion again.  I was reminded of how much I like subversion and how I wanted to set up a server on an external hard drive for backing up my computer.  But back to this project...

Like I said, it was fun, but it was also kind of tricky!  I had to go back and look up my login info, the right commands and all that stuff.  I also new that I needed to remove any .git files from my current directory, but when I ran the ls -la command to find any hidden files, there weren't any!  That surprised me, but I went with it. 

As I added a folder for our team, filled it with the appropriate files, and committed the changes I had a great sense of accomplishment, even though it only took a few minutes.  Now I just need to remind my team to remove what they have already downloaded and to instead use our new "source code" from subversion!  I think this will also help us to keep up with all the changes that we make as we begin working on the code - making me even more optimistic about our success in this endeavor!

When Life Gives You Lemons...

As the A-Team searched for ways to contribute to the Sugar Labs FOSS project in the last few weeks we stumbled across a delightful activity called Lemonade Stand.  This is a math/microfinance related game where the user runs a lemonade stand.  It challenges students to perform quick and accurate money math, work with ratios, manage their budgets to maximize profit, and even provides some "real world" situations that may be harmful or beneficial to the success of the lemonade stand. 

We had some trouble running the program at first because the check-out and build instructions embedded a folder an extra level.  Correcting these build instructions is actually our first idea for what we can contribute to this project! 

We also ran into some problems trying to figure out how to play the game!  We couldn't find any instructions on the wiki or in the game for what the goal was or how to take any action.  Since the GUI does not include a mouse we were able to deduce that the game is played via keystrokes, but which keys?  Through about 20-30 minutes of trial and error ("does this key do anything? or this key combination?") we were able to figure out basic game play and it was actually really fun!  Adding some instructions to both the wiki and the GUI is a second idea for contributions. 

I was personally intrigued by the random "real world" events.  A few examples that we ran across include lemon trucks crashing near the lemonade stand (gives you free lemons), a sugar salesman stopping by to give you some free samples, and ants stealing some of your supplies!  In 30 minutes of play time, I had ants steal my supplies multiple times and expressed to my teammates that I needed to relocate!  To my surprise, this is actually one of the requested features that has not yet been implemented.  I'm interested in playing with it, but I think my teammates also have a lot of other ways we can contribute which we are sure to be able to complete in our time frame.

Overall, I am really excited about Lemonade Stand.  I think it has great potential as a Sugar activity and is actually something I'd love to share with my sister, who teaches fourth grade!  I still have a lot of exploring to do into the inner workings of the game, but that should be fun, too!

TOS Ch.8: Documentation

Before beginning I must apologize for my neglect.  Something, I'm not sure which event in life, but something broke my habit of regular blogging.  So consider this the beginning of my catch-up blogs to update the world (at least those of you who are interested) in my progress through this course.

This chapter in our text book is about documentation: the purposes, best practices, and standards.  Amusingly, I find this subject to be a theme in my coursework this semester.  I am also taking an operating systems class in which my professor values good commenting in code so highly that it is actually a part of our grade!  Until taking this class I thought I was a relatively good commenter, but I am now finding that I have a lot of growing to do in that area.

In addition to my operating systems class, another class related to software design has been almost entirely about the other type of documentation - the living, cohesive, professional document.  I have also found this to be extremely challenging as it requires reviewing and editing the document every time it grows to make sure that it is consistent with itself!  As the document grows, so does the complexity and time required to accomplish this task - no wonder programmers hate documenting!  Even as I acknowledge its importance and firmly believe that it must be done, I dread going back to reviewing the document every week.

I also found this chapter on documentation to be beneficial because of my team's FOSS project for the semester.  We have decided to invest our time in a new activity called Lemonade Stand.  This activity is very new and therefore has a lot of room for improvement.  One of the first things we noticed is a total lack of documentation for the user!  We spent our first half-hour or so simply trying to figure out how to play the game and find the magic keys, since there is no mouse in its GUI!  The activity owner is also interested in having better documentation for the activity in its code base and wiki, so we are eager to apply what we are learning to this project.

It may seem surprising that while I spent the first bit of this blog complaining about how hard it is to create good documentation, and to maintain good documentation, yet that is what my team and I are excited about contributing to our FOSS project.  Perhaps that gives you an idea of how much we recognize and value the need for it.  We have all been part of FOSS projects in the past which have had terrible documentation and it was so frustrating to try to use or contribute to the software.  We don't think that anyone should have to go through that frustration, and so we are willing to put in the effort.

As we begin this process I expect that I will be rereading this chapter in even more detail because it is so important to get this right!  I'm glad to have the TOS book as a quick resource and guide.

Patching Things Up: TOS Ch 7

Since we have been dealing with bugs, we are now looking at the proper way to create and submit patches.  My group, The A-Team, had already looked through this chapter together in preparation for correcting our Sugar - Pippy bug, but we had not completed the text's exercises as directed yet.  Here is a summary of my experience with those exercises...

Exercise 7.2.2
This exercise is about exploring the diff command.  This command allows you to compare two files and find any changes or differences.  The basic format is diff <file1> <file2>.  There is an option with the diff command, -u, that changes the output.  Without this option the command only outputs what has been removed and what has been replaced.  When you include this option it includes a lot more information about the file and what lines were changed.  It actually includes the text of the file and shows the lines that have been removed and the lines that have been added in their context.  I can see how this extra information could be very helpful!  What if the line that was added to a file is simple x += 1;?  There is no context to help the programmer decide if this was a good change!

Exercise 7.8
The  wording in this exercise is actually rather confusing.  By the time I did this exercise I thought I was pretty comfortable with the concept of patches and using the diff command.  Actually, I would still hold to that assessment, but I didn't understand what I was supposed to create and compare.  After looking at the blogs of my classmates, I made a decision about what to do and here are my results.

The exercise says first to create a file, foo, with the contents bar.  So I started with creating a file, bar.txt, and placing a simple sentence in that file.  Then I used a unix command to copy the bar file into a file called foo.txt.  Finally, I created a patch file using the diff command in which I compared the empty file, /dev/null, with my foo file.  The contents of the patch show the contents of the file being added.  I'm still not sure that this is what the instructions intended, but it is what I did.

Exercise 7.9
This exercise asks us to create a patch on the echo command so that it echoes the words entered in reverse order.  It was pretty easy to follow the directions provided until I reached the end of them, where the instruction was to enter the code $ ./configure$ make, which simply gave me error messages because ./configure$ does not exist.  This turned out to be one of those silly mistakes that just requires a bit of space and some critical thought.  Apparently, when I started working on this assignment I was more tired than I thought because I simply didn't recognize that the '$' implied a new prompt and the make command is a familiar and separate command.  Like I said, one of those silly mistakes.  Fortunately for me I did not spend too much time fussing with it.  I chose to walk away and about an hour later had the unexpected epiphany!

Overall, this was an interesting a rather simple task.  It was actually kind of fun to play with patches.  This whole week or two has been very encouraging as we go forward with out projects!

Patching the Bug

As mentioned earlier in my blog, we were able to take our bug from creating the ticket to submitting the patch.  Due to the simplicity of our bug this whole process was relatively easy!

Submitting the ticket was as simple as filling out the form on the bug-tracker website.  As we began reading TOS Chapter 7 regarding patches our next set of questions were answered.  We knew how to fix the problem - writing the new code was very simple, but what were we supposed to submit to fix it?  The answer was a patch, creating by diff-ing the original file with the corrected file.  So we ran that simple command and named our file according to the best-practices guidelines found in our text book.

Now that we had created the patch we had to figure out Sugar's procedure for submitting them.  After some research on the IRC and websites we found two methods.  The first is to simply attach the patch to the bug ticket.  The second was to submit the patch to the git server using the git send-email command.  Since we weren't sure which was best, we did both!  And then there was the waiting for a response.

I was extremely pleased to check my email this morning and find a chain of sugar emails related to our patch.  More specifically, accepting it! 

I also had a little problem with my Ubuntu system, requiring me to check-out the current version of sugar again and was pleasantly surprised to find our fix already in place!  Success!

Thoughts for the Future

This week I attended College of Charleston's Computer Science Alumni Symposium.  At this annual event, several CS Alumni are invited to return to the school and share their experiences and lessons learned with current students.  I had also attended this event last year and found it to be a valuable time, so I was glad for the opportunity to participate again. 

It was interesting to me how many of them recommended things that we are actually doing in this class.  The advice to get involved with FOSS projects was repeated several times, along with the advice to find something that you are passionate about and get involved.  We also were encouraged to start getting familiar with refactoring code because in your job you will most likely be working with code written by someone else, and it may not be the highest quality work.  I was pleased to hear that our experiences in this class are exactly what people out in the corporate world are looking for in future employees.

Unfortunately I also found myself personally discouraged.  I am eager to use this degree upon graduation, but at this time my life has so many unknowns after May.  I know that women with families can pursue successful careers in this field because I know many who have, including the women in the CofC Computer Science Department.  However, I seem to be in a holding pattern.  All I know is that I will not be living in Charleston after the summer and I will be learning a whole lot about motherhood - which will always trump my career.  I'm hopeful of finding some sort of part-time work that allows me to telecommute or perhaps start my own small consulting business, but I think for the first year, or even first few years, I will simply be working for myself, fostering that creativity that future employers will be looking for. 

Here comes the real test - when school is over and life's changes clamor for my attention, will I take the initiative and make the time to exercise what I've learned?  I know my education has given me the resources to continue learning on my own.  I hope I will. 

Here's to the future!

Who ya gonna call? BUG-BUSTERS!

Ok, maybe that was a little bit corny, but hey, that is me.  At this point in our HFOSS projects we are getting involved with the bug tracker and solutions.  We have been tasked to identify a bug and fix it.  This assignment has had its ups and downs...let me explain.

At first we were all very optimistic because the bug tracker is very organized.  At least it impressed us more than what we saw last semester in our projects.  There is also a simple section of bugs that are supposed to be easy to fix - a good place for beginners.  However, as we started reading those tickets we got confused.  Many of the remaining open tickets either already had patches waiting for approval or the developers disagreed on the proper method of handling the bug reports or we still didn't understand what they were talking about.  This was turning out a bit more complicated than it first appeared.

However, we continued searching and using the software and discovered an error in a Pippy program.  Pippy is an activity for the Sugar OS that provides a simple Python programming environment.  Since this is educational it comes with several sample programs built into it.  One of these programs, Factorial, is supposed to do a factorial calculation on a number entered by the user.  What it actually does is give the user an error message saying that a variable is never defined.  The problem is that the coder refers to the user's number as 'number' in some places and as 'n' in other places - a common newbie or 'quick-and-dirty' coding mistake.

Since there was no bug ticket about this we thought maybe this error was left intentionally, but after communicating with the Activity Team on the IRC, they encouraged us to pursue a solution.  Ah, sweet relief!  I'm actually pleased that we get to see this bug all the way through discovery and solution.  It's almost like we get a little bit of positive bonus learning experience!  I know this project has and will continue to provide lots of 'extra' learning opportunities, but most of them tend to be unexpected complications, while this seems (for now) to be simply an opportunity to participate in an extra step.  I'm pleased to say that I'm still quite optimistic about the project!

Bugs - The Not-So-Sweet Side of Sugar

After getting Ubuntu back up and running I began rebuilding Sugar.  This time I ran into more trouble than I did previously.  Checking out the source code and running the dependency check went just as smoothly, albeit a little more slowly, than the last time.  However, when I built it before I was able to run a simple command, sudo apt-get install <list_of_packages>, and include the list of missing dependencies.  When this command ran it easily installed all of the dependencies.  This time it didn't work.  I had to run the command for each dependency and find the right order to do so.  I also had to download an additional package, or set of packages, related to abiword which apparently does not come with my current version of Ubuntu.  While this build took much longer than the first and involved a far more in-depth investigation, it was still successful.

I finally began investigating bugs and was quite impressed with the organization of the bug tracker.  It was very easy to navigate and find different types of bugs, different ages of bugs, different priorities, etc.  As I looked for the oldest open bug I found one, ticket #122 dates back to late 2008 and appears to have a current status of 'assigned.'  This bug seems to be a documentation request about a missing link on the planet.sugarlabs.org website.  This website is the collection of Sugar-related blogs.  I expect that this hasn't been fixed, or at least it's status has been ignored, simply because it is so low on the priority list.  Another bug that is actually related to how Sugar runs is ticket #245, which has been reopened.  This is about two years old, but has been modified in the last few months and is a request for a spinning cursor, or some way to signal that the machine is thinking, as it loads a language tool.  From the discussion, it seems that this was deemed unimportant because the load time for that tool is so small.  It also seems that they group has made a decision and has whatever they want to fix it, but is waiting for the next release to commit.

Our next step was to join the bug tracker, which was very simple.  Just click the button that says 'Register,' fill out the form, and voila!  It was interesting to see how the appearance of the page changed and how much more information was available!  I like the different views when you are logged in!

The third step was to find a bug and try to reproduce it.  I was pretty excited about this challenge and found a new bug, ticket #2591, that I was really excited to try.  This bug states that when a user in the Favorites view clicks and drags an activity icon over a different activity icon and drops it there, then the first activity will open when the second activity is selected!  Fascinating, right?  Well, I thought so until I tried to run the Sugar Emulator.  While it worked just fine when I rebuilt it, it no longer does.  I had to re-check it out, rebuild it, and then I found a new problem.  Ubuntu's keyring manager is not accepting my password today and therefore interfering with my Sugar Emulator.  So, instead of replicating this bug, I will be researching how to fix the keyring manager, or starting over from scratch. Yay!


As I begin that search and fix, I do not have time to triage some bugs.  I hope to come back to that soon, but if I can't run Sugar, I can't proceed with anything else for the project, so that is taking priority...

Finding my way back...

After completing the Freeciv assignment for last class, I ran into some unexpected troubles.  Some package that I was required to install managed to corrupt my Windows registry.  When I returned to my computer later and rebooted I was unable to access either my Ubuntu system or my Windows user profile.  Since mine was the only visible account with administrative privileges, I was rather stuck.  When I booted into Safe Mode I was able to access my account and perform a back-up.  After a few hours of emotional turmoil and backing up my computer, I was drained and had to walk away.  Actually, I didn't walk away. I lied down right where I was and took a nap.

About an hour and a half later my dad, my personal Windows guru, called me to help me work out my problem.  My dad has been a computer scientist working for Chevron for over 25 years and has a lot of experience with troubleshooting.  He also seems to know Windows inside and out!  He led me through a secret back door of Safe Mode to grant administrative privileges to another user profile.  Here is the secret:

1. In Safe Mode run a command terminal as administrator.
2. Enter the command $ net localgroup administrators <UserProfile> /add
3. At this point you can reboot in normal mode and access the user profile to which you just granted admin privileges.  

From there you can create a new account with admin privileges and move your files from your old account to your new account.  Your settings will not be transferred, but that is simple enough to set up again.  This is the process my dad led me through after diagnosing that the problem is in fact a registry problem.  Then we called it a night.

After this I still needed to get Ubuntu installed on my machine and catch up to where I was with my SugarLabs project.  I was hesitant to use Wubi again since that allowed some damage to my Windows installation, but I am also not a fan of VirtualBox.  I had heard of people booting into Ubuntu using a flash drive and began investigating a way to do that. 

Most of the instructions I found were to have a fresh install every time you boot up, not a persistent boot.  I finally found some instructions to create a persistent bootable Ubuntu flash drive.  I admit I was nervous going into this but I didn't see another way, so I started following the instructions.  To my utter delight and surprise, everything went smoothly!  When it was time to use the flash drive I was a bit lost, though.  The instructions show that during a boot the screen should show a few special keys for book options.  Unfortunately, my screen does not, so I rebooted several times trying different keys mentioned in their example.  Finally I chose F2 which brought me to the boot menu.  I managed to figure out how to tell my computer to boot from the flash drive and tried it.  AND IT WORKED!

In order to make sure that this was a persistent boot I changed a few settings and created a document.  Then I rebooted to see if the changes stuck and they did!  Now to make sure that Windows still booted properly...shut down the computer, remove flash drive, boot up...and Windows works fine!  Finally, it was time to get back to SugarLabs.  Maybe that is something better saved for another blog.  Here, suffice it to say that I'm getting back on track.  My registry is still not fixed so I will continue to work on that, along with using subversion for future backups, but I think that will be an ongoing learning process.

A True Programmer is ... Lazy

This week the class had an assignment to complete the checkout and build of Freeciv, as modeled by our textbook in Chapter 5.  Knowing my schedule leading up to the due date, I began work promptly after the previous class.  Unfortunately, I ran into some problems with installing some of the dependencies and when my research only confused me more, I chose to walk away for a while. Let me actually explain that process.

A big part of my confusion was translating the commands used in Fedora to the commands used in Ubuntu.  When I finally figured out that I should just use the command I was already familiar with, sudo apt-get install <package>, this helped move me along.  However, some of the packages couldn't be found.  I then found the instructions to get those packages from their source website, downloaded them, and followed their install instructions.  Thinking that my problems were over, I repeated my commands and discovered that the packages still could not be found.  Then I remembered that last semester we had trouble with installing dependencies because they simply weren't where the system expected them to be, so I began looking for instructions to tell me how to fix that mapping problem.  I tried what I found and it still didn't work.  Frustrated, this is where I walked away.

I knew that most of the class was using Ubuntu, not Fedora, and would probably run into many of the same problems with dependencies, so I kept checking the class blogs to see if there was any helpful advice.  Finally, this morning I found several recommending the use of the Synaptic Package Manager, instead of the terminal, to install the problem dependencies.  Never having used Synaptic Package Manager, I thought that this would be another good thing to learn, since it seems to be so very helpful.  I wasn't exactly sure which packages to install since so many appeared in my searches, so I just tried to cover my bases with the most recent version and all of its extensions (-dev, -doc, etc.).  Having completed this, I moved on to the configure experience.

I attempted to run the command ./autogen.sh, but the terminal said that no such file could be found.  That was fine since the book showed the same result.  I followed their instructions and still ended up with the same error.  Frustrated again, I opened the actual folder to see if the file existed and sure enough, it did!  Why, then, could my computer not find it?  I almost surrendered but then I realized something very important!  This morning I had not returned the the Freeciv folder and was instead working from my home folder.  I just love those small, easy, careless mistakes that can take hours to find!  Anyway, the careless mistakes continued as I mis-typed the command in the Freeciv directory.  When I finally got through my careless mistakes I finally had victory - the rest of the build was rather simple.

I thought this exercise was a good reminder of several things.  First, it reminded me that sometimes you need to walk away and come back with a fresh perspective.  Second, it reminded me to be extremely careful and mindful about spelling and directories - always check in those places first when you come across an unexpected error.  Third, it reminded me that sometimes it is okay to be lazy.  I don't mean lazy as in putting things off and doing barely enough to get by, but lazy in the sense of really using all of your resources.  Knowing that most of the class used Ubuntu and would be blogging about their experiences gave me an extra set of resources to search.  But I still had to be patient for them to appear when my own Google searches proved mostly useless.

I was also encouraged by one of chapter's closing comments.  The author wrote, "Very few people know every detail about Autotools, or about any build tools.  Experienced developers know as much as they need to know to get the job done, and they know where to look for help when they're stuck."  I am getting a lot of practice knowing what to look for and where to find it this semester, but sometimes I still feel so lost and inexperienced.  It helps to be reminded that experienced programmers still don't know everything - I just need to know how to learn it.

Change is good...right?

The class group assignment this week turned into a bigger challenge than we expected.  In order to reach this point we have researched our HFOSS project, joined the mailing list and IRC chat, started talking with other developers and preparing to dive in.  This week we were challenged to checkout and build the source code!  That seemed like it wouldn't be a problem for our RapidSMS project, until we started looking for the code and trying to choose a specific project to join.  At that point (late in the week) we realized that even the 'beginner' level tasks were far beyond our ability and understanding.  Okay, maybe we could have figured it out eventually, but they went well beyond our confidence level and hope for success.

As we began researching alternatives, now finding ourselves way behind the rest of the class, we took advantage of some of their research.  SugarLabs seems to be a big enough project with a variety of challenges, and two other groups have deemed it possible for a successful class project.  Since one of our other interests originally was educational software, we decided that SugarLabs was the right choice for us.

Even so, at this late hour we were struggling to catch up with orienting ourselves to the project wiki, finding information, source code, IRC information, mailing lists, etc.  This means we all had rather stressful and discouraging weekends, I'm sad to say.  However, I do still have that glimmer of hope.  One of my team members, Carly, shared a link she found for instructions to build to Sugar Emulator.  We're not sure at this point if this is the source code we needed, or if there is more that we need, but following that link I was able to successfully checkout the source code and build it!  You can imagine the celebration until I tried to run the emulator...

At this point I found that I couldn't access any of the activities!  Fortunately I had a prior engagement that forced me to walk away from the problem for a few hours.  I wonder when I will stop being surprised at how helpful it is to take a break!  When I returned later in the evening and ran the emulator again, I had the bright idea to try right-clicking on the activities and all of a sudden a new option appeared: 'Start New.'  Thinking to myself, "Well that looks promising," I chose this option and the activity opened!  I was even allowed to play with it!  There are still a few activities that are not working and this week I hope to understand those issues better - perhaps I am missing a dependency or skipped a step in using those activities.  I'm sure that a little research and reading will go a long way in solving that problem.  I know I've stated this in previous posts, but it is so refreshing to be optimistic about a project this big, especially since my last experience was so discouraging.

On other matters, I unfortunately still do not have the subversion server installed on my machine, at least not fully.  I think I found the server through the Ubuntu Package Manager and I clicked 'Install,' but there is more involved in setting it up.  I was unable to complete that task because I chose to prioritize the HFOSS project for now.  Subversion can wait another day or two.

I still feel like we have a long way to go in order to be 'up to speed' in this project, but I feel empowered to do so and emboldened to ask the questions I need to ask.  Maybe that is the desperation setting in, or maybe the second trimester of a pregnancy brings with it a boldness and sense of purpose.  Who knows?  All I know is that I'm starting to accept that change really can be a good thing, even though it often means there is extra work to be done.

The Power of Subversion

Our current classroom challenge is to install and experiment with subversion.  For those readers who are not already familiar with subversion, it is a Source Code Management System (SCM).  More simply put, subversion is one of many software tools to help you manage different versions of a file or directory through its changes.  For the Mac users out there, you may have heard of a computer back-up program called Time Machine.  I haven't personally investigated Time Machine, but if you've heard the sales pitch, it is a very similar concept.  Using an SCM can allow you, and anyone else with access, to make changes, track changes, revert to previous versions, etc.  It even allows two people to be updating a file or directory at the same time!  As a student who has done my share of group projects, I wish I'd learned about subversion back in high school!

Last semester in my software engineering class I was briefly exposed to subversion through the open source project we worked with.  However, checking out files from the repository was the limit of my experience.  This semester we are going to be using subversion within our group projects to share and manage our own progress and files as we take on another FOSS project.

My experimentation so far had a bit of a rough beginning.  I downloaded and installed subversion on my Windows machine, I couldn't quite get it to work.  The command terminal would open for a second and then close.  Since I also have Ubuntu installed on my machine and I knew I had installed subversion on that system before, I rebooted and entered the world of Linux.  Once I made it that far, things got much simpler. 

Ubuntu already contains the code for subversion, so in order to install it, you simply open a command terminal and issue the install command.  In my case the command is "sudo apt-get install subversion."  I knew I had previously installed subversion because I had used it for a class last semester, as mentioned above.  However, near the end of the semester I had some problems with an Ubuntu update and had to uninstall and reinstall the OS, so I re-issued the command to make sure I did have subversion and then I was able to proceed.

Using the class textbook and another guide on subversion (provided by the professor) I was able to check out files, modify them, add to the repository, update my own copy, and so much more.  If I had more time at the moment I would go back through the reading and try out as many commands as I could!

I am very excited about this tool and am eager to become more familiar with it.  I know that there are many other SCMs available, but I think that being able to say confidently that I have experience with subversion, and thus with the concepts of SCMs, will be a great asset when I begin looking for work.  This is especially relevant to me because I am hoping to find some work which allows me to telecommute, since shortly after graduation I will also become a mother!  Since SCMs allow workers to update and collaborate without being in the same room or same building, I can see that this will be a necessary skill to work from a distance.

Upon Further Investigation...

Since my last post, the A-Team began a deeper investigation into the workings of RapidSMS.  We were primarily looking for information about the inception, history, current work, and primary contributors to this project.  What we found, however, was very little about the inception and history of the HFOSS project. 

In case I had not clarified this before, RapidSMS is a framework for developing data collection and reporting tools using basic text messages.  It is not a stand-alone application.  From our research, this framework seems rather complete.  Most of the current contribution have to do with applications developed on the RapidSMS framework.  Personally, it was interesting and exciting to read about some of the ways RapidSMS has been used and deployed in the world.  Their case studies page has a great summary of how RapidSMS has been tested in the field, primarily in African countries.  There are some other projects beyond these that are currently being developed and which we need to examine further.

We have also been in contact with the manager of the RapidSMS Google Group.  The response was mostly positive.  He was very welcoming and expressed a willingness to help us brainstorm ways that we, as a group of inexperienced students, can contribute to this project - something that I am extremely thankful for.  The only negative really is something inherent to the Open-Source community, specifically that many of the people contributing to the project are either doing this in their spare time or are frantically trying to piece something together for their job, which means we might have to be 'aggressive' in our communications efforts.  This is no surprise, but I sometimes struggle to be aggressive with people I can't see and have never met.  How aggressive can you be when email is your only point of contact?  In spite of that minor discouragement, I find that I am still optimistic about getting involved, especially with the help of the Google Group manager.

I'm excited to start getting to work on the code and exploring, especially after starting to read about subversion!  I was actually amused reading a team-mate's blog because his 'stuck' to start this is the opposite of mine.  My Ubuntu system cannot connect to the school's wireless network, but it can connect to my home network, while his can connect to the school's network, but not his home one.  However, as I am also a full-time military wife, I try to keep my school work at school and take care of home related things at home.  I'm hoping to get help connecting to the school's wireless network this week so that I can keep this distinction for my own sanity, but I may have to make some boundary changes.

Joining the Community

This week we chose an open source project in which to participate.  We, as the A-Team, chose the RapidSMS project, which essentially uses simple texting to update, maintain, and retrieve data about patient healthcare, supplies, or whatever is appropriate in the context.  It is a really interesting project that seems to be encouraging current contributions.

We were able to join their mailing list, which is hosted through Google Groups.  This was quite simple for me, since I have used Google Groups in the past.  I am glad to at least have one tool in my toolbox with which I am familiar.

Joining the IRC client is a bit more confusing and challenging.  A personal aside that will certainly be affecting my performance this semester is that I am pregnant with my first child.  My husband and I are very excited about this, but I am already noticing that my need for sleep has increased dramatically, which gets in the way of my completing the necessary research to learn new tools.  I mention this in my blog because I value honesty: honesty with myself, my peers, and my superiors.  Our group found a way to join the IRC client through a web browser and I have been able to connect, but I still don't understand how it works or what I am supposed to do with it beyond the fact that it is a tool for live communication between collaborators.  I plan to continue researching this because I sincerely want to understand and master the tools Dr. Bowring has presented.  I just have to admit that my progress will likely be slower than I expected.

The Open-Source Bazaar

For class this week we read an article called The Cathedral and the Bazaar, by Eric Steven Raymond.  I found this article very interesting and informative about the difference between the open-source and closed-source models of development. Comparing them to a chaotic bazaar and the creation of a cathedral was very insightful and helped me understand their differences in a very real way.  Cathedrals took hundreds of years to construct, required a small circle of management who made all of the design decisions, and those design decisions were made at the beginning of the project.  The result is a beautiful work of art that inspires awe and draws your eyes to heaven, but these results come centuries after the inception of the concept.  An open street bazaar, on the other hand, comes together completely, quickly, efficiently, and with such variety that you can find whatever you seek from some vendor.

I see a lot of similarities in his analogy.  A cathedral is a safe place, a place of sanctuary, structure, organization.  There is something comforting about that structure, the fortress.  In reading this article I can see why I tend to be drawn more to closed-source than open-source development.  I am not someone who generally likes chaos; instead I thrive with boundaries and guidelines.  While that is my personal tendency, I am growing increasingly aware of the benefits of open-source development.

Raymond's writing style is very engaging, almost convincing me that open-source just might be the answer to software development!  I really enjoyed following his journey as he experimented with the principles he saw modeled by Linus Torvalds in his work with Linux.  The way he pulled out lessons for programming throughout the text was also helpful, yet somehow discouraging to me.

As I continue my education in computer science I find more that I enjoy in the challenge and I am finding my strengths, but I am also finding that my interests are extremely narrow.  If the key to writing good software really lies in the interest level of the developers, then I fear for my future career.  My true interest is in databases, specifically in improving the database tools available to non-profits, which is not a big market. 

On the other hand, if the nature of great programmers is to be "too lazy to fail" then I just might be okay.  I don't like redoing work that has already been done perfectly well.  Why re-invent the wheel?  I remember struggling with that frustration during some of my assignments in earlier classes, even as I realized the value of figuring out how to implement data structures or sorting algorithms myself.  In those cases, I knew from the beginning that if I could create and implement that code myself that I would have a  much better understanding of the material than if I simply used whatever someone else created.  However, in major software projects that are so much more involved and complex, I would much prefer to let someone else do the ground work, give me something to start from.

Maybe after another semester of working with open-source projects I will feel more prepared for the 'real' world.  I believe that I am, but it's those feelings that get in the way.  I guess at least for now it's time to step out of the safety of the cathedral and go shopping in the bazaar...                                      

Diving In...

One of the main goals of the Software Engineering Practicum class is to gain experience working on an actual software development project (practicum -> practice; makes sense to me!).  As students, we are understandably limited to Open-Source Software, and for this class, we are focusing on Humanitarian Free and Open-Source Software (HFOSS) projects. 

I have to admit when I took an initial glance at the main page listing these HFOSS projects, I was not very inspired by the names and descriptions.  I personally have a very focused interest in databases, which not many of my classmates necessarily share.  Also, having worked in the non-profit sector for two and a half years before beginning my computer science degree, I have seen promise after promise of technology that is going to make all the problems in the implementation of an NGO's mission disappear overnight.  Honestly, a lot of the problem is people, not technology; the people in the organization who are so focused on the mission that they are unwilling to spend the time to learn how to use the existing or new tools available to them, the people receiving the services who do not understand the value or importance of them, the people working to communicate that importance without stopping to study and understand the cultural differences and use that understanding in their communication.  Enough of that rant, suffice it to say that I don't believe that technology is the "Silver Bullet" to solve the world's problems, although I do believe it can be a great tool.

After our team, the A-Team, met in class on Thursday to choose our top three options, I went back and researched those three a lot more and, thankfully, got a lot more excited about the possibilities!  The projects that we chose seem to be led by people who do understand the difficulties involved with using technology in developing countries where there is not necessarily electricity or the internet, and seem to be really working to meet the felt needs of their target audience! That makes me so happy!  And I'm so glad to experiencing that sense of optimism that is so important in a programmer/developer!  I think we really can contribute to something good here!

Beginning to Blog

Welcome to my first blog, and thank you for visiting.  Here I will record my experiences, impressions, and lessons learned throughout my time in College of Charleston's Software Engineering Practicum.  I admit that I am a bit shocked to find myself at the end of this degree so quickly! How can I possibly have learned enough to be ready for the 'real' world?  But then, I suppose that sense of confidence and preparedness is part of what this class is about, so here we go!

At this point I have registered for POSSCON, created my blog (obviously) and joined the class wiki, and completed the first reading assignment.  I am happy to say that after completing the reading assignment, I am more open-minded about open-source software than I was at the end of the last semester.  Maybe I just needed a few weeks away to be refreshed in order to regain a sense of optimism!  I have no doubt that I will learn a lot through this class regardless of how much I feel like I've contributed to any project.  Here's hoping...