Decathlon Design

Overview
For our final project we were assigned the task of creating an interactive html mockup of our previously designed home management system using wicket. I'm very happy with our final product, as I feel it has a clean designed and useful features. I also feel that our project satisfies the three prime directives, which I will go into more detail about later. You can view our current project hosting page here. On our project hosting page you can see in detail how to use and develop our system farther. Below you can see a screenshot of our home management system's dashboard page:

Lessons Learned
A major point, which I learned about software engineering, is that it is not easy to work in groups; at least without good communication. In the beginning, we were a bit more organized: letting each other know when and what we were committing. Towards the end we were rushing a bit so all of us were all submitting revisions of the same file; this caused quite a bit of conflicts. At one point we had two different versions of a few pages, because of the conflicts I had pick and chose parts of each page to commit for the final versions. If I could've done the project again, I would have made sure we had better communication about what pages we were currently working on and planning to commit. Overall, I would still say we (Noah, Kevin, and I) worked very well as a group.

Aside from that, I definitely feel that working in a group was advantageous. If you have any kind of software engineering project, I would say working and groups and using some sort of version control is key. Being able to split the workload is extremely helpful, and with version control everyone stays up to date, and you never get too far off track.

Prime Directives

1. The system successfully accomplishes a useful task.
   I believe that our project accomplishes a useful task in the sense that it gives Team Hawaii potential ideas for the actual home's management system. Besides providing ideas to Team Hawaii, doing this project allowed me to get more experience with wicket and web design.
2. An external user can successfully install and use the system.
   As long the user has java installed they can simply download the jar or source file from here. We have an in depth user guide on our google project hosting site; the user guide can be viewed here.
3. An external developer can successfully understand and enhance the system.
   Because we used Ant as our build system, any developer can download and further develop our system with ease, regardless of operating system. Also, developers can view our developer guide wiki page here.

Deliverables
All files associated with this project can be downloaded here.

Wicket Katas

Overview
For this assignment we were given eleven different coding katas, for Wicket. A coding kata is a programming exercise, which through practice and repetition, will help you hone your skills. We were given eleven katas as Wicket programming exercises in hopes of helping us get a little more familiar with Wicket. Some of them were really easy while others were a bit more challenging, but doing these katas definitely helped me get more familiar with Wicket. I would definitely say that katas, in general, are good for helping someone get used to a new language, framework, or anything that they're new to. Repeating and practicing small exercises, at least from my experience, will help you get used to the new environment you're working in. I would say if you started with a few simple katas and then moved on to increasingly harder ones, you would probably have a firm understanding of whatever it was you were trying to learn. In the following section I will visit the eleven Wicket katas that we did in detail.

The Eleven Wicket Katas

• Exercise 01
  Kata 1A - Add a new line to the page that says, "In one week, the time will be ", where is replaced by a timestamp one week later than the timestamp that now appears on the page.
  • Finished: Yes
  • Time to complete: 10 minutes
  • Problems Encountered: The only problem I ran into for this kata was whether to use Date or Calendar for displaying the date. I couldn't figure out how to add time using Date, so I ended up using Calendar because it has an add method built in.
  Kata 1B - Add a button to the page labelled "Refresh". After pushing the button, the times update themselves.
  • Finished: Yes
  • Time to complete: 15 minutes
  • Problems Encountered: I had a problem with the buttons onSubmit method. I didn't realize that you have to override the onSubmit method.
  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.
  • Finished: Yes
  • Time to complete: 5 minutes
  • Problems Encountered: This kata was particularly easy; it just took a quick search to figure out how to change this setting.
• Exercise 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.
  • Finished: Yes
  • Time to complete: 1 hour
  • Problems Encountered: I got the image and link working properly within 5 minutes, but it took me an hour to figure out why the image wasn't rendering properly. After some help from other students I was able to fix the issue and get the image to render properly.
  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".
  • Finished: Yes
  • Time to complete: 25 minutes
  • Problems Encountered: Most of the time I spent on this kata was spent thinking of how I was going to program it. When I started programming it was pretty straight-forward and everything seemed to work smoothly.
• Exercise 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.
  • Finished: Yes
  • Time to complete: 5 minutes
  • Problems Encountered: This kata was essentially the same as kata 2A so it was very easy to complete.
• Exercise 04
  Kata 4A - Add a new cheese called "Velveeta", which costs $0.25/lb.
  • Finished: Yes
  • Time to complete: 5 minutes
  • Problems Encountered: None, this was just a matter of adding a new item to the list of cheeses.
  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.
  • Finished: Yes
  • Time to complete: 30 minutes
  • Problems Encountered: I didn't realize that I needed to modify the Address object at first, so I was only modifying the CheckoutPage java and html file. This caused errors to occur and it took me a while to figure out that I needed to modify the Address object and add in the country.
• Exercise 06
  Kata 6A - Get rid of the blue columns that appear when displaying the website. These are for development, not deployment purposes.
  • Finished: Yes
  • Time to complete: 2 minutes
  • Problems Encountered: No issues came up, I just had to change the style from "container showgrid" to "container".
  Kata 6B - Place the image underneath the form, not to the right.
  • Finished: Yes
  • Time to complete: 2 minutes
  • Problems Encountered: No issues, just had to make both the image and form divs used up the same amount of columns.
  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.
  • Finished: Yes
  • Time to complete: 40 minutes
  • Problems Encountered: I just had to do some research on how to use Properties in Wicket, besides that everything was pretty straight forward.

