Doing peer reviews of other people's implementations of the User Command Interface for the Wattdepot project was very interesting. Both projects that I reviewed had implemented their systems very differently. Both groups split their programs up, but one group implemented their program using an interface, while the other group implemented their program by extending their classes from the main class. Anther interesting aspect of the two implementations was the fact that one group hadn't used any methods in their different classes, but just used System.out.println() within a constructor. I guess I am saying that it took some time getting used to each group's coding style before I was able to review each group. One of the most important things that I have learned from looking at other people's code is the importance of Javadoc comments. I was able to easily read through the code that had good documentation of what was going on.
It was interesting reading other peoples review of our system. The 5 reviewers of our system had similar critiques of our system. Basically each of the reviewers talked about our lack of test cases and having too many methods within one class. These are very true comments and I agree with their review. While working on the project I made the stupid mistake of trying to write in all the test cases for my code after finishing my code. I also need to organize my code better and not put everything into one class. Something I learned that helped a lot when looking at reviews of our system, was when reviewers would write in exactly what command they inputted that failed to work while they were testing our code.
The most helpful reviews were the reviews which contained constructive criticism. Most of the reviewers review of our system were constructive with the exception of one. While reading the reviews, one comment about my group's projects was that we have written our code in "spaghetti code." This is a very harsh comment that did nothing to help our group improve our system since the comment ended there. This reviewer did not specify what parts of our code was "spaghetti code." Writing comments without giving evidence just confused me because I didn't what what exactly made our groups code hard to read. Besides having one long file, I thought that our groups code was easy to follow.
Tuesday, November 10, 2009
Monday, November 9, 2009
Reviewing other people's WattDepot-Cli
This week for ics 413, we get to review other people's implementations of their User Command Interfaces. Each member of the class was assigned to review two other group's projects, not including their own of course. We were also assigned to base our reviews on the criteria given by our professor. A copy of that review sheet can be found here. I was assigned to review two groups: Umikumakahi and Umikumalua.
Umikumakahi
Umikumakahi's system was very tricky to review, since I was not able run their system in my command prompt or in the Eclipse IDE. I was not able to test whether commands worked or not therefore my review was based more on their javadocs and their design of the system. My full review can be found here.
Umikumalua
Umikumalua's system worked well, but had many issues where bad input would crash the program. Also, commands were case sensitive which cause me problems when trying to test out the commands on the system. For example, 'list sources' would work where 'LIST SOURCES' would not be recognized. There were also a few commands that were not implemented which need to be before their next version comes out. My full review can be found here.
Umikumakahi
Umikumakahi's system was very tricky to review, since I was not able run their system in my command prompt or in the Eclipse IDE. I was not able to test whether commands worked or not therefore my review was based more on their javadocs and their design of the system. My full review can be found here.
Umikumalua
Umikumalua's system worked well, but had many issues where bad input would crash the program. Also, commands were case sensitive which cause me problems when trying to test out the commands on the system. For example, 'list sources' would work where 'LIST SOURCES' would not be recognized. There were also a few commands that were not implemented which need to be before their next version comes out. My full review can be found here.
Wednesday, November 4, 2009
Creating a WattDepot CLI
For my ICS 413 class, we are writing code for the WattDepot-Cli program. WattDepot is a new program that helps people regulate accurate power usage of power plants and homes throughout the island. More information can be found about the WattDepot program here.
In class, we were paired up with another person in our class to create a CLI(Command Line Interface) for the WattDepot program. I was paired up with Shaun Ramento. This assignment was very hard to start off. It took a long time just learning the API of the WattDepot. Just getting simple functions like client.getSource() was troublesome, since the Source class also had many other methods nested in it. After learning the basics of the API, we had to figure out how we were going to implement the CLI(Command Line Interface). We decided to create a new class, that would hold all of our methods in it, and also figure out what commands the user is inputting. The 10 commands that we needed to implement can be found here.
After getting the two simple commands, 'help' and 'quit' done, we started working on the next set of commands. We decided to split up the work on commands 2.3 and 2.4 so we would be able to help each other get used to the API. We then split up the work by the type of commands we will need to access. I took commands that dealt with sensordata and shaun took the commands that dealt with power. Finally, we split up the last two sections of the assignment where I took section 2.9 and Shaun took section 2.10.
After getting about half way through the assignment, our professor told the class that he did not like the way that a certain group was deigning their code. This group had all their methods setup in one java class file. Our professor told the class that these people need to rewrite their code by splitting up their methods and to use an interface. This was a problem, because my partner and I had decided early on to do the commands the same way that he lectured about, which meant that we also needed to change the design of our implementation of the project. Also, the group wrote their code using a lot of System.out.println() which we also did. Rewriting the code to not have these System.out.println() statements caused much time to be wasted since we had to rewrite a good portion of our code to fulfill the standards of the program.
We made a mistake by not writing junit tests while we writing our java code which caused a lot of time to be wasted since we would write code, run the program, then enter code to see if it works properly. This was a huge mistake. Too much time was wasted in this process. We ended up writing our junit tests late, which caused us to waste more time since we had to look over our code to remember what we had to test.
After finding out that we needed to change the design of our project, we decided to finish all of our methods then work on moving the methods around. Unfortunately, we were not able to setup our project in the way that our professor wanted us to, since we had problems finishing the rest of the methods by the Wednesday deadline. So we did not move the methods into their own separate classes and implement an interface. I wish I had more time to understand this interface and creating separate classes. I will most likely look at how other people have implemented this portion of the assignment, since it seems like it is very useful and essential to learn writing code in table-based dispatching form.
Here is the distribution to team eha file.
In class, we were paired up with another person in our class to create a CLI(Command Line Interface) for the WattDepot program. I was paired up with Shaun Ramento. This assignment was very hard to start off. It took a long time just learning the API of the WattDepot. Just getting simple functions like client.getSource() was troublesome, since the Source class also had many other methods nested in it. After learning the basics of the API, we had to figure out how we were going to implement the CLI(Command Line Interface). We decided to create a new class, that would hold all of our methods in it, and also figure out what commands the user is inputting. The 10 commands that we needed to implement can be found here.
After getting the two simple commands, 'help' and 'quit' done, we started working on the next set of commands. We decided to split up the work on commands 2.3 and 2.4 so we would be able to help each other get used to the API. We then split up the work by the type of commands we will need to access. I took commands that dealt with sensordata and shaun took the commands that dealt with power. Finally, we split up the last two sections of the assignment where I took section 2.9 and Shaun took section 2.10.
After getting about half way through the assignment, our professor told the class that he did not like the way that a certain group was deigning their code. This group had all their methods setup in one java class file. Our professor told the class that these people need to rewrite their code by splitting up their methods and to use an interface. This was a problem, because my partner and I had decided early on to do the commands the same way that he lectured about, which meant that we also needed to change the design of our implementation of the project. Also, the group wrote their code using a lot of System.out.println() which we also did. Rewriting the code to not have these System.out.println() statements caused much time to be wasted since we had to rewrite a good portion of our code to fulfill the standards of the program.
We made a mistake by not writing junit tests while we writing our java code which caused a lot of time to be wasted since we would write code, run the program, then enter code to see if it works properly. This was a huge mistake. Too much time was wasted in this process. We ended up writing our junit tests late, which caused us to waste more time since we had to look over our code to remember what we had to test.
After finding out that we needed to change the design of our project, we decided to finish all of our methods then work on moving the methods around. Unfortunately, we were not able to setup our project in the way that our professor wanted us to, since we had problems finishing the rest of the methods by the Wednesday deadline. So we did not move the methods into their own separate classes and implement an interface. I wish I had more time to understand this interface and creating separate classes. I will most likely look at how other people have implemented this portion of the assignment, since it seems like it is very useful and essential to learn writing code in table-based dispatching form.
Here is the distribution to team eha file.
Sunday, November 1, 2009
Continuous integration and Hudson
For my ics 413 class we were just introduced to continuous integration. We were introduced to this topic because we are going to be working in groups on this upcoming assignment. In groups projects, big changes to software can lead to problems since those changes may not be compatible with other group members code. Continuous integration is an idea where programmers of software projects make small changes to projects then committing those small changes. The continuous integration environment that my 413 class is using will be Hudson.
Hudson is a system that helps software development by continually building and testing projects. Hudson will monitor my groups SVN repository by building and testing new project updates. Anytime a group member commits something new to the SVN repository, Hudson builds and verifies the project. If any build or test fails, an email would be sent out to everyone working on the project saying that the project failed to build. Anytime there is a failed build, it should be immediately fixed. The Hudson system is very useful since it verifies a project just in case one of the group members forgot to.
Hudson was very simple to setup and use since most of the instructions were given to us in a webcast. If I were to do it on my own, I think that it wouldn't be too hard since there are instructions all over the internet. The only problem that I had while setting up Hudson for my group was that I didn't set the automatic build field, so Hudson looked for a file in a folder that didn't exist, so the build kept failing. Other than that user error, everything else in the setup was straightforward.
Hudson is a system that helps software development by continually building and testing projects. Hudson will monitor my groups SVN repository by building and testing new project updates. Anytime a group member commits something new to the SVN repository, Hudson builds and verifies the project. If any build or test fails, an email would be sent out to everyone working on the project saying that the project failed to build. Anytime there is a failed build, it should be immediately fixed. The Hudson system is very useful since it verifies a project just in case one of the group members forgot to.
Hudson was very simple to setup and use since most of the instructions were given to us in a webcast. If I were to do it on my own, I think that it wouldn't be too hard since there are instructions all over the internet. The only problem that I had while setting up Hudson for my group was that I didn't set the automatic build field, so Hudson looked for a file in a folder that didn't exist, so the build kept failing. Other than that user error, everything else in the setup was straightforward.
Monday, October 19, 2009
My Madeup Midterm Questions!
1. What is an anti-pattern? Give one example of an anti-pattern.
"An antipattern is a recurring negative solution to a problem" (http://www.ibm.com/developerworks/opensource/library/os-junit/#N100C5) In otherwords, an anti-pattern is a test where it seems like it is testing a lot of the code, but rather it has missed much of the code. It is giving a false sense of security that the code is working properly.
Examples of anti-patterns:
Happy path tests - Tests if everything is working properly and gives the correct results. This is only an anti-pattern if this is the only type of test used.
Validation and boundary tests - Like the happy path test, but tests the boundaries of something(maybe a method, list, input, etc.) and also tests if the correct output is thrown if there is invalid input. This could be an anti-pattern if the data that you put in returns valid when it should not be valid. For example, if an input should be out-of-bounds, but it still returns valid input.
Easy tests - Tests that are very simple (like testing toString()) because the code is hard to test. These tests work but do not accomplish much.
Overly complex tests - A test that is so complex you cannot tell if it is correct or not. The anti-pattern is not knowing if a test is correct or not. It is better to have a simple test that you know is correct.
2. When overriding equals(), you must also override hashCode(). Why could overriding hashCode() in the following manner not be good?
public int hashCode() { return 0; }
This is because the hash would become one long list of values in one bin.
3. What makes a build tool, like ANT, so useful?
-Build tools are cross-platform
-It allows for the compilation and testing of code to be automated
-It can download and install everything that is needed for running the code
-It can be incorporated with IDE's like Eclipse.
4. What is the main problem with only allowing one person to checkout and modify a project at a time?
Everyone would have to wait on that one person.
5. What is the difference between White Box testing and Black Box testing?
In Black Box testing, there is no knowledge of the internal structure of the program. Some examples of Black box testing is equivalence and boundary value analysis. In White Box testing, a person could test the paths within a program. Some examples of White Box testing is control flow testing, data flow testing, and branch testing.
6. In the article about coverage tools, In pursuit of code quality: Don't be fooled by the coverage report, what did the author mean by "fools gold?"
It is when there is a high coverage report, but it doesn't mean that the code was exercised well.
7. What does the following code written in an ant build file
It defines a property, checkstyle.config.file, and sets its value to checkstyle.xml.
8. According to the Stanford article, why are heavy multitaskers unable to perform better in the tests than the light multitaskers?
The heavy multitaskers were unable to filter out the excess information and thus were not able to concentrate.
9. Emma's coverage report indicates that you have covered 100% of you code. Does this mean that your code is now bug free? If not, explain.
Even though all of your code has been executed by Emma, it doesn't necessarily mean that your code is bug free. A test could cover all of the lines of code but not have been fully exercised. For example, a person could write a single test that covers every line of the code.
10. What irritates hackers the most when they are trying to help people on forums?
When people ask questions that they could have easily looked up the answer to themselves.
"An antipattern is a recurring negative solution to a problem" (http://www.ibm.com/developerworks/opensource/library/os-junit/#N100C5) In otherwords, an anti-pattern is a test where it seems like it is testing a lot of the code, but rather it has missed much of the code. It is giving a false sense of security that the code is working properly.
Examples of anti-patterns:
Happy path tests - Tests if everything is working properly and gives the correct results. This is only an anti-pattern if this is the only type of test used.
Validation and boundary tests - Like the happy path test, but tests the boundaries of something(maybe a method, list, input, etc.) and also tests if the correct output is thrown if there is invalid input. This could be an anti-pattern if the data that you put in returns valid when it should not be valid. For example, if an input should be out-of-bounds, but it still returns valid input.
Easy tests - Tests that are very simple (like testing toString()) because the code is hard to test. These tests work but do not accomplish much.
Overly complex tests - A test that is so complex you cannot tell if it is correct or not. The anti-pattern is not knowing if a test is correct or not. It is better to have a simple test that you know is correct.
2. When overriding equals(), you must also override hashCode(). Why could overriding hashCode() in the following manner not be good?
public int hashCode() { return 0; }
This is because the hash would become one long list of values in one bin.
3. What makes a build tool, like ANT, so useful?
-Build tools are cross-platform
-It allows for the compilation and testing of code to be automated
-It can download and install everything that is needed for running the code
-It can be incorporated with IDE's like Eclipse.
4. What is the main problem with only allowing one person to checkout and modify a project at a time?
Everyone would have to wait on that one person.
5. What is the difference between White Box testing and Black Box testing?
In Black Box testing, there is no knowledge of the internal structure of the program. Some examples of Black box testing is equivalence and boundary value analysis. In White Box testing, a person could test the paths within a program. Some examples of White Box testing is control flow testing, data flow testing, and branch testing.
6. In the article about coverage tools, In pursuit of code quality: Don't be fooled by the coverage report, what did the author mean by "fools gold?"
It is when there is a high coverage report, but it doesn't mean that the code was exercised well.
7. What does the following code written in an ant build file
<Property Name="checkstyle.config.file" value="checkstyle.xml" />It defines a property, checkstyle.config.file, and sets its value to checkstyle.xml.
8. According to the Stanford article, why are heavy multitaskers unable to perform better in the tests than the light multitaskers?
The heavy multitaskers were unable to filter out the excess information and thus were not able to concentrate.
9. Emma's coverage report indicates that you have covered 100% of you code. Does this mean that your code is now bug free? If not, explain.
Even though all of your code has been executed by Emma, it doesn't necessarily mean that your code is bug free. A test could cover all of the lines of code but not have been fully exercised. For example, a person could write a single test that covers every line of the code.
10. What irritates hackers the most when they are trying to help people on forums?
When people ask questions that they could have easily looked up the answer to themselves.
Wednesday, October 14, 2009
Google Projects and SVN
I was just introduced to SVN or subversion and found the program to be very useful. SVN is a useful tool for working on big group projects. SVN allows for people working on a project to make small changes to the projects and commit the changes to a server for everyone to update. The SVN program that we were introduced to was TortoiseSVN. The good thing about TortoiseSVN is that when a person has to commit an updated version of a program, that person needs to have the most recent version. For example, if a person tries to commit an updated verison of a program to the server, but there was a newer version of the program commited, that person has to update to the newest version of the program then make the changes and commit to the server again. This may also be a negative for SVN since if there are many people making changes at the same time, there may be changes every few minutes or hours. Therefore a person could only be making small changes instead of making one big changes to the program.
I used google projects to host the project. It was very useful since it allowed me to put all of my files onto the server. Anyone who wants to download my files would be able to from the google server. I liked how google projects allows other people to have easy access to my files. When TortoiseSVN is used with Google Projects, any updates could be easily updated by checking out the most recent copy of the project.
I used google projects to host the project. It was very useful since it allowed me to put all of my files onto the server. Anyone who wants to download my files would be able to from the google server. I liked how google projects allows other people to have easy access to my files. When TortoiseSVN is used with Google Projects, any updates could be easily updated by checking out the most recent copy of the project.
Wednesday, October 7, 2009
JUnit and Emma testing
For another class assignment, we were introduced into creating our own tests and running them on JUnit. We were also introduced into using a coverage tool called Emma. JUnit allows java developers to easily test their code over and over. This saves the programmer a lot of time testing their code every time small changes are made. JUnit is especially useful for running tests on code after small changes are made and can tell the programmer if a change to the code has messed up other parts of the code. Emma is a coverage tool that tells the tester how much of the code was actually covered by the JUnit tests. To get used to JUnit and Emma, I wrote tests for my robocode robot.
I have never utilized JUnit before so this my first experience writing my own tests for code. It felt like I was learning an entirely new language, but after a few hours of looking at the API and the RobotTestBed I got the hang of it. I found that writing tests that are not acceptance tests are very challenging. At first, I had a hard time figuring out what types of behavioral tests to test on my robot. I decided to test if my robot moved to the correct side of the map initially, if my robot moved up and down the left or right wall, if my robot had its gun facing the correct direction, and if my robot turned 90 degrees when it was either hit by a bullet or ran into another robot.
The most challenging of the four behavioral tests were testing to see if my robot moved paralled up and down either the right or left wall. Eventually, I figured out that I had to test if the robot was first close to a wall then check if the robot was also facing parallel with the wall. After figuring that out, the rest of my tests went by pretty smoothly. Just thinking about what tests to run took a majority of my time. Thinking of the most efficient tests to test the most amount of code was challenging.
Using Emma was also an interesting experince for me. I had a lot of problems working with emma at first because I didn't understand exactly what all the red, green, and yellow highlights on my code were. As it turns out, the green highlights are highlights of code that was run during the tests. The red highlights were code that was not seen by Emma during the tests. The yellow was codes that were seen, but not executed or used by Emma. While trying to run Emma I ran into problems with Emma not being able to see my CounterBot.java file. This scared me for about an hour until a friend told me that I had to change the emma.build.xml file. The build file was not looking for the correct java code in the correct place, so after changing the code, I Emma was able to read my java file. I found that Emma was able to read 100% of my java file and also read almost all of my JUnit tests. The only test that Emma didn't read 100% was my TestToSide test. I think it was because some of my code doesn't get called if the robot only starts on one side of the map for the entire test.
In order to make my robot easier to test, I think I would have to create more methods within my code. I was not able to run any unit tests on my code since I didn't have methods that were not events within my code. I had a lot of code within the events like onHitRobot, onScannedRobot, and all those other tests. Therefore, I would probably make a moveDirection() method and a fire() method. This would allow me to test is my robot is moving laterally or test how strong of a bullet my robot would fire at a given distance.
My distribution file can be found here.
I have never utilized JUnit before so this my first experience writing my own tests for code. It felt like I was learning an entirely new language, but after a few hours of looking at the API and the RobotTestBed I got the hang of it. I found that writing tests that are not acceptance tests are very challenging. At first, I had a hard time figuring out what types of behavioral tests to test on my robot. I decided to test if my robot moved to the correct side of the map initially, if my robot moved up and down the left or right wall, if my robot had its gun facing the correct direction, and if my robot turned 90 degrees when it was either hit by a bullet or ran into another robot.
The most challenging of the four behavioral tests were testing to see if my robot moved paralled up and down either the right or left wall. Eventually, I figured out that I had to test if the robot was first close to a wall then check if the robot was also facing parallel with the wall. After figuring that out, the rest of my tests went by pretty smoothly. Just thinking about what tests to run took a majority of my time. Thinking of the most efficient tests to test the most amount of code was challenging.
Using Emma was also an interesting experince for me. I had a lot of problems working with emma at first because I didn't understand exactly what all the red, green, and yellow highlights on my code were. As it turns out, the green highlights are highlights of code that was run during the tests. The red highlights were code that was not seen by Emma during the tests. The yellow was codes that were seen, but not executed or used by Emma. While trying to run Emma I ran into problems with Emma not being able to see my CounterBot.java file. This scared me for about an hour until a friend told me that I had to change the emma.build.xml file. The build file was not looking for the correct java code in the correct place, so after changing the code, I Emma was able to read my java file. I found that Emma was able to read 100% of my java file and also read almost all of my JUnit tests. The only test that Emma didn't read 100% was my TestToSide test. I think it was because some of my code doesn't get called if the robot only starts on one side of the map for the entire test.
In order to make my robot easier to test, I think I would have to create more methods within my code. I was not able to run any unit tests on my code since I didn't have methods that were not events within my code. I had a lot of code within the events like onHitRobot, onScannedRobot, and all those other tests. Therefore, I would probably make a moveDirection() method and a fire() method. This would allow me to test is my robot is moving laterally or test how strong of a bullet my robot would fire at a given distance.
My distribution file can be found here.
Subscribe to:
Posts (Atom)
