And The Results Are In: Wattdepot Review

I just finished reading the reviews of my groups Wattdepot project and I have to say I am pleasantly surprised. They were mostly all positive. One the exception of course of our group not having any real test cases so that was one thing that everyone commented on.

I believe that the better your system is the easier it is and yet the harder it is the review. When I looked at the reviews for my group's system, many of them were a short and precise: This system works, the described checklist item works and is in order. But from my experience when it is good, it is harder to break or find something for the group to improve on.

One of the strategies I tried during the review, since we had to review two systems, was first trying to break the system and then reviewing the code. After that I tried reviewing the code first and then trying to break the system. I found the latter a lot after and easier to do. The reason being is that when you review the code, you can see which of the specifications were not implemented, and immediately you can see problems. I was able to see which exceptions were not caught and immediate knew how I could break the system. It is a lot faster than trying to think up of ways and then testing all possibilities on how I can break a system.

All in all, I believe that taking different approaches that work well next time can speed up the reviewing process, I found it not so bad and gave me a lot of insight into potential problems and even fixes and ideas on how to improve me own project.

Your code has good Feng Shui: WattDepot Code Reviews

All these parentheses and semicolons really ruin the feng shui of the code!

Although it can often be a very good thing, a lot of programmers hate to do code reviews. So this week we get a hard learned lesson is code reviews.

I have been tasked to review two other groups WattDepot project mentioned in our previous blogs. Watch as I tear it up.

The reviews for these two groups were assessed based on the checklist found here.

To read my full review of the code refer to the links below:

Eolu (eono)

Ehiku

Summary:

Eolu

Not all the commands were completed. Overall the design could use work, the methods can be split into there respective classes and the javadocs require updating. Comments need to also be added to many methods, it is inconsistent.

Ehiku

All but the chart command is completed and functioning. The design for the system is very good, all methods are separated into their own class. Commenting and naming conventions need to be more consistent across the different programmers. Overall well programmed.

Ten Specifications Down for Team UMI: WattDepotCli

So we have just completed our first team project and everyone could use some sleep. It is three in the morning and only four out of the ten teams have submitted their projects as of yet.

At the beginning of the project, I believed that it would not have been so bad. Working with partners has proven to be an effective was of learning and increasing productivity. So I'll share some of the experiences I had with my partner.

Unfortunately for us, my partner and I were unable to meet everyday since we both has busy schedules. Unfortunately again that this project be over the Halloween weekend where everyone likes to party away. With my schedule being so full, I was hoping to try finishing up small easy parts during my spare time. Though that didn't work out as well as I had planned.

Luckily for me, my partner is quite the diligent worker and before I could really step in a do much work, most of the project was already complete. I was left to review some code and add in a part of the remaining Cli. I do wish I could have helped more though, but the delegation of tasks were not as clear with each person working on something and then moving on to the next one that is not yet taken.

With proper delegation of tasks I believe that the project could have flowed smoother, but differences in schedule and does not often allow for that. Even with many people with a single goal, I learned that it takes a lot of communication between these people to get the job done. It wasn't until we sat down and talking about the task as hand were we able to really get it flowing.

Integration With Hudson

For the rest of the semester we will be grouping together with a partner or other people. We've already touched upon using a version management system such as SVN to allow us to have a centrally distributed build. So now that we are working with partners it's a good time as ever to get into the practice of using this newly found knowledge.

Last week, we were introduced to Hudson which allows us to automatically run repeated jobs and auto build/test our systems. This automated process is connected to our google repository. This is a very useful tool for us to use now that we are working with a partner/s. When one of us breaks and build on uploads a new build it will automatically test it and send out a report by email to us.

Most of the setup was done by my partner but from what I could tell, the Hudson system was very quick and easy to set up. It only took a few minutes to get our program up online and have it start building. I'm sure it will continue to become a very useful tool throughout the rest of the semester and probably our future career.

Midterm Review

The midterm is coming up and to help us study we are creating ten quiz questions that will help us review the material when creating the questions and allow others to review material while scouring for answers. These questions are similar to ones found in class and will test our overall knowledge of the material discussed in class minus anything related to RoboCode.

10 Questions are posted, return on Tuesday for the Answers!

Edited with Answers on the Bottom

Questions

1. Please code the FizzBuzz program discussed at the beginning of the semester. Count from 1-100, replace multiples of 3 with fizz, multiples of 5 with buzz, and multiples of 3 and 5 with FizzBuzz.

2. Why is the above useful knowledge?

3. Why is it useful to ask smart questions? What is an example of a Smart question and answer.