Deliverables

• akinsey-wicket-example01
• akinsey-wicket-example02
• akinsey-wicket-example03
• akinsey-wicket-example04
• akinsey-wicket-example06

Wicket Chart Web Application

Overview
For this venture, we were given the task of creating a website with an interactive graph using Wicket and Google Visualization. Wicket is a Java based web application framework which basically allows you to use Java to create advanced web applications, and Google Visualization allows people to create dynamics graphs with all types of data. For this task we combined Wicket and Google Visualization to produce a webpage that allows you to modify the data values, ranges, and title of the graph displayed on the page.

Learning Wicket
As mentioned by the instructor of my Software Engineering class, Wicket has a very steep learning curve. Needless to say it wasn't easy to learn; even reading Wicket in Action, a book on Wicket, didn't fully prepare me for the actual programming aspect. At first glance, the code seemed quite overwhelming but after sitting down and actually studying the code I began to connect the pieces. In my opinion, frameworks like Wicket require hands on experience to actually learn how to use them.

To be completely honest, my general impression of Wicket is that it's excessively complicated to design what should be a really simple webpage. Take the page I designed for this assignment for example: it took me six java files and one html to create. If I were to create this same page in php, a web scripting language, it would take me a single php file and be immensely simpler. One thing I particularly liked about Wicket is the fact that you can use automated debugging tools such as checkstyle, findbugs, and pmd. Finally, like how I could used an automated building system like Ant to manage the entire project, as this greatly speeds up this development and distribution process.

The Web Application
As mentioned above the function of the web application is pretty straight forward: you can modify the form values on the left of the page and the changes will reflect on the chart displayed on the right. Below is a screen shot of the application to give everyone a better idea of what the application looks like:

Lessons Learned
Given the task, I learned that web application development is definitely not as easy as it seems. The process is definitely tedious, but life can be made easier by using tools such as ant, findbugs, checkstyle, and pmd. While doing this assignment, I was really just reassured about how necessary automated quality assurance tools are. I'm glad that I got some experience with Wicket in the process of doing this assignment, and I in the future it might be useful if I have to design a large web application.

Deliverables
My Wicket chart web application can be downloaded here:
http://www2.hawaii.edu/~akinsey/ics413/wicket-chart-akinsey-1.1.1117.zip

Solar Decathlon Project: Design

Overview
As mentioned in my last post, for this project we were given the task to design a mockup user interface for the home management system of Team Hawaii's Solar Decathlon house. Unlike the previous post, in this post I will go over the design aspect of the project. The overall approach we took was to design a system that anyone could simply pick up and use without much thought. As a result, we feel we have designed a pretty well rounded home management system that should cover most, if not all, bases.

Design
Like mentioned above, our goal was to design a system where the user doesn't have to put much thought into how it use it. We were trying to follow the Keep it simple, stupid! or KISS principle; this principle basically states that your design should be simple and straightforward. We tried to achieve this by designing a very basic and intuitive template and then used this template as a basis to design each of the pages for the home management system. The end result of our initial design, was a system that was pretty simple to understand and use:

After collaborating with my group members a few more times, we were able to come up with a final design that we felt was simple and very consistent throughout each of the pages. We went back and added a few finishing touches such as rounding corners, adjusting spacing, and aligning the pages with each other. Our last meeting was basically to polish our design and make sure all the pages were consistent with one another. The final design of the home management system can be found on our group's Google project hosting site. A few screenshots from our final design can be seen below:

As far as design, I actually learned some new things while designing the home management system. First, I learned that it's not such good practice to bombard the user with lots of data and charts. The second thing I learned was that it's important to put things in terms that the user will understand; don't use language that the average user won't understand. Finally, that it's better to put minimal information on a page than to make the user have to constantly scroll down.

Solar Decathlon Project: Working in Groups

Overview
For this project we were given the task to design a mockup user interface for the home management system of Team Hawaii's Solar Decathlon house. As a group, Noah Wooden, Kevin Leong, and I decided on which features we thought the home management system should implement and got to work on putting together a initial mockup to present to Team Hawaii. We collaborated using the issues system provided by Google project hosting.

Working in Groups
Working in groups for this project, was a fun and useful experience. Being assigned groups for this project gave us the chance to get to know each other a little better and I would also say that working in groups significantly sped up the design process. All we had to do was come to an agreement about who would work on each section.

Our group had four meetings:

• First Meeting: Introduce ourselves to each other, exchanged contact information, and outlined a very broad strategy on how we would approach the project.
• Second Meeting: Talked on the phone, examined each of our initial designs and picked what we liked from each, divvied up who would handle designing each page.
• Third Meeting: Met in class, briefly showed each other what we had been working on, made suggestions for changes on each other's pages.
• Fourth Meeting: Physically met with each other, hammered out each of the pages that we were suppose to design while getting feed back from each other. Meeting lasted about eight hours.

