ICS 413 Soft Engineering final thoughts

ICS 413 seemed valuable because it may be the only class that teaches how to program in a professional setting. That's what I thought at first. What I think I'll value from this class most is the level of preparation I received in programming and project management. Over the course of this semester our class worked on continuous integration tools, open source software development, project health and even making a portfolio. These things are really crucial to preparing me and making me feel prepared for a professional career in programming.
I'll start off by saying that the lecture videos aspect of this class was helpful in constantly reminding me how things should be. As helpful as a lecturer may be, I don't think people are comfortable making professors repeat a certain topic over and over again.
Software Integration is a topic I was not familiar with at the beginning of this class, but now I can understand it and appreciate the role it plays in making a project that has good flow. It can help programmers make progress, and what's more important is that it makes things a lot faster and easier.
Open source software was something I had a idea about, but now I got the history of it as well. It's given me perspective about the technology world and society as it is today. This idea of sharing software and making contributions to a project is very comforting. If the world is truly connected, then anybody can contribute. I am very excited about the idea of many people sharing and contributing to the body of work in any project. I'd like to think it is perpetuating progress. History has shown that communication and the distance between people has been a big road block to the sharing of ideas and advancements in technology.
This semseter we also used something called software ICU. I wasn't not familiar with it at all and didn't know you could do something like that. We setup sensors in the programs we used like eclipse and ant. Then when we used those programs it showed how well we used them and how often. It is a reflective way of looking at our progress in a project and whether the habits are healthy. If progress is steady and updates are added incrementally then it's healthy. However, it can also show that you spent the whole night before the due date working on the project in order to get it done. I think it is very practical to use this to kind of keep yourself honest.

Lastly I was able to develop my online persona using this blog and through working on the projects. It's a big plus! I was really scared that once I graduated I wouldn't have anything to show propective employers. I'm always getting emails from my counselor with employers asking for people in the field that have a year or two of
programming experience. How can I have experience if nobody hires me?

Overall, this class has been a positive influence on me because of how many I learned. Of course I had to work my butt off to get a good grade. I think it's made me a better programmer.

GreenDepot Project

I've been working on the GreenDepot and version 2.0 is out. Although it has some flaws in it, it has come a long way from version 1.0. Take a look at this url http://code.google.com/p/greendepot/. I think there are improvements to be made and new features that could help users. I've already implemented some styling changes to the pages. I think it looks a lot better, but I definitely need some input from other people. Please leave feedback.

The GreenDepot project

The deadline for this project was always at the back of my mind during the time our group worked on it. I have to say that I honestly had a tremendously fun time working on GreenDepot version 2.0. Unlike working on version 1.0, there was no overhead in creating the structure of our web application. Once the initial functions set up, we started throwing ideas around and figuring out how improve our application. Granted, the project was probably the worst application in our class at the version 1.0 phase. I feel that we made great progress and feel really proud of our work.

It started on the second week of November. Our groups were chosen and I was partnered up with Nate and Edwin. We had some trouble getting together to meet because of our varying schedule. Night was the only time we could meet and talk, so we talked over google chat. And for a time that sufficed, but now that I look back I think the few times we met up outside of class were really valuable. Those times allowed us to talk and make sure we were on the same page with each other.

GreenDepot is a web application that uses wicket as the basis. Wicket allows programmers to just use html a markup language and java. The application is geared toward displaying data in a meaningful manner, using WattDepot as the source for all the data. WattDepot is a open source software project that allows developers to get simulated data from the Oahu power grid. This software was the foundation for GreenDepot. Without it, we wouldn't have anything to work with. Using this data we displayed it in two ways.

First there is the StopLight page. This page shows you a meter with green, yellow and red, and acts as a sort of stoplight. It will generate data using WattDepot and based on our thresholds for what is a low carbon emission time and what is high, we indicate green for a good time and red for a bad time for using eletricity. We also provide suggested hours on the side which indicate data from yesterday which hours were best.

Secondly there is the GridInfo page. It serves as a chart that will display the 24 hours data from the date you chose as input. Right now, we have a start date input and an end date input. This way you can set the time as long as you like to get an idea of the carbon emission, whether it be for a day or ten days. This was implemented in a much easier way using google charts. I've really come to love all the software tools google offers. I never knew that google had invested so much into developing so much software for users everywhere. There is a lot to look at when you click that "more" tab in their front page.

More recently, I've added a contact page for information pertaining to our project and also changed the layout of the page. It has a smoother look and I think it doesn't look as junkie as it used to. Before the page had too much stuff that distracted the user. Now it can focus the user to the results of the page and what we have to say.

This project had some bumps, but I've tried to work on it daily and the software ICU has shown that the development side has been healthy.


This project was really hard. Wicket was hard to learn and I struggled at first. But I learned a lot. What amazed me was the amount of time I spent on this. I was really excited for this project. It really drew my attention and I think it shows that I could do this as a profession. Writing software and creating applications has a great appeal for me and I would love to continue doing it.

A peek at other peoples code.

I was able to review another group's project code and see what they had done. It was very interesting to actually examine all they had accomplished. It made me even more determined to improve my group's work and get coding!

