I've been fighting with this bug for a while now. The problem is that a graph where the x-axis follows a logarithmic scale, the minimum value allowed is 20. The x-axis on this graph represents the frequency of sound in Hz, and it makes sense, to me (and probably the original designers), to have the lower limit be 20 Hz because that is the lowest frequency that the human ear can hear. However, some of the developers think that it might be useful to have it be zero for people who might use Audacity for reasons other than audio recording. You can test bass speakers at frequencies below 20 Hz and watch them slowly move back and forth trying to produce the sound. I found the 'equalization' effect source code, which a lot of it seems relevant to the bug (the graph is used for equalization and comes up when you select the 'Equalization' effect from the effects menu), but I'm having trouble understanding most of the source code included in it. The file is over 3000 lines of code, after all... I've found a few things in it that I could almost swear would cause the problem, but when I save and rebuild, the lower limit is still at 20 Hz. The first thing I found was an array of doubles, which starts with 20.0, and the rest of the numbers in the array highly correlate to the values along the x-axis, so I tried changing the head value (again, 20.0) to 0, but nothing happened. There's also some places in the code which set a 'lowLog' equal to the log base 10 of 20.0. I changed these to 1.0 instead of 20.0 because the log of 1 = 0, which is what they were hoping the lower bound would be. Nothing has worked, however. A couple of times after re-building the code, it returned compile errors - so I had to undo my changes. It looks like some of the output from Equilization.cpp goes to another file Equilization.o (object?), which is affected by some changes and causes errors there.
That's about everything I've been up to, personally. John made an outline for the online tutorial we'll be writing, which turned out good. I'm looking forward to seeing how that turns out. I suspect I'll be doing most of the editing for it after he and Joseph have some substance to it - for some reason I love proofreading other people's writing... We're also planning on meeting to work out some details for the poster. We need to figure out which program we're going to use to design it. I don't think anyone in the group has Photoshop, but perhaps there's an open-source solution out there that will suffice!
Monday, March 24, 2014
Thursday, March 20, 2014
Planning to Meet Charleston
There
were a few groups from the list that I was interested in attending meetings
for. My first choice is the Agile Group. Agile development seems to be the most
desirable type of development for today’s employers and I think that being a
part of that group would not only help increase my understanding and skills on
the subject, but also look pretty good on a resume. Unfortunately, they do not
have an open calendar, so I submitted a request to join their LinkedIn group. There
were a couple of familiar faces from my contacts who are already a part of the
group. We’ll see what their meeting schedule is like once I get an invitation.
The
second group I was interested in was the Charleston Tech Group. This group
seems a bit more broad as far as topics covered, but upon looking at their ‘meetup’
website, I was pleased to find that they had a great range of interesting things
in their meetings. Topics covered everything from 3D printing to Java games to
Android UI development and more. There are two meetings that are being planned
at the moment. The first is for JVM languages (such as Clojure) which I thought
was interesting because that is what Jason’s group is using in their project
this semester. The other is about UML / Graphic design tools to model process
flow. This might not be the most exciting talk to attend, but I do feel that it
would be educational. There is a lot of automation possible when you model a
program in UML tool that can generate code based off of the UML relationships.
Sadly, neither of these meetings have dates pinned to them yet, so I’m not sure
when/if they’ll actually happen. It looks like their last meeting was almost
exactly 11 months ago, so I’m not sure how active they are.
The
third group I was pretty excited about was the SCSLUG group – Charleston South
Carolina Linux Users Group. There was a funny post on their Google+ page by
someone who said: “…my Linux pimp hand is not as strong as I would like…”. It’s
pretty funny, but it’s also similar to how I feel. When I first started using
Linux in ’07 I was very intrigued, but also a little apprehensive. My friend
that showed it to me was very intelligent and I was a little intimidated by it,
almost thinking that it was only for smart people to use. I don’t think the
same way about it nowadays, but I still don’t know how to fully leverage the
strong points of Linux, so I think attending this group would be a great
learning experience. By looking at all of the pictures they had up on Flikr, it
seems like a pretty friendly group as well! Apparently, they meet every second Saturday
of the month, though, so it won’t be until April 12th before they
have their next meeting. Hopefully one of the other groups will have a meeting
coming up sooner. If not, I might talk to some classmates and see if they found
anything else interesting that is coming up sooner.
Thursday, March 13, 2014
After the break...
Going into the break I was pretty depressed about how my semester was going. I was doing poorly in multiple classes due to my poor attendance caused by my chronic illness. I had missed tests, assignments, and I just didn't feel good about any or it. During the break, though, the medicine I had started a while back finally started showing progress and now I'm feeling much better (still not 100%, but a big improvement). I've spoken with my professors and am allowed to make up the missed work and I'm feeling great about getting back on track. I also got an email from a recruiter at Google asking for my resume and transcript, so that is also very exciting!
Aside from all the non-coding related stuff, I was able to build our project from source and started looking at a particular bug. I believe I've found the exact file in which the bug occurs, now the only thing left is to pinpoint it. The file is quite but - 3600 lines of code - but I don't think it will be that bad. After reading a few hundred lines of it, I'm beginning to get a feel for the project and how it works. Some of the code was commented out, and there has been decent documentation within the code to let you know what it's doing, but of course it could be better. The code itself is descriptive as well, which helps a ton, so I'm pretty confident about fixing this but, which will be the first one for our group. It's also exciting because my group was getting nervous about my attendance and wasn't sure what was going on - I was kinda MIA, so if I fix a bug it will probably be a big relief to them, and myself as well of course.
Tuesday, March 11, 2014
Reflections on my Progress
So far this semester has been slow. Sometimes I feel like I can be a little more critical on myself than is necessary, but I feel like our group has not accomplished much compared to the others. We've contributed to the Audacity wiki, and built the source code on all the operating systems as well as put the source code up on a Github repository, but have yet to do much else. The group also seems to be a little divided as far as vision for the project. There seems to be too many ambitions among us all. Some just want to fix a few bugs and keep it plain, some have thrown the idea out of writing a nyquist plugin, and another idea came up recently of writing an online textbook (much like the one we've been reading this semester) that uses nyquist as a gateway language to teach non-programmers how to program. Nyquist is a functional language that you can use to basically generate sounds and manipulate them. Apparently, even though Audacity is written in C++, it actually handles all of the audio code with nyquist - the C++ is mostly the interface and file managing. One of the challenging things I find about this project is that because Audacity is cross platform, some of the bugs are only specific to one operating system. This means that when I'm reading a bug on the BugZilla and trying to reproduce it in Linux, I find one behavior and I think I know how to approach it, but then I check the same bug on Windows and find something unexpected and I am no longer sure of my strategy, or if a fix that I apply might break it on the OS in which is was originally working.
The group has decided on a couple of bugs to focus on, thankfully, which we hope to have figured out by the end of the break - one involving a frequency scale that does not accept a value below 20 Hz, and another more interface related one that deals with button shading so that it's more obvious to the user what is selected. Also, I'd like to catch up on my blog posts (needless to say...) not only for the grade aspect of it, but blogging also helps me to gather my thoughts about the project, the group, and everything else that's going on. It helps me reset my perspective, which in turn makes me think more clearly about the project and gives me a little boost in confidence - not to be taken lightly!
The group has decided on a couple of bugs to focus on, thankfully, which we hope to have figured out by the end of the break - one involving a frequency scale that does not accept a value below 20 Hz, and another more interface related one that deals with button shading so that it's more obvious to the user what is selected. Also, I'd like to catch up on my blog posts (needless to say...) not only for the grade aspect of it, but blogging also helps me to gather my thoughts about the project, the group, and everything else that's going on. It helps me reset my perspective, which in turn makes me think more clearly about the project and gives me a little boost in confidence - not to be taken lightly!
Tuesday, February 25, 2014
That could be me in a year!
Here I comment on the Alumni Symposium. My class schedule this semester did not allow me to attend this time, so the only thing I know of it is the speaker lineup. I'll mainly comment on a symposium I attended a couple of years ago. The first thing I want to mention is that the age of the speakers is vastly different. The symposium I attended earlier in my college career featured many older graduates, mostly from the graduating classes before 2000, whereas the recent symposium had several students who graduated within the past couple of years. Many of them stayed in Charleston as well. Most of the speakers talked about their job, and there was one who spoke of graduate school. I remember one speaker worked in the defense industry and spoke of the potential of jobs in the security sector. There was another interesting alumni who apparently did not originally graduate with a computer science degree. He was a construction worker for a long time, but realized that he didn't want to be doing it his whole life and went back to school for computer science. You would never guess that he was a computer scientist by looking at him, which just proves the saying "You can't judge a book by its cover." Dr. Starr said that he did all of the homework problems at the back of the book instead of just the ones that were assigned as he was really committed to his education and making it work for him. He was probably the most impressive speaker to me. The last speaker that I remember was a graduate student, I think going for his Masters degree, who specialized in optimization of the workstation, or something similar. I think I remember that he was all about having multiple monitors in some particular orientation to maximize productivity. At the time, I remember thinking that it seemed kind of silly, because everyone knows that having two monitors over one increases productivity. We employ this strategy at the helpdesk, the lab was recently implemented it, and at the time, I thought it was already pretty much common knowledge.
I'm not sure I personally identify with any of the speakers that I remember. I don't see myself going to graduate school, or at least not right after I get my Bachelor's degree. I don't think I'd like the security sector that much, although I'm sure your job would also be very secure if you were in that industry. I want to somehow contribute to society with my skills. I don't mean to say that programming jobs don't contribute, because surely they do, in one way or another, but I mean in a sense that makes the world a better, easier, more healthy, or environmentally friendly place to live. Not just work for a random for-profit company that writes and provides program x to a particular market. I think I made a post last semester about the point of sale software that Papa John's uses. I don't want to be on the team that writes programs like that, I want to be on the team that writes, for example, software that helps reduce emissions, or guides solar energy panels during different weather conditions for the maximum output. Maybe not in a year, but some day, I hope.
I'm not sure I personally identify with any of the speakers that I remember. I don't see myself going to graduate school, or at least not right after I get my Bachelor's degree. I don't think I'd like the security sector that much, although I'm sure your job would also be very secure if you were in that industry. I want to somehow contribute to society with my skills. I don't mean to say that programming jobs don't contribute, because surely they do, in one way or another, but I mean in a sense that makes the world a better, easier, more healthy, or environmentally friendly place to live. Not just work for a random for-profit company that writes and provides program x to a particular market. I think I made a post last semester about the point of sale software that Papa John's uses. I don't want to be on the team that writes programs like that, I want to be on the team that writes, for example, software that helps reduce emissions, or guides solar energy panels during different weather conditions for the maximum output. Maybe not in a year, but some day, I hope.
Tuesday, February 18, 2014
Squashed?
This post is supposed to be a report on a bug we fixed and submitted. I am sad to say that has yet to happen with our group - at least for a legitimate bug. We created a Google+ group a while back and have tossed around several bugs to examine more closely from the Audacity Bugzilla, but have yet to make any changes to the code. The most significant thing we've contributed to the community, and so far the only thing that I'm aware of, was getting them to update the wiki with proper instructions on joining the IRC chat. I've recently created a GitHub repository for our group to use for our bug fixes, and possibly a Nyquist plugin that we'd like to write. I figured we'd try GitHub instead of Subversion this semester just to get more exposure and experience with more tools. So far, 3 out of 4 of us have successfully built Audacity from the source code, with me being the one left out. John and Joe used Ubuntu or a virtualized version of Ubuntu to build it, while Matthew used Visual Studio on Windows. I think the main reason that it's not working for me is that I am running Mint Linux, which somehow complicated the build process. I've been on the Audacity forums getting some help, but so far have still been unsuccessful. I plan on reformatting my computer and just putting Ubuntu on it instead. I think I like Ubuntu more anyway...
Thursday, January 23, 2014
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.
/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.
Tuesday, January 21, 2014
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!
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!
Tuesday, January 14, 2014
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.
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.
Wednesday, December 4, 2013
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.
Sunday, December 1, 2013
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.
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.
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.
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.
Homework #17 - 10/17 (Makeup)
Chapter 18 - Distributed Software Engineering
*After reading my fellow team members' blogs, I realize that mine isn't looking too bad. I'm not saying that their blogs are any better or worse than mine by any means, I just thought I was much farther behind than I really am, which gives me hope. We are optimists, after all, as Brooks says in the Mythical Man Month.
This chapter is all about distributed systems, which in reality, includes most systems in use today. Even word processors now, are linked to the cloud and remotely load settings in from other sources. The author highlights some of the difficulties included in developing a distributed system:
*After reading my fellow team members' blogs, I realize that mine isn't looking too bad. I'm not saying that their blogs are any better or worse than mine by any means, I just thought I was much farther behind than I really am, which gives me hope. We are optimists, after all, as Brooks says in the Mythical Man Month.
This chapter is all about distributed systems, which in reality, includes most systems in use today. Even word processors now, are linked to the cloud and remotely load settings in from other sources. The author highlights some of the difficulties included in developing a distributed system:
- Transparency - Should the system appear as a single unit, or is it sometimes useful to understand that it is, in fact, a distributed system? My intuition here, says that it is better to appear as a single unit. It just seems like a cleaner design and hides the unnecessary details from the end user.
- Openness - Should a system be designed using standard protocols that support interoperability or should more specialized protocols be used that restrict the freedom of the designer? Here I think it definitely varies on the system being built. If the system is something that has very specific and unforgiving requirements, then probably specific protocols should be used. If there is a little flexibility in the design of the system, perhaps then, using standard protocols to increase interoperability would be preferred.
- Scalability - How can the system be constructed so that it is scaleable? How can the system be designed so that it's capacity can be increased as demand increases? Cloud computing comes to mind as a good solution to this problem. If your service is getting more demand, allocate it more resources from the cloud.
- Security - How can usable security policies be defined and implemented that apply across a set of independently managed systems?
- Quality of Service - How should the quality of service that is delivered to system users be specified and how should the system be implemented to deliver an acceptable quality of service to all users? This is a good question - what does quality of service, in the case of your system, mean? Is it having a stellar feature set, or is it more focused on always being available?
- Failure Management - How can system failures be detected, contained, and repaired? For distributed systems, this is a big concern. You may not have control over some of the components of the system, but when they fail, the service is either interrupted or degraded, so how do you plan for that?
Reading this chapter has helped me increase my understanding of distributed systems, and what everyone means when they talk about things like, scalability, and quality of service, etc. I've kind of been able to identify certain parts with my databases class. We've had to develop, essentially, a distributed system of our own design over this semester. We use a MySQL database in the back end to store our entities, and their relations, and write a php or java front end to serve the data to clients in the web browser and allow them to perform basic crud operations on the data being stored in the database. I'm very grateful for my undergrad experience here at College of Charleston. I'm not sure how well other schools prepare their students for real world applications, but I feel as if the staff does a good job here by assigning relevant readings and projects.
Homework #16 - 10/10 (Makeup)
WELL - here I was about to read chapter 17 of our book, but when I start flipping through the pages, I realize that I've been reading the wrong textbook for a good portion of this semester, because the book I have been reading doesn't even have a chapter 17. This is pretty depressing....I've been reading the textbook we used for my CSCI 360 class. A lot of the material is similar, but still. I've probably done several incorrect assignments up to now. I don't know when it was that I confused our books, probably after fall break when my health started getting worse and I wasn't sleeping as well and started missing a lot of class. Ah well, what can ya do?
SO, chapter 17 of the right textbook. This chapter is all about software reuse and taking small preexisting components and composing them into a larger target software program. A 'component' can be interpereted in different ways, however. Some define it as a software element that can be independently deployed and is composed according to a composition standard. Others say that it is unit of composition with contractually-specified interfaces and explicit context dependencies. Basically, some think that a software component is only defined a component if it is written by the standards, and others define a component based on its key characteristics.
Some definitions of component characteristics to remember:
Software reuse is one of the things mentioned in "The Silver Bullet" as a way to dramatically increase software development productivity. Buying off-the-shelf software not only saves you the pain of designing, and writing it, but also the huge task of testing and debugging it. This is certainly an imaginable concept, but it would also require huge effort on the part of the developers to write their components according to a standard so that they may be compatible with other components written in the same fashion.
SO, chapter 17 of the right textbook. This chapter is all about software reuse and taking small preexisting components and composing them into a larger target software program. A 'component' can be interpereted in different ways, however. Some define it as a software element that can be independently deployed and is composed according to a composition standard. Others say that it is unit of composition with contractually-specified interfaces and explicit context dependencies. Basically, some think that a software component is only defined a component if it is written by the standards, and others define a component based on its key characteristics.
Some definitions of component characteristics to remember:
- A component is standardized if it is used in a CBSE process and conforms to a standard component model. This can define interfaces, metadata, documentation, composition, and deployment.
- A component is independent if it can be composed and deployed without the use of other components
- A component is composable if all interactions take place through a publicly defined interface.
- A component is deployable if it is self contained and able to act as a stand-alone entity.
- Components must be documented so that future users can decide whether it will meet their needs or not. All of the syntax and semantics of the interface should be defined.
The rest of the chapter goes on to define the two different types of component-based software engineering: development for reuse, and development with reuse. The first dealing with making components that will be reused in other applications and the later making applications that use existing components.
When writing components for reuse, you need to make sure there are no application-specific methods, names have been generalized, methods provide complete functionality, exception handling is consistent among methods, incorporate a 'configuration' interface to allow the component to be adapted to different situations, and integrate any required components so that the developed component is independent.
When writing applications that use preexisting components, you first design the application in an outline being as general as possible to maximize the number of potentially usable components. Then, you modify requirements depending on the available components and design the architecture. Further component search and design follows based on whether the previously selected components will fit the need. Finally, after all the components have been selected and the architecture design solidified, the system is composed.
Software reuse is one of the things mentioned in "The Silver Bullet" as a way to dramatically increase software development productivity. Buying off-the-shelf software not only saves you the pain of designing, and writing it, but also the huge task of testing and debugging it. This is certainly an imaginable concept, but it would also require huge effort on the part of the developers to write their components according to a standard so that they may be compatible with other components written in the same fashion.
Homework #13 - 9/26 (Makeup)
This reading is all about software life cycle models. Not the most interesting thing to read about, but certainly important. Just as we can model systems and their behavior with UML diagrams for a better understanding of the system and an aid in the development of the system, we, too, can model the development cycle of a piece of software. Also, un-intuitively, software life cycles can be modeled as activity-centered diagrams, where a class in the diagram represents an activity in software development (ie Problem Definition Activity, or System Development Activity). The other way life cycles can be modeled uses an entity-centered view, in which each class in the diagram represents the content and structure of the work product (ie a Requirements Specification Document).
There are several commonly used life cycle models, most of which are activity-centered. The first, and oldest, being the Waterfall model, in which it describes a sequence of activities that occur. The requirements process leads to the design process, which leads to the implementation process, etc. The thing about the waterfall model is that there is no way to back up, to traverse up the waterfall is impossible. Because of this, the waterfall model is not used in large, costly software development. It is mainly only appropriate for small scale personal or school projects, where one can restart with little consequence. The V-model is a variation on the waterfall model in which with each activity before implementation, there is a paired activity afterward that focuses on the validation of the system through testing and client acceptance. There still is no way to go backwards in the life cycle, or re-iterate on activities. For this reason, the spiral model has become popular. This risk-analysis based model starts at an origin and spirals outward. The farther away from the origin, the greater the cost of the development thus far. Each quadrant of the model represents the type of activity that is taking place along that point in the spiral. This way, as you move along the spiral, you will iterate among the four quadrants, first determine objectives, alternatives, and constraints. Then evaluate the alternatives, identify and resolve risks. Then comes developing and verifying the next component in the system, whether it is designing, or coding. Finally, you plan for the next phase, which could be a requirements plan, or integration plan.
I cannot say I plan on becoming a project manager at any point in my career, but learning about life cycle models is still important to me. It's all related in the end, really. For example, the spiral model can not only be used in modeling software life cycles, but it can also be used to model a design plan for your code. First, design the general layout of your code - come up with classes and methods, etc. Then write some prototypes and evaluate any alternatives, once you've decided the best way to go about it, write the code. After writing that portion of code, test and debug it before moving on to the rest of the program. This way you write in small increments and each part is tested on its own before you integrate all of the components together for the whole program.
There are several commonly used life cycle models, most of which are activity-centered. The first, and oldest, being the Waterfall model, in which it describes a sequence of activities that occur. The requirements process leads to the design process, which leads to the implementation process, etc. The thing about the waterfall model is that there is no way to back up, to traverse up the waterfall is impossible. Because of this, the waterfall model is not used in large, costly software development. It is mainly only appropriate for small scale personal or school projects, where one can restart with little consequence. The V-model is a variation on the waterfall model in which with each activity before implementation, there is a paired activity afterward that focuses on the validation of the system through testing and client acceptance. There still is no way to go backwards in the life cycle, or re-iterate on activities. For this reason, the spiral model has become popular. This risk-analysis based model starts at an origin and spirals outward. The farther away from the origin, the greater the cost of the development thus far. Each quadrant of the model represents the type of activity that is taking place along that point in the spiral. This way, as you move along the spiral, you will iterate among the four quadrants, first determine objectives, alternatives, and constraints. Then evaluate the alternatives, identify and resolve risks. Then comes developing and verifying the next component in the system, whether it is designing, or coding. Finally, you plan for the next phase, which could be a requirements plan, or integration plan.
I cannot say I plan on becoming a project manager at any point in my career, but learning about life cycle models is still important to me. It's all related in the end, really. For example, the spiral model can not only be used in modeling software life cycles, but it can also be used to model a design plan for your code. First, design the general layout of your code - come up with classes and methods, etc. Then write some prototypes and evaluate any alternatives, once you've decided the best way to go about it, write the code. After writing that portion of code, test and debug it before moving on to the rest of the program. This way you write in small increments and each part is tested on its own before you integrate all of the components together for the whole program.
Homework #11 - 9/19 (Makeup)
Reading through these old assignments is a little bit depressing. Not in the sense that I don't like reading them, but just realizing how many of them I've actually already read, but never wrote a blog post on.
Seeing as I have not written very many complicated programs, when I read that about half of the development time of a piece of software is devoted to testing and debugging, I was a little surprised. Can it really be so cumbersome? The author provided many references to back up his statement of this, and it was also mentioned in the Mythical Man Month article, in which the author stated that he devotes one third of the development schedule to designing, one sixth to implementing, then the rest (half) to testing and debugging - wow! I suppose it sounds intimidating, but I'm the inexperienced one here, so I'll take their word for it!
One of the most interesting parts of this read for me, was the different phases of thinking about testing and debugging. The author has a funny line in the article: "I called the inability to distinguish between testing and debugging 'phase 0' because it denies that testing matters, which is why I denied it the grace of a number". Well said, sir. Well said. Phase 0 thinking assures that your software will have no testing, therefore no quality assurance, and therefore, no quality. Phase 1 thinking is assuming that when your tests succeed, the software works. But in reality, this is not the case. Myers says that it only takes one failed test to prove that software doesn't work, but even an infinite number of tests cannot prove that it does work. Phase 2 thinking is where you assume the software doesn't work. In this case, the tester is always trying to prove that the code is broken, and if perhaps it is not, testing will never end, because there are no bugs to reveal - but they keep trying. Phase 3 is thinking about testing and debugging as gaining confidence in the software. A successful test does not actually improve the quality of the software, but it increases our perception that it is quality software. Therefore, when we have gained an acceptable amount of confidence in the software through testing and debugging, is when we release it. And finally, phase 4 thinking is a state of mind of testing. Developers know there will be bugs, but the main goal is to write your code with testing in mind. The act of thinking about and designing tests while programming will increase your bug prevention, and make your code easier to test when the time comes. Although all of the testing strategies strive towards the same goal of quality software, this is the best. It not only reduces the amount of bugs by using preventative measures, but also makes the labor of testing easier because the code, itself, is more testable.
Seeing as I have not written very many complicated programs, when I read that about half of the development time of a piece of software is devoted to testing and debugging, I was a little surprised. Can it really be so cumbersome? The author provided many references to back up his statement of this, and it was also mentioned in the Mythical Man Month article, in which the author stated that he devotes one third of the development schedule to designing, one sixth to implementing, then the rest (half) to testing and debugging - wow! I suppose it sounds intimidating, but I'm the inexperienced one here, so I'll take their word for it!
One of the most interesting parts of this read for me, was the different phases of thinking about testing and debugging. The author has a funny line in the article: "I called the inability to distinguish between testing and debugging 'phase 0' because it denies that testing matters, which is why I denied it the grace of a number". Well said, sir. Well said. Phase 0 thinking assures that your software will have no testing, therefore no quality assurance, and therefore, no quality. Phase 1 thinking is assuming that when your tests succeed, the software works. But in reality, this is not the case. Myers says that it only takes one failed test to prove that software doesn't work, but even an infinite number of tests cannot prove that it does work. Phase 2 thinking is where you assume the software doesn't work. In this case, the tester is always trying to prove that the code is broken, and if perhaps it is not, testing will never end, because there are no bugs to reveal - but they keep trying. Phase 3 is thinking about testing and debugging as gaining confidence in the software. A successful test does not actually improve the quality of the software, but it increases our perception that it is quality software. Therefore, when we have gained an acceptable amount of confidence in the software through testing and debugging, is when we release it. And finally, phase 4 thinking is a state of mind of testing. Developers know there will be bugs, but the main goal is to write your code with testing in mind. The act of thinking about and designing tests while programming will increase your bug prevention, and make your code easier to test when the time comes. Although all of the testing strategies strive towards the same goal of quality software, this is the best. It not only reduces the amount of bugs by using preventative measures, but also makes the labor of testing easier because the code, itself, is more testable.
Saturday, November 30, 2013
Homework #9 - 9/12 (Makeup)
Response to Mythical Man Month (Ch 1-4):
Tonight's reading was quite interesting to say the least. It touched on many different aspects of the development life cycle of a programming project. For one, when a project is falling behind schedule, a natural reaction is to add more man-power in order to get it back on track. However, adding men to the project, in fact, has the opposite effect. Time for training the newcomers in the language, environment, and the current system design must be accounted for. Then there's the time it takes to devise a new delegation of the tasks involved in the project, so that the new people have something to do. And finally, you must include the time it takes to re-write the schedule with the new man-power included in the projection. So overall, the trade-off for adding more people to a project to get the job done faster is negative.
I like the idea that the author credited Harlan Mills for: making programming teams that resemble surgical teams. Several small groups of people working on the same project, or component of a project, with each member having a very specific role within the group that supports the effort of the group as a whole. Only one or two main programmers and designers, and several other supporting roles are needed. This idea of a surgical team reminded me of a pair-programming video that Dr. Starr showed our CSCI 230 class several semesters ago. It stated that using pair-programming increases productivity, quality of code, and the learning and enjoyment of the programmers involved, and although I cannot say I've had much experience with pair-programming, I am inclined to agree heavily.
Another part of this article was talking about how most programming projects are divided among developers, and each developer is also in charge of the design of his or her specific component. The author says that this is dangerous because the overall design of the system is no longer unified, and can have many parts that, while they may be well designed in themselves, are not designed to work with the other components as well. Therefore, again, the solution is to divide the design of the project from the implementation of the project. Hence where the term, code monkey, comes from. A small team of the "creative" and "elite" programmers get to have all the fun designing the system, then pass off the frustrating part of implementation to the "lesser" programmers. This idea in itself seems backwards to me as well. Why would you want the elite programmers to just design it, if they aren't going to the skills that classify them as "elite" to actually code it? Even though it may be well designed, the code would not be as efficient and reliable as it would had the elite programmers been the ones coding it in the first place. Perhaps I'm thinking about it in the wrong way. The author did say that this team architechture should only be used for large scale programming projects.
I enjoyed this read a lot and have definitely taken away from it, at the very least, that adding more people to a project that is running behind schedule is the wrong move. One cannot conquer the Mythical Man-Month because it is just that - mythical and imaginary.
Tonight's reading was quite interesting to say the least. It touched on many different aspects of the development life cycle of a programming project. For one, when a project is falling behind schedule, a natural reaction is to add more man-power in order to get it back on track. However, adding men to the project, in fact, has the opposite effect. Time for training the newcomers in the language, environment, and the current system design must be accounted for. Then there's the time it takes to devise a new delegation of the tasks involved in the project, so that the new people have something to do. And finally, you must include the time it takes to re-write the schedule with the new man-power included in the projection. So overall, the trade-off for adding more people to a project to get the job done faster is negative.
I like the idea that the author credited Harlan Mills for: making programming teams that resemble surgical teams. Several small groups of people working on the same project, or component of a project, with each member having a very specific role within the group that supports the effort of the group as a whole. Only one or two main programmers and designers, and several other supporting roles are needed. This idea of a surgical team reminded me of a pair-programming video that Dr. Starr showed our CSCI 230 class several semesters ago. It stated that using pair-programming increases productivity, quality of code, and the learning and enjoyment of the programmers involved, and although I cannot say I've had much experience with pair-programming, I am inclined to agree heavily.
Another part of this article was talking about how most programming projects are divided among developers, and each developer is also in charge of the design of his or her specific component. The author says that this is dangerous because the overall design of the system is no longer unified, and can have many parts that, while they may be well designed in themselves, are not designed to work with the other components as well. Therefore, again, the solution is to divide the design of the project from the implementation of the project. Hence where the term, code monkey, comes from. A small team of the "creative" and "elite" programmers get to have all the fun designing the system, then pass off the frustrating part of implementation to the "lesser" programmers. This idea in itself seems backwards to me as well. Why would you want the elite programmers to just design it, if they aren't going to the skills that classify them as "elite" to actually code it? Even though it may be well designed, the code would not be as efficient and reliable as it would had the elite programmers been the ones coding it in the first place. Perhaps I'm thinking about it in the wrong way. The author did say that this team architechture should only be used for large scale programming projects.
I enjoyed this read a lot and have definitely taken away from it, at the very least, that adding more people to a project that is running behind schedule is the wrong move. One cannot conquer the Mythical Man-Month because it is just that - mythical and imaginary.
Homework #8 - 9/10 (Makeup)
Response to The Future of Programming:
I personally don't see this getting very far. They advertise programming from the browser and therefore being able to program on any device that can run a browser, or more specifically, Chrome. Sure, programming on Chromebooks might be useful, but there's no real difference to doing that compared to programming on any other conventional laptop. The other possibility that they say opens up is that you'd be able to program on your iPad! Are you kidding? I can't think of anything worse than trying to write a program on any sort of touchscreen device - unless - we're talking about drag and drop snippets of code to create a larger program, Which is what I think is the real future of programming. Before I talk about that, I want to finish with Cloud9, though. One of their other main selling points is that you can "zoom" in and out of your code to have a better idea of where you are within it. This is pretty cool, but it isn't novel by any means. It is probably something that will be a standard of any future IDE's that come out. Ian showed me the Sublime text editor, which I have fallen in love with this semester. It more or less does the same thing. Another selling point of Cloud9 would be to access your code anywhere online, but again, this isn't a very novel technology, nor does it really meet any new needs. Over the semester, we've learned how to use version control repository programs, such as Subversion, and Git. These programs, in my opinion, provide the same services that Cloud9 does and more. Not only can you save your code online, and re-download it from any other machine (although perhaps not as easily), but you can also revert to older versions of the code if you accidentally broke something, then committed it to the repository. In the end, Cloud9 to me is mainly just a kind of over-the-top showcase of what an IDE should be. It looks pretty, but doesn't provide any new functionality that previous IDEs haven't before.
Now, where I think the real future of programming is headed is graphical programming interfaces. Much like how developing websites has become nowadays compared to when the world wide web still had its baby teeth. Before, you had to know HTML and even then, you had to spend a lot of time and effort to make a website that looked more than pathetic. Nowadays, you click on a theme, and boom, it formats your entire page for you. Adding pictures and tables? No problem, just click here. Don't like it over there? No problem, just drag it over here. The most comparable thing that is in use today that I can envision the future of programming to be like, is developing apps for Android. The Android SDK implements drag-and-drop programming with certain elements, such as radio buttons, check-boxes, and lists. All you have to do is click which type you want to insert and its done, no writing Java code necessary. The other thing that leads me to believe that this is the future of programming is how much more abstracted our languages have gotten. If you think about the progression throughout the decades it makes a lot of sense. Machine language deals with literal machine hardware instructions, with C, you can directly access memory elements at a specified location, then you move to Python or other similar languages, where you can dynamically specify the type of a variable, it is no longer static. It won't be long before languages are abstracted further to be able to accept "ideas" of how the program should work as the input, and the environment or language will translate it further for you as necessary. It's only a small step from this to graphical programming, in my opinion.
I personally don't see this getting very far. They advertise programming from the browser and therefore being able to program on any device that can run a browser, or more specifically, Chrome. Sure, programming on Chromebooks might be useful, but there's no real difference to doing that compared to programming on any other conventional laptop. The other possibility that they say opens up is that you'd be able to program on your iPad! Are you kidding? I can't think of anything worse than trying to write a program on any sort of touchscreen device - unless - we're talking about drag and drop snippets of code to create a larger program, Which is what I think is the real future of programming. Before I talk about that, I want to finish with Cloud9, though. One of their other main selling points is that you can "zoom" in and out of your code to have a better idea of where you are within it. This is pretty cool, but it isn't novel by any means. It is probably something that will be a standard of any future IDE's that come out. Ian showed me the Sublime text editor, which I have fallen in love with this semester. It more or less does the same thing. Another selling point of Cloud9 would be to access your code anywhere online, but again, this isn't a very novel technology, nor does it really meet any new needs. Over the semester, we've learned how to use version control repository programs, such as Subversion, and Git. These programs, in my opinion, provide the same services that Cloud9 does and more. Not only can you save your code online, and re-download it from any other machine (although perhaps not as easily), but you can also revert to older versions of the code if you accidentally broke something, then committed it to the repository. In the end, Cloud9 to me is mainly just a kind of over-the-top showcase of what an IDE should be. It looks pretty, but doesn't provide any new functionality that previous IDEs haven't before.
Now, where I think the real future of programming is headed is graphical programming interfaces. Much like how developing websites has become nowadays compared to when the world wide web still had its baby teeth. Before, you had to know HTML and even then, you had to spend a lot of time and effort to make a website that looked more than pathetic. Nowadays, you click on a theme, and boom, it formats your entire page for you. Adding pictures and tables? No problem, just click here. Don't like it over there? No problem, just drag it over here. The most comparable thing that is in use today that I can envision the future of programming to be like, is developing apps for Android. The Android SDK implements drag-and-drop programming with certain elements, such as radio buttons, check-boxes, and lists. All you have to do is click which type you want to insert and its done, no writing Java code necessary. The other thing that leads me to believe that this is the future of programming is how much more abstracted our languages have gotten. If you think about the progression throughout the decades it makes a lot of sense. Machine language deals with literal machine hardware instructions, with C, you can directly access memory elements at a specified location, then you move to Python or other similar languages, where you can dynamically specify the type of a variable, it is no longer static. It won't be long before languages are abstracted further to be able to accept "ideas" of how the program should work as the input, and the environment or language will translate it further for you as necessary. It's only a small step from this to graphical programming, in my opinion.
Homework #7 - 9/5 (Makeup)
Response to readings:
I was already familiar with the first reading assigned for today, The Magical Number Seven. Dr. Manaris spoke of it often in the classes I took with him. I remember him saying, "If you have more than 7, plus or minus 2, lines of code in your method, you are probably doing it wrong! Split it up into multiple methods!" Since learning of it, I find myself thinking of it every now and then in everyday life. For example, if I'm to grocery shopping, I won't even try to remember the list of things to get in my head if it's around that magical 7 ± 2 number. Sometimes I wonder if computer science students from other schools learn of this principle. I don't spend that much time reading other people's code, but I wonder if I did, how much of it would I find that could be broken up as Dr. Manaris said?
The second reading for today was a study done on wireless tire pressure monitor systems (TPMS) used in passenger vehicles today. These little devices are very nifty in that they alert you of low tire pressure without you having to consistently check it yourself. They're really a neat little invention - the scary part of them that this paper reveals, is that so far, there has been little to no security measures taken to prevent 1 - the eavesdropping of signals and 2 - differentiate between fake and legitimate signal packets. The engine's computer failed in several respects in that there were several ways to tell that a packet was false. For one, you could send a packet to the ECU stating that the tire pressure is low, but at the same time, give a pressure value that is acceptable. This is a little surprising that software was developed to alert for low tire pressure, but it can't even tell what low vs normal tire pressure is! Another flaw in the ECU is that it doesn't validate authenticate messages. In other words, one could continuously bombard the ECU with signals with mixed messages until finally one gets through that would turn the light on. At first, finding out that this system wasn't very secure didn't seem like that big of a deal, but imagine that you are travelling long distance at night on a small two-lane interstate. If there are thieves following in a car behind you that have this signal replicating device, they could send a packet to your car causing the low tire pressure light to become illuminated. Now personally, if my tires were a little low on pressure, I'd probably just wait until I got to the next rest stop or gas station, but there are probably some people out there who would pull off the side of the road and bust out their little 12V air pump - game over! I can't imagine that this issue will go unchecked as the technology further develops. Eventually there will be some industry standard of security measures to be taken in terms of TPM systems.
The final reading for the night was planning for failure in the coming (or perhaps already here!) age of cloud computing. I really enjoyed this article, it read as if it were advice from an older brother or something. The author gives great advice on how to handle failure in general. When your service fails, what do you do? Does your browser display an http error, or does the application crash and freeze the browser? Do you have a backup page to display in the event of a failure? Some of this advice seemed like common since, but some of it not so much. For example, I don't know if I would have thought to use request buffering to reduce bottlenecks in the system, or to include little "retry" segments into the parts of my code that rely on retrieving data from a foreign source. In the case the source has a hiccup, it might not serve the data when first requested, but the retry statement would allow it to get the data the second time instead of passing an error to the client application. I think I'll save this article to my bookmarks as all-around good programming advice and practices to employ when I'm employed.
I was already familiar with the first reading assigned for today, The Magical Number Seven. Dr. Manaris spoke of it often in the classes I took with him. I remember him saying, "If you have more than 7, plus or minus 2, lines of code in your method, you are probably doing it wrong! Split it up into multiple methods!" Since learning of it, I find myself thinking of it every now and then in everyday life. For example, if I'm to grocery shopping, I won't even try to remember the list of things to get in my head if it's around that magical 7 ± 2 number. Sometimes I wonder if computer science students from other schools learn of this principle. I don't spend that much time reading other people's code, but I wonder if I did, how much of it would I find that could be broken up as Dr. Manaris said?
The second reading for today was a study done on wireless tire pressure monitor systems (TPMS) used in passenger vehicles today. These little devices are very nifty in that they alert you of low tire pressure without you having to consistently check it yourself. They're really a neat little invention - the scary part of them that this paper reveals, is that so far, there has been little to no security measures taken to prevent 1 - the eavesdropping of signals and 2 - differentiate between fake and legitimate signal packets. The engine's computer failed in several respects in that there were several ways to tell that a packet was false. For one, you could send a packet to the ECU stating that the tire pressure is low, but at the same time, give a pressure value that is acceptable. This is a little surprising that software was developed to alert for low tire pressure, but it can't even tell what low vs normal tire pressure is! Another flaw in the ECU is that it doesn't validate authenticate messages. In other words, one could continuously bombard the ECU with signals with mixed messages until finally one gets through that would turn the light on. At first, finding out that this system wasn't very secure didn't seem like that big of a deal, but imagine that you are travelling long distance at night on a small two-lane interstate. If there are thieves following in a car behind you that have this signal replicating device, they could send a packet to your car causing the low tire pressure light to become illuminated. Now personally, if my tires were a little low on pressure, I'd probably just wait until I got to the next rest stop or gas station, but there are probably some people out there who would pull off the side of the road and bust out their little 12V air pump - game over! I can't imagine that this issue will go unchecked as the technology further develops. Eventually there will be some industry standard of security measures to be taken in terms of TPM systems.
The final reading for the night was planning for failure in the coming (or perhaps already here!) age of cloud computing. I really enjoyed this article, it read as if it were advice from an older brother or something. The author gives great advice on how to handle failure in general. When your service fails, what do you do? Does your browser display an http error, or does the application crash and freeze the browser? Do you have a backup page to display in the event of a failure? Some of this advice seemed like common since, but some of it not so much. For example, I don't know if I would have thought to use request buffering to reduce bottlenecks in the system, or to include little "retry" segments into the parts of my code that rely on retrieving data from a foreign source. In the case the source has a hiccup, it might not serve the data when first requested, but the retry statement would allow it to get the data the second time instead of passing an error to the client application. I think I'll save this article to my bookmarks as all-around good programming advice and practices to employ when I'm employed.
Subscribe to:
Posts (Atom)