33.DecathlonDesign3

I learned a great deal trying to make a pseudo-implementation of our decathlon design. In summary, Wicket is a fickle beast and blueprint CSS is useful. As for the 3 prime directives of software engineering, I will describe how our implementation met the required criteria:

1. The system successfully accomplishes a useful task.

I believe the objective of the system we implemented was to show a way a user would theoretically interact with the solar decalthlon house system. Our product is still a mockup of sort and was pitched to Professor Johnson, who will in turn show it to the leads in charge of the Solar Decathlon Project. The system's usefulness will be evaluated by whether anyone likes it or not. However, I believe we managed to create a useful implementation that will eventually help guide the direction of our ICS414 full implementation of the Solar Decathlon Home System. I believe this provides enough proof that we satisfy the 1st prime directive.

2. An external user can successfully install and use the system.

The documentation of our project can be found at http://code.google.com/p/solar-decathlon-teamhawaii-2/w/list. What is nice about the way wicket works is that one only simply needs to have java installed to run the wicket server via a .jar file. Our respective .jar can be found here. By simply typing in "java -jar wicket-solardecathlon1.3.1.jar," a user is able to start their own web server with our wicket content. This is quite clever as no other third party add-ons are needed.

External users can check-out our project being hosted on Google Code if they wish to see what we've done or wish to make changes (granted they have to be of the proper group). I believe this provides enough proof that we satisfy the 2nd prime directive.

3. An external developer can successfully understand and enhance the system.

Our code is well documented and we have run the ICS413 build system quite thoroughly to make sure the style is uniform with all the other projects being presented. The wiki page mentioned previously will also provide an external developer some other necessary documentation for them to build on what we have started. I believe this provides enough proof that we satisfy the 3rd prime directive.

If we had chance to do this all over again, I probably would have tried to make sure that certain naming conventions and css methodologies be followed when writing the code. There were a few cases were miscommunication on our parts lead to confusion and the wasting of time modifying variables in a convention that each of us would use, yet the others would not. Communication is a huge deal, and an important part of the development process. We had to have quite a few meetings and online chat sessions to make sure all of us were on the same page. The critiques from Professor Johnson during our final presentation proved we had to change our color scheme. Although it displayed well on our screens, it should display well universally. Testing once again struck with vengeance.


As an added note, getting jquery working with wicket was a fairly painful process to learn with the fullcalendar package. But I am confident now I will be able to successfully add more jquery features and move around css much more quickly thanks to the experience I've gained working with the wicket framework and the blueprint css package.

31.WicketKatas

Overview Code katas are exercises in programming that help you to refine your skills.  The goal of this assignment is to: Improve your comfort level with Wicket by performing a number of small changes to existing Wicket systems. Each Kata involves a modification to one of the example systems in the ICS Wicket Examples project.   To start, I downloaded all the .zip distribution of all examples but example05 to your local system.  I edited the build.xml file so that the project name is no longer exampleNN, but rather exampleNN-kteichma. I then ran "verify.build.xml" using Eclipse. These example files were modified in the following ways: The Eleven Wicket Katas Example 01: Kata 1A:  Add a new line to the page that says, "In one week, the time will be <time>", where <time> is replaced by a timestamp one week later than the timestamp that now appears on the page. Kata 1B: Add a button to the page labelled "Refresh".  After pushing the button, the times update themselves. Kata 1C:  Wicket, by default, runs in "Development" mode, but production systems should run in "Deployment" mode.  Override the getConfigurationType() method so that Example01 now runs in Deployment mode.  See this page for details.  This particular example was finished by my partner and I during our class period. It took about 40 minutes. Professor Johnson gave some nice hints on how to you the java Date constructor to make a date from a timestamp. I was able to review form usage in this particular kata and discover the development mode. Example 02: Kata 2A:  Add an additional link on the home page that says, "Go to image page".   Create this page, which should display an embedded image.  This image should be G-rated.  It should be in a .jpg file stored with the system, not retrieved from the web. Kata 2B:  Add a button on the home page with the label, "Make font bold".  After the user pushes it, all the text on the page should become bold, and the button label should change to "Make font italic".  When the user pushes that button, all of the text should change to italic and the button label should change to "Make font normal".  Pushing that button changes the text back to its original state and the button label should now say "Make font bold". Kata 2A was finished in class. Estimated time it taken to complete was around 40 minutes. I can't remember too much about this one other than it took us a while to figure out that there was an Image object we could use to add pictures stored on the system to the webpage. Kata 2B was a little harder, and I'm not quite pleased with the solution I implemented. I ended up making separate form pages for italicized and bold lettering. There is obviously a better way to do this, such has make bold and other style labels, but this was the only solution that occurred to me in my lack of time. Example 03: Kata 3A: Add a new tab called "Image" that takes the user to a page containing an embedded image (your choice, G-rated).  It should be in a .jpg file stored with the system, not retrieved from the web. This particular example took about 10 minutes as it was very simular to example 2a. It was almost a no brainer as I was able to copy and paste most of the code used in kata 2A. Example 04: Kata 4A:  Add a new cheese called "Velveeta", which costs $0.25/lb. Kata 4B:  Add a "country" field to the billing address that appears when checking out.   The country field should provide a drop-down menu with a selection of 5 countries. This particular example took 40 minutes. I had some issues with this particular kata in that it took a while to figure out how the data was stored. It will be interesting to eventually see how this front end will end up working with DB back end. As of now, all of the entries are hard coded into the java source. Example 06: Record how long it took you to accomplish each of these katas. Kata 6A:  Get rid of the blue columns that appear when displaying the website. These are for development, not deployment purposes. Kata 6B:  Place the image underneath the form, not to the right. Kata 6C:  It is often convenient for web applications to consult a properties file when starting up in order to get configuration values.  An easy way to do this is with the standard Java Properties mechanism.  (See Java in a Nutshell for details on properties file manipulation.)   For this Kata, modify your Example06 system to read in a file (if present) located in ~/.example06/configuration.properties.   (Note that ~ means "the user's home directory", and that there is a System property in Java that provides this value.)  This property file should contain a line like the following: deployment = true In other words, it contains a property called "deployment" whose value is true if the Wicket application should run in deployment mode, otherwise the application should run in development mode (see Kata 1C). Your application should read in the properties file and set the System property wicket.configuration before starting up Wicket. The Jetty class is a convenient place to do this processing. Finally, your application should write out a message on startup indicating whether or not it found the file, and what the resulting configuration mode will be.  If the file is not found, or the property is not present in the file, then the application should run in development mode.  This particular example took me another 40 minutes. I still was not able to finish Kata 6C as I have been running out of time juggling ICS311 and ICS413 and ICS321 these past 2 days. Big projects all due at the same time. Kata 6A was a fairly easy change as turning off the grid doesn't require much. As for kata 6B,  this just required some basic knowledge on how grids work and making more area. Overall, I enjoyed the process of experimenting with Wicket and I look forward to using it more extensively in the future. However, I do recommend keeping our options open as http://oodt.jpl.nasa.gov/better-web-app.mov provided by Professor Chin in my 215 scripting class, shows that there are great alternatives out there. Here is a link to my distribution file

