Ecologineers Review

The Ecologineers system provides a web application for users to query the Wattdepot database for carbon intensity readings. Readings for each hour are returned with a rating of red, yellow, or green assigned. Based on these readings, users are able to make decisions regarding their electrical usage. My job was to perform a review of the Ecologineers system. My full review of the system can be found here.

I found that the overall functionality of the system was good. The system met the functional specifications. It returns the reading and rating of a specified day's carbon intensity in hourly increments. A UserGuide, DeveloperGuide, and ReleaseNotes were provided on the project website. The design and implementation is good, however, the visual aspect of the web application could be improved. A more visually appealing user interface could be implemented which would greatly improve the web interface. There were a few bugs in the system such as entering a year that is far in the past or a year in the future. The testing implemented seems to only check "happy paths". Adding tests that check bad input and the functionality of the web application would further ensure the quality of the system. The Ecologineers team did a good job of not letting the system stay in a failed state for a long period of time. The "health" of the system was moderate. The group seems to be functioning ok, however, it may benefit from starting earlier on the development of the project. This could help improve the project's "health" by raising the churn and commit statistics.

Wattwaiter 1.0

Wattwaiter is a web application that allows users to query the Wattdepot database to determine carbon intensities for a given day. By obtaining this information, consumers are able to make educated decisions about electrical usage. Wattwaiter provides a visual breakdown of the carbon intensities by hour. Colored flags are assigned to each hour to indicate the intensity. The flags are colored green, yellow, and red which correspond to low, moderate, and high carbon intensities respectively. We hope by providing this information to consumers, they are able to adjust their electrical usage and become "smart" consumers.

Using Wicket was difficult for me because I don't have much experience in creating web applications. Luckily, other members in my group were more experienced and able to help me understand how it works when I got stuck. Wicket in Action was a good resource that explained how to accomplish basic tasks using Wicket. Also, I found the Wicket examples to be very useful. They allowed me to view working code that demonstrated how to create different components. I also had to familiarize myself with HTML. Now, I have a basic understanding of HTML and Wicket that I hope will grow as the project progresses. Overall, I felt that the project went well.

I feel that the design of our system was good. We were able to accomplish the goals of the application without making use complicated. It is simple for users to query different dates and interpret the data that is returned. This is an important aspect of the project, so users will not feel it is a hassle to use.

I feel that our group worked well together. We all contributed to the design and implementation of the project. Having several different perspectives helped to improve the design of the system by considering different approaches. Also, our communication was good which helped everyone stay on-track.

Shown below is a screenshot of our software ICU from Hackystat. By observing the metrics, it can be seen that there is room for improvement. The areas that need improvement are churn and testing. We will put more focus on these aspects during the cycle of the project.



Below is a link to our project website where guides on Wattwaiter and a distribution of the system can be found.

Wattwaiter 1.0

Wattdepot Version 2.0

The goal of the Wattdepot-CLI project was to create a command line interface that could access Wattdepot and return useful information to users. This information could then be used to improve electricity usage of consumers.

Wattdepot 2.0 is the second release of our command line interface. Wattdepot Version 2.0 features 3 new commands in addition to the previous commands that were originally released. Our initial version used the correct structure for the program which made creation of Version 2.0 much easier. The most commonly observed weakness of our original program was insufficient Javadocs. In Version 2.0, we improved the Javadocs in order to make the API easier for other developers to understand. The testing that was implemented for each command verified not only happy paths, but also covered input validation and exception checking. Our coverage was decent at 82%, however, there is still much room for improvement.

In order for this project to be successful, it took teamwork and dedication. We met in person as often as possible and regularly on IRC to discuss progress of the project as well as issues that arose. We divided the work evenly between the group members which ensured that each member was participating. I felt that all members of the group carried their weight. Each member's work was critical in the success of this project.

Hackystat is a software ICU which tracks the statistics of your project in order to ensure that you stay on track. It provides information dealing with the automated quality assurance tools we have been using as well as ANT and Eclipse. Hackystat also provides a visual summary of the projects "health". At a glance, developers are able to see the "health" of their project in order to keep a project's progress in the right direction. By looking at our Hackystat metrics, our project's "health" was decent, but our testing statistic could use some improvement. Our project's Hackystat chart is shown below. Click on the image for an enlarged view.



Below are the results to some queries that were executed using our Wattdepot-CLI.

What day and time during the month was Oahu energy usage at its highest? How many MW was this?
November 2-6, 9-13, 16-20, and 23-27 all had a usage of 995MW

What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
November 2-6, 9-13, 16-20, 23-27 all had a usage of 493MW

What day during the month did Oahu consume the most energy? How many MWh was this?
There was no data found for this.

What day during the month did Oahu consume the least energy? How many MWh was this?
There was no data found for this.

What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
On November 4, 5, 16, 17, and 30, 29,959 lbs of carbon were emitted.

What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
On November 7 and 8, 22,908 lbs of carbon were emitted.

Software Review Experiences

Peer reviewing is a process where other developers review your code and provide comments about good and bad things that they find. Performing these reviews is not only beneficial to the project that you are reviewing, but also to yourself. Peer reviews are a great way to help other developers improve their code while improving your own skills at the same time.

While performing reviews, we are able to practice our code reading and understanding skills. These are important skills to have as many large projects require working with other developers. Being able to read and understand other's code makes you a valuable team member because you are able to help others when they run into problems. I was also able to view weak points in other programs. By taking note of areas that other projects need to improve, I was able to see areas in my own project that could use improvement.