There are a lot of different details to consider when reviewing a project. My professor very eloquently wrote the list for it in his website. These are the main points.

• The build
  
• System Usage
  
• Javadocs
  
• Naming conventions
  
• Testing
  
• Package design
  
• Class design
  
• Method design
  
• Overall feel and look of implementation
  
• Documentation
  
• Software ICU data
  
• Issues management
  
• Continuous integration
  

Take a look at the review I wrote based on these criteria. Link.

I felt that Ecologineers' web application was at the brink of success. This group has done good. They managed to produce a web application that worked. Although they need to polish their implementation and their user interface, they're on their way to creating a solid application.

GreenDepot 1.0 , but not quite

It's my very own web application. This week through the work of a group of me, Edwin Lim and Nathaniel Ashe, we were able to create a humble web application that dealt with carbon density during a 24 hour interval. It's a culmination of all that we've learned in ICS 413. We're using everything from continuous integration tools like Hudson to open source sottware like WattDepot. These types of software have been discussed on my blog before, but now they're all part of the project my teammates and I are working on. Take a look here.

GreenDepot is a software source software as well. It's primary use is to gauge at what time of day is the most efficient for power consumption. As of this moment, I'm sorry to report that our project is unsuccessful in meeting the criteria set a week ago. Our professor wanted certain things done by now and they are not. What we have is a Wicket web application that takes a date and stores it in a variable. We've even managed to calculate the all the carbon density data for all the hours of a day, but haven't been able to output to an appropriate medium.

Now what's Wicket you may ask? It's a web application design tool. It certainly has many functionalities. It quite a long time just to understand how Wicket worked. This tool is one that works toward creating an application without using too many different types of languages. All you need is html and java. With a combination of markup language and high level programming language, the results seem pretty good. Things are kept simple by limiting programming to only two languages. It allows people to quickly go through it and understand it. However, I bring up again my results. It was not easy learning this new construct.

Another factor that led our team to meet only a few of the goals was that again, our communication failed. I mentioned in my last blog that communication between Edwin and I was difficult at the start. It didn't get better this week either. We weren't able to effectively decide what to do and so time was wasted. Nate our new teammate was well new, and it took some time for us to set up ways to communicate. Ultimately it kept us from deciding on what to do and how to do it.



As you can see from the HackyStat evaluation, our performance was not great. We were behind from the start and so had to rush at the end to make some progress. If we are to continue in this project and be successful I think we need to communicate more and be able to work together more frequently. It's only when we are working as a group that things are getting done. One team member might get stuck on something and the other helps out. Most of our problems have been solved that way.

WattDepotCli Version 2.0

My partner and I have updated our WattDepot Client project. This improved command line based program can now take 3 more commands and provide you with a good idea of what is happening in the grid of Oahu's power plants.

In terms of functionality I feel that our client program does everything it's supposed to. Yet, it's not the shiniest of code. There's a lot of polish that needs to be applied still. More tests and error checks can still be applied to the program in order to cover some vulnerabilities. That's probably one of our weaknesses. WattDepot-Cli-Umikumalua still needs more polishing. What we were able to do was to create more exceptions to handle things like null pointer errors and making sure that a source/power plant existed before we threw that name into a function. These tests and error handlers have made things look better, but it hasn't made me feel safer about it.

I've worked really hard on upgrading the way the command line interface works. Before, the interface was really just one big class that was extended. But now, I understand how to make a interface and how to use different classes that are highly flexible and scalable. If I wanted to add more functionality to just one command, there would be room to expand and it would not cause all kinds of havoc.

A new tool I was introduced to was HackyStat. It's a type of monitor that tracks your actions when your developing software. So it can show you how often you've updated your project and code, or how much time you've put into a certain task. It's definitely worth looking into. I say this not because my grade in class depends on it, but because when it comes to productivity you should want to have some insight into what you are doing and what you think you should be doing. It's another way of reflecting on your capabilities and habits. Even if it's that helpful or improving your skills, it can still serve as proof that you did something.

Although it may seem to be a complicated and unimportant system, I have used this client software to derive some useful facts and insights into how my island home of Oahu operates.

Using this Client I built, I conducted a test for the month of November to determine which day had the maximum and minimum power generated and which day had the maximum and minimum carbon emitted. These tests looked at a particular plant or a network of plants and calculated the amount of carbon or power that was emitted for a particular day based on an interval of checking. What I found out was quite interesting. Our habits shine through even in the data. Based on the outputted data (which you can access here), the SIM_OAHU_GRID was at the peak during weekdays. A peak day like November 16th and 17th saw 995 MegaWatts of power being generated within the Oahu grid. On the other hand during the weekend, energy emissions were down to to 665 MegaWatts of power being generated which is about two thirds of the usual power consumption. The results for carbon emissions were in the same pattern as for power generation, as expected. Since there was more power being generated the carbon emissions rose as well. Emissions ranged from a weekend low of 22.8 million lbs to the weekday 29.9 million lbs of carbon. I would like to think that Oahu is a very industrious city and most of our power consumption is used during weekdays because of businesses.

Feel free to take a look at my distribution package and the WattDepot-Cli project page. here

My Experience with Software Review