4. Why is it important to know how to override equals() and hashCode()?

5. When overriding equals() and hashCode, what are important things to keep in mind?

6. Why is it important to follow coding standards?

7. How effective is multitasking? Can you list some strategies to be more effective at working?

8. What is ant and how is it a useful tool to us?

9. What are the differences between white box testing and black box testing? Can you give an example where they are used?

10. What is Subversion and Git? What are the differences between them? List an Advantage and Disadvantage of both.

Answers

1. Please refer to your first blog post for the answer.

2. The FizzBuzz program is useful to know because it is a common example of a general coding question that would be asked on an interview.

3. It is useful to ask smart questions because it allows anything who may help you information on the problem and allows them to reply more quickly.

4. It is important to know how to override the two methods because it allows you to change the restrictive method to allow better comparability with objects such as object classes that you define.

5. When override these methods, you must remember to override both of them and that when overriding the equals method it has the following characteristics, Symmetry, Reflexivity, Transitivity, and Consistency.

6. It is important to follow coding standards because it allows uniformity between code and easier accessibility by other users reading and trying to understand your code.

7. Multitasking is not effective, it only feels like we are being more efficient, but it spreads user focus across multiple things and lowers the quality of work. Remove your self from distractions such as cell phones or the TV.

8. Ant is a java build tool that allows us to automate a building process of files in a distribution. It is similar to the make tool, but uses java.

9. White box testing is a more internal approach to testing in which the tests are designed based on the actual code, while black box testing is an external outlook at the testing in which we test to see if the code works correctly.

10. Subversion and Git are version control software. A big difference between the two is that Subversion is centralized and Git is distributed. One advantage of subversion is that when there is a change all the versions will be updated to the most recent, but since it is centralized, everyone will experience problems if the centralized version is compromised. With Git you clone the repository and run and change the files from a local copy off your computer, this means that there is no extra history coming from any other contributor and may lead to having multiple copies a file for different versions.

Did I just Google Groups Subversion?

This week we are taking our projects online and hosting them through google. We also learned about configuration management through subversion.

Google allows us to host projects through googlecode which allows us to give access of our code or project to other members and then collaborate by sharing ideas and code. One of the ways we can cooperate on a single project is through the use of subversion. This program allows us to download files from our google repository and then after making changes, committed them for everyone else to download and view.

You can view my google project page here.

One of the most difficult things through this process was figuring out how to use the SVN client, SmartSVN, properly and direct it to my repository. Once I got the steps down, it was a simple task and took less than a minute to connect to a classmates repository to download their files. The other majority of the time was spent configuring the google group site to add members and have email notifications. Again this is a problem when you first start using these things.

One of the things I really took from this was the configuration management and using SVN. The ability to collaborate on a larger project without having to constantly contact and talk to other contributors is going to become a great asset to me in the near future. I'm planning on working with a few friends on an upcoming project. One of the things I really like about using our repository was the fact that it allowed for the tracking of changes. It will be a lot easier to quickly read through and understand new changes made by other contributors when it is highlighted for you.

Junit Testing My Patience

After learning about build systems we were given the task to create jUnit tests for our robots.

You can find my distribution for my robot with test cases here.

It is one thing to design your robot, but it is a whole other thing to figure out tests for your robot. Trying to think of a way I could test a robot that doesn't have any predefined move path was torture. The fact that my robot's movement is based on the positioning of the enemy robot made it very difficult for me to test the proper movement.

The easiest test for my to do was, other than acceptance tests, were the firing tests. My robot fires very conservatively so it was easy to check, if they move don't fire, if they sit still fire!

The biggest problem was the unit test and the movement behavioral test. The unit test was very difficult because my robot in itself is very simple. Moving constantly in a predefined angled but relative to the enemy, the only thing I could think of was having the only formula I could have in it, which was one we had done earlier in our run through robocode, the Fire03 robot we built who's firepower was determined by the distance from the enemy.

Since this is in fact the first time we are doing tests I don't feel as confident in my test cases than I should be. After all my robot didn't do so well in the competition because I was unable to compensate or catch certain interactions with different movement patterns. All of which could have been better if there was proper testing.

I wasn't able to figure out how to run emma, although understand what it does essentially. I think my robot has a long way to go still. After some though I believe that one of the ways it could be modified for both testing sake and actual performance is to have a more clearly defined movement pattern. Right now I feel that is just too basic and very hard to test for, well how hard is it to test for a robot that moves forward? But then how hard is it to test for a robot that moves randomly without using the math.random() function. I kind of feel like that at this point, stuck between something really basic and something overly complex.

I think simplicity is the key to more sleep.