Review of hale-aloha-cli-tnt

The three prime directives should be looked at whenever you try to review a code. The three prime directives are:

• Does the system accomplish a task?
• Can an external user successfully install and use the system?
• Can an external developer successfully understand and enhance the system?

We can use these directives to review how user friendly the code is to both the end user as well as an external developer.

For this project assignment we were to, as a group, create a system that accesses data from the WattDepot server for the Hale Aloha dormitories at the University of Hawaii at Manoa. The system would be a command line interface system that does the following:

• Gets the current power for a tower or a lounge
• Gets the daily energy for a tower or a lounge for a given date
• Gets the total energy for a tower or a lounge from a given date until now
• Ranks the Towers by energy consumption between two given dates

In addition to these commands, we were to design the system in a way where additional commands may be added later.

            For this review, I took a look at the hale-aloha-cli-tnt system. It is a command line interface based system that makes use of the WattDepot server to gather information.

So what is WattDepot? If you haven’t read my earlier blogs, then here is a brief summary of WattDepot is. WattDepot is an open source, RESTful web service that collects electricity data (such as power and energy). For more information, check out this link.

Let’s review the system using the Three Prime Directives.

Does the system accomplish a useful task?

            The overall functionality of this application meets all the basic things that were required. The project is able to successfully retrieve the current power of a tower/lounge, get the energy for a tower/lounge from a specific date after 22 November to the current date, get the energy usage for a tower between two given dates as long as the were after 22 November, and finally give a sorted order from least to most between two dates as long as the dates were after 22 November. The reason the dates had to be after 22 November is because the server failed around that time and the only accessible data is from after 22 November.

Can an external user successfully install and use the system?

            The homepage contains very precise information about what the system does, however the sample input and output is located in a User Guide wiki page. Like mentioned earlier, the User Guide wiki page contains a sample input and output for the system along with simple instructions on running the system. In the download page, the group offers the option to download an executable jar file for those simply wishing to run the application. In addition to this, they also offer an executable jar file along with their source files so that the external users do not need to compile the system first before executing it. The distribution file contains a version number along with a timestamp for external users to monitor any changes and how long ago the changes took place.

            In terms of testing, both valid and invalid commands were used. The following are the commands and the type of output it gave:  “help”

·      “help”

o  Gives the proper output.

·      “current-power Lehua”

o   Gives the proper output of Lehua’s power.

·      “current-power lehua”

o   Gives a bad syntax error showing that it is case sensitive

·      “Current-power Lehua”

o   Gives a bad command error showing that the command checker is also case sensitive

·      “daily-energy Lehua 2011-11-23”

o   Gave the proper output of Lehua’s daily energy

·      “daily-energy Lehua 2012-11-23”

o   Gives a bad date error.

·      “daily-energy Lehua 11-23-11”

o   Gives a bad syntax error showing that the date must be properly formatted

·      “daily-energy Lehua 11-23-2011”

o   Gives a bad syntax error that there is only one way to write the date.

·      “daily-energy Lehua 2011-10-21”

o   Gives a date error showing that the date should be after 22 November.

·      “energy-since Lehua 2011-11-23”

o   Gives the proper output of the amount of energy used in Lehua since 23 November

·      “energy-since Lehua 2011-12-25”

o   Gives a date error

·      “rank-towers 2011-11-23 2011-11-25”

o   Gives the proper output rating the towers from least to most.

·      “rank-towers 2011-11-25 2011-11-23”

o   Gives both a date error and a bad syntax error showing that it recognizes that the start date is after the end date.

·      “quit”

o   quietly closed the application

Overall, the system does very well and is very useful. The system did not crash when providing bad inputs and it provided correct and useful outputs when providing valid commands.

Can an external developer successfully understand and enhance the system.

            The Developer’s Guide wiki page provides clear instructions on how to build the system once the sources are downloaded. Quality assurance is done automatically by running ant –f verify.build.xml that runs checkstyle, PMD, and findBugs. The wiki instructs the user to run this command first before any sort of additional modifications to the code to ensure the original code didn’t have any errors. In terms of coding standards, the wiki page mentions the eclipse format and provides a link to the xml document for users to use. The application wiki mentions that it follows issue driven project management and continuous integration. Continuous integration is a practice in where smaller pieces of code are verified for validation at smaller increments instead of at the end of construction. Often times, each integration is automatically verified (in our case using the “ant” tool) and assists the group find out who, when, and what broke the code if there is a build failure. Issue driven project management is a practice in which the over build is broken down into smaller issues, usually about two days worth of work. For this project, we submitted issues in Google Code and used that service to also monitor and add our issues. A link is provided to the continuous integration server to that is associated with the application. The only thing the Developer’s Guide is missing is how to construct the JavaDoc documentation. The information contained in the Developer’s Guide is very concise and doesn’t contain any useless information.

