Final Thought on ICS 613 Software Engineering

Finally, the semester is over. After taking the ICS 613, here's my final thought of the course.

Positive Aspect:

This is the real-world trainng of software engineering experience. I really enjoy the tought assignments in this class because I believe that is the best way of training myself to become a better software developer. I've learnt a lot of new practices as well as experienced in team environment. The professor, Dr. Johnson, is also very passionate about the subject. I believe that he might had spent a lot of additional time preparing the screencast lectures for the class.

Negative Aspect:

This class is very time-consuming both on the programming assignment and writting the blog. It's both programming and writting intensive. I've spent about 75% of my time working for this class alone. Fortunately, my other classes didn't have much work.

In conclusion, I would recommend this class to every ICS students but also make sure that you don't take two programming intensive classes at the same semester.

Ekolugical Carbonometer 2.1

Ekolugical Carbonometer is a web application that developed in Wicket by team Ekolu. This application is the gateway to data of power grid on the Oahu island. In addition to the improvement of the existing pages (stoplight and grid info) from previous version (1.0), the new version (2.1) also includes three new pages which are Grid visualization, Source summary, and Carbon Intensity page. The section below is the summary of the system improvement.

Main Page: Provides brief description of each pages. Also the layout of the main page has been updated to be consistent with the rest of the system. Instead of wicket URL, the new system also provides the bookmarkable URL for each page.

Current Carbon Intensity Page: this is formerly the Stoplight page. This page use the stoplight to indicate the status of the carbon intensity level of Oahu grid at the current hour. In addition, it also provides useful tips accordingly to the status. The tip is also updated in every ten seconds.

Grid Information: display the power data in chart view. Three major improvements of the page includes the calculation of data period of each granularity option, the use of ajax-style for processing the chart, and the update of chart Y-axis based on the dataset.

Grid Visualization: presents power data in a visualization mode. The system provide user an option to include multiple power data in the chart.

Daily Carbon Intensity: display the daily carbon intensity information of the Oahu grid. The stoplight-mode also available on this page.

Source Summary: displays the summary of each power source. The detail information of the project is available on Google project hosting site under ekolugical-carbonometer.

Project Experience

It's finally a big relief after this project is done. I've been working very closely with my teammate both BJ Peter Delacruz and Wahib Hanani on this project. Each of us very devotes to this project. Personally, this is a great experience for software development. There are a few factors that matter to the completion of this project. We've used the software ICU to monitor the project progress such as the coverage of the system. However, the software ICU doesn't really reflect the amount of actual work for each member due to some administering tasks doesn't monitor by the system. Also, working collaboratively is very important for this groupwork. Though, we have assigned specific tasks to each member, we always jump in to help or shuffle the task so that each member can involve in all part of the system. Last word to say, I will miss the fun working in ekolu team.

Have a wonderful winter break!!!

Review of e-hoomaluo Web Application

E-hoomaluo is a web application providing daily information on the level of carbon intensity of Oahu grid. After reviewing the system, here's the few things that catch my attention. The cool features of the system is the calendar picker which simplify user a lot. It's also prevent user from typing the invalid date. However, the date format should be rearranged to mm-dd-yyyy instead of yyyy-mm-dd. In term of interface design, the date textbox should set to readonly. This will eliminate the issue that user will input invalid date or any random text. Also, the date textbox size should shrink to only the length of the date. I also suggest to have a calendar grid icon for the calendar picker icon, it's more familiar to most user. After waiting for a result to show up, I've got an error message at the top of the page. I was freak out a bit as the message for any date that has no data that goes as "Got a bad result...". The users might interpret the message differently and they only like to see a good result. To gain user's attention, the error message should has some style like red bold text and somewhere in the middle of the page. I do like the carbon-level label which is a good idea to help user to understand the result better. However, the mathematical symbol should be replaced with text as not everyone knows these symbols. In the system documentaion, I think the description of wattdepot package is incorrect. The last suggestion is for the threshold calculation. The system need to filter the hard-coded threshold value with at least another constraint such as time or total carbon emission. My last word for the implementation design, I like the idea to pack the page components in a component package.

Beside my comments above, I also checked the system coverage, reviewed the software ICU, and reviewed the naming style. I don't find any major issue that worth mention here. I hope this review will somehow help improving the e-hoomaluo system. Keep doing great work!!!

Web Application Experience: Ekolugical Carbonometer 1.0

