More Development!

Today we revisit the program from the last blog-post, except this time instead of just looking at the program and evaluating it, we're actually taking their code and adding more features to it.  This was a first for me, editing other people's code and writing in their style, that is.  Though I guess that this sort of thing is pretty much standard in the tech industry, for everyone to build upon each other's code.

Anyways, let's get to it! In addition to the four commands that were present in the first version of the code, we are now responsible to add three additional features to the code base. They are:

• set-baseline: Takes consumed-power levels for each hour of a certain day and uses these as a baseline, or a set that can be used for comparisons. There is an optional date parameter, and if it's blank, by default the day before the current day is used to generate the baseline values.
• monitor-power: Monitors the current power of a certain location, generating results every-so often, depending on the value entered. Values keep showing up until the user exits out.
• monitor-goal: This takes the current power and compares it to the baseline value generated using the set-baseline method. Compared to the baseline value, this command prints out a number 1-99, which is the percentage of how much energy is being saved. In order for the goal to be met, the current-power must be 5% less than the baseline value.

So having come off with some experience as to how to go about creating commands, we set off to build the next set of commands with another group's code. We split up the commands, so that one person did each command.  Taking dependencies into account, the set-baseline command would have to be completed before the monitor-goal command could be implemented. The monitor-power command, on the other hand, could be implemented without the need for any prerequisites.

It took a while to understand the way that the other group made their code, which was different from the style we chose. For one, their code was admittedly more complex and elaborate than our own, taking into account such things as time difference, manually coding date-validity checkers, among other things.  After a while though, I managed to get the hang of coding in their style, and went on to code my part, which was the set-baseline command.

I came across some problems when coding. One, A lot of JUNIT tests were failing when I was running them.  These were tests written by other members that had been verified to work on other computers, but for some reason I was unable to run them. As such, during the verify process I would be unable to check for bugs in my code, because the process would stop after a JUNIT test did not pass. I was able to temporarily solve this by removing the JUNIT files from the codebase, and then I was able to run my own code and testing.

Another problem I came across was that subversion was not working properly for my computer. When I finished my code, I was unable to commit to the server.  After hours of troubleshooting, I had to send my code to my group members, who got it to commit just fine.

Now during this whole time the group was all occupied with studying for finals, thus finding time to work on this project proved to be quite difficult.  I finished rather late, and as a result, the person who was doing monitor-goal, which is dependent on my code, had a late start to finish their code.  Eventually, we all got our individual pieces into the group build. However, depending on whose computer we ran the code off of, some features would work, while some features would not.  After going at it for hours, and the deadline for the project being less than a day away, we were still unable to figure out why some things would only work part of the time.

Eventually it came to the point where continuing to dedicate time to this project would jeopardize our ability to study and perform well in our other final exams, and thus we had to prematurely cut-off development of the project. The code is added and online, though it needs some tinkering before it can be functional as intended.

Adding code to the project became a real-test to see whether or not this code fulfilled the three prime directives, as evaluated in the previous post. There was sufficient documentation both on the wiki and in the code itself, so adding commands proved to be a doable task, save for the time taken to get acquainted with the code. Overall, I'd say that this code fulfills the directive of being able to be built upon by external users quite well.

This time around, I think our group had a better idea of what needed to be done, but as far as being able to get things done on time, I think we still have some work to do. Granted, final exams were a major factor in our general inability to get things done on time, but in other ways, I think we all are still adjusting to working in a group and being accountable to other members.  This entire project has been a learning process, and I'm sure that all of us are now a lot more familiar with the benefits, as well as the challenges, that come in group work, and with working on other people's code.

Technical Review of hale-aloha-cli-jcev

Continuing on our group project work from my last blog post, we have now moved into the technical review stage, which is looking over written code and evaluating it to determine it's strengths and weaknesses.  We will be doing this, however, with code written by another group, team-jcev. The functionality of their software is the same as the one my group came up with, but they chose to take a different approach in order to get to that functionality.  For the purpose of this evaluation, we will be using a standard called "The Three Prime Directives", as used in my first post. Basically, these are three things that a program or system must accomplish in order to be considered "good" or "usable".

1. The system successfully accomplishes a useful task

