Joining the Project

     So this has been a fun night of signing up for all of the different collaboration venues available to the Audacity community. This includes the forums here: http://forum.audacityteam.org/, the IRC channel using the Pidgin chat client, and the developer mailing list. I can't say it was all that eventful, but I did come across a couple of interesting things. First off, joining the mailing list was a piece of cake, just put in your email address, then reply to the activation email that they send you. I have yet to get any messages from them, and I've been on it for a few days now, but I doubt they will send too many emails. Probably only when something relatively big is going on with the project. The next thing I did was sign up for the IRC chat. This was also pretty easy to do following the directions posted on the wiki. There was one thing that didn't match up with the direction, however. One of the steps asks you to register your username so that someone else cannot choose it and impersonate you, and the way to do that is by using NickServ, which was built into Pidgin, from what I understand. As soon as you create your username, it warns you that it is not yet registered, although you can choose to ignore it. The wiki instructed me to use the command:

/msg NickServ register password

where password is the password you used when you created your username. This did not work, however. The error message said that the syntax was wrong and that I needed to include an email after the password in order to register. So I did that, and got an email with another command to paste in the chat client that contained a registration code to complete the registration. I think my first suggestion to the community is going to be to update the IRC instructions to reflect what I experienced, even though it really isn't hard to fix given the error message when you try to do what the wiki says.

     The final thing I've done tonight was sign up on the forums, which is where all the meat is. There were 16 people in the IRC chat when I logged on, but nobody was saying anything, so I started reading the forums. After I signed up, I immediately found the perfect subject to read up on: How to Compile Audacity! Earlier tonight I spent a significant amount of time trying to build and compile Audacity from the source code, but haven't yet been successful, although I think I'm really close. Audacity requires the wxWidgets 2.8.x library and a C++ compiler, CMake, to successfully build. 2.8 is actually not the newest version of the wxWidgets library, it is now up to 3.0, which is the one I downloaded, assuming it would work. Installing this library also required me to install yet another dependency, of course. So after doing that, I figured out how to install the library. Installing CMake was easy, as it's just a simple sudo apt-get install command. Now with all of the dependencies installed, I go to try and build Audacity, but it cannot seem to find the wxWidgets library. Turns out, it doesn't work with 3.0 yet, so I went and downloaded/installed 2.8, but it is still giving me the same thing. It doesn't seem to see it. Funny thing is, "Moving to wxWidgets 3.0" is on the front page of the Compiling Audacity section of the forum, haha. Once I finally get this thing built, I'm going to write a step-by-step how to so my groupmates can simulate it.

Foss Experiences and Reflections

     So today's assignment was to install a new FOSS program and fiddle with it some as well as read The Cathedral and the Bazaar and blog about both. As for the FOSS program, I chose Audacity, naturally. I can justify this choice, as even though it was our group's chosen project to work on, I have never really used it before, so it is indeed new to me! I think actually, at some point I have downloaded it - probably back in '07 and '08 when I ran Ubuntu as my main OS, but I didn't really do much with it. My initial findings with the program is that for one, it is not very aesthetically appealing. All of the buttons and menu selections look like pre-Windows XP styled options. Of course, this isn't really that big of a deal as long as it works, but why not make it look pretty? One of the other things that I noticed in my short little tinker session is that when you import an audio file (I used an mp3 song) and increase the playback speed, the pitch of the sounds also goes up, much like old keyboards with pre-recorded songs and a tempo increase button. I found this a bit odd, as from my understanding, it is much more preferable to keep the pitch unchanged from the original, regardless of playback speed. I supposed there are situations for justifying it, like wanting to sound like a chipmunk, but there should at least be an option for enabling/disabling the pitch change effect. It also may be that there actually is some option to achieve this effect that I simply haven't yet discovered, because it really seems outdated if there isn't - just like an old keyboard.

     The second half of the blog will be about the read, which I found delightful. It was a great contrast to the Mythical Man Month, which we read last semester. Just reading about open-source development makes me want to switch back to Ubuntu and get my hands dirty again. I used to use exclusively open-source programs and for those that I couldn't, I would use a Windows emulator (which is probably obsolete now, with virtual machines being all the rage) called WINE (WINdows Emulator) to run the programs that were Windows-exclusive which I still needed. Ubuntu blew my mind at the time, with things like multiple desktop workspaces, a ton of keyboard shortcuts, and seemingly endless addons to customize your desktop, which I loved. Anyhow, that is a little off topic from the reading. I overall enjoyed reading it very much, especially the author's experience in dealing with a (relatively) large base of contributors to his "fetchmail" program. The open-source methodology is so contradictory to what seems intuitive. Lots of developers working on the same project with high turnover seems like it would be a total disaster, but in reality, it is the opposite. Learning how debugging can be solved with a parallel approach was especially epitomic. Multiple developers investigating several different error traces to find the bug and when one will invariably find it, the others can stop tracing. The debugging time scales (logarithmically) with the amount of people debugging! Amazing!

