Hale Aloha CLI Part 2: Rise of the Hash (Version 2.0)

In my previous post I investigated the inner workings of the Hale-Aloha-CLI-Hash project, answering the question of whether it successfully accomplished all of the Three Prime Directives of Java-based open source software engineering. If you are just tuning in, you are more than welcome to read my previous blog, but I am certain you will see that the system that I reviewed, surely, was a good system that did satisfy the directives.

However this time, by some odd stroke of fate, I was given the opportunity to be just one,amongst a group of my peers (actually, the same group as in my post on IDPM through teamwork on Hale-Aloha-CLI-Chair) of the project's developers that expanded upon the previous system by building in new functionalities. Working with not only my team members but also an unfamiliar territory (since being a new developer to the project, I was not well adjusted to the previous group of developers' coding strategies) we were to add commands such as:

(1) set-baseline [tower | lounge] [date]
This command defines [date] as the "baseline" day for [tower | lounge]. [date] is an optional argument in YYYY-MM-DD format and defaults to yesterday. When this command is executed, the system should obtain and save the amount of energy used during each of the 24 hours of that day for the given tower or lounge. These 24 values define the baseline power for that tower or lounge for that one hour time interval.

(2) monitor-power [tower | lounge] [interval]
This command prints out a timestamp and the current power for [tower | lounge] every [interval] seconds.

(3) monitor-goal [tower | lounge] goal interval
This command prints out a timestamp, the current power being consumed by the [tower | lounge], and whether or not the lounge is meeting its power conservation goal.

In addition to implementing the above commands, we are also to update any of the guides to reflect the changes, effectively upgrading the system to Hale-Aloha-CLI-Hash V.2.0.

Although my team members and I eventually did get everything up and running, it was not without a few roadblocks along the way.

One of the major issues, as a group, that we ran into, was our favorite friend: communication (or, a serious lack of it). While each of us were responsible for our own individual task, communication was even more strained in this project, with no one, if I can recall correctly, communicating in-depth. That is, until the final week of development emerged and the rate of communication increased more and more, with the highest rate occurring on the last day. While I too played my own part in not communicating more efficiently with my partners, making the necessary developments for the new version of the system became increasingly stressful as well since I had no idea how much progress my partners were making and if they needed any assistance in finishing up their task.

Another major issue we ran into as a group was working with the previous groups' implementation of the command line interface of the system. Now, I am not trying to make the case that their choice of implementation led the project to violate any of the Three Prime Directives, but, for me, their choice was slightly confusing. Simply put, the actual interface of the project did not function in a manner that most would consider to be an interface and, as a result, adding new commands was somewhat complicated. However, after getting used to the way that they implemented their interface, my team members were able to both add and test the new commands.

From the perspective of the Three Prime Directives, I think we did a good job advancing the system. Albeit, it may not be perfect (since there were a few last minute updates to the system like the last time we used teamwork in IDPM), but it successfully satisfies the Three Prime Directives, making it easy for other developers as well to advance it even further. Despite some of the issues we had in development, I really enjoyed working in teams for IDPM, since not only did it help me to understand what my weaknesses are as a programmer, but also my strengths in relation to both my team and the other's team.

A Closer Examination: Hale Aloha CLI Hash

Going to any restaurant, I can imagine its customary to have appetizers before you dive into the main course. That is, if you are not in a rush! In my previous blog, I detailed just a small taste of what teamwork was like in Issue Driven Project Management (IDPM). While my experience, to say the least, was not quite what I expected it to be, I did learn a lot of new things from my experience, with learning how to communicate more efficiently topping the list.
However, what I learned in my experience is only just the appetizer. In fact, I think in order to digest and appreciate the full effect that IDPM fosters, I must also experience it as an outsider looking in. Thats where Hale Aloha CLI Hash comes in.
Both the Hale-Aloha-CLI-Hash and Hale-Aloha-CLI-Chair are simliar projects, setting out to provide a Java based implementation of a Command Line Interface which provides users a useful way of working with WattDepot energy from the Hale Aloha student resident towers located at the University of Hawaii at Manoa, differing only by, of course,the developers who worked on it and their implementation strategy. Being similar, the requirements of the project were the same: developers were to create six commands,help, quit, current-power, daily-energy, energy-since and rank-towers. Simple, yes? I know.
As an outsider looking in, I analyzed their source code throughly, looking for other things another developer would look for if they were to examine this project, for example, if this project satisfied the Three Prime Directives of Java-based open source software engineering.

If you remember way back when the blog in which I analyzed a piece of software in terms of the Three Prime Directives, you would also remember that satisfying these directives is integral to projects of a higher quality that are not just easy for users to use, but administrators and developers to use as well.

Continuing on in the same fashion as my first blog, I witnessed that the Hale-Aloha-CLI-Hash project, in terms of the Three Prime Directives:

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

