For this assignment, our professor decided not have a final exam, instead we were given the opportunity to improve our web apps. Since our last presentation, we took the critiques as the basis to improve our application. The critiques are mostly aesthetics that involves applying the best user interfaces given what our application is set out to do. These includes decreasing the size of our logo, which for some reason is supposed to be intuitive enough for us to realize and change right away, having default values for our grid info page and setting our pages so that they fit nicely with a lower resolution screen. The last problem provided a very typical mistake I think what novice programmers face when creating user interfaces, and that is we assume that people who eventually will use our application will have a similar computer set up just like ours. I learned from this class and the provided UI video lecture that we need to broaden our perspective to be able to account for a larger set of audience each having different different computer set ups.
Other than fixing our user interfaces our professor has given us some more functions to choose from as extra credit. We initially planned on doing five functions but as we go through our finals we wound up just doing two. Those two were the nice URL function and the AJAX stoplight page refresh. These function were not that bad to implement. Our team tried to learn AJAX just for this particular function. As for the function that didn't make it, date picker, and google visualization, we tried to implement them but were having problems that we just abandoned them. One thing to note is that during our presentation for version 2.1 we told how we were having problems with our date picker and one of our fellow classmates pointed out the bug. This made me realized that when an application is deployed, it's users can be very helpful in finding bugs. But I woudn't count on them because I learned from a different class that fixing programs already deployed are costlier than finding them during dvelopment.
All in all I really enjoyed working on this project. I also enjoyed working with my group. I'm really taking this experience as a good indication of how the professional programmers work in the real world since I plan on being one.
Saturday, December 19, 2009
Tuesday, November 24, 2009
Oscar WebApp Code Review: WattWaiter
For this assignment we are doing code reviews on our fellow classmates' Oscar web applications. I am reviewing team WattWaiter with Remy Baumgarten, David Mau and Kevin Chiogioji as members. This review is based on a new checklist that has some new points that includes Wiki Documentation, Software ICU, Issue Management and Continuous Integration.
My overall feel of the application is that it was designed, both the program and the application interface, very good so much so that it could almost be passed as professionally built. The negative things I have to say are mostly nitpicks that this checklist looks for. Other than that it was a very robust application.
The full review can be found here.
The WattWaiter web app can be accessed here.
Monday, November 23, 2009
Ecologineers: Oscar Web Application
As we continue along working in bigger teams, we explore more and more on how to develop applications. For this assignment, my group from the previous WattDepot project got teamed up with another two man group. Just like my original group, we all worked perfectly together. We set up plans, delegated jobs and met up regularly. I had as much fun on this project just like the last one.
As for the proj
ect itself, it was very daunting at first to hear that were going to learn a new framework that were going to use for this project. Our professor repeatedly reminded us the importance of this framework during lectures and especially at the project screen cast. The reading (Wicket in Action by Martijn Dashorst and Eelco Hillenius) alone was a little hard to comprehend but just as other languages, you learn by doing it. We were given some example applications to show us how the new framework works. As we progressed on our project we quickly learned that Wicket wasn’t as bad as we thought it would be. It turned out to be straightforward. When we tried to implement Wicket with our code we had some small problems. One problem was actually merging the form and table page. We initially planned then delegated the two jobs to two of our people, one of them being me. When we tried to merge the two together we hit some snags where our Wicket tags were not being passed into the HTML tags. Another problem, which I think was a big one, is that our color tags won’t render the color. Since we ran out of time we just left it as is which instead of passing the HTML color it passes the color words instead.
Since we were introduce to Software ICU in the last project. We also implemented it for this project. From the look of the screen shot from above, our coverage was fair since we only had six test cases. Our devTime, Commit, and Build has some steep increase because even though we did the initial set up then met up regularly and discussed the plan, we didn’t actually started to code until weekend.
All in all I really enjoyed working on this project and not to mention with my group. I really got a feel on how to develop real word applications. This is also a good project to learn good sustainability practices since any user can download, run and use our application to help decide when to use or not use an appliance.
Our project site can be accessed here and our distribution file here.
As for the proj
ect itself, it was very daunting at first to hear that were going to learn a new framework that were going to use for this project. Our professor repeatedly reminded us the importance of this framework during lectures and especially at the project screen cast. The reading (Wicket in Action by Martijn Dashorst and Eelco Hillenius) alone was a little hard to comprehend but just as other languages, you learn by doing it. We were given some example applications to show us how the new framework works. As we progressed on our project we quickly learned that Wicket wasn’t as bad as we thought it would be. It turned out to be straightforward. When we tried to implement Wicket with our code we had some small problems. One problem was actually merging the form and table page. We initially planned then delegated the two jobs to two of our people, one of them being me. When we tried to merge the two together we hit some snags where our Wicket tags were not being passed into the HTML tags. Another problem, which I think was a big one, is that our color tags won’t render the color. Since we ran out of time we just left it as is which instead of passing the HTML color it passes the color words instead.
Since we were introduce to Software ICU in the last project. We also implemented it for this project. From the look of the screen shot from above, our coverage was fair since we only had six test cases. Our devTime, Commit, and Build has some steep increase because even though we did the initial set up then met up regularly and discussed the plan, we didn’t actually started to code until weekend.
All in all I really enjoyed working on this project and not to mention with my group. I really got a feel on how to develop real word applications. This is also a good project to learn good sustainability practices since any user can download, run and use our application to help decide when to use or not use an appliance.
Our project site can be accessed here and our distribution file here.
Monday, November 16, 2009
WattDepot-Cli 2.0: Second time is the charm!
As we wrap up on our WattDepot-Cli project we gain more perspective on how the software development works. In this assignment we are to update, improve and add new commands to our version 1.0 of WattDepot. We are still working with our initial partners and as for our group, it has never been better. Even from the start of this project my partner and I communicated every other day and delegated jobs. Our jobs weren’t so concrete which gave us a little flexibility so that we can do other things outside of this class. We also met twice a week not including the time we spent working on our projects in class. All in all my experience with my partner in producing the WattDepot client was a pleasant one.
In terms of our client, we have improved our methods by reviewing the changes in the commands provided in the WattDepot wiki and suggestions coming from last week’s code review. One of the things we did was to add the necessary comments and improve our Javadoc so that any developer can understand our code and use our API for reference. We also have added more test cases. Most are still happy-path tests but now we’ve included some behavioral test such as our validation tests. Even with more test cases our coverage is still under the healthy 90%. Our coverage is 63% because some of the new commands and old commands didn’t get tested. Other than the coverage being low, we did find that writing test cases was much easier when we refactored the commands into their own classes.
As for new materials that we learned, we used a program that displays the current condition of our program. It is called Hackystat. Hackystat retrieves information from our local and Hudson builds and the amount of time we spend in Eclipse. It measures and displays different categories that are pointed to the overall health of our program.
Here’s a screen shot of our program information.
The overall health of our program is a little stable. The reason for this is because of the lack of testing (30%) which consequently affected the coverage. The screen shot also shows the increasing trends of our development time commit and build because we worked on it mostly on the last four days before the due date.
The last part of this assignment is to answer some question regarding information that we gather from our program.
Our Wattdepot client version 2.0 can be found here.
In terms of our client, we have improved our methods by reviewing the changes in the commands provided in the WattDepot wiki and suggestions coming from last week’s code review. One of the things we did was to add the necessary comments and improve our Javadoc so that any developer can understand our code and use our API for reference. We also have added more test cases. Most are still happy-path tests but now we’ve included some behavioral test such as our validation tests. Even with more test cases our coverage is still under the healthy 90%. Our coverage is 63% because some of the new commands and old commands didn’t get tested. Other than the coverage being low, we did find that writing test cases was much easier when we refactored the commands into their own classes.
As for new materials that we learned, we used a program that displays the current condition of our program. It is called Hackystat. Hackystat retrieves information from our local and Hudson builds and the amount of time we spend in Eclipse. It measures and displays different categories that are pointed to the overall health of our program.
Here’s a screen shot of our program information.
The overall health of our program is a little stable. The reason for this is because of the lack of testing (30%) which consequently affected the coverage. The screen shot also shows the increasing trends of our development time commit and build because we worked on it mostly on the last four days before the due date.
The last part of this assignment is to answer some question regarding information that we gather from our program.
- What day and time during the month was Oahu energy usage at its highest? How many MW was this?
- What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
- What day during the month did Oahu consume the most energy? How many MWh was this?
- What day during the month did Oahu consume the least energy? How many MWh was this?
- What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
- What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
Our Wattdepot client version 2.0 can be found here.
Wednesday, November 11, 2009
Code Review: A subtle but rewarding learning experience
Some people might not like the fact that their code is to be reviewed or to be the person who does it but I believe that there is a rewarding experience that results from this experience. I, for one, value the effort a person did to look how our overall product came out to be, some of which say that we didn’t commented enough for them to understand our code. Besides having a working system, our class’s third prime directive states that our code should have a good developer-level documentation that provides the inner workings and therefore should make it easy for them to understand and expand. This is particularly true in our assignment which taught me a valuable lesson since we have to create our user interface client upon the WattDepot system. The documentation on the WattDepot system helped us implement the commands that were assigned. Another comment I took into consideration was the design which didn’t really surprised me since we didn’t follow the design requirement. Our system grouped all the commands into one class instead of having each one of them in its own class. This is particularly an important point since it restricts our system’s extensibility. This design is now an important part because we are adding more commands into our client and this task would’ve made our jobs a lot easier. This I also think that the checklist that our review is based on also helped on how I will improve our client. All of our command methods are expressed to have “side effects” and therefore is a design problem that we have to address.
Overall I found this assignment worthwhile. Having another person not just examines but also gives suggestions on how to improve our system is a good way for me to actually be a good programmer. Not only did I have fun working with my partner but I also enjoyed reviewing other people’s system and hope that they find it helpful.
Overall I found this assignment worthwhile. Having another person not just examines but also gives suggestions on how to improve our system is a good way for me to actually be a good programmer. Not only did I have fun working with my partner but I also enjoyed reviewing other people’s system and hope that they find it helpful.
Monday, November 9, 2009
WattDepot Client Code Review
After working for more than a week on the WattDepot client, we have to review our fellow classmates' client for this assignment. This review is generally a way for us learn how to both give constructive criticism based of a checklist and apply them to our existing code to improve upon for our upcoming updated release of the WattDepot client.
Eha
In general the client works good, it does what it supposed to do. Some of the things that I find a little weird was the chart output which has some rather small points and therefore a low chart considering that given the same arguments other clients produced a proportional chart. As for the design, the only thing is that it did not followed the design requirement of having each commands in it's own class. This is important so that the client supports extensibility considering our next assignment will have new commands.
The full review can be found here.
Elua
When I first tried to review this group's client I had some problems some problems such as not being able to run the jar file. After using Eclipse to run the client I encountered a bigger problem, for some reason only the 'help' and 'list summary' commands work and the rest didn't especially 'quit'. After some time they released a second version which only fixed the non-executing jar file and from that second build I based my review. Their client followed the proper requirements and all their commands worked perfectly. Their test cases were also some of the things that they have done a good job.
The full review can be found here.
Eha
In general the client works good, it does what it supposed to do. Some of the things that I find a little weird was the chart output which has some rather small points and therefore a low chart considering that given the same arguments other clients produced a proportional chart. As for the design, the only thing is that it did not followed the design requirement of having each commands in it's own class. This is important so that the client supports extensibility considering our next assignment will have new commands.
The full review can be found here.
Elua
When I first tried to review this group's client I had some problems some problems such as not being able to run the jar file. After using Eclipse to run the client I encountered a bigger problem, for some reason only the 'help' and 'list summary' commands work and the rest didn't especially 'quit'. After some time they released a second version which only fixed the non-executing jar file and from that second build I based my review. Their client followed the proper requirements and all their commands worked perfectly. Their test cases were also some of the things that they have done a good job.
The full review can be found here.
Wednesday, November 4, 2009
Full Scale Software Engineering Project: WattDepot
Continuing from my recent post about a new concept we learned, we get our hands on an interesting programming practice called Continuous Integration. For this assignment, we were partnered up and create a command line interface for the WattDepot system. WattDepot is a web service that collects information about Oahu’s energy and power production/consumption. My partner, David Joel Lazarro, and I had to implement various commands to be used on the stored WattDepot data. We planned on splitting the commands in two and as we started working on our commands, we got our first experience of practicing continuous integration. We initially didn’t get the hang of it. We rarely commit to our repository, waiting until a full working method, both tested and verified locally, before committing our changes. But as we progress in this project we learned how to properly practice it. We did have some problems such as fixing merge conflicts since we didn’t really have any set design plan. As our code continued to grow, we finally found a good rhythm that tied our code into a unified look.
As for WattDepot, we implemented all the commands that were assigned. This is one of the first times where I had to build on someone else’s code in this scale. Having a good documentation and API really helped me understand the inner workings of the WattDepot system. This reinforces the importance of the third prime directives first taught in this class. The commands were mixed in terms of implementation difficulty, but I noticed some recurring similarities within some consecutive commands, which made the whole thing not so bad. Halfway through our given time for this project we were told improve our design strategy and implementation. This threw us of a little. The new strategy is meant to improve the scalability, reusability and efficiency of the command line interface. My partner and I understood the design strategy that was shown to us and we tried to implement it but to no success. This is the reason why we didn’t really have some good test cases for this project. The new strategy could’ve helped us design better cases instead of having just acceptance tests. Our methods were designed in way that it is constrained by the parameters preventing us from testing the instances of commands. This would’ve been easily implemented if we followed the new strategy’s design of having the commands in separate classes.
All in all I thought this project gave me an insight to the world of software engineering. Planning and implementing this project was just as fun as meeting up and working with my partner. I also thought that having a project that teaches us the importance of sustainability, especially in these times, is a cool way to really get our attention.
Our distribution file: Ekahi.
As for WattDepot, we implemented all the commands that were assigned. This is one of the first times where I had to build on someone else’s code in this scale. Having a good documentation and API really helped me understand the inner workings of the WattDepot system. This reinforces the importance of the third prime directives first taught in this class. The commands were mixed in terms of implementation difficulty, but I noticed some recurring similarities within some consecutive commands, which made the whole thing not so bad. Halfway through our given time for this project we were told improve our design strategy and implementation. This threw us of a little. The new strategy is meant to improve the scalability, reusability and efficiency of the command line interface. My partner and I understood the design strategy that was shown to us and we tried to implement it but to no success. This is the reason why we didn’t really have some good test cases for this project. The new strategy could’ve helped us design better cases instead of having just acceptance tests. Our methods were designed in way that it is constrained by the parameters preventing us from testing the instances of commands. This would’ve been easily implemented if we followed the new strategy’s design of having the commands in separate classes.
All in all I thought this project gave me an insight to the world of software engineering. Planning and implementing this project was just as fun as meeting up and working with my partner. I also thought that having a project that teaches us the importance of sustainability, especially in these times, is a cool way to really get our attention.
Our distribution file: Ekahi.
Monday, November 2, 2009
Continuous Integration
For this assignment we were introduced to a new practice in software development called Continuous Integration. The main objective is to commit changes frequently so that any errors are quickly detected and easy enough to solve. This builds the repository gradually instead of committing a huge change that it doesn’t look as the original and committing these changes can lead to clobbering of update changes.
To practice continuous integration, we are using Hudson. The creation of a new job within Hudson fell to my partner. From what I saw him do, the set up went good and we were up and running in no time. The other tasks that fell onto me were to initially build within Hudson and then create a small change from my local copy and committing it. This ensured that Hudson detected the changes and it worked as such. The next task is to commit a broken code and check if Hudson’s build report shows a failed build. I then received an email report saying it did so. Lastly, we fixed the bug and committed the changes and made sure that Hudson’s build is back to normal.
After a couple of days of using Hudson and practicing continuous integration, I find it as something I would definitely use in the future. Besides the automatic email notifications of any build failures, I find the logic behind small incremental changes as something that can improve any team based projects. This approach reminds me of the divide-and-conquer strategy which applies to the planning and then implementation of creating software.
To practice continuous integration, we are using Hudson. The creation of a new job within Hudson fell to my partner. From what I saw him do, the set up went good and we were up and running in no time. The other tasks that fell onto me were to initially build within Hudson and then create a small change from my local copy and committing it. This ensured that Hudson detected the changes and it worked as such. The next task is to commit a broken code and check if Hudson’s build report shows a failed build. I then received an email report saying it did so. Lastly, we fixed the bug and committed the changes and made sure that Hudson’s build is back to normal.
After a couple of days of using Hudson and practicing continuous integration, I find it as something I would definitely use in the future. Besides the automatic email notifications of any build failures, I find the logic behind small incremental changes as something that can improve any team based projects. This approach reminds me of the divide-and-conquer strategy which applies to the planning and then implementation of creating software.
Sunday, October 18, 2009
Midterm Study Questions
Here are some study questions for the our midterm.
Update: Added the answer to the questions
1. What are the three prime directives?
7. What are some advantages of Git over SVN.
Update: Added the answer to the questions
1. What are the three prime directives?
- The system accomplishes a useful task
- An external user can install and use the system
- An external developer can understand and enhance the system
- Sets: no duplicates and add works differently
- SortedSet: traverses elements in their "natural order"
- List: Ordered collection and like an array with flexible size
- 2 space indent
- No tabs, only spaces.
- Left curly brace on preceding line; right curly brace on its own line
- 100 columns of text maximum maximum
- JavaDoc layout standards
- Java-based
- xml is simpler than a Makefile
- Built in Java support and its tools
- Easier to extend in a portable manner
- So that Ant downloads the necessary libraries needed
<target name="TestTarget"
description="Target that does nothing.">
</target>7. What are some advantages of Git over SVN.
- Allows users to work productively even when not connected to a network
- Makes most operations much faster since no network is involved
- Allows participation in projects without requiring permissions from project authorities
- Avoids relying on a single physical machine. A server disk crash is a non-event with distributed revision control
- White box testing tests the implementation of the code where it accepts an input and produces the appropriate output
- Black box testing tests the expected output given the input
- Double Maintenance: prevents multiple copies of the same file and must be updated independently
- Shared Data problem: allows two or more developers access the same file/data
- Simultaneous Update: Must prevent clobbering when two updating the same file at the same time
- Free Redistribution
- Source code availability
- Derived Works
Tuesday, October 13, 2009
Configuration Management: Subversion
In this assignment we have to practice using subversion as our centralized configuration management tool using TortoiseSVN as a subversion client and Google Code to host our source projects.
All in all I find this assignment very helpful in any group projects. Tortoise was very easy to use and install. When I first imported my source codes to Google host, I accidentally uploaded other directories such as bin, lib and build. Tortoise was easy enough to use where I just deleted my local copy and committed the changes to Google host's copy. As good as Tortoise's function are, I find it weird that I have to right click within directories to use all of its function instead of a graphical interface such as those in SmartSVN. Setting up Google host site was just as easy as using Tortoise. All tasks were completed except for adding a codesite-noreply@google.com. I posted to the appropriate forum so that they can add the link to our discussion manually.
You can check out my host site here and discussion here.
Updated WallEE.
All in all I find this assignment very helpful in any group projects. Tortoise was very easy to use and install. When I first imported my source codes to Google host, I accidentally uploaded other directories such as bin, lib and build. Tortoise was easy enough to use where I just deleted my local copy and committed the changes to Google host's copy. As good as Tortoise's function are, I find it weird that I have to right click within directories to use all of its function instead of a graphical interface such as those in SmartSVN. Setting up Google host site was just as easy as using Tortoise. All tasks were completed except for adding a codesite-noreply@google.com. I posted to the appropriate forum so that they can add the link to our discussion manually.
You can check out my host site here and discussion here.
Updated WallEE.
Wednesday, October 7, 2009
Testing: It's not as easy as it sounds!
On this assignment, we have to create different test cases for our Robocode robots. These test cases are Acceptance, Behavioral, and Unit tests. Acceptance test are tests that simply checks if our robot beats one of the sample robots in a given number of rounds. Behavioral test are tests that makes sure our robot’s movement, firing, or targeting are doing what they are intended to do. Lastly, there are Unit tests which verify our robots’ method output given different inputs. The later might have to be written after our robots’ code is "refactored".
We were given a heads up on the what these test are when we described possible test cases on our partner’s robot during lab. Describing these tests was easy enough but little did I know that implementing these seemingly easy test was going to be so hard.
For my acceptance test I used SittingDuck and Corners against WallEE. As for my behavioral test, I created a test to make sure my robot turns in the right direction since WallEE is based on sample walls, it turns left towards and perpendicular to the first wall it sees. Lastly my unit test consists of testing how my robot fires a bullet with power proportional to the distance of the enemy. This was the hardest to implement because I did not have the methods that was in accessible in WallEE such as determining the distance between WallEE and its enemy. This was a great opportunity for me to modify my code in order to have a “testable” block of code, which I did but to no result. It was hard for me to “refactor” that specific code so that I can test it and at the same time preserve its original function. So I did most of the distance calculation within my test which I know is not a good idea because it does not preserve the encapsulation of my code.
I don't feel that my tests adequately ensure the quality of my robot because I only have four test cases. Two of which are acceptance and one of each behavioral and unit tests. What I would have done is to test my other movement strategy which is WallEE treading back to where the enemy was to get another shot.
After implementing the test cases for the junit, I ran Emma which is another build tool that measures and reports Java code coverage. Here are the results:
All in all this assignment was hard but very rewarding. The practice we get from creating not just only any test cases but good test cases will help us write codes that are both easy to understand and easy to test.
The new distribution file of WallEE can be downloaded here.
We were given a heads up on the what these test are when we described possible test cases on our partner’s robot during lab. Describing these tests was easy enough but little did I know that implementing these seemingly easy test was going to be so hard.
For my acceptance test I used SittingDuck and Corners against WallEE. As for my behavioral test, I created a test to make sure my robot turns in the right direction since WallEE is based on sample walls, it turns left towards and perpendicular to the first wall it sees. Lastly my unit test consists of testing how my robot fires a bullet with power proportional to the distance of the enemy. This was the hardest to implement because I did not have the methods that was in accessible in WallEE such as determining the distance between WallEE and its enemy. This was a great opportunity for me to modify my code in order to have a “testable” block of code, which I did but to no result. It was hard for me to “refactor” that specific code so that I can test it and at the same time preserve its original function. So I did most of the distance calculation within my test which I know is not a good idea because it does not preserve the encapsulation of my code.
I don't feel that my tests adequately ensure the quality of my robot because I only have four test cases. Two of which are acceptance and one of each behavioral and unit tests. What I would have done is to test my other movement strategy which is WallEE treading back to where the enemy was to get another shot.
After implementing the test cases for the junit, I ran Emma which is another build tool that measures and reports Java code coverage. Here are the results:
- Class - 86%
- Method - 88%
- Block -84%
- Line - 85%
All in all this assignment was hard but very rewarding. The practice we get from creating not just only any test cases but good test cases will help us write codes that are both easy to understand and easy to test.
The new distribution file of WallEE can be downloaded here.
Tuesday, September 29, 2009
Build System: Ant
As we progress and improve our robots for the improved robot Robocode rumble, we were introduced to a very useful build tool called Ant and its dependency manager called Ivy. We also got a first hand experience with the Ant code which was provided by our professor. We are to adapt this Ant code with our code and invoke 3 quality assurance tools.
The only problems I had after running checkstyle were with the javadoc and missing package info. The first one was really easy to fix. All I had to do was add the necessary @param that was left out. It is interesting to see how after revising my code to follow our class' java coding standards and having it reviewed by a classmate, that this necessary javadoc information was overlooked. This is where the quality assurances come in handy. The automation of tasks such as looking for coding standard errors helps achieve the 3rd prime directive, which informs an external user by providing a correct java documentation.
The other problem was not as easy to fix like adding the missing javadoc information. After looking at the results of running checkstlye, which I thought didn't help because it displays the same error message, I checked the original system to see what was missing and it turns out that within DaCruzer's directory is an html file that describes the package. So I did created the same file which describes my package.
After running checkstyle, I tried running the other quality assurance, pmd and findbugs, and did not get any errors.
These quality assurance tools are very helpful in producing robust system that corrects coding standards, improve code efficiency and packages easily. I had a hard time understanding what the Ant code does at first but now that we had hands on experience and understanding each line during a class discussion, I feel like this is something I can use in the future to be better programmer.
Updated WallEE can be downloaded here.
- ant -f checkstyle.build.xml
- ant -f pmd.build.xml
- ant -f findbugs.build.xml
The only problems I had after running checkstyle were with the javadoc and missing package info. The first one was really easy to fix. All I had to do was add the necessary @param that was left out. It is interesting to see how after revising my code to follow our class' java coding standards and having it reviewed by a classmate, that this necessary javadoc information was overlooked. This is where the quality assurances come in handy. The automation of tasks such as looking for coding standard errors helps achieve the 3rd prime directive, which informs an external user by providing a correct java documentation.
The other problem was not as easy to fix like adding the missing javadoc information. After looking at the results of running checkstlye, which I thought didn't help because it displays the same error message, I checked the original system to see what was missing and it turns out that within DaCruzer's directory is an html file that describes the package. So I did created the same file which describes my package.
After running checkstyle, I tried running the other quality assurance, pmd and findbugs, and did not get any errors.
These quality assurance tools are very helpful in producing robust system that corrects coding standards, improve code efficiency and packages easily. I had a hard time understanding what the Ant code does at first but now that we had hands on experience and understanding each line during a class discussion, I feel like this is something I can use in the future to be better programmer.
Updated WallEE can be downloaded here.
Monday, September 21, 2009
Test bout against Sample Robot!
We are getting closer to the big fight and in the process testing and refining our robots against the sample robots we reviewed. Ever since our group discussion on designing counter measures against sample robots, I have been planning a robot that will win against all of the sample robots. My strategy is similar to the sample robot Walls. After reviewing each sample robots, I learned that Walls outlast the other robots by avoiding enemy fires, since it travels a long distance along the perimeter of the wall. I am adopting Walls because of this attribute, hence the name of my robot WallEE. I added some movement where whenever it scans an enemy, it goes back so that it will have another chance to shoot at the enemy. Another thing I added is just a simple avoidance strategy where it changes direction if it gets hit.
My robot did great against each sample robots. I purposely added the avoidance strategy just to defeat Ramfire and Walls itself. Those were the only robots that sometimes would fare better than WallEE. This is one of the things I had to improve on, to get a better percentage of winning. I realized that these two sample robot wins because they cornered mines. So I added a firing criteria where my robot fires a bullet with its power relative to the enemy's distance. This strategy, coupled with the avoidance strategy improved that percentage. I learned that I have to improve my robot's overall functions, movement, tracking and firing, so that it is equipped with different functions counter the sample robots
I learned from this experience, that adding functions to counter a specific enemy strategy is inefficient. I have to improve my robot's overall functions, movement, tracking and firing, so that it is equipped with different functions to counter the sample robots. This would be something I would've done differently. I would've tried a strategy that works on most enemies since it's too tedious to plan a counter for every strategy.
Download: WallEE
My robot did great against each sample robots. I purposely added the avoidance strategy just to defeat Ramfire and Walls itself. Those were the only robots that sometimes would fare better than WallEE. This is one of the things I had to improve on, to get a better percentage of winning. I realized that these two sample robot wins because they cornered mines. So I added a firing criteria where my robot fires a bullet with its power relative to the enemy's distance. This strategy, coupled with the avoidance strategy improved that percentage. I learned that I have to improve my robot's overall functions, movement, tracking and firing, so that it is equipped with different functions counter the sample robots
I learned from this experience, that adding functions to counter a specific enemy strategy is inefficient. I have to improve my robot's overall functions, movement, tracking and firing, so that it is equipped with different functions to counter the sample robots. This would be something I would've done differently. I would've tried a strategy that works on most enemies since it's too tedious to plan a counter for every strategy.
Download: WallEE
Tuesday, September 15, 2009
Robocode Sample Strategies Reviewed
After creating our own movements and reviewing other people's implementation, it was a nice change of pace to review the sample robots the contributors of Robocode have created. I got an insight to some simple strategies for creating the best robot. Studying their implementation have shown me different methods I would have not known or use otherwise. This have helped me plan a strategy for the upcoming Robocode competition.
Review Tasks:
Movement: This robot moves around the perimeter of the wall in a clockwise manner. It does this by turning left and by going ahead to the wall it is facing. It has an avoiding strategy which moves the robot back if the enemy who shot it is in front and ahead if it's behind.
Targeting: Its targeting mechanism is very basic that it uses the game's call to scan which does it automatically whenever the robot moves or turns its body/gun/radar.
Firing: It also has a very basic firing system where it fires at an enemy whenever it scans an enemy robot.
RamFire
Movement: This robot searches for an enemy and ram it then when it hits its enemy if fires a bullet with power that depends on the enemy's energy. It does this by relying on the enemy's bearing which in turn determines how the robot turns in which direction.It has no avoidance technique since its primary objective is ram enemies for bonus points.
Targeting: Its targeting is dependent on how the robot moves when it changes it's direction.
Firing: The robots firing mechanism depends on the enemy's energy points. It fires a low power bullet if the energy level is low. The robot's purpose seems to use ramming as primary technique instead of firing bullets.
SpinBot
Movement: This robot moves in a circle and fires an enemy when in range. Its avoidance strategy is its circular movement.
Targeting: Its targeting mechanism is pretty basic, it fires whenever it scans an enemy.
Firing: Since its targeting is basic, this robot fires a bullet with a power of 3.
Crazy
Movement: This robot's movement just like its name suggest is crazy. Its erratic behavior resembles a chicken with its head cut-off. It has a set amount of pixel movement and changes direction each turn. It changes reverses direction whenever it hits a wall or another robot and then returns to its original behavior. Its erratic behavior is its avoidance strategy and consequently does not follow any following strategy.
Targeting: Considering its crazy moves, the targeting mechanism lacks the same extremity, it just follows the gun's heading.
Firing: This robot does not have any criteria for firing. It just fires when an enemy is scanned.
Fire
Movement: This robot mostly sits still and only moves when it is hit. It moves back and fort whenever it gets hit each time. Its avoidance strategy is useless if not close to nothing since it only moves so that it never gets hit in the same place twice consecutively.
Targeting: Its targeting system is basic. It relies on the gun's turning as a way to scan for enemies.
Firing: Its firing criteria is to shoot the enemy with a high powered bullet if it's target is close and lower powered bullet when near.
SittingDuck
Movement: This robot does nothing therefore there is no avoidance or following strategy.
Targeting: It does not find a target.
Firing: And does not fire.
Corners
Movement: This robot moves to the top left corner and just stays there. It changes corner for the next round whenever it dies.
Targeting: Its targeting system is average since it first checks to see if there is a robot in it's path and if there is starts it's custom firing method. It also only scans a 90 degrees radius that is adjusted depending on the corner. This however could be a potential flaw that limits the robot's firing range since it stops and fires at an enemy before it even gets to it's corner.
Firing: This robot's firing criteria is to use a bullet power relative to the enemy target's distance.
Tracker
Movement: This robot's following strategy is to close in at a chosen target and moves within 100 pixels of that target and fires. It moves back a little if gets too close.
Targeting: Since the robot's strategy is to follow a chosen target and gets close enough to fire, its targeting depends on the gun's turning.
Firing: This robot doesn't have any special criteria. It mainly shoots a higher powered bullet whenever it gets close to an enemy.
Upon writing my review for each robots, I realized that the best strategy is to balance the movement, targeting, and firing methods. All three aspects have overlapping functions that when combined properly can build one of the best robots.
Review Tasks:
- Movement: How does the robot move? Does it have an avoidance or following strategy?
- Targeting: How does it find a target to fire?
- Firing: What is its criteria for firing?
Movement: This robot moves around the perimeter of the wall in a clockwise manner. It does this by turning left and by going ahead to the wall it is facing. It has an avoiding strategy which moves the robot back if the enemy who shot it is in front and ahead if it's behind.
Targeting: Its targeting mechanism is very basic that it uses the game's call to scan which does it automatically whenever the robot moves or turns its body/gun/radar.
Firing: It also has a very basic firing system where it fires at an enemy whenever it scans an enemy robot.
RamFire
Movement: This robot searches for an enemy and ram it then when it hits its enemy if fires a bullet with power that depends on the enemy's energy. It does this by relying on the enemy's bearing which in turn determines how the robot turns in which direction.It has no avoidance technique since its primary objective is ram enemies for bonus points.
Targeting: Its targeting is dependent on how the robot moves when it changes it's direction.
Firing: The robots firing mechanism depends on the enemy's energy points. It fires a low power bullet if the energy level is low. The robot's purpose seems to use ramming as primary technique instead of firing bullets.
SpinBot
Movement: This robot moves in a circle and fires an enemy when in range. Its avoidance strategy is its circular movement.
Targeting: Its targeting mechanism is pretty basic, it fires whenever it scans an enemy.
Firing: Since its targeting is basic, this robot fires a bullet with a power of 3.
Crazy
Movement: This robot's movement just like its name suggest is crazy. Its erratic behavior resembles a chicken with its head cut-off. It has a set amount of pixel movement and changes direction each turn. It changes reverses direction whenever it hits a wall or another robot and then returns to its original behavior. Its erratic behavior is its avoidance strategy and consequently does not follow any following strategy.
Targeting: Considering its crazy moves, the targeting mechanism lacks the same extremity, it just follows the gun's heading.
Firing: This robot does not have any criteria for firing. It just fires when an enemy is scanned.
Fire
Movement: This robot mostly sits still and only moves when it is hit. It moves back and fort whenever it gets hit each time. Its avoidance strategy is useless if not close to nothing since it only moves so that it never gets hit in the same place twice consecutively.
Targeting: Its targeting system is basic. It relies on the gun's turning as a way to scan for enemies.
Firing: Its firing criteria is to shoot the enemy with a high powered bullet if it's target is close and lower powered bullet when near.
SittingDuck
Movement: This robot does nothing therefore there is no avoidance or following strategy.
Targeting: It does not find a target.
Firing: And does not fire.
Corners
Movement: This robot moves to the top left corner and just stays there. It changes corner for the next round whenever it dies.
Targeting: Its targeting system is average since it first checks to see if there is a robot in it's path and if there is starts it's custom firing method. It also only scans a 90 degrees radius that is adjusted depending on the corner. This however could be a potential flaw that limits the robot's firing range since it stops and fires at an enemy before it even gets to it's corner.
Firing: This robot's firing criteria is to use a bullet power relative to the enemy target's distance.
Tracker
Movement: This robot's following strategy is to close in at a chosen target and moves within 100 pixels of that target and fires. It moves back a little if gets too close.
Targeting: Since the robot's strategy is to follow a chosen target and gets close enough to fire, its targeting depends on the gun's turning.
Firing: This robot doesn't have any special criteria. It mainly shoots a higher powered bullet whenever it gets close to an enemy.
Upon writing my review for each robots, I realized that the best strategy is to balance the movement, targeting, and firing methods. All three aspects have overlapping functions that when combined properly can build one of the best robots.
Monday, September 14, 2009
Conforming to Java Coding Standards
After reading the Elements of Java Style I can't help but admit that my coding style is not that great. I have used one-line comments placed right next to the code, which I thought seemed convenient since it immediately follows the code it refers to. Instead I figured that it is better to add it before the code declaration since we are only allowed 100 characters per line, which is part of our class' own coding standard. Since I imported the Eclipse formatting template I didn't really have any problems reformatting my robots to conform with the assigned coding standards. All of the work was changing the javadoc to third person, making sure it ends with a period. Another thing that I had to do was to add
My updated source code.
<code>...</code> tags since I included method names in my javadoc.My updated source code.
Wednesday, September 9, 2009
Practice run in Robocode, gearing up for the Big Fight!
Robocode is an excellent program that lets users design their robot's function and puts it to the test by facing off with other robots. For this assignment, we familiarize ourselves to the program by creating simple functions that teaches us movement, radar control and targeting.
These functions are:
All in all I thought that it was a fun assignment. As challenging as it is, I think that this is a good exercise for us not only to use open source materials but to apply different fields such as Math as tools needed in programming. My ideas for a competitive robot will most definitely involve Math since I plan to focus on movement and targeting.
My sample code can be found here.
These functions are:
- 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.
- 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.
All in all I thought that it was a fun assignment. As challenging as it is, I think that this is a good exercise for us not only to use open source materials but to apply different fields such as Math as tools needed in programming. My ideas for a competitive robot will most definitely involve Math since I plan to focus on movement and targeting.
My sample code can be found here.
Monday, August 31, 2009
OSS Experience: TV Guide Browser
Goal: Apply and learn the Three Prime Directives of Java-based Open Source Software
Program: TV-Browser
Source: http://sourceforge.net/projects/tvbrowser/
Download: TV-Browser
Overview: TV-Browser is a TV guide that gathers information on the shows that the user is interested in. The program has extensive array of functions that the user can customize to fit their need.
Prime Directive 1: The system successfully accomplishes a useful task
In terms of functionality the program is extensive enough to deliver different user experience by customizing different functions such as favorite shows, specific time slots, show links, user ratings, etc. I find that all of these functions are useful but they are executed in a way that most people would find hard to use. The manual, that is accessible within the program itself, was useless since it's just a link to the program's Wikipedia page. I also find the whole layout too simple, where the show information are in different panes. A user might want a good flow of the things he or she needs.
Prime Directive 2: An external user can successfully install and use the system
I downloaded the program and installed it with great ease. The installation process was straight forward. The customization features starts with the installation where the user have choices which services or plug-ins will be installed accompanied by a short description of what they do.
Prime Directive 3: An external developer can successfully understand and enhance the system
The program have developer-level documentation, which can be found on the developer page.
Overall, I find this program very interesting but I would change most of the interface for me to use it more. All the functionality is included but the program missed on the implementation that would make the program user friendly.
Program: TV-Browser
Source: http://sourceforge.net/projects/tvbrowser/
Download: TV-Browser
Overview: TV-Browser is a TV guide that gathers information on the shows that the user is interested in. The program has extensive array of functions that the user can customize to fit their need.
Prime Directive 1: The system successfully accomplishes a useful task
In terms of functionality the program is extensive enough to deliver different user experience by customizing different functions such as favorite shows, specific time slots, show links, user ratings, etc. I find that all of these functions are useful but they are executed in a way that most people would find hard to use. The manual, that is accessible within the program itself, was useless since it's just a link to the program's Wikipedia page. I also find the whole layout too simple, where the show information are in different panes. A user might want a good flow of the things he or she needs.
Prime Directive 2: An external user can successfully install and use the system
I downloaded the program and installed it with great ease. The installation process was straight forward. The customization features starts with the installation where the user have choices which services or plug-ins will be installed accompanied by a short description of what they do.
Prime Directive 3: An external developer can successfully understand and enhance the system
The program have developer-level documentation, which can be found on the developer page.
Overall, I find this program very interesting but I would change most of the interface for me to use it more. All the functionality is included but the program missed on the implementation that would make the program user friendly.
Sunday, August 30, 2009
Fizz Buzz Program
It was pretty interesting that the very first thing we did in class, after learning everybody's name and expectations from this class, was to write a comparable program that prospective programmers might expect in a job interview.
The program is called FizzBuzz, which prints the numbers from 1 to 100 and substitutes "Fizz" for numbers divisible by 3, "Buzz" by 5 and "FizzBuzz" by 3 & 5.
I did manage to write the program correctly but it was a little different from the one we did as a class. For my "FizzBuzz" line I have:
And as a collective class effort we came up with:
It was interesting what everybody came up with considering there are different approach for solving the problem. I realized that our class' approach was better in terms of style and efficiency, my approach had two comparisons whereas the class' had only one.
So when I wrote the same program in Eclipse, I used our class' solution.
Here is my FizzBuzz Code:
As for Eclipse, I have been using it as my IDE since ICS111 so I learned a few shortcuts and it took me no less than 4 min to write and run the program with no problems.
The program is called FizzBuzz, which prints the numbers from 1 to 100 and substitutes "Fizz" for numbers divisible by 3, "Buzz" by 5 and "FizzBuzz" by 3 & 5.
I did manage to write the program correctly but it was a little different from the one we did as a class. For my "FizzBuzz" line I have:
if (i % 15 == 0) {
System.out.println("FizzBuzz");
}And as a collective class effort we came up with:
if (i % 15 == 0) {
System.out.println("FizzBuzz");
}It was interesting what everybody came up with considering there are different approach for solving the problem. I realized that our class' approach was better in terms of style and efficiency, my approach had two comparisons whereas the class' had only one.
So when I wrote the same program in Eclipse, I used our class' solution.
Here is my FizzBuzz Code:
/*
* Prints out the number from 1 to 100 but
* substitute Fizz for all multiple of 3,
* Buzz for 5 and FizzBuzz for 3 and 5.
*/
public class FizzBuzz {
public Static void main(String[] args) {
for (int i = 1; i <= 100; i++) {
if (i % 15 == 0) {
System.out.println("FizzBuzz");
} else if (i % 5 == 0) {
System.out.println("Buzz");
} else if (i % 3 == 0) {
System.out.println("Fizz");
} else {
System.out.println(i);
}
}
}
}As for Eclipse, I have been using it as my IDE since ICS111 so I learned a few shortcuts and it took me no less than 4 min to write and run the program with no problems.
Subscribe to:
Posts (Atom)