JavaDoc Review

            I was successfully able to create a JavaDoc documentation successfully. After reading through the various class documentations, the documentation shows that the entire application is linked together by the Processor class. The package names are named appropriately where the Main class is contained in a higher-level directory, the command processor is in a subdirectory of the main directory, and the various commands are also in a subdirectory of the main directory.

Build System Review

            Using the ant command “build.xml”, I was successfully able to build the system without any errors. The author(s) of each piece of the code are listed in the source code to allow external users to know who wrote each piece of code. In terms of coverage, after running JaCoCo, the project doesn’t have 100% coverage.  In some cases such as the Main, Processor, and InvalidArgumentException classes, the coverage is 0% mainly because test cases were not made for those classes. However, the sub-100% coverage is due to the fact that none of the test cases contain a case where the author asserts an invalid statement. The current set of test cases successfully tests the application pretty well for the valid inputs. However, because of the lack of test cases for invalid inputs, there is a slight chance that an external user may create an enhancement that calls throws some random exception and the external developer may have no idea why it is being called.

Coding Standards Review

            What I found to be really nice is that each of the command classes were formatted in the same way (because of the interface class). What I found to be very surprising at the same time was hardly any private methods were used. But this is okay since WattDepot provides a lot of the methods already. The only files I had small problems reading was the Main class and the CommandManager class. In the main class the only thing I had issues with was figuring out when the IOException would be thrown. Documentation on what would have thrown it would have been nice. The CommandManager class was beautifully written using some advanced Java techniques that I have not come across before and because of this I had some problems reading and had to take some time to do a bit of research on some of the things. This is was not a problem caused by the author.

Issues Page Review

            The issues page associated with this project makes it very clear on who worked on which part of the system. It seems that a different person worked on different classes in the system and because of this, if an external developer had any questions about the system, it would be very easy for them to contact the author(s) that worked on that piece of the system. In the group of three, it seems that two of the developers did more of the work. The other group member worked on a single command class, its test case, the Main class, and the Help class. Most of these classes were fairly short and it is clearly shown in the amount of issues posted by that author. However, I would give him a slight break, as he is an undergraduate student working with a two graduate students.

Continuous Integration Server Review

            The Jenkins continuous integration server shows the progress of failed and good builds. Other than at the very beginning of the project between build three and four where the time it took to fix the project was about a day and a half, all failed builds were fixed within an hour. Most were even fixed in as little as 10-15 minutes. As for commits that were associated with issues, less than nine out of ten of them were related to an existing issue.  However, the group was pretty close to having nine out of ten commits be associated with issues; approximately eight out of ten.

Conclusion

            Based on my review of the hale-aloha-cli-tnt system, I have come to the conclusion that an external developer could successfully understand and possibly enhance its features. Although some of things are slightly advanced for where we are, the enhancements would be relatively simple because the sources are very uniformly organized. The overall system works very well and I was not able to make it crash. The source codes are documented so that most users would be able to understand it, however I would like to have seen comments around some of the exceptions and the things they caught. The group did a very good job implementing it, as well as a very good job working as a group.

First Experience with Issue Based Project Management

So, this was actually the first time I was allowed, or rather, told that I could write a program in a group. For this, we used issue based project management by hosting a project on Google Code. The point behind this was to teach us how to program as a team, by defining issues for us as a team to solve. The issues should be things that could be fixed and have enough issues in where the use is relatively always busy; maybe about a weeks worth of work or so.

For this project, we were to construct a command line interface that queries the WattDepot server and return some information about energy and power; similar to what we did with the WattDepot kata. The use of project management allowed us to put into practice using Google project hosting, Ant (as a use to build the system), automated quality assurance, and simple testing to accomplish a large goal by creating smaller goals that each group member tries to accomplish to complete the final task.

For this project our group was named hale-aloha-cli-tiger, a command line interface that queries the WattDepot server and gets various types of information. We set up our project management by first assigning a different command for each of the group members to work on and get working locally. Once that was finished and well tested, we created an interface to make sure the programs both contained a run method and a verify method to make sure they only ran if the parameters were right. This was probably not the best way to go as small problems with parameters occurred later in the process. Maybe we should have created the Main class,Command Processor class, and the interface first. This way, we would have been able to skip the step of modifying some of our methods in the commands.

