What I'll Take Away From This Class Is...

Like all things, it must come to an end eventually, and after a while we take a long look back and reminisce in the memories and experiences that we made and will never forget.

It sounds like a cliche of highschool but in college it happens every semester.

This semester I was fortunate enough to take the ICS413 software engineering class taught by Professor Johnson. A class and I know for sure I will take away a lot.

It was a interesting learning experience and has really given me a lot of insight into software engineering.

Overall the class was not overly hard, but still required some effort to do well in. The screencasts and reading were done at home and part of this inverted pedagogy as professor Johnson calls it. It allowed us to restructure our time in and out of class, allowing us to choose when to listen to a long lecture and instead in class either do an activity or get a pre-emptive start on the assignment at hand with the ability to ask questions early.

I thought it was unconventional for an ICS course but worked very well and I could definitely see it working in certain types of courses.

In terms on the ARCS model of teaching, which stands for Attention, Relevance, Confidence, and Satisfaction. I felt that the course structure and assignments fulfilled all of those foundations well. The variety of assignments were relevant to our interests and kept our attention, I can recall that the Robocode assignment was a very interesting idea and the class competition was an interesting day in class.

Upon finishing this course I do feel slightly more confident about my ability as an ICS student and more professionalism.

Rounding the Home Stretch: Greenometer v2

Greenometer v2 is finally here just in time to save you from Green$.

After our initial experiences with working in a larger group and creating our first web application, once again I have to commend our group members Kelvin Green and Edward Meyer. Both of them did an outstanding job in taking charge and adding a lot of functionaility to the overall system.

While our first project was very ambitious, we tried to tackle a lot more this time around adding a much functionality as we could and then finally adding some very nice finishing touches thanks to Kelvin' experience.

Overall this time around we worked a lot more as a group, each member was more hands on with the coding itself and adding functionality, although much of the harder code was once again accomplished by the more experienced members. But overall collaboration was up and everyone contribute a good amount of code, and while not coding was also around to answer each other's questions.

As an end result we are left with a very professional, in my opinion, looking site with a lot of functionality. We were able to implement five of the extra credit criteria and even went as far as added extra functionality that was not originally on the list.

I feel confident and proud in our overall package and am confident that it is truly something I can proudly display on a public site for others to use.

Eco-Depot Code Review

We are once again tasked with doing a code review. Each time we do this, we are hoping that it gets easier. This time we are reviewing a web application based on our Wattdepot clients. We will be using it in conjunction with wicket to develope page that users can use to determine when we can defer electrical usage.

Today I will be reviewing the Eco-Depot system.

My review can be found here.

The eco-depot system fulfills most of the basic requirements of the system. The quality of the code is good and is designed properly. The only part of the system that requires improvement is the testing and overall group process. Some members are doing a vastly greater amount of work than others. Suggesting that the project issue manager should be used to delegate tasks properly.

Wicket Good: Web App Development Using Wicket

No longer are we working in small pairs, but now we are a quartet of different people with different abilities. Will having a larger group with more responsibilities hinder our progress or will it be smooth sailing with that much knowledge on board. With our combined knowledge we are Greenometer!

After completing our Wattdepot clients last week, our group was paired up with another group forming our quartet and were assigned to create a web application that displays a table of carbon emissions for an requeste

d day. The table has a color code that will tell the user the carbon intensity of the grid at that hour to help them decide how to better manage their electrical usage.

One of the first things we did have was two group members clearly taking charge. Having a project manager to keep the work delegated and in track was very useful. Each part of the overall project was able to be laid out and each member was assigned a task base on their ability.

Those with more understanding of how to build a Wicket application did most of the development of the web app. While those who were more unfam

iliar were assigned to doing more menial tasks like gathering test data and documentation while looking at the development of the application to get a good understanding of wicket.

With one of our more knowledgeable members, Kelvin Green, we took an ambitious route and did more than the basic specifications. We took it up a level to add a better visual representation of the sampled data to give users a graphical layout of the data rather than a simple table format. One downside to this layout was that it is difficult to users to view the actual numbers from the sampled data.

