Streaming binary file from http response up to AWS S3 with Node.js

Recently, I found myself needing to take images from a remote source and copying them to an Amazon S3 bucket to be used by a client website. Initially, the task seems simple enough... for each image:

1. Send GET request to remote source for image
2. Write response onto webserver as file
3. Read file and upload to S3

Although each image would simply overwrite the previous one on the webserver, there really isn't a need for any additional disk writing to the webserver, since the end goal is only to copy the images up to S3:

1. Send GET request to remote source for image
2. Forward response to S3

The concept is fairly trivial, but still took me a good amount of time to nail down due to a bit of a quirk I wasn't aware of with the Node.js Request module.  The modules used:

• request
• aws-sdk

The biggest gotcha here was that the request module expects a String in the response body by default. To make sure the response stream is kept as raw bytes, the request should be considered to use null as the encoding . Related code:

I've only tried this so far with images, but it should work with just about any small file. Unfortunately, I am uncertain about how well this works with a large file, where memory issues may arise. Obviously, the code will need to be tweaked to fit your needs.

INTELLIsense? I think not...

I am ashamed. These blog posts are getting few and far beyond and certainly shorter and shorter. However, here's a short and sweet tip for those of us that work on occasion with MS Sql Server.

IntelliSense is often useful for getting at those pesky tables with long names -- if not for the auto-complete function, at least verifying that certain tables or columns exist certainly helps. However, this is predicated on the fact that the IntelliSense cache is not being.. cachey. For example, when a table structure is changed and for one reason or another, IntelliSense refuses to acknowledge the existence of, let's say, a new column. What can we do? Refresh the cache of course!

 There are two ways to refresh the cache:

1. Go to Edit -> IntelliSense -> Refresh Local Cache and
2. Hit Ctrl+Shift+R

Maybe I'll start doing some basic posts about jQuery, CSS and basic DOM navigation in the future. But, until next time...

Source: Dan's Blog

When there is no time for Sametime

Short entry here but possibly useful for anyone who needs to use Lotus Notes but never uses any of the Sametime features. As someone fits the above criteria, I found it to be quite the irritation that, despite my efforts to disable Sametime, the tray icon nevertheless insisted on making an appearance. As it turns out, to remove the icon from the tray while your Notes client is launched, you have to edit a *.ini file. Here are the instructions:

1. Edit the plugin_customization.ini file in Notes : at c:\Program Files\lotus\notes\framework\rcp\plugin_customization.ini or c:\notes\framework\rcp\plugin_customization.ini

2. Add the following line: com.ibm.collaboration.realtime.application/useSystemTray=false

Once this is done, close Notes and launch it again. This should work.

I actually found my plugin_customization.ini file at c:\Program Files (x86)\IBM\Notes\framework\rcp\ but it's expected that there's some varying between systems (naturally). Anyway, following these steps worked like a charm for me, so it should for you too, making your system tray just a little bit cleaner.

Source

Hale Aloha CLI: Part 2: Revenge of Hash: The second coming v2.0

Previously, on "Trials and Tribulations" - Command-line interface hale-aloha-cli-hash was tapped for inspection (episode recap). Critics (me) of Team hash's command-line phenom raved about the tool, saying that it "does indeed accomplish a useful task" and that the team "did an admirable job". But the tool was not only met with gold stars and sunshine as the very same critics (still me) mercilessly pointed out that the application was "not without its flaws".

This episode is brought to you with no further commercial interruption by yours truly.

Strangely enough, although we still refer to Team hash as the trio of developers who were responsible for the genesis of hale-aloha-cli-hash, a twist of fate intervened and alas, the project that I had extensively reviewed previously suddenly landed within my domain of responsibility. Due to the nature of the Hale-Aloha-CLI project, the rationale behind Team chair suddenly taking over the hash project was sound. Often, a piece of software is written with a certain approach, design and frame of mind. These concepts, however, often belong exclusively to the originators of the software. In open-source development, it is important to keep new developers in mind, and since the objective behind the Hale-Aloha-CLI project was to create a user interface which was modular enough for new developers to add additional commands, it made good sense for our two teams to switch our development focus to each others' projects.

Although I had performed a fairly in depth review of hale-aloha-cli-hash in my previous entry, it became obvious that a hands-on experience was going to reveal so much more as soon as I began to start implementing a new command. Before I go any further, here is the project page for hale-aloha-cli-hash and you'll note that the system now accepts 3 new commands: set-baseline, monitor-power and monitor-goal.

All in all, the design of the system was pretty intuitive, all the code for execution of commands were together and all the code for argument checking were found together and so forth. The biggest challenge, initially, was fully understanding the thought process of the previous developers. There was a Java interface in the project, which I initially heralded as being uniquely dissimilar to the hale-aloha-cli-chair implementation. Unfortunately, upon further investigation, I found that the developers may have misinterpreted the reasoning for the interface to exist in the first place.

For some of you out there, it may behoove you to know that an interface acts sort of like a blueprint. It lays out the basic frameworks for building something, in this case a Command. After adhering to the basic frameworks, it then becomes the developer's prerogative to embellish and add functionality to the Command to make it unique and useful, as long as the basic framework remains the same. Interfaces, in terms of Java, define methods that have to exist for every class which implements it. However, in hale-aloha-cli-hash, the interface defines every version of existing commands and the only class which implements the interface is responsible for executing the different commands. What this means is that the interface becomes a blueprint that is used only once which, in this case, defeats the purpose of drawing one out in the first place. Secondly, due to this fact, every time a new command is added to the interface, it has to also be added to the execution class. It quickly became a little unwieldy to keep track of all the changes that had to be made to existing code in order to add a single command.

However, the real challenge was again in working with group members. It is certainly understandable that most members, if not all of us, had other big responsibilities looming on the horizon but it wasn't until the project deadline was starting to peak over the mountains to cast its oppressing rays upon the group that our lines of communication really fired up. I tried to pick up one of the more unique commands: monitor-power as my primary issue for version 2.0 of hale-aloha-cli-hash because it involved a bit of thread use (which I was interested in) and it served as a takeoff point for the monitor-goal command. What I found out soon after, however, was that monitor-goal was even more so dependent on the existence, or at least an abstract conceptual mock-up of the set-baseline command. Due to the division of labor that we had settled on as a group, this meant that if one command was delayed, it had the potential to delay another command from being made as well.

This was especially evident as the set-baseline command was not fully incorporated into the system until recently, and thus the monitor-goal command had be stalled in its production a bit. In the umpteenth hour, however, my team and I were able to roll out a working product. Given the fact that we were building our system on top of a previous developer's system, I thought that we did a tremendous job overall of adapting our mindsets to accommodate for the different design. One of the few downsides to this, I found, was that I caught myself essentially assimilating the style of the previous group, and was digressing from my own coding style. This is not necessarily a bad thing, but being a chameleon when dealing with poorly written code can prove to be a problem in the future.

I do not mean to boast here but to simply make an observation based on the facts as I perceive them. The previous developers of hale-aloha-cli-hash created a system that did satisfy the three Prime Directives of software engineering, but I strongly believe that hale-aloha-cli-chair's design was more intuitive for developers. Of course, this is not to say that hale-aloha-cli-hash no longer meets the third Prime Directive, but that we may have taken the third directive more to heart in our inception of hale-aloha-cli-chair. If nothing else, this should be a learning experience for everyone in that while it is important to have a functional product, you can never spend enough time mulling over and designing the architecture of your system from the ground up.

In the end, I am still a huge fan of Issue Driven Project Management because I believe that under the right circumstances, it can complement and expedite the development process tremendously. Despite some of the communication issues and some last ditch efforts to get things working, IDPM still did help our collaborative efforts along as a group in the end. The experience of taking over hale-aloha-cli-hash was one of the most unique experiences in my software engineering career and it was invaluable in the lessons it taught me and although the project is not without its bugs and flaws (some existing from the previous development team, while many others were introduced by our current team), I feel pretty good about the project experience overall and I look forward to a fruitful future of similar challenges!