I think it was because of the concept of issue driven project management, we thought the best thing to do is break down the program into smaller program (the individual commands). This worked, but I feel like it would have been more efficient for the group if the dependencies were created first. In the end however, we got it all to work, but testing was quite difficult as the results that were printed out were always different.

Overall, I felt that this was a very good experience. It was pretty nice being able to write code from other and ask for input without getting into trouble. The only downside I think is that because we as students had a mess load of work for other classes, communication was very difficult a lot of cramming was actually done, even though we were not supposed to. Issue driven project  management is something I will definitely try implementing in future projects both in school and in my professional field.

Can You Feel the Power?

WattDepot is an open source application developed to monitor the power usage of the Hale Aloha freshman dorms at the University of Hawaii at Manoa. In the Hale Aloha system, there are four identical towers: Ilima, Mokihana, Lehua, and Lokelani. In each of these buildings in the same place, there are sensors that monitor the power usage of the residents. The data provided will assist us in pushing for a more sustainable campus.

Similar to Robocode, I attempted a few kata in assist in familiarizing myself with manipulating data received from WattDepot. The following kata were given:

Kata 1: SourceListing

Implement a class called SourceListing, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a list of all sources defined on that server and their descriptions, sorted in alphabetical order by source name.  Use the System.out.format method to provide a nicely formatted list.  For example:

Server: http://server.wattdepot.org:8190/wattdepot/

Source                 Description

Bar                    Represents the energy consumed by the Bar building.

Baz                    Represents the energy consumed by the Baz floor of the Bar building.

Foo                    Energy generated by the Foo power plant.

Qux                    The energy meter associated with the Qux household.

Kata 2: SourceLatency

Implement a class called SourceLatency, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a list of all sources defined on that server and the number of seconds since data was received for that source, sorted in ascending order by this latency value.  If no data has every been received for that source, indicate that.  Use the System.out.format method to provide a nicely formatted list.  For example:

Server: http://server.wattdepot.org:8190/wattdepot/

Source                 Latency (in seconds, as of 12-Oct-2011 14:32:12)

Baz                    9

Bar                    10 

Foo                    14

Qux                    No data received.

Kata 3: SourceHierarchy

Implement a class called SourceHierarchy, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a hierarchical list of all sources defined on that server.  The hierarchy represents the source and subsource relationship between sources. For example:

Server: http://server.wattdepot.org:8190/wattdepot/

Source Hierarchy

Baz

  Bar

  Zob

    Zob-A

    Zob-B

Foo

Qux 

Thus, the source Baz has two subsources, Bar and Zob.  The source Zob has two subsources, Zob-A and Zob-B.  Foo and Qux have no subsources. The hierarchy is represented by two space indentation.

Kata 4: EnergyYesterday

Implement a class called EnergyYesterday, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a list of all sources defined on that server and the amount of energy in watt-hours consumed by that source during the previous day, sorted in ascending order by watt-hours of consumption.  If no energy has every been consumed by that source, indicate zero.  Use the System.out.format method to provide a nicely formatted list.  For example:

Server: http://server.wattdepot.org:8190/wattdepot/

Source                 Energy consumed in watt-hours (19-Oct-2011)

Baz                    932

Bar                    1025 

Foo                    1436

Qux                    2357

Kata 5: HighestRecordedPowerYesterday

Implement a class called HighestRecordedPowerYesterday, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a list of all sources defined on that server and the highest recorded power associated with that source during the previous day, sorted in ascending order by watts.  Also indicate the time when that power value was observed. If no power data is associated with that source, indicate that.  Use the System.out.format method to provide a nicely formatted list.  For example:

Server: http://server.wattdepot.org:8190/wattdepot/

Source                 Highest recorded power in watts (12-Oct-2011)

Baz                    10,034 10:30am

Bar                    10,456 2:45pm

Foo                    14,876 12:30pm

Qux                    23,578 4:15pm

This is a little tricky due to the presence of both virtual and non-virtual sources. For non-virtual sources, you could retrieve all of the sensor data and just iterate through to find the maximum power value. However, virtual sources represent an aggregate of non-virtual sources, so there is no sensor data associated with them directly, and it is unlikely that the sensor data timestamps for its constituent sources will be synchronized exactly.

One reasonable way to deal with this is to request the computed power at (say) 15 minute intervals for the entire day, which provides 96 data points per source whether it is virtual or non-virtual.

Kata 6: MondayAverageEnergy