We will define 'useful task' as being able to successfully deploy all required functionality of the system as specified in the class assignment page. The following is an evaluation of the functionality provided in the group's code:

    current-power: returns current-power in kW of location

        -runs as intended, throws error if input is wrong

    daily-energy: returns power in KW used at location for specified date

        -runs as intended for valid dates

    energy-since: returns power in KW used at location during specified interval

        -runs as intended for valid dates

    rank-towers: returns energy-usage of towers from lowest to highest during the specified time interval

        -had problems running certain dates that should have been valid. for example, entering in (2011-11-27 2011-11-28) yields a message that says "dates overlap or are beyond current date", even though these should be valid dates. Worked for dates in December.
    help: shows list of available commands

        -runs as intended

    quit: exits program

        -runs as intended

As detailed on the assignment page, this code exhibits most of the required functionality, with the only one I was unable to run being the 'rank-towers' command. Upon testing, some issues came up with regards to input.

-The names of the locations were case-sensitive. If the user entered in the correct name but forgot upper-case, the function would not run

-In the case of out-of-bound dates, the program displays all of the error code, which probably shouldn't be seen by the user.

-Although this is more due to uncontrollable issues, functions that include dates that were within the period of server down-time last week did not return proper results.

Overall, while one of the functions did not seem to work on my computer, the rest was able to run rather well. The program was able to relay important information about energy usage in the freshman towers to the user, so I'd say that it fulfills the first directive of serving a useful purpose, although there are improvements that could be made for it to better fulfill this directive.

Directive 2: An external user can successfully install and run the system

In order to evaluate the system in regards to this directive, we will be looking at the site for the project, which can be found here. Within the project-site lies the wiki, which contains two articles, one for users, and one for developers. Within the user guide, there are explicit instructions for installing and running the program on a user's computer.  Sample input is also provided for the setup process, more specifically the command needed to launch the program from command prompt.

In the 'downloads' section of the project site, there contains a zip file containing the source code, which also includes an executable jar file for running in the command prompt. Version number is included for user reference. Also included in addition to the group's own code is an executable wattdepot .jar file for user and developer usage.

Since I was able to successfully download and run the program on my computer, I'd say that the instructions given in the wiki were useful. The following is a list of input to the program and their respective output:

>current-power lehua

Error: Source "lehua" does not exist.

>current-power Lehua

Lehua's power as of 2011-12-02 23:37:7 was 33.81kW

>currentpower Lehua

Error: "currentpower" is an invalid command! Try "help" for a list of valid commands.

>help

(shows help commands)

>daily-energy Ilima 2011-11-27

Lehua's energy consumption for 2011-11-27 was: 582.7kWh.

>daily-energy Ilima 2012-11-27

400: Range extends beyond sensor data,...

>energy-since 2011-11-27

Bad input: Less than 2 arguments.

Correct syntax: energy-since [tower | lounge] [date]

>energy-since Mokihana 2011-12-27

Bad input: Date 2011-12-27 exceeds the current date.

>energy-since Mokihana 2011-11-27

2011-11-27 00:00:00 to 2011-12-02 23:38:07 is: 3789.84 kWh

>rank-towers 2011-11-27 2011-11-28

Bad input: dates 2011-11-27 2011-11-28 overlap or are beyond the current date.

>rank-towers 2011-11-27 2011-12-01

For the interval of 2011-11-27 to 2011-12-01,energy consumption by tower was:

Mokihana 3140 kWh

Ilima 3170 kWh

Lehua 3179 kWh

Lokelani 3700 kWh

>quit

Quitting...

The program seems to have all of the basic functionality required, with the only functions I had issues with being daily-energy and rank-towers. There also seems to be a rather robust system of input error checks, and shows a consideration for a variety of possible user mistakes. However, there are spots here and there that could use fixing, like the error message for out-of-bound dates, acceptance of non-case-sensitive locations, and the fixing of the rank-towers method for valid dates. Despite these issues, I'd say that the program fulfills the second directive of an external user being able to successfully install and run the program.

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

For this directive, we will look at the developer wiki on the project site. There seem to be detailed instructions for every step of the way from installing ant, an automated build system that is necessary to run the project build, to detailing the coding standards, to outlining the development process. As far as modifications and additions to the code goes, the way of doing so seems to be clearly laid out. The approach that the group has been using is issue-driven project development, which entails splitting up the project into individual problems, or issues, which are then worked on until they are fixed.  A new issue is to be created for each new addition to the code, and set to "fixed" when it is good enough for addition to the code. JUnit tests must also accompany each new addition as well. A link to the Continuous Integration server is also provided, which serves the purpose of compiling uploaded code and returning an error message if the code fails to compile. 

Also, instructions for compiling javadocs, or the documentation of the code that can be compiled from the comments within the code itself, are also provided.

