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.
Wednesday, December 14, 2011
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
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
Friday, December 2, 2011
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.
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.
Subscribe to:
Posts (Atom)