30.WicketChart

The Wicket Project we were assigned was to implement a one page web application that provides two components: 

1. A form that accepts a variety of parameters
2. Along with a submit button that when pressed, generates a GoogleOMeter visualization.  

To see what a GoogleOMeter is, go to http://imagecharteditor.appspot.com/, then click "Show full gallery", then scroll to the bottom.  The last three visualizations are GoogleOMeters. I ended up choosing the 3rd visualization

The form should allow the user to: 

• Set the start and end of the Y axis;
• Set the title
• Set the width
• Set the height
• Provide a data value for the pointer

The web application in general should:

• Use Wicket
• Use Blueprint CSS for layout
• Use the ICS 413 build system
• Provide at least one useful test case
• Employ sessions so that multiple users can generate charts independently

In terms of testing, I employed that the lower bound and upper bound values would have error checking to see if the user had inputted nonnumerical characters. Since extract a string from these text boxes via Double.parseDouble(), if there is, for example, a letter in the "Lower Bound" text box, this would cause an exception. My program catches this exception and immediately sets the values of all the bounds, lower, mean, and upper to zero. On the case that the user enters correct input, the "Mean" becomes the average of the lower and upper bounds. My JUnit test explicitly tests for this particular case of erroneous user input and verifies that the "Mean" value gets set to "0.0" to allow for the chart to still be created with safe values.

The overall experience of this assignment was quite good. The CSS grid style layout was fun to play and felt similar to other grid layouts used in other various programming language interface structures. See http://www.learncomputer.com/blueprint-css/ for reference on the CSS system we employ in our web application.


Using sessions and the ICS413 build system proved to be tedious, but nice once everything was working properly. Going through all the errors and satisfying what was generated by our style checkers (build.pmd.xml and build.checkstyle.xml) was a pain to say the least. It was almost as painful as porting the form provided by Professor Johnson's wicket-example06 into a single page to be viewed and interacted with by a user. It really forced me to read through the code and figure out how the wicket system works. However, the overall experience was a good exercise in problem solving and hard work. I look forward to working with Wicket in the future.

My distribution for this assignment can be found here.

27.DecathlonDesign3

The design aspect of the Solar Decathlon system was fairly difficult. With limited input from the lead management, we were left to guess what we thought would be relevant information to be displayed to a user. What do we think would be important to know? Where should the system's priorities lie? These were questions we had to consider while creating the balsamiq mockups. When our team met together to delegate what jobs we should do, I was assigned the Aquaponics and Lighting systems. These two features and the desired design will be explained in the following paragraphs.

Since the engineers had not given us specifications on each particular system, we all had to do a bit of research. For my particular case, it was necessary to research a bit about aquaponics and they key concepts surrounding it. I had to figure out what chemicals and attributes typically need to be monitored. I also had to decide upon what things a user realistically has control of. In the end, I made my best guess and hopefully it wasn't too far off the mark. I decided the picture visualization of the health of the fish and the plant would be a very straightforward indicator of the current status of that particular system.

In terms of the lighting system, it was hard not to reinvent the wheel. I tried to think of some new things that would be nice to set from the web interface. Color seemed to be an important feature of the LEDs explained to us by the engineers so I wanted to set up a way that the user could interact with such lights and set their respective colors. I ended up going with using an interface much like that found in adobe photoshop (almost exactly hah!).