In my opinion the most useful meeting was probably the fourth, because we actually got to sit down with each other and give one to one feedback on each of the pages we were designing. That's not to say that the initial meetings were useless, as the second meeting was actually quite productive in the sense that we were able to decide on what features we liked and divided up the work between the three of us. The only thing I would change about our meeting process in the future, would be to split the fourth meeting into two meetings as it took quite some time.

Issue Driven Project Management
As mentioned above, we used Google project hosting's issues system to assign tasks to each of our group members. A screen shot of the issues system can be seen below:

I would say there were advantages and disadvantages to using the system. Using the issues system was definitely helpful for assigning specific tasks for each group member when we couldn't physically meet; this basically made each of us responsible for a task that we agreed to finish by a certain date. When we didn't physically meet this definitely helped speed up the design process, but when we did meet I would say that using the issues system slowed us down a bit. When we physically met we would vocally assign a page to each person as opposed to using the issues system. Even though we still assigned pages for each person to work on, I feel that we worked more as a group on each of our pages (e.g. giving each other feedback and tips). As a result, the issues system more of a hassle because we had to assign a task to each person when we were really working as a whole. When we met, I felt like we were just assigning issues because we had to and not because it was useful. In conclusion I would say that using the issues system was definitely advantageous when working separately, but when physically meeting it was more of a setback.

Decathlon User Stories

Overview

The Solar Decathlon is a competition in which 20 teams consisting of college level students build a home that is powered by only solar energy. The winning house's design should blend affordability, consumer appeal, and design while maintaing optimal energy production and maximum efficiency.

Hawaii's Solar Decathlon team, or Team Hawaii, consists of a wide range of students, from electrical engineers to architects, but the one thing the team is currently lacking is computer science students. The goal of this current project is to have students from our software engineering class hopefully help and maybe eventually join Team Hawaii in the Solar Decathlon competition by designing a mock up user interface for the home management system of the house. This system will control and monitor multiple features of the house such as lighting, H.V.A.C., power statistics, and entertainment.

Before we can get into the design of the home management system, we have to look at what requirements that users of the house would like. To do this we're assigned the task of creating ten user stories that will describe interactions with users and the system, and it will explain the goals and benefits of the interaction. In short, wikipedia says that a user story "...is one or more sentences in the everyday or business language of the user that captures what the user wants to achieve."

User Stories

Power
• As a user of the system, I would like to be able to monitor the distribution of the energy consumption. For example I would like to see how the energy is being dispersed to the different functions of the house, such as lighting, entertainment, H.V.A.C., or the AquaPonics system. When one system (e.g. The H.V.A.C. system) of the house is consuming too much energy the home owner should be notified via an alert. As a result of being able to view these statistics and monitor the behavior of the power usage the user would be able to see which areas that they need to cut back in, whether it be not running the lights as often or turning down the air conditioner.
• I would like to be able to see how much energy, on average, the house produces per day. This would allow me to predict the power production over next few days. Because I can predict the amount of energy that my house should produce on a certain day, I can set a target power usage goal for that day. This will allow inhabitants of the house to not go over their power budget.

Lighting
• I would like to be able to control the brightness of the lights in the home as well as the hue, through the home management system. Brightness level is a bit of a necessity, as sometimes you need to work in a bright surrounding, while other times you need to work in low light settings. Being able to control the color of the lights is also important; say I wake up in the middle of the night and don't want to be blinded by white light, instead we could use amber. By being able to simply control the lighting, the user has full control of their working environment, as a result this could increase productivity.
• I would like the ability to lock the lights over wherever I currently am in the house. This would allow the user to sit at a desk and lock the lights directly above the desk, turning off the lights everywhere else. One advantage of being able to localize the light, is that it would save energy. Instead of having all the lights on we can just have light where we need it.

H.V.A.C.
• I would like to be able to set the max and minimum temperature that the house is allowed to reach. This would prevent the house from ever being too cold or too hot. For example if it is hot, but we want to conserver energy, we could set the max temperature to something moderately high like eighty-five degrees. This would allow the house to not turn on the air conditioner until it reaches the max temperature set by the user, as a result we conserve energy.
• I would like to know how much power is allotted to the H.V.A.C. system. I would like the interface to show me how long I can run the air/heat for before having to turn it off and recharge the system. This will allow me to efficiently manage my use of the H.V.A.C. system. This too, will also help in conserving energy.

AquaPonics
• As an occupant, I would like the ability to monitor the AquaPonics system. Because this system is tied into the ecosystem of the home, being able to monitor it and make sure everything is running correctly is extremely important. I would like the home management system to allow me to monitor the pH levels of the water. If the pH level is off significantly, the system should alert the occupant and provide a number of a technician to call for assistance.

Entertainment
• I would like the ability to voice activate and control the television using the home management system. Alternatively the user should be able to control the television when using the home management system application on their smartphone. This would allow the user to control all aspects of the television entertainment system, such as controlling the volume of the sound system associated with the television. This allows ease of use, and it is very convenient for the user.
• The ability to control music using voice activation would also be important. While not a necessity, it would appeal to the average user of the home. Voice control would allow the user to select music by just saying the name of the song. Likewise, with the television, the music should be controllable via smartphone too.

