Decathlon Design 2.0

Last month I made a post about designing the layout for a system that would be used by teamhawai‘i's entry into the Solar Decathlon.  For our final project of the semester we've worked on transferring the project from Balsamiq Mockup to HTML.

For our project our group implemented Wicket, CSS, JavaScript and Ajax to give our web app the look that we would like it to have before we add the functionality (a project for next semester.)  For this assignment we were evaluated on three prime directives:

1. The system successfully accomplishes a useful task.

 I believe that our system will help users of teamhawai‘i's house with a fun and simple interface to easily obtain data regarding the house's functions.  I think our group tried to push the design to be fairly interactive, and to allow the user to take control of the system when needed.  The house functions may be a trivial for this assignment, but they're there to set the base to build off of for future development.

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

Our system is packaged and ready for distribution.  Download the latest version from our site's downloads section and be sure to read the installation guide to avoid any problems.  The system is completely compressed into a .jar file, and it contains almost everything needed to run the web app locally on the host's computer (you need java installed on the system to run the .jar.)  Once you've downloaded our latest distribution, navigate to the directory the .jar file is located in Terminal or command prompt and type the command: %java -jar filename to run the app.  Ant will go through the build process to create all the class files and set up Jetty to act as the web server.  After the installation process is completed the user will be prompted to visit the URL where they can view the web page.

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

Our code is well documented to help any new developers understand the program's layout.  This was pretty much the first time anyone in our group has actually tried web programming, but we tried to document our HTML because there are probably a few coding conventions we didn't follow there.  The pages are pretty modular.  To add a new page to the project, a developer just needs to extend the base page and provide a side bar.  We look towards improving the layout of the system to allow it to be more modular and to include better CSS rules to make everything more consistent.

Final Thoughts

Overall, this was a great experience.  I've been meaning to get into web development, and this project gave me a little taste of it.   From a software development standpoint, this exposed me to working with a group on a program.  We ran into a few problems including: inconsistent file versions, variable names and different coding conventions our group ran into during the development process, but we were able to fix most of them.  There's a lot of work that goes into working in a group project, but I believe the most important factor is to always have open lines of communication with your group members.

Wicket Katas

Code katas from a programing perspective are exercises in programming that help you to refine your skills, and we were given a few to sharpen our Wicket programming skills.  Here are some of the examples that were modified in this exercise.  Below I have provided you the links to all of the original files and the corresponding exercise that go along with them.  You can download my files here.


Example 1: Hello, World!  (Original)
Kata 1A:  25 minutes  ✔
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: 10 minutes  ✔
Add a button to the page labelled "Refresh".  After pushing the button, the times update themselves.
Kata 1C: 20 minutes  ✔
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.


The katas ifor example one were not that bad.  I think the hardest part was trying to find the right methods to format the time to add a week.  Othere than that, everything seemed pretty straightforward.


Example 2: Links, Lists, Forms, Tables  (Original)

Kata 2A:  40 minutes  ✔

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:  2 hours 30 minutes  ✘

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".

General Idea: Find a dynamic way to insert corresponding bold and italic HTML tags at the front and end of the document.  

I particularly had some trouble with this task.  The first approach I tried was one that I would use in PHP, which involved having a conditional of some sort that would allow a certain Wicket tags to appear under certain conditions.  This isn't how Wicket works though.  Tags must be in place before the page is loaded or else it will throw some nasty syntax errors saying that either the tag has been created, but it cannot find a variable, or vice-versa.  So this idea was not going to work.

Another idea I had was to dynamically change the data that was being assigned to the label using StringResourceModels.  I have a feeling that this is the 'correct' way to do it, but implementing these objects was a little bit beyond my current Wicket knowledge.  My current understanding of these objects is that under certain conditions, the data that is displayed can change, whether it's being passed a certain type of object, or by using get methods on the object to return data corresponding to the current state of the object.

The third idea I thought was to create every label and button, and adjust their visibility via the Component.setVisible() method.  Unfortunately I had some trouble with my buttons setting these values to true or false for some reason.  It would seem that every time the page is reloaded it will reinitialize the boolean values to their default values, which didn't help much.