I was tasked with reviewing a project of some fellow peers and also to provide insightful feedback to help them better their results. While I did this, a few revelations came to me through their own feedback of my project. The comments have made me aware something.

A major point stressed in the beginning of the semester by my professor in ICS 413 was that when you are creating Open Source Software there are "three prime directives." One of these directives was being able to create software that users could work with effectively and understanding it. I feel that, I have been weak especially in that department. A common comment I got was "it needed more error checks." It reflects bad on my understanding of interfaces because one of the most common habits people have is to use something without reading the manual. I need to make it so that human error is not a major factor in the program. I know I cannot totally provide a solution to the things that can happen, but testing and error checks can help.

I also learned about development through this review process. It was quite surprising and amusing. I learned that I had some strengths and also weaknesses in programming and so did my peers. I never thought to do validations for certain inputs like the html address, but the others did. One of my strengths was that I had a strict coding standard in terms of grammar and getting the details right. When I used the command line built by the other students, it was bad. Their system was not as clean as mine, but they had better program testing. Whereas I had done more happy tests to make the program work better on the command line, they had done testing to provide coverage on the unit and behavioral level. I was kind of narrow minded that way. What I was focusing on was the way the program ran and how the user felt. That's why I was really annoyed when the other programs did not work as expected. For example, they had a help command that printed the syntax of the commands to be inputted. But it didn't work. I had to tediously check the source code to figure out exactly how to input the values and get the right results. On the other hand, I had worked very hard on this portion of my program.

This review has led me to look at programming in a changed manner. Although students are taught not to work together in the first years of computer science, it's become essential in software development because of the different techniques and approaches other programmers have for a specific task. It's made me want to continuously seek input from my peers in order to get a well-rounded outlook on what needs to done to write good programs.

A review of my peers program

Now that my partner and I have built a client, it's also important to review the source code of our peers. Our assignment was to review how well it meets development standards. Their WattDepot client should be similar to our own client. Last week we were tasked with implementing a command line program that worked to provide information using the WattDepot project servers. This simulation of Oahu's power grid was meant to challenge our skills and teach us new practices. Now we're at the review stage, the new objective is to reflect on our project as well as look at our peers product and determine the quality of it.

The standards I try to compare against is laid out on my professors page for ICS 413. Link
These are the two projects I reviewed. The link to the review is below.
WattDepot-Cli-Elua
WattDepot-Cli-Eha

I found that the client for Elua worked for the most part, but wasn't very refined. There are still a few things to be worked out in order for the user to easily use the commands.

Eha on the other hand is not a optimal build. In my opinion, the source code could be drastically rewritten in order to give the program room to expand. At this point it looks like spaghetti code.

WattDepot Client

I recently worked with a partner on a project called WattDepot-cli. Our objective was to creative a command line client that could process certain instructions and gather information based on the simulated data from WattDepot. I learned a lot from this project in terms of working with another person and how a long term project functions.

The first thing we did was look at continuous integration software. Hudson was created to help users steadily update their projects in order for the project to grow and be configured in an efficient manner. I have detailed the use of it in my previous blog. It's worth a look for those who appreciate speedy updates. Link

A second threshold to cross was learning the basics for WattDepot. It's a sort of stepping stone toward creating a smart grid for electric companies. WattDepot functions as monitoring software that gathers information on how much a certain power plant generates in a certain period of time.

The initial learning curve was pretty steep. What was difficult to understand was the way WattDepot worked. What helped was using the wiki on the project site. It was very informative on how to do what I need to do. Link
For example, one of the commands had to calculate the total emissions of carbon emitted per day. I had closely look at the all the methods in the WattDepot Client to really understand what I had to do. My partner Edwin was responsible for the list sources, list source summary, list sensor data {day}, and list sensor data {timestamp} commands. I was responsible for the remaining ones power generated {day}, power generated {timestamp}, chart {source}, and list total. Yeah, that list is really ugly so please check out the wiki site because it is very helpful.

I have to say that Hudson wasn't very help in the very beginning. It actually slowed us down at the start. We hadn't divided up the work yet and my partner and I were both waiting for each other to update. This miss-communication wasted a lot of time. But once we got going in a good rhythm the updates to Hudson was very useful because we had certain parts to work on and they didn't interfere with each other so there was no integration problems. We used subversion strictly to update our own commands to put the whole command line program together.

Because we wasted a lot of the time, our program is not of the highest quality. We also suffered from a lack of communication. Like I have said, the first few days were into the project was pretty quiet. Not to mention we made one of the greatest errors, not exchanging cell phone numbers. In the modern age it doesn't matter what type of bandwidth you have, cellphones still beats email.

Hudson: a Continuous Integration System

Software Engineering, a term that brings to mind many words. Easy is not one of those words. That's because programming is a tedious process that requires many steps, from testing to debugging. That's why there are many tools out there that are created to help the process along and keep programmers a bit more happy.

I was just introduced to a tool that tries to do one thing very well, Continuous Integration. Hudson is online software that updates software for a project site and maintains the integration process so that users are taken out of some of the frustrating parts. I certainly don't want to keep making distribution files and uploading them.