Upon compiling of the javadocs for the group's code, all parts of the code seems to be documented, and they give useful information as to the inner workings of the program. Since the commands are fairly segregated from the rest of the code in other sections of the program, information hiding seems to be implemented effectively in the system.

Building the system using ant resulted in no errors, and took around a minute or so. It was clear how many JUnit tests there were during compiling. Looking through the JUnit test files, it seems there are many tests in place to test many different aspects of the different commands.

Looking through the source code, there is ample explanation regarding the workings of the code, and instructions on modification and augmentation to the code itself. comments seem to be present when necessary.

Back on the issues page, it is clear which member of the group worked on which part of the project, and if a problem stemmed from a certain area, it would be apparent who worked on it, based on the information from the issue page.

The CI page for the project, which shows the success or failure of the commits for the project, showed that the project was regularly worked on, save for the Nov.22-24 server outage.  When faulty builds were uploaded, they were swiftly resolved, based on the times of the commits.  It looks like most of the updates were based around particular issues that needed addressing.

Although for a new user, getting accustomed to using all of the tools would take some getting used to, there seems to be adequate explanation and walk-through present on the project site of this project, as well as within the code itself. Overall, I'd say that an external user could very well adapt and add-on parts to the system. Thus this system fulfills the third prime directive.

Teamwork time!

Up until now we've been able to do all of our projects in this class individually, not needing to compromise or change our style so that it fits with others, being able to do things at our own pace.  However, with this new project we were given, we no longer had those luxuries of independence.  Although eager and excited to get the project done at first, this would turn out to be one of the most stressful projects of the semester, at least for myself.

Energy. Whether we're using our computers, watching tv, or even studying in our room with the lights on, we use a lot of it everyday.  Multiply that amount by the number of people living in a dormitory, and the number jumps up higher. Multiply that number by the amount of dormitories in a university, and it becomes enormous. Getting a glimpse of energy-usage within UH was the objective of this project, more specifically the power-usage of the freshman towers.

Specifics involve writing a command-prompt that would take user input querying one of four commands and returning pertinent information upon submission. The four commands we were to implement were:

• current-power: Returns the current power of the associated tower/lounge
• daily-energy: returns the amount of power used by a tower/lounge on a certain day
• energy-since: returns the total amount of power used by a tower/lounge since a certain day
• rank-towers: ranks towers by energy usage over a certain period of time

Having done the wattdepot katas before this project, these all seemed rather simple to implement. On our own these would probably take no more than a week to figure out. But that wasn't the case this time around, as we had to coordinate with each other and split up the work accordingly.

I was paired up with Micah and Jesse, two people who I previously worked with in earlier classes but had not really interacted with beyond that.  Though thinking back now, even throughout this whole project we didn't really communicate outside of a colleage/group-member capacity, although it was refreshing to bounce ideas off one another and come up with different ways to approach this project, as opposed to going at it alone.

A major resource in group projects that we had sort-of dabbled in earlier but not fully utilized is google project hosting, a sort of hub for contributors to download and update their project. A new approach that we took to getting the work done was something called issue driven project management, where the project is split into issues, which are then divided up among the group members to address. Upon gradual completion of issues, the group member would commit their build to the website, and update the page where the issues were so as to let the whole group know their progress.

Our code website can be found here: http://code.google.com/p/hale-aloha-cli-kmj/

So after getting all the groundwork done, creating stub classes and setting up our project on google project hosting and connecting it to jenkins which would check our builds, we set off eager to do our parts. Unfortunately, nothing really materialized in the first six days of the project due to various circumstances (homework,  exams, procrastination, etc.) Our first in-progress review came one unsuspecting Tuesday, and when we got our evaluations back, they were simply-put, abysmal.  Six days and hardly anything to show for it.  Though judging by the professor's decision to later on nix the scores, there must have been a lot of other groups who hadn't made much progress.  Though after that scare we resolved to work much harder than earlier.

Coming up to the deadline we came across some unforseen roadblocks, the most important one being that the wattdepot-server was down. Without that, we were pretty much dead in the water, as we couldn't test any of our code and had no way of knowing if anything we were writing would work. Fortunately, our deadline was pushed back one week and we had some breathing room to further work on the code.

