Blog 4 - Testing

Apparently we did learn a notion earlier about "writing test cases before coding is better" because not only does it help us find bugs during coding progress, it does not take much time either to write them in advance. I personally think that if you can write some good test cases before even you start on coding, you can get a better idea of what kind of result that you are expecting and thus make you to think more about the requirements as they are not always explicit or easy to comprehend, not to mention that they tend to change after a certain amount of time.

As for its glorious definition, unit testing is a piece of code that exercises a very small, specific area of functionality of the code being tested. For example, I believe almost everyone of us had encountered the awful segmentation fault compiling errors most of the time. And what I usually did to find out which part went wrong was to merely locate several simple "printf" statements in different segments of the main code and try to trace it down to figure out at which point the segmentation fault begins. From this you would be certain that those codes before that point were "safe" - they were free from syntactical errors and were compiled successfully. This helps you to determine whether your functions work as intended. This is especially helpful when you want to find bugs that embed themselves somewhere in a loop condition. If something goes wrong, all you have to do is to locate several "printf" statements in that loop and compile the code and check if some of the loop iterations failed.

CxxTest is just a simple testing framework designed specifically for C++. In iteration 2, the test cases that we had depend solely on this framework to test our code functionality. Although I personally was kinda clueless about what's going on with all the files in this CxxTest directory, I was certain that this testing framework will come in handy after we build the linked list of tokens and want to check if the linked list is successfully built and not broken somewhere in between the token nodes. Had we not introduced to this, I assume it would have been painful to check that, especially when we were also supposed to deal with the token terminals and token lexemes in each token nodes, not just the linked list structure. So what we had to do in order to complete for iteration 2 was to feed the test cases with corresponding input and make sure all of them pass. Though getting a bunch of failed test cases error might not be fun, it really helps us to know which part of our code was not working and helped us to think even further about why different implementations yield different test cases error. And we can compare and check and edit accordingly.

Blog 3 - Subversion and Source Control

To be honest, I have no clue with what version control software is before taking this class. Indeed I am glad to have Subversion this great tool introduced to us all in this class because not only it provides great functionality to our iterations/projects, it also broadens my way of thinking how technology advancement can be so rapid.


Version control/source control is a system specifically designed for controlled access, information changes and storage of code and documents for software developers who work in a team. Subversion(svn) is exactly an instance of version control software. What I think is important to share with you readers are the advantages offered by Subversion.


Apparently the most significant advantage that I figured is that you can submit your updated files to a repository(online data warehouse) via a terminal. I still remember those days which I had to keep emailing myself the updates of my codes over and over again. With Subversion, not only you can store your data/code online, there is this project-wide undo button that you can always roll back to where you previously were to get rid of a big mistake. This is possible because Subversion keeps a record of changes made over time and thus you can easily check out the codes you submitted at a specific time(although I'm still not very sure how to do this).

Other than that, Subversion also allows multiple software developers in a team to work on the same project in a controlled and more convenient way. Say my partner just did some changes on the code and tagged these changes as "Revision #x". I can easily check out the corresponding tagged, revised codes and add/merge my code with his/hers. In case I somehow messed up or maybe even accidentally deleted my local copy of the code, I've always got a back up code stored securely at Subversion. Furthermore, the log function is very useful too. It can display the history of changes made to a file or directory associated with a time stamp. In this way, it becomes possible and easier for us to track down who has made the changes or possibly broken the code at a certain period. With regard to iterations grading in this class, this log function helps to avoid any unwanted possible arguments made between the TAs and us if we have issue with our code submission. This is because every submission had been timestamped and the TAs can easily pull out what we'd done in the latest submission before the due time and just grade that particular submission accordingly. Well, given that you submitted your code correctly.

Blog 2 - Working in Groups

Hmm it seems like a good idea to have given a chance to write a blog on issues about working in a group because I've got a lot to say. To be honest, I was not able to complete iteration 1 until the past Sunday night (October 9). Apparently there were a couple of obstacles getting in my way while I was working with the project and at the same time, I was defeated by time. In fact I only got my codes working like 10 minutes before the due time on Thursday night and yeah I am serious. Yet I was only able to get one of the sample test files working. Now I'm hoping to get at least some partial credits for my iteration 1. God bless me. 

So you must be wondering why I'm such a loser. Well I'd say there were two prominent reasons. First, I wasn't able to communicate well with my partner. Second, time management crisis. Should I figure out effective methods to tackle these challenges for the next couple iterations, I'd be certain to say I would eventually get something out of this class as I did get to learn something useful. 

Now the story begins. Ever since I got zero reply from my partner for about a week after I sent him a couple of emails trying to figure out how to split the workload, I knew I was doomed. My partner was being completely unresponsive and reckless. Just try to imagine a situation in which you'd sent more than 10 emails trying to get him/her back to working on the iteration(well in fact I wasn't sure if he/she did even start working on it) and yet you only got one reply after all. After that, I didn't get any response from him anymore until the official due date. By all means I didn't act harsh and I still emailed him/her pretty much like everyday just hoping to get everything sorted out. And NO, there was absolutely nothing personal going on between me and him/her. Actually I was very clueless with the reason that happened, too. To be honest, I must admit that I am not good in programming so I was trying organize to-do-things in a timely manner but little did I know I would end up like that. Later I figured the fact that I would be better off to get the iteration started all by myself and wait for something to happen as something extra/bonus, given that "something" ever happens. 