General
• The main interface of the Home Management System should be integrated into a touch screen slate like device, such as the iPad, located within the home. It should allow the user to control all of the previously mentioned aspects. As well as being integrated into the slate device, the Home Management System should be portable to the web and smartphone devices. This will allow the user ease of control of the home wherever they may be.

Website Usability

Overview

Usability, in terms of web design, is the ease of use of the website for a user. If a website has poor usability, people will leave your website. In order to have a successful website with good usability you must follow a few simple rules.

• Appease the user: A user shouldn't have to think to use the website. Everything about the site should be straight forward, from the content to the user interface.
• Keep it simple: Don't over-complicate the user interface or design of your website. If the user interface isn't simple the users will be confused and leave. If the design of your website is messy/cluttered people will leave.
• Be straight forward: Don't beat around the bush when trying to convey a message on your site. Be straight forward and say what you trying to say as simply as possible.
• Follow conventions: It is important to follow conventions when designing your website (e.g. putting the "sign in" link on the upper right side of a webpage) as it will greatly decrease the learning curve for your website. If you do everything against the normal conventions of making a webpage, users will have a hard time learning how to navigating/use your website.
• Test your website: It is important that you make your website adjust to the user and not the user adjust to your website. A user shouldn't have to download a specific browser to view your website, you website should work with multiple browsers. It is also important that before you release your site, you test the usability of it by observing a few people actually using your website.

Examples of Good Usability

1. Imgur: A simple image sharer


This is an example of good usability because it gets right to the point. Everything a user needs the site for is on the front page. The purpose of the site is to host images, so the site gives the option to simply upload an image from your computer or from another site all on the front page. This is a user interface in the simplest form, if one requires more options they can optionally create an account to gain access to those features.

2. Dropbox: Online file storage


Dropbox is a also another example of a site with a really simplistic user interface on the main page. When you first come to the site you are presented with a video that explains what Dropbox is, then right below is a link to download it. Those two things are what users come to the site looking for: what the tool does and where to get it. As a result of the video and download link being very large and hard to miss, the users don't have to think twice about how to use the site. It also uses standard conventions of putting the login information in the top right corner of the website.

Examples of Bad Usability

1. Havenworks: A political news site


This website obviously has bad usability in the sense that it is completely cluttered. The navigations isn't straight forward or standard at all; there are many sub-links in content of site, for example. Also there are walls of text with no bold keywords which makes it very difficult to skim over the content. If the design doesn't turn users away, the usability definitely will.

2. Jones Chijoff: Designer


This is a fine example of a site that has an appealing design but a poor user interface. The user interface that this person uses is completely nonstandard and will most likely be confusing to the average visitor; the user will have to learn how to use it. The way that the website presents itself leaves visitors wondering what services this person offers, or even what the point of the website is.

RoboHosting

Overview

For this assignment we were asked to create a google project hosting page for our existing robocode project, in my case robocode-ajk-wallspin. We were assigned to set up the google hosting page to allow use of subversion for content management updates and also to create wiki guides for developers and users of the project. Along with a google project hosting page, we had to set up a google groups page for the discussion of our project. Overall I would say this was a great learning experience and will help me in the future if I am ever part of a large (or small) development group. I was able to complete all of these task successfully, with little difficulty, after a little trial and error. The most difficult part of this task was setting up the wiki pages for the project and learning about the wiki syntax; other than that it was a pretty straight forward task.

Lessons Learned

Like mentioned above, I mostly learned about using subversion and google project hosting to allow content management for developing projects. I definitely think this will be a useful tool for future projects, and in fact I have already set up a google project hosting page for a project I have in my ICS 451 (Data Networks) class. I will be working on a peer to peer program for this class; I will be working with two other students so using subversion and google project hosting will greatly improve our workflow since we will be working on multiple copies of the same code. I'm hoping to learn a lot more during the course of this project, as we will most likely be using it more in depth.

Useful Links

• Creating a new Google Code project
• A short guide on setting up svn
• WikiSyntax Reference Guide

Deliverables

• Robocode-ajk-WallSpin Project Page
• Robocode-ajk-WallSpin Project Discussion Page

RoboTesting

Overview
This was my first experience with writing JUnit tests so it was a fun learning experience, but also a difficult one. We were assigned to write six tests for our existing robocode project: two acceptance tests and four behavioral or unit tests. For my project I wrote two acceptances tests which tested my robots WallSpin's ability to beat two other robots; in my case the SittingDuck and RamFire Robots. I wrote three behavioral tests which tested that WallSpin visited each corner of the arena, visited the center of the arena, and spent at least fifty percent of its time in wall mode when facing the Crazy robot. The last test I did was a unit test, which tested that WallSpin's firePower method returned a bullet fire power relative to the enemies distance.

Tests

• TestWallSpinVersusSittingDuck
  Type: Acceptance Test
  Overview: This tests that WallSpin can successfully beat SittingDuck.
  Difficulty: This test was rather easy to create as it was based off of the example test provided for this assignment.
  Test Quality: I feel that this test in particular, because it is only facing SittingDuck, does not really ensure the quality of my robot. All this test really does is make sure that my robot knows how to target and fire at a stationary robot.