The last pitch effort for this task was to just create 3 static web pages and link them all together and have the corresponding tags and buttons on each page, but I felt that would not really accomplish the assignment from a developer standpoint, even though it would yield the correct output (except the pages would all be different).

Example 3: CSS Formatting  (Original)

Kata 3A:  8 minutes  ✔

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 exercise was very simple.  It involves one method call to fetch an image and display it to the screen.  Creating the link to the new page was also very easy since it is the same code as the other 4 pages.

Example 4: Cheesr  (Original)

Kata 4A:  10 minutes  ✔

Add a new cheese called "Velveeta", which costs $0.25/lb.


Kata 4B:  30 minutes  ✔

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. 


The first one was fairly simple.  You just have to add another item to the list, and you can easily follow the format of the other listed items.


Adding the select form was slightly difficult not because of the difficulty of the coding, but the amount of methods you had to create.  Many of them were get/set methods to ensure that the address objects were getting all the info needed to make a shipment.  I enjoyed this one, since it involved a bit of tracing.

Example 6: Blueprint, CSS, Sessions, Forms  (Download)

Kata 6A:  2 minutes  ✔

Get rid of the blue columns that appear when displaying the website. These are for development, not deployment purposes.
Kata 6B:  3 minutes  ✔

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.


The first two were by far the easiest out of all the katas, requiring you to disable some CSS code, as well as move an image into another div.  But the same cannot be said of the last kata.  I wish I had more time to figure this one out.


Thoughts
I think it may help that I've been recently trying to teach myself PHP, but the flow between PHP and Wicket have some similarities.  I think I could get kata 2B down once I learn how to use more of Wicket's API, but it's always fun to have some dynamic coding for web apps where you have your higher languages spitting out HTML code that will be interpreted not just as characters.  I think these exercises helped to sharpen not only my Wicket skills, but also my general web development capabilities.  Working with services like Jetty help you realize how all the components of a web server come into play to take in user input, interpret it, and give back the expected results.  I will try to update this blog as I complete the last two of these exercises that eluded me.

Wicket Chart

For this week's assignment we were exposed to a Apache Wicket,  which which is a web application framework that allows you to do web programming in Java.

Initial Thoughts

This was the first time I had ever heard of Wicket.  As a novice web developer, it reminded me a lot of PHP.  Similar to PHP, Wicket uses a model-view-controller (MVC) architecture.   Wicket interacts with an application server (in my case I am using Jetty) which then uses Java code that is on the web server to handle the Wicket requests.  The server returns the output which is viewed by the user.

From a development standpoint, I feel it can be a very slow process waiting for Java code to compile, whereas working with a scripting language like PHP gives immediate results.  But being able to have the strength of a full programming language behind your web application allows for many options that are not available to scripting languages.

Wicket Chart (Download)

This was my first web application I've created using Wicket.  The idea is to allow the user to modify a Google visualization (in this case a GoogleOMeter) through the web application.

Setup

1. Open up the directory and run the command: %ant -f build.xml
2. Once the installation is complete run the command: %ant run
3. Open a web browser and go to the url: http://localhost:7070/Wicket-Chart

Once the program you have Jetty running, you're ready to view the web application.  It is a single web page that will have a form filled with preset values.  After modifying the field values, you can view the changes to the graph by clicking the 'Submit' button at the bottom of the form.  This will refresh the page and update the fields and image to reflect the changes.

Testing

There are a few simple checks that my program covers when the user inputs.  My program will check to make sure that the user has filled in the values.  If the fields are left empty, they should default to 0.  Another check I implemented was to check to make sure that the min value was indeed smaller than the max value.  In the case that this test fails the min and max value will be set to 0 and 100 respectively.  If the value does not fall between the min and max value it will be assigned to one of the ends.

The final feature that my program provides the user is an automatic scaling system.  Google restricts their images to:

• 1 px ≤ width/height ≤ 1000 px
• width * height ≤ 30000 px

If an image is too large, Google will usually throw an error that looks like this:

Usually the user would get an invalid image, but I tried to implement a simple check that will scale images down to an acceptable range, while keeping the dimensions proportional.