As a final cautionary note, this may be the season finale of "Trials and Tribulations" but rest assured that I am fighting for the networks to renew it for many more to come!

Hale Aloha CLI Spotlight: Hash

My previous blog was clouded by frustration, and I admit that I left out crucial components. For example, for an entry about my experiences with Issue Driven Project Management, I all but neglected to touch upon what IDPM entailed at all. Even more to my shame, I hadn't mentioned that our project was called hale-aloha-cli-chair even once. I promise to try and make up for my previous deficiencies here while attempting to be concise enough to get to the point of this entry: a technical review of our sister (brother?) project, hale-aloha-cli-hash (You'll note, of course, the similarities in the project names).

Both the hale-aloha-cli-chair and hale-aloha-cli-hash projects set out to accomplish the same goal: a Java based implementation of a Command Line Interface which provides its users a functional way of interacting with WattDepot energy data from the Hale Aloha student residence towers on the campus of the University of Hawaii at Manoa. In this implementation, both our teams set out to design an open source system which has six commands built-in: help, quit, current-power, daily-energy, energy-since and rank-towers. For a more in depth description of the commands' functionality, I present to you the project page for hale-aloha-cli-chair.

If you'll recall from my first blog entry, the all-encompassing goal of open source software boils down to a useful application for users and a higher level of effectiveness in allowing developers from anywhere contribute with relative ease. Thus, I reiterate here once again, for your convenience, the three Prime Directives of open source software engineering:

Prime Directive #1: The system successfully accomplishes a useful task.
Prime Directive #2: An external user can successfully install and use the system.
Prime Directive #3: An external developer can successfully understand and enhance the system.

However, whereas the previous review of the open source project aTune was a mere glance at a well-established application, I am now in an unique position where I am able to test and review an early version of hale-aloha-cli-hash to which I will have access to all of the quality assurance tools the hash team was using as well as a general insight into their goals as I analyze their source code and architecture in depth.

I would be remiss, however, if I didn't do my due diligence and lay down a better picture of the general approach to the project that both the chair and hash teams took towards the Command Line Interface implementation. To be brief, the project consists of energy usage by students in the Hale Aloha towers being recorded by sensors which communicate its data to a WattDepot database which allows the Command Line Interfaces to retrieve relevant energy data to display to the user of the CLI.

OK, you caught me, those are not WattDepot servers, but look how happy that user is with the CLI!

To learn a bit more about how WattDepot can be interacted with, see my previous blog entry regarding my initial experience with WattDepot. From a user's perspective, this is a more than sufficient information to begin using the CLI. However, from a developer's standpoint, there are a few more objectives in the CLI implementation. First of all, both of these CLI project are managed by an Issue Driven Project Management system and are under Continuous Integration.

For your experienced developer, these concepts may not be a shock at all, but for those of you who are new to software development or are simply interested in educating yourselves, both of these processes are tools which aid a development team in achieving efficient collaboration. Issue Driven Project Management, or IDPM, is a means of managing a project by creating simple, uncomplicated issues which can be resolved in a short span of time. What this allows a project team to do is to create a large quantity of small tasks for its team members to draw upon so that they will always have something to work on at their pace. Since the issues are quickly resolved, IDPM also requires that the team members put their heads together frequently to generate more issues so that their resources (read: developers) are never idle. In supplementing IDPM, there are a number of automated quality assurance tools that are required for successful development of the CLIs as well. These assurance tools allow for a concept called continuous integration.

When multiple developers are working on a project concurrently, there is bound to be an integration issue. Even though developers may be working on separate issues, they may end up modifying something similar and conflict with one another's work. What continuous integration does is not to prevent these conflicts from happening but to make certain that the conflicts can be quickly resolved. If developers are committing their changes to the shared repository with a higher frequency, the amount of modification to overcome when a conflict occurs is going to be smaller. This means that in order for continuous integration to work, changes made by a developer must automatically be checked for errors by quality assurance tools and each developer must make small but frequent commits to the repository.

Armed now with this barrage of conceptual knowledge, I invite you now to cruise alongside me as I walk through my technical review of hale-aloha-cli-chair's sister brother sibling project: hale-aloha-cli-hash. Keep in mind, once again, that the big picture is to make sure that the hash team was able to satisfy the three Prime Directives of open source software engineering.

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

To answer this question, I first went to the hale-aloha-cli-hash project page where I was able to download the latest distribution of the project.

I first ran through the system using correct input values:

E:\Downloads>java -jar hale-aloha-cli-hash.jar
Connected successfully to: http://server.wattdepot.org:8190/wattdepot/