Up until the submission there were a couple of issues, two of which come to mind. The first one being that me, usually going through projects at my own pace, sort of threw off the timing of the group, meaning that it was hard to move on without my pieces of the project. This resulted in a loss of productivity and me staying up the entire night before the deadline in order to get anything done. The second issue, which is probably a by-product of the first, is that we had some compatibility issues with our code when we combined them. I was responsible for the commandParser, the thing that checks user-input and then invokes the commands, but since we all had different requirements for our commands, it took some working-around in order to resolve. But after a long-night of coding and looking things up online, it all was finally resolved.

So we come to the end of our first group project, and I must say that I'm exhausted. Though as much as I'd like to think that it's done and finished, we've only reached version 1.0 (or maybe not even that far, depending on how the reviews turn out :/), and it looks like there's still a ways to go.  Though coming this far having worked in a team, I think resulted in a lot more valuable experience gained than if I had gone at it alone.

edit: forgot to add link to hosting website, added link

Energy!

A bit of a drastic change from the last couple of topics we've been covering, today we will be going over energy and energy consumption in Hawaii. Now what exactly does this have to do with software engineering, you might ask? I know I did. We'll attempt to get down to that question in a bit, but first, a little background about energy consumption in Hawaii.

Because of Hawaii's unique location and environment, in terms of energy consumption it is different from the rest of the US in many ways, some of them good, and a lot of them not so good.  Because Hawaii consists of a cluster of small islands located in the middle of the pacific ocean, it means that local resources are scarce, so we must import all, if not most of our energy from overseas.  As a result, gas prices are the highest in the nation, thanks in part to import costs.  Other areas in the US have the luxury of being able to depend on a wide variety of resources for energy consumption, like coal, natural gas, and whatnot, because the resources are readily available. However, here in the Pacific, roughly 75 percent of our energy production depends solely on imported oil, which makes for a pretty expensive process.

Fortunately, while lacking in some areas, there are other environmental factors that Hawaii has going for it in terms of energy. That is, an abundance of natural energy sources throughout the islands.  Since it is pretty much tropical weather all year round, there is a high exposure to sunlight, thus solar power is an especially effective way of gaining energy.  Also, especially-strong trade-winds make Hawaii an ideal place for harvesting wind-energy. Along with other resources including hydro-electric energy and geo-thermal energy, Hawaii has the potential to become 100% self-sufficient in it's energy production and consumption.

Unfortunately, despite this potential and the opportunity to become energy self-sufficient, there are many drawbacks and obstacles in the way.  For one, the costs of overhauling the current energy infrastructure and installing renewable energy-harvesting devices are uneconomical at this point in time.  A lot of people trying to make ends meet month-to-month aren't too thrilled about having to pay higher energy bills.  However, what most people don't realize is that if the infrastructure, which is decades old, is not updated, and new energy sources aren't utilized, then at the rate we're going, electricity is going to become a lot more expensive in the future. Gas prices have been increasing for a while with no signs of stopping, and as a result our electricity bills, a product of mostly imported oil, will also rise as well.  It's either start paying more now for cheaper and sustainable energy in the future, or let it go and wind up paying gradually higher and higher prices for energy later. But like all things, it's difficult to get a large number of people to start thinking about something in the long term.

In addition to that, the question of where would these installations be built is another big issue.  Hawaii, being a bunch of small islands, doesn't really have a lot of free space, so unlike the mainland, we can't simply go out into the desert and deploy a square-kilometer of solar panels.  Regarding wind power, a lot of people are opposed to having windmills installed on the tops of mountains, as it takes away from the natural beauty of the islands.  Additionally, the areas in Hawaii with the highest potential for wind energy harvest are near the smaller, less populated islands.  However, it's Honolulu, the big city, that has the highest power demands.  The idea of having a bunch of windmills built in one's backyard to help power someone else's home doesn't really sit well with a lot of islanders from the smaller isles.  Thus, until these problems can be reconciled, it's going to be a tough journey to get Hawaii self-sufficient.

So getting back to the question, what does this all have to do with software engineering? With regards to the power grid, the network of energy that distributes power to all homes in the islands, information harvesting regarding usage is becoming an increasingly important factor in the way things work.  With this information, engineers can figure out usage at certain times, what areas need more energy or what areas could do with less, and how to effectively distribute energy in such a way that does not result in wasted power and that conserves an already limited resource. The future of energy distribution and consumption will lie heavily on the quality of the software engineers working to improve the process.

Online Project Hosting!