Decathlon Design

This week I was able to create a few mock up pages for the Solar Decathlon system that our software engineering class is currently working on.  Initially we worked on our designs individually before we were assigned to groups of three or four students.  As I mentioned in an earlier post my background is in print layout and design working for our school's newspaper.

Initial thoughts

Main Menu

The key to working together as a team is to always have some an line of communication with every member.  Working in a group is nothing new to me, and working with a couple friends made this group experience even more enjoyable.  Being comfortable enough with your team to present 'off-the-wall' ideas without fear of being judged harshly allows the group to come up with some ideas that you wouldn't normally come up with on your own.  I must admit that I was also relieved to be working in a group because that meant that the work load would be spread out, which would allow me to focus on what I like to do, layout design.

When our group first formed, we decided to take a look at the mockups we had come up with individually and tried to take all the ideas we liked and tried to merge them into one system.  We had decided to start with my layout as a base design, which has since gone through some redesign.  For the most part I was to deal with most of the graphical aspects of our program, as my team would put as much content and functionality as they could on each page.

Design choices

Energy menu

As a group we had a general idea of what we wanted to include in the system.  I think the most challenging part of this assignment was how it should be displayed to the user.  For me, the design had to be both intuitive and innovative.  Throughout the past week I would always be pitching lines like "How cool would it be if we did... " or "I have an idea!  It's a little out there, but I think it's pretty good."  Many of these ideas didn't make it too far, but a few of them were accepted by my team.

As a computer science major, when you think of visualizing data you'll probably think of something like a bar chart or line graph.  While these types of visualization do a good job at presenting the user with information, they're not very enjoyable to look at.  For this project I have tried to come up with ways to present the user with data visualizations that they could provide the user with information they needed, be visually appealing, and if at all possible, be interactive with the user.  One of these ideas was the visualization I came up with for our energy menu which can be seen above.

Another important design aspect is to be consistent.  You don't want to have your users to be navigating to your system and then suddenly the entire layout changes and they don't know where to find anything anymore.  On all of the pages a constant menu bar is there to tie all the pages together.  The menu bar contains a widget and 4 main menu buttons.  On the left side of the page you have a submenu bar that corresponds to the current main menu that you are located in.

Project management
While working in a group, we used a combination of Subversion and Google Project Hosting which can find at: http://code.google.com/p/solar-decathlon-teamhawaii-2.  This setup worked out quite well as literally takes seconds to share your files with the entire team.


This project was an Issue Driven Design Project, which meant as issues came up, we would create a task in the Issues section of our Google Project, from there team members would try to handle the issues, whether it was to update files or create new pages.  Even though there are only three of us working on this project, having the issues down somewhere can be good because you can just check to see if there's anything that needs work on instead of having to remember it.

Thoughts so far
I think we worked very well as a group this past week.  There are a few more designs that I would like to come with in the next week.  I am also looking forward to programing these systems and have been trying to create designs that implement many of jQuery UI's.


********************************************************************************


Updates

As a group we put on the finishing touches to our mock up.  We ended up adding only a couple new pages: the Scheduler and Settings menus.

The design concept behind the scheduler was to allow the user to create a new event a simply as possible.  We want to incorporate the same 'drag' utility that has been provided throughout the entire program to allow the user to automate tasks with just a few simple clicks.

Scheduler

The scheduler also would have a chart that corresponds to the time period currently being viewed.  It will allow the user to predict how much energy is going to be used during that time period, and should have a general idea of the stress it would put on the system.  It could turn into a game of balancing tasks to make sure the house never takes on more than it can handle.  We'd like the graph's color represent the house's current load, green being a safe condition, and red being a high load.  By clicking on the graph we hope to allow the use to modify tasks near that time frame.

Settings Menu

In addition to the current functions available in the settings menu, I think there should be a 'snapshot' that can save the variables of the house's current state.  Then at any time the user could revert to the saved states with a single click.  This could apply to many different situations including things like a power save mode to a nice dining mode.  It would really be up to the users to set the house up exactly how they'd like it to be every time they use the snapshot feature, but the possibilities are endless.

User Stories