After a successfully downloading the project,which was quite simple I must say, proving that the system accomplished this task was trivial. Here is some sample output:

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 (yyyy-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 [start] 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 Lokelani
Lokelani's power as of 2011-12-13 was 43.38106384657915 kW
>
daily-energy Lokelani 2011-12-12
Lokelani's energy consumption for 2011-12-12 was: 794.4316447372753 kWh
>
rank-towers 2011-12-05 2011-12-12
Source For the interval 2011-12-05, 2011-12-12 energy consumption by tower was:
Lokelani-08-telco 206 kWh
Lehua-10-telco 210 kWh
Mokihana-06-telco 212 kWh
Lokelani-12-telco 218 kWh
Mokihana-04-telco 240 kWh
Lokelani-10-telco 248 kWh
Mokihana-08-telco 250 kWh
(Shortened output)
>
quit

Prime Directive #2: An external user can successfully install and use the system

No system is ever useful without the proper documentation on what the systems is and what it does, and as a result, is incomplete. However, that is not the case for this project. In addition to the easy process of installing the system, both a user's and developer's guide are provided, giving an in-depth description of what the system is, how to install the system, and some basic commands that the system accepts when it is running.

Here is just a snippet of information from both pages:
(Users)
Introduction
To download the latest distribution of the hale-aloha-cli-hash system please navigate to the "Downloads" tab above and download the latest distribution of the system.

Details
After downloading the distribution .jar file it can be run in the following way:

1) Navigate via the command line to the directory which contains the "hale-aloha-cli-hash.jar" file that you have just downloaded.

2) To start the program issue the command:

% java -jar hale-aloha-cli-hash.jar
.........................

(Developers)

System Requirements
This program requires the following installed to compile and run:

Ant 1.8.1

Java 1.6

Installation
After checking out the hale-aloha-cli-hash project you must navigate to the top level of the directory and run the following command:

% ant
This command will download the following packages necessary to run the project: Ivy, JUnit, WattDepot, JavaDoc, PMD, Checkstyle, and Findbugs.

Verify installation
Once the ant command executes successfully run the following:

% ant -f verify.build.xml
...................

Thats another success in terms of the Three Prime Directives!


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


A feature that makes a system good is the fact that it is useful and that, of course, it can be used by other users. Yet, what really makes a system great is that in addition to said feature, it can also be used by a wide range of other developers as well.
From the page where commits to the project can be seen, its obvious to me that each team member of the group did a good amount of work that contributes to the project's success. Each member not only implemented the required functionalities and their appropriate test cases, but also gives other developers a complete overview of their work, illustrating their combined effort to ensure their project followed specific coding standars, their project's correctness under quality assurance tools, their project consistency at being verified to build successfully under continuous integration and that the proper documentation (i.e Javadocs) could be generated, if need be.


All in all, the group did a good job at creating a system that adhered to the Three Prime Directives. If you are curious please feel free to check it out yourself here

A Job for Teamwork: Issue Driven Project Management

Usually whenever I hear the word teamwork, I can't help but think of all the bad experiences that I have had when teamwork was a factor in completing a task. In such situations, a lack of communication between team members usually lead to hours of frustration at the progress being made(or,not being made) coupled with,as I often find out, a final submission that usually left a lot to be desired(what can I say, even I sometimes can become quite the perfectionist!).
Despite my prior experiences,collaboration with others is often a must in software engineering, especially for large-scaled systems, and even for, in this case, issue driven project management.
Joining together my skills from a previous post on WattDepot katas, and a brief introduction to the basics of continuous integration (CI) via Jenkins my team and I were were thrown face forward into the the pool of issue driven project management with a project that develop a command line interface program to understand various aspects of energy use in the Hale Aloha residence halls. Our project called,hale-aloha-cli-chair(command line hack for accessing information resources),upon invokation, enters a loop in which you can enter commands for the program to execute.
While the project itself seemed straightforward, mixing in the element of teamwork made IDPM more stressful than I could have imagined. In the beginning, it was less so since issues were successfully created and chosen to complete by each respective team member. However as time progressed, communication between all of us became strained, to the point that by the time the final submission was due communication was almost nil and there were a higher volume of last minute commits to the system. I had hoped I could have had an experience that was devoid of such stress, but when each member of the group is a busy college student juggling many things around at once, I think, how could I expect anything different?
Despite the stress mixing teamwork produced, I think we all did a good enough job with the project. Though the amount of work done by each of us could be considered slightly less that equal, each of us were successful at implementing the required functionalities of the project (all except a User Wiki guide, that is!) and extensively testing each of the functionalities with automated quality insurance tools such as PMD, checkstyle and FindBugs.
All in all, it may have not been the experience I was hoping for, but it definitely was an experience worth having. I think it has prepared me to be more productive at facilitating a more effective chain of communication and doing my best to keep that chain from being broken, in addition to keeping productive levels relatively high for the next time.

Watts Up? : Working with WattDepot!