Overall I believed we worked well together. Members were there to keep each other in check, and although we had varying schedules and were unable to meet face to face, the quick relay through email and online instant messaging was an acceptable substitute.

Here is a view of our HackyStats ICU data.

Many of the ares are pretty good. I would say it is an overall healthy system. We had a mild start with some development time and builds, but it really got going over the weekend which is expected for students.

Big Brother is Watching: WattDepot v2 & Software ICU

In this assignment we were tasked with writing the commands of a command line interface for the WattDepot client. We were paired up with a partner and given our first real software engineering task.

In the second version of this assignment, three new command specifications were added to an updated WattDepot client and we were again working with our partner. The only difference this time was that we were being watched. Using hackystat, our project branch's health was continually being monitored for commits, coverage, work by each member, etc.

This pushed everyone a step further since you couldn't slack off and complete the assignment the night before it was due anymore. But it was also a very useful tool for monitoring your progress throughout the assignment. I had found myself

going to the hackystat project browser to check on our statistics every now and then to see the improvement.

What started off as a minimally functioning system, we designed into a well organized implementation that addressed much of the issue if not the only issues for our previous designs from the reviews. We separated methods that w

ere stored in one class and added many test cases to raise our coverage of the system. We had been lacking any test cases from our initial implementation and have now raise it to around 62% line coverage at around 80% class coverage. Though we chose to have a well designed system with good coverage over completing the three new command specifications. We were only able to complete two out of the three.

I believe this time around the group dynamic was a lot better. We had much more communication between each other, and I believe although we did not finish, we accomplished more than our initial implementation. We were not able to meet regularly, but through online contact we were able to discussion implementation and delegate tasks efficiently.

Here are some comparisons of our progress using the ICU.

Before

After

It could use a bit more work, but there is a huge improvement. Overall I believe it is a pretty healthy project with commits from both sides and improving coverage.

Using our project, we are required to answer the follow questions. We will be doing 4 out of 6 questions because we were unable to complete the last command.

Here are the questions we will be answering:

1. What day and time during the month was Oahu energy usage at its highest? How many MW was this?

2. What day and time during the month was Oahu energy usage at its lowest? How many MW was this?

3. What day during the month did Oahu consume the most energy? How many MWh was this?

4. What day during the month did Oahu consume the least energy? How many MWh was this?

Answers: To be completed when I figure it out, math and problem solving aren't my strong point.

And The Results Are In: Wattdepot Review

I just finished reading the reviews of my groups Wattdepot project and I have to say I am pleasantly surprised. They were mostly all positive. One the exception of course of our group not having any real test cases so that was one thing that everyone commented on.

I believe that the better your system is the easier it is and yet the harder it is the review. When I looked at the reviews for my group's system, many of them were a short and precise: This system works, the described checklist item works and is in order. But from my experience when it is good, it is harder to break or find something for the group to improve on.

One of the strategies I tried during the review, since we had to review two systems, was first trying to break the system and then reviewing the code. After that I tried reviewing the code first and then trying to break the system. I found the latter a lot after and easier to do. The reason being is that when you review the code, you can see which of the specifications were not implemented, and immediately you can see problems. I was able to see which exceptions were not caught and immediate knew how I could break the system. It is a lot faster than trying to think up of ways and then testing all possibilities on how I can break a system.

All in all, I believe that taking different approaches that work well next time can speed up the reviewing process, I found it not so bad and gave me a lot of insight into potential problems and even fixes and ideas on how to improve me own project.

Your code has good Feng Shui: WattDepot Code Reviews

All these parentheses and semicolons really ruin the feng shui of the code!

Although it can often be a very good thing, a lot of programmers hate to do code reviews. So this week we get a hard learned lesson is code reviews.

I have been tasked to review two other groups WattDepot project mentioned in our previous blogs. Watch as I tear it up.

The reviews for these two groups were assessed based on the checklist found here.

To read my full review of the code refer to the links below:

Eolu (eono)

Ehiku

Summary:

Eolu

Not all the commands were completed. Overall the design could use work, the methods can be split into there respective classes and the javadocs require updating. Comments need to also be added to many methods, it is inconsistent.

Ehiku