I originally added to function to completely disallow certain lights to be enabled. However, I ended up revising this due to lack of creativity on my part. In our particular design, the user should be able to intuitively click areas of the house to light up key areas both inside and outside the house.

Both features, aquaponics & lighting, have the option to be automatically controlled by the house systems, or to be manually set by the user. Since the house should be self-sustaining, the system should have the option to promote this ideal as well.

Design is hard. Making good design decisions takes a lot of work and a lot of testing. In our case, my team and I simply consulted with each other on what would make for good features for our system. I believe we ended up taking an approach that was very similar to the "Apple" design concepts with the way we tried to make intuitive visualizations that any type of user could quickly understand. The KISS (Keep It Simple Stupid) approach was another concept we tried to keep in mind.

27.DecathlonDesign2

The process of issue driven design was a very interesting experience. Our job for stage 2 of the design process required that I, and two other classmates, team up to polish one of our designs. We had to learn how to work with one another and instigate good patterns of production. The trials and tribulations we faced were few, but significant. Overall the journey of teamwork and coordination proved to be successful, at least from my point of view. I hope the same was felt by my other teammates.


In terms of communication, I believe that my partners, Tony Gaskell and Gregory Burgess, and I performed quite well. We managed to contact each other through the America Online Internet Messaging service to ask for tips and insight on features that should be included in the mockups. We also coordinated a bit during class. Tony provided the layout knowledge as his design was selected by Professor Johnson for us to work on. We summarily delegated tasks to each other. I performed the design for the Aquaponics and Lighting systems of the house. Here is a link to our project's website : http://code.google.com/p/solar-decathlon-teamhawaii-2/

The hardest part of this assignment was methodically writing down each issue as they came to mind. I noticed that during the time I was designing, I was in a sort of a creative flow. I did not want to break the flow to write down each issue I came across and implemented. I feel like the act of writing would take me out of my zone and it would often take a while to get back into the zone. Perhaps with more practice, I will be able to self document these ideas as they come, but I found it quite hindering at this point in time.



In the end, I believe the whole process of this exercise was very useful. Setting tasks for oneself and accomplishing them in a timely manner is very conducive to a professional persona. Hopefully with more practice I will be able to show that I have predictable production as it seems like this type of issue driven development incorporates this. It should be noted that I feel like there are a few more things I would like to add to my systems, and I don't feel like they are ready for presentation at this point in time. They soon, however, will be ready.

24.DecathlonUserStories

The option of being part of the Hawaii Solar Decathlon Team while in ICS413 is quite the opportunity. "The U.S. Department of Energy Solar Decathlon is an award-winning program that challenges 20 collegiate teams to design, build, and operate solar-powered houses that are cost-effective, energy-efficient, and attractive. The winner of the competition is the team that best blends affordability, consumer appeal, and design excellence with optimal energy production and maximum efficiency.

The first Solar Decathlon was held in 2002; the competition has since occurred biennially in 2005, 2007, and 2009. The next event will take place on the National Mall in Washington, D.C., Sept. 23–Oct. 2, 2011. Open to the public free of charge, visitors can tour the houses, gather ideas to use in their own homes, and learn how energy-saving features can help them save money today."

Purpose

The Solar Decathlon:

• Educates student participants and the public about the many cost-saving opportunities presented by clean-energy products
• Demonstrates to the public the opportunities presented by cost-effective houses that combine energy-efficient construction and appliances with renewable energy systems that are available today
• Provides participating students with unique training that prepares them to enter our nation's clean-energy workforce.

-http://www.solardecathlon.gov/contests.cfm
-http://www.solar.hawaii.edu/

It is because of this project, our class begins the process of designing a system that allows for close monitoring of the applications with their respective costs and profits. This is done to help aid those living in the house have a tight control of their expenditures in order to break even with the power grid and be self sustaining. For this blog entry I will show 10 user stories that can portray options describing the use of the system to be developed.

1.) A household member wishes to inquire to the families energy consumption for that particular month. They will use their smart phone to bring up a web app that allows for the graphical visualization of their current monthly consumption. The member will have the option to choose which day/month/year they would like to view.

2.) A household member wishes to get up out of bed in the middle of the night after awaking to a clatter. The member will say "lights," and the voice activating lighting system will dimly illuminate the room. After exploring the area of the house from which the noise came, the user will return to bed and say "lights" a second time, and the lights turn off.


3.) A household member wishes to set an alarm for the lights to turn on in his house in the early hours of the morning. The user will set this alarm on their phone and go to sleep. The lights then turn on at the requested time in the morning.

4.) A household member wishes to view the O2 generation for a various day. The member will use their smart phone to bring up the data represented by the web application. After clicking the O2 tab, the user will see a line graph that shows the estimated O2 being produced by the aquaponics.

5.) A household member decides that they need to save more energy for that month. The user then goes to their smart phone and enables a checkbox called "spartan savings". This puts the house into spartan mode where only the absolute bare minimum energy is expended to help the house break even with the power grid.

6.) A household member wishes to be notified if their expected energy consumption will cause them to not break even with the power grid. He then whips out his smart phone and goes to the energy consumption tab. He then enables a check box that will "notify if consumption > produced." The user then rests assured that he will know when this may happen.