In an earlier post, I noted that in order to become an avid programmer practice would surely make perfect. Continuing on with that valuable, but often overlooked piece of information, I have had another chance to practice my skills on a more challenging systems, WattDepot.
For those unfamiliar to WattDepot, simply put, it is a system for acquiring and storing data from electricity meters for smart grid research and experimentation. For the past few days, I have been working with the system by learning the basics. And, I must say working with the system was a unique challenge. Never have I ever spent such a large amount of time coding and testing, coding and testing, and, did I forget to say,testing!? There were so many new things about Java that I had to learn on the fly such as working with XML timestamps and Calendar events(specifically, conversion) that I often ended up confused, but I pushed my way through to a successful completion of all my katas.
By the end of programming my katas (which took hours,as I stated earlier!), I, in addition to feeling stressed out, felt that WattDepot offered a great service especially for Hawai'i. Since Hawai'i has some of the most expensive costs of energy in the nation, the WattDepot can serve as a library of information that can be used to understand what changes need to be made to our current energy habits and how those changes may affect the costs if energy in the years to come. In fact, I was often surprised at about how much energy is consumed at the University (since the data WattDepot collects and maintains is only from the freshman towers at UHM).
For those interested in getting some practice with WattDepot, it is available to download at: http://code.google.com/p/wattdepot/downloads/list and you can take on the same challenge that I had!:
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

Update: The Journey Traveled So Far...

There never seems to be quite enough time in the day anymore to solve all of the problems when faced with the challenge of examining the intrinsic techniques of being a great software engineer. Despite that feeling, I feel that there have been several things that I have learned up to this point that will bring me that much closer to an understanding to what it means to be such from the techniques I have both examined and applied so far. These questions are only a few in number but they are representative of how far I have traveled and also just a hint at the direction that I will be traveling in.

1. What are some of the common types of problems that Configuration Management are good at solving?
If you have problems such as (but not limited to): (a) Not being able to reproduce a bug that was witnessed in your own copy of the system, (b) Unable to determine what happened to your fix of the code, although it was fixed at a time prior to your being unable to determine and (c) If you wonder if a bug you saw is fixed within the copy of the system you have, then configuration management will be useful!

2. How does CVS solve the three classical problems that configuration management faces?
For issues with double maintenance,CVS has a centralized repository with a single master copy of each file.
For issues with shared data, CVS allows multiple developers to create local copies of that master copy to work on.
For issues with simultaneous updates, CVS allows multiple developers the ability to edit files simultaneously and CVS creates a "merged" file with all the changes.

3. What are three scalability issues build systems face?
Modularity, Incrementality, and Coupling

4. What is the responsibility of the *.build.xml file?
The *.build.xml file is responsible for implementing support for single functions such as checkstyle,jar,Javadoc,PMD, and Distribution?

5. In a version control system, what is a "delta" representative of?
"Deltas" are a representation of the difference in the versions of files.

Sharing Files...It's just THAT simple!

When it comes to collaborating with teammates by sharing software projects, believe me, I would love to say gone are the days where emailing each other is a requirement. Alas, it is not something that is completely true, however, the task has become easier thanks in part to Google Project hosting and configuration management software clients such as Subversion and Git. Subversion, or SVN for short, is a software versioning and a revision control system distributed that developers use in order to provide current and historical versions of files such as source code, web pages, and documentation.
With the combination of Google's project hosting service and Subversion's configuration management capabilities, project developers are able to create a centralized repository where pertinent documentation, for example, the project's user & developers guide, summaries and also the project itself, can be found and downloaded. Moreover, with the subversion capabilities teammates are able(granted, they must have commit privileges) once downloaded to commit any changes they have made to the project. It really makes sharing projects widespread and simple.
Thanks to that, sharing my Robocode project, DaRumble, was as easy as one, two, three. The only difficulty that I encountered was in creating the pages with the specific documentation (the user & developer guides)due in part to the wiki markup syntax (it took me about five minutes to get the page to display an underscore!), but aside from that, giving a partner commit-access to the project and creating a trunk folder where that partner can commit changes did not take much time to do. In fact,when I was setting the trunk folder up for access, I cleared up the misconception that I had earlier when I thought that any user must download the project first and then re-upload any changes made. I learned,however, that if the user has any configuration management system client, they are able to visit the repository of the project and commit any changes even without downloading the project.
All in all, I think from working with this configuration system, I have gained another useful tool in working with software systems and, to a larger extent another perspective that will being me closer to understanding to what being a great software engineer is.

If at all curious, please feel free to visit my project's page at:
http://code.google.com/p/robocode-wch-darumble/

The End All Be All : Top Robot!

Have you ever wondered what it must be like for those contestants that compete on shows like Top Chef or Iron Chef America. The competition is completely maddening and with the added pressure of making top gorumet meals in sometimes less than an hour surely makes it worse, I would think.