Moving on to the first Webapp project in ICS613, I was assigned to the same group. My teammates are BJ Peter Delacruz and Wahib Hanani. We name the system "Ekolugical Carbonometer". Our goal is to build a web application that displays carbon emission information for the Oahu power grid. The information displays with a color: red, yellow, and green to indicate the carbon intensity level high, medium or low. Additional detailed about the system can be found here. Check the download section, for the appropriate package.

Activity Overview

On the first day, we met in BJ's office to start on the project. I created the Google Project Hosting for the project and updated the build.xml files to reflect the new project. BJ and Wahib both were working on configuring Hudson and Hackystat. During the week, we met three times: twice during the class hour and another standup meeting. We also had one long meeting over the weekend to review and refactor the system. Beside meeting in-person, we also communicate via Skype. Before I started involve in implementing the system, I spent about two days studying Wicket. We don't use the issue tracker very often. One of the reason due to the project period which isn't that long. Instead of waiting for another member to fix issues that we've found, we just fix it right away.

System Overview

Our implementation goal is to give a reasonable result to the users. We don't want users to defer electricy for three days straight or can always use the electricy anytime. For version 1.0, the system computates dynamic threshold for carbon intensity. The threshold for each day derives from the threshold of the previous two days. The system also check to make sure that the red flag will not stay over 12 hours period. The system still need a lot of improvements as some major issues are listed below:

the output still sometime remain green for the whole day which mean the threshold does not quitely accurate

the system needs to refactor

the system needs more tests

Hopefully, the next release will at least address thes issues.

Group Overview

Overall, everyone works really hard on this project. Each member shares idea and participate actively in the project. We have worked really hard to verify the system and ensure that the distribution package will work for the other users. However, due to the complexity of Wicket and time constraint for the project, the delivered product at this stage is not fully satisfied the goal.

Software ICU

Below is the screenshot of software ICU for our system. From the screenshot above, there are two red flags on churn and test. It's because the system doesn't fully test. The coverage, complexity, and coupling look pretty good.

To join the project, feel free to contact one of the project administrator from the project owner list.

Wattdepot Client Version 2.0 (Ekolu)

Finally, we're done!!! During this week, team ekolu has been working really hard to meet the released deadline of version 2.0.

Activity Overview

First of, while BJ and Wahib were updating the current implementation based on the code review's comment, I'd updated the current command specification to meet the specification of the new version. It toke me quite a few hours just to remove one word from the command string and update the index of the string. As I had to update the main class and all the test class, after I had finished two commands, I realized that the current implementation was poorly designed. At least if we had used patten recognition, it probablly not a pain.

Next, there's two tasks that BJ (as a team leader) did. He created a new job of wattdepot-ekolu-daily-build in Hudson and define the wattdepot-cli-ekolu project in Hackystat. Actually, we worked on the last one together in class. As we followed the instruction from Dr. Johnson's screencast of Software ICU, we didn't have any major problem setting up our project.

Later, we moved on to implementing the three new commands below and its test cases.

2.11 fueltypes {source} by Wahib Hanani
2.12 totalpower {source} {timestamp} fuelType {fuelType} by Lyneth Peou
2.13 carboncontent {source} {timestamp} sampling-interval {interval} by BJ Peter Delacruz 

After that we reviewed the whole system to improve the coverage overall as we had a very poor coverage for class (92%), method (73%), block (58%) and line (65%) in the first version. In the reviewing process, we had also done a lot of significant improvement to the system.

Also, we'd worked together to solve the questions in part B, posted here.

Lastly, we had another round of testing and verifying the distribute package before posting the package.

System Satisfaction

The version 2.0 of wattdepot client by team ekolu includes the following updates:

created a new class for quit command and its test case

splited the method of ChartPower command (2.10) into its own functionality

reviewed the exception block

added more test cases for each command to satisfy the coverage overall; in which most part that wasn't cover is the exception block

also cleaned up the unused code

At this point, I really satisfy with the released of the version 2.0. We had taken care most of the issues raised by reviewers especially George Lee gave us a bunch of constructive comments. The code coverage of this version is pretty good.

class: 97%
block: 97%
method: 75%
line: 79%

However, I think the quality design of the system is still average in term of the current implementation of processing the string input and the exception. Also, we have not implement a good mechanism to process the exception at this version.

Group Interaction

During this week, we met 3 times and communicated through skype for most the time. I think the communication via skype was very productive. The partition of the work in this round was not overload to the team leader as the first version. Each of us work on one new command and two questions. Of course, I had been working on this project everyday and for this version I've spent about triple time I worked on the first version.

Experiencing Software ICU

