16.MyIsernReview

Author of reviewed code: Shaoxuan Zhang

Introduction
This was a very interesting exercise for me, as the person who's code I reviewed was my group member. Therefore, the code I reviewed is, at least partially, my own. This essentially provided me with an opportunity to look at my own product and try to critique it.

Installation review
Although I already had this entire project on my computer, I tried to download it and run it as though I had never done so before. Since there was no .jar file contained in the download package, I ran it by importing it into eclipse.

I was able to easily download the file from the link provided on Shaoxuan Zhang's blog entry. It was a simple task to import the project into eclipse and run it. I had no problems installing and running this software. It passed the verify.build.xml test without and errors. At this point I have no problems with the project.


Code format and conventions review
This was an interesting task, as I had previously read and worked on the code I was trying to review. Going over this code again just focusing on code format gave me a different outlook on the code. Despite my best efforts, however, I was only able to find one problem. A bit more white space between methods would have made the code slightly easier to read. My table of convention violations is only

File	Lines	Violation	Comments
ExamplePrinter.java, TablePrinter.java, ...	12,10,...	EJS-7	White space needed between methods

Test case review
This was a particularly difficult area for me to critique, since it was my job to test the code. I tried to look at my own code with a critical eye and think of what was lacking in my own test cases.

Black box perspective
From a black box perspective, this was a difficult program to test. The requirements were just that the output be a series of tables containing the data from the XML files. There was no specification as to the format of the tables. Therefore, creating general test cases that considered the output of the entire system was nearly impossible.
Despite this, a test that parsed the output tables and compared them with expected values was missing.

White box perspective
This are was quite thoroughly tested. There were many tests for boundary conditions and illegal values. There were 8 separate tests for exceptions, as seen from the output of running JUNIT. Looking at the output from emma, there is only one section of code that was not tested, and that was the exception handing within of ExamplePrinter, the class that contained the main function. This section of code would only run if there was something wrong with any of the xml files used by main(). However, since the file names are hard coded, I see no way of testing this section of code. I could find no other missing tests from a white box perspective.

Break da buggah
It took me quite a long time to break this code, but I was able to find a problem. If the XML file is of an incorrect format, the program does not always behave correctly. For example, if an element is repeated twice with two different values, only the second will be displayed. For example, I edited collaborations.example.xml by adding an additional < Description> element, such as:

< Description>
A graduate student at the University of Hawaii spent the summer working in the University of Maryland research group.
</Description>
< Description>
This is a second description that does not belong here.
</Description>

This invalid XML format is not caught by the system and the output table contains

...--------------------------------------------------
...| Years | Description |
...--------------------------------------------------
...| 2005 | This is a second description that does |
...| 2006 | not belong here. |
...--------------------------------------------------

Summary and Lessons Learned
I got a fresh new perspective on my own project, and I think I did a fairly good job. I think Shaoxuan Zhang and I did a good job on the structure, design, implementation, and testing of the project. Perhaps the only thing I would change is to add some more complete black box tests.

I tried to critique my own code fairly, but I think it is impossible when you already know so much about it. It is much harder to critique and break your own code.

15.MyISERN-1.0

Group Ivory distribution available
HERE

Group Ivory Team: Shaoxuan Zhang, Ben Karsin


Lessons about JAXB:
The example given to us for this project was a great help. It provided many of the necessary functionality of JAXB. Without the example to show us the many complicated classes and methods of JAXB, this project would have been extremely difficult.
While adapting the sample code to meet our project, however, I learned quite a lot about JAXB.


XML
I was able to quickly understand the structure of the XML documents. I was expecting them to be much more complicated. Once we understood the structure of the documents and what needed to be done with them, we were able to work on the rather tedious task of creating the structure and implementation of this project.


Major Issues
One of the major issues we had was creating a nice table format. There was no specification in the assignment for a desired format, so I spent quite a bit of time trying to come up with an optimal solution. I turned out, however, that my partner was able to design a very nice looking table that is able to work well with different sizes and numbers of entries.
During this project both my teammate and I because quite frustrated with findbugs. Some of the errors given were unnecessary, annoying to overcome. For example, it tends to complain about
if (a != b) {
...
}
else {
...
}

This is really an insignificant problem but can become quite annoying. We also had some rather annoying little problems with javadocs giving errors if package.html is not of an exact format.
Overall, the majority of the issues we faced were not very large, but added up to be quite an annoyance. We eventually overcame them all and have a quite nice and stable project.