All but the chart command is completed and functioning. The design for the system is very good, all methods are separated into their own class. Commenting and naming conventions need to be more consistent across the different programmers. Overall well programmed.

Ten Specifications Down for Team UMI: WattDepotCli

So we have just completed our first team project and everyone could use some sleep. It is three in the morning and only four out of the ten teams have submitted their projects as of yet.

At the beginning of the project, I believed that it would not have been so bad. Working with partners has proven to be an effective was of learning and increasing productivity. So I'll share some of the experiences I had with my partner.

Unfortunately for us, my partner and I were unable to meet everyday since we both has busy schedules. Unfortunately again that this project be over the Halloween weekend where everyone likes to party away. With my schedule being so full, I was hoping to try finishing up small easy parts during my spare time. Though that didn't work out as well as I had planned.

Luckily for me, my partner is quite the diligent worker and before I could really step in a do much work, most of the project was already complete. I was left to review some code and add in a part of the remaining Cli. I do wish I could have helped more though, but the delegation of tasks were not as clear with each person working on something and then moving on to the next one that is not yet taken.

With proper delegation of tasks I believe that the project could have flowed smoother, but differences in schedule and does not often allow for that. Even with many people with a single goal, I learned that it takes a lot of communication between these people to get the job done. It wasn't until we sat down and talking about the task as hand were we able to really get it flowing.

Integration With Hudson

For the rest of the semester we will be grouping together with a partner or other people. We've already touched upon using a version management system such as SVN to allow us to have a centrally distributed build. So now that we are working with partners it's a good time as ever to get into the practice of using this newly found knowledge.

Last week, we were introduced to Hudson which allows us to automatically run repeated jobs and auto build/test our systems. This automated process is connected to our google repository. This is a very useful tool for us to use now that we are working with a partner/s. When one of us breaks and build on uploads a new build it will automatically test it and send out a report by email to us.

Most of the setup was done by my partner but from what I could tell, the Hudson system was very quick and easy to set up. It only took a few minutes to get our program up online and have it start building. I'm sure it will continue to become a very useful tool throughout the rest of the semester and probably our future career.

Midterm Review

The midterm is coming up and to help us study we are creating ten quiz questions that will help us review the material when creating the questions and allow others to review material while scouring for answers. These questions are similar to ones found in class and will test our overall knowledge of the material discussed in class minus anything related to RoboCode.

10 Questions are posted, return on Tuesday for the Answers!

Edited with Answers on the Bottom

Questions

1. Please code the FizzBuzz program discussed at the beginning of the semester. Count from 1-100, replace multiples of 3 with fizz, multiples of 5 with buzz, and multiples of 3 and 5 with FizzBuzz.

2. Why is the above useful knowledge?

3. Why is it useful to ask smart questions? What is an example of a Smart question and answer.

4. Why is it important to know how to override equals() and hashCode()?

5. When overriding equals() and hashCode, what are important things to keep in mind?

6. Why is it important to follow coding standards?

7. How effective is multitasking? Can you list some strategies to be more effective at working?

8. What is ant and how is it a useful tool to us?

9. What are the differences between white box testing and black box testing? Can you give an example where they are used?

10. What is Subversion and Git? What are the differences between them? List an Advantage and Disadvantage of both.

Answers

1. Please refer to your first blog post for the answer.

2. The FizzBuzz program is useful to know because it is a common example of a general coding question that would be asked on an interview.

3. It is useful to ask smart questions because it allows anything who may help you information on the problem and allows them to reply more quickly.

4. It is important to know how to override the two methods because it allows you to change the restrictive method to allow better comparability with objects such as object classes that you define.

5. When override these methods, you must remember to override both of them and that when overriding the equals method it has the following characteristics, Symmetry, Reflexivity, Transitivity, and Consistency.

6. It is important to follow coding standards because it allows uniformity between code and easier accessibility by other users reading and trying to understand your code.

7. Multitasking is not effective, it only feels like we are being more efficient, but it spreads user focus across multiple things and lowers the quality of work. Remove your self from distractions such as cell phones or the TV.

8. Ant is a java build tool that allows us to automate a building process of files in a distribution. It is similar to the make tool, but uses java.