Below is the screenshot for the first and last day of software ICU for wattdepot-cli-ekolu. During this week, we've been using software ICU as a tool to monitor the project health. I think from the two screenshot above, we've been doing a lot better than we first started; the coverage is high, the complexity is low, also the devtime is high. Everyone participating very actively in this round.

Answer to Question in Part B

During November, for SIM_OAHU_GRID

The highest energy usage is 995MW; usually at 8PM every weekday: 2-6, 9-13, 16-20, 23-27, and 30.

The lowest energy usage is 493MW; usually at 4AM every weekday: 2-6, 9-13, 16-20, 23-27, and 30.

The most energy consume: no data

The least energy consume: no data

The most carbon emitted is 29959.193 lbs on the following day: 5, 13, 16, 17, 20, 26, and 30.

the least carbon emitted is 22908.58 lbs on the following day: 7 and 8.

To derive the answer of these questions, I implemented a temporary class that has two methods; one for the energy statistic and another one for carbon statistic question. These methods use the two existing method to create a data set of each hours (for energy) or day (for carbon) and sort out the one that has the lowest or highest values.

Personal Experience

This is a really good setting for experiencing group coding and software development. I think some of the tools that we've been using is very useful such as Subversion that give us a quick warning whenever the system fail.

How Does Code Review Improve Wattdepot Client?

Code review is an informal process of getting some feedback at the early stage of developing software. Code review requires the release of the source code to the selected reviewers. Also, the reviewers are required to thoroughly test the functionality of the system, verify the system documentation, read the source code, and evaluate the performance of the system. Of course, the goal of code reviewing is to catch all possible errors and bugs at the early stage.

For reviewers, the most interesting part of code review is getting to learn the others "coding style" while reading their source code as there's always new thing to learn.

After working on the Wattdepot Client 1.0 as team ekolu, my assignment was to review the Wattdepot Client of the other two team; umikumaha and umikumakolu. Actually, the review checklist, provided by Dr. Johnson, is useful such that I know where to begin at. At least there are two common issues I've found to improve my own Wattdept Client 2.0 after the code review.

First issue was the coverage tool does not cover most of the exception code. My first thought was maybe it's normal because it's just exception. After I'd thought about this, the way to tweak the coverage tool might be creating test cases for each exception.

Second issue was the try/catch of a single exception in multiple command classes. As in each command the exception code is about 10 to 20 lines of codes, creating a new exception class by itself will probably eliminate the redundancy code.

Personally, I think code review is a very helpful process to improve the performance of the system as well as to write source code. Sometimes we're only keeping on the main parts and ignoring the tiny parts that in fact could blow off the system unexpectedly.

Code review of wattdepot-cli-umikumakulo

This is the wattdepot client interface of team umikumakulo (or thirteen) by George Lee and Yichi Xu. Below are some issues that I identified.

A. Review the build: the system successfully build.
1. Missing some external libraries in Eclipse due to the incorrect build directory.

B. Review system usage: there is no problem with the happy testing for all the commands.
2. The error message is invalid. The below is error message should be "Invalid source" instead of "Connection error".

>list summary SIM_KAEH
Connection error

3. Also, the system does not validate the input string properly as input string such as the following are also work.

list sourcres!@#@
list summary23
list power232s ... day

4. The empty command issue: the system should let go of the empty command instead of display "Unknown command" message.

C. Review the JavaDocs: there is no problem generating the Javadocs for the system.
5. The description of the main command class is meaningless. For example, chartPowerCommand: Implements the chart command. Instead, the description of this class should be "Creates HTML file representing chart for power generated or consumed from startday to endday.

D. Review the names: there is no significant issuer with the naming convention in the system.

E. Review the testing: the result of code coverage is over 90% for method, block, and line.
6. Mostly the exception block is not covered.

F. Review the package design:
7. The help and quit command should be part of the command package instead of processor package.

G. Review the class design:
8. The commandProcessor is not self-contained because it also trigger the help command and quit command differently from the other commands.

H. Review the method design: after reviewed the source code of the commandProcessor class, I found myself the answer to the issues the I mentioned in part B.
9. Instead, the commandProcessor should check for each term of the input token (maybe just ignore the case).

I. Check for common look and feel:
10. From the Javadocs, George and Yichi refers to the system sometime as "command line interface" or "command handler". Though, it's not so important for the functionality of the system, it still represents some confusion to the user.

11. Also, after reviewing the source code, there exist some uncommonality in the format. Some blocks of the source code space out widely, which make it more clear and easy to read, while some blocks does not have any whitespace at all.

I hope my comment will help George and Yichi to improve the wattdepot-cli-umikumakulo.