What makes this an improvement from subversion you may ask? Well, subversion is still part of the system. A user can still use subversion as the updater, but Hudson takes a step further and checks for errors as well as maintaining different projects. Hudson is a system that does not require installation. It's cloud computing or something similar to it. This makes the system very easy to use.

I made one commit to the package and Hudson was able to determine if my package was working or not. When an error was detected, I fixed it and was able change my configuration in a few seconds and the project was updated as well in even fewer seconds.

Hudson is another tools that can help developers work faster and with less human error. It does this because I believe packaging software, updating it and integrating it with other software are all trivial tasks. "Work smarter not harder"

Hudson Wiki Site

Some fundamental Questions

Here are some questions I think software engineers should know. These are also important because they are part of the topics I've been studying this semester in class.

1. What are some things you can do to prepare for a question about problem in the forums?
Answer:
Research and understanding the problem beforehand can better clarify your problem to responders to your post.

2. Why must your first statement in a method or class documentation comment be written in a complete sentence?
Answer:
Documentation about your program is derived from the first sentence of your documentation comments. If it is not in a complete sentence, it may be ignored.

3. What is one of the things an Ant build.xml file must do first to ensure software congruity?
Answer:
The version of the users current package software must be check so that problems may not arise later on. It stops the process there, to alert the user to update first.

4. What character must never be written into programs?
Answer:
The hard tab is a bad character to use. Using it is a bad practice.

5. What is wrong with this statement and why?
try {
FileOutputStream outputFile=new FileOutputStream("good.txt");
OutputStreamWriter outStream= new OutputStreamWriter(outputFile);
for (int i = 0; i < accounts.size(); i++)
{
Object outputAcct = accounts.get(i);
String toWrite = ((Account)outputAcct).fieldData();
outStream.write(toWrite + "\n");
}
outStream.close();
} catch (IOException e) {
}
Answer:
-no indentation
-the catch statement implements no action should the exception be called

6. Why are the anti-pattern happy tests inadequate?
Answer:
Testing for a "happy test" does not check for errors in your methodology. This type of test, does not
account for errors that may result from bad programming.

7. If a problem comes up during the commit process in subversion
what will happen to the changes already made and why?
Answer:
There will be no commit. Any error in any of the transactions will result in a fail for all transactions.

8. The following can cause problems if it is not instantiated.
Which of these programs will find an error with this statement below during an Ant
verify run and why only this program?
PMD/FindBug/CHeckStyle
String foo;
Answer:
FindBug looks for errors such as this in the bytecode of your program.

9. Open Source Software is a recent term. when was it first used?
What group coined it?
Answer:
In 1998 the Open Source initiative created it to differentiate it from the more ambiguous term "free."

10. Give a couple of disadvantages to Open Source Software.
Answer:
-Testing is not as rigorous, and only at the pleasure of the developer; for those that are not working for monetary gain.
-The quality may suffer from bad documentation and hard to understand source code.

Project hosting = effective communication

The internet sure has many uses. But Google groups is not a utility many people know about. I started a project this week to better organize my work with Bato 1.1. If you've been following my blog so far (and you should), you'd know that Robocode is open source software that was created to help programmers get better at coding in java. I've also used different software for packaging my code so that it can be better distributed and for others to modify and improve it if they so wish. Ant the packaging was able to package and debug my code in a very short time. This week the focus was on software updates and project hosting.

Subversion is a system that allows users to update their project without too much hassle. This program updates as you change the code. If you change just one line, it's no big deal. Just commit that one file and Subversion can update it. There's no need to upload the entire file again. It was easy, but it takes time to get used to. I used a client called TortoiseSVN. It does not have a GUI. Instead you create a repository in which you upload or download files. This allows anything within the repository to be uploaded and changed in a short time.

At the other end of the upload is the project site, which I created on Google groups. It's a site that I haven't known about until this course in ICS 413. It's a very valuable development. Because it's free! Through Google groups I was able to create a site in which to explain the development for Bato. The initial setup was really easy. I added members and a discussion group to talk about the topic at hand. It was also easy to create pages for visitors to look at and learn about my project.

