Issue Driven Project Management

Recently I've partaken in a group project with two fellow software engineers (Branden Ogata and Jayson Gamiao) in which we developed a Command Line Interface (CLI) for energy and power consumption in the UH Manoa Dorms. More specifically we enhanced the wattdepot katas to have a more user friendly front end. This project also used many of the Issue Driven Project Management (IDPM) concepts such as breaking a project into meaningful tasks. Using IDPM really made our lives easier, since everyone had a specific job to do. At first I thought that this project would've been done faster if one person just coded everything since, he/she would know how the code worked. However I was proved wrong because each project member contributed and showed their areas of strength in programming terms.

To briefly explain what IDPM is; In software project management things can get very complex and the larger the project is the more complex it will be. Essentially IDPM has project members working on tasks, which are small jobs to complete the overall project. The project members should have a task to work on at all times and tasks should be meaningful. My overall attitude to what worked with IDPM was that it provided a framework in which group members know what to do and what other group members are doing at all times. This is evident with email notifications with each update and build tools verification.

The project implemented the following commands

• current-power [source] Prints the current power consumption of the source
• daily-energy [source] [date] Prints the amount of energy that the source consumed on the given date
• energy-since [source] [date] Prints the amount of energy that the source consumed from the given date to now
• rank-towers [date] [date] Prints the Hale Aloha towers in order of energy consumption between the dates given
• help Prints a list of commands that the user may type in 

The functionality built in was a soft of idiot proof user interface where if users intentionally try to break the system, an error message would be printed. The functionality that was not implemented was the addition of more commands. The wattdepot API allows more commands than the 4 listed above, but for brevity sake our group chose to implement those 4 as a starting point. This project leaves room for upgrading the code, at this page.

The Google code page for this project is located here

WattDepot Fun

Recently I've partaken in a kata exercise using the WattDepotClient. What is the WattDepotClient you ask? Well it is basically a Java Class that holds a lot of energy data from the dorms located at UHM. The purpose of the katas was to manipulate this energy data and print the selected data. All in all I completed 5 out of the 6 katas here, due to the difficulty in some of the katas I did not have enough time to finish all of them. What was most fun about these katas was the fact that we were given a system/API and was told to understand the methods and utilize them for our kata solutions. Most likely that without access to the API, the katas would've taken much longer to finish. It took roughly a day per kata but kata 3 was most difficult in my opinion. However I had gained insight to a possible solution with the help of my fellow software engineer, Russell Vea. 


I felt that WattDepot was a excellent exercise in a sense that it provided real world data. All the data collected were actual energy/power usage from dorm rooms, and it was fun knowing that I had access to this data.   

Energy in Hawaii

Living in Hawaii, we unknowingly pay more for our energy use than the mainland. Coupled with the fact that our primary resource to create power is gas, we put ourselves in a situation where Hawaii is at the mercy of Gas. I know this firsthand because recently I just started to drive to school, rather than catch the bus. However as Hawaii tries to shift towards a clean energy solution, I think of all the pros and cons of this effort.

What was interesting to me was the fact that Hawaii pays around 30 cents per kWh while the mainland only pays 10 cents. This is a prime example of the 'paradise tax' we pay for living in Hawaii. Since we do not have a 'super grid' like the mainland, we rely heavily on electric plants that consume gas as a means to make energy. Keeping in mind that Hawaii is in a prime spot for other renewable energy alternatives, such as wind, solar, and geothermal. 

Energy in Hawaii is difficult to describe, but I would summarize it in one word, complacency. Most of the residents here are either unaware or don't care for the clean energy movement, and most likely they'll grumble and whine when it is too late. Hawaii clean energy initiative is a great idea but it requires a collective effort from the community. For example a small group of energy enthusiasts won't make a dent when hundreds of thousands of energy users don't preemptively change their energy usage.


I like to use the analogy of a person that thinks their actions doesn't make an impact on this situation as an example of the problem we face. If people in Hawaii don't begin to try become more energy efficient, I would ultimately be paying the price by a higher electricity bill, and paying an arm and a leg for gas. This bystander effect will be the biggest challenge that the HCEI would face in my opinion. However a lot of people are making efforts to promote clean energy in Hawaii.

For instance Jay from HNEI has received a grant from the US Department of Energy to do work using neat energy meters. These energy meters are a great tool to provide real empirical data on energy costs. For example if I installed an energy meter and suddenly realized that my energy usage has jumped twofolds just by watching tv, I would reconsider my habits to try reduce my energy usage. Hopefully this issue does find a solution to itself in the future, as Hawaii is in dire need for a clean energy solution.

Five Important Lessons Learned In Software Engineering

1. Why should software developers always keep the three prime directives in mind?
    The three prime directives ensures that a software system is a well developed and easily maintainable code. The three prime directives are found here.


2. The FizzBuzz program makes use of the assertEquals jUnit test cases, what would be an example test case for this program?
    Since the FizzBuzz program tests for number cases with, FizzBuzz being printed if n is divisible by 3 or 5. Fizz printed if n is divisible by 3 and Buzz if n is divisible by 5. We could use the test case assertEquals("Test for FizzBuzz", "FizzBuzz", 15) for example.


3. Before committing changes to a project hosted on google code which ant target should be run?
    The verify target should pass to ensure the next person working on the project that it is a working version of the code.


4. What kind of bugs would Checkstyle find that PMD wouldn't?
    Checkstyle would find coding standard errors while PMD would find errors that deals with the code. Such as Bugs, dead code, suboptimal code, overcomplicated expressions, and duplicate code.


