3081 Blogging Assignments

                Testing is a very important and necessary part of software development. Even though many people consider it to be an essential part of the process of development, testing is often overlooked. This is mainly due to the fact that testing is generally considered boring and tedious. However, there are many tools to help reduce the pain that is normally included with testing. Some tools help test individual units (or parts) of a project, cxxTest is one such tool. There are also debuggers, such as gdb that may aid in the process of fixing the errors found while testing.

                Unit testing, as it is called, is one popular way to test software. Unit testing infers that each "unit" or part of the source code is tested individually. Normally, unit testing is an easy form of testing when the object oriented programing discipline is in use. When many "objects" exist, it is easy to test these parts individually. Another form of testing (referred to as regression testing), tests older parts of a program after a new part has been introduced. When new features of a program are introduced, they sometimes conflict with previous functions. Regression testing tests to ensure new parts of a program comply with the other, older parts of a program.

                CxxTest is a unit testing framework that attempts to reduce the amount of tedious work needed to properly test a program. It does this through the use of automation. CxxTest uses an automation script to generate an intricate set of tests from the simple header file written by the tester. The automation script makes the time required to write tests much smaller, this is due to the fact that the automation script deals with the complex requirements to write an effective test. The user is able to write the tests in a rather simple format.

                There is a slight learning curve for the proper use of cxxTest. However, once you are able to utilize it properly, the time required for testing will be greatly decreased. One thing that I would have liked to know, is the fact that cxxTest doesn't rely upon shared libraries.  This means the files required for testing are highly portable, and can be moved around from directory to directory with no problems. One just has to make sure the file path of the automation script in the makefile is correct.

                Testing, an often overlooked part of the development process, is a very important process. Many people delay testing their project until they can no longer avoid it; by this time, it is often too late to easily fix an error. Testing should be involved at every step of the development processes, enough to the point that it becomes second nature.

What is Subversion and Source Control?

    Source control refers to the management of the changes made to program files and other aspects of software development. Source control also allows a team of people to develop software more efficiently. It allows the team members to work on different aspects of a project at the same time with minimal interference. Source control also normally includes references to revisions of the source code, keeping track of the differences between the versions. It also deals with source tags (normally, tags refer to major milestones in the project), and branches (different versions) of the source code.
Subversion, abbreviated SVN, is a source control program that automates the process of controlling revisions of source code and other such documents. Subversion is freely available from the developing company, Apache. Subversion stores projects in a password-protected repository on-line, allowing access from multiple computers. The repository used for this class is stored on the University's servers; however, some companies (ex. Google) host servers available to the public.

Why Source Control?

    Source control allows the development of large scale projects to proceed in a much more efficient manner. Multiple people can be working on a project simultaneously with little or no interference from fellow team members. It also allows for a project-wide undo button. One can revert back to an earlier version if needed. As mentioned before, tags and branches of source code can be made as well. Branches can be useful for different builds of the same program (ex. 32 and 64 bit versions). Tags are equally useful when it comes to keeping track of major milestones of a project (ex. V1.0 or v1.1).

Tips Regarding Source Control and Subversion:

    Since the beginning of the semester, the learning curve I've been following is somewhat slow. One of the most major things I wish I didn't learn the hard way pertains to the copying and moving of file directories. Subversion creates a hidden ".svn/" folder in every directory that is in the repository. So, simply copying and pasting folders from place to place can cause some serious pain down the road. The major problem I experienced occurred when I attempted to revert back to our first iteration. I naively deleted the source directory and replaced it with the first iteration. When it came time to commit the changes for the next lab, I committed the changes and they appeared in our tag directory (instead of the original source directory).
    Before I realized copying folders was a bad idea, I ran across the problem stating that the folder I was trying to commit changes to wasn't in source control yet (even though it appeared in the repository). I found that the most fool-proof way around this was to checkout a new copy of the project, and submitting the changes from that copy. I believe the problem referred to the fact that the repository had a folder named the same as mine but Subversion didn't recognize it as the same folder. So, replacing the files one-by-one in a freshly checked out copy seems to work the best. I'm sure there is a better way to fix that problem, I would love to know how to since I've run into the problem a few times now. However, I only seem to run into the problem when I'm running close to a deadline, so I haven't had time to figure it out by myself.

    My overall experiences with source control and Subversion have been somewhat successful. It was a slow learning curve at first, and it lead to a few hiccups here and there. But, once I was able to get the knack of things, I became rather efficient with Subversion. It's now hard to imagine making a project like this without source control. I have a feeling source control will be a tool I utilize through the rest of my career.

      Working in a group has worked very well for me this year. Being able to split up some of the work has made my life much easier. I have had a few problems as well, figuring out the logistics of actually working on the project has been somewhat complicated. Even though we have the ability to work separately (using subversion), we have found ourselves working together on a single computer (which is rather inefficient). So, as I have learned, working in groups has both its upsides and downsides.