Implement a class called MondayAverageEnergy, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a list of all sources defined on that server and the average energy consumed by that source during the previous two Mondays, sorted in ascending order by watt-hours.  Use the System.out.format method to provide a nicely formatted list.  For example:

Server: http://server.wattdepot.org:8190/wattdepot/

Source                 Average energy for last two Mondays in watt-hours (24-Oct-2011, 17-Oct-2011)

Baz                    10,034 

Bar                    10,456 

Foo                    14,876 

Qux                    23,578 

Kata 1 was fairly straight forward and did not take much time; maybe around 15 minutes. This is because the provided SimpleApplication.java file provided nearly all the method calls needed to solve it. All it took was slight formatting.

Kata 2 took a little longer; maybe around 30 minutes mainly because I was not familiar with Java's Calendar, Date, and XMLGregorianCalendar classes. After much reading into the API and a lot of guess and check works, I was able to format the outputs to correctly show the current date and time.

Kata 3 is where it started getting a bit difficult and took me a couple of hours to complete, mainly because I was reading through the API trying to figure out how to find the subsources. The formatting was also quite difficult and was not able to get it to work very nicely and resulted in me hardcoding the indentations. It works nicely for this problem, but if the code were to be used where a subsource contains a subsource, the indentations may be off.

Kata 4 was even more difficult than Kata 3 and also took me a few hours to complete, mainly because it took me some time to get used to the XMLGregorianCalendar class required in one of the methods. It also took me quite some time to figure out how to set the days correctly so it would get "yesterday's" data, rather than "today's".

Kata 5 was a bit confusing at first because a lot of problems happened while writing it. The first thing wrong (I guess you could say) is the fact that the system times out after a certain amount of time because it takes too long run run the queries if the increment time was small (ie. 5 or 15 minutes). Because of this, I had to set my intervals to 60 minutes so that it the program stopped timing out. Another problem I had and was unable to fix was not being able to display the actual time where the most energy was consumed.

The final kata, kata 6 was the one I was unable to finish. I am currently still working on manipulating the time based variables and was unable to manipulate it so that it would give me the time for "Monday". The could seemed simple enough, but I would always get errors when I tried passing it my variables as arguments and/or trying to get the manipulation to work.

Like Robocode, I learned quite a bit from doing these Kata. It was my first time really dealing with real world data that was always changing. I also learned that because the data is coming from real time, the results can sometimes be insanely slow and even time out, which can frustrate even the most patient programmer since you aren't always able to check if the outputs are correct. I hope to continue working on these Kata to really practice manipulating the times.

Isolated

It seems like whenever people think of "paradise", the first thing that comes to mind is Hawaii. The weather is nearly perfect all year around and the people make it even better. However, what many don't really know is how expensive it really is to maintain this "paradise" and the fact that it affects the cost of living for the residents of the state so greatly, which pretty much adds insult to injury where everything else in the state tends to cost around 20% more than on the mainland.

Alternative energy sources have been the topic of numerous debates; especially in the university setting. I have done some research on the Hawaii 2050 sustainability plan that focuses on a sustainable Hawaii, by the year 2050, and a huge portion of that plan is based around alternative power sources. What I found quite interesting from the presentation was the fact that the best places to build alternative energy plants is on a separate island.

The capital city of Honolulu is located on the island of Oahu and is the most power hungry city in the state. There have been recent plans to build windmill farms on the island of Molokai because of the amount of land available, but also because of how windy the island generally is. However, plans have faced problems due to the locals protesting about protecting the land. Geothermal energy from the volcano located on the big island of Hawaii was another possibility brought up in the presentation that could possibly bring similar problems as on Molokai. The locals here seem to have a strong appreciation for "keeping the country, country", but at the same time complain about how expensive the cost of living is. Perhaps a compromise is in order?

The potential for renewable energy in Hawaii seems to be limitless. Hawaii offers a surplus of natural resources for various types of renewable energy rather it be from the wind, lava, ocean, or sunlight. It may however, take time for us to get used to these changes and many may be totally against it, but we must realize the fossil fuels are a finite supply that some theorize may be past the half way point of the world supply. It is definitely time for a change and once we set the example (hopefully with the Hawaii 2050 sustainability plan), the rest of the world will follow.

Resources:
Hawaii 2050 Sustainability Plan

Midterm Time!!!

1. What is the difference between Checkstyle, PMD, and FindBugs?
Checkstyle finds bugs directly within the source code that do not fit the coding standards. PMD analyzes code using static analysis by looking at the class files without actually running the code. It finds any unnecessary lines of code. FindBugs focuses on finding code that could potentially be dangerous to the system such as infinite loops.