Ever run into those situations when you've been put into a group and everyone's working on different parts of the same project, and then you run into problems trying to combine it all? For example, a component that one person took hours to edit being replaced with an unedited version from another group member, or certain parts of a project just magically 'disappearing', sound familiar? Well, for all those unfortunate souls that go through these lapses in communication, the all-powerful Google has a solution to your problems.

Google Project Hosting, which can be found here, is an online space where you and other collaborators can access and make changes to the group's project. A handful of useful tools for collaboration are provided, including an 'Updates' page that automatically shows when and where an update has taken place, a list of all members involved in the project, a wiki where instructions for files and other valuable information may be added, an 'Issues' page for posting problems regarding the project, and many other utilities.

With regards to handling different versions of files and updates, Google makes use of many different types of software designed to handle file revisions and controls, however with regards to this project, the software that we are using is called Subversion, which does a really good job at making sure every member is on the same page, and is considered an industry standard for collaborative programming. Basically, there is a master copy of the project, in this case the instance hosted on Google project hosting, and all members have a copy of that master copy in a folder on their computer.  When one makes changes or additions, one uses a Subversion client and "commits" their copy to the master copy, or in other words, replaces the master copy with their own copy.  Of course, before doing this it would be wise to make sure that the version you plan to upload does not have any errors in it and plays nicely with other components of the project, lest everyone be stuck with a faulty master copy. The Subversion client I used for this project is called TortoiseSVN, a free client that can be found here.

The site I created for this project can be found here: http://code.google.com/p/robocode-ari-dontshootihavecake/

Our objectives for this project were to create a hosting space using Google Project Hosting, where we would upload the code for our competitive robot. Setup didn't take long at all, and after entering basic information the site was successfully set up. The next step was installing TortoiseSVN, which didn't take too long either.  Unlike the SVN client for Macs which was featured in our class screen-cast and had a dedicated GUI for operations, Tortoise worked directly through the file directory, and was fairly intuitive to use. Before uploading my robot to the site, I had to make sure that my robot was working properly, and using apache ANT to verify my robot, once I made sure my robot would work, I created a fresh distribution and once putting it into the special folder on my computer for this site, I used Tortoise to commit my files to the online hosting space. This took a matter of seconds and was relatively hassle-free.

Upon uploading my files, I looked around the site and noticed that my actions were promptly noted within the 'Updates' and 'Changes' sections, easily visible to other collaborators. Looking in the 'Source' section of the website, I saw a directory containing all of the files from my distribution, which can also be seen by other members.

After getting acquainted with Google Project Hosting and Subversion software, I must say that this makes it a lot easier to collaborate with others on group projects, and is less of a hassle then having to email individual files or drag-and-drop out of flash drives. My experiences with these tools went pretty smooth, and I would definitely use them when working in groups on codes (Which I have a feeling we might have to in the future).

Let's mess around with ANT!

On our continuous journey through the glamorous and exciting world of software engineering, we come across another valuable programming tool, which goes by the name of ANT. And yes, while those tiny insects that scrounge the earth may come to mind upon hearing this name, it's actually an acronym standing for "Another Neat Tool". So the whole insect thing was actually just an afterthought, as it turns out. Anyways, so what exactly does this ANT do? Well simply put, it's an Apache-built automated software build tool, which given the right commands, can automatically compile java files, alter directories, grab updates and modules and whatnot from the internet and place them in the proper system directories on your computer, and that's just the tip of the iceberg. It's as if it gives you the power of an ant-whisperer of sorts, where you tell the ants what you want to be done and they just all go off and do what you told them to do. For more fun facts on ANT, here you go.

In order to get our feet wet with ANT, we were assigned 8 little katas to figure out and compile. Some took more time than others, but for the most part they were all relatively straight-forward.  In order to complete these katas, we had to make various build files, which were to be done in XML(ANT uses xml files to execute commands and whatnot). Although lacking in prior experience with the language, the resources provided online, including the apache ant website and tutorials pages proved to be of great assistance in helping me to get off the ground.

There are a couple of special things about ANT that I noticed while going through the katas. Why some of these things are present in ANT I do not know, but they're just things that you're going to have to get used to. For example, properties, which can be thought of as variables, are immutable in ANT, meaning that once you've declared something, you can't change the value, which was the point of one of the katas.

Another interesting feature of ANT is dependencies, which are pretty much what targets, which can be thought of as methods, need to do in order for them to run. For example, if I had a target="foo" that had a dependency on another target="bar", denoted by depends="bar", that means that in order for "foo" to run, "bar" must first be run. Even though the code for "foo" might be written before the code for "bar", when compiled, "bar" is run first, followed by "foo". It's a pretty interesting feature of ANT.