Teamwork
On the first day after the project was assigned, we decided to meet at the library. Upon meeting, however, we decided that it was an unnecessary waste of time to meet every day in person, so we decided to just use email, phone, and Skype to communicate regularly. The technology helped us communicate, but the project is fundamentally difficult to divide. We both began by reading the given documentation and tutorials, and began designing separately. Shaoxuan came up with a working program before me, so we decided to use his. He completed the design and implementation of the core of the project, while I was responsible for the testing, documentation, and other various small tasks needed to finish the project.
In the future, I think we should schedule specific IM or Skype meetings at a specific time each day, as the delay of email can be inefficient. I hope that future projects are more divisible and we are able to partition the work. We ended up getting the task done rather well, but I think if we were able to better divide the work, our time would have been used much more efficiently.

14.CM.Practice

All three tasks were completed.

Installation:
Downloading and installing TortoiseSVN was very easy and only took a few minutes. It did, however, take me a little while to get used to the interface for this program. Once I played around with the interface, however, I found it very easy to retrieve, commit, and update SVN projets.
Once I installed TortoiseSVN, i downloaded the stack project, added a period to one of the javadoc sentences, and committed it. This was a rather fast and easy task.


Problems Encountered:
I ran into only a few problems during this small practice. Most of them were caused by the rather confusing interface at Google project hosting. Sometimes it was difficult to find certain options or menus on the website.
The biggest problem I had was setting up the automatic email notification for the -svn group. The text boxes to input the email addresses to send notification to were in an unexpected area. I had to keep slightly changing my project and re-committing it. I eventually figured it out and was able to get the notification on my Google group.

Lessons Learned:
I learned to use SVN. It is quite a useful tool and I am very glad that I now know how to use it and how to host projects. This assignment was a very easy introduction to some very useful and powerful software.

12.WebSpiderReview

Author of package under review: Edward Kim

Introduction
When I first began reviewing this code, I was quite surprised by the lack of support classes and methods. The entire program is contained within a single class and has only 3 methods. However, when looking closer, it is quite concise and seems to accomplish the tasks. There are not many tests, but they provide good coverage. I think this is a case where more testing is needed to produce a stable program.


Installation
It was quite simple to run download and run the package from Edward Kim. The zip file contained everything I needed to run all of the tools. I simply opened my command line and ran all of the necessary files.

I used ant to run all of the provided xml build files. The output data from the junit tests were quite extensive, but I was able to run all of the tools without any errors. For simplicity of testing, it would be nice to display a simple pass or fail for each of the junit tests. I was also able to create the jar file using dist.build.xml without any problems.

I then ran the command
java -jar webspider-{classmate}.jar -totallinks http://www.hackystat.org 100

The results were that 3211 links were found. It seemed to run this task correctly.


Code Format and Conventions
Upon opening the source file, I immediately noticed that the example file was used and the additional features were added. While it is nice to use this as a foundation, it is important to remember to change the header comments and add detailed comments about added features.

File	Lines	Violation	Comments
WebSpiderExample.java	24,26,83	EJS-13	All letters of URL are capitalized.
WebSpiderExample.java	24,25,26	EJS-39	Global variables not documented.
WebSpiderExample.java	36,138,213	EJS-56	No pre/most conditions.
WebSpiderExample.java	63,66,163	EJS-9	Variables names wc and resp not clear.
WebSpiderExample.java, TestWebSpider.java	N/A	EJS-40,41	No Summary of files/package

Test Case Review
There were few test cases provided for this application. The file TestWebSpider.java contained a few tests that ran the application with several different settings. Some of the tests took a long time to execute and produced excessive output because the program was run over a website with a link depth of 100. Cases could be tested much faster and cleaner with more, smaller tests.

Black Box Perspective
There was no testing of abnormal I/O combinations. Only one test was run that verified correct output. Test of each method should be done from this perspective to ensure proper execution for a wide range of input. For black box testing, the addition of tests done over a controlled set of web links would be very useful. I would add tests something similar to Randy Cox's test website, available at

http://www2.hawaii.edu/~randycox/11.WebSpider/test/main.htm

In addition, it would be helpful to test each method separately and compare the output. Tests should be done over the method mostPopular() with different lists of Strings being passed (including an empty list and a very long list). Likewise, tests could be done over the crawl() and getNumLinks() methods with different combinations of input. The resulting tests should have their results compared to the "expected" results.


White Box Perspective
Coverage was very well tested. Emma reported that coverage was well over 90%. While all the code was tested in some way, exceptions were not tested for, and abnormal cases were not considered. At the very least some tests where exceptions should be thrown are needed. Boundary conditions are also not tested, and in some cases unhandled exceptions will result. For example, if a null is given as input to one of the methods.

Some tests that should be added include testing passing null values to the methods. An example of this would be sending the mostPopular() method a null value instead of a list.

Break da buggah
To break this program, I simply began trying strange input. I first used the control website provided above to ensure it gave correct output. It passed these tests. I then tried simply providing not enough input. The command was

java -jar webspider-eykim.jar -totallinks

The result was

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2
at edu.hawaii.webspider.WebSpiderExample.main(WebSpiderExample.java:112)