An important aspect of designing a system is to put yourself in the place of a user of the system.  What is important user may be different than what is important to a designer.  With that respect, you must always keep your users in mind because they are ultimately the ones who will be impacted the most by the design.

For the Solar Decathlon, it is important to always keep the goal of the competition in mind which is to design, build, and operate a solar powered house that is cost-effective, energy-efficent, and attractive.  Here are some problems I hope to address while developing some software for the competition.

Maintenance of the system

Since the house must be solar powered, it is important to maintain system and to make sure that you are getting the most out of each component.  As a user, you may not be thinking about what condition your battery is in as it wears over time.  This feature is already provided by laptops, which warn the user when power levels are low or to get their battery serviced.

While keeping a watch on your battery's condition it would also be a smart idea to keep track of the condition of the solar cells themselves.  You could measure the condition of the cells with the ratio Amount of Energy Trasfered / Amount of UV Radiation Exposed.  While this info may not be exciting to the user, it is a very simple measurement that can be taken to provide the user with the information needed to maintain their house properly.  While on the idea of panel condition, solar cells degrade at a slow rate (about 20% over 25 years), and it may not necessarily to monitor the output of each individual cell, but rather to see which cells are actually functioning.  Since the solar encasing for the house is designed to go around the house, as opposed to conventional solar panels that sit on top of the roof, they may be more prone to physical damage as opposed to wear over time.

The aquaponics system seems to be another integral part of teamhawai‘i's house.  I believe monitoring the water conditions would be a crucial aspect to the competition.  For aquaponics there are three major fields you want to monitor: water temperature, pH levels, and electrical conductivity.  By providing the user with this data, they can respond to problems with their system before problems scale out of control.

Apart from the solar energy and aquaponic system, the two water tanks play another important role in the house by both providing water and storage for grey-water, as well as providing some heating capabilities to the house with the latent energy that is absorbed and released by the heat-insulating material that is contained within the tanks.  So it goes without saying that monitoring temperature and water levels would be important to the user.  But what does it mean to provide these readings to the user?  The user shouldn't have to do any calculations of their own when they try to take a warm shower or want to cool down the internal temperature of the house.  So why not implement a system that uses these data values to help the user manage their energy consumption?  A graph projecting future power levels based on tasks that the house is providing wouldn't be too far of a stretch.

Attractiveness

After all the maintenance systems are established we can get into the fun things that would make any user want to buy the house.  One that I thought of applied to the aquaponics system.  Keeping a mini database of the current plants being grown, and of the fish that are in the tank would be a nice educational touch to the system as a whole.  Like a mini aquarium / plant nursery that could display info on the organisms that are part of the system.

We want a system that is easy to manage.  Computers that are incorporated (i.e. display panels) to the structure of the house would be a nice touch to provide user ease of use.  And like most technologies today, having mobile devices (i.e. smart phones) would have to be essential.  These technologies could allow the user to manage the house at a few simple clicks, whether at home or not.  For example setting the temperature of the house on your way home from work.

Finding a way to network your house in a way that services are aware of each other is another important feature I think that should be incorporated into a 'smart house'.  What I mean is, I would like the systems to communicate with each other.  The first thing I can think of is say you want to turn down the temperature of the house, but doing so would cause you to exceed the amount of energy that has been generated because of other tasks that are being preformed around the house.  It may be possible for the house to arrange task priorities, and to maybe turn down energy usage in some areas where it's not as important in order to delegate power for the new task.

I believe the air conditioning system should also be smart.  There should probably be some software that can keep the house at a certain set temperature in the most efficient way possible.  Taking readings from both internal and external ambient air temperatures as well as humidity levels would be essential.  Based on these readings the system could pump out air at certain times to keep the system cool without the user having to worry about it.

WebsiteUsabilityReview

Today, it seems like just about anyone can create create their own website in a few minutes with the help of a startup wizard.  Whether people know it or not, there are conventions and standards that they should followed when designing page layouts.

My Background: Ka Leo

Dummy layout for kaleo.org home page