9. White box testing is a more internal approach to testing in which the tests are designed based on the actual code, while black box testing is an external outlook at the testing in which we test to see if the code works correctly.

10. Subversion and Git are version control software. A big difference between the two is that Subversion is centralized and Git is distributed. One advantage of subversion is that when there is a change all the versions will be updated to the most recent, but since it is centralized, everyone will experience problems if the centralized version is compromised. With Git you clone the repository and run and change the files from a local copy off your computer, this means that there is no extra history coming from any other contributor and may lead to having multiple copies a file for different versions.

Did I just Google Groups Subversion?

This week we are taking our projects online and hosting them through google. We also learned about configuration management through subversion.

Google allows us to host projects through googlecode which allows us to give access of our code or project to other members and then collaborate by sharing ideas and code. One of the ways we can cooperate on a single project is through the use of subversion. This program allows us to download files from our google repository and then after making changes, committed them for everyone else to download and view.

You can view my google project page here.

One of the most difficult things through this process was figuring out how to use the SVN client, SmartSVN, properly and direct it to my repository. Once I got the steps down, it was a simple task and took less than a minute to connect to a classmates repository to download their files. The other majority of the time was spent configuring the google group site to add members and have email notifications. Again this is a problem when you first start using these things.

One of the things I really took from this was the configuration management and using SVN. The ability to collaborate on a larger project without having to constantly contact and talk to other contributors is going to become a great asset to me in the near future. I'm planning on working with a few friends on an upcoming project. One of the things I really like about using our repository was the fact that it allowed for the tracking of changes. It will be a lot easier to quickly read through and understand new changes made by other contributors when it is highlighted for you.

Junit Testing My Patience

After learning about build systems we were given the task to create jUnit tests for our robots.

You can find my distribution for my robot with test cases here.

It is one thing to design your robot, but it is a whole other thing to figure out tests for your robot. Trying to think of a way I could test a robot that doesn't have any predefined move path was torture. The fact that my robot's movement is based on the positioning of the enemy robot made it very difficult for me to test the proper movement.

The easiest test for my to do was, other than acceptance tests, were the firing tests. My robot fires very conservatively so it was easy to check, if they move don't fire, if they sit still fire!

The biggest problem was the unit test and the movement behavioral test. The unit test was very difficult because my robot in itself is very simple. Moving constantly in a predefined angled but relative to the enemy, the only thing I could think of was having the only formula I could have in it, which was one we had done earlier in our run through robocode, the Fire03 robot we built who's firepower was determined by the distance from the enemy.

Since this is in fact the first time we are doing tests I don't feel as confident in my test cases than I should be. After all my robot didn't do so well in the competition because I was unable to compensate or catch certain interactions with different movement patterns. All of which could have been better if there was proper testing.

I wasn't able to figure out how to run emma, although understand what it does essentially. I think my robot has a long way to go still. After some though I believe that one of the ways it could be modified for both testing sake and actual performance is to have a more clearly defined movement pattern. Right now I feel that is just too basic and very hard to test for, well how hard is it to test for a robot that moves forward? But then how hard is it to test for a robot that moves randomly without using the math.random() function. I kind of feel like that at this point, stuck between something really basic and something overly complex.

I think simplicity is the key to more sleep.

Built by Ants - Scavenger:ReTune

So I have a 70+% win rate against sample Walls, yet I have a 70-80% lost rate against a Walls traveling in the opposite direction. The irony hurts so much. Yet I still can't figure out how to compensate for both.

These past two weeks we have been learning about build systems. Using ANT we are able to build our robot, run some automated quality assurance checks, and even test our robots through junit.

Click here to see my the build system for my Robot.

I gained a lot of insight about how build systems work and I can start to see the powerful advantage it gives programmers. Just having something like check styles saves so much time. I had caught at least ten errors that I didn't know I had, though more than half was either me forgetting to add a period to my javadocs or not putting spaces in my "if statements". Then things like PMD and FixBug, can save a lot of time has headaches by automatically catching common errors and bugs in your code.

