Oscar WebApp Code Review: WattWaiter

For this assignment we are doing code reviews on our fellow classmates' Oscar web applications. I am reviewing team WattWaiter with Remy Baumgarten, David Mau and Kevin Chiogioji as members. This review is based on a new checklist that has some new points that includes Wiki Documentation, Software ICU, Issue Management and Continuous Integration.

My overall feel of the application is that it was designed, both the program and the application interface, very good so much so that it could almost be passed as professionally built. The negative things I have to say are mostly nitpicks that this checklist looks for. Other than that it was a very robust application.

The full review can be found here.
The WattWaiter web app can be accessed here.

Ecologineers: Oscar Web Application

As we continue along working in bigger teams, we explore more and more on how to develop applications. For this assignment, my group from the previous WattDepot project got teamed up with another two man group. Just like my original group, we all worked perfectly together. We set up plans, delegated jobs and met up regularly. I had as much fun on this project just like the last one.

As for the project itself, it was very daunting at first to hear that were going to learn a new framework that were going to use for this project. Our professor repeatedly reminded us the importance of this framework during lectures and especially at the project screen cast. The reading (Wicket in Action by Martijn Dashorst and Eelco Hillenius) alone was a little hard to comprehend but just as other languages, you learn by doing it. We were given some example applications to show us how the new framework works. As we progressed on our project we quickly learned that Wicket wasn’t as bad as we thought it would be. It turned out to be straightforward. When we tried to implement Wicket with our code we had some small problems. One problem was actually merging the form and table page. We initially planned then delegated the two jobs to two of our people, one of them being me. When we tried to merge the two together we hit some snags where our Wicket tags were not being passed into the HTML tags. Another problem, which I think was a big one, is that our color tags won’t render the color. Since we ran out of time we just left it as is which instead of passing the HTML color it passes the color words instead.


Since we were introduce to Software ICU in the last project. We also implemented it for this project. From the look of the screen shot from above, our coverage was fair since we only had six test cases. Our devTime, Commit, and Build has some steep increase because even though we did the initial set up then met up regularly and discussed the plan, we didn’t actually started to code until weekend.

All in all I really enjoyed working on this project and not to mention with my group. I really got a feel on how to develop real word applications. This is also a good project to learn good sustainability practices since any user can download, run and use our application to help decide when to use or not use an appliance.

Our project site can be accessed here and our distribution file here.

WattDepot-Cli 2.0: Second time is the charm!

As we wrap up on our WattDepot-Cli project we gain more perspective on how the software development works. In this assignment we are to update, improve and add new commands to our version 1.0 of WattDepot. We are still working with our initial partners and as for our group, it has never been better. Even from the start of this project my partner and I communicated every other day and delegated jobs. Our jobs weren’t so concrete which gave us a little flexibility so that we can do other things outside of this class. We also met twice a week not including the time we spent working on our projects in class. All in all my experience with my partner in producing the WattDepot client was a pleasant one.

In terms of our client, we have improved our methods by reviewing the changes in the commands provided in the WattDepot wiki and suggestions coming from last week’s code review. One of the things we did was to add the necessary comments and improve our Javadoc so that any developer can understand our code and use our API for reference. We also have added more test cases. Most are still happy-path tests but now we’ve included some behavioral test such as our validation tests. Even with more test cases our coverage is still under the healthy 90%. Our coverage is 63% because some of the new commands and old commands didn’t get tested. Other than the coverage being low, we did find that writing test cases was much easier when we refactored the commands into their own classes.

As for new materials that we learned, we used a program that displays the current condition of our program. It is called Hackystat. Hackystat retrieves information from our local and Hudson builds and the amount of time we spend in Eclipse. It measures and displays different categories that are pointed to the overall health of our program.
Here’s a screen shot of our program information.

The overall health of our program is a little stable. The reason for this is because of the lack of testing (30%) which consequently affected the coverage. The screen shot also shows the increasing trends of our development time commit and build because we worked on it mostly on the last four days before the due date.

The last part of this assignment is to answer some question regarding information that we gather from our program.

• 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?

Unknown

• What day during the month did Oahu consume the least energy? How many MWh was this?

Unknown

• What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?

4th, 5th, 16th, 17th, and 30th of November. 29,959 pounds of CO2 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?

7th and 8th of November. 22,908 pounds of CO2 were emitted.

Our Wattdepot client version 2.0 can be found here.

Code Review: A subtle but rewarding learning experience