>
help
Here are the available commands for this system.
current-power [tower | lounge]
Returns the current power in kW for the associated tower or lounge.
daily-energy [tower | lounge] [date]
Returns the energy in kWh used by the tower or lounge for the specified date (yy
yy-mm-dd).
energy-since [tower | lounge] [date]
Returns the energy used since the date (yyyy-mm-dd) to now.
rank-towers [start] [end]
Returns a list in sorted order from least to most energy consumed between the [s
tart] and [end] date (yyyy-mm-dd)
quit
Terminates execution
Note: towers are: Mokihana, Ilima, Lehua, Lokelani
Lounges are the tower names followed by a "-" followed by one of A, B, C, D, E.
For example, Mokihana-A.
>
current-power Ilima
Ilima's power as of 2011-12-01 was 27.439735792375984 kW
>
daily-energy Ilima 2011-11-30
Ilima's energy consumption for 2011-11-30 was: 664.6056753929341 kWh
>
energy-since Ilima 2011-11-25
Total energy consumed by Ilima from 2011-11-25 to 2011-12-01 is: 3951.9046231694
37 kWh
>
rank-towers 2011-11-25 2011-11-30
Enter dates as YYYY-MM-DD
Older data may not be valid.
Command was not processed, please check for correct arguments
>
rank-towers 2011-11-25 2011-11-30
Source For the interval 2011-11-25, 2011-11-30 energy consumption by tower was:
Mokihana-06-telco 126 kWh
Lokelani-08-telco 131 kWh
... (truncated for the blog entry's sake)
Ilima 3601 kWh
Lokelani 4172 kWh
>
quit

Of the six commands the CLI is supposed to have implemented:
> help: provided a helpful message explaining the usage.
>current-power: implemented and functional.
>daily-energy: implemented and functional.
>energy-since: implemented and functional.
> rank-towers: implemented but for gave errors at times even with correct input. Also ranks towers AND lounges instead of just towers, but this is more of a design choice than a problem.
>quit: exited the system cleanly.

All of the intended functionality of the project were implemented and working. Although the rank-towers command did not always properly execute, the system is still overall useful and it is fair to say that, although it is not without bugs/flaws, hale-aloha-cli-hash does indeed accomplish a useful task.

Prime Directive #2: An external user cans uccessfully install and use the system.

In order for the project to allow an external user to successfully install and use the system, there ought to be some features about both the project itself and the project homepage which provides guidance for the average user who may not know much about software development. There were several questions I asked myself in order to determine if the hash team was successful in conveying this user-friendliness.

> The project homepage provides an overview of the purpose of the application and briefly lists the available commands.
> There is a User Guide wiki page featured on the project homepage which describes how to download, install and execute the system. The wiki also lists the available commands again, and a more detailed description of each command.
> The downloadable distribution includes an executable jar (the execution of which was seen up above) which means the user doesn't have to know how to compile and build the system in order to use it.
> The system version number is clearly attached to the project distribution and users can easily use this to keep track of the which evolution of the system they are using.

In addition to the valid inputs above, I also tested the system with invalid inputs.

E:\Downloads>java -jar hale-aloha-cli-hash.jar
Connected successfully to: http://server.wattdepot.org:8190/wattdepot/

>
hello world
Invalid Command
>
HELP
Invalid Command
>
current-power
Invalid Number of Inputs
>
current-power foo
Command was not processed, please check for correct arguments
>
current-power 1 2
Invalid Number of Inputs
>
daily-energy foo bar
Error occured while running daily-energy.
Command was not processed, please check for correct arguments
>
daily-energy Ilima foo
Error occured while running daily-energy.
Command was not processed, please check for correct arguments
>
daily-energy Ilima 11-25-2011
Error occured while running daily-energy.
Command was not processed, please check for correct arguments
>
daily-energy Ilima 2012-11-25
Error occured while running daily-energy.
Command was not processed, please check for correct arguments
>
daily-energy Ilima 2011/11/25
Ilima's energy consumption for 2011/11/25 was: 548.7930279141283 kWh
>
current-power foo
Command was not processed, please check for correct arguments
>
rank-towers 2011-11-25 2011-13-25
Enter dates as YYYY-MM-DD
Older data may not be valid.
Command was not processed, please check for correct arguments
>
exit
Invalid Command
>
quit

Judging from the reasoning behind the invalid inputs, it was clear that in general, invalid inputs are broken up into three categories: unrecognized commands, incorrect number of arguments and everything else being simply errors occurring along with a helpful hint of what the user may have done wrong to illicit the error. Surprisingly, the CLI accepted my input of 2011/11/25 which is not necessarily a bad thing. The only reason this raises an eyebrow is because the hash team simply chose to disregard the the delimiters so an input such as 2011111225 (perhaps due to an inexperienced typist) will still be accepted and there may be some combination here which gives the incorrect date. However, here is the rundown of invalid inputs I tried:

> Completely invalid command was recognized as an invalid command.
> Upper case version of an available command was recognized as an invalid command.
> Invalid number of arguments (too many or too little) handled well and lets users know of the problem.
> Invalid arguments handled well but generally provides a general message as to why an error occurred (this is, again, more of a design choice than a problem).
> Strange delimiters for dates will be accepted as long as they are one character long.

Given that hale-aloha-cli-hash provided users a simple documentation of how to get up and running and continued to guide them throughout the usage of the CLI, I would say that the hash team did an admirable job of satisfying the second Prime Directive. As an external user of this application, I believe I would be capable of following the User Guide wiki and understand what the CLI is capable of from both the documentation and the built-in guidance that the application provides.

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

Here is where the distinction between open source software and other software really shows up. This CLI implementation as well as our own does not only need to be useful to users and usable by users, but also expandable and modifiable by other developers. The goal of this project is to create a CLI with 4 built in commands for interacting with WattDepot energy data. However, it's also very important to note that, since WattDepot has so much other data available, it would be prudent to allow the CLI to be extensible with more commands. In determining whether the CLI created by the hash team does indeed allow for an external developer to easily enhance the system, I asked myself several questions to this end as well.

First, I investigated the project's homepage for some insight into the project and for hints on how to get started.

> A Developer's Guide wiki page was featured on the front page.
> The guide provided clear instructions on how to build the system from source files.
> The guide indicated the quality assurance standards being followed by the project.
> The guide provided some tips on how a developer might try to adhere to those quality assurance standards.
> The guide provided references to coding standards being followed.
> The guide mentions that the project is issue driven and explains how to partake in the project through creation of issues.
> The system is under Continuous Integration and the guide provides a link to the CI server associated with the project.
> The guide also explains how JavaDoc documentation can be easily generated.

Since the wiki page was very well done and provided a good insight into the development process, I felt confident with taking the next steps towards contributing to the project. I was able to check out the sources from SVN (recall my previous entry explaining the advantages of SVN) and generate the JavaDoc documentation for my perusal very easily. Regarding the JavaDocs themselves, I gained even further insight into the project.

> From viewing just the JavaDocs, I was able to gain a decent understanding of the system's architecture and the its components.
> For the most part, the naming scheme of the components were very intuitive and clearly indicated their underlying purpose with the exception of the existence of both a Node and Nod class. I was able to ascertain what a Node class probably does, but it seemed like the Nod class performed roughly the same duties. The name of the class being "Nod" was also a bit odd but this was just a small problem that I could certainly live with.
> The system is designed to support information hiding and uses the protected keyword so restrict access of certain methods to only those within the package. This is likely done to facilitate JUnit testing but also offers other advantages like being extensible.

After generating the JavaDocs, I was then able to build the system and generate test coverage information regarding the system using JaCoCo. Using this information and a review of the testing source code, I was able to determine that the existing set of the test cases were implemented rationally and does a good job of preventing new developers from making enhancements that can break the pre-existing code. In this analysis process, I was also able to gain a further insight into the hash team's reasoning behind certain design choices. In addition to reviewing the test case source code, I also reviewed the actual implementation source code as well. To this end, I found several more good qualities about the hash team's code.

> Java coding standards were followed.
> Comments were sprinkled throughout the code appropriately, giving new developers clues and explanations regarding existing code.
> The code is easy to understand and the comments were neither too sparse nor too overwhelming.

Since the project was under continuous integration, I also checked the CI server associated with the project to draw some conclusions about the consistency of the hash team's development process.

> Although there were build failures, indicating that a developer may have failed to verify the build prior to committing to the repository, the failures were always corrected promptly.
> The system was worked on in a consistent fashion, and commits from developers were done very frequently.
> Most of the commits made to the repository were associated with an appropriate issue, with the exception of a few quick fixes here and there.

Finally, although this does not really have a huge relevance (it is relevant, just not hugely so) on the third Prime Directive, I was curious to see how the system was contributed upon by its three individual developers. To this end, I reviewed the team's project page and analyzed the Issues page associated.

> It was evident which parts of the system were worked on by each developer.
> Based on the Issues page, it is apparently who I need to talk to if I had a question regarding a certain part of the system or its behavior.
> Even with just a simple glance at the Issues page, it becomes glaringly obvious that one particular developer contributed significantly less than the other two. Whereas developers BrysonYHori and mitchell.kupfer seemed to have implemented the majority, if not all of the system, developer macmillan.johnw contributed only two fixes to the project which, based on the Issues, were relatively minor and done in a single day's time frame.

Although hale-aloha-cli-hash is not without its flaws here, it is clear that a strong effort was made from the inception of this project to create a modular system which is open to external developers. From the project's homepage to the source code documentation and even the team's own striving for excellence in adhering to their coding standards, it is clear that this project is one that satisfies the third Prime Directive of open source software engineering. It is a shame that of the three developers on the team, there was an evident imbalance in contribution and effort but, once again, that does not factor into my analysis of the project's adherence to its goals at all.

Hale Aloha CLI CHAIR Project Page
Hale Aloha CLI hash Project Page

Trials and Tribulations of Computers and Sciences

I'll be frank. This post is not going to be pretty, elegant or overall very fun to read. This is not your fault, readers. I am not punishing you. In fact, this particular entry is being written as a response to a software development project that I was recently and currently involved in. Unfortunately, until 7 hours ago, the project was, more or less, not fully implemented and thus there was a bit of difficulty in gathering my final thoughts on the ultimate experience I wanted to convey.

To be brief, the project's inconsistency most likely stemmed from a difficulty in facilitating an effective line of communication between our team members, likely due to the fact that we are all current college students with too much on our plates and too little time in the day. However, this ultimately resulted in quite a bit of "last minute heroics". I have to admit, I am largely to blame. At the inception of the project, I was full of optimism and may have unwittingly assumed a role of leadership I was not necessarily willing to be in. As a result, as my initial barrage of Emails missed their marks, I let my own failure to "rile up the troops", so to speak, get to me. As a result, my own enthusiasm for the project diminished significantly and now I sit before you in confession of having given up even before the "last minute heroics".

Overall, my experience of issue driven project management was hectic. In theory, it sounds like an amazingly streamlined and intuitive way of solving the project management problem. However, in practice, if project members are unable to communicate effectively, the entire process completely deteriorates. This is, of course, not the problem of the design of the concept but rather a problem with the people trying to take advantage of the process. At times, it seemed like a big hassle to create an issue just to work on something but, again, this problem arises only due to a lack of consistent group meetings.

The command-line interface our group has implemented is fully functional and includes four commands for the users to interact with the WattDepot data energy at the Hale Aloha towers on the UH campus. Our design allows for the project's main execution to only create a processor, which then essentially takes over. In retrospect, having the main method exist outside of the processor is probably unnecessary, but in the spirit of keeping things modular, this was the design choice we made. The processor then explicitly "gathers" commands in a HashMap. Although I say "gathers" here, our implementation actually requires that we hard-code the existence of these commands into the processor. However, barring adding a couple of lines to the class, the system is modular and adaptable to accept additional commands.

Although I feel like the overall quality of the project is pretty good and is something I can reflect on and take some pride in, I am certain that, in the past 7 hours (6 of which I was asleep for), there was a significant amount of testing done to the completed project as a whole. Additionally, I found it really troublesome to write JUnit test cases for many of the classes I implemented, due to functionality conflicts like void methods or the infinite loop which drives the command-line interface. I was able to get fairly decent test coverage on the classes by making them more modular and testable but I am still very reluctant to say that the tests were "good". This perception does not, however, factor in ease of development for new developers, ease of use for users or even if the project can be successfully distributed because, again, despite having waited to the last minute, I ran out of time to fully test these requirements.

Introduction to WhatDepot?

In my last post, I intended to bring to everyone's attention the energy situation in Hawaii and how, in the midst of a unique problem, there are unique solutions. I also touched upon the fact that there exist numerous opportunities for a software developer to contribute as part of these solutions, especially in terms of data analyses.

As a concept, preparing a system for energy data analysis seems like a trivial task. Install a power meter, read that meter at some interval, store that data into a database and then query the database. However, when the time comes for implementation, it becomes a very involving task indeed. Luckily, we live in a time where open source applications are numerous and it's often easy to find an open source project that suits your needs, even if only partially so. Shortly after my previous entry, I learned of an open source web service which collects electricity data and stores it in a database. The service, aptly named WattDepot, even features a robust API for accessing the collected data. WattDepot can even be installed locally for experimentation or simulations and is capable of near real-time feedback. Of course, the best part of WattDepot might be that it's open source, and thus free to use for anyone who is interested in taking advantage of its many features.

But, as with almost all open source projects, there is certainly a bit of a learning curve involved. When I first tried my hand at creating a Robocode robot, there was quite a bit of trial and error as well as a heavy dose of perusing the Robocode API. WattDepot was no different. Although I had access to a WattDepot server which was already set up, and I knew that I had a wealth of predefined tools to help me interact with it, learning exactly how to do what I needed to do still took a bit of the proverbial banging of my head against the wall. Once again, in order to ease into a new system, I performed several katas to help familiarize myself.

1. Get sources. Print alphabetically.
One of the most basically things I learned quickly about WattDepot was that all the data came from sources. Each source had a variety of information associated with it, and one of the most useful bits of information is its name. In trying to alphabetize these sources, I tried to take advantage of the fact that the source names are Strings, and the String class's natural ordering happened to be, in a sense, alphabetical. Here, I "cheated" a bit and threw all the sources into a treeSet to shed the duties of sorting. Then the realization came that even if I were to sort the names, I wouldn't necessarily be able to keep each source's description associated with it. Luckily, Source objects in WattDepot have a compareTo method built in, and as fate would have it, the comparison was by name.

2. Get sources. Print from newest to oldest data.
The second thing I quickly learned about WattDepot was that there were SensorData objects associated with the sources. In order to get the timestamps of how recent the latest data was obtained from a particular source, I had to obtain the latest SensorData associated with each source. Here, I learned again how the compareTo method for this data type was implemented by throwing all the SensorData objects into a treeSet and printing them out. As luck would have it yet again, the objects were sorted by how "fresh" the data was, and printing out the name of the source the data came from was a simple exercise in parsing the String representation of the source.

3. Get sources. Print out their subsources. And their subsources. And their subsources...
With a heavy dose of String manipulation review in my mind now thanks to all the data parsing from the previous exercises, it wasn't particularly difficult to get split a source's subsources up and print them out. However, there was a bit of trouble here because in order to print out hierarchies, it made sense to make use of recursion. Unfortunately, upon investigation, all of the sources on this particular server had either only one level deep of subsources or none at all. What this means is that, even though I wrote my hierarchy printing code to be prepared for recursion, I was never able to fully test it out, since there is no recursion involved if there were no subsources that had its own subsources.

4. Get sources. Print energy consumed by that source... yesterday.
This particular kata or simple exercise took, by far, the longest of all. The goal was very similar to the first two exercises, yet the implementation had to be drastically different. When a query to the WattDepot database for the energy consumed by a particular source is made, the result is just the energy as a floating decimal number. In order to sort these numbers, I chose to put them all into an ArrayList. However, keep the numbers relevant, I needed a second ArrayList with the names to which the energy consumption data corresponded. Only then was I able to sort the lists and print out the results. This kata, however, took a longer time to implement because I hadn't had a lot of experience manipulating Calendar objects, but it turned out to be a surprisingly powerful and useful tool.

5. Get sources. Print highest recorded power per source... yesterday.
With my new found understanding of Calendars, and having already set the foundations for filling two lists which correspond to one another in order to sort them, this kata took a bit shorter to implement. However, due to the fact that we needed to find the highest recorded power by each source, we had to sequentially query the database a number of times per source in order to compare and find the highest recorded number for each source. This not only added more loops, decreasing the performance of the application, but added a lot more individual queries to the server, and overall, the execution of this particular kata was almost excruciatingly slow. In order to expedite the process, I decreased the query intervals to a mere two queries per source and when I was satisfied that the code was serviceable, I reverted back to shorter intervals between queries. Unfortunately, much like the conundrum between exhaustive and practical testing, I was only able run practical tests with longer intervals so as to avoid waiting for long periods of time just to test the execution.

6. Get sources (I see a pattern here). Print the average energy used in the last two Mondays.
Given the last two katas, the most trouble this one gave me was actually in the date manipulation. I found that, if you tried to set the Calendar object's day of the week to Monday, you will end up getting the upcoming Monday's date. What I needed was the past Monday's date. After wracking my brain briefly, I ended up going with the brute force method of the good ol' switch statement. If today is Monday, go back seven days. Otherwise, if today is Tuesday, go back one day and so forth until Sunday, where we go back six days. No, this was not the most elegant solution, but given how little I still understand about how Calendar objects fully function, it was a workable solution.

Through these exercises, I got to understand WattDepot a lot more and, as much as I hate to admit it, I learned a lot about Java that I may not have otherwise learned. While it is on a crude level so far, a lot of the energy data manipulation I learned from these exercises involved sorting data and formatting the output. This is deceptively important, however, because a big part of studying data involves presenting the data in ways that the data can be visualized and trends and patterns might be identified. I was able to complete these six katas to my satisfaction but I unfortunately neglected to jot down the specific amounts of times each one took to implement because I tend to do my coding with breaks interjected. Ultimately, however, it isn't the amount of time devoted to learning a craft that matters, but what you are able to derive out of the experience instead. In this case, I learned a lot more about WattDepot and how to manipulate the information I can attain from interacting with it by sitting down and devoting time to learning and I truly hope that I can inspire you to do the same. Even if it's not WattDepot, or even computer science... sit down and take the time to learn something today! After all, if I hadn't put in the time and effort, I'd definitely still be asking "what depot?"

Sim City: Hawaii Edition

If you've ever played Sim City, you know how hard it can be to be to make those decisions as mayor to help your tiny town grow into a bustling metropolis. I'm not talking the decisions about which disasters to unleash so you can watch your virtual citizens be engulfed in its destructive glory (try the alien invasion, aliens always tear your city up good). Nay, I am talking about the legitimate decisions of balancing your city's need for utilities, the cost required to maintain them, as well as environmental concerns.

Look at this thing ruining your citizens' day

One of the utilities that your Sim City citizens craved the most (when they weren't getting blasted by alien laser beams) is, of course, electricity. Although the decision in the game was one of simply keeping citizens happy by providing them with electricity while not contaminating their breathing air with pollution, the struggle for keeping a city out of the dark is a much more complex situation in reality. There are other concerns to look out for as well, such as the depletion of non-renewable resources that threatens to spell the end of the era of taking the availability of fuel for our cars or oil to burn in generating electricity of granted.

At this point, you might be wondering what this post is doing on my software engineering blog. The answer is two-fold. First, since you are reading this blog at all, you are on an electronic device with access to the internet and the concept of power and energy should at least interest you on a superficial level even if it's not a lingering thought in the back of your mind all the time. Secondly, this is my blog and I can write whatever I see fit on here!

Having said all that, allow me to express something of importance to this entry. I live in Hawaii. This is important because Hawaii, unlike most places in the country, faces a very unique situation when it comes to energy. Due to its relatively isolated positioning in the world, Hawaii is heavily dependent on importing oil in order to keep our lights on. What this amounts to is that our residential electricity prices lead the nation by nearly triple. It's clear to see now how the energy challenges that we face in Hawaii might concern a software engineer whose livelihood depends on having consistent access to electricity. Even putting aside the obvious reliance of a software engineer upon power, it is also important to take note of Hawaii's unique challenges from a concerned citizen's perspective.

In addressing Hawaii's energy situation, it is good to first understand that energy is the measure of power used over a given amount time. In other words, a light bulb using a little power that's on for a long time can end up using the same, or even more, energy as a microwave that uses a lot of power but is only on for a few minutes in the day. Energy consumption is therefore what we must keep our eye on even more so than how must power a device requires to operate.

Energy conservation is a concern all over the world, but it is of particular importance in Hawaii. As I mentioned previously, Hawaii's reliance on oil for energy generation raises the costs of energy quite a bit. Additionally, due to the fact that Hawaii is geographically isolated from the rest of the world, its energy grid is isolated as well. This means that energy can't be freely transferred from grid to grid as needed as is the case in the continental U.S., not to mention the fact that Hawaii's power plants need to be smaller and therefore less efficient as well. What all of this amounts to is essentially that traditional methods of power generation aren't nearly as effective in Hawaii as they are elsewhere, yet it is very difficult to uproot these practices and adopt new methods as well.

Granted, it is often difficult to buck traditions and change is often slow and sometimes painful. Fortunately, there is and should be optimism for the energy situation in Hawaii because, along with its unique energy problems, Hawaii also has unique potential solutions. For example, although Hawaii's small size results in inefficient power grids, the same small size means a more modest need for energy overall compared to larger metropolitan areas. Furthermore, Hawaii is uniquely primed for numerous sources of renewable energy as well, including wind, wave, solar, ocean thermal and geothermal. Couple the potential for renewable energy with the desirability for Hawaii and its people to ditch the reliance on imported oil and there certainly exists reason for optimism.

Of course, better people than I have thought of these things before me and it is through these people that I am able to convey some of these thoughts to you today. It would especially be of surprise to me if any of these concepts were lost on the folks at the Hawaii Clean Energy Initiative (HCEI). The HCEI ambitiously plans for Hawaii to achieve 70% clean energy by the year 2030. There is probably initially quite a bit of skepticism for this number upon hearing it. However, the plans call for 40% of the energy to be from renewable sources and also reducing our need for energy by 30% thus enabling the 40% of renewable energy to effectively be 70% of the overall energy requirements. As people grow ever more conscious of the growing need for an energy solution and become more efficient with their energy use, even by simply replacing light bulbs with newer, more energy efficient ones, the 70% clean energy goal may not be so unrealistic after all.

For software developers in Hawaii, there are even a number of unique opportunities to contribute to the energy solution. For example, the Hawaii Natural Energy Institute (HNEI) implements various ways to collect energy usage data from consumers through installed devices in households which can send energy use information to HNEI as well as give users a more tangible reading on their own energy consumption. This allows HNEI to study not only energy usage in these households but also energy usage behaviors before and after the consumers are aware of their own consumption rates. Naturally, with all this collected data, software development expertise is then employed in the analyses and parsing of the information which may even be represented as graphical interpretations of energy usage that consumers can then access. Another opportunity for computer scientists interested in energy studies appears at Hawaii's flagship university campus as it undergoes renovations and seeks to improve energy efficiency in its buildings through wireless sensors streaming energy usage data to a central computer. Again, with all the data collected, there are opportunities for analyses and manipulation of the raw data into something coherent and useful. Likewise, with the rise in energy consciousness come more energy efficient homes and again, data collected from these homes provide unique opportunities for software engineers to help analyze it.

Even though being a mayor of Sim City might seem like a trivial task, the underlying lesson that one can take away from it is clear. Whether it's a computer game or reality, the need for better energy solutions exists and is more evident in the state of Hawaii than perhaps anywhere else in the country. Hopefully by now you also see why a software engineer might be interested in being part of the solution on a deeper level than simply the fact that their career choice relies on energy because, in fact, there are more than ample opportunities out there to challenge us and put our expertise to practical use.

Not so trivial pursuit - Software engineering edition

Hello readers. Today, I present to you 5 quickie questions for budding software engineers to chew on. Some of these are more specific to my development experiences so I don't expect you to know the answers, but you are reading this on the internet after all, so feel free to embrace the power of infinite shared knowledge.

1. Subversion is a version control system. Name another and briefly describe how it differs from Subversion. (Hint: Linus Torvalds insists you don't use Subversion)

RCS: Doesn't allow for concurrent changes, each developer must obtain a lock to edit a file. Developers must access the same file system to access files.

CVS: Versions are file-based as opposed to repository-wide. Back-end repository is composed of files rather than a database.

Git: Every developer has their own local copy of the whole repository. Rather than managing commit access, you choose other developers' repositories to merge with your own.

2. Briefly describe the difference between exhaustive and practical testing. Which test would you choose? (Answer correctness is based on your justification of your choice, rather than the choice itself)

Exhaustive testing can be more thorough and thus come closer to proving the correctness of a program where as practical testing tries to uncover errors by testing samples. Exhaustive testing, if possible to execute, can produce more reliable results. However, in most non-trivial programs, exhaustive testing is near-impossible if not impossible and thus impractical.

3. Name two ways that a robot can be scanned other than explicitly saying calling the scan() method.

Here are three other ways: 1) When your robot turns, assuming its gun and radar are not set to turn independently. 2) When your robot's gun turns, assuming its radar is not set to turn independently. 3) When your robot's radar turns.

4. When defining an equality relation, name at least two properties that must be upheld.

Here are four: 1) An object must equal itself. 2) An object must never equal null. 3) If two objects are equal, then their hash codes must be the same as well. 4) If object A equals B, and B equals C, then A must also equal C.