The first thing you notice right away is that we use a lot of xml. I first learned about xml in my ICS101 class. We watched a video in which they talked about how companies use XML to help their transactions. I never associated it with the programming that I've done up to only a few weeks ago when I was going through a program called OTCG, which is a networked open source online trading card game framework. Using these xml definition files you can create any card game you want and connect to other players online to play with them. The only thing is its very basic and you have to define all the actions yourself in xml definition files. The minute I opened up one of the build.xml files in the sample folder I immediately recognized this as something familiar, though I never really saw how it could be applied to something as grandiose as a build system.

The assignment had us adapting the sample code as a template to our own competition robot. It was a fairly simple task, I didn't run into any hiccups that was not cause by pure carelessness, which was me looking at an entirely wrong folder which was one character off from the actual folder for fifteen minutes.

Competition Bot - Scavenger: First Tuning

It's time to gear up for our first class competition of RoboCode. Over the weekend, we have been designing and tweaking our robots for war.

Lets take a look at the robot I've designed. You can download it by clicking here.

Name: Scavenger

Description: Circle the Enemies and FIRE!

Movement: Moves in a slight angle relative to a traget robot's position

Tracking: Track closely with gun and adjust heading to match target

Fire: Fire on stationary targets

I named my robot Scavenger because of the way it wins. It will move in a circular path around enemies waiting for them to expend their energy by dodging fire. The original design was to only fire after the enemies have become disabled. This worked for the most part, but winning is about scoring points and you are able to accumulate a huge amount of points, although less than surviving, by scoring hits. This also allows Scavenger to take down stationary robots that have yet to be disabled such as SittingDuck, and Fire.

One of the things I learned while fine tuning this robot was that each situation requires a slightly different approach. To win we must try to make our strategy as general as possible and then fine tune.

We were able to discuss with our classmates strategies against eight of the sample robots. In each strategies, I realized that although each strategy may work on one of these robots, it would never work on another. You can tell by the labels written on the strategies when it is labeled as, e.g. "WallsCounter", "SpinBotcounter", etc.

Even after coming up with a strategy myself, I found that, although I could beat one robot with it, I would lose or come very close to losing against a different robot. I knew my strategy was solid, but I understood that I had to do test runs to understand problems.

Erratic Movement Robots:

The only two Sample Robots that I was unable to defeat with over 50% success rate was the two AdvancedRobots. SpinBot and Crazy both extend AdvanceRobot allowing them to, along with other things, do simultaneous movement. Since my robot is based off the movement of the target, the erratic movements from the SpinBot and Crazy to lower the effectiveness of my evasive movement. I believe if I can devise a better strategy for wall collisions and tracking, I would be able to fine tune my robot to defeat even these advanced robots.

Problems

The Walls:

No, not the Walls robot that seems to take everything down, but the walls of the arena itself hindered my movement. Allowing the robot to turn to correct it self wasted valuable time and allowed others to get more hits on it. I finally opted to just back track a few steps. Since the robot's movement is based on the movement on the target, it will auto correct itself after backing away from a wall. Otherwise, on stationary targets it will provide evasive movement until they have moved or run out of energy.

Enemy Range:

The last problem I found was trying to get my circling movement based on my target and their range correct. I had noticed that with by turn radius 120 degrees I was easily able to beat sample Walls, but the large turn radius allowed Sample Tracker to get an upper hand. If I lowered the turn radius to 100 degrees, I would be able to quickly move around Tracker, but then the small turns was less effective against Wall's fire. After hundreds of test runs, I decided that it would be best to just make a minor compensation rather than adjusting my strategy. I opted to change the turn radius relative to the distance of the target. This fix allowed me to compensate for both near and far targets.

So You Think You Can Robot?

Today we will be reviewing some sample robots included with the RoboCode game and looking at what makes them tick.

We will be evaluating: Walls, RamFire, SpinBot, Crazy, Fire, Sitting Duck, Corners, Tracker; on these three criteria:

1. Movement - How they heck are they moving? Crazy randomness or controlled chaos?

2. Targeting - Which way are they looking? How do they find their next prey?

3. Firing - Fire at will! How do they fire? Unload all your ammo and pray no one is left standing?

Walls