First Impressions

My FOSS Preferences

Plainly, my top three FOSS projects choices are Audacity, Firefox, and Filezilla.

     I'm excited to get started this semester for several reasons. For one, I stopped working so much. I'm only working probably 2 nights a week, 3 tops, and I only have job instead of three. I should have much more time to commit to school, which is exactly what I want. Last semester is probably the worst semester I've had at College of Charleston.
     The second reason is that my group seems very excited and ambitious. I've had classes with John before, and he's a great teammate as well as really smart. Stephen and Matt also seem like great guys. When we were discussing which projects to choose, Matt through out the idea of Audacity and immediately, Stephen was stoked. Apparently he is big into audio processing on his own - he's got an idea of writing a plugin that would fill a big need that he says hasn't been done before, or at least to his knowledge. Working on Audacity also tailors to my interests. I have a pretty large musical background. I was in choir all through middle, high school, and a couple years in college as well. I taught myself how to play the guitar in high school and have been playing off and on since. I can read music, although not fluently, given time I can figure it out. Another great thing about this project is that if we succeed, Stephen says we could make money off of it, which would be awesome and a great resume builder.

     Some of the resources for the reading today was pretty familiar to me. Everyone knows what wikis and blogs are, but I had to look up planets. It's basically a feed aggregator which displays posts from other web-blogs and internet communities on a separate new webpage. I'm also familiar with listsrvs. As I work at the helpdesk, there are several times I've dealt with them. Sometimes, when people graduate, they're email is still on the enrolled student listsrv, so they still get emails even after they've graduated. There's also listsrvs for department faculty, all faculty, certain student body groups, among many others. They are incredibly useful when trying to communicate to a group of people.

Homework #19 - 10/24 (Makeup)

Tonight I'm going to blog about my project for my databases class. I was really enthusiastic about it and intend to keep working on it after the course is over, just for the experience. It was supposed to be a system for backyard gardeners. Users would be able to create an account with their name, email, and address. They would automatically be assigned a garden object upon their account creation. This was going to be handled by using SQL triggering on the database. The code would look something like this:

DELIMITER \\
CREATE TRIGGER addGarden  AFTER INSERT ON gardeners
BEGIN
  INSERT INTO gardens (owner_id)
  VALUES (OLD.id);
END\\
DELIMITER ;

I did not get this code to actually work, but the idea is that you have to change the delimiter from a semicolon before you write the function so that you can use the semicolon at the end of the insert statement without ending the function early. The trigger runs after an insert occurs in the gardeners table, or in other words, after a gardener has created their account. It then inserts a new garden into the gardens table with the owner_id attribute of the garden set to the OLD.id. Here the OLD means that it is using the id of the statement that caused the trigger, the gardener. I think this may be where I made my mistake, as I am not sure that the OLD.id is doing what I think it is. Then the trigger is ended, and we reset the delimiter back to the semicolon.

There is also a pre-filled database of plants containing attributes such as common name, scientific name, mature height, duration, growth rate, minimum pH, maximum pH, among others. Users will be able to select from plants from this database to add to their personal garden and will get advice on things they should do based on the plants selected, for example, how deep to plant the seed, or how far apart it should be from another seed. The system will also recommend certain plants that the user should try to grow based on the location of their address. It can do this because the database also has table containnig list of states that each plant naturally occur in, so it can do a simple query like the following to produce a suggestion list:

SELECT common_name FROM plants p
INNER JOIN naturally_occuring n
ON p.scientific_name = n.scientific_name
INNER JOIN gardeners g
ON g.state = n.state
WHERE g.state = n.state

This code seems bloated from reading it, but it basically makes a new, temporary table from the three tables, plants, naturally_occurring, and gardeners and matches the tuples accordingly. It then selects only the common name of the plants where the state the gardener lives is the same as the state that the plant naturally occurs in.

For now that is all, I intend to have more features too - perhaps reminders on when to harvest, or weather information to alert users of inclement weather that may endanger their plant.

Homework #25 - 11/14 (Makeup)