• TestWallSpinVersusRamFire
  Type: Acceptance Test
  Overview: This tests that WallSpin can successfully beat RamFire.
  Difficulty: Again, this test was also pretty easy to create; it was just a matter of changing the robot that WallSpin should face, from SittingDuck to RamFire, from the previous test case.
  Test Quality: This test does ensure the quality of WallSpin, in the sense that it guarantees that WallSpin can beat another simple robot which can track and attack. It is important that WallSpin can beat certain robots, like RamFire, a hundred percent of the time.
• TestWallSpinMovement
  Type: Behavioral Test
  Overview: This tests that WallSpin visits each corner of the arena.
  Difficulty: Like the first test mentioned, this was easy to write as I just used the example class file provided for this assignment. It just so happened that my Robot used wall movements, so it should be guaranteed to visit each corner of the arena.
  Test Quality: I would say that this is a valid and important test because it makes sure that my robot is behaving the way it should. This test reassures that WallSpin will visit each corner of the arena when facing SittingDuck.
• TestWallSpinCenterMovement
  Type: Behavioral Test
  Overview: This tests that WallSpin can will move to the center of the arena when hit by a bullet.
  Difficulty: This was a bit more difficult of a test to write, because I had to calculate the center of the arena and take into account the size of the robot. I basically had to test if the robot was within fifty units of the center in either the x and y coordinates.
  Test Quality: This test does ensure the quality of WallSpin because it makes sure it is behaving the way it is supposed to: moving to the center of the arena when hit by a bullet. To guarantee that WallSpin is hit by a bullet, I make it fight the WallsRobot. If WallSpin were to not move to the center of the arena during its battle with Walls, it would mean that there is a flaw in WallSpin's code.
• TestWallSpinPercentageMovement
  Type: Behavioral Test
  Overview: This tests to see that WallSpin spends at least fifty percent of its time along the walls when facing the Crazy robot.
  Difficulty: This test was a bit difficult to write as I had to calculate the range of where the walls lie in the coordinate system, then check during each turn if WallSpin was within those coordinates. At the end of the rounds I divide the number of times WallSpin was along the walls by the number of turns that WallSpin took, this provides me with the percentage of time WallSpin was riding along the walls. Thinking of how to conceptually write the test was more difficult than actually writing it.
  Test Quality: I would say this is an important test of WallSpin's behavior, because depending on the robot it faces, it should spend roughly fifty percent of its time in wall mode. If it's not then something is wrong with its code, or the robot it is facing has trapped it in a corner.
• TestWallSpinFirePower
  Type: Unit Test
  Overview: This tests to see if WallSpin's firePower method returns a firepower relative to the distance of the enemy.
  Difficulty: This test was pretty difficult to write, because I had to modify the source code of WallSpin to allow this unit test. I had to make the firePower method take the maxDistance of the arena and the enemy's position as parameters to be able to unit test the method. In the unit test I set the maxDistance as five hundred and give firePower varying positions for the enemy's distance.
  Test Quality: This test is probably one of the most valid and important tests, as it makes sure that WallSpin is firing bullets proportional to the enemies distance. If this test fails this means that WallSpin's code is flawed and that WallSpin is most likely either wasting too much energy or using too little energy.

Jacoco
Running Jacoco showed that my WallSpin class had a total of seventy-two percent coverage. Basically it showed me what I already suspected, that some of the code in methods like moveToCenter are not guaranteed to be reached all the time. In WallSpin's moveToCenter method there are some cases I check for that will rarely be reached, such as the special case where the robot is already in the center when moveToCenter is called. Even though it showed me things that I already knew, the Jacoco output was very interesting to look at. I've never seen a tool that showed the coverage of the code, and I definitely believe that this can be a useful tool for detecting errors in my future projects.

How could I redesign WallSpin to make it easier to test?
If I were to rewrite WallSpin I would definitely separate its methods more effectively and make them have return values as opposed to being void. This would make it much easier to write unit tests for WallSpin. I actually had to modify WallSpin's source code in order to write the firePower unit test. I would also give the robot more defined movement patterns, as it would be much easier to create behavioral tests for. With the existing source code I had, it was very difficult for me to come up with my behavioral and unit tests.

Download
To download my WallSpin robot distribution click here.

Competitive Robot: WallSpin

Overview
For this assignment we were given the task of creating a competitive robot that only extends the Robot class. I approached this assignment by analyzing which of the sample robots did best, and then chose to combine the two strategies that I thought worked best. The prior Robocode assignment was a warm up to get us ready for making our competitive robot, and seeing how I used a few strategies that I had learned from that assignment, I would say it was a great warm up.

In the following sections I will explain what approach I took when designing my competitive robot. I will also go into the advantages and disadvantages that my strategy presents.

Design
Movement is one the strong points for my robot, since it combines the wall strategy with a move and spin strategy. WallSpin starts off by moving to the top wall, it then continues to move along the walls and fire just like the Walls robot; it does this until it is hit by a bullet. Once hit by a bullet it switches to spin mode: WallSpin will move to the center of the arena then loop between moving forward and spinning, and moving back and spinning. Whenever WallSpin is hit with a bullet it switches between wall mode and spin mode, under the condition that the bullet hits are at least six seconds apart. As for wall collisions, if it collides with a wall in wall mode it is ignored, but if it collides with a wall in spin mode it backs away from the wall. Finally, if WallSpin collides with another robot it determines if the robot is in front of it or behind it and moves away accordingly.