I've recently became interested in web development this past summer after working as the design editor for over the past year at Ka Leo O Hawai‘i, the University of Hawai‘i at Mānoa's student-driven newspaper.  This semester I made finally the transition from print to web.  Though I have never really had a focus in web development, I thought it wouldn't be too far of a leap to go from print to web.  Though it is a slow process, we've drafted a new layout for the website that we hope to have up and running in the next couple weeks.

Challenges

While creating a website in itself is a task, creating a news site has more restrictions.  There's a lot of research that you need to put in before you make a site.  Before you even draft out a page, it is good to know who you're users are:

• What browsers are they viewing the page with?
• What is their screen resolution?
• What operating system are they using?
• What do they want to out of your site?

You can use an application like Google Analytics to do the information gathering on your current site so you can make adjustments to server your users in the future.

What's in a page?

There are many things to take into account when creating the layout for your website.  But the most important thing is to server your users.  People come to your site for a reason, and it is your job to make it an easy and enjoyable experience.

"Keep it simple, Stupid!"

A well-known saying in the programming community, but it has many more applications than that.  You want a site that is easy to navigate with high affordability.  If people come to your site and leave within a few minutes because they couldn't find what they were looking for, the only thing your site accomplished was to wasting their time.

The Information Age

Websites are not static documents.  They can be updated on an hourly basis to provide the most up-to-date content for their users.  This is what makes news sites extremely effective in comparison to their printed counterparts.  When people view your web site they want the most recent information.

"The Good, the Bad and the Ugly"

College Publisher

Good: College Publisher

College Publisher provides hosting for many college newspapers across the nation.  Their home page has a very simple layout with easy a simple tabs for navigating the site.  The "What Can You Do Here" towards the middle of the page provide simple icons to grab attention and useful links to help new users discover what services the site provides.

Good: jQuery

jQuery

jQuery, like College Publisher, also provides a top bar for navigating the site.  It uses whitespace effectively to provide a very simple layout to forward you to four project sites.  They've decided to stick with an analogous color scheme: yellow, green and blue, which is very easy on the eyes and entertaining.

Bad: Yes English School

Yes English School

I remember seeing this site a few months ago, and I must say they made some improvements.  I know they're going for a very artistic layout, but their site overall is not very helpful.  Their logo is not very easy to read with the rainbow bullseye behind the text.  The cursive font they use for each section is not very easy to read.  On top of that their site does not offer much insight to what the lessons are like.  They only provide their prices.

Ugly: Evolution and the Nature of Science Institutes

Evolution and the Nature of Science Institutes

At first I thought I was looking at a page from ten years ago, but I see that it was recently updated it 2 days ago.  Not to mention the site takes about 24 scrolls to hit the bottom of the page.  On average you should hit the bottom of a page in about two to three scrolls at most.  No one is ever going to read to the bottom of the page in one sitting.

RoboHosting

This week we delved into the world of content management systems (CMS) and Subversion.   Although I've never used one for developing my own programs, it wasn't very hard to learn being used to downloading patches.  It's a nice change to get a glimpse of the development side for once.

Task 1: Download and install an SVN client.
I decided to use SmartSVN, a GUI for Subversion.  The installation process was very simple, and I can easily checkout the source files I want access to.

SmartSVN graphical user interface.

Task 2: Checkout/modify/commit an existing system.
The project we had to modify was robocode-pmj-dacruzer, a sample bot created by our professor to help us learn everything from automated builders (Apache Ant), automated quality assurance tools (Checkstyles, PMD, FindBugs), code coverage tools (JaCoCo), to CMS this week.

I was able to successfully import the project via SmartSVN, modify the documentation, and commit the changes.  I made sure to build and verify to the project both before and after making any changes to any of the files to avoid confusion if an error occurred during the process.

My change was very minor which involved inserting a line of documentation to better explain the function of the findbugs.build.xml file:

"Build fails if findbug detects an error."

Task 3: Create a new system hosted at Google Projects.
The the final task was to upload the most recent version of our robocode robots onto Google Code.  Like most of Google's products, setting up a project home was very simple following the online instructions.  You can explore my project home: robocode-agh-cakebot for a project description, source download, developer and user guides, as well as view any changes that have been made to the code.