Deliverable 4:

     I'm much more happy with my contribution to the group from this point on. I spent several hours working on this deliverable with material the other group members gave to me. I researched online to see what a professional deliverable report should look like, and borrowed elements of the layout and some formatting designs. I also feel like I have pretty sufficient technical writing skills, so when I compared my report to the ones the group previously produced, I feel as if the writing quality was just a little bit better, or at least more concise and to the point.
     Again, however, the group suffered from our division in both design and communication, and so the product was not written with a complete understanding of the overall system design. For example, in our test cases, the "Requirement" section of the JSON file was usually just a '?'. I had no idea what was even the point of including this in the file if they were all just question marks. When I was reading back through some of the older deliverable instructions, it said that each test case was to be able to be traced back to a single requirement. For me, that is what this section should have stated: which requirement is this specific test case testing for? After asking Ian about it, however, he explained it as it was supposed to be the required circumstances of the input to get the same expected result. Perhaps I still misunderstood what he said, but this is what I took away from it at least.
    I also reworked some of the previous deliverables to fit into this one and rewrote some of the wording, since at each deliverable, it stated that it was supposed to be a chapter in our final deliverable booklet. I was quite pleased with the document after I was finished with it. It really did look like a professional document. Tan whipped up some images we could use as kind of a company logo for our group, and I was able to include those as well, further adding to the convincing professionalism. Getting a good looking deliverable wasn't the only positive thing that came out of the experience, though. All of my team members complimented my work on it, and I felt like I finally did something to really contribute to the group, boosting my confidence as well. Really a great experience overall and I'm glad I was able to work on it and put so much time into it.

Homework #20 - 10/29 (Makeup)

Deliverable 3:

     To be honest, I don't even remember what was going on with my circumstances around the time of deliverable 3. My group basically functioned entirely without me for this one. I feel like I definitely dropped the ball during this part of the semester. I remember Ian showing me the code and walking us through it as a group. I also remember suggesting that we should implement a time stamp attribute to keep track of when the test cases were run. Even though our set of test cases were run basically at the same time, or at least with very little time in between each, it wouldn't matter much for our class project, but in a real world setting, information about who ran the test, and when it was run would also want to be recorded. Other than that, Ian pretty much wrote the entire framework, and Andrew wrote the entire deliverable. I'm not sure what Tan was working on at the time.
     In a sense, I suppose we divided up our group sort of like the surgical team described in the Mythical Man Month, with Ian being the main surgeon. Andrew and I were mainly bookkeepers and Tan ended up filling a dual role of the surgeon's right hand man, and also the public relations person, since he wrote the front end of our application, which would communicate the information to the client. In our case, however, the group suffered from more disorganization than anything else. Normally, the division of tasks among group members is to increase the total efficiency, but in our case it probably hindered us more than doing us any good. It is very much similar to how Brooks describes some systems being developed by large teams: programmers are usually in charge of not only the implementation, but also the design of their components of the system. In this sense, you get several components that are not designed in a unified manner. This was the case in our group as well, I think. We had basically one person writing the framework, so the others might not have fully understood the design. Unfortunately, that includes those of us who wrote the actual deliverables - so some of the information conveyed could have likely been incorrect as it was not fully understood in the first place.

After hearing that we did pretty much a horrible job on this deliverable, I committed myself to putting a lot more effort into the team and our future deliverables.

Homework #18 - 10/22 (Makeup)

Chapter 19 - Service Oriented Architecture

     This chapter brings back memories.... I interned at BMW in Spartanburg at the IT Innovations department. There was a lot of neat things going on there with several different projects being worked on by different interns. I was probably assigned the least interesting project, and also probably the hardest. Let me see if I can recall, in correct details, what I was assigned. I was working on a back end web service which would be used for an in-house app store. The web service was to take in a JSON message which contained metadata about an app and error reporting for that app. It would include the client/developer name and contact information, a time stamp that the error report was sent, the error message, and some other stuff I can't remember. The JSON message was sent via SOAP and RESTful messages to a Glassfish server that was hosting my web service. The service was then to take the JSON, parse it, and store the information in an Oracle database. Whew, I think that's the gist of it.
     The reason this was, at least what I perceived, the hardest task is because I had never had any exposure to all of the technology and standards that come along with web services. For that matter, I don't think any of my colleagues did either. I had to read about SOAP messages, RESTful services, WSDL and XML descriptor files, and other things I don't remember. It's also the first time I had seen SQL or done anything with a database, so the learning curve was huge, as you can imagine. It took me the entirety of my 5 month internship to finish what should have been a relatively simple program.
     If I had another chance to develop the same type of system, I would jump at it. Back then I didn't really have a good grasp of what things such as a WSDL file was. All that I knew is that it was necessary to have for a web service to run. Now that I realize what it actually is and it's purpose, it wouldn't be nearly as confusing if I were have to do it again. Another thing I might employ is an actual life cycle model for my project. I remember not really knowing what I was doing, and just using the code-and-fix or waterfall models. Once something broke, and I couldn't figure out what I did to break it, I would frequently just scrap the whole thing and started over from scratch - it was quite frustrating, really.