I am sure all of us have had to write a small program yourself as a homework assignment, maybe it was a program that sorts a list of integers. I bet it started out as you coding the small program in the best way you can. Now you want to test it to make sure you are getting the intended output, maybe you add a value to your list and make sure it gets sorted in the right place, or you delete a few values and then test your program to make sure they are gone and the remaining list is sorted correctly. If everything looks good you submit it to be graded. The tests you preformed were unit tests.

FOLDOC (the Free On-Line Dictionary Of Computing) defines unit testing as, "The type of testing where a developer (usually the one who wrote the code) proves that a code module (the "unit") meets its requirements." Meeting its requirements means that the software behaves as intended and a unit can be thought of as the smallest testable part of an application. In object-oriented programming languages, like C++, a unit is usually an interface, such as a class. The whole goal behind unit testing is to isolate each part of the program and check that each individual part is correct. The unit test itself is actually a strict statement that the unit must satisfy. Unit tests are used to find problems early in the development cycle, since that is much more convenient than having to go back and find the bug after the application was finished.

                The actual testing can be done manually like my first example but is best done with a testing framework such as CxxTest for C++. Once a framework is in place and you know how to use it, adding unit tests becomes relatively easy. Running unit tests was indispensable for our last project, Iteration 2. My partner and I had unknowingly written the string regex incorrectly. We forgot to put a "." in the string regex and therefore our testing statement,

TS_ASSERT ( p.parse( readFile("../samples/forest_loss_v2.dsl")).ok ) ;

always failed when it tried to read "myData.dat" in the .dsl file. Without unit testing we never would have known the bug, all other tests we have ever run always worked fine. Sometimes you just don't know what input to test and this is where unit testing really pays off since it can be used to test all kinds of input, even whole files. The biggest challenge I have encountered with unit testing is just getting used to the framework and knowing what tests to run. My advice to someone about to get into unit testing with CxxTest or any other testing framework would be to not give up when you get frustrated when your tests fail. It is going to happen, just stick with it and use simple tests first, then work your way up to whole files. Believe me, you and your code will be thankful when finally, all your tests pass.

Subversion, when used correctly, is an extremely useful tool in organizing different versions of files and programs in a single area called a repository. You can think of this repository as cloud storage, it's not specifically located on one single computer but is being hosted somewhere else and you can access it remotely. However the key difference that sets Subversion and all other version control systems (or vcs) apart from simple cloud storage is their ability to keep track of version numbers of every file you update. Each vcs treats this a little differently, some put version numbers on each individual file while others keep track of a global version number, but each one will increment this version number every time a file is updated. This sounds, and actually is, quite helpful when developing a program. Anytime you want to go back to a previous version of a file or program you can have your preferred vcs give you that previous version of that program. Another huge advantage to working with vcs is the ability to have multiple people checkout, or download, a copy of a particular file, modify the file in any way it needs to and then upload it back into the repository. Normally when you think about multiple people uploading the same file one after the other each person would overwrite the previous version and the last one to upload their file gets to keep their changes. It doesn't work that way in vcs. Every time you try to upload a file to your repository it will check to see if the repository copy of the file has been updated since your last upload. If it has, Subversion can show you the changes between the newer repository copy and your modified local copy. This is an invaluable resource when dealing with multiple programmers working on the same file. Everyone's changes can be seen, merged together and a final complete version can be put together for everyone to download again. This all sounds wonderful but isn't as easy as it sounds. The main problem is being able to do all of these things correctly and efficiently. I personally have run into two major problems while using Subversion for our class.

I live far enough away from campus that I do not want to come to school unless I am already there for classes. So on the weekends when I want to work on this class's homework I do not have access to the schools computers. Subversion is very helpful here in the fact that you are able to connect to your repository over the internet, for our class I use a SSH client on my home computer. However, connecting and uploading to your repository doesn't always go as planned. I had this affect me the first time we needed to upload files for blog assignments. We needed to upload two files for that assignment: blog_url.txt and blog_1.pf, sounds easy enough right? Here is what happened, I uploaded blog_url.txt no problem, now I wanted to upload blog_1.pdf and the connection froze.  I closed the connection, re-logged in and tried again, same thing, a frozen connection. No matter how many times I tried, it always froze. I tried uploading a blog_1.doc and blog_1.txt both worked just fine of course, only the format that I actually needed to upload would make it freeze. After a long series of frustrating failures I searched for a different SSH client and choose a new one. Guess what happened, this time it finally worked! As a warning to future users of svn or other revision control systems, make sure you have a reliable way to connect to your repository whenever you need to use a remote connection.

The second problem I had involved my partner too. We were trying to update our local workspace to match the group repository. When we would try the 'svn update' command an error message said "Unversioned file of the same name already exists". Being svn beginners we asked our TA, Robert Edge, what is going on and how to fix it. He tried to work his magic but wasn't able to solve the conflict. Everything from explicitly stating the conflict is resolved to deleting the file in question did not work. In the end we actually had to just checkout a whole new, fresh copy of our group repository. For us this wasn't a big problem but what if your repository or the files in it were quite large.  This could be potentially a huge problem to try to resolve in a corporation using Subversion.

So, in the end, would I recommend the use of Subversion or other vcs? Yes, because the benefits of version numbers and a single place where all your project files are located that can be accessed remotely outweighs the problems that I have encountered. I have encountered each of these problems only once and, although they were both very frustrating, after they were fixed things went smoothly and everyone was happy again.

Let me start off by saying I really enjoy working with someone else in this class. My partner for our WTF project is Zhouyun (Joseph) Feng. He has been amazingly helpful for the iterations and labs. I believe that the benefits of working in a group far out ways the challenges that can arise. I will explain three benefits and two challenges that I have noticed so far by working with Joseph.