Enough complaints. I'd talk a little about time management issue. I'm sure there are people who are taking 4061 and 3081 simultaneously at the same time in this semester and I suppose we all are mentally well prepared to cope with both of these programming intensive classes. Heaven yeah both of these projects were due one day apart from another in last week and I'm certain everyone had got their schedule planned well ahead to spare time on each of those. In fact I didn't start working on iteration 1 until one week before the due date (I know we had been given two weeks to work on it) and the stats is I spent 30+ hours to get it done after working on it 8 days in a row. Based on this analysis, I now realize that I'd now overcome the fear of "i-am-not-sure-if-i-can-do-it" and that I need to get the next couple iterations started as soon as the specs are up.   


I was happy yet overwhelmed by the feeling of accomplishing iteration 1 last night. The contentment is more than enough to hold me back from worrying about the grade. Moreover, I'd say the professors and the TAs are very helpful and their email response is so immediate and is something that I'd never expected before. Furthermore, the forum is very helpful too so be sure to check it everyday especially before you start working on your code; you get to avoid mistakes that others had encountered. For example, I spent more than one hour thinking of how to write a regex for lineComment but only until later I realized there were actually some hints on the forum! 


Despite these obstacles, it was certainly an interesting experience in my college life after all.

Blog 1

One of the topics that I think I have reasonably known well is writing effective comments. From my previous programming experience, I had got to know that comments are essential to let first-time readers to know what is going on with your code and it is especially important if you're working on the projects in a group. Provided that you have a bunch of well-explained comments, you would be able to communicate with your partner(s) better as  coding progresses.

Another topic that I think I have grasped in pretty well is values, pointers and references. I have had intensive experience of exercises/practices in these subtopics when I took CSci 1902 and CSci 2021. Creating pointers to store a bunch of data and later referencing the pointers to retrieve the data was kinda fun in a way that I realized that pointers and arrays are such powerful structures to hold data and to play with.

One topic that I don't really know well would be testing frameworks and writing good tests. I have had hard times writing merely simple test cases when I was programming in Java, so don't mention "good" test cases. I was kinda confused as to how to really write several(strong) test cases that would really prove that the functions work correctly on all test cases.

Another topic that I wish to get out of the class by the end of the term is to be good at programming in C++ (using classes, inheritance, templates). I did not have a chance to really get most out of Java last time and I am glad that I am now given a chance to learn more about creating classes and inheriting them from one to another to function a big project as a whole. Having done continuous effort on projects but always not getting the expected outcome was always a nightmare to me. I truly hope that I can get much out of this course, or at least more than what I already knew.