7.) The house member from story #6 also wishes for everyone else in the house to know if their consumption is far too great, and goes back to the energy tab on the smart phone web app and enables "notify all household members" check box under the "notify if consumption > produced" checkbox.

8.) A household member decides that they want to email their cousin their energy usage vs. consumption graph to brag about how "green" they are being. The user then brings up their smart phone. The user then clicks on the energy tab and clicks the "month" button. The graph provided by google has a link associated with it, and the user copies it into an email and sends it to their cousin.

9.) A household member wishes to play pong on their phone but also have it visualized by the LED array encasing the house. They bring up their smart phone and have it access the web application which consequently has a games tab. The user selects the games tab and selects pong. By default pong is only displayed on the phone, but the user decides to enable it to be viewed on the LEDs and enables the checkbox to do so.

10.) A senior household member wishes to prohibit the TV from being turned on during certain hours of the day. But this member is currently at work. He then brings up his smart phone and accesses the parental housing controls and selects TV. With a quick scroll of 2 drop down menus, the member has now set the TV to be powerless/inactive from hours 7am to 6pm.

23.WebsiteUsabilityReview

When defining usability, one should consider its five quality components:

• Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?
• Efficiency: Once users have learned the design, how quickly can they perform tasks?
• Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency?
• Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
• Satisfaction: How pleasant is it to use the design?