Another thing that ANT allows you to do is to run features from JAVA from within ANT. This includes compiling java files, running java files, and even generating javadocs, all of which were some of the katas assigned.  In order for ANT to be able to use the features from java, however, it's important to make sure that java is properly installed on your computer, and that all your environmental variables are inputted correctly.  This proved to be a minor setback for me completing all of the katas, but eventually I was able to find the errors and fix them accordingly.

Well, that just about sums up my experiences with ANT thus far, and my impressions thus far is that it's a pretty powerful development tool to use, and if done right, it can make one's job as a software developer a lot less difficult.

Robocode!

For this week's program we've been dabbling with a little something called robocode, and as the name implies, yes, there are robots involved! Unfortunately however, it's all within a computer simulation, so my hopes of pitting customized roomba bots against each other in a fight to the death will have to wait for now.

Simply put, robocode is a game where you can program custom robots and then put them in a virtual arena where they do battle with other robots until the last one stands. Robots have three basic functions; movement, firing, and detection of other robots, and although that may not seem like a lot, you have the whole java arsenal at your disposal to customize how a robot moves, how it reacts to other enemies, and a multitude of other things. From dancing in sine curves around your enemy to doing a little victory dance when you've destroyed an opponent, the sky's the limit with how detailed and intricate you can get. Robots can be programmed in either java or .NET, but for the purposes of this project java will be exclusively used.  For those of you who wish for a more detailed explanation of the wonderful world of robocode, here you go.

I must say that it was a bit difficult at first to get my homemade robots actually working, but after looking over many tutorials and reading through the robowiki, I was able to make a bot that could move around, and eventually destroy other bots.  The great thing about robocode is that there is a pretty sizable community, with a multitude of resources including tutorials, explanations, forums and whatnot, something for people of all skill-levels.

Programming knowledge aside however, honestly I'd say the most difficult part of robocode is using trigonometry. Of course, it is by no means mandated that you use trig in order to move around your robot, but without it your code is going to be a lot longer and you're going to have find a lot of workarounds in order to get your robot to do what you want it to do. For example, when locking on to a coordinate, you have to take into account the current angle the robot is facing and the position of the coordinate relative to that robot, calculate the slope and convert that to degrees, then get the robot to face that position and then calculate the distance to determine how far to send the robot. Doing that without trigonometry, you're gonna have a hard time finding those calculations.  I personally spent a good 3 to 4 hours trying to come up with a sufficient formula to calculate angles, but not being the trig-whiz I once was in high school, I was unable to figure it out myself.  Fortunately however, with help from my good friend the internet, I was able to find a method from a bot that did the exact same thing, and with some slight modifications to the code I was able to implement the function within my robot (properly cited in my code, of course). Right there is another great thing about robocode, you are able to take things you like from other robots and add them to your own, and for the most part it's easily compatible, because all robots are an extension of just one of two classes, Robot or AdvancedRobot.

We were tasked with making a grand total of 13 robots, each with their own specific function. From doing nothing, to travelling in a spiral, to following other robots, to shooting all robots, in all they all pretty much cover the basics of robot movement and action.  I was able to complete 12 of the 13 robots, the only one left undone being a bot that tracks another robot with it's gun but does not fire.

Having gotten my feet wet with robocode, I feel that I'm a bit more familiar with the way these robots function. It's easy to pick up, but underneath that simplicity there's just so much depth and so much you're able to do with these robots, that in order to master it, it's gonna take a while. It was really helpful that the project was divided into bots with incremental steps in complexity, so that when you completed one robot you gained insight as to how to program other robots. I'm better off than I was when I started this project, but of course, there's still a long way to go in order to "build the best, destroy the rest!"

Seeing as how the next project involving robocode will be to create a competitive robot and facing off against classmates, I have a feeling that it's definitely going to be harder than fighting with practice bots that just stay still and don't fire at you. It's really going to be important to be mindful of a bunch of factors in order to build a robot that can survive in the arena, things such as ammo depletion, turning direction, trajectory and so on. I know I already have some ideas for my robot (none of which I shall disclose at this time), and am looking forward to programming it in to my robot and pitting it up against my classmates in the upcoming weeks.

Well that just about sums up my experiences with robocode thus far, and I'm sure there's plenty more to come down the line. For those of you who are interested in robots, or just improving your programming skills, I would definitely recommend dabbling in robocode, just to see how far and how skilled you can become.