There are many ways to write code to accomplish a certain task. Everyone's mind works differently, so people usually go about doing things in different ways. It is useful to observe how other people solve a problem as it is difficult for one person to think of all solutions. By reviewing other developer's code, we are able to learn new techniques that we can add to our own arsenal. This helps us to continually grow as programmers. While performing the reviews, I saw different ways of solving problems which made me re-think my solution. I think that a best solution is often produced by combining the good parts of many different solutions.

I was able to learn a lot by reading comments about our project. The information provided was very useful. Reviewers were able to find flaws in the program that we were unable to find during our own code review. We were also able to get feedback about which parts of our program were difficult to understand. The ability of other developers to understand your code is as important as the functionality of the code itself. By fixing these issues, we will improve the quality of our program and take one step closer to accomplishing Prime Directive Number 3 (an external developer can successfully understand and enhance the system).

I found peer reviews to be a very useful tool. It provided insight into other's code as well as my own. Performing reviews is great for learning new ways of accomplishing tasks while helping out fellow developers. Reading other's reviews of your code can give you insight into what other people see when they look at your code. If we let it, the information provided can show us different views which can help us improve our skills. In order to continue to grow as programmers, we must have an open mind.

Wattdepot-CLI Review

After creating our Wattdepot-CLI, we were tasked to perform reviews of two other groups projects. The criteria for the reviews were provided and can be found here. The two projects that I reviewed were for Eiwa and Umi.

Eiwa - The project was able to be built successfully and all the commands were functional. Some changes may need to be made to either the help menu or the command names as they do not match. Different classes were created for each of the different commands. The JUnit tests implemented were good, however, additional testing needs to be implemented for the remaining untested methods. Some reorganization may need to be done. The full report for this project can be found here.

Umi - The project was able to be built successfully and all the commands were functional. Reorganization of the commands should probably be done, so multiple commands are not implemeted in a single class. Also, this project may want to seperate the command line interface and the commands into seperate packages. More test cases need to be generated to provide sufficient checks of functionality. The full report for this project can be found here.

Watt Depot CLI

Watt depot is a service that collects and stores electricity data. Tools can then retrieve the data and analyze it for consumers. Consumers are able to use this data to become smart consumers. By observing data trends, consumers can adjust their usage. By knowing when off-peak demand times are, consumers are able to use electricity during lower demand periods to lower their electricity bill. This also benefits the electric company by reducing demand.

Developing a Watt-Depot-CLI was a challenging task. There were several different commands that needed to be implemented. The commands can be seen here. Learning the Watt Depot API to complete the CLI was a task in itself. There were many different methods that we needed to understand in order to implement the commands correctly. At first, progress was slow while as we were still getting accustomed on how to accomplish certain tasks using Watt Depot. As we got more experience working with Watt Depot classes and methods, it became easier and we increased our productivity. We were able to successfully implement all the commands.

Testing was a large part of this project. In order to ensure that our commands were implemented correctly, we created JUnit tests to validate inputs and outputs. These tests are particularly useful during development to ensure that previously written code continues to work correctly.

This was our first project that required working with a partner. This was much different than working alone. In order to have a successful project, you must designate work and ensure that you understand each other's code. Luckily, communication was not a problem for our team. We were able to coordinate meeting times to discuss the project as well as communicate through IM. I felt that this was a crucial factor in the success of our project. It allowed us to discuss issues that came up and brainstorm feasible solutions. Without good communication, our progress would have been much slower and our product would not have been as good.

We split the project up fairly evenly. Each of us developed code to implement the commands as well as tests to verify their functionality. Although the work was divided, we ensured everyone knew the status of the project by committing frequently. This not only allowed us to follow each other's progress, but also help each other when issues arose. This strategy worked out well for us. We continually had forward progress and when a roadblock was hit, we had someone to turn to for help.

Through this project, I was able to learn not only about coding, but also teamwork and time management. Teamwork was a critical part of this project as we were dependent on each other in order to complete the project successfully. Time management was crucial to allow us to work at a lower stress level. I found that by working hard at the start of the project, we were able to make changes to our design without much stress. Although I still have a lot to learn, knowing some of the skills that are needed in future development projects will be very beneficial.

Hudson the Watchdog

Continuous integration is a software development practice where members of a development team integrate their work frequently. Work is integrated at least once daily. Then, an automated build tool is used to verify the integration. This detects any errors/problems with the build quickly. By integrating frequently, it allows software to be developed faster with less integration problems.

Hudson was used as the automated build tool for our watt-depot-cli project. Hudson was configured to use SVN to poll for changes made to the project repository. If changes are detected, it does an automated build of the project to ensure that it is working correctly. It also sends out email notifications if a build fails. This allows developers to be aware that something is not working correctly and that it needs to be fixed. This is good so that files with errors in them are not downloaded by other team members. Sometimes, a developer may forget to verify a build before committing to the project. Hudson prevents a broken build from going unnoticed for long periods of time.

I was able to see the benefit of continuous integration with my project by observing what happens when conflicts occur. When there are conflicts, the amount of code affected is usually minimal because the differences between files are minimal. This makes conflicts much faster and easier to resolve. The longer you wait to integrate, the more differences there may be which can make resolving conflicts a long and painful task.

One bad thing about continuous integration is that sometimes it gives a false sense of how a project is progressing. Sometimes our team was working on developing a new feature for the project and wanted to help each other fix problems with the code. We uploaded the code through SVN, knowing that there were problems with the code that we were working to resolve. A failed automated build was performed and logged on the Hudson server. This added to our cumulative build count which made it appear as though our project was having issues by the storm clouds that appeared next to our project. An outsider looking at the statistics may conclude that we are having problems with our project even though this was not the case.

Overall, I found continuous integration to be a useful practice when working with a development team. It makes integrating changes much quicker and easier. I also found that the automated notifications that Hudson sent to be useful. This is a very useful technique that I can see benefitting many future projects.