Targeting for WallSpin is extremely basic. WallSpin will only fire when its gun meets meets paths with another robot, and its gun is always facing sideways. This means that in wall mode WallSpin always has its gun facing away from the wall it is riding, and in spin mode it has to do spin to scan for robots. In other words, my robot doesn't track a specific robot; it just fires at the first robot it scans. In retrospect, I think it might have been more effective to make the gun track the closest robot while in spin mode and be at a set angle while in wall mode.

Firing is another strong point for WallSpin. I based the firing implementation off of the previous assignment's Boom03 robot; it fires bullets proportional to the distance of the enemy. If the enemy is close it will fire powerful bullets and if they're far it will fire weaker bullets. This is effective because when you fire bullets you lose energy proportional to the power of the bullet. This strategy is an alternative to firing weak bullets repeatedly and doing minimal damage, and firing strong bullets and wasting the robot's energy fast. WallSpin also detects if it hit the enemy with a bullet of power greater than two, if it did then it fires another high powered bullet immediately. My thought behind this was if WallSpin hit the enemy with a high powered bullet, the enemy is probably close and will most likely be hit again.

Results
I tested WallSpin against eight sample bots: Walls, RamFire, SpinBot, Crazy, Fire, Corners, Tracker, and SittingDuck. My test consisted of battling each sample robot ten times and reporting its percentage of wins to losses. Here are the results of my testing:

• WallSpin(60%) vs. Walls(40%)
  Walls seems to be on par with WallSpin; I would say that it is a pretty level playing field. These percentages were obtained from the first ten battles I ran, I ran ten more battles and the results were even closer; %50 wins for WallSpin and 50% for Walls. I think it does decent against Walls because it uses a very similar strategy.
• WallSpin(100%) vs. RamFire(0%)
  These battles were a complete shutout, as RamFire didn't win a single round. I think WallSpin does so well because it is almost always moving and RamFire spends most of its time trying to catch up instead of attacking.
• WallSpin(80%) vs. SpinBot(20%)
  Theses battles seemed like they came down to luck for SpinBot. The only time SpinBot won was when it trapped WallSpin in a corner and WallSpin couldn't navigate away. Due to SpinBot's relatively fast fire rate, if it traps WallSpin it will always win. If I were to try and solve this issue I would probably have to implement more advanced evasive maneuvers to avoid getting trapped; perhaps I could try to ram the enemy in this scenario.
• WallSpin(100%) vs. Crazy(0%)
  These battles were very one-sided; Crazy didn't stand a chance against WallSpin. It seems that the majority of the time Crazy was really far away from WallSpin and when it did get close, with its erratic firing behavior, it rarely landed a bullet. Most of the damage dealt to WallSpin was from Crazy ramming into it.
• WallSpin(90%) vs. Fire(10%)
  This was also a fairly one-sided battle, and the only time Fire won was when it got WallSpin in close range and unleashed a barrage of bullets on it. I think Fire is at a disadvantage because it spends the majority of the time sitting still which makes it an easy target for WallSpin when it is in wall mode.
• WallSpin(20%) vs. Corners(80%)
  Corners was the biggest challenge for WallSpin, as the only time it won was when it prevented Corners from reaching a corner. I think Corners does a really good job because it has such a fast fire rate and a great tracking system. If I wanted to beat Corners I would probably have to implement a better tracking/firing system.
• WallSpin(100%) vs. Tracker(0%)
  WallSpin destroys Tracker because it spends most of its time in wall mode, due to Tracker spending most of its time trying to catch up. I think Tracker would have a chance if it got WallSpin out of wall mode, but even then if it were to shoot WallSpin again it would just go back into wall mode.
• WallSpin(100%) vs. SittingDuck(0%)
  This is an obvious win because SittingDuck doesn't attack at all.

Lessons Learned
I actually did learn something new about software engineering by doing this assignment; mainly about the development process. For this assignment I took a different approach than I usually do, as I normally program everything first then comment last. Instead, for this assignment, I laid out the structure of my entire program and then started by doing JavaDocs for each of the methods. I was amazed at how much faster and more efficient I was able to write my program. I knew what each method was supposed to do before even implementing it; this might not seem like a big deal, but it actually helped a lot.

Though it was much simpler to code my robot, I did still run into issues and have bugs. In the beginning, when I would find a bug, I would make some rash decision and make a drastic change in an attempt to fix the issue. That didn't go so well. As I found out my approach wasn't working, I decided to actually sit down and read through all of the code to see if I could pinpoint where the issue was; this was the right approach. As soon as I did this, I was able to find my bug and fix it almost immediately. I would say that one of the lessons I learned was patience, because I wasn't able to fix my bugs by just blindly trying to change things. I had to stop and think about the problem, then analyze my existing code to narrow down where the issue was coming from.

If I could do this project over again, and if I had more time to work on it, I would have liked to analyze each of the strategies of the sample robots in more depth and come up with a better overall strategy. Though I believe my strategy is decent, I think I could have come up with a much better strategy given more time to think about and work on the assignment. Overall it was still a great learning experience.

Download
You can download my packaged robot here.

Robocode