5. Given the following Ant code, what would you expect to happen? The default target is bubbles.


Ant prints out everything nice, then spice and finally sugar.

Alone we can do so little

An obligatory irrelevantly relative introduction spiel
If the pyramids were worked on by a single person, Tutankhamun's tomb would probably have a pretty big sunroof. Let's not argue over the details behind that statement or how King Tut existed after the age of pyramids and was buried in the Valley of Kings instead. The point being made is that the pyramids were built on the backs of a huge labor force working together to accomplish a single objective. Now if we can only apply this wonderful concept of collaboration to the world of software development, imagine all the virtual pyramids we could build together!

Let us collaborate...
Helen Keller once said, "Alone we can do so little; together we can do so much." The power of collaboration ought to be intuitively obvious to anyone. To illustrate, if we had 8 slices of pizza, it would be much faster for 4 people to eat 2 slices each as opposed to 1 person eating all 8 by themselves provided, of course, that each person eats at a relatively similar pace. Likewise, if a piece of software had to be developed, it seems obvious that if the work was divided amongst several developers, the overall efficiency of the development process would increase as well.

Pitfalls of working together
There are several downsides to group development of course:

1. The balance of work is not always fair. We've all been there before, a teacher assigns group work and you're forced to divvy up the work amongst the group members. But the day before the project is due, one of your group members have yet to even bother to communicate a single thought to the rest of you, not to mention put in any work effort. That's when you grit your teeth, shout some obscenities in your head and suck it up and do their work for them. By the way, if you have never gone through this before, you're the person that's slacking off.