First up we have walls, a very simple robot. The first thing it does when it begins is to turn to the wall closest to the direction is it facing; meaning even if the wall is one pixel away from it, if it is facing in the other direction it will go to that side instead. I am unsure of the coders reasons for doing this, but it does save valuable time turning. After reach a wall it will travel around the battle field in a constant circle from corner to corner.

This walls robot does not have actual targeting. What it does is use the radar as attached to the gun, and fire as soon as the gun is aligned with another robot. The gun is always point out at the battle field, so it will fire once as it lines up with a target horizontally or vertically, and then again when the robot turns at the corner because of the shift in the position of the gun.

One thing I noticed is that this robot will stop and fire continuously at another robot that is blocking it's path, only if the gun is currently facing in that direction cause by the arc of a corner turn. Meaning this will only happen in a corner. Other than that, if your robot moves and doesn't stick to the sides, this robot is not very effective. Against a stationary opponent though, it is super effective.

RamFire

RamFire is a interesting a unique robot as it is on a suicide missions. How this robot works is it chooses a target and then SLOWLY rams into them. In RoboCode, collisions between two robots cause damage to both parties. It will keep moving up against its target, "Ramming", them for damage.

Targeting is done by a simple scan from the turn of the gun and body. Once it scans its first target and rams them continuously. My tests show that it does not track, but goes for the first scanned target, if its current target moves out of the way in time, it will begin scanning again for something to ram.

To avoid killing itself in the process, RamFire begins bombarding its target once it has made contact with them. In RoboCode, you score points and regain energy on successful gun hits.

Again this robot is quite effective against a stationary target or one that stays in the corner and can become trapped. Other than that move of my simple movement robots, as long as they do not stop can usually avoid getting caught by RamFire.

SpinBot

SpinBot is a very simple robot that I actually borrowed some code on when doing my own spinning movement. SpinBot moves in a circle and that is about it. Looking at the code, the robot is taking a very hard right while flooring the gas and never stops.

While rotating in this circle, any time the gun lines up with another robot, it will fire a shot at it. It is kind of simple is does ok against some robots as the circular movement avoids many shots, though due to the small radius of spin it sometimes runs into the bullet anyways as it makes a full circle, and then it is also a easy target for robots such as RamFire.

Crazy

Now here is an interesting robot. They name only gives us a small hint at what this actually does. The Crazy robot is designed to move around in a crazy fashion. What? I had to take a look inside the code to understand for myself what the heck was going on.

The Crazy robot's movement is designed in a very simple three step manner. It turns 90 degrees one way, then 180 the other way, then 180 again the other way, all while moving forward or backwards. On wall hits or being hit, it will reverse direction. This gives it a very random move path because there are many collision events and each time it will respond but moving around in a circular 180 degree fashion.

There is no real targeting like with many of the above robots, what Crazy does is fire on the scan of the gun with another robot. Very simple no tracking involved.

Overall Crazy is a very evasive robot and survives a while even against the more aggressive robots.

Fire

Fire is a very simple robot and is something that we have programmed before. Fire is no movement. It is stationary and rotates it's guns to scan for targets. Upon scanning a target it will stop turning its gun continuously fire until the target is destroyed. Fire turns its gun in a clockwise fashion so it has minor tracking ability if you are moving in a northern or north eastern path, but will lose its target and start firing on a new one if you move counter clockwise around it.

Overall very aggressive but does not work well against mobile and other aggressive robots who have mobility.

Sitting Duck

Like the above Fire robot, Sitting Duck is also a robot that we have made before. Having none of the three elements we are looking for, sitting duck basically is a stationary target practice, or a road block.

Corners

Corners is quite a good robot, but interestingly very simple. I had heard that it was one of the tougher robots. Upon testing, it is mind boggling how simple it is and yet it is very powerful.

All Corners does is picks one of the corners to go hide in. It moves to the sides and the into the corner on start. If by chance that it is destroyed in the current round, it will remember that is choose a different corner the next round hoping for the better.

Firing on Corners is very simple too. It is set to fire on scan from the gun, so it will fire if a robot moves directly in front of its line of vision. Once in the corner it will rotate the run back and forth between the angles that its back is not against. This allows it to fire at a more rapid pace and avoid needless scans. I though it was very effective that it did not scan areas it knew had no enemies.

