I had recently joined in on a group that was working to implement a Command Line Interface for an open source project called Hale-Aloha that was built on the WattDepot client and server. I had a good time working within the group and although it was hard at first, I felt that I had gained some good knowledge and practice in issue-based project management utilizing continuous integration.
For those people who don't know, continuous integration is based on the concept of Agile computing, where a large project is broken up into smaller portions that can be programed and coded within days. These small components are usually code that can be run alone or based off of already generated code which work with code that has already been coded and tested. When these smaller code bases are tested and completed, they are usually loaded into a code repository that has a working database of all codes and components that make up the full final project. With Agile computing, not only the work is divided into many small parts, but there are several groups that are working at the same time on the program, but on different parts and thus need some way of accessing the code repository frequently. Because of the amount of access and change that come with Agile computing, the code repository should also be checked frequently to see if any changes to the code repository break or render the full code base broken where the are serious errors to the project. Continuous integration allows the code repository to build the code repository to made a distributable program several times through automation. Having continuous integration also provides a useful service where it can be told to rebuild the project if any changes are submitted to the repository, showing whether the just submitted code provides a build of the project that works or leaves the project broken.
Continuous integration also provides a good base to implement issue-based project management. Issue-based project management is a style of group programming where duties are often separated and the members post issues to address problems or new additions to a project in development to let the other members know what part of the project is being worked on or what part of the project needs to be worked on. Issue-based project management also provides a running list of changes that have been worked on or what is being worked on, thanks to the programmers who are working on the project as well as the testers and the users; by each of them posting issues.
The base that our group was working on is a program that monitors and records data about energy usage from a residential complex called WattDepot. This program takes in data from sensors located through the residential complex and can provide data that can be used to show how energy is used through the residential complex, what is the maximum amount of energy used at one time, or how much power is generated in the case of solar or other ways of producing power. WattDepot is extremely useful where it can be used to provide a general overview as to where energy is used the most and during what time intervals as well as generating data that can show general energy usage or production over a longer periods of time, such as over days, weeks or even months.
All of this comes together when building an open source program that follows the three prime directives for an open source program. The three prime directives are to provide a program that performs a useful task, able to install and run, and have a documented way on how to improve the program. All three of the directives allow people who want to try out or maybe to improve the project can do so without much hassle. By following the three prime directives, an open source project can be improved upon and distributed much more widely than a project that follows only one or two of the directives.
Since the group I was in was trying to implement the WattDepot client into a command line interface, which can show the user the data collected into much more understandable values that provide a clearer picture on energy usage and consumption for a residential complex, such as a house or building; I found out about other groups that were trying to make programs that were trying to implement similar functions. In order to evaluate the project that I was working with, I compared one of the other projects that was similar. The project that I reviewed was called hale-aloha-cli-bking and can be found here.
First things first, I downloaded their project and tried to install the program. It
was easy, following the user wiki in the project site which gave me information about installing the program. The user wiki also gave good information about the project and what the program does, which does several things:
1. Returns the current power in kW for a specific tower or lounge
2. Returns the energy in kWh used by a tower or lounge for a specified date.
3. Returns the energy used since a specific date to now.
4. Returns a list in sorted order from least to most energy consumed between two dates.
After installing the program and running all of the functions, I had found several potential problems with the program in general. Several of the functions provided had adequate error checking, but did not mention what specific error did occur. There were also some smaller errors that could be easily fixed, which I believe is already being worked on.
After reviewing the installed program, I went over the developer wiki to find out about how I could improve or implement any changes to the system. I looked over the guidelines for developing the system and see the style notes that was implemented for the project. I had downloaded the program's code from the project's code repository to review their code base. I rebuilt the program from the code base and tired to understand how the program was developed by looking over the changes to the source code as well as the issues that were submitted. I noticed that the project had implemented several concepts that were good, but they also had some confusing syntax and code that was sometimes difficult to read. I also noticed that several of the builds were not noted with the issues that were supposed to be addressed with the new builds. Overall, the project seemed fairly well documented, but there were some problems that were confusing to understand that could be better explained or written.
After comparing the two groups, it seemed that both groups had communicated and progressed fairly well, but still needed some more practice and work with issue-based project management. Also, I think that given the chance, if both groups were to communicate with each other to test and get outside opinions about their respective projects, then there would be a better end result that would benefit both groups.
No comments:
Post a Comment