2. Incompatibility of styles may exist. Sure, we can all pick up The Elements of Java Style, read it cover and cover and try to adhere to the standards at all cost. But there is always going to be a slip-up here or there. This really becomes a problem if you have a team member that's brilliant at coding but you can never figure out how their code works because it is simply unreadable and the documentation basically says, "trust me, it works."

3. Working concurrently is difficult. If the goal of a project was to serve a plate of faux-Chinese food to a hungry customer, a plausible solution would be to implement the Panda Express assembly line of food scooping. But when dealing with software development, working on a project sequentially becomes highly inefficient. Why must developer A wait for developer B to finish working on the Apple class of their Fruits project when he's in charge of handling the Orange class? But if they're each handed a copy of the Fruits project, it's entirely possible that the changes developer A makes to the Fruits project conflicts with with the changes developer B made.

Navigating the pitfalls
For dealing with the first two pitfalls, a large portion of the solution is communication. If there is an imbalance of duties, it really is up to every member to correct the situation. All too often you'll find that the person picking up the slack doesn't ever voice their dissatisfaction. Likewise, some of the solution to the second issue is to simply communicate and decide on a coding standard that will suit every project member involved. Then, as I've discussed previously, use a project builder like Ant! Using Ant in conjunction with automatic assurance tools like PMD or FindBugs and especially CheckStyle in this case will eliminate a big headache for any collaborative software development effort.