Tracker

Tracker is the only robot to have a lock and track movement out of the other seven reviewed. It is similar to the tracking robot that we have programmed. It rotates its gun to scan for a target. One found it will lock on and move to within a set distance.

The targeting like most of the other robots, consist of turning the gun around until the object is scanned. To keep track of a target, it will store a targets name and check to see if a scanned object is the currently tracked target.

Firing for Tracker is a simple, when it is within a set distance fire at the target. Upon testing, I found it to be extremely ineffective. Since it only fires at a target at a certain distance, it is very easy to miss a constantly moving target. I also found that it has a hard time catching up to a target that is constantly on the run.

I was able to defeat Tracker using a movement only robot that goes runs to the corners. Tracker wasted energy by missing all its shots and then running out of energy before every getting the chance to get close enough.

Battle For Supremacy

As a final battle after testing and reviewing each of of the samples separately, I decided to have a little fun and throw them all into a giant battle. Surprisingly, the top place robot were SpinBot and Crazy. The circular movement robots. I had initially thought the robots utilizing the corners and sides where there is less threat from behind would win, but the circular movement of the robots allowed them to avoid fire from all sides.

Robocode v2: Real Programmers Don't Comment!

We are once again back at our robocode basics, finishing up unfinished code and fine tuning it for review. Movement01 doesn't do anything, so what is there to fine tune?

The main task this week was to implement RoboCoding Standards into our code that conforms to the java standards set forth in our book, class, and RoboCode.

Click here to see my attempts at RoboCoding Standards.

Comments are easy right? We've been coding for years!

As we saw in class; everyone, even the most experienced java programmer, can admit to breaking one or two standards. Trying to stick to a hundred different rules for coding is like trying to write an essay in proper English. Everyone has a different style of coding, yet we want to have a unified style of explaining what we write.

Just going back and reviewing my code, I had found huge amounts of violations that I had always though was correct. I had come to the conclusion that I was either an idiot or that standards for commenting change over the years.

One of the big things I noticed was the enormous amounts of end line comments. It seems like such a rampant thing that I always see people do. Well code monkey see, code monkey do, and like everyone who's made the mistake, the fact that bad commenting habits spread is a very important reason that being careful to stick to a proper uniform style is useful.

Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.

An interesting quote I saw on a shirt the other day had me wondering why we comment our code. The main reason I give for having comments is to allow others who may look upon your code to be able to read and have a clear sense of what is going on. Not everyone is a genius and can speak code, and not everyone is a genius in that they can write a program from start to finish without needing someone to review it.

These standards are there to allow us to map out our thought process to other coders. This allows cooperation between two unlike minded people. If you can't understand where one person is coming from and trying to do then how can you ever possible understand how their code works. But if we can write it down in a way that you can ready, although you may not understand their code, you can see how they are trying ti approach a problem.

It is also helpful, I believe, to have a very consistent and uniform for style to coding that we can easily read through ourselves. By avoiding writing redundant comments, and avoiding using third person. It creates a better overall flow in the though process and understanding when you read your's or another's code.

The Robocode Experience

For the past week, our first real java project in class was to familiarize and try our luck at at RoboCode.

What is RoboCode you may ask?Well, Robocode is an Open Source educational game started by Mathew Nelson. You build small tanks that are thrown into a battlefield where they battle it out until one is left. The catch is that each tank has to be programmed in java by you.

After installing the open source game, we were assigned simple design tasks for basic movement, tracking, and firing. The tasks ranged from simply doing nothing, to having tracking software installed onto your tank.

While it is fun to play around with, anyone learning java can greatly benefit from creating a few robots. After about a year of learning new programming languages, I too, have to admit my java was very rusty. After spending a couple hours on RoboCode, memories of searching through the java API and creating insanely complex loops and methods only to find out there was one in the API, came rushing back. An uneasy feeling rose up in my stomach as I instantly knew I was going to be getting very little sleep this entire semester.