Project Home: http://code.google.com/p/robocode-ahg-cakebot/

RoboTesting

A few weeks ago our class was exposed to a neat software development tool called Apache Ant.  I haven't really used automated builders in the past, but I like it thus far.  Along with our automated building software we were introduced to a few automated quality assurance tools: Checkstyle, PMD, and FindBugs which take care of catching various formatting violations (including missing Javadocs) which allows me to focus more on the code's logistics.

Testing
This week we focused on creating JUnit tests, and it was up to us to create test a six test cases that would adequately ensure the quality of our robots.  Along with JUnit we used a Java code coverage tool called JaCoCo which will check to see what lines of code are executed every time you run a program.  This helped a lot when testing my robot's evade() method.

Test Cases

Quality Tests

TestCakeBotAim:  My bot tracks enemy movement with its gun, this is a simple test which checks that the gun adjusts its heading appropriately when the enemy or my bot moves.  This is a basic black box test to ensure that the number that comes out of the method is the expected value depending on the input.


TestCakeBotFiring:  I implemented a method so that my bot can adjust it's power based on the distance to the enemy.  This test ensures that my bot is firing weaker shots on opponents that are further away, and stronger shots when they are closer.


TestCakeBotWall: A simple test that makes sure that my both changes its heading upon hitting a wall of the robocode battlefield.  The bot may not hit every wall in the test, but it is alright because as long as it can be proven to work on one wall it should apply to all others.

TestCakeBotEvade:  Depending on where my bot gets hit by a bullet it will change its heading by 45° into the shot.  The bot slightly favors turning right (as it will go that direction when hit from straight on).  This test case checks that the bot is turning the correct direction when hit by a bullet.  JaCoCo was especially helpful with this test case as I figured out that my bot would always turn right due to a logic error in my conditional statements.

Acceptance Tests

CakeBotVersusSittingDuck:  A very simple test against a bot that does nothing.
CakeBotVersusCrazy:  Pits my bot against a bot that performs random actions.

In both of these tests JUnit will run the bots in Robocode and check if my bot will win 10/10 battles.  If my bot happens to lose 1 match the test will fail.

Thoughts
This was quite a learning experience, as well as the most extensive testing I've performed on a single program.  There were a few modifications I had to perform on my robot's code to make some of the actions testable!  For instance my evade() and smartShot() methods had to be redesigned to return double.
On the other hand, I had some trouble designing the test that checked to make sure that the robot would change its heading when it ran into a wall.  Fortunately I was able to modify some code by our professor which originally checked if a bot visited certain locations on the battlefield in a match to instead test the heading of the bot as it approaches the sides of the battlefield.
The acceptance tests were the easiest tests since there isn't really any specific code that you have to test.  All that matters is that your bot wins (which isn't too hard when your bots are SittingDuck and Crazy.)
Testing for specific onEvent calls were the hardest to test.  Technically you can't call any of your robot's methods outside of its run() method, so I had to manually create my own events and populate it with the appropriate parameters to test a few of the robot's methods.

Overall, it was a fun project that.  My future projects will be designed with testing in mind so that I won't end up modifying many of my methods.

Here is the latest distribution file of my bot: robocode-ahg-cakebot.zip (requires Apache Ant v. 1.8.1)

Competative Robocode

Overview:

This is the second AI programming assignment I've come across at school.  Generally I find these assignments to be both very frustrating and rewarding (depending on if it does what you want or not!)  Some of the things I wanted to implement didn't seem very difficult, but when you take the math that is involved, it can be hard to get the right results.

Design:

Movement:

The movement system I implemented this bot is very simple.  For the most part it will try to move in a straight line in intervals equal to half of the stage width/height.  When it hits a wall it will attempt to turn around 180° before moving again.  This can be bad sometimes if it manages to get itself stuck in a corner.

Targeting:

This bot has a fairly decent targeting system which I took from my Boom04 bot.  It will lock on the first target it scans.

Firing:

Firing on every scan can be in efficient, especially the shots are missing.  In order to make up for this there is a counter that will stop the bot from firing until it runs out of energy.  Bullet strength/speed is determined by distance to target.  The closer the target is, the stronger the bullet.