Enter SubVersion
Obviously, the problem of multiple developers working on a piece of software existed the very first time two programmers got together, modified the same piece of code, and realized they overwrote one another's alterations. If I had to guess, this probably took place a long time ago...

Not necessarily drawn to scale

But, I digress. With the advent of version control software, developers were able to successfully resolve the issue of concurrent development by requiring the source file to be checked out for revisions. While the source is checked out, no one else could make changes to it, but it made it possible for multiple developers to work on the same project without destroying one another's progress. However, the check-out system meant inefficient development, since a file could not be worked on simultaneously by another developer as long as it was checked out. The resolution was optimistic locking. Rather than actually locking the file from modifications and requiring that a file be checked in before it can be checked out again, a file could be "checked out" by any developer at any time and when they check the file back in and commit their changes, the changes are merged with other developers' changes. If a conflict arises, the developers can then work among themselves to resolve it. Subversion is one such version control system which utilizes optimistic locking and allows concurrent development.

Experiencing the multi-developer environment
To really grasp how useful Subversion can be, the best way is to experience it first hand. Downloading a project file from Google Project Hosting (which we will dive into a bit later) on which you are collaborating with 20+ people on is an interesting experience, to say the least. When I first downloaded the project just to get a feel for Subversion, I was able to immediately see the minor tweaks that my fellow developers had made previously. After settling on the revisions I wanted to make, I downloaded the latest project file again and, already, I saw additions to the project file that I weren't there just minutes ago. Conveniently enough for me, the changes did not interfere with the additions I had in mind, and I went ahead with my revisions, and committed the new file without a hitch. It was very interesting to see the updates being made in almost real time as multiple developers made their tweaks and committed their own changes. It was easy enough to simply download the project, make changes, and upload the changes but ultimately, the process had to be applicable to my own projects somehow! Subversion works by having contributors work from a central repository, but where could one host a repository that is easily accessible to all team members? One solution to this question came in the form of internet giant Google's own project hosting.

Hosting your very own software development project
Getting started with Google Project Hosting is simple, you just log in to your Google account, head over to the project hosting site and create a new project. To find out more, head over to their Getting Started wiki. Once again, I was able to host my very own project without too much problems. The only minor bump in the road for hosting my Robocode robot and officially opening the little guy up for open source development was creating the user and developer guide wikis. For those of you that are new to wiki editing like I was, there is a special wiki syntax by which you must abide by to quickly construct your wiki pages. Not all of the syntax is extremely intuitive, but a helpful guide does leave you with enough information to work out what you need to do to get your wiki looking how you want it to look. One interesting quirk about WikiSyntax is that words with multiple capitalization is automatically regarded as a link to another wiki page. Unfortunately, as it turns out, if you are hosting a Java project like I was, a lot of your references to your own project is regarded by the wiki as a link to a non-existent wiki page. This is a bit of a hassle, but ultimately, something that I could live with considering some of the other more useful features. For example, putting in a heading automatically generates an anchor to which you can then reference directly from a link. This was very helpful in creating a wiki with multiple headings and a Table of Contents that allowed the viewer to quickly jump to a specific heading. In fact, see it for yourself at my project home page.

Final thoughts
Not only is collaboration a good idea in software development, it is crucial to the success of larger projects. Albeit, I have thus far only barely scratched the surface of the potentials of hosting a project online and using version controlling systems to manage a collaborative project. But even with my brief swim in the vast ocean that is open source development, I can quickly already see the advantages to having a project hosted in a centrally accessible location and allowing multiple developers to access and modify the code concurrently. I'm hoping I was able to convey why I am so excited about the possibilities that these tools open up for me as a developer and that you, my faithful audience, will have some of the excitement rub off on you as well. After all, if you're reading this, you are likely interested in software engineering and if you're interested in software engineering, your proverbial mouths should be watering with anticipation of how you, too, can start collaborating with others right now!

Links to check out:
Apache Subversion
Getting started with your own Google Hosted Project
My Google Hosting Project Home Page

Coward: One who, in a perilous emergency, thinks with [its wheels] - Ambrose Bierce

A few weeks ago, I wrote about the marvelous little virtual minions that I created through the wonder that is Robocode. Now, one might have presumed that my robots were mere results of simple exercises no more exemplary of a battle worthy digital tank than a twig is of a shady oak tree. However, if one were to have thought that, then one would have failed to overlook that when thirteen twigs are combined, they would most definitely create something greater! Such as a branch perhaps?

To be certain, the general goal of this new endeavor was to create a robot that would compete among its peers in the virtual arenas in all of their 40 by 40 pixels of glory. In my efforts to accomplish this goal, I forged together a chimera of my previous iterations of single-function robots to create a single entity armed with the three basic principles of a Robocode robot: Movement, Targeting and Firing. Additionally, as any good robot knows, its primary edict in life is the Three Laws of Robotics. Now, if you will all recall from our previous discussion of the Three Laws of Robotics, the first two laws don't really factor much into Robocode robots. Thus, the ThirdRobotLaw robot was conceived, with its utmost priority being the protection of its own life.