Benefits:
      Being able to split up some of the work in the development process has made life much easier. As with most projects, there's at least some amount of tedious work. In the case of Iteration 1 for our project, formatting all the regular expressions was slow but mostly easy work. Being able to evenly split that work up made the development process go by much faster.

      As for dealing with the complex parts of the development, being able to brainstorm with my project partner is nearly invaluable. My partner thinks somewhat differently than I do, so being able to bombard each other with ideas normally leads to some good results. In the case of Iteration 1, we had a hard time making a regular expression to recognize line comments. Being able to bounce different ideas off of each other, made the trial and error process go much faster.

      Having a group of people also allows for a wider range of resources. My partner has taken different Computer Science courses than I have, so he was able to reference different past projects than mine to find ideas for our current project. We were also able to network with more people, to discuss and ask general questions about the project with a wider range of people.

Challenges:
      Along with all the benefits, there is also the inevitability of encountering challenges. I haven't had many problems this semester with group work. Other semesters, I haven't been quite as lucky. In the first Computer Science course I took, my lab partner wasn't much help. He would tell me every time I asked him to do something that he couldn't figure it out. Turns out, he wasn't even trying. He didn't even know how to run the programs we were writing. I ended up doing most, if not all, the work. However, since we were working as a group, he ended up getting the same grade as I did. So, accountability in a group isn't the easiest to ensure.

      Also, in some cases, a group partner of mine would get most (if not all) of a project done before I had the time to look at it. Since I wasn't able to help in the development process, I didn't understand the program as much as I had hoped. This would then feel as if I didn't know enough to continue on to the next project.

      So, to compensate for the challenges, I normally try to make sure my partner(s) are holding up their end. Using Subversion has helped me with that a lot. Checking the log and being able to see the differences between the versions makes it very easy to account for the work being done. I also try to be all around more proactive on the projects, so I don't get left behind.

      In most cases, I enjoy working in groups. Being able to work in groups is a requirement for many computer science related careers. Knowing that I'll be able to enjoy working it in a career as much as I do here makes me very sure I chose the right career path for me.

This class has been quite interesting to me so far. I feel that, by the time this class has ended, I will be much more proficient in software design. Reading through the expected course outcomes, I find a lot of topics that I don't know the first thing about. There are also a few topics I feel I grasp quite well.

The few things I do grasp quite well include "writing loops, and code in general, that are easy to understand". I learned to write clear and precise code the hard way a few times in CSci 1901. I wrote some really ugly looking stuff in that class. Looking back on some of the different assignments now, I can't even tell what I was trying to do. My grade suffered a few times due to that. So, for the most part, I am now very careful to write code that is readable and easy to understand.

Hand in hand with writing clear code, I think "writing effective comments" is an essential part of making readable code. Sometimes, no matter how well you design, things just get hard to understand when working with complex data structures or really in-depth algorithms. That's when effective commenting can come into play. I used to have a problem with over-commenting my code. I specifically remember typing "Increment 'i' by one" in one of my 1901 assignments. I don't think my grade ever suffered from that; but, I now understand that the target audience of my comments should know what i++ means.

While reading through the expected course outcomes list, I realized that there is a lot I have to learn. One of the topics I'm most excited to learn about is "integrated development environments". I have messed around with a few different IDE's, but have never really used one for actual work. I started off this semester thinking I could teach myself how to use "Eclipse" to write the C/C++ for this course (and others). I have since come under the impression that Eclipse is more for Java development than C/C++. If anyone decides to comment on this blog (and knows a thing or two about IDE's), I would greatly appreciate a push in the right direction.

I am also excited to learn about "designing a useful class hierarchy" and "modular software design". I feel that the other computer science classes I have taken have touched on this topic slightly, but never covered it with great depth. Its obvious that most programs aren't designed in one big file. So, it would be useful to know how and why real-world applications get the structure they have.

Other things in the list of topics, such as UML and context free grammars, I don't know the first thing about. I hadn't even heard of UML or context free grammar before attending this class. I am somewhat excited to learn about these topics, I'm also a bit worried. Having the book "UML Distilled" leads me to expect we'll cover the topic thoroughly, and I don't know the first thing about it.

All in all, I'm very excited to work my way through this class. Learning about all these topics in one semester won't be an easy ordeal. By the time this class is done, I expect that my opinions and skills pertaining to program design and development will be greatly changed. I believe that having the core skills taught in this class will be an invaluable tool for my future classes and careers.