This weeks project was to start working on Robocode. Robocode is a program written in Java which allows programmers to create robots and make them battle in an arena. For this assignment we are creating robots to perform some simple, and some not so simple tasks.

This is the first time I have ever worked with Robocode and I actually find it to be really fun. Doing to tasks that involve planning the movement of the robot are really refreshing my memory on Trigonometry. I also haven't worked too much with Java lately so working on this assignment is really helpful.

Here is my checklist for the assignment:

• Position01: The minimal robot. Does absolutely nothing at all.
  Creating this robot was beyond simple; all I had to do was create an empty class.
• Position02: Move forward a total of 100 pixels per turn. When you hit a wall, reverse direction.
  This robot was also relatively simple, though it required me to look in the API for the onHitWall() event.
• 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.
  The one was still pretty easy, just took some very simple incrementing.
• Position04: Move to the center of the playing field, spin around in a circle, and stop.
  I decided to have a little fun with this one. I saw that a lot of people were making the robot face north then move up on the y-axis till it was centered and then move along the x-axis till it was in the center of the map. I wanted to give myself a bit of a challenge and make the robot make one diagonal move to the center as opposed to two moves along the y and x axis. It took me about ten minutes to work it out on pencil and paper. I took the following approach:
  
  1. I check the quadrant the bot is in
  2. I face the bot north
  3. If the bot is in the upper two quadrants I rotate it to face south
  4. I calculate the angle using the following formula: angle = arctan(opposite/adjacent)
  5. Rotate toward center using angle found in previous step
  6. I calculate the distance needed to travel using the Pythagorean Theorem: c = sqrt(a^2+b^2)
  7. I move ahead the distance calculated in the previous step
• 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.
  This used similar mechanics as Position04 so this was still very basic as far as the programming went.
• Position06: Move to the center, then move in a circle with a radius of approximately 100 pixels, ending up where you started.
  Again, this was a build off Position04. The only semi-difficult part was getting the robot to follow a path with a radius of 100 pixels.
• Follow01: Pick one enemy and follow them.
  At first I was lost on this but I was able to look at the Tracker robot, which was provided with Robocode, as inspiration. After reviewing the Tracker robot which did something similar I was able to piece together which events and methods I needed to make this robot work.
• Follow02: Pick one enemy and follow them, but stop if your robot gets within 50 pixels of them.
  This was just a build off of Follow01; it was just a matter of adding an if statement which check if the robot was within 50 pixels.
• Follow03: Each turn, Find the closest enemy, and move in the opposite direction by 100 pixels, then stop.
  At first I was a bit stressed about this one, because I couldn't figure out how to detect the closest enemy. After researching a bit I discovered that the onScannedRobot method actually returns the closest robot. This made things a lot easier; all I had to do was rotate towards the detected robot and back away 100 pixels. I also decided to check when a wall was hit, because the bot would repeatedly smash into the wall when I didnt.
• Boom01: Sit still. Rotate gun. When it is pointing at an enemy, fire.
  This was one of the simpler robots to code; it just took a little research. All this one does is spin its radar to detect an enemy, when it does it fires its gun.
• Boom02: Sit still. Pick one enemy. Only fire your gun when it is pointing at the chosen enemy.
  This robot is nearly the same as Boom01 except it picks one enemy and only shoots at that enemy. I had to add a variable which stores the name of the enemy, and every time an enemy is scanned it just compares the name to make sure it's the same 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).
  This robot posed a slight challenge. I decided to calculate the max distance obtainable in the arena and then detect how far the enemy was relative to the max distance. Based on that information I have the robot fire with power relative to the distance of the enemy.
• 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).
  This was a pretty simple task, all I had to do was rotate the radar continuously to scan for the target robot. When the target robot is detected I just have my robot turn its gun towards it. This is updated every time the enemy is scanned so it is updated constantly.

The overall experience of this assignment was pretty fun. Though I'm still a complete novice to Robocode, I do feel like I will have a slight advantage now when writing my competitive robot. I feel more prepared than I would be if I were just assigned to write the competitive robot right off the bat. I'm thinking of doing a combination between the existing Wallbot and Spinbot while using the targeting technique of Boom04. I definitely think this was a great warm up exercise. My source code for this assignment can be found here.

Open Source Software - PDFsam

Overview
Description:
PDFsam is a Java based open source program that allows the user to manipulate PDFs in various ways. Some of the basic functions of the program allow for the rotating, splitting, extracting, merging, and splicing of PDFs. The program comes in both command line and GUI format to suite the preference of the user.

URL: http://sourceforge.net/projects/pdfsam/

Stated Objectives:
A simple tool designed to split and merge pdf files. With it’s simple and intuitive interface you can:

• split your pdf documents (into chapters, single pages, etc.).
• merge many pdf documents or subsections of them.
• extract sections of your document into a single pdf document.
• mix alternate pages taken from two pdf documents in straight or reverse order into a single document.
• rotate pages of the selected pdf documents.
• visually reorder pages of a selected pdf document.
• visually compose a document dragging pages from selected pdf documents.
• save and load your environment to automatize your recurrent jobs.
• manage pdfsam settings and set an environment to load at start up.

Visual:

GUI Interface of PDFsam