There are problems with catching erroneous I/O that could be easily fixed. Additional testing could have revealed these errors.


Lessons Learned
Doing this type of critical review, I see many errors that I made myself. For example, I had quite inadequate testing in my version of this same program. In breaking this program, I see that I should write much more extensive tests for my own future program. Black box testing, specifically, tends to be under emphasized. Catching cases where strange input can break your program is very important. You never know what the user will do with your program.

Reading this code also showed me how simply and concisely this program could be done. My version had several additional classes and many complex algorithms and data structures. This version, however, was done quite cleanly with only a few short methods. It shows me that I should spend more time on program design rather then jumping strait into coding.

11.WebSpider

Download available Here

Summary
At first glance, this seemed like a rather simple program. Once I began working, however, that perception changed. Despite the setbacks, I accomplished all 3 tasks. I did not attempt the extra credit.

Task 1:
The importance of program design and planning was very important in this stage. The later tasks would rely heavily on how this task was implemented. As such, I spent quite a lot of time trying to come up with a good design. Despite my efforts, however, my design was not able to smoothly incorporate the required features for Tasks 2 and 3.

Task 2:
I completely redesigned my program from Task 1. I added a new class and a TreeMap to hold the required information about the most popular link. It became clear during these tasks that emma and coverage driven testing are quite uselss. Even with nearly 100% coverage, very few errors were found and much time was wasted trying to get the coverage to 100%. In the future I will focus more on writing "good" unit tests rather then very specific ones that get more coverage.

Task 3:
The logger system was very easy to use. I only had to add a few lines of code and it was working fine. The only problem I had was getting the javac compiler to recognize the Hackystat logger. I was only able to test it in eclipse. Please note that the .jar file contains a version with the logger commented out. To test the logger, please recompile the source.

Conclusions
Good tests can be very helpful, but bad ones can be a waste of time. The amount of time I wasted on emma would have been must better used writing more effective tests. Next time I plan on spending less time with emma and more time with just junit.

10.Stack

Download zip file Here

Task Overview
I was able to complete all five tasks successfully. I came across several problems during this assignment, all of which I was able to overcome.

The process of downloading and installing ant, all of the tools, and setting all the environment variables was rather simple. The instructions were straightforward and I was easily able to get my version of the Stack project could pass the "verify" script.

The most difficult part of this project, for me, was creating the javancss.build.xml file. I have quite a bit of HTML experience but I have never used XML. I had several problems with the path variables required by JavaNCSS. However, after going over the other build files provided and looking at the samples given on the JavaNCSS Website, I was able to accomplish this task.

The final task involved running emma and increasing the coverage to 100% by writing additional test cases. I really liked this tool. It provided very clear information and can make it much easier to write meaningful test cases.

Conclusions
Some of theses tools may be very useful in the development of software projects. However, I think they are all not necessary. The most useful, I feel, are CheckStyle, FindBugs, PMD, and emma. SCLC and JavaNCSS both provide similar information, yet JavaNCSS provides a little bit more (Cyclomatic Complexity Number, etc.). I do not see the information provided by these two tools as being very useful in most software development projects. All the other tools, however, were very helpful and I could see using them in the future. They may even help me break my "bad" habit of putting opening braces on their own lines.

08.CodeRulerRedux

The newest version of my CodeRuler bot can be found

Here

After cleaning up my code to fit the Java conventions, I carefully read the review of my bot. There were several areas that the reviewer felt I could improve my bot. I considered every suggestion and tried to improve my strategy.

The first area I tried to improve was the knight AI. The reviewer mentioned that fleeing when faced with a stronger enemy may not be the best approach. I realized that, while dying needlessly should be avoided, knights should try to weaken the enemy forces until they are on the verge of death. I, therefore, added a condition that only allows knights to flee if they are under half health.

Another area that needed attention was the peasant AI. They covered ground very well, avoided enemy knights, claimed land quite efficiently. The problem was that they would get stuck after a certain point. I tried solving this problem in many different ways. First, I tried taking every square on the map into consideration while scoring, thus preventing equal scoring of all directions. This caused a timeout immediately. I then tried the same strategy, evaluating only every 5 squares. This prevented them from moving within 5 squares of the walls. I ended up staying with my previously strategy, as the peasants would eventually claim the entire board. I left this attempted strategy in the source code (commented out).

I added one final tweak that helps increase my score. Once I control 70 peasants, all castles should create knights. Since knights are worth more points then peasants in the final score, this can increase your score slightly when you have completely wiped out the enemy. It does not matter in a close game, but in a complete victory it will increase your score.

From this revision of my Code Ruler, I realized that many of my coding habits do not follow the convention. I will try to break all of my bad coding habits. Certain things (like giving an opening bracket its own line) I will may always prefer, but I can now try to follow a more universally accepted standard.