5. Of the three review methods, which has the fastest turnaround?
    Walkthroughs have the fastest turnaround, minimal overhead. With little/no preparation and no formal process. The other review methods include technical reviews and inspections. Technical reviews' goals include defect discovery and ambiguity resolution. Inspections attempt to detect and remove all defects.

Google Code Project Hosting

I've been working with hosting my Robocode robot on Google Code's project hosting site. So far my experience with it has been most satisfactory, as I was able to successfully host my distribution on Google Code and sync it with my SVN client.  I've tested the SVN capabilities by uploading all the files for my project onto the truck portion of my project webpage. The most difficult thing I had to troubleshoot was the formatting of the wiki pages to adhere to my liking. I was most surprised with the quality of hosting projects on Google Code. It was very easy to create a page and start uploading and creating wiki pages. Plus the fact that other developers are able to join the project by just adding their email makes Google Code very simple.

A link to my robocode robot I've been developing is here. Overall I look forward to using the Google Code project hosting site to work on future projects, since it is a great free option for developers. 

One robot to rule them all

Alas, my robot project has come to an end. However there is still one more act in this play, the epilogue of my journey of which is called robocode. The name of my competitive robot is called RobotDevil because just like the real devil, you never know what (s)he is going to do, or not do... The inspiration of my robot was the idea of a snowflake. They say that no two snowflakes are alike, and I would like to believe that when a user runs RobotDevil, no two instances will behave the same. Without further ado, whose cuisine robot will reign supreme?

Overview 

If I asked you to pick a number between 1-10 and use that number as some sort of 'random' generated output, how 'random' would that be? The same theory applies to what I had attempted in my robocode project. I had set out to try create a robot that ideally will not win 100% of the time yet not lose 100% of the time either. A rudimentary coin flip of a robot would be my esoteric description. In essence I opted to build a robot that would display 'random' movement behavior, an optimal firing scheme and sophisticated tracking logic.

Design

Movement: Movement is the heart and soul of RobotDevil, since our movement paradigm is limited to the battlefield and 360 degrees of turning options, the 3 factors in movement for RobotDevil was the degree of the turn, length of the turn, and condition of a hit wall. The general strategy for moving the robot was to create unpredictable behavior, since most advance robots will attempt to predict RobotDevil's next movement. The only downside to this approach is that RobotDevil may not make the most logical decisions, such as moving towards an enemy bullet or walls.

Targeting: Targeting is relatively simple in the design of RobotDevil, once an enemy robot has been scanned by our robot, the robot will adjust the firepower to either the MAX_BULLET_POWER or 1. RobotDevil continuously sweeps the area by rotating the radar and gun 360 degrees.

Firing: Firing is simple since once RobotDevil sees another robot it either fires a weak bullet or the strongest bullet. The measure taken to anticipate the movement of an enemy robot was not taken since our movement is not predictable.

Results (Out of 100 rounds)

RobotDevil 2606 (14%) V.S. Walls 16575 (86%)
RobotDevil 17549 (52%) V.S. RamFire 16466 (48%)
RobotDevil 1867 (10%) V.S. SpinBot 17423 (90%)
RobotDevil 10136 (59%) V.S. Crazy 6993 (41%)
RobotDevil 20612 (68%) V.S. Fire 9593 (32%)
RobotDevil 15093 (51%) V.S. Corners 14241 (49%)
RobotDevil 2664 (12%) V.S. Tracker 19446 (88%)
RobotDevil 18020 (100%) V.S. SittingDuck 0 (0%)

As the results show, RobotDevil performed horribly against Tracker, SpinBot and Walls. Partly due to the fact that these robots stay at a distance and attack rather than approach other robots. I suppose one design improvement RobotDevil could use is a better tracking system. 

Testing
Majority of the testing was done to ensure that the movement of RobotDevil was truly random. So jUnit tests to check between two length in distances traveled are not the same. It is suffice to say that the tests were a good indicator of random movement but this brings me back to my original question of how random is random.

Lessons Learned
I felt that this robocode development experience provided myself with invaluable experience in jUnit and simple software development principals. It was a great introduction in testing practices such as behavior in code. Perhaps after seeing some of the robots developed by my fellow software developers, it will provide me with inspiration on possible future implementations in RobotDevil.

Using ant as an alternative to make?

I'm a bit biased when dealing with build systems, because I've worked with the very simple make build tool.  Yes it doesn't have all the bells and whistles as ant does but it gets the job done and it was popular before build systems took off. (make was the original build system hipster)

I approached ant just like how I would approach women. I would try to RTFM look at example files and try to understand how it works by just reading the code.  The code I tried to analyze first was the XML files packaged in the PMJ.dacruzer folder. I took a look at the build.xml file, only to be stumped as to what the heck was going on after 30 minutes. However the structure of the build.xml file was similar to a make file, which led me to believe I was on the right path.  I attempted to try complete a couple of ant katas, as a way of getting my feet wet. The katas dealt with cleaning, compiling, javadocs and packaging a system.

Eventually I turned to the ant manual for more information. The manual has a lot of information but it was a bit difficult to understand what exactly was going on. I had also asked a couple of software developer friends of mine on some insight about some of these katas.

In the end I was able to finish all of the katas, except the packaging kata.  The difficulty I had with this kata was the creation of the zip file.  However from completing all the other katas I have learned a lot about ant. For example I learned about basic dependencies, immutable properties, and working with java files within ant. I still appreciate make but ant seems to provide software developers with a much more convenient tool than make. The fact that ivy and ant works together to provide a build system + dependency management tool for a software developer, is awesome.