2.What are some differences between Ant and Make?
Make supports any programming languages and is very widely used. It allows the user to invoke shell commands without constantly typing in the same commands. Ant's build.xml file is much simpler than makefile. It is also java based and therefore supports the java community. It also simplifies cross-platform development.


3. In a professional blog, why should you write for the world and not the teacher?
That way, any software engineer will be able to gain insite to what you are trying to say. Enough information should be given so that anyone will know what you are talking about and not just the teacher or a small group of people.


4. What are 5 conventions for naming variables/methods in Java?
Pluralize group related attributes, Use nouns when naming interfaces, Use camel notation (ie. myVariable), use verbs for naming methods, use JavaBeans convention for accessor methods (is/get/set).


5.What is the difference between a version and a configuration?
A version is a sequence of updates overtime and are parallel variants. Configurations are types of systems that exist for different users, different systems, and/or for different functionality and/or pricing.

Care to make my robot better?

In my last blog, I discussed my Robocode robot and what it does. Well now the source code of my robot is up online and can be found here. But then you ask "hey, what if I want to work on that project (or any other project) with a group of some of my friends?" Well, you can do that too with a little thing called subversion (SVN). What is SVN? SVN is a way to share files with groups of people, make changes, and then uploading it back for the others to work on. What is also very nice about it, is that it leaves a log of the changes made and when they were made.

I was able to finish all the tasks required for the SVN and found it to be very interesting. Before this "sharing" files would be done just be e-mail within the group and more times than none, all of the files are so different that you pretty much have to restart the entire project. The tasks themselves weren't too difficult as not too much programming was involved; it was more like, modifying some things.  The most important thing I think I learned from this is how you can share files through google and allow group members to work on said project while automatically keeping a log of the changes made.


Links:
http://code.google.com/p/robocode-mma-mizuonegai/

Let's Get Ready To Rumble!!!!

It's the moment you've all been waiting for. The robocode competition. After weeks of testing, learning things with ant, and designing our very own robot, it's time to test our skills as well as our imagination. With this project, I was attempting to design a robot where that would be both offensive and defensive. It is actually quite hard to explain, much easier if you watch it in action.

So what does my robot do exactly. It's actually quite simple. For the movement, I designed my robot to simply follow other robots. At first, it will lock on to a single robot and follow it until either it (the enemy) or itself dies. In the case of a melee situation where more than 2 robots are involved, once the enemy is destroyed, it will then lock on to the nearest enemy and repeat the process. This way, the robot isn't stuck once the enemy is following is destroyed.

Like I mentioned earlier, targeting is done by means of scanning for the nearest robot. It will not change targets until one of the two robots is destroyed. It is a very risky procedure, but it reduces the amount of time required for the robot to re-lock on to a new target. This could potentially save the robot's butt.

Although firing could potentially refuel the robot, it also costs a pretty significant amount of energy to even fire off a bullet. Because of this, my robot will only fire when it is near the enemy. If the enemy begins to move away, my robot will be close enough where the odds of the bullet hitting would be pretty high and for this reason, the robot will always fire at the highest strength allowed by the rules.

Against the sample AI robots, my robot did fairly well. It would always win (obviously) against the ones that didn't move like SittingDuck and the two interactive ones. Against the ones that did move (and even fire back) my robot could consistently beat the Target robot. Against a few of the other robots, my robot would often win between 60 to 90% of the time. However, against the Walls robot I was unable to beat it. It was just too fast and well protected by the walls. The reason it couldn't beat Walls, well, my robot had to know where the other robot was before it moved and since walls basically just goes in a circle, my robot simply could not keep up. Would I change my design? I probably would. I would try to incorporate a faster way for my robot to turn and move, probably by implementing the AdvancedRobot class instead.

Because my robot had such a simple design, not much testing was required. The types of testing I did was to make sure I could beat a hand full of the sample robots more than 50% of the time, along with make sure my robot knew how to move away if it made a collision with the enemy robot. I tried getting my robot to limit itself in a "safety bubble" by having it stay near a wall, but often times it ran out of energy.

So from all of this and weeks of programming, what have I learned? I learned quite a bit actually. I learned the amount of time it takes to create larger programs as well as the sheer amount of testing it takes in order to make the program do what I wanted it to do. I also learned by means of the kata I finished earlier, that it is better to break a large program into smaller pieces of code via the divide-and-conquer technique and just have your code do a bunch of small things before putting it all together. So now that it has all been said, lets FIGHT!