Some people might not like the fact that their code is to be reviewed or to be the person who does it but I believe that there is a rewarding experience that results from this experience. I, for one, value the effort a person did to look how our overall product came out to be, some of which say that we didn’t commented enough for them to understand our code. Besides having a working system, our class’s third prime directive states that our code should have a good developer-level documentation that provides the inner workings and therefore should make it easy for them to understand and expand. This is particularly true in our assignment which taught me a valuable lesson since we have to create our user interface client upon the WattDepot system. The documentation on the WattDepot system helped us implement the commands that were assigned. Another comment I took into consideration was the design which didn’t really surprised me since we didn’t follow the design requirement. Our system grouped all the commands into one class instead of having each one of them in its own class. This is particularly an important point since it restricts our system’s extensibility. This design is now an important part because we are adding more commands into our client and this task would’ve made our jobs a lot easier. This I also think that the checklist that our review is based on also helped on how I will improve our client. All of our command methods are expressed to have “side effects” and therefore is a design problem that we have to address.

Overall I found this assignment worthwhile. Having another person not just examines but also gives suggestions on how to improve our system is a good way for me to actually be a good programmer. Not only did I have fun working with my partner but I also enjoyed reviewing other people’s system and hope that they find it helpful.

WattDepot Client Code Review

After working for more than a week on the WattDepot client, we have to review our fellow classmates' client for this assignment. This review is generally a way for us learn how to both give constructive criticism based of a checklist and apply them to our existing code to improve upon for our upcoming updated release of the WattDepot client.

Eha
In general the client works good, it does what it supposed to do. Some of the things that I find a little weird was the chart output which has some rather small points and therefore a low chart considering that given the same arguments other clients produced a proportional chart. As for the design, the only thing is that it did not followed the design requirement of having each commands in it's own class. This is important so that the client supports extensibility considering our next assignment will have new commands.

The full review can be found here.

Elua
When I first tried to review this group's client I had some problems some problems such as not being able to run the jar file. After using Eclipse to run the client I encountered a bigger problem, for some reason only the 'help' and 'list summary' commands work and the rest didn't especially 'quit'. After some time they released a second version which only fixed the non-executing jar file and from that second build I based my review. Their client followed the proper requirements and all their commands worked perfectly. Their test cases were also some of the things that they have done a good job.

The full review can be found here.

Full Scale Software Engineering Project: WattDepot

Continuing from my recent post about a new concept we learned, we get our hands on an interesting programming practice called Continuous Integration. For this assignment, we were partnered up and create a command line interface for the WattDepot system. WattDepot is a web service that collects information about Oahu’s energy and power production/consumption. My partner, David Joel Lazarro, and I had to implement various commands to be used on the stored WattDepot data. We planned on splitting the commands in two and as we started working on our commands, we got our first experience of practicing continuous integration. We initially didn’t get the hang of it. We rarely commit to our repository, waiting until a full working method, both tested and verified locally, before committing our changes. But as we progress in this project we learned how to properly practice it. We did have some problems such as fixing merge conflicts since we didn’t really have any set design plan. As our code continued to grow, we finally found a good rhythm that tied our code into a unified look.

As for WattDepot, we implemented all the commands that were assigned. This is one of the first times where I had to build on someone else’s code in this scale. Having a good documentation and API really helped me understand the inner workings of the WattDepot system. This reinforces the importance of the third prime directives first taught in this class. The commands were mixed in terms of implementation difficulty, but I noticed some recurring similarities within some consecutive commands, which made the whole thing not so bad. Halfway through our given time for this project we were told improve our design strategy and implementation. This threw us of a little. The new strategy is meant to improve the scalability, reusability and efficiency of the command line interface. My partner and I understood the design strategy that was shown to us and we tried to implement it but to no success. This is the reason why we didn’t really have some good test cases for this project. The new strategy could’ve helped us design better cases instead of having just acceptance tests. Our methods were designed in way that it is constrained by the parameters preventing us from testing the instances of commands. This would’ve been easily implemented if we followed the new strategy’s design of having the commands in separate classes.

All in all I thought this project gave me an insight to the world of software engineering. Planning and implementing this project was just as fun as meeting up and working with my partner. I also thought that having a project that teaches us the importance of sustainability, especially in these times, is a cool way to really get our attention.

Our distribution file: Ekahi.

Continuous Integration

For this assignment we were introduced to a new practice in software development called Continuous Integration. The main objective is to commit changes frequently so that any errors are quickly detected and easy enough to solve. This builds the repository gradually instead of committing a huge change that it doesn’t look as the original and committing these changes can lead to clobbering of update changes.

To practice continuous integration, we are using Hudson. The creation of a new job within Hudson fell to my partner. From what I saw him do, the set up went good and we were up and running in no time. The other tasks that fell onto me were to initially build within Hudson and then create a small change from my local copy and committing it. This ensured that Hudson detected the changes and it worked as such. The next task is to commit a broken code and check if Hudson’s build report shows a failed build. I then received an email report saying it did so. Lastly, we fixed the bug and committed the changes and made sure that Hudson’s build is back to normal.

After a couple of days of using Hudson and practicing continuous integration, I find it as something I would definitely use in the future. Besides the automatic email notifications of any build failures, I find the logic behind small incremental changes as something that can improve any team based projects. This approach reminds me of the divide-and-conquer strategy which applies to the planning and then implementation of creating software.