(http://www.useit.com/alertbox/20030825.html)

For this blog entry, I will describe how these five quality components apply to two  websites as I believe them to have high levels of usability. I will then describe how two other websites are lacking in areas of usability.

(Good Usability)


nytimes.com (The New York Times)

Learnability: The front page of the New York Times website should have a very familiar feel as it mimics a newspaper. Most people know what a newspaper looks like,
and how to navigate it. Arguably, this webpage navigates better than a newspaper as one doesn't have to fumble about with the loose sheets of paper.

Efficiency: Since most users already know the design of a newspaper, one can just read the headings and briefly glance at what things are interesting to them. The front page provides snippets of information that the writers feel relevant to their articles and are what promotes the users interest to click a link.

Memorability: Again as mentioned previously, this webpage is very intuitive due to the fact that it mimics a newspaper design. As long as the user has seen and used a newspaper, they will always know how to navigate this page.

Errors: It is very hard to make an error on this webpage as the links are very distinguishable from each other. However, if one were to make a mistake and mis-click on a link, he/she would be able to simply hit the back button to get to the front page. Also, each page that is clicked on will generally have some link back to the front page, no matter where the user navigates to.

Satisfaction: There is an sense of unbroken information flow when I navigate this page. Finding interesting information is very easy as it will pop out at the user. The left column also provides links to various specific pages related to categories of news, such as sports, science, health, etc. The user interface to this website is very simple and I believe it to be very pleasant to navigate.

pandora.com (Pandora Internet Radio)

Learnability: The front page of pandora is very self-explanatory. To create a new internet station, one just clicks the button, "create a new station..." From here, the user can enter in the name of a genre or particular band they are interested in, and pandora will generate playlist of songs for the user. In total, the user has to perform at most three actions to start listening to music. Since there are few hoops to jump through, the chances of the user accomplishing these basic tasks are fairly high. In the case that the user wishes to create an account, there will be more steps involved, but this will be a one time task.

Efficiency: After the user has created their first station as explained in Learnability, the user will only have to repeat the same steps to create a new station. In the case that the user wishes to switch stations to another station in the set of stations they have created, the user will only have to click on the station. So far, the total count of operations that a user would have to endure is four. In most cases, the user will only be switching through stations. The worst case scenario would consist of the user constantly creating many new stations, but users will generally not behave this way.

Memorability: Unless the user forgets their account information, the total amount of the common operations that a user will commit to memory is ~four. I would imagine that even the least tech savy people would be able to handle these four operations, no matter how long they may have been away from this page. Since the labels of all the links are self explanatory, the user will not have to remember much to get started again. In fact, the site saves the users information, so a default station will start playing music as soon as the user comes back to the page.

Errors: It's difficult to make errors on this website. If the user selects the wrong station, they can simply click on the correct one. If the user creates a station that they did not want, they can delete it by using the drop down menu associated with the station and repeat the process of station creation until they are satisfied.

Satisfaction: Navigating this page and accomplishing the task of creating a music channel is fairly seamless. Manipulating the station environments feel natural to those who are comfortable using computers. Even if you don't use a computer, it should be pleasant to use this site as there aren't too many things to remember. One could say the ease of use is comparable to typical music entertainment electronics.

(Bad Usability)


http://www.joneschijoff.com/ (Industrial Designer?)

It's hard to understand what the point of this webpage is. Navigating it is simply a pain. Although it incorporates the use of HTML5, it is misused. The user does not immediately understand what the point of the brain in the middle of the page is supposed to represent. There is minimal amounts of information being displayed. Thus, navigating and trying to find information is very tedious. The user will only remember this site in a way in which they will remember never to visit it again.

The chances for error while browsing this page are very large. The user can click just about anywhere on the front page and get output, however the output is enigmatic. In the most general case, upon clicking a part of the brain, you are given a zoom in view of the brain. When clicking the right error, you are taken to a matrix of pictures that have seemingly little to do with each other. There are no text links and the user is left to deduce where the useful information is.

When I leave this page, I'm left feeling very dissatisfied.

http://www.siphawaii.com/ (Shop in Paradise)

This site gives an ample definition to the statement "information overload". It is the exact opposite of the page previously reviewed. The web designer has filled this page up with many colors and styles. The main page is hard to look at. Reading the page gives the user an inclination to turn their head away from the bombardment of noise. In terms of efficiency, the website is not efficient at all. The person who made this page obviously neglected most common html interface structures, such as a drop down menu. There is a lot of redundancy with the labels and more than enough pictures.

The links on this page provide no feedback to the user as to which links have been previously been clicked. If a user wishes to find what item(s) they were looking at previously, they will have to make the search once again with little reference. This can debilitate the learning process associated with this page. The user will learn that you have to associate items of interest in relation to items of disinterest to find the items again.

The pages are also extremely "tall." The user will have to scroll through large portions of screen real estate to have the chance of finding what he/she is interested in. My finger is worn from the continuous use of the mouse-wheel on my mouse.

Upon adding an item to the cart, the user is whisked far away from anything that resembles the page they were at previously. This can cause confusion and perhaps annoy the customer enough so that they may give up entirely.

The site is memorable in that I may remember never wishing to be bombarded by so much information at one time again. I leave this page feeling extremely dissatisfied.

Conclusion
In conclusion, the less thinking involved, the better the user response and hence, the higher rating of usability corresponding to the product.

21.RoboHosting

This assignment required the ICS413 class to:

1. Task 1: Install an SVN client. Download and install an SVN client. 
1.  If you are using Windows, I recommend TortoiseSVN. If you are using a Mac, I use SmartSVN. Both are free, open source packages.
1. I downloaded both subversive plugin for Eclipse, and SmartSVN for OSX.
2. Task 2: Checkout/modify/commit an existing system hosted at Google Projects.

1. Check out the "robocode-pmj-dacruzer" project into your local workspace with commit access. You should be a member of this project, and thus able to check it out using https.Make sure that the "verify" target passes."Improve" the project in some way. This does not have to be a major improvement. Perhaps there is a JavaDoc comment that could be worded in a slightly better way, for example. Make sure that the "verify" target still passes. Commit your change to the repository, and make sure you include an informative commit message explaining how you improved the Project.
1. I managed to complete all of these steps simply using the subversive plugin for eclipse. I could successfully import the project from https://robocode-pmj-dacruzer.googlecode.com/svn/trunk without having to access the terminal.
2. The Eclipse run of ant verify.build.xml gave an output of successful completion. Thus it can be expected that the Subversive checkout accomplished the task and got the required files.
3. I added the comment "OVER 9000!" to the firing method of DaCruzer and ran the verify.build.xml one more time. After it proved successful, I synchronized with the repository, and after some quick merging, I committed the new revision.
3. Task 3: Create a new system hosted at Google Projects.

1. The assignment of getting our robocode robot java project hosted on Google Code didn't prove too problematic. However, I initially had trouble sharing my project on google hosting. I erroneously uploaded the project to the main directory instead of the trunk using Eclipse’s Subversion plugin. I’m still unsure as how to delete files in the main directory with this plugin, however, I was able to delete this extra file via the terminal by use of :

1. svn delete https://robocode-ktt-bubonic.googlecode.com/svn/robocode-ktt-bubonic --username kurt.t.teichman@gmail.com --message Bad upload

2. I then proceeded to check out the project using Eclipse's Subversive plugin again and ran the ant verify.build.xml through Eclipse. Everything went smoothly.
3. I created a google discussion group for the project @ http://groups.google.com/group/robocode-ktt-bubonic-discuss
4. I created the required UserGuide and DeveloperGuide wiki page using Googles markup language which was a pain. I used Professor Johnson's sample guides for the robocode-pmj-dacruzer for inspiration when creating these.

The majority of the assignment ran smoothly and I got to experiment and use the Eclipse Subversive plugin. I feel like the assignment was a great introduction to the usage of SVN and hosting projects on Google Code. I would highly recommend trying this out if you have any aspirations of creating projects that will be worked on by multiple people. If you wish to see the robocode-ktt-bubonic project, please goto:

https://code.google.com/p/robocode-ktt-bubonic/

19.RoboTesting

Testing Bubonic with JUnit was an interesting experience. After you figure out how JUnit works, using ant with the command line and through eclipse, and jump through all the configuration hoops, you can finally think about how you wish to test your robot.

I found that the acceptance tests were the easiest to create. Since my robot was able to beat Walls and SittingDuck 100% of the time, I did not have to extensively modify the sample test case, provided by Professor Johnson. These tests were valuable to insure that my robot had a baseline standard and was affective against both a trivial robot and a not so trivial robot.

The second easiest tests to create were the Bubonic simple movement behavioral tests. Since Bubonic’s strategy heavily relies on hugging a wall and scaling up and down, I thought these would be good tests to create. Thus, I had two cases that I wanted to test for: the robot seeking the left or right wall, and the robot moving to the top and bottom of the map (this case is dependent on another robot’s movement).  These were easy to test for in that it simply came down to a simple the position checks. The RobotSnapShots were enough to get the position of the robot at the end of a round. From these snapshots, I was able to use the getX() and getY() functions to find out whether my robot was indeed on a wall, and if it made it to the top or bottom of the map, respectively. These tests were valuable in that I wanted to make sure that the intended movement actually occurred and thus would be a good type of test to run. It should be noted that the vertical movement of Bubonic is dependent on an enemy robots movement so for that particular test case, the sample.Walls  robot was used to promote Bubonic’s movement. The Jacoco coverage for the horizontal movement test and the vertical movement test were 92% and 98%, respectively.

The hardest tests to create involved the testing for more specific behaviors. Since some of Bubonic’s behaviors are fairly complicated, the test cases became proportionally complicated to design. One test I wanted to check was whether my radar swept the top and bottom of the battlefield at least once after the robot reached the left or right wall and was moving vertically.  Since an enemy’s robot movement determines my robot’s vertical movement, I needed to load an enemy robot that moves unconditionally (not SittingDuck). Thus, I used test subject, Walls again, to generate the typical movement done by Bubonic. The test case only checked the radar heading after the robot has gotten into its specific position and is doing the intended movement. In retrospect, I could have spawned the robot on one of the sides of the map, but it would still initiate the same algorithm of movement. This was a valuable test in that proper scanning of the field insures that Bubonic knows where all the robots are.  Assuming that the radar alternates between 0 and 180 degrees, it wasn’t hard creating a boolean that would store whether the 0 or 180 case had been reached upon the end of a turn. The Jacoco coverage for the radar sweep test was 99%.

  public void onTurnEnded(TurnEndedEvent event) {
    IRobotSnapshot robot = event.getTurnSnapshot().getRobots()[1];
    double currentRadarHeading;
    double xPos = robot.getX();
    //Checks to see if the robot is on either the left or right wall
    if (xPos < 40 || xPos > (width - 40)) {
      robotOnWall = true;
    }
 
    if (robotOnWall) {
      currentRadarHeading = Math.toDegrees(robot.getRadarHeading());
      if (currentRadarHeading == 0) {
        radarHasSweptTop = true;
      }
      else if (currentRadarHeading == 180) {
        radarHasSweptBottom = true;
      }
    }
  }

The hardest test involved checking if Bubonics intended behavior would be triggered by a stationary target. In theory, Bubonic should stop and fire at this target with the hardest bullet until the target starts moving again. So the test subject for this experiment was SittingDuck. The method I used involved the comparing of an initial radar heading with a previous radar heading to see if the radar has not moved. If the values are equal, it can be assumed that the radar has locked onto a target. Then it is a necessary check to see if Bubonic’s gunheat is increasing, which shows the Bubonic is indeed firing at the target. The Jacoco coverage for the stationary target behavior test case was 99%.

  public void onTurnEnded(TurnEndedEvent event) {
    IRobotSnapshot robot = event.getTurnSnapshot().getRobots()[1];
 
    double currentRadarHeading;
    double xPos = robot.getX();
    //Checks to see if the robot is on either the left or right wall
    if (xPos < 40 || xPos > (width - 40)) {
      robotOnWall = true;
    }
 
    if (robotOnWall) {
      currentRadarHeading = Math.toDegrees(robot.getRadarHeading());
      if (previousRadarHeading == currentRadarHeading) {
        radarIsNotMoving = true;
        checkGunHeat(robot.getGunHeat());
      }
      previousRadarHeading = currentRadarHeading; 
    }
  }

The overall coverage for my test classes, as well as the Bubonic robot itself was pretty good. I had done some intensive testing on my robot vs. various other robots at high speed before the robocode competition to figure the weaknesses of my robot. Had I known how to successfully implement JUnit test cases, I think I could have further optimized my robot. I feel though, however, that my robot is fairly simple. Thus it was fairly easy to test. Had I created an advanced robot with really advanced features and behaviors, testing would not have been as straightforward. A link to my project file can be found here.

09.CompetitiveRobot

Design 

• Movement
• Bubonic will immediately goto the closest side on the horizontal plane.
• Once there, Bubonic will move forward in increments determined by (absolute difference between the its current Y coordinate and the enemy's previous Y coordinate + 75) units/(set of actions) creating a stutter effect. A normal tracking robot will have difficulty hitting Bubonic due this function creating dynamic movement.
• This serves as a way to quickly catch up to a robot moving in the vertical plane. By doing so, Bubonic can catch up to a robot before it decides to move horizontally closer. Bubonic is confident in its long range shooting (more so than close combat).
• Upon hitting a wall on the vertical plane, the robot will move backward in increments determined by (absolute difference between the its current Y coordinate and the enemy's previous Y coordinate + 75) units/(set of actions)
• *Note: set of actions={targeting,firing}
• The generalMovement() method also has proven to allow for quick escape as the distance function often provides large values. These large values cause for dramatic movement and make standard targeting of Bubonic difficult.
• Also, upon the event of one of Bubonic's bullets hitting an enemy, bubonic will backtrack in the opposite direction from which it was heading. This often causes quite a few misses on the enemies part and can put Bubonic in a better shooting position. In close combat, sometimes a key dodge will prove the difference. However, Bubonic has walked into a few unnecessary bullets as well due to this feature. I still can't decide whether it's worth having it in or not as I have not done any statistical analysis, but it will still be left in for the ICS413 Roborumble.
• Targeting
• While on the side wall, Bubonic's radar will scan the 180 degree open field looking for targets.
• Bubonic implements Non-Iterative Linear Targeting to track and lead its shots on moving enemy robots.
• It effectively guesses where a target is heading under the assumption that its moving linearly.
• I have incorporated the noniterative version of linear target tracking which can be found at: http://robowiki.net/wiki/Linear_Targeting
• However, since Bubonic constantly pans its radar 180 degrees of the open field in a "car-windshield wiper" fashion, it will fire at the first robot it encounters. Since the onScannedRobot event contains the velocity, distance, and bearing, one can derive a guess at to where the enemy robot is heading. It should be noted that I had to modify the code as it had been made for an advanced robot. This involved changing setTurnGunRightRadians(radians) to the form of turnGunRight(degrees). A Math.toDegrees() function was necessary at this step.
• It should be noted that Bubonic's targeting is best used in group skirmish, due to it not locking onto any particular target. But against one target, it still does fine.
• If one were to improve Bubonic's targeting system for 1v1, the "car-windshield wiper" should take into account the last bearing and degree relative to where the gun is pointing and adjust the area of radar sweep to minimize the unnecessary scanning of the rest of the field.
• Firing
• Firing is heavily intertwined with targeting. 
• The Linear Targeting allows for Bubonic to fire a leading shot on enemy robots moving in a straight line (linearly). 
• In short, triangles are being made each time the onScannedRobot event gets triggered. The algorithm then uses the velocity, distance, and bearing to generate vectors/sides of these triangles and makes a probable guess to the next position of the robot. It will then take into account the desired bulletpower(most notably the speed of the bullet) to determine a proper trajectory to intercept the next position of the target robot. 
• Thus, Bubonic will fire on the first robot that is scanned after interpreting various data associated with that enemy robot.
• The last case the firing system handles is the event in which the target robot stops moving. When this happens, Bubonic will also stop moving and proceed to fire its most powerful bullet at the target until one of the robots is dead.

Results

Bubonic managed to win consistently over all the robots. I had the hardest time with SpinBot as my targeting algorithm works best against bots moving in constant linear fashion. If Spinbot spawned close to the middle of the map, Bubonic would have great difficulty in landing a shot. SpinBot was able to catch Bubonic either at odd angles (ie 180 degrees) or coming out of a corner. Bubonic is most vulnerable at the point when it switches directions at a corner. This allowed lagged shots to often hit Bubonic as it reverses directions.

Bubonic > Walls

Tracker can significantly get the jump on Bubonic which will allow it to start doing damage early. I believe this to be the cause for the single loss to tracker.

In the end, I believe that Bubonic's survivability is greatly determined by the linear targeting and the movement function. Even if Bubonic is having a hard time landing a bullet a robot, it will generally be very hard to hit.

If I were to try to improve upon my design, I would definitely try to implement some sort of pattern matching. This would be used to detect whether an enemy robot is moving in a circle, as apposed to linearly. Bubonic then could try to switch targeting algorithms on the fly to deal with this type of movement.

Lastly, I would have to clean up the way field scanning is done as it's inefficient in it's current state.

• Here is a link to the Bubonic_1.0.jar file.

Lessons Learned
The 09.CompetitiveRobot exercise was very fun. I played around with many different type of targeting systems while trying to give Bubonic a small edge. The vast majority of targeting styles were developed for the Advanced Robot and it was hard trying to port some of this code into a regular Robot for which the assignment specified. Here are a few of the targeting methods I worked with:

• Iterative Linear Targeting
• Non-Iterative Linear Targeting
• Guess Factor Targeting (Predictive Targeting)
• Wave Targeting

I've managed to get all of these implemented in some form for Bubonic's targeting. The advanced targeting(Guess Factor & Wave) used some heavy statistical analysis. Even when I got it working, I realized that many of the assumptions the algorithm accounts for are impossible for a simple robot. If I had to rank these by simple Robot usability & effectiveness, predictive targeting was 3rd best of these five. Iterative Linear Targeting would be 2nd best, but it wasn't as accurate as the Non-Iterative Linear Targeting. Thus, the best overall was the Non-Iterative Linear Targeting which takes into account the dimensions of the battlefield.

The programming lessons I gained from this experience included mainly how I style my documentation. Most notably, I changed the use of certain types of comments entirely. I often would use "//" comments to redundantly explain what my code was doing. After going through Elements of Java Style, I am now using these comments to abstractly explain what the objective of the code is.

This project also required me to go out and actively learn something new(and review my Trigonometry). This process learning new things is something I am slowly getting better at. Learning a system quickly and being able to implement changes in rapid time is a skill that I'm sure all programmers wish to obtain. I was able to take in the robocode project and make my own unique changes with the system. Research & Development skill + 1! All in all, I enjoyed this open source experience.

One other lesson learned from doing this exercise was properly writing javadocs. I had a general clue as to how to use them and how to generate them, but I had no idea of the standard style to use when writing javadocs. Hopefully my documentation is now up to standard for the class, and it will be seen when reading my source code + generated javadocs.

07.Robocode

Robocode is an open source educational game that Professor Johnson has introduced us to in ICS413. It was originally developed by IBM to show the capabilities of Java in supporting a 2d game engine. However, since leaving the hands of IBM, it has evolved into a great utility for others to learn Java.

The objective of 07.Robocode, introduced by Professor Johnson, was to introduce the class to the experience of actively learning a new java system along with its respective API. We also had to get used to working with the Eclipse IDE along with refreshing our knowledge of intermediate Java.

The objectives of the 12 robot designs are as follows:

• Position01: The minimal robot.  Does absolutely nothing at all.
• Position02: Move forward a total of 100 pixels per turn.  When you hit a wall, reverse direction.
• Position03: Each turn, move forward a total of N pixels per turn, then turn right.  N is initialized to 15, and increases by 15 per turn.
• Position04: Move to the center of the playing field, spin around in a circle,  and stop.
• Position05: Move to the upper right corner.  Then move to the lower left corner.  Then move to the upper left corner. Then move to the lower right corner.
• Position06: Move to the center, then move in a circle with a radius of approximately 100 pixels, ending up where you started.
• Follow01: Pick one enemy and follow them.
• Follow02: Pick one enemy and follow them, but stop if your robot gets within 50 pixels of them.
• Follow03: Each turn, Find the closest enemy, and move in the opposite direction by 100 pixels, then stop.
• Boom01: Sit still.  Rotate gun.  When it is pointing at an enemy, fire.
• Boom02: Sit still.  Pick one enemy.  Only fire your gun when it is pointing at the chosen enemy.
• Boom03:  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).
• Boom04: 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).

Each of the robots provided their own unique challenges, but none took too long to implement. The trickiest part of the whole experience was having to learn how the robots work with bearings and the trigonometry functions needed to navigate the map. Most notably, I had to remember which functions returned radians and which returned degrees.

During the development of the simple robots, I was able to effectively utilize the Eclipse IDE. It provided great interfacing with the javadocs associated with the Robocode project. The means to implement the methods were described by the respective javadocs.

I used the sample robots for general knowledge on how to use the Robocode methods to meet the criteria for the assignment. These could be found in the Robocode installation package. Sample robots, such as the Tracker robot, provided great insight in deciphering method usage as the names of the robots provided intuitive knowledge of what to expect in the source code. The tracker robot tracks, the spin robot spins, and so forth.

The whole process felt very smooth. Whatever errors I encountered were usually displayed/flagged by Eclipse. These could generally be quick-fixed by proper selection from the recommendations provided. Thus, I believe I was able to meet the criteria for all 12 robots. The compressed Java project for 07.Robocode can be found here:

• http://www2.hawaii.edu/~kteichma/413/07.Robocode/MyRobots.zip

Since developing these sample robots, I now have a decent idea of where to go when designing a competitive robot. I will most likely use the Tracker robot, provided in the Robocode samples, as a template. I am confident that I can now at least create a Robot that will defeat: Walls, RamFire, SpinBot, Crazy, Fire,  Corners, Tracker, & SittingDuck as required by 09.CompetitiveRobot.

04.FizzBuzz

The whole premise of the FizzBuzz problem is very interesting.  After reading:

• Why can't programmers program? 
• You can't teach height: Measuring programmer competance via FizzBuzz

one can understand the significance of the problem. If indeed there are many programmers out there who aren't capable of producing this simple code on the spot, there is a just concern. The details of the FizzBuzz exercise are as follows:

• The FizzBuzz program should print out all of the numbers from 1 to 100, one per line
• If the number is multiple of both 3 and 5,  print "FizzBuzz".
• Else if the number is a multiple of 3,  print "Fizz".
• Else if a multiple of 5, you print "Buzz" .

The FizzBuzz problem is fairly trivial as long as one understands exactly what is being asked. However, if you are under pressure to solve this problem,  the order of the constraints can throw you off. When I originally devised the solution, I wrote each line of code corresponding to the order of how it was explained:

The FizzBuzz program should print out all of the numbers from 1 to 100, one per line, except that when the number is a multiple of 3, you print "Fizz", when a multiple of 5, you print "Buzz", and when a multiple of both 3 and 5, you print "FizzBuzz". 

Although I got it working, It was messy and I had arrows describing where chunks of code should be moved. 

Since I developed a working solution during my ICS413 Software Engineering class, the exercise of implementing FizzBuzz with Eclipse was easy. The exercise took roughly ~5 minutes for me to implement the code and run the program. I had no problems creating a new project in Eclipse nor with receiving any erroneous output. My code snippet is as follows:

package com.kteichma.FizzBuzz;
Public class FizzBuzz {

   /**
    * @param args
    */
   Public Static void main(String[] args) {
       FizzBuzz fizzbuzz = New FizzBuzz();
      
       For (int i = 1; i < 101; i++)
           fizzbuzz.printCorrectOutput(i);
   }
   /**
    * @param i
    */
   Public void printCorrectOutput(int i) {
       If ( (i%5 == 0) && (i%3 == 0) )
           System.out.println("FizzBuzz");
       Else If ( i%3 == 0 )
           System.out.println("Fizz");
       Else If ( i%5 == 0 )
           System.out.println("Buzz");
       Else
           System.out.println(i);
   }
}

It should be noted that in my first implementation of this assignment,  the cases contained in the method printCorrectOutput(int i); were included in the for loop. After being informed about the shortcomings of other programmers mentioned in the required readings provided by Professor Johnson, I have become increasingly interested in becoming capable in problem solving and writing code. I look forward to the upcoming assignments.