A problem I encountered was with the email. I was not able to enable an email send-out to the discussion group in the event that I was to change my package and let members know about the change. These are the links to my project and discussion.
(http://code.google.com/p/robocode-wcm-bato/)
(http://groups.google.com/group/robocode-wcm-bato-discuss)

SVN and Google groups allows users to effectively and cheaply host a project. They are tools that can be very beneficial in maintaining communication between different developers and the public. One thing I know about open source software is this, you have to effectively document you code, as well as provide a package for users to easily download. These two mediums allow for that and makes life so much simpler.

JUnit testing

The experts say that writing tests for your program will probably take more time than writing code for the program itself. I now know that, the experts are right.

This week I started writing JUnit tests to check certain aspects of my Robocode robot. What seemed like a simple task turned out to be a major challenge. Up till now, I've little experience using JUnit. It's almost like learning a new programming language. There are syntax to learn and different ways of doing things. What made it even more challenging was that my robot was limited in ways that made my imagination grasp at straws when the time came for writing the tests. My robot was very simple and that made testing very difficult. What could you test for if there were no calculations to verify?

I found that writing good tests required a look at three different types of testing. They were acceptance testing, behavioral testing, and unit testing. These three types are essential for testing different aspects of a program. For instance, acceptance testing is a process that requires you to check that the main objective of a program is fulfilled. The behavioral testing requires that an intended action of the program be executed and work reliably. And the unit tests are to check if a certain block of code (like calculating the hypothenuse) correctly outputs the right values.

This was my mindset when I started writing tests for my Bato.1.1. Here are some of the tests I wrote and an explanation. The package with these tests and my robot source code can be downloaded here.


TestBato1

This is an acceptance test to check whether Bato can defeat the robot Crazy ten times in a row.

TestBato2

This is another acceptance test that checked if Bato can defeat the robot SpinBot at least half the time.

TestBato3

This is a behavioral test that checks if Bato is too close to the enemy. It determines through ten rounds if Bato is ever at least 20 pixels away from the enemy robot.


TestBato4

This is another behavioral test that checks if Bato is stuck in a corner. Based on my fighting strategy, I have observed that this could be a problem. So this is a useful test.

With my robot being so simple and lacking in calculations I could not come up with anymore test cases to writeup. The final step was to verify my tests and see if I covered all the possible cases. It was up to the program Emma to tell me if I could do any more. Here are the results.
Emma Coverage summary
class: 75% (6/8)
method: 80% (35/44)
block: 65% (440/682)
line: 64% (112.8/176)

Would any developers out there like to comment on these percentages and how I did?

Using Software Tools. Less Grunt Work.

This week I had my first experience with Ant a software tool developed by Apache to help with the software build process. It has sub-processes that checks for syntax errors, errors in run time, and also makes sure your source code is up to Java coding standards. The initial learning curve is not that steep. I think with a little determination, most programmers can be comfortable with this tool in a short time. This tool was used for my robocode robot and it helped to check my source code. There are quite a few things that Ant does with just a simple command typed into the command line. I will detail the requirements for installation and also how to use Ant.

Ant is a open source software available at (http://ant.apache.org/). I found it somewhat difficult to set up on my computer particularly because there are not a lot guides that give you a step by step explanation of the process. Most of the sites I visited showed guides that were inadequate. Here is my take on how to set it up on a windows vista HP Laptop.

1. Download Ant and unzip. Move it to the C:/ directory. Or try to move the Ant file to a directory that has no spaces in the name. It can be problematic later on.

2. Now click start, right-click computer, and click properties. If you are running on a Vista OS, then you should see a window opened. Click on "advanced system settings" under Task on the left side.

3. Click on Environmental Settings. This is where you will enter two variables.

4. The first variable will be called JAVA_HOME. Under the variable value, enter the system path that leads to your latest sdk version of Java. For example, this my path. C:\Program Files\Java\jdk1.6.0_16.

5. The second variable will be called ANT_HOME. The variable value of this variable will contain the path to the same directory as the above variable. So just enter the same thing.

6. Now open dos. Go to the directory which contains your build.xml and type ant.

Those are the basic steps to setting up Ant and checking if it works. There are many utilities within Ant that are quite helpful.

• ant
• ant -f checkstyle.build.xml
• ant -f junit.build.xml
• ant -f findbugs.build.xml
• ant -f pmd.build.xml
• ant -f jar.build.xml
• ant -f verify.build.xml
• ant -f dist.build.xml

Each one has their use. Checkstyle and findbug for example check for irregularities in your code and byte code. While jar and dist on the other hand are used to package your source code. And verify is the special command that does it all. It pretty much does everything on the list.

On this occasion Ant was used to improve my source code for Bato, a robocode robot created about two weeks ago. I made some improvements on the movement of Bato and after compiling it, I used the commands checkstyle, pmd and findbugs. I was surprised that there were many errors. I mean it compiled didn't it? What could be wrong?

It turns out that there were some small coding standard violations, like leaving no white space between a while declaration and the "{" bracket. Another problem was declaring a variable and not using it. Findbugs made sure I changed it before letting me get a "Build successful."

Finally after going through that, I used the verify command to make sure I was able to get a successful build as well. Verify is the command in which you can use to check if everything has been done.

In terms of quality assurance, I found the program to be quite helpful. I didn't even know about some of the errors that checkstyle and findbugs found. It drastically shortened my work time. The one complaint I have about some these programs were how they alerted you to an error. The messages were kind of ambiguous and not very helpful. It took me awhile to figure out what was wrong with my code.

JUnit is plugin that tests your program in order to make sure that your program works in all cases. This was the most difficult of the programs to learn. I found that JUnit can be helpful and downright essential if you want to know what works and what doesn't.

This is a good tool to have for programmers. It makes things so much easier during the entire coding process and generally makes a better experience for users.

Check out my robot source code here along with the build files.

Update
I've revised my package

(robocode-wcm-Bato-1.1.1003)

Building your own robot.

Robocode is a open source software available on sourceforget.net. This is my attempt creating a robot implementation using their package. I'm at a point now where I have a basic understanding of the structure and techniques for controlling a robot. My past blogs have detailed my studies into other sample robots provided by the Robocode program. Now I'll give a brief overview of how my robot works in the same format. I have christened my robot Bato.

Movement:
The robot moves in a circle in order to dodge bullets fired at it. During every iteration, it moves 36 degrees to the left and ahead 20 pixels. I chose 36 pixels because I did not want the robot to move in a perpendicular way. If it moved at 36 degrees or some degree which did not add up to 360 every time, there would be a certain randomness to it. It has proven effective against robots like Corners, Fire, RamFire, Crazy and of course SittingDuck. I did have difficulty with Wall, SpinBot, and Tracker however.

Targeting:
The targeting for Bato lies in using something similar to Tracker. Bato keeps its sights on one target and attempts to maintain the focus in order to fire continuously at this target. While this was effective against the aforementioned robots, Wall, SpinBot and Tracker were not so easy to beat. With Corners, Fire, RamFire, Crazy and SittingDuck, I had a nearly 100% winning streak. But with the other three robots, the statistics were lower. It appears that Bato's movements are so similar to SpinBot that it does not have an advantage with it. It was the same with Tracker, the targeting strategy of Bato was so similar to Tracker that the results were almost always 50:50. And the Wall robot remains dominant.

Fire:
My strategy for this was simple. I had observed that most of these robots only fired at certain times. Therefore, I chose to fire as frequently and use the most power fire I could. The only drawback was that Bato is frequently disabled if it cannot hit the target if it is moving too fast.

I've learned a little bit about project development through this robot building process. When the time came for coding, it was pretty simple. The problem was to find an idea that worked. This is a classic problem for developers. When I had this problem, I knew I was on a good path because I did not have many problems with syntax or knowing how to do something. That part of development should have been handled by now, and sure enough I had more problems with working at the performance side of the program.

When I look at my robot now, I definitely see flaws in it's strategy. I think if I had a lot more to development this robot I would add in a lot more small details to tweak it and give it more functionality. The project was very helpful in learning how to develop a competitive piece of code.
Here is the robot package. It is entitled "Competitive robot: Bato 1.0."
(http://www2.hawaii.edu/~wingma/)

Robot Strategies

Now that I've learned the basics to Robocode, there are also strategies to consider. What are some strategies out there that work and that can provide me with some insight to how a robot is successful in the battle field? I was assigned to look at the sample code provided in the Robocode directory. Here's what I found:

• Walls

Movement- The main strategy of this robot is to find the closest wall, and run around in straight lines.
It's one of the simplest and most effective strategies. Because when it goes to the side of the wall it covers a big area in which the robot can now no longer be hit.
The robot can only be hit at other are from 180 degrees. This is a dominant robot amongst the sample robots.
Targeting-Uses a boolean variable to scan when the robot is moving, but not when it's turning.
Firing-It shoots at anything it sees.

• RamFire

Movement-This robot always moves toward the target. It wants to collide with robots to deal damage for a ram bonus.
Targeting-The first robot it sees.
Firing-It fires at any robot, but it does not shoot to kill. It wants to ram robots to death.

• SpinBot

Movement-It turns right as much as it can during one turn.
Targeting-No targeting.
Firing-Fire if it sees another robot.

• Crazy

Movement-It moves in an unpredictable fashion so a robot that uses a repetitive algorithm will not hit it twice at the same spot. It will also move crazy even when backing up.
Targeting-No targeting.
Firing-Fires on sight of any robot. It's the same fire power every time.

• Fire

Movement-This robot moves a little and most of the strategy is in running away when it's been hit.
Targeting-It has really bad tracking. It's very ineffective since it doesn't keep it's gun trained on the target.
Firing-Fire power is determined by whether the target is 50 pixels away or within 50 pixels.

• Sitting Duck

Movement-None. This robot is basically a target for all the robots.
Targeting-None
Firing-None

• Corners

Movement-It goes to the corner. It also keeps battle data to determine whether to switch corners next round, if 75% of other robots are still alive at the time of it's death.
Targeting-Once it's at a corner, the robot turns it's gun around to search for targets.
Firing-Fire power is determined by the enemies distance away from it. The closer the target is, the stronger the bullet.

• Tracker

Movement-It follows one target constantly. If it hasn't been seen for 11 turns, then it finds a new target.
Targeting-The gun is trained on the one target.
Firing-Constantly fires on the one target, since it's mostly in tracker's sights.

I learned that simplicity and a good idea can go a long way. The Wall robot for example was very successful in both avoiding bullets and dealing out damage to other robots. The Tracker on the other hand worked in a completely different way. It's main goal was to damage and destroy as many robots as possible. In that aspect it was successful, but in surviving it was not. When it stopped to shoot at its target, enemies had time to shoot back. Another aspect of the Wall robot strategy that was extremely effective was in using the wall as a shield. When you hug the wall the enemy knows where you are, but it cannot come from behind you.

Robocode has some realities to consider. Cover, speed, and nonstop movement is key. When other robots have a hard time hitting you, and you are hitting successfully the damage ratio amongst robots will be in your favor. Nonstop movement is important because I've only observed robots that shoot after they have found a target. If you were to constantly move, the chances are also in your favor.

All these elements are not unlike guerrilla warfare. You perform hit and run tactics, and take advantage your enemies weaknesses and avoid your own. This is my favorite part of the process of doing something competitive. I get to find the best ways to do something and look at my own capabilities.

Adhering to coding standards. It's not that bad.

It's easy to talk about writing in the correct style and following the standards for coding. But when it's time to actually edit your code and make sure it's correct, there is a lot of work involved. I was assigned to correct my source code from my robocode project and it allowed me to look at the codes of my peers. That was good because I found that there were other implementations out there I hadn't thought of or failed to implement.

One of my weaknesses as a programmer is in mathematics. When I looked at another classmates code today, I realized how easy an implement the program was when he just wrote a formula to compute a value. What I did in my implementation was a big bunk of a mess. Trigonometry was a big help to that classmate. When I had tried that kind of implementation in my own program it was very hard. This is one aspect of programming I need to work on.

However, I also realized that I also have some strengths. I have a very strict way of coding and I always look for exceptions and problems to the program. For example, I included a HitRobotEvent method that specified what to do in case there was a robot collision. I included them in all my simple robots that needed it. Some of my classmates didn't do that, so I think I have a different perspective for how a program should work. I kind of think in terms of a overall program and it really bothered me that a collision could happen, so I look for all the cases in which thing could happen. The assignment didn't specify what to do in that kind of situation, but I think it's a good mindset to have. In professional coding, you need to have test cases in mind in order to prevent any type of bugs.

When I read "The Elements of Java Style" it showed me that I had been doing at least some things right. I already include white space and good variable names in my code to improve understanding. These things just made sense. They were guidelines set not because someone said so. They were things worth doing and benefited all programmers. Although I have to admit it is very tedious at times. For example, hard tabs are used by most beginning programmers. But it's prohibited by Coding guidlines. It's a bad habit that creeps in because ICS101 doesn't really warn you about this, but it would be a good idea to inform beginners about that sort of thing. Most of what I know about programming standards and are congruent with Java standards I learned back in ICS101.

Overall, these guidelines aren't difficult to follow. It's like writing a sentence in a paper. If you want to sound professional, you better improve your grammar.
Here is a link to my page for the revised robocode source code.

(http://www2.hawaii.edu/~wingma/)

These are coding standards set by my professor.

• ICS Coding Standards
• ICS Robocode Standards

Robocode. Let the battle begin!

When was the last time you had some fun programming? Robocode is an open source software program that provides some fun and experience with writing code in java. You download a program that builds an environment in which you write code to create a robot that will follow your instructions ultimately to smash the other robots. This was an IBM program that was meant as an exercise in programming. But now 8 years after the release, the software is still strong. It's being maintained by volunteers and could very well go for another 8 years in my opinion. Why? Well I've had a taste of the software and how it works. After going through a short installation process, you'll be absorbed in programming your own robot for hours. It might be a guy's thing with building the most violent robot or just being competitive. You should also take a look at this wiki page volunteers have made for this program. They are a VERY dedicated bunch. (http://robowiki.net/wiki/Main_Page) Well, without sounding like I'm their advertising representative, let the battle begin!

This post will have a few stages to it. First I'll give a quick note about installation and go on to the things I've learned.

Installation:

Go to the link provided above to robowiki.net. It has a very thorough guide to installing robocode and programming it in the Eclipse IDE. Inside the basic tutorial page there will be five links for:

• Using Eclipse as IDE
• Add robot project from an IDE into Robocode
• Creating a robot in Eclipse
• Running your robot from Eclipse
• Debugging your robot with Eclipse

These are the five essential guides that will set you on the course to becoming a Robocoder. Follow through the instructions and you should be fine. They even got pictures and everything.

Basics functions:

I had twelve small programs to build. They were meant to challenge my knowledge and force me to learn the rudimentary skills of Robocode and coding in general. I won't bore you with a long explanation of what to do. Read it and I give a brief about it afterwards. My source code provided will give you an explanation of how I implemented.

1. Movement01. Compile the Robocode and check if you are able to run it.

2. Movement02. Move 50 pixels each turn and be able to turn around when the robot hits a wall.

3. Movement03. Move n pixels per turn and increment n by 10 each turn. n+=10.

4. Movement04. Move the robot to the center of the battle field.

5. Movement05. Move the robot in order from upper left corner, to lower right corner, to upper right corner and then to the lower left corner. You must move diagonally when you can.

6. Movement06. Move the robot to the center and then in a complete circle with the robot ending up in the same position from where it started from, the center.

7. Tracking01. Follow exactly one robot around.

8. Tracking02. Follow the robot and keep at least 20 pixels between it and your robot.

9. Tracking03. Each turn, determine the closest enemy around your robot and move 100 pixels away from it.

10. Firing01. Spin constantly and fire bullets at any of the targets when your robot detects them. The robot cannot move.

11. Firing02. Only target one enemy while spinning and fire on this target alone. The robot cannot move.

12. Firing03. Fire at any targets, but the fire power must be proportional to the distance from your robot. The farther away, the weaker the fire power. The robot cannot move.

13. Firing04. Track a target with your robots gun, always pointing at it. Although you don't actually fire.

I had a lot of problems with some of these programs. For example, movement05 required the robot to move diagonally rather than from wall to wall. Therefore, I had to find the angle to turn the robot and the length to move it. First I found the length using the pythagorean theorem, but finding the angle proved more difficult. In the end I found a compromise. I moved the robot to a certain point that was always 200 pixels away from the walls. That way I knew that the angle was always 45 degrees and the hypotenuse would be 282.

Fear not programmers, it may sound bleak but there are a lot of materials and samples you can rely upon to get you through this. The Robocode package itself has sample robots that you can try out and that have source codes to reference on. Look around and you'll find something to solve your problem. That's what I did.

Conclusion:

This particular exercise made me realize something that was inevitable. Mathematics is really important in programming. I need to know fundamental formulas in order to produce practical code. I actually look forward to studying math now, because I think it will be useful. These 13 programs were useful. Without it, there's not much you can do with Robocode if you don't know the basics.

Once you've gotten the basics out of the way, that's when you can actually built your own robot that will defeat the rest. Over the course of coding and testing these robots, I always had ideas coming up about how to change little details or how to use what already worked. Robocode is very exciting. (except at 1:00 in the morning and you're neck is aching from working on a bug all night)
Go to my UH website to download my source code for all thirteeen exercises. (http://www2.hawaii.edu/~wingma/)

Free software to maintain finances.

I chose to test an open source software(OSS) from sourceforge.net called Virtual Cache. It is a java based program offered for free on sourceforge to be downloaded. What you get from the download is an .exe file that installs the program Virtual Cache onto your system and runs a small GUI in order to interact with the user. The main purpose of Virtual Cache is to maintain financial records and transactions of funds. The user enters the date, amount of money, and an explanation. All this data is stored in a database that is password protected.
This is the download page(http://sourceforge.net/projects/virtualcache/)
This is the main site(http://virtualcache.sourceforge.net/)

The three Prime Directives for Open Source Software Engineering

1. The system successfully accomplishes a useful task.

This program keeps a track of all monetary transactions that you as the user input, does the arithmetic and shows you the current balance. The main strength in this software is in it's simplicity. There are not that many factors to calculate. I like that you are able to just input a few bits of data to maintain a personal and somewhat secure balance of your assets. The password protection is what makes it actually worthwhile, compared to a regular excel sheet. Virtual Cache is pretty useful.

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

The installation is relatively easy. The .exe file walks you through the regular process and then you just start up the program. The GUI has flaws however. I found it very confusing that when I started it up for the first time or the second time, it did not have a startup sequence. It instead relied on the user to create a new database and password, which was not too rigorous, but still required more studying of the program. It would be nice to have a small introductory questionnaire that sets you up with a database right after you start-up the program for the first time. After some determination the program works and runs smoothly enough to compute your balance.

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

The one big fault with this program is that the source codes are not offered on the summary page of the side. In order to download the source code, you have to download it from another server. This is a major weakness in their execution. I find it really aggravating to have to go through so much just to look at their code. There is no documentation either. This makes the third criteria for the prime directives unmet.

So..
I find this piece of software very useful, but it is also very limited. It's potential to grow is limited. With such a simplistic structure architecture it remains easy to use, but if it becomes too complicated I think it'll be a bother to just turn on. The trouble in accessing the source codes will also be a hindrance. I would not pay for this software.

Basics of Java and getting back into programming.

Programming is just any other skill that you learn. It can be forgotten. I was asked to write a simple program called the fizzbuzz program. According to my professor, he had read an article in which this program was used as test during a job interview. Link. What was surprising was that the articles says that a majority of computer science graduates are incapable of doing this or they take an extraordinary amount of time to solve this problem.

What the fizzbuzz problem asks for is to print a number from 1-100 or whatever the range. Whenever there is a multiple of 3, the word fizz would be printed in it's place. Whenever there is a multiple of 5, the word buzz would be printed instead. And the third condition is that whenever there is a number that is the multiple of both 3 and 5, the word fizzbuzz would be printed. Seems simple right? I tried it out for myself as well. Here's the code in Java:

public class fizzbuzz {
    public static void main(String[] args) {
         for(int i = 1; i<= 100; i++){
                 if(i%15==0){
                     System.out.println("fizzbuzz");
                 }
                else if(i%3==0){
                     System.out.println("fizz");
                 }
                 else if(i%5==0){
                     System.out.println("buzz");
                 }
                 else{
                     System.out.println(i);
                 }
             }
        }
}

This program took about 3 minutes to implement, counting start-up time for my eclipse editor and compiling. Although it was easy because I knew what I needed to do already, it still took some time to figure out the mechanics. The very first time I tried this, it more than 5 minutes because I had not programmed in java for quite awhile, not to mention the programs associated with the installation of Java and using an IDE. I think that is one of the major problems with those cs graduates. Programming requires practice, and quoting a cliché, "if you don't use it, you lose it."

This fizzbuzz program is not a complex program at all to implement. What I think cs graduates and programmers have to realize is that, programming needs to be viewed as being as important as doing simple math or knowing how to speak English. It's the basis for their career and if that's not up to par, they're at a disadvantage.

The basics are the fundamental to software engineering. Being able to write up this fizzbuzz program brought me back to reality about what I need to know. This experience has taught me that quality programming may be a goal for software engineering, but you need to know how to program first.