Prime Directive 1
PDFsam is a bare bones PDF manipulator which allows users to effectively and efficiently modify PDFs; I've come to this conclusion after running PDFsam on a few PDFs of various sizes. It is an open source alternative to expensive paid software such as Adobe Acrobat. Though PDFsam does not have all of the features that Adobe Acrobat does, it still has the core features that allow the user to split, merge, rotate, and splice PDFs. For most people looking for a free alternative to Adobe Acrobat, these basic features should satisfy their needs. Though PDFsam only has a few basic functions, it performs these functions exceptionally.  PDFsam might not have every feature that a paid PDF editing program might have, but due to it being open source it leaves room for any programmer to come along and add more features.

For my job at UHM's Hamilton Library I often find myself having to do some tedious task involving PDFs, and thankfully at my work place they have Adobe Acrobat installed. The only problem with this is that I have to physically be in the library to do work that pertains to PDFs, which is quite a pain as I work remotely the majority of the time. After testing this program with various PDFs I would say it can effectively perform the same basic features of merging and splitting that Adobe Acrobat can. If I had known about this software sooner, I would have definitely used it in the past. One thing I am sure of, is that I will definitely be using PDFsam for future tasks involving PDFs.

Prime Directive 2
An external user should be able to install PDFsam without an issue. For Windows users PDFsam downloads as an executable installer and for Mac users it downloads as a DMG file, both of which are standard for installing programs on their respective systems. 

As for use of the program, there is extensive documentation on how to use the software. For an average computer user the program should be pretty straight forward regarding use, but for others it might require a quick reading of said documentation.

Without reading the documentation I was able to install and use this program without any issues whatsoever. I was able to run the program for the first time and merge a PDF without reading a manual; it was rather intuitive.

Prime Directive 3
An external developer would be able to pick up and develop more plugins for this PDFsam, and even make changes to the core program. The structure of this program is very modular; the entire source is extremely well organized. All of the class files are accurately named such as MainGUI.java, PlugInsLoader.java, and MergeMainGUI.java. Along with well named classes and modularity, the whole project is actually exceptionally documented and has an API as a resource for developers.

After taking a brief look through the source of the project I can understand bits and pieces of code, but to actually pick up and develop for this project I think one would need a solid understanding Java and how to write code to modify and export PDFs. To actually pick up and write code for the PDFsam project one would probably have to study the code and API for quite some time as the code seems fairly complex, at least from an undergrad point of view. 

Fizz Buzz Program

Time to implement: 35 minutes (including documentation)

The last time I programmed in java was for my ICS 311 (Algorithms) class about three semesters ago, so I had to look up the proper way to do that javadocing. Other than that I had minimal issues.

One concern that did come up while I was programming was whether or not to print the output in the main method or in the calcFizzBuzz method. After a bit of debating with myself I figured it would be more efficient to call System.out.println(); once in the main method as opposed to four times in the calcFizzBuzz method. Another option would have been to create a variable to store the String to be printed, then at the end of calcFizzBuzz I could have just printed that variable. I figured this was unnecessary and it was most efficient (in my mind) to do it the way I have displayed below.

Doing this assignment reminded me that writing code isn't as simple as creating a program that produces the right output. Code needs to be well written and well documented, if anyone were to ever look at your undocumented code, they would probably go crazy trying to figure out what you were thinking. Software engineering is usually done in teams, and because of this people need to write clear, concise, and well documented code.

package FizzBuzz;

/**
* Fizz Buzz program for ICS 413
*
* Program loops from 1-100 printing: "Fizz" for multiples 
* of 3, "Buzz" for multiples of 5, "FizzBuzz" for multiples
* of both 3 and 5, or the actual integer if it isn't a multiple
* of 3 or 5.
*
* @class  ICS 413
* @author     Anthony Kinsey
* @date   August 28, 2010
*/
public class FizzBuzz {

/*
  * Main Method
  *
  * Loops from 1-100 and calls calcFizzBuzz method
  * to generate the proper output.
  *
  * @param   args[] - Ignored
  * @return  void
  */
public static void main (String[] args) {

   FizzBuzz fizz = new FizzBuzz(); //create instance of this class
   
   for(int i = 1; i < 101; i++) //loop from 1-100
     System.out.println(fizz.calcFizzBuzz(i)); //print output obtained by calling calcFizzBuzz

} // end method main
   

/*
  * calcFizzBuzz
  * 
  * Determines if the provided integer (num) is a multiple of 3, 5, or 3 and 5
  * and prints the following:
  * 
  * if num is multiple of 3 - output is "Fizz"
  * if num is multiple of 5 - output is "Buzz"
  * if num is multiple of 3 and 5 - output is "FizzBuzz"
  * if num is neither a multiple of 3 or 5 - output is String representation of the integer num
  *
  * @param   int num - the integer to analyze
  * @return  String - returns Fizz, Buzz, FizzBuzz, or String representation of an integer
  */
private String calcFizzBuzz(int num) {
   
   if(num % 15 == 0) return "FizzBuzz"; // multiple of 3 and 5
   else if(num % 5 == 0) return "Buzz"; // multiple of 5
   else if(num % 3 == 0) return "Fizz"; // multiple of 3
   else return String.valueOf(num); // neither a multiple of 3 or 5
   
} // end method calcFizzBuzz

} // end class FizzBuzz