ThirdRobotLaw, or TRL as I've come to know the little bugger as, was designed with a focus on survival. As such, it was determined that the strategy for its movement would be to minimize opportunities to be hit by its opponents. What this entails is that first we had to reduce the potential angles of attack by enemies. Hugging a wall, as it turns out, was an obvious choice since it immediately reduced a fourth of the cardinal directions from which bullets could come from. Upon the battle starting, TRL picks either the West or East wall to run towards in a true coward's fashion by determining which wall is closer. Upon reaching a wall, TRL changes to one of two modes depending on the number of enemies left on the battlefield. The first mode, if there are more than one enemies remaining is to randomly choose a direction between North and South and glide towards it at a random interval. The idea behind this mode is that if the enemy of TRL's enemy is the enemy of that other guy. TRL deviously hides along the wall and shuffles along at random and hopes that its enemies kill each other off. However, when the battlefield participants dwindle down to but one opponent, TRL will then adopt the only strategy available to a coward in that situation: eat or be eaten. At this point, TRL goes into turret mode and ceases to randomly glide around in a desperate effort to not die. It is also important to note that even in turret mode, if TRL is hit by bullets multiple times, it will try to glide away at random again in an effort to avoid bullets again. Conversely, if TRL is missing too often, it will try to move away from its current wall in an effort to get more aggressive.

Prior to reaching turret mode, TRL does not really engage in any sort of robot targetting. When it finally does begin to track enemies, there should only be one enemy left and thus, no real illusion of choice as far as who to prioritize. Using a modified version of the TrackFire sample robot's tracking mechanism, TRL sits in place and tracks the closest enemy. The closest enemy, in this case, also happens to be the only enemy.

When in turret mode, whenever TRL scans a robot and its guns are ready to fire, it will do so. However, based upon how far its enemy is, TRL will scaled back the bullet power in order to conserve energy since greater distances usually means a higher likelihood of missing. Yet, in order to compensate for robots who also act as stationary turrets, if TRL is able to connect on several consecutive shots, it was switch its guns to fire maximum power bullets under the assumption that either the other robot is stationary or our tracking is doing a decent enough job of keeping our gun lined up.

Here are the results of TRL's 1v1 attempts against the sample Robocode robots:

Vs. Walls: 0 wins, 10 losses (an absolute massacre)
Vs. RamFire: 0 wins, 10 losses (yet another massacre)
Vs. SpinBot: 1 win, 9 losses (slight improvement, but otherwise utter defeat)
Vs. Fire: 2 wins, 8 losses (still yet a bit better)
Vs. Crazy: 5 wins, 5 losses (two random robots producing 50/50 results)
Vs. Tracker: 7 wins, 3 losses (a bit more positive news)
Vs. Corners: 10 wins, 0 losses (unfortunately this was TRL's primary sparring partner)
Vs. SittingDuck: 10 wins, 0 losses (anything less here would be unacceptable)

On a whole, versus sample robots, TRL does not fare well in 1v1 situations, winning only 35 out of its 80 battles, 10 of which were against SittingDuck. While it would be most gratifying for me to report that in group battles, for which TRL was designed for, it performed admirably and conquered the field of battle by watching others die in front of its radar that was simply not the case. In fact, depending on the types of robots it faced in battle, it was often the first robot to die, especially when the other robot specialized in wall movements as well, forcing TRL to leave its sanctuary. The silver lining is that in the absence of these types of robots, TRL was rarely the first robot to die, and occasionally nabbed the first place in a round by virtues of janitorial prowess (i.e. finishing off the last enemy who has already no doubt sustained heavy damages). In retrospect, it might have been prudent for TRL's random wall sanctuary to include the North and South walls to avoid being pigeonholed by certain wall riding robots. Additionally, rather than turning its body to glide up and down, it may have been simpler and faster to simply make use of the back() functions available to all Robocode robots.

In testing TRL, I knew that its 1v1 prowess would be limited at best and so its acceptance tests consisted of generally weaker sample robots like SittingDuck and Corners. I also made the decision that I did not particularly care if TRL could beat non-SittingDuck opponents 100% of the time and that a better-than-half average was sufficient. In testing its movements, I made sure that its two primary controlled movements were implemented correctly. That is to say that TRL always necessarily arrived at either the East or West wall in each round without fail, and that against a stationary target, it too was stationary. Finally, I tested that TRL's bullet power was indeed scaling based upon its intended algorithm and that upon successfully hitting a target consecutively, it would then increase its bullet power to maximum.

If nothing else, this project has taught me one thing: an idea might sound good but until it manifests and is tested, there truly no way to know. Even in hindsight, I feel like the design of the strategy to evade at random until everyone else is dead is a sound one. Albeit there are kinks and unexpected behaviors that were unforeseen in the design of the robot, but overall the tactic still seems good, even if the execution in practice yields poor results. However, rather than focusing on the weaknesses and shortcomings of the robot, the most important thing that I took away from creating ThirdRobotLaw was actually the development process. From the Java coding standards to the automatic quality assurance tools, I learned more about the process than robocode development. It was simply nothing short of amazing how much more polished my project appeared in the end when I made use of Ant in conjunction with Checkstyle, PMD and FindBugs. Certainly, having more tools at my disposal as a developer now and having gained familiarity with how to take advantage of said tools, I would probably have approached this project a little differently. In particular, I would have been testing my robot along side JUnit from start to finish, making sure that each behavior was working as intended before moving on and tacking on more features. One of the biggest mistakes I made in this project is a mistake that often extends to students and possibly developers all over the world in that I started to write my robot as soon as I had a design in mind. I then proceeded to write big portions of functionality that intertwined with one another all at once rather than keeping them as separate modules which can then be tested on a per module basis as well. Ultimately, the failures led to a disappointing survival rate for a robot whose namesake is, in and of itself, an instruction for absolute survival. As a TRL's designer, I express my regrets here and now, and apologize to my loyal fans for TRL's many flaws. However, as a more seasoned Robocode developer now, I can promise you without a guilty conscience that version 2.0 of our robots will better than ever! Maybe by then it will be able to win 36 out of 80 rounds...

I'm terrified of bugs but Ant just might change my mind

I am. I truly am terrified of bugs. As a person, I am terrified of just about anything with more than four legs and as a software developer, I am terrified of my programs not doing what I want them to do. O bugs how I loathe thee! I recently discovered however, albeit ten years too late, that there actually is a bug I am actually quite fond of: Ant. Granted, if one were to truly overanalyze this one exception to my entomophobia, an ant is still an insect and the Ant I am so fond of is a Java application builder.

As any software developer should know, there exists a massive divide in the developer world regarding operating systems. Furthermore, not every developer is going to agree on which development environment they prefer to write code in and everyone has their own thought process about how their software projects should be organized. Naturally, these exponential differences between developer systems are going to cause trouble when two or more developers deem it necessary and wise to collaborate on a project. Thus the birth of software building utilities arrived and developers could carry on knowing they were right all along about which development system and environment is the best.

Ant is a tool which is ideally used for building Java projects. Invoking Ant on different operating systems should, theoretically, always yield the same project build and ultimately make it possible for developers to continue to work on the project in their preferred manner but have a quick solution for sending the project off to be worked on by another person as well. Additionally, Ant can be instructed to run various quality assurance tools each time it tries to build a project thus ensuring that the projects being shared adheres to the same standards as others using the same Ant build. It's easy to see now why a software developer can, upon learning about the existence of it, be so quick to embrace the technology.

Learning to write an Ant script does require a basic understanding of XML. However, suffice it to say that each Ant task is a different XML tag that is understood by Ant to perform some action whether it be print something to the command line or to simply set a value to a property. In order to get a crash course on Ant, I walked myself through several "Ant Katas" to get familiarized with some basic Ant scripting concepts. Said Ant Katas follow:

Preface
I do not intend to explain how I accomplished these katas in detail, but rather share with you my learning experience through them. On a side note, there have been several external links thus far in this article for your edification and education. You are welcome.

Ant Kata #1 - Ant Hello World
The idea behind this Kata is to learn how to write a simple Ant script. With a bit of quick internet researching, I was able to learn that an echo tag with a "helloworld" message value was all I needed. However, this being my first foray into Ant scripting, I hit a road block almost immediately. An echo tag by itself was no good because Ant requires actions to be wrapped in target tags to be performed. Targets, as it turns out, are the little blocks of instructions that tell Ant what to do. But since you can have several targets inside an Ant script, how would it know which target needs to be carried out, if at all? Hence my final lesson from a deceivingly simple kata was that one can specify a default target for Ant to use when the script is executed if no target is specified by the user of said script.

Ant Kata #2 - Ant Immutable Properties
This Kata involved associating a value to a property element in Ant and then associating a different value with it shortly after. As one might expect with a Kata referring to immutability, a property's value can not be altered once it has been set. What struck me as interesting here is that essentially properties can be viewed as constants in Java since they can only be set and referred to but never changed.

Ant Kata #3 - Ant Dependencies
If you have ever used Make before, you might be familiar with the concept of dependencies. Briefly speaking, associating a dependency to one target tells Ant that the execution of this target depends on the successful execution of its dependencies. For any person reasonably logical, the concept of dependencies shouldn't be very difficult to grasp. If a target Keyholder depends on Car (to get to work) and a Store depends on Keyholder (so it can open), it follows that Car is needed for Keyholder which is needed for Store. Likewise, if Car depends on Store (apparently the car needs to be purchased from the store first in this case) then we have a circle of dependencies with no logical entry or exit point. In the latter case, Ant would complain and fail to execute the build.

Ant Kata #4 - Hello Ant Compilation
The point of Ant is to build projects - ideally Java - and any decent Kata routine certainly ought to have something practical as part of its choreography. Ant Katas are no different and to practice Ant in see it perform its core functions in all its glory, I wrote a simple Java program to simply print "Hello Ant" to the console. By applying everything I learned in the previous Katas, I was able to execute this Kata without much trouble. Compiling the Java file was a simple matter of calling on Ant's javac task and telling it where to find the Java file and where to put the compiled file.

Ant Kata #5 - Hello Ant Execution
Of all the Katas, the one which gave me the most problems was figuring out how to execute the compiled class file from the previous Kata. Rather than an issue with understanding how to use the java task in Ant properly, it was a dependence on my development tools to keep track of my class path which led to my headaches. However, once I was able to surmise that it was my use of a lengthy package name which was causing my Ant build failures, I was able to quickly diagnose the problem and fix my script accordingly. Lo and behold, my compile was successful and my execution printed out "Hello Ant" to my delight.

Ant Kata #6 - 8
For you, the reader, I will summarize that the goals for Katas 6 through 8 were to have JavaDocs be generated by an Ant script, a standalone "clean" target to exist and be readily invokable should the user choose to do so, and to put everything we've learned from the previous Katas together and package the project in one neat zip file for distribution. However, as I forewarned previously, this is a discussion of my learning experience through these Katas and, quite frankly, there is little left to discuss here.

Ironically, it turns out, the simpler Katas taught me the fundamentals of Ant scripting which allowed following Katas to be much easier to execute, and the skills for deciphering how Ant tasks work were all it took to execute the latter Katas. In retrospect - which is always an easy perspective to speak from - it was with a very low level knowledge of Ant and XML that I was able to manage completing my 8 Ant Katas and take my first step towards writing more robust and functional Ant scripts. That fact, coupled with the power of Ant and its supreme usefulness in software development, made me a believer that perhaps not all bugs demand from me the response of utter terror.

Three Laws of Robotics

Whenever a person thinks of robots, they tend to think somewhere along the lines of C-3PO or R2-D2 - digitally charged beings programmed so superbly that they are nothing short of autonomous.  Now imagine, if you will, that R2-D2 had spent the majority of the Star Wars franchise sitting in place and twirling its dome-like noggin around in circles.  Han, Luke and Leia would have met an early death at the hands of Jabba the Hutt but R2-D2 would have performed exactly what I programmed my robots to do in Robocode.  Continuing down the line of not-so-obscure science fiction references, it is nearly blasphemous to talk about robots without talking about the Three Laws of Robotics as established by the late Isaac Asimov.  The laws state:

1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
2. A robot must obey any orders given to it by human beings, except where such orders would conflict with the First Law.
3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

Given my limited exposure to the joys of Robocode I was saddened to find that, while my robots all certainly cannot injure a human being and obey my poorly devised orders to the letter, they were all ill equipped to protect their own existence.  In my defense I, too, was given instructions on the functions that I was to write into my robots and, to their credit, all the robots I wrote performed valiantly on the field of battle with what they were given.

To get my feet wet, so to speak, I started off with a building a robot that did absolutely nothing.  This poor robot, when pitted against just about any other robot, was essentially defenseless.  I do make it a point to say just about any other robot because it drew every match it had against the sample SittingDuck robot which came packaged with Robocode to a dramatic stalemate.  However, as one might expect, making a robot that does absolutely nothing is not very interesting and soon, with the aide of a few built in movement methods, I was creating robots that could leisurely move across the playing field provided its opponents, too, were all pacifists who fired no bullets.  But even robots moving across the field back and forth quickly grew tiresome and it became all too obvious that more advanced techniques would be required to get them to perform more interesting movements.

Problems for me quickly arose when I attempted to create a robot that moved itself to the center of the playing field.  Firstly I realized that, due to the nature of how headings are organized from a range of 0 to 360, I had to warp my way of thinking and the trick to turning the robot efficiently would be to be very methodical and view destination headings as being relative to the robot's current headings.  To turn efficiently also meant that the choice to turn left or right was important and had to be based upon the robot's initial heading.  After tinkering around with the numbers a bit, I was finally able to get a robot to properly turn and move towards the center vertically and then horizontally.

Alas, I was not satisfied.  When walking to the middle of an open field, I would never first walk vertically along the field, turn 90 degrees, and proceed horizontally towards the middle.  Barring any obstacles, I would almost certainly walk diagonally across and I could think of no reason why my robot should not be allowed the same choice.  Thus, through trigonometry, I was able to devise an algorithm for which my robots were able to locate the center of the field, decide to turn left or right to be efficient and move straight to the center in a straight line.

Having mastered exhibited this skill a single time now, I forged ahead in my quest to learn Robocode and attempted to get my robots to not only acknowledge the existence of other enemies but to react to their existence as well.  Surprisingly, following another robot proved not to be as absurdly difficult as one might have imagined since Robocode actually offers several helpful methods for tracking enemies.  Since it is possible to keep a robot's radar facing in the same heading as the robot itself, following other robots was just a matter of turning my robot according to where the enemy is.  However, when it came time to finally work with the guns, a lot of unforeseen trouble headed my way.

Initially, working with guns seemed fairly straightforward: turn the gun in a direction which automatically activates the robot's radar and every time an enemy is scanned, fire away.  But when trying to track an enemy, I found that my previous algorithm for following an enemy did not translate very well.  This was due to the fact that, upon scanning an enemy, the bearings returned to my robot was relative to my robot's current heading, and not my robot's gun's current heading.  Thus working with bearings, which ranges from -180 to 180 and having to translate its relation from the robot's heading to its gun's heading turned out to be a spatial nightmare for me.  Ultimately, the solution I found was to translate the bearings into the same 0 to 360 range that headings worked in and after struggling with the problem for hours, I was able to get my robot to track another robot fairly well.  Albeit, at times, the tracking would still lose its target and the robot would be forced to spin its gun to relocate the enemy.

Although I was able to complete 13 simple robot implementations and develop a minor grudge against Robocode and mathematics in general, I realized that some of the instructions specified picking an enemy and although they did not necessarily always say to stick with the chosen enemy, the implication was there and had somehow gone over my head.  Thus, it is difficult to say that all 13 of my robots are living up to their specifications, but at least they are not injuring human beings.