Hale Aloha CLI v2

Taking upon another group's code is no easy task. The difficulty can range from perplexing to hair-pulling. Thankfully, taking on Team Pichu's implementation of a WattDepot Command Line fell into the former category (our friends at Team Teams, who inherited the system previously built by us at Team Cycuc unfortunately fell into the latter category.) As previously blogged about, the level of extensibility is made through open-sourcing one's code and providing thorough documentation. Another important part of making code easily extensible is simple, comprehensible code, which Team Pichu has provided. The process of extending it was no harder than creating a new Command that extended the provided interface and adding it to their processor class (which used branching rather than enumerations, which, while less elegant and efficient, is easier to understand.) As such, the members at Team Cycuc: Yong Hong Hsu, David Wilkie and I successfully create Commands that extended Team Pichu's implementation, though issues with communication meant for an implementation that does not meet specifications.

In many ways, it was easier to work with an existing implementation since issue-driven management means that one can easily assign tasks via Issues in Google Project Hosting, but the problem with Issues is that just because they're there doesn't mean that they're correct and that communication isn't required. The problem with our implementation came from poor planning and coordination, and assumption that all commands do not depend on each other. If we as a team had looked at the specifications thoroughly, we'd know what each of us had to do at what time. Monitor Goal, assigned to Yong Hong Hsu, relies on set-baseline and monitor-power to successfully monitor whether a source achieves a goal, but fails to correctly integrate the methods coded by David and I. In retrospect, my implementation wouldn't have worked as a monitoring-device since the power isn't automatically updated while MonitorPower.run() is running, though an Issue wasn't raised by Yong Hong nor was I contacted in any other method.

With this in mind, I can easily say that our build is a partial failure in terms of the first Prime Directive "Does the system accomplish a useful task?" since it provides partial functionality, as it sets baselines and monitors power, but doesn't allow for the user to monitor whether a tower lowers their energy consumption to a certain percentage of the baseline. It does, however, print out the power at a regular interval such that a user itself can monitor the power of a WattDepot tower.

The ease of which I had implemented MonitorPower however (it took less than a day of coding), shows that the second two Prime Directives are achieved, all credit to Team Pichu. In comparison to Team Teams reaction to taking over our code, their code was incredibly easy to understand due to its simple constructs, meaning that the KISS principal should be used always, especially if one expects to open-source their project to provide for more functionality from other users.

UPDATE(8:45 am): After much running-around-with-hair-on-fire coding, I've gotten monitor-goal and monitor-power to work roughly as specified. It can be found here , it's a last-minute-heroics edition of the interface, since that's what I had to do.