ICS 413 has been a very eye opening experience for me. I was able to apply what I learned before from previous Java classes which I enjoyed since I don't like to learn things and not get to see some practical application for it.
Valuable Experiences:
I found that most of the class provided very valuable information and incite to the world of software development. I think that the group experience was the best part as we were able to share knowledge and see different views on how to solve a problem. SVN in particular was an interesting experience since we were able to work on the project even if we weren't together, plus the ability to revert to a previous version was a nice feature for the projects. Also the Ant tools added an interesting aspect to the development process as it allowed for testing and the catching of errors that we otherwise might have missed when just looking over or simply just running the code and assuming there are no errors. Lastly I thought that Wicket gave some interesting experience as well as an introduction to web frameworks.
More Experience:
The only thing I felt needed improvement in the class was the coverage of Wicket. I found that Wicket was a particularly difficult language to get a hold of and I thought that the book did a fairly poor job of explaining how Wicket works, plus having it available to only 4 people at a time was a major inconvenience. With that said I think that more time should be spent on Wicket in order for students to full grasp and get the hang of using the language.
More Learning:
After taking this class, I have come to realize that I do not want to become a software developer. While I did enjoy working in groups, I found that software development is extremely time consuming and has the potential to be extremely frustrating. So really I have no interesting in continuing my learning in this area. However if I had to choose an area, I would like to learn more about web frameworks (maybe not Wicket) and how they integrate with Java, HTML and various other languages.
Overall:
I found this class to be extremely helpful in that it gives a great overview of the process and the tools of software development. I enjoyed the experiences from this class, not only for the basic knowledge of software development and the great experience of working in groups but also the fact that this course has helped me decide what I would like to do with my ICS degree when I graduate (most likely networking and IT work).
Thursday, December 17, 2009
Greensmart Ver. 2.0
Greensmart Ver. 2.0 saw some major changes as well as some minor changes from the 1.0 version. We fixed the bugs found in version 1.0 and improved the overall look and feel of the website.
What does this do?
This project has two options. You can view the stoplight page or view the chart page. Should the user go to the stoplight page then they will find that there is a stoplight there that displays the current level of carbon intensity with a specific message to the color. If the user chooses to go to the chart page then they can select a date or a range of dates and the data will be displayed in chart form.
Changes:
Originally we only had one page which took a date and then printed the resulting carbon intensity, carbon intensity level and the hour in a long chart that didn't fit on a screen. However in version 2.0 we changed that. Now there is a home page where you can choose to go to either the chart page (which displays carbon intensity data) or the stop light page which takes the current computer time and calculates the carbon level then displays the results on a stop light with a corresponding message depending on the color of the level. On the chart page we now use Google Charts to graph the carbon intensity and the hour and use background colors to show the level of the intensity instead of printing everything out in a table. Also the user is now able to choose to graph either the carbon intensity or the energy for a given time period.
We also changed the look of the page by changing the background color to the color white and also added "web 2.0" buttons and a new logo that we designed ourselves. Also we created a contacts page and now all of the pages have links to all of the other pages of our project which makes navigation around the site a breeze. To further improve the look of the page we incorporated the date picker to the chart page so now the user has the option to visually pick out which date or which date ranges of data they wish to view.
In addition to the date picker the other extra credit option that we choose to implement was the nice urls. This eliminates the strange wicket generated urls and replaces them with text which gives the project a more professional look to it.
Lessons Learned:
Through this project I was able to gain basic knowledge of Wicket and how it interacts with both Java and HTML. Another thing that I learned was while the project might meet the specifications (like our ver. 1.0), the user interfaces must be easy and friendly to use without too much clutter and a lot of intuitiveness for ease of use for any user no matter how computer literate they are. Lastly I realize that had the option been available it would have been better for us to specialize in certain areas of the project. For example one person does the HTML work, one person does the Wicket and one one person works on the Google charts, ect. Specialization would have allowed for less errors as well as a faster production time.
What does this do?
This project has two options. You can view the stoplight page or view the chart page. Should the user go to the stoplight page then they will find that there is a stoplight there that displays the current level of carbon intensity with a specific message to the color. If the user chooses to go to the chart page then they can select a date or a range of dates and the data will be displayed in chart form.
Changes:
Originally we only had one page which took a date and then printed the resulting carbon intensity, carbon intensity level and the hour in a long chart that didn't fit on a screen. However in version 2.0 we changed that. Now there is a home page where you can choose to go to either the chart page (which displays carbon intensity data) or the stop light page which takes the current computer time and calculates the carbon level then displays the results on a stop light with a corresponding message depending on the color of the level. On the chart page we now use Google Charts to graph the carbon intensity and the hour and use background colors to show the level of the intensity instead of printing everything out in a table. Also the user is now able to choose to graph either the carbon intensity or the energy for a given time period.
We also changed the look of the page by changing the background color to the color white and also added "web 2.0" buttons and a new logo that we designed ourselves. Also we created a contacts page and now all of the pages have links to all of the other pages of our project which makes navigation around the site a breeze. To further improve the look of the page we incorporated the date picker to the chart page so now the user has the option to visually pick out which date or which date ranges of data they wish to view.
In addition to the date picker the other extra credit option that we choose to implement was the nice urls. This eliminates the strange wicket generated urls and replaces them with text which gives the project a more professional look to it.
Lessons Learned:
Through this project I was able to gain basic knowledge of Wicket and how it interacts with both Java and HTML. Another thing that I learned was while the project might meet the specifications (like our ver. 1.0), the user interfaces must be easy and friendly to use without too much clutter and a lot of intuitiveness for ease of use for any user no matter how computer literate they are. Lastly I realize that had the option been available it would have been better for us to specialize in certain areas of the project. For example one person does the HTML work, one person does the Wicket and one one person works on the Google charts, ect. Specialization would have allowed for less errors as well as a faster production time.
Tuesday, November 24, 2009
Wicket Peer Review
For the Wicket review I tested out the Greendepot system.
A. Review the System
I was able to download and build the system without any errors.
B. Review system usage
When I ran tests on the system I noticed that I was able to input a date and have the application recognize the date, however no data would be printed out. Also while testing false values (entering strings or invalid dates) I noticed that all of them resulting in crashing the program. However the interface is simple and self explanatory.
C. Review the JavaDocs
All of the package, class and method summaries provide high-level descriptions with a self contained first sentence. Also the relationships between packages, classes and methods is well described. However the description of the system summary could be better than "a greendepot client". Also all of the JavaDocs conform to the standards put forth in chapter 4.
D. Review the names
In the GreenDepot.java there is a variable called "x". This variable should be renamed into something with meaning. Other than that all of the names in the JavaDocs as well as the actual code conform to the standards set in chapter 3 of Elements of Java Style.
E. Review the testing
There were no tests included with this system besides the HelloWorld test from the example system.
F. Review the package design
The design of the package is good and reflects a logical structure for the system. I found it interesting that the .wicket was left out of the package and instead just went to edu.hawaii.greendepot.
G. Review the class design
Each class is well organized and accomplishes one well defined task. However I think that some of the accessor methods could be set to private as they aren't called on outside of the class that they are contained in.
H. Review the method design
The methods are all short and easy to understand. However in the getCarbonList method of the CarbonCalculator.java I think that the code that creates a timestamp should be in its own method. That way it can be called by other classes and allows for the method to accomplish only one task instead of 2.
I. Check for common look and feel
The look and the feel of the code is consistent. However to improve the coding I would add more comments as there are very few now which causes the code to be a little harder to understand.
J. Review the documentation
The project home pages does a good job of providing the goals for the project as well as what the system accomplishes. However there is no screen dump of the system available.
The UserGuide provides a great step by step method to download and run the system. Just as a small note, I would bold the section titles just so it is easier to find and it doesn't look like one big paragraph.
The DevelopersGuide does a great job of explaining the system and how to extended, but it does not include instructions to build the file, but those can be found in the UserGuide pages.
K. Review the Software ICU data
The ICU seems to be gathering data consistently and reliably. Currently the overall health of the project is good with the only negative aspect being the churn rate. The from the data we can see that the majority of the work took place recently due to the spike in the DevTime and Build fields at the end. Also with the exception of the huge spike in the churn rate we can see that the source code is constantly at a medium to high quality rate.
L. Review the issue management
The issues page was never used during the development of this system.
M. Review continuous integration
There are no long gaps in between commits and with the exception of the first bad build all failed builds are fixed extremely quickly. Also there is a continuous integration job that executes on commit and executes all of the appropriate Ant tasks. Lastly there is a daily build job that executes once a day and executes all of the correct Ant tasks.
Summary
I think that the greendepot system is an ok system. The coding is sound except I think that it could use more comments. Also the lack of outputs, error handling and testing is also a down side to this system. However the based on the ICU and the continuous integration the group seems to be working well and producing good quality code and I think that the next version of this system has the potential to be a well functioning web application.
A. Review the System
I was able to download and build the system without any errors.
B. Review system usage
When I ran tests on the system I noticed that I was able to input a date and have the application recognize the date, however no data would be printed out. Also while testing false values (entering strings or invalid dates) I noticed that all of them resulting in crashing the program. However the interface is simple and self explanatory.
C. Review the JavaDocs
All of the package, class and method summaries provide high-level descriptions with a self contained first sentence. Also the relationships between packages, classes and methods is well described. However the description of the system summary could be better than "a greendepot client". Also all of the JavaDocs conform to the standards put forth in chapter 4.
D. Review the names
In the GreenDepot.java there is a variable called "x". This variable should be renamed into something with meaning. Other than that all of the names in the JavaDocs as well as the actual code conform to the standards set in chapter 3 of Elements of Java Style.
E. Review the testing
There were no tests included with this system besides the HelloWorld test from the example system.
F. Review the package design
The design of the package is good and reflects a logical structure for the system. I found it interesting that the .wicket was left out of the package and instead just went to edu.hawaii.greendepot.
G. Review the class design
Each class is well organized and accomplishes one well defined task. However I think that some of the accessor methods could be set to private as they aren't called on outside of the class that they are contained in.
H. Review the method design
The methods are all short and easy to understand. However in the getCarbonList method of the CarbonCalculator.java I think that the code that creates a timestamp should be in its own method. That way it can be called by other classes and allows for the method to accomplish only one task instead of 2.
I. Check for common look and feel
The look and the feel of the code is consistent. However to improve the coding I would add more comments as there are very few now which causes the code to be a little harder to understand.
J. Review the documentation
The project home pages does a good job of providing the goals for the project as well as what the system accomplishes. However there is no screen dump of the system available.
The UserGuide provides a great step by step method to download and run the system. Just as a small note, I would bold the section titles just so it is easier to find and it doesn't look like one big paragraph.
The DevelopersGuide does a great job of explaining the system and how to extended, but it does not include instructions to build the file, but those can be found in the UserGuide pages.
K. Review the Software ICU data
The ICU seems to be gathering data consistently and reliably. Currently the overall health of the project is good with the only negative aspect being the churn rate. The from the data we can see that the majority of the work took place recently due to the spike in the DevTime and Build fields at the end. Also with the exception of the huge spike in the churn rate we can see that the source code is constantly at a medium to high quality rate.
L. Review the issue management
The issues page was never used during the development of this system.
M. Review continuous integration
There are no long gaps in between commits and with the exception of the first bad build all failed builds are fixed extremely quickly. Also there is a continuous integration job that executes on commit and executes all of the appropriate Ant tasks. Lastly there is a daily build job that executes once a day and executes all of the correct Ant tasks.
Summary
I think that the greendepot system is an ok system. The coding is sound except I think that it could use more comments. Also the lack of outputs, error handling and testing is also a down side to this system. However the based on the ICU and the continuous integration the group seems to be working well and producing good quality code and I think that the next version of this system has the potential to be a well functioning web application.
Monday, November 23, 2009
Wicket Web Development
I found that Wicket was hard to learn and that it is actually quiet complicated. However the teamwork helped me to get a better grasp on the Wicket framework and how it relates to the Java coding.
The good:
I thought that at first the basic Wicket syntax such as the HTML tagging and the basic set up of the corresponding Wicket tags in the Java code was really easy to setup and were clearly defined. Also the WattDeopt commands to get the data were easy to figure out since we had previous experience writing code to get WattDepot data.
The bad:
Other than the basic set up of the tags and basic objects I found that Wicket was very hard to use. Throughout the project I found myself constantly thinking that JavaScript could do the same function, in less code and in an easier way to understand (or at least thats what I think). However in the end we were able to reason the framework out and complete the system.
System design:
I think that our system is very solid. We have all of the requirements fulfilled but we would have liked to put pictures that correspond to the carbon intensity level instead of merely listing the level. Also I believe that the system can be upgraded easily.
Teamwork:
I thought that our team worked very well in that we divided the tasks up and everyone did their part. Also if one of us got stuck we could ask the other members for help and get a greater incite to what we might have been doing wrong. Also often times if someone got stuck, the other members would stop and help look at the code and figure out a solution.
ICU:
Here is a link to the ICU for the past 7 days. The coverage is about average but the complexity and the coupling are good. However the churn rate is really bad which means that we were constantly changing our source code and adding or deleting lines. the rest of the fields remain average. So over all the development for this project was good, however it seems that we tended to refactor our code very often.
The good:
I thought that at first the basic Wicket syntax such as the HTML tagging and the basic set up of the corresponding Wicket tags in the Java code was really easy to setup and were clearly defined. Also the WattDeopt commands to get the data were easy to figure out since we had previous experience writing code to get WattDepot data.
The bad:
Other than the basic set up of the tags and basic objects I found that Wicket was very hard to use. Throughout the project I found myself constantly thinking that JavaScript could do the same function, in less code and in an easier way to understand (or at least thats what I think). However in the end we were able to reason the framework out and complete the system.
System design:
I think that our system is very solid. We have all of the requirements fulfilled but we would have liked to put pictures that correspond to the carbon intensity level instead of merely listing the level. Also I believe that the system can be upgraded easily.
Teamwork:
I thought that our team worked very well in that we divided the tasks up and everyone did their part. Also if one of us got stuck we could ask the other members for help and get a greater incite to what we might have been doing wrong. Also often times if someone got stuck, the other members would stop and help look at the code and figure out a solution.
ICU:
Here is a link to the ICU for the past 7 days. The coverage is about average but the complexity and the coupling are good. However the churn rate is really bad which means that we were constantly changing our source code and adding or deleting lines. the rest of the fields remain average. So over all the development for this project was good, however it seems that we tended to refactor our code very often.
Monday, November 16, 2009
CLI Ver. 2.0
This assignment allowed us to take a look back at our version 1.0 code and take into account the reviews that were given by our classmates. From there we were able to implement the appropriate changes as well as use a revised library. Along with this revised library came 3 additional methods that were implemented to the end of our code. The newest distribution of the Eono system can be found here.
Version 2.0:
In this version we extended our code to meet the requirements in a better way. The first step was we implemented a different interface. Originally the interface had many method signatures, but in this design we made only one method signature (doCommand) available. Also we took the individual commands and made them into their own class. Lastly we implemented extensive testing as opposed to our last build where we only used the tests supplied in the example system.
Group meetings:
We would meet as often as we felt necessary which would be a couple times a week. In addition we would work individually and collaborate over instant messenger. Also we divided the work equally and I believe that the both of us each carried our own weight.
Software ICU:
The software ICU statistics suggest that our project is not healthy but at the same time not sick. We seem to be in between the two leaning more towards the healthy side.
Here are the statistics for Eono
According to the screen cast our coverage as well as the churn rate were unhealthy, but our complexity, coupling, DevTime, commit and build were all healthy. Also we since we created our test cases last, our test column value is unhealthy.
Questions:
All questions were answered by adding and additional test class and then changing the test class to meet the requirements of the questions. The test class will not be added to the final distribution of the system.
1. 2009-11-02T19:00:00.000-10:00 : 9.835E8
2. 2009-11-02T04:00:00.000-10:00 : 4.97E8
The above answers were found by starting a date at 2009-11-01T00:00:000-10:00 and ending at the end of the day. The time would be incremented by 1 hr in a loop and the largest or smallest value would be held in a counter and returned at the end.
3. highest: 2009-11-02 (monday) : 14764.0 MWh
4. lowest: 2009-11-07 (saturday) : 14089.0 MWh
The above was found by calculating the energyGenerate by the grid each day and the lowest/highest levels were kept and returned at the end.
5. highest: 2009-11-04 (wednesday) : 2.9959472E7 lbs
6. lowest: 2009-11-07 (saturday) : 2.2908808E7 lbs
The above was found by calculating the carbonGenerated by the grid each day and the lowest and highest values were kept and returned at the end.
Version 2.0:
In this version we extended our code to meet the requirements in a better way. The first step was we implemented a different interface. Originally the interface had many method signatures, but in this design we made only one method signature (doCommand) available. Also we took the individual commands and made them into their own class. Lastly we implemented extensive testing as opposed to our last build where we only used the tests supplied in the example system.
Group meetings:
We would meet as often as we felt necessary which would be a couple times a week. In addition we would work individually and collaborate over instant messenger. Also we divided the work equally and I believe that the both of us each carried our own weight.
Software ICU:
The software ICU statistics suggest that our project is not healthy but at the same time not sick. We seem to be in between the two leaning more towards the healthy side.
Here are the statistics for Eono
According to the screen cast our coverage as well as the churn rate were unhealthy, but our complexity, coupling, DevTime, commit and build were all healthy. Also we since we created our test cases last, our test column value is unhealthy.
Questions:
All questions were answered by adding and additional test class and then changing the test class to meet the requirements of the questions. The test class will not be added to the final distribution of the system.
1. 2009-11-02T19:00:00.000-10:00 : 9.835E8
2. 2009-11-02T04:00:00.000-10:00 : 4.97E8
The above answers were found by starting a date at 2009-11-01T00:00:000-10:00 and ending at the end of the day. The time would be incremented by 1 hr in a loop and the largest or smallest value would be held in a counter and returned at the end.
3. highest: 2009-11-02 (monday) : 14764.0 MWh
4. lowest: 2009-11-07 (saturday) : 14089.0 MWh
The above was found by calculating the energyGenerate by the grid each day and the lowest/highest levels were kept and returned at the end.
5. highest: 2009-11-04 (wednesday) : 2.9959472E7 lbs
6. lowest: 2009-11-07 (saturday) : 2.2908808E7 lbs
The above was found by calculating the carbonGenerated by the grid each day and the lowest and highest values were kept and returned at the end.
Tuesday, November 10, 2009
Review of reviewing
After reviewing the Umi and Umikumakahi systems I realized a couple of things.
The Good:
Reviewing other people's code can give great incite to your own current project. I know that my group had problems implementing the interface in the correct manner, however I got some ideas on how to better design my system with the interface after looking at others code. Also the responses from the reviewers of my system gave me more incite on how to better improve my system.
The Bad:
Reviewing these systems thoroughly was very time consuming. This can be attributed to the great depth of detail that the reviews cover. Everything from the initial package to the system structure is carefully analyzed which allows for very helpful feed back on all aspects of the system.
Lessons Learned:
After reviewing the Umikumakahi system I realized the importance of comments in the code. In this system there are no comments in the code making it near impossible to understand in a decent amount of time. Occasionally the thought of "if I don't comment here, it won't make a big deal since this is a minor line of code" crosses my head. But after reviewing this system and seeing how impossible it is to understand, I have told myself to comment at all possible locations that might be hard for an outside reviewer to understand.
The Good:
Reviewing other people's code can give great incite to your own current project. I know that my group had problems implementing the interface in the correct manner, however I got some ideas on how to better design my system with the interface after looking at others code. Also the responses from the reviewers of my system gave me more incite on how to better improve my system.
The Bad:
Reviewing these systems thoroughly was very time consuming. This can be attributed to the great depth of detail that the reviews cover. Everything from the initial package to the system structure is carefully analyzed which allows for very helpful feed back on all aspects of the system.
Lessons Learned:
After reviewing the Umikumakahi system I realized the importance of comments in the code. In this system there are no comments in the code making it near impossible to understand in a decent amount of time. Occasionally the thought of "if I don't comment here, it won't make a big deal since this is a minor line of code" crosses my head. But after reviewing this system and seeing how impossible it is to understand, I have told myself to comment at all possible locations that might be hard for an outside reviewer to understand.
Sunday, November 8, 2009
Systems Review
Over this past weekend I reviewed the Umi and the Umikumakahi systems. Both of the systems gave me a better incite on how to better implement my system. The first system I reviewed was Umi. Overall the system was very solid and I liked the way the implementation was set up.
A. Review the build
I was able to build the system using ant -f verify.build.xml without any problems.
B. Review the system usage:
I was able to execute all of the commands with the exception of the 2.8 command which I called with:
list power generated SIM_WAIAU_8 day 2009-11-15 sampling-interval 30 statistic average
which yielded a command invalid error. But along the lines of invalid commands, I found that the system had very good error handling and that I was unable to crash the system. However one of the downsides was that I was able to execute invalid input on commands that took no arguments. For example I inputted the command: list sources SIM_KAHE_1 which yielded the same results as the command: list command. The same is true for quit (ex. quit test) and the help command.
Also I found that the execution of a false source on the list power generated command caused the system to freeze up and I had to force quit the application. An example of this is:
list power generated SIM_OAHU_GRID_1 timestamp 2009-11-15T12:13:00.000-10:00
C. Review the JavaDocs
Upon reviewing the JavaDocs I found that the system was well documented. All of the class, method and package descriptions were well defined in 1 sentence. Also the effects of the methods were also documented (such as the throwing of errors). However I found that there was no sample code examples and that there was no use of HTML tags in the comment code in the source code.
D. Review the names
After looking at the JavaDocs and the source code itself I found that the system implemented good, logical names for their variables, classes, methods and package names.
E. Review the testing
There was no additional testing besides the tests that were already given with the example system.
F. Review the package design
I found that the name and design of the package of this system made perfect sense.
G. Review the class design
While reviewing the source code I found that the methods accomplished a single well defined task and that the instance variables for the methods as well as the classes and instance variables were all appropriately named. Also the methods were made private as often as possible.
H. Review the method design
I found that the methods of this system were well designed with the exception of the listPowerSample method which was quiet long. Also for this method I found that a block of code stores items in an ArrayList, but this block can be separated from this method and made into its own separate method which would return and ArrayList. Lastly I found that the methods had very low number of side effects as the variables used were usually instantiated in the method itself.
I. Check for common look and feel
I found that the code seem very uniform with no major differences between authors.
-----------------------------------------------------------------------------------------------------------------
This next review is for Umikumakahi. I found that their system had good structure, but other than that it caused me lots of problems, especially since there were no comments in the code besides the JavaDoc comments.
A. Review the build
I was able to build the system with ant -f verify.build.xml without any problems.
B. Review the system usage
I was unable to run the system on my computer. I tired to use Eclipse but the error "Some projects cannot be imported because they already exist in the workspace" occurred which prevented me from importing the project even after I deleted my project from the workspace. In an attempt to test it with another IDE I downloaded and imported the system into NetBeans IDE. However once imported NetBeans reported that the system had 100 errors and these errors prevented me from testing the system. Screen shots of my NetBeans can be found here:
NetBeans IDE
100 Errors
C. Review the JavaDocs
The methods, classes and packagese all have high level descriptions and were all summed up well in one sentence. Also the relationship between classes and packages were well noted. However like the umi system there is no examples of code and the use of HTML tags inside the source codes's JavaDocs comment was not found.
D. Review the names
The names of the classes, packages and methods were well chosen and conform to the standards defined in Java Style chapter 3. However some of the instances of class were misnamed as they were the same as the instance of the object they were instantiating. For example the instance for the Console object was called console.
E. Review the testing
After running ant -f emma.build.xml I found that nearly all the code was accessed with the exception of the WattDepotChartCommand and the CommandLineInterface classes. Also the tests were well thought out and the test results were set to match those sent out by email.
F. Review the package design
This system implemented 2 packages and I found that the packages were logically broken down and that they do a good job separating the commands and the interface itself.
G. Review the class design
Each of the methods in this system do one "well" defined task. I say "well" since each command has its own method so it is easy to tell what method you are looking at, however since there is no comments in the code, I found that often times the method was hard to follow easily. Also there were no private methods used in this system. However the instance variables were all named and used correctly.
H. Review the method design
The method design is good in that it implements only one task. However without any comments in the code I'm not sure if some of the longer methods could be cut down by making a method that could be shared between classes. However the methods have no side effects on the variables since each command has its own class which means the variables are independent of each other.
I. Check for common look and feel
I found that the coding in this system was uniform and there were no discrepancies in the format of coding used between authors.
A. Review the build
I was able to build the system using ant -f verify.build.xml without any problems.
B. Review the system usage:
I was able to execute all of the commands with the exception of the 2.8 command which I called with:
list power generated SIM_WAIAU_8 day 2009-11-15 sampling-interval 30 statistic average
which yielded a command invalid error. But along the lines of invalid commands, I found that the system had very good error handling and that I was unable to crash the system. However one of the downsides was that I was able to execute invalid input on commands that took no arguments. For example I inputted the command: list sources SIM_KAHE_1 which yielded the same results as the command: list command. The same is true for quit (ex. quit test) and the help command.
Also I found that the execution of a false source on the list power generated command caused the system to freeze up and I had to force quit the application. An example of this is:
list power generated SIM_OAHU_GRID_1 timestamp 2009-11-15T12:13:00.000-10:00
C. Review the JavaDocs
Upon reviewing the JavaDocs I found that the system was well documented. All of the class, method and package descriptions were well defined in 1 sentence. Also the effects of the methods were also documented (such as the throwing of errors). However I found that there was no sample code examples and that there was no use of HTML tags in the comment code in the source code.
D. Review the names
After looking at the JavaDocs and the source code itself I found that the system implemented good, logical names for their variables, classes, methods and package names.
E. Review the testing
There was no additional testing besides the tests that were already given with the example system.
F. Review the package design
I found that the name and design of the package of this system made perfect sense.
G. Review the class design
While reviewing the source code I found that the methods accomplished a single well defined task and that the instance variables for the methods as well as the classes and instance variables were all appropriately named. Also the methods were made private as often as possible.
H. Review the method design
I found that the methods of this system were well designed with the exception of the listPowerSample method which was quiet long. Also for this method I found that a block of code stores items in an ArrayList, but this block can be separated from this method and made into its own separate method which would return and ArrayList. Lastly I found that the methods had very low number of side effects as the variables used were usually instantiated in the method itself.
I. Check for common look and feel
I found that the code seem very uniform with no major differences between authors.
-----------------------------------------------------------------------------------------------------------------
This next review is for Umikumakahi. I found that their system had good structure, but other than that it caused me lots of problems, especially since there were no comments in the code besides the JavaDoc comments.
A. Review the build
I was able to build the system with ant -f verify.build.xml without any problems.
B. Review the system usage
I was unable to run the system on my computer. I tired to use Eclipse but the error "Some projects cannot be imported because they already exist in the workspace" occurred which prevented me from importing the project even after I deleted my project from the workspace. In an attempt to test it with another IDE I downloaded and imported the system into NetBeans IDE. However once imported NetBeans reported that the system had 100 errors and these errors prevented me from testing the system. Screen shots of my NetBeans can be found here:
NetBeans IDE
100 Errors
C. Review the JavaDocs
The methods, classes and packagese all have high level descriptions and were all summed up well in one sentence. Also the relationship between classes and packages were well noted. However like the umi system there is no examples of code and the use of HTML tags inside the source codes's JavaDocs comment was not found.
D. Review the names
The names of the classes, packages and methods were well chosen and conform to the standards defined in Java Style chapter 3. However some of the instances of class were misnamed as they were the same as the instance of the object they were instantiating. For example the instance for the Console object was called console.
E. Review the testing
After running ant -f emma.build.xml I found that nearly all the code was accessed with the exception of the WattDepotChartCommand and the CommandLineInterface classes. Also the tests were well thought out and the test results were set to match those sent out by email.
F. Review the package design
This system implemented 2 packages and I found that the packages were logically broken down and that they do a good job separating the commands and the interface itself.
G. Review the class design
Each of the methods in this system do one "well" defined task. I say "well" since each command has its own method so it is easy to tell what method you are looking at, however since there is no comments in the code, I found that often times the method was hard to follow easily. Also there were no private methods used in this system. However the instance variables were all named and used correctly.
H. Review the method design
The method design is good in that it implements only one task. However without any comments in the code I'm not sure if some of the longer methods could be cut down by making a method that could be shared between classes. However the methods have no side effects on the variables since each command has its own class which means the variables are independent of each other.
I. Check for common look and feel
I found that the coding in this system was uniform and there were no discrepancies in the format of coding used between authors.
Wednesday, November 4, 2009
Energetic data
Two is better than one:
In this assignment we worked in pairs on a command line interface that would retrieve specified data from a server and then print out the results. I thought that working in pairs was a good experience as we were each able to offer each other different perspectives when it came to solving an error or figuring out the best way to implement code. The tasks were initially divided in half with my partner taking the odds and myself taking the evens. However towards the end (methods 9 and 10) my partner worked on ten while I worked on the interface. So in the end I thought that the distribution of tasks was quite even. Through this even distribution we were able to finish all of the given tasks and set up an interface for our classes. Like I said before I liked working in pairs and I thought that it was a great learning experience.
Problems:
As with all programming there is bound to be problems and probably lots of them at that. In our case we ran into problems where our project in eclipse wasn't the project in the SVN folder, so we found ourselves constantly copying over code and files to keep SVN up to date. The other problems that we ran into were a variety of pmd and findbug errors which were easily resolved after the problem was identified. But probably our biggest hurdle was that after attempting to build an interface, my partners SVN stopped working. This was a major set back as now I was the only one who was able to commit the changes, so towards the end all of her code was emailed to me, then put into the appropriate file and finally committed. Lastly a problem that seemed to bug us a lot was how to implement a certain method. However after discussing it would would find an agreeable way to create a method and one of us would put the ideal into code.
In this assignment we worked in pairs on a command line interface that would retrieve specified data from a server and then print out the results. I thought that working in pairs was a good experience as we were each able to offer each other different perspectives when it came to solving an error or figuring out the best way to implement code. The tasks were initially divided in half with my partner taking the odds and myself taking the evens. However towards the end (methods 9 and 10) my partner worked on ten while I worked on the interface. So in the end I thought that the distribution of tasks was quite even. Through this even distribution we were able to finish all of the given tasks and set up an interface for our classes. Like I said before I liked working in pairs and I thought that it was a great learning experience.
Problems:
As with all programming there is bound to be problems and probably lots of them at that. In our case we ran into problems where our project in eclipse wasn't the project in the SVN folder, so we found ourselves constantly copying over code and files to keep SVN up to date. The other problems that we ran into were a variety of pmd and findbug errors which were easily resolved after the problem was identified. But probably our biggest hurdle was that after attempting to build an interface, my partners SVN stopped working. This was a major set back as now I was the only one who was able to commit the changes, so towards the end all of her code was emailed to me, then put into the appropriate file and finally committed. Lastly a problem that seemed to bug us a lot was how to implement a certain method. However after discussing it would would find an agreeable way to create a method and one of us would put the ideal into code.
Friday, October 30, 2009
Continuous Integration
Continuous integration is an interesting tool that can be very helpful while developing software. Continuous integration allows for your team to upload the latest versions of the code to a repository (in my case GoogleCode) and then have Hudson automatically build the system for you and notify you when the build is complete and if it failed or completed successfully.
My initial impression of Hudson was that it was a nice way to automatically test your system. I found that the interface was well set up and easy to use and that if continuously gave detailed information about who was currently building, what the queue to build was and information about failed and completed builds. The only downside is that if the build failed there is no information on what caused the build to fail. However, the build shouldn't fail as it is the user's responsibility to run such tests as ant -f verify.build.xml to ensure a passing build before committing the changes.
My initial impression of Hudson was that it was a nice way to automatically test your system. I found that the interface was well set up and easy to use and that if continuously gave detailed information about who was currently building, what the queue to build was and information about failed and completed builds. The only downside is that if the build failed there is no information on what caused the build to fail. However, the build shouldn't fail as it is the user's responsibility to run such tests as ant -f verify.build.xml to ensure a passing build before committing the changes.
Sunday, October 18, 2009
Midterm Review Questions
Here are some questions I thought would be helpful in reviewing for the midterm:
1. What is the difference between "white box" and "black box" testing?
Black Box: Design a set of test cases to see if inputs match the desired outputs. Can also catch errors of omission. No access to source code required.
White Box: Use of coverage tools (CheckStyle, ect) to find bugs. Can catch code that has been writen.
2. Why is Subversion so helpful to software development?
Allows for multiple versions to be stored in a database.
Supports optimistic locking and all files are available for check out so that multiple users can edit the same file at one time.
3. What is the purpose of Ant?
Ant provides cross platform coverage tools that execute specific xml targets which performs a white box testing of the specified code.
4. What does the task "ant -f verify.build.xml" do?
This command runs all available tools (CheckStyle, FindBugs, JUnit, ect) as well as the build.xml target and fails the build if one of the tools fails.
5. What is emma and what is its output?
Emma outputs statistics about which lines of code were executed and which ones were skipped. Breaks down the statistics by package and source files.
6. What are the 3 prime directives?
1. The system accomplishes a useful task.
2. An external user can successfully install and use the system.
3. An external developer can successfully understand and enhance the system.
7. What is the GNU project?
It is a Linux based open source operating system which strives to function with open and non open source software.
8. What are the difference in implementation of automated and manual quality assurance?
Manual: Actual writing of tests cases with JUnit, manually reviewing source code.
Automated: Uses coverage tools (CheckStyle, PMD, ect) to run tests on code.
9. How do you download someone else's code from Google Hosting?
Under the "Source" tab on Google Hosting you have two options:
1. You are part of the project so you checkout the https:// link to be able to work on and update the code.
2. You are not part of the project so you download the http:// link in order to view and modify the code but not be able to update the actual hosted code.
10. Write the FizzBuzz program.
1. What is the difference between "white box" and "black box" testing?
Black Box: Design a set of test cases to see if inputs match the desired outputs. Can also catch errors of omission. No access to source code required.
White Box: Use of coverage tools (CheckStyle, ect) to find bugs. Can catch code that has been writen.
2. Why is Subversion so helpful to software development?
Allows for multiple versions to be stored in a database.
Supports optimistic locking and all files are available for check out so that multiple users can edit the same file at one time.
3. What is the purpose of Ant?
Ant provides cross platform coverage tools that execute specific xml targets which performs a white box testing of the specified code.
4. What does the task "ant -f verify.build.xml" do?
This command runs all available tools (CheckStyle, FindBugs, JUnit, ect) as well as the build.xml target and fails the build if one of the tools fails.
5. What is emma and what is its output?
Emma outputs statistics about which lines of code were executed and which ones were skipped. Breaks down the statistics by package and source files.
6. What are the 3 prime directives?
1. The system accomplishes a useful task.
2. An external user can successfully install and use the system.
3. An external developer can successfully understand and enhance the system.
7. What is the GNU project?
It is a Linux based open source operating system which strives to function with open and non open source software.
8. What are the difference in implementation of automated and manual quality assurance?
Manual: Actual writing of tests cases with JUnit, manually reviewing source code.
Automated: Uses coverage tools (CheckStyle, PMD, ect) to run tests on code.
9. How do you download someone else's code from Google Hosting?
Under the "Source" tab on Google Hosting you have two options:
1. You are part of the project so you checkout the https:// link to be able to work on and update the code.
2. You are not part of the project so you download the http:// link in order to view and modify the code but not be able to update the actual hosted code.
10. Write the FizzBuzz program.
Saturday, October 10, 2009
Hosting and Subversion
I found that Google makes hosting open source projects extremely easy. The hardest part of this assignment was actually learning how to get TortoiseSVN to upload my files to Google hosting. However after that it was all downhill and fairly simple.
Overall Results:
I was able to complete this assignment with out omitting any steps. I found that Google's user interface was very straight forth and easy to navigate and execute desired operations. Also I liked how Google Code Hosting has all the project information on one webpage ranging from the Wiki pages to the code for the robot.
Difficulties:
I found that it was hard to use TortoiseSVN to do the initial upload of files to Google Code Hosting. After watching the screencast for the week I thought that TortoiseSVN would have a similar interface for uploading as SmartSVN. However I found that there was so such interface and I had to fool around a little with TortoiseSVN until I finally figured out how to upload the files. In order to upload in TortoiseSVN you follow the same basic steps as SmartSVN in that you create a new folder and copy and paste the files you want into it. Then in TortoiseSVN you have to select the files and folders you want to upload (or the root directory would work too I think), right click and select the TortoiseSVN option. Then you have to click "add" and select the files you would like to add to the project. After that you can right click the root directory of the project and select the "SVN Commit..." button which will then proceed to as you to log in and then will upload all of your files to Google Code Hosting.
BlackMagic Code Site:
The BlackMagic site can be found here.
Overall Results:
I was able to complete this assignment with out omitting any steps. I found that Google's user interface was very straight forth and easy to navigate and execute desired operations. Also I liked how Google Code Hosting has all the project information on one webpage ranging from the Wiki pages to the code for the robot.
Difficulties:
I found that it was hard to use TortoiseSVN to do the initial upload of files to Google Code Hosting. After watching the screencast for the week I thought that TortoiseSVN would have a similar interface for uploading as SmartSVN. However I found that there was so such interface and I had to fool around a little with TortoiseSVN until I finally figured out how to upload the files. In order to upload in TortoiseSVN you follow the same basic steps as SmartSVN in that you create a new folder and copy and paste the files you want into it. Then in TortoiseSVN you have to select the files and folders you want to upload (or the root directory would work too I think), right click and select the TortoiseSVN option. Then you have to click "add" and select the files you would like to add to the project. After that you can right click the root directory of the project and select the "SVN Commit..." button which will then proceed to as you to log in and then will upload all of your files to Google Code Hosting.
BlackMagic Code Site:
The BlackMagic site can be found here.
Wednesday, October 7, 2009
Robotesting
Creating tests for my robot was actually quite a difficult process. I ran into various problems which all revolved around me placing the test files in the wrong directory. These were easily solved by placing the files in the correctly location.
I created 2 acceptance tests, 1 behavioral test as well as 1 unit test. For my acceptance tests I pit BlackMagic against SittingDuck and Crazy respectively. For the behavioral test I made sure that my robot's first few moves are to the middle of the battlefield. Lastly for my unit test I made sure that the targeting method for BlackMagic was correct.
At first I found the tests hard to create as I have never done Junit testing before. However as I created more tests I became more comfortable with it. Unfortunately I was not able to reach the specified 6 tests due to the design BlackMagic. Because BlackMagic moves in a random fashion it is nearly impossible to test it's movements. Also the targeting is set to fire ahead of the enemy so it is hard to confirm that my bullets will hit every time. Lastly BlackMagic is very simple and uses very few lines of code which made unit testing even harder.
Considering that BlackMagic is such a random robot I believe that my tests were adequate enough to ensure the quality of my robot as I think that my tests covered almost all the possible inputs for my unit test and I ran multiple tests to confirm that my acceptance tests passed consistently (0% failure).
As far as emma goes in my BlackMagic file I used 100% of the methods and classes, however I only used 94% of the blocks and 93% of the lines. This was due to the fact that the lines specifying what to do if a enemy got too close were never executed. As for the test files, all of them were at 100% for all categories.
If I were to redesign BlackMagic to make it easier to test, I would change its movement from random to a pattern form and also I would add in a more extensive response for when an enemy hits BlackMagic. This would allow for more methods to unit test as well as a more rounded robot.
The current distribution for BlackMagic can be found here.
I created 2 acceptance tests, 1 behavioral test as well as 1 unit test. For my acceptance tests I pit BlackMagic against SittingDuck and Crazy respectively. For the behavioral test I made sure that my robot's first few moves are to the middle of the battlefield. Lastly for my unit test I made sure that the targeting method for BlackMagic was correct.
At first I found the tests hard to create as I have never done Junit testing before. However as I created more tests I became more comfortable with it. Unfortunately I was not able to reach the specified 6 tests due to the design BlackMagic. Because BlackMagic moves in a random fashion it is nearly impossible to test it's movements. Also the targeting is set to fire ahead of the enemy so it is hard to confirm that my bullets will hit every time. Lastly BlackMagic is very simple and uses very few lines of code which made unit testing even harder.
Considering that BlackMagic is such a random robot I believe that my tests were adequate enough to ensure the quality of my robot as I think that my tests covered almost all the possible inputs for my unit test and I ran multiple tests to confirm that my acceptance tests passed consistently (0% failure).
As far as emma goes in my BlackMagic file I used 100% of the methods and classes, however I only used 94% of the blocks and 93% of the lines. This was due to the fact that the lines specifying what to do if a enemy got too close were never executed. As for the test files, all of them were at 100% for all categories.
If I were to redesign BlackMagic to make it easier to test, I would change its movement from random to a pattern form and also I would add in a more extensive response for when an enemy hits BlackMagic. This would allow for more methods to unit test as well as a more rounded robot.
The current distribution for BlackMagic can be found here.
Monday, September 28, 2009
BlackMagic Ver. 1.1.930
The first step that I did to create Ver. 1.1 of the BlackMagic robot was to use a build system (Ant) to run tests and error check it. I used the following commands to ensure my code was up to date and error free:
ant -f checkstyle.build.xml
ant -f pmd.build.xml
ant -f findbugs.build.xml
CheckStyle:
During my first run of CheckStyle I ran into the following errors:
Got an exception - java.lang.IllegalArgumentException: the name [date] is not a valid Javadoc tag name
Missing package-info.java file.
The 2nd error was easily fixed by copying and modifying the package.html into /src/smw from the DaCruzer package.
After fixing that error I ran CheckStyle again and encountered the following errors on multiple occasions:
'{' is not preceded with whitespace.
Missing a Javadoc comment.
'while' is not followed by whitespace.
First sentence should end with a period.
Unused @param tag for 'a'.
Expected @param tag for 'e'.
The spacing error and the Javadoc comment errors were easily taken care of. The @param errors were taken care of by adding in the input variable name to the @param comment. For example a method takes (onHitWall e) so the comment is too look like this @param e .... but my comments were formatted in the following way @param .... with out the variable name.
After fixing these errors I ran CheckStyle again and had the following error remaining:
Missing package-info.java file.
This was easily fixed by adding in the overview.html file to /src.
Upon running CheckStyle again I encountered no errors.
PMD:
Luckily PDM built with no errors.
FindBugs:
Just like PMD this target built with no errors.
Improved Performance:
After loosing in the 2nd round of the Robocode tournament to a walls based robot and seeing how many robots were based on the walls model, I realized that I needed to integrate an anti-walls section to my robot. However this was extremely hard to implement given BlackMagic's current movement scheme, so instead I added a method which increased my victory percentage against walls, but I was still unable to consistently beat walls. My hope is that BlackMagic Ver. 1.1 will be able to beat other non-wall based robots more effectively.
Distribution:
The latest version of BlackMagic can be found here.
ant -f checkstyle.build.xml
ant -f pmd.build.xml
ant -f findbugs.build.xml
CheckStyle:
During my first run of CheckStyle I ran into the following errors:
Got an exception - java.lang.IllegalArgumentException: the name [date] is not a valid Javadoc tag name
Missing package-info.java file.
The 2nd error was easily fixed by copying and modifying the package.html into /src/smw from the DaCruzer package.
After fixing that error I ran CheckStyle again and encountered the following errors on multiple occasions:
'{' is not preceded with whitespace.
Missing a Javadoc comment.
'while' is not followed by whitespace.
First sentence should end with a period.
Unused @param tag for 'a'.
Expected @param tag for 'e'.
The spacing error and the Javadoc comment errors were easily taken care of. The @param errors were taken care of by adding in the input variable name to the @param comment. For example a method takes (onHitWall e) so the comment is too look like this @param e .... but my comments were formatted in the following way @param .... with out the variable name.
After fixing these errors I ran CheckStyle again and had the following error remaining:
Missing package-info.java file.
This was easily fixed by adding in the overview.html file to /src.
Upon running CheckStyle again I encountered no errors.
PMD:
Luckily PDM built with no errors.
FindBugs:
Just like PMD this target built with no errors.
Improved Performance:
After loosing in the 2nd round of the Robocode tournament to a walls based robot and seeing how many robots were based on the walls model, I realized that I needed to integrate an anti-walls section to my robot. However this was extremely hard to implement given BlackMagic's current movement scheme, so instead I added a method which increased my victory percentage against walls, but I was still unable to consistently beat walls. My hope is that BlackMagic Ver. 1.1 will be able to beat other non-wall based robots more effectively.
Distribution:
The latest version of BlackMagic can be found here.
Monday, September 21, 2009
Competition Robot
Design:
The design for this robot's movement is stemmed from a math error that I made while attempting another design. At first I hoped the have the robot move to the top middle, then move down in a 45 degrees, turn around go back up and then go down the other side at a 45 degree angle, repeating this movement pattern until the end of the match. However due to a math error, I found that I could make the robot's movement erratic, so I decided to keep this design. The downside is that the robot will sometimes follow it's previous path, thus making it susceptible to being hit from shots that were fired behind it.
The shooting design of this robot is meant to hit moving targets. It seems that this robot is most accurate while making turns, however it does have an ability to hit targets on the run due to a change in turret's position. When up close with the enemy, this robot will fire, move back, turn and fire again then continue moving around the battlefield.
My robot named BlackMagic can be found here.
Victory:
This robot can effectively beat the following sample robots: Corners, Fire, SittingDuck, Crazy, SpinBot and Tracker. This is due to the fact that many of these are stationary, or the fact that the movement pattern of my robot is able to evade most of the shots fired and it was able to return fire with a high rate of success.
Defeat:
My robot is unable to reliably beat the following robots: Walls and RamFire. It seems that walls moves too fast for my distance shots to be effective and also the when my robot repeats it's movements it literally runs into bullets fired by walls. As for RamFire, my robot does not have an effective way to get out of being cornered by RamFire. If the battle is kept in the middle of the field my robot usually can win. However when the battle moves to the sides it usually gets trapped and RamFire is able to take advantage of that and finish off my robot.
Lessons Learned:
After analyzing the battles, I realized that I need a more effective strategy to deal with robots that corner or force my robot to the edges, where they can do huge amounts of damage. Also I learned that an inconsistent movement really works in evading fire from the enemy, however retracing the route that the robot just executed could have disastrous results as it may run into bullets that were previously fired by an enemy robot.
The design for this robot's movement is stemmed from a math error that I made while attempting another design. At first I hoped the have the robot move to the top middle, then move down in a 45 degrees, turn around go back up and then go down the other side at a 45 degree angle, repeating this movement pattern until the end of the match. However due to a math error, I found that I could make the robot's movement erratic, so I decided to keep this design. The downside is that the robot will sometimes follow it's previous path, thus making it susceptible to being hit from shots that were fired behind it.
The shooting design of this robot is meant to hit moving targets. It seems that this robot is most accurate while making turns, however it does have an ability to hit targets on the run due to a change in turret's position. When up close with the enemy, this robot will fire, move back, turn and fire again then continue moving around the battlefield.
My robot named BlackMagic can be found here.
Victory:
This robot can effectively beat the following sample robots: Corners, Fire, SittingDuck, Crazy, SpinBot and Tracker. This is due to the fact that many of these are stationary, or the fact that the movement pattern of my robot is able to evade most of the shots fired and it was able to return fire with a high rate of success.
Defeat:
My robot is unable to reliably beat the following robots: Walls and RamFire. It seems that walls moves too fast for my distance shots to be effective and also the when my robot repeats it's movements it literally runs into bullets fired by walls. As for RamFire, my robot does not have an effective way to get out of being cornered by RamFire. If the battle is kept in the middle of the field my robot usually can win. However when the battle moves to the sides it usually gets trapped and RamFire is able to take advantage of that and finish off my robot.
Lessons Learned:
After analyzing the battles, I realized that I need a more effective strategy to deal with robots that corner or force my robot to the edges, where they can do huge amounts of damage. Also I learned that an inconsistent movement really works in evading fire from the enemy, however retracing the route that the robot just executed could have disastrous results as it may run into bullets that were previously fired by an enemy robot.
Wednesday, September 16, 2009
Sample Code Analysis
To better understand the samples provided with the Robocode package, I will be analyzing 8 sample robots in the areas of movement, tracking and firing.
Walls:
Movement: Regardless of starting position this robot will always face the the nearest wall with the least angle movement to face the wall. The robot will then head to that wall and move to the closest corner. From there the robot will move clockwise around the walls of the arena. If this robot hits another it will reverse, do a left turn then head to the nearest wall, move to the corner and continue moving along the walls.
Targeting: There is no targeting algorithm for this robot. Simply if a robot is scanned this robot will open fire on it.
Firing: The only criteria for firing is when a robot is scanned.
RamFire:
Movement: Movement is determined by the enemy robot's position. Once an enemy is scanned the RamFire will then move up to it and ram into it. In the case that the robot has moved, RamFire will follow it.
Targeting: The tank moves until it scans a robot then the gun is pointed at the enemy.
Firing: Firing is initiated once the RamFire has rammed into the robot it is targeting. Firing continues until the enemy moves.
SpinBot:
Movement: SpinBot moves in circles continuously in one spot.
Targeting: There is no targeting algorithm besides scanning.
Firing: SpinBot fires when a enemy robot is scanned.
Crazy:
Movement: This robot will move forward and turn right, but keep moving while making the right turn, then it will turn 180 degrees to the left while still moving, after that the robot makes a 180 degree right turn while moving. This process is repeated forever. When it hits a wall the direction is reversed.
Targeting: There is no targeting algorithm besides scanning.
Firing: Crazy fires when an enemy robot is scanned.
Fire:
Movement: This robot only moves when it is hit in which case it makes a right turn and moves 50 pixels the first time. With each hit the amount moved decreases by 1 pixel.
Targeting: There is no targeting algorithm besides scanning.
Firing: If Fire has more than 50 energy and the enemy is less than 50 pixels away, the robot will fire at power 3, else it only fires at power 1.
Sitting Duck:
Movement: This robot doesn't move.
Targeting: This robot doesn't target other robots.
Firing: This robot doesn't fire on enemy robots.
Corners:
Movement: Regardless of the robots position, it will turn to face the north wall, go to the wall and make a left turn and move all the way to the top left corner.
Targeting: There is no targeting algorithm besides scanning.
Firing: Corners fires proportional to the distance of the enemy or current energy level. In the first case if the enemy's distance is less than 200 or the energy level is greater than 15, the robot will fire at power one. If the enemy robot's distance is less than 50 Corners will fire at power 2. Otherwise the robot will fire at power 3.
Tracker:
Movement: Tracker's movement rate is determined by the enemy that it is tracking. Once Tracker finds an enemy, it will move to 140 pixels of its position and either wait or fire on the enemy robot. Also if the enemy is too close (within 100 pixels) Tracker will move back in the enemy has a position of less than -90 degrees and equal or less than 90 degrees. Else it moves ahead 40 pixels.
Targeting: Once the enemy is scanned the gun will move to face the enemy. It will re-rotate every time Tracker is tracking an enemy.
Firing: The gun will always fire at the power of 3.
Conclusion:
I think that a lot of basic structures for movement and tracking can be learned from these sample robots. I know while designing my robots I would often look to these sample robots to gain inspiration or to review and adapt algorithms that were used.
Walls:
Movement: Regardless of starting position this robot will always face the the nearest wall with the least angle movement to face the wall. The robot will then head to that wall and move to the closest corner. From there the robot will move clockwise around the walls of the arena. If this robot hits another it will reverse, do a left turn then head to the nearest wall, move to the corner and continue moving along the walls.
Targeting: There is no targeting algorithm for this robot. Simply if a robot is scanned this robot will open fire on it.
Firing: The only criteria for firing is when a robot is scanned.
RamFire:
Movement: Movement is determined by the enemy robot's position. Once an enemy is scanned the RamFire will then move up to it and ram into it. In the case that the robot has moved, RamFire will follow it.
Targeting: The tank moves until it scans a robot then the gun is pointed at the enemy.
Firing: Firing is initiated once the RamFire has rammed into the robot it is targeting. Firing continues until the enemy moves.
SpinBot:
Movement: SpinBot moves in circles continuously in one spot.
Targeting: There is no targeting algorithm besides scanning.
Firing: SpinBot fires when a enemy robot is scanned.
Crazy:
Movement: This robot will move forward and turn right, but keep moving while making the right turn, then it will turn 180 degrees to the left while still moving, after that the robot makes a 180 degree right turn while moving. This process is repeated forever. When it hits a wall the direction is reversed.
Targeting: There is no targeting algorithm besides scanning.
Firing: Crazy fires when an enemy robot is scanned.
Fire:
Movement: This robot only moves when it is hit in which case it makes a right turn and moves 50 pixels the first time. With each hit the amount moved decreases by 1 pixel.
Targeting: There is no targeting algorithm besides scanning.
Firing: If Fire has more than 50 energy and the enemy is less than 50 pixels away, the robot will fire at power 3, else it only fires at power 1.
Sitting Duck:
Movement: This robot doesn't move.
Targeting: This robot doesn't target other robots.
Firing: This robot doesn't fire on enemy robots.
Corners:
Movement: Regardless of the robots position, it will turn to face the north wall, go to the wall and make a left turn and move all the way to the top left corner.
Targeting: There is no targeting algorithm besides scanning.
Firing: Corners fires proportional to the distance of the enemy or current energy level. In the first case if the enemy's distance is less than 200 or the energy level is greater than 15, the robot will fire at power one. If the enemy robot's distance is less than 50 Corners will fire at power 2. Otherwise the robot will fire at power 3.
Tracker:
Movement: Tracker's movement rate is determined by the enemy that it is tracking. Once Tracker finds an enemy, it will move to 140 pixels of its position and either wait or fire on the enemy robot. Also if the enemy is too close (within 100 pixels) Tracker will move back in the enemy has a position of less than -90 degrees and equal or less than 90 degrees. Else it moves ahead 40 pixels.
Targeting: Once the enemy is scanned the gun will move to face the enemy. It will re-rotate every time Tracker is tracking an enemy.
Firing: The gun will always fire at the power of 3.
Conclusion:
I think that a lot of basic structures for movement and tracking can be learned from these sample robots. I know while designing my robots I would often look to these sample robots to gain inspiration or to review and adapt algorithms that were used.
Saturday, September 12, 2009
Robo Revisions
Revisions:
Reviewing other student's code allowed me to adapt more effective solutions to my robots especially the robot that needed to move to the center. Now instead of going to the corner and then half way down the height and moving half way across the width, I now have a solution to move to the middle from any point. As I suspected the Pythagorean Theory was the key, however I was unable to implement it correctly in my first try. My modified robots jar file can be downloaded here.
Coding Standards:
Until now I only thought of coding standards as ways for me to better organize my own code for my own reference. However now that we are reviewing other students code I realized that coding standards play a key role. Without these standards understanding others code could have the potential to be a daunting task. Also coding standards requires comments which further allows others to understand your methods and the coding in the main method.
Reviewing other student's code allowed me to adapt more effective solutions to my robots especially the robot that needed to move to the center. Now instead of going to the corner and then half way down the height and moving half way across the width, I now have a solution to move to the middle from any point. As I suspected the Pythagorean Theory was the key, however I was unable to implement it correctly in my first try. My modified robots jar file can be downloaded here.
Coding Standards:
Until now I only thought of coding standards as ways for me to better organize my own code for my own reference. However now that we are reviewing other students code I realized that coding standards play a key role. Without these standards understanding others code could have the potential to be a daunting task. Also coding standards requires comments which further allows others to understand your methods and the coding in the main method.
Wednesday, September 9, 2009
Robowars!
In preparation for an all out robowar I have successfully created a series of 13 basic robots that outlined basic functions a serious robot should have such as tracking enemies, firing on enemies as well as basic movement behavior. The coding for my robots can be found here.
The requirements for designing sample robots is as follows:
Movement:
I had no problems coding the first 3 movement robots and the onHitWall even made it really easy to program the second robot. However the trouble came when I had to have the robot move to the center of the field (the 4th movement). Immediately I suspected that some sort of triangulation via the Pythagorean Theorem however after numerous tries I was unable to figure out how to consistently triangulate the center so instead I had the robot move to the left top corner, move half way down the move half way in. The next problem was with the 6th movement. Using the previously mentioned I was able to get the robot to the center, however I had problems moving in a circle without using the AdvancedRobot methods, so instead I used a for loop and created a slow moving circle.
Tracking:
I was kind of lost when it came to the tracking methods, so I borrowed and modified code from the tracking.java sample robot from the Robocode files. After reviewing and analyzing the code in order to understand it, tracking became easier to understand and it was easier to modify the code that I had borrowed.
Firing:
Again like the tracking methods I was unsure of how to use the firing methods so I borrowed some code from the fire.java sample robot to get me started. Just like the tracking robot I analyzed the code to understand it, then began to modify the coding appropriately. The hardest part about the firing section robots was the Firing03 robot which required fire power proportional to the distance of the enemy. The further away the less power was to be used. In order to do this I took the max fire power for the robot (which happens to be 3) and then took 3% of the distance to the enemy and subtracted it from three thus creating the desired fire rates.
Conclusion:
It took a while for me to understand the coding for tracking however once I got the hang of it things were a lot easier to code. At first I thought there was a tracking method call, but I realized that robots automatically scan and that in order to track I needed to use the onScannedRobot method call. Also I realized that geometry will play a huge part in creating a successful robot as geometry influences movement, firing and even tracking an enemy robot. With that said I think its time for me to hit the books to review my geometry.
The requirements for designing sample robots is as follows:
- Movement01: The minimal robot. Does absolutely nothing at all.
- Movement02: Move forward a total of 50 pixels per turn. If you hit a wall, reverse direction.
- Movement03: Each turn, move forward a total of N pixels per turn, then turn left. N is initialized to 10, and increases by 10 per turn.
- Movement04: Move to the center of the playing field and stop.
- Movement05: Move to the upper left corner. Then move to the lower right corner. Then move to the upper right corner. Then move to the lower left corner.
- Movement06: Move to the center, then move in a circle, ending up where you started.
- Tracking01: Pick one enemy and follow them.
- Tracking02: Pick one enemy and follow them, but stop if your robot gets within 20 pixels of them.
- Tracking03: Each turn, Find the closest enemy, and move in the opposite direction by 100 pixels, then stop.
- Firing01: Sit still. Rotate gun. When it is pointing at an enemy, fire.
- Firing02: Sit still. Pick one enemy. Only fire your gun when it is pointing at the chosen enemy.
- Firing03: Sit still. Rotate gun. When it is pointing at an enemy, use bullet power proportional to the distance of the enemy from you. The farther away the enemy, the less power your bullet should use (since far targets increase the odds that the bullet will miss).
- Firing04: Sit still. Pick one enemy and attempt to track it with your gun. In other words, try to have your gun always pointing at that enemy. Don't fire (you don't want to kill it).
Movement:
I had no problems coding the first 3 movement robots and the onHitWall even made it really easy to program the second robot. However the trouble came when I had to have the robot move to the center of the field (the 4th movement). Immediately I suspected that some sort of triangulation via the Pythagorean Theorem however after numerous tries I was unable to figure out how to consistently triangulate the center so instead I had the robot move to the left top corner, move half way down the move half way in. The next problem was with the 6th movement. Using the previously mentioned I was able to get the robot to the center, however I had problems moving in a circle without using the AdvancedRobot methods, so instead I used a for loop and created a slow moving circle.
Tracking:
I was kind of lost when it came to the tracking methods, so I borrowed and modified code from the tracking.java sample robot from the Robocode files. After reviewing and analyzing the code in order to understand it, tracking became easier to understand and it was easier to modify the code that I had borrowed.
Firing:
Again like the tracking methods I was unsure of how to use the firing methods so I borrowed some code from the fire.java sample robot to get me started. Just like the tracking robot I analyzed the code to understand it, then began to modify the coding appropriately. The hardest part about the firing section robots was the Firing03 robot which required fire power proportional to the distance of the enemy. The further away the less power was to be used. In order to do this I took the max fire power for the robot (which happens to be 3) and then took 3% of the distance to the enemy and subtracted it from three thus creating the desired fire rates.
Conclusion:
It took a while for me to understand the coding for tracking however once I got the hang of it things were a lot easier to code. At first I thought there was a tracking method call, but I realized that robots automatically scan and that in order to track I needed to use the onScannedRobot method call. Also I realized that geometry will play a huge part in creating a successful robot as geometry influences movement, firing and even tracking an enemy robot. With that said I think its time for me to hit the books to review my geometry.
Sunday, August 30, 2009
How to get a programming job
The FizzBuzz program is used by some employers to test the programming abilities of the workers that they are attempting to hire. FizzBuzz is a simple program that loops through numbers 1-100 and prints out "Fizz" if the number is a multiple of 3, "Buzz" if the number is a multiple of 5 and "FizzBuzz" if the number is a multiple of both 3 and 5.
Ready, set, go!
The FizzBuzz program took me a total of 5 minutes to complete including the time it took to write comments. Below is the code that I implemented:
Errors
Unfortunately I ran into errors with Eclipse during this project. It started with Eclipse taking close to 2 minutes to open and eventually to its current state where it will not even boot up. Because I had no time to spare while doing this project I hastily tried uninstalling and reinstalling Eclipse with no change in its behavior so I turned to the next best thing and used a program called Notepad ++ to code my FizzBuzz. While this is a lot harder than using a compiler as it does not correct your coding should there be an error, it is manageable with such a small program as this one. I will continue to work on solving this problem and hopefully will have Eclipse up and running again by the end of tonight.
Lessons learned
Through this experience I have learned that there is no substitute for a good compiler as it makes coding and testing a java file easier since the compiler will tell you when you have an error in your code and you can also test the file in the compiler instead of using the command line.
Ready, set, go!
The FizzBuzz program took me a total of 5 minutes to complete including the time it took to write comments. Below is the code that I implemented:
Errors
Unfortunately I ran into errors with Eclipse during this project. It started with Eclipse taking close to 2 minutes to open and eventually to its current state where it will not even boot up. Because I had no time to spare while doing this project I hastily tried uninstalling and reinstalling Eclipse with no change in its behavior so I turned to the next best thing and used a program called Notepad ++ to code my FizzBuzz. While this is a lot harder than using a compiler as it does not correct your coding should there be an error, it is manageable with such a small program as this one. I will continue to work on solving this problem and hopefully will have Eclipse up and running again by the end of tonight.
Lessons learned
Through this experience I have learned that there is no substitute for a good compiler as it makes coding and testing a java file easier since the compiler will tell you when you have an error in your code and you can also test the file in the compiler instead of using the command line.
Surfing with Dooble
Dooble is an open source web browser available through sourceforge.net (http://sourceforge.net/projects/dooble/) or at Dooble's website (http://dooble.sourceforge.net/). According to the description of the program Dooble focuses on user privacy and security and comes with a instant messaging program as well as an email program. However with this strong focus on security, is this web browser still able to meet the 3 prime directives?
System Functionality?
The first directive asks if the program was about to accomplish a useful task. After testing Dooble on a variety of websites containing different I am somewhat disappointed with its performance. Dooble has no problem surfing regular websites such as google or gamespot, however the problems start when Dooble attempts to navigate to secured sites. As an example I attempted to connect to paypal's web site, but Dooble will not display the page stating it has run into a network error. I then tried to connect to my bank's website but got the same error. So it seems that Dooble is unable to connect to sites that have security certificates, which I find ironic since this browser stresses security. I also ran into problems while attempting to play flash files. It seems that Dooble does not support Adobe Flash which means that watching online content such as TV episodes is not possible with this browser. Overall I enjoyed this browser while just surfing, but when it comes down to it, I would not be able to use this browser as it does not support secured websites as well as Adobe's Flash Player.
Ease of setup?
The second directive asks if a user can successfully install and use the system. Dooble successfully meets this directive from download to the actual running of the browser. Downloading from sourceforge was easy, the installation was simple and only asked where to install the program and the running of the program was simple, fast and easy. The only issue I would have with the installation is that the default installation location is not defaulted like most programs to C:\Program Files but instead is defaulted to the user's account, so in my case C:\Users\Scott Wong. This is a minor inconvenience if I wanted to access or edit the files as I am used to looking in C:\Program Files for the installed files.
Want to help develop Dooble?
The third directive asks if an external developer can successfully understand and enhance the system. This area is unfortunately another area in which Dooble runs into problems. While looking through the Dooble source code I noted two things. First of all the coding format itself is very neat and organized with appropriate indenting and spacing which made the code easy to read and follow. However the second thing I noticed was that the source code had almost no comments in most source code files or had sporadic commenting in other source code files. This is disappointing since my ICS teachers have always stressed the use of comments to allow others to understand my code. This also made the code hard to follow as I was unsure of what most of the code was trying to accomplish. Perhaps someone with a history of software development would be able to understand the code without comments, but seeing as I lack that experience I feel that this system does not meet the third directive.
To sum things up Dooble is a great way to surf the web if you have no intention of accessing secured sites or watching flash web content. The ease of downloading, installing and running Dooble enhances the experience and is a definite plus. However I believe that it will be a long and hard process if you intend to edit the source code as the lack of comments might leave you wondering what function you are really editing.
System Functionality?
The first directive asks if the program was about to accomplish a useful task. After testing Dooble on a variety of websites containing different I am somewhat disappointed with its performance. Dooble has no problem surfing regular websites such as google or gamespot, however the problems start when Dooble attempts to navigate to secured sites. As an example I attempted to connect to paypal's web site, but Dooble will not display the page stating it has run into a network error. I then tried to connect to my bank's website but got the same error. So it seems that Dooble is unable to connect to sites that have security certificates, which I find ironic since this browser stresses security. I also ran into problems while attempting to play flash files. It seems that Dooble does not support Adobe Flash which means that watching online content such as TV episodes is not possible with this browser. Overall I enjoyed this browser while just surfing, but when it comes down to it, I would not be able to use this browser as it does not support secured websites as well as Adobe's Flash Player.
Ease of setup?
The second directive asks if a user can successfully install and use the system. Dooble successfully meets this directive from download to the actual running of the browser. Downloading from sourceforge was easy, the installation was simple and only asked where to install the program and the running of the program was simple, fast and easy. The only issue I would have with the installation is that the default installation location is not defaulted like most programs to C:\Program Files but instead is defaulted to the user's account, so in my case C:\Users\Scott Wong. This is a minor inconvenience if I wanted to access or edit the files as I am used to looking in C:\Program Files for the installed files.
Want to help develop Dooble?
The third directive asks if an external developer can successfully understand and enhance the system. This area is unfortunately another area in which Dooble runs into problems. While looking through the Dooble source code I noted two things. First of all the coding format itself is very neat and organized with appropriate indenting and spacing which made the code easy to read and follow. However the second thing I noticed was that the source code had almost no comments in most source code files or had sporadic commenting in other source code files. This is disappointing since my ICS teachers have always stressed the use of comments to allow others to understand my code. This also made the code hard to follow as I was unsure of what most of the code was trying to accomplish. Perhaps someone with a history of software development would be able to understand the code without comments, but seeing as I lack that experience I feel that this system does not meet the third directive.
To sum things up Dooble is a great way to surf the web if you have no intention of accessing secured sites or watching flash web content. The ease of downloading, installing and running Dooble enhances the experience and is a definite plus. However I believe that it will be a long and hard process if you intend to edit the source code as the lack of comments might leave you wondering what function you are really editing.
Subscribe to:
Posts (Atom)