The first and foremost benefit of working in groups is exactly like the old adage says, "Two heads are better than one." If you don't know C pointers very well maybe your partner does, or maybe you have previous experience with C arrays so you take over that section of the program. The whole idea of working in a group is collaboration, working together to finish the project, and having someone there with you who wants to help complete the work is a very reassuring feeling.

I bet everyone in our class always writes code that hardly ever has any bugs in it. Yeah right! Just a tiny mistake can stop your entire program from compiling correctly or returning the results you expected. Going through code together with someone else, instead of just yourself, makes it much more likely to catch that nasty bug lurking in your code lines. I am sure Joseph and I will continue to do this for future project iterations.

A lot of us programmers don't mind sitting in front of a computer all day long, am I right? Working with a partner gives us a chance for interaction and makes assignments more fun and realistic. Real world programming is done in teams and this is good experience for when we go out into the world and look for internships and careers. Every one of us in a group needs to remember to work hard with your partner and also have a good time doing it.

I feel that the biggest challenge so far has been figuring out our time schedule. I am very busy this semester and I am still trying to find a balance between work and school that fits well for me. So finding a time when we are both available to work together has been tough. I needed to take more time off from work so that I can be free more often. With my new schedule, hopefully we can get together more frequently for iteration two and beyond.

Another challenge that can occur is differences in each person's style of writing code; however, this hasn't been a big problem yet. Just like every person can use different words to form a sentence with the same meaning, each person can use different approaches to solve programming problems. For example you might want to use a for loop for a certain problem but your partner wants to use a while loop. In the end they do the same thing, just different wording. We all need to remember to compromise with our partners if there is a disagreement about which direction to go in.

In conclusion, I find it highly beneficial to work with a partner for this class or any other classes in the future. The benefits of having someone team up with you should always be greater than the obstacles you need to overcome. Work with your partner, have fun, get to know each other, interact, and collaborate. Since we are all in groups together, no one should feel alone. And who knows, you just might meet a really good friend.

In this blog entry I will discuss two things from our intended learning outcomes that I know well and have previous experience with, and two things that I hope to learn and improve on.

The first topic I feel I know well is "writing effective comments".  Now I am sure many of you who read this will laugh at me for choosing this topic, seeing as how basic it is, but it is also an important one. Writing meaningful comments is just the same as showing your work on a math test; the teacher grading your test wants to see how you got your answers. Or in our case the person examining your source code wants to know how your program works or what each part does. Without comments a lot of your codes meaning can be lost, level with me here, sometimes even you can forget why you put a while loop here or what this variable represents. Comments are the only way of programmers showing their work. No matter what language I am programming in, C or Java are the only ones I've learned that I find useful, I always write comments describing complex areas in my code. If I ever need to look back on an old assignment those comments can be lifesavers if you forgot how your code came together. That is why I feel it is so important to write effective comments. Everyone needs to remember, it doesn't matter if you got all the right answers on your math test if the teacher doesn't know how you got them. This topic actually goes along well with the next area I will discuss.

The second topic I feel I know well is "writing loops, and code in general, that are easy to understand". Nothing is worse than looking at some source code that makes no sense to your and has no comments or documentation. It might as well have been written in Greek! I know my next example is extreme, but it really does fit with this topic. Can anyone tell me what this C program does?

#include <stdio.h>
main(int t,char _,char *a)
{
return!0<t?t<3?main(-79,-13,a+main(-87,1-_,main(-86, 0, a+1 )+a)):1,t<_?main(t+1, _, a ):3,main ( -94, -27+t, a )&&t== 2 ?_<13 ?main ( 2, _+1, "%s %d %d\n" ):9:16:t<0?t<-72?main(_,t,"@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l,+,/n{n+\,/+#n+,/#;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l q#'+d'K#!/\+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw' i;# ){n\l]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#\ n'wk nw'iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c \;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;\#'rdq#w! nr'/ ') }+}{rl#'{n' ')# }'+}##(!!/") :t<-50?_==*a?putchar(a[31]):main(-65,_,a+1):main((*a == '/')+t,_,a+1 ):0<t?main ( 2, 2 , "%s"):*a=='/'||main(0,main(-61,*a, "!ek;dc \i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry"),a+1);
}
Feel free to check out the original posting at: http://www.funenclave.com/reality-bites/most-confusing-c-code-7690.html

I bet no one can follow it; it uses a lot of recursive calls and pointers. In the end all it does is print out the lyrics to "The Twelve Days of Christmas". This code actually won the International obfuscated C code contest. Getting back on track to the topic, I always write loops and code that I understand and write comments on anything I might find confusing or don't want to forget. If you can't understand your own code no one else will either. In a very similar idea to Occam's razor, "the simplest answer is most often the correct answer" whenever possible write code that is simple and easy to follow.

The first topic I feel I don't know well is "tools for automation, scripting languages and build tools". Throughout my few short years of learning programming languages none of my classes have had me use a software automation tool. However, they sound very useful and interesting, things like test automation, build automation, and documentation generators would help a programmer speed up the process of designing and producing applications. One of my questions about this topic would be how often are these automation tools used in "real world" business style programming and how much is done manually? I am always very interested in what kind of tools are out there to help us become better programmers. I hope this class will show us these kinds of tools and how useful they can be.

The second topic I feel I don't know well is more of a general objective, "be able to program at an intermediate level in C++". I am sure many of my fellow students will feel the same way as me here, unless perhaps you already know C++. I want to learn C++ and be able to create useful applications with it. These kinds of skills also need to be transferable to any future internship I would be going into. At the end of this class and the end of this semester, I want to have confidence in my programming skills and understanding.