Win results against a few sample robots:
vs Sitting Duck: 100%

vs Corners: ~60%
vs Crazy: ~70%
vs Fire: ~ 50%
vs RamBot: ~60%
vs SpinBot: ~ 50%
vs Tracker: ~70%
vs Walls ~40%

Lessons Learned:
Designing a bot for the first time can be a little daunting.  I think for the first attempt you should try and keep it very simple, and build your way up from there.  I wish I knew more trigonometry so that I could express some features I would have liked my robot to have, (i.e. - predictive targeting).

Download: www2.hawaii.edu/~gaskell/ahg.CakeBot_1.0.jar

BattleBots

Open Source Project: TeXlipse

Simple user interface with syntax highlighting.

Overview:

Source: http://sourceforge.net/projects/texlipse

TeXlipse is a Java-based plugin that adds LaTex text editing support to the Eclipse Java IDE.  

Key features include:

• Syntax highlighting
• Command completion
• BibTex support
• Automatic building
• Spell checking

Prime Directive #1: The system successfully accomplishes a useful task?

As a first time LaTex user, it was nice using it in an IDE that I am already familiar with.  The most important feature to me was the Syntax highlighting  and automatic building.  The addon performs the these tasks wonderfully, but that was after going through the hassle of setting it up...

Prime Directive #2: An external user can successfully install and use the system.

Part 1 - Installation

Installing the plugin was fairly straightforward as it can all be done through Eclipse's interface.

Part 2 - Configuration

The guide was not as helpful as I would have liked it to have been, especially since it's written from a Windows perspective (interface is a little different).  Although after manually setting up your Builder and Viewer settings you have control over everything.  It's up to your discretion whether you want to view the PDF file in Preview or Acrobat Pro!

Prime Directive #3: An external developer can successfully understand and enhance the system.

The file from SourceForge will give you all the of the Java files a developer would need to start developing for TeXclipse.  All of the code is well documented, though the library is so expansive it would take a new developer some time to understand how everything works.

FizzBuzz

On the first day of class we were presented with a quick Java programing quiz called FizzBuzz.  A simple program which we were only given 5 minutes to complete on paper.

Unfortunately I came up a few lines short before I handed it in so I wrote it again later on that day taking about 6 minutes complete after starting up Eclipse:

/**

 * FizzBuzz program. 

 * Prints numbers 1 to 100.

 * If the number is divisable by 3 it prints out "Fizz".

 * If the number is divisable by 5 it prints out "Buzz".

 * If the number is divisable by 15 it prints out "FizzBuzz."

 * 

 * Time taken to write 4 minutes.

 * @author Tony Gaskell

 *

 */

public class FizzBuzz {

  public static void main(String[]args){

    for (int i = 1; i <=100; i++){

      if (i % 3 == 0){             // <-- If the number is divisible by 3...

        System.out.print("Fizz");

      }

      if (i % 5 == 0){             // <-- If the number is divisible by 5...

        System.out.print("Buzz");

      }

      else if (i % 3 != 0){        // <-- If the number not divisible by 3 or 5...

        System.out.print(i);

      }

      System.out.print("\n");      // <-- UGH

    }

  }

}

Nothing had really changed since the code I had written in class except for being able to get in the last else statement.

The program is a simple for loop that counts from 1 to 100.  If the counter i is ever divisible by 3 it will print Fizz to the screen, and Buzz if it is divisible by 5.  I decided to do as few checks as possible so that the program could run slightly faster.  By default if the number is divisible by both 3 and 5 it will print out FizzBuzz on one line since there's no new line characters being printed out at each check.  The final else statement catches everything that is not divisible by 15 and prints the appropriate number to the screen.  At the end of each iteration a new line character is printed.

I think the program turned out pretty well for the time that was put into it.  

I'm not too fond of the line: System.out.print("\n"); since it's not very elegant, but it gets the job done I suppose.

Luckily I have used Eclipse before in my second semester of Java programming, so I was already pretty familiar with the interface.

I was pretty surprised that I could recall my Java since I haven't touched the language in a little over eight months, but I guess the syntax is pretty much the same thing as C.