I was able to start slow, learning the basic methods involved in moving and turning the tank, but some of the later movement specifications were no simple task. It required you to think about the positioning of your tank for different orientations and adjust accordingly. In one of the movements, I found myself making a different test case for the tank’s relative position to the center of the battlefield, and which way it’s gun was facing. Throw obstibcles in front of that and you’ve got yourself a thinker.

If you want to take a look at my completed (12/13) Robots, download themhere.

One of the hardest problems I had was having to use complex math to allow more elegant movement. One of the robots, which I was unable to finish was a robot that would move from one corner to the opposite corner, which was more complex than I initially though. In the game itself there was a sample robot that would move to corners by first moving vertical then horizontally. I had implemented something similar to this, but then after some discussion with other friends, we agreed that it did not hold up to the true task for the movement, which was to be able to move diagonally from one corner to the next. This seems somewhat simple in math, though my worst subject, it requires just a bit of trigonometry. Drawing things out on paper or even in the air can help many times. It helps you visualize your objectives. On paper is sounded simple, use the position to make a triangle using some trig functions and you’ve got yourself a direction, but trying to implement it in java still causes me many problems. This was in fact the only one I was unable to complete.

This was an overall good exercise in java. The real challenge lies in creating an actual competitive robot. Implementing creative movement patterns and attack strategies may require a lot more planning, and much more complex math. We can build upon the smaller programs that we have made, much like our experiences with java programming. Always keep good code in case you ever have use for it in another.

Falling Off the Java Bicycle: FizzBuzz Implementation

After a two year break from java, I once again returned on the popular java programing language, and this time I feel off the bike pretty hard. The object of the program is insanely simple after programing for a few years. I understood exactly what I had to do and what I needed to do to get there the second the program was described. Then why did I fall? The primary reason was the my decaying memory of the java language syntax. Writing java down on a pice of paper after two years was insanely hard. With only fragments of the opening syntax, many a times I would look down and realize my line prints in C. Quite embarrassing to come into a high level class like this I feel like a total beginner again.

After the failure in class, the assignment was the do the code once more. This time I remembered the correct syntax and was allowed to use the Eclipse editor, needless to say, I was able to blaze through with all the speed of a top notch muscle car. From the time the editor loaded to the completion of the comments and test run, it took all but two or three minutes. Half the speed comes from the Eclipse editor as it has many useful features such as autofilling of functions and easy copy paste features. Eclipse also allows you to shave from a few seconds off your time to a few minutes depending on the program with its pre-filled public static method, and the amazing ability to compile and give error messages while you code. Overall even with such a simple program, even programmer can fall into these simple traps, and the course design gives an overall feeling of a well designed prep course.

Below is my second attempt at the FizzBuzz program:

OSS Experiences: DRAW ME!

Today, I will be evaluating the vector graphic drawing application GlyphEdit. The program is written in java and runs on popular platforms including, Windows, Mac, and Linux. The basic features of this program allows the user to create simple vector objects using predefined shapes and lines. A few extra features allow you to group, rotate, scale, and even add text to the object.

The first question that comes to mind is, what reason is there to use GlyphEdit when there are already many open source graphic tools that do a lot more, e.g., GIMP. The one feature that stands out in GlyphEdit is the ability to save the graphic in the 3D geometry data format, OBJ. Which for the purpose of this blog, i.e., focuses on java, allows us to easily implement graphics in java applets without the constant guess work.

Sounds useful! But I downloaded another application and couldn’t figure out how to run it! No need to fret here, after unzipping the file, all that is needed to run the application was a click on a file corresponding file for your OS. The application’s GUI elements were made to mimic the simple clean look of a Mac OSX application. The button layout, standard to most graphic editing program, you choose a shape on the panel to the left and click on the canvas to draw.

The last useful thing about GlyphEdit is that it is written entirely in java. Browsing through the folders you will be able to find all the java files, then open and view them. The files are separated into the graphic objects and the applications GUI, all with full comments; allowing you to easily change the layout of the buttons or add new features such as color selection.

Overall, while overly simple, I found the application very practical and useful as someone who has tackled a java applet or two. Although there are some hiccups here and there with newer OS versions, it is definitely a keeper in my java archives.