Enhancing the BackR

In my last posts, I had covered some concepts about Issue Project Management and WattDepot. While in my last project with two fellow classmates we created a Wattdepot system called Hale-Aloha-cli-Bking, now it was our turn to enhance, not our system, but another system created by a different group.
That group is the "BackR", which I had previously made a technical review about its system. Just to mention the quality of the "BackR" system, I would say it looks quite comprehensive but at the same time very tedious to understand since it uses a wide range of advance functionality (such as Reflection). I had a hard time trying to figure out the overall functionality, since it is more complex than I thought. However, after going through all the code (which took me around an 1 hour), it was pretty simple to implement the three modules, described as follow:


(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.  For example, if lounge Ilima-A used 100 kWh of energy during the hour 6am-7am, then the baseline power during the interval 6am - 7am for Ilima-A is 100 kW.
-------------------------------------------------------------------------------------------------------------
(2) monitor-power [tower | lounge] [interval]

This command prints out a timestamp and the current power for [tower | lounge] every [interval] seconds.  [interval] is an optional integer greater than 0 and defaults to 10 seconds. Entering any character (such as a carriage return) stops this monitoring process and returns the user to the command loop.
-------------------------------------------------------------------------------------------------------------
(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.   [goal] is an integer between 1 and 99.  It defines the percentage reduction from the baseline for this [tower | lounge] at this point in time.  [interval] is an integer greater than 0.

For example, assume the user has previously defined the baseline power for  Ilima-A as 100 kW for the time interval between 6am and 7am, and the current time is 6:30am.   If the goal is set as 5, then Ilima-A's current power must be 5% less than its baseline in order to make the goal.  At the current time, that means that Ilima-A should be using less than 95 kW of power in order to make its goal.
-------------------------------------------------------------------------------------------------------------

After doing a preview of the three modules with my group, we thought it would be simple to implement all those three modules. Yes, it would be simple to enhance in our system, but not in a another group's one. However, having successfully passed the Three Prime Directives (reviewed in my last post), we had a well-code written developer guide for us to enhance the system.

As mentioned by my fellow classmate Sean Chung in his post, he explained how the system strictly enforce the use of a specific number of arguments,  giving us no choice for optional arguments. Sean fixed that, but I ran into another problem. How do we then keep the baseline for each tower after we call the method "set-baseline"? I couldn't save it in the Processor class since every time a user enter a new command, then it would create a new Processor object. I couldn't save it also in the MonitorGoal class, since an instance of every module is created after each command call. So I decided to save in the Main HaleAloha program. I had to use some static fields and methods; otherwise it will have the same problem as mentioned above since I would have to create a new instance of the main class after every "monitor-goal" command call.

It would be great that the previous group would have implemented a database to save the baseline, but I do not really blame them. It was an unexpected issue I had to deal with, in which most of the programmers out there usually experience. Therefore, this debugging experience taught me that how important is to implement something that will be useful to enhance and maintenance the system in the future. Also it taught me how important is to stick to the Three Prime Directives for the best functionality of the software.

Spotlight: the BackR. A Technical Review

Last week I mentioned that I was working on some kind of project with two fellow classmates. So now, we took the role of a technical reviewer. We are now to review another group's project which implemented the system as we did: the HaleAloha-cli. Just in case if someone did not read my previous post, the HaleAloha-cli is a type of command line interface (CLI) which retrieve energy data from some dorms at the University of Hawaii at Manoa  using the Wattdepot Server. I dedicated a post about energy in Hawaii which introduce Wattdepot at the end. Also a post about my experience through some katas in order to learn more about the Wattdepot system using Java. Wattdepot is basically a open-source software dedicated to collect and storing energy data using electricity meters.

The project name I am reviewing is called the hale-aloha-cli-backr (they used "backr" because the three members sat at the back row of the classroom. Ha!), and for more information about the that project, the project page can be found here. The project, as mine also, is worked on using the idea of Issue Driven Project Management (IDPM). This allows the members of the group to break down the project into small tasks called "issues" which has to be update constantly until it is done. Their Jenkins website project can be found here. I think I did not mention about Jenkins in my last post, but it is basically a Continuous Integration (CI) which monitors the repository of a system or application being developed. CI standards propose that all issues must be updated constantly until the issue is done. This will make the developer to constantly work on the project.

While reviewing the system, I will be using the Three Prime Directives guideline.
Prime Directive # 1: The system accomplishes an useful task.
Prime Directive # 2:The system can successfully be installed and used by a new user.
Prime Directive # 3:The system can successfully be understood and enhanced by a new developer.
It is the most standard and frequently used open - source production guideline to review the quality of the system/application. For more information, please refer to my very first blog about the Three Prime Directives, in which I reviewed an open - source application called the "Sweet Home 3D".

So without any further due, lets begin the technical review.

Prime Directive # 1: The system accomplishes an useful task.
To review the first Prime Directive I just download the system, and run the commands. It was fairly straightforward to download the system and use it if you go through the UserGuide wiki page. Just to point out a tiny thing is that it is not necessary to compile the source code. The jar file was there and it was ready to be used. So I don't think the Ant step in the UserGuide should be there, maybe it should be in the DeveleporGuide.

As seen above, all 5 commands/modules were fully functional and were implemented successfully. There were some errors when running with some other towers or lounge which gives me an error saying that the "date is too back in the past". I tried 2011-11-11 and still it gave me that error. Maybe it is due to the Wattdepot server which was shutdown last week and might had produce some kind of lost of data. However, the system did accomplished successfully a task. So Prime Directive # 1 PASSED!


Prime Directive # 2:The system can successfully be installed and used by a new user. 
This time, I inspect the overall hale-aloha-cli-backr's homepage. The main home page clearly explained what the system does (with some nice graphics, a plus). There is a download distribution in .zip file which contains the jar file ready to use without any compilation of the source code. The distribution also does contain a version number (v1 as 12/1/2011) which can be changed when another developer update the system.

The UserGuide wiki page contains precise information about the system. The UserGuide is clearly explained for a new user (maybe someone not familiar with Java or Ant) to download the current distribution and use the jar file. However, as I mentioned above, maybe the Ant step in the UserGuide has to be deleted since the system should be compiled and ready to use for the new user.

Now, I will be testing invalid inputs and check if the program catches all the errors. Below shows a series of incorrect input with their output warnings.

Good! the system caught all the errors I had input. There is just one thing that I think commands should ignore upper-cases. Who knows, maybe someone prefers upper-cases rather than lower-cases, or maybe there was a typo. Nobody is perfect! Ha! And for this particular system it does not ignore upper-cases except for "quit". It is not a big issue, and maybe it was their own idea and design to go with that. Prime Directive # 2 PASSED!


Prime Directive # 3:The system can successfully be understood and enhanced by a new developer.

Now, I will inspect the system as a developer who wants to enhance the system. First I checked the DeveloperGuide wiki page. Easy to follow, but only for someone who knows about Ant and Java. SVN is mentioned but it is not clearly explained what it is. However, it does explain how to run the QA tools and generate Javadocs at the same time. It does also explain the overall structure of the system, explaining what classes are implemented and provide some guidelines on how to enhance the system. 

After that, I went to check the generated Javadoc documentation of the program. It is way clearer than my group system's Javadoc documentation. It is clearly and nicely explained. Naming convention to the classes, variables, etc are very clear and provide a good sense on what they actually do. Overall good job on this part. 

To check the coverage of the program, I ran the Jacoco tool. It covers 82% for overall instructions and 72% for branches. Not bad, since 100% does not imply that it is a perfect system. Then I checked each test cases and it seems that most of them have fully coverage on the code. Each test case is associated to one command/module, so there should not be any problem when enhancement is done by a new developer. Developer will just need to add a new command in the command package and create a new test case for that particular new class command class created. 

Checking through the source code, I will say it is fairly easy to read and follow. Comments were everywhere that allow developer to better understand what the code is doing. Overall, good job on this part also. 

Now checking the issue page on the home page website, there were lots of issues that were taken care of. The issue page shows what task or problem a developer was working on. Therefore, an external developer would know who to contact to ask some question regarding some part of the system. Issues were also clearly stated on what it was about, and it seems that the amount of work were equally distributed since the amount of issues are almost the same. 

Now lastly, checking the CI server (Jenkins) it seems that developers were constantly working on it since there were updates every day, until the Wattdepot server went down. There were three failures in total (no counting when the outages occurred) but it was corrected immediately. Finally I would say most of the commits were associated with at least one issue.   Prime Directive # 3 PASSED!


Overall, the system looks good. As most of the other groups, some enhancement might be needed, but it is working really fine so far. I like also the way the guys implemented reflection to automatically store all the classes when running the system. A truly plus for them. Much more improvement could be done in the wiki pages for more information regarding tools for the developer that will need to use. Good job BackR!

Group Project Management

So over the past two-three weeks I was still coding in Java to learn more about Wattdepot. After I went through some katas to get to know more about the Wattdepot server, this time was more about group-programming. I paired up with other to fellow classmates to create a command interface to retrieve some energy data in one of the dorms at the University of Hawaii at Manoa. 

When I start learning Java (and programming in general), most of the time the coding was done by myself. I did some group-programming in the past, but it was quiet inefficient. However, for this project some useful tools were used, such as the Google Project Hosting and Jenkins. We used the Google Project Hosting as our based-project place to hold our a repository of our system, and also to create issues (updates or processes) regarding the process of the project. Jenkins were used to auto build (using ants) our system and check for any errors. So far, I liked using both of the tools as a way to manage some kind of medium size project. However, what I would like is to learn how to set up Jenkins for future projects. 

We started off the project in the wrong way. We hadn't met up for about 6 days since the first day that the project was announced in class. After the process-review done in class, which was really bad for my group, we decided to start and work as much as we can on this project. In no time, for our surprise, we finish most of the code in less than two weeks. The program was working at perfection and what was left was doing some error checking (user inputs) and QA. We did that and we finished earlier than we expected. However, after the Wattdepot server went down due to some hardware failure, most of our test cases failed. I was kind of pissed off about that, because we basically were ready to submit everything last week (which was the original deadline). And now we have to go back again and check our test cases. 

Overall, I think I learned one thing or two about coding while working in a group-project. There is also a possibility that the project would had taken less time when doing independently. However, I find quiet it motivating to code in groups because you learn a lot from your partners and maybe fixing some bugs can take less time when doing in groups. This had motivated me to continue with my career in software engineering and I hope I can learn more about it. 

WattDepot Katas

If you had read my last post, I wrote that I was going to do some katas about WattDepot. WattDepot is web-server that collect energy data from various places. It is a ongoing project that try to reduce the waste of energy and increase awareness of proper management of the electricity. The data can be retrieved as a XML format and parsed into some form of data that can be analyze and manipulated for research purposes.
I have completed all of the katas, but I really had a hard time doing some of those. I had to do a quick scan through some APIs such as Calendar, XMLGregorianCalendar, Tstamp, Date, and the WattDepot. Below is a summary from each kata I did.

Kata 1: SourceListing

Implement a class called SourceListing, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a list of all sources defined on that server and their descriptions, sorted in alphabetical order by source name.  Use the System.out.format method to provide a nicely formatted list.

• Simplest kata out of the 6. I just did a loop through all the sources from the server. I got from each one their name and description.
• Time taken : 15 minutes.

Kata 2: SourceLatency

Implement a class called SourceLatency, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a list of all sources defined on that server and the number of seconds since data was received for that source, sorted in ascending order by this latency value.  If no data has every been received for that source, indicate that.  Use the System.out.format method to provide a nicely formatted list.

• Things got complicated when I had to retrieve data from each source. For this kata I had to compute the latency of each server for which I need to get the properties from each source by retrieving the sensordata. After I had figure it out how to get the latency, I then had to sort it out in order by the latency. I went back to the Collection API, and I decided to use the SortedMap. SortedMap will automatically sort the keys by their "natural ordering". However SortedMap allows duplicates so I had to do some checking for that. I just create a condition to check if the latency to be stored is already set in the collection. If it is, then I just retrieve the value ( a list of the sources) and just add the new source to the list. 
• Time taken: 1 hour. 

Kata 3: SourceHierarchy

Implement a class called SourceHierarchy, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a hierarchical list of all sources defined on that server.  The hierarchy represents the source and subsource relationship between sources.

• Well, for this kata I think I overestimated it. I thought I will just have to write a recursive method to check all the sources. But wait, what if the next one to be checked is a sub-source of the first one? Then I just delete that one I continue with the rest of list. But what if that sub-source has also other sub-sources?. After hitting my head many times on my desk, I decided to do it a dumb way. I checked that the sources in the WattDepot server I was testing, there is only two level of hierarchy. So what I did is to get all the parent sources first, and then check each of them for their sub-sources. It should work so far until two level of hierarchy. If a sub-source has other sub-sources, my code will  not work properly. 
• Time taken: > 3 hours. 

Kata 4: EnergyYesterday

Implement a class called EnergyYesterday, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a list of all sources defined on that server and the amount of energy in watt-hours consumed by that source during the previous day, sorted in ascending order by watt-hours of consumption.  If no energy has every been consumed by that source, indicate zero.  Use the System.out.format method to provide a nicely formatted list.

• This kata was as bad as the last one. Not of the difficulty of coding it, but I had to look through a bunch of API to get yesterday's date. I spent hours and hours looking through the Calendar API, the Date API, and XMLGregorianCalendar API. Without success in getting the date, I got frustrated and I haven't worked on the katas for the whole last weekend. Sunday at night, I resumed my research about dates API, and came across the Tstamp API. Wow, Tstamp was all I need (and some methods from the DateFormat and Calendar API) to get what I was looking for. After I got the two times (one from yesterday's date at 00:00:00 and the other at 23:59:59) I just used the EnergyConsumed method from WattDepot and compute the energy consumed. After that I used again the TreeMap to sort the list according to the energy. 
• Time taken: > 3 hours. 

Kata 5: HighestRecordedPowerYesterday

Implement a class called HighestRecordedPowerYesterday, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a list of all sources defined on that server and the highest recorded power associated with that source during the previous day, sorted in ascending order by watts.  Also indicate the time when that power value was observed. If no power data is associated with that source, indicate that.  Use the System.out.format method to provide a nicely formatted list.

• If you had done the previous, then this shouldn't be that bad. The problem is with the non-virtual and virtual sources. Non-virtual sources have all the energy data, but virtual sources does not. What I did (as recomended by Prof. Philip Johnson) is to increase the interval of the time (in XMLGregorianCalendar) by 60 minutes. This will get us 24 energy data for each sources. Overall there are more than 1000 data retrieved, so it takes around 4-5 minutes for my code to query all the data. I just used the Tstamp again  (Thanks!) to increase the time. Then I will just create another method to get the time at which the highest energy recorded occurred for each source. This method I had to do a little research also, because I had to convert the current XMLGregorianCalendar format to a Date format. Again I used the another SortedMap with key as the energy to sorted the list, and the value as a TreeMap that stores both the source name and the time.
• Time taken: 45 minutes.

Kata 6: MondayAverageEnergy

Implement a class called MondayAverageEnergy, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a list of all sources defined on that server and the average energy consumed by that source during the previous two Mondays, sorted in ascending order by watt-hours.  Use the System.out.format method to provide a nicely formatted list.

• After going through all the hard work of reading a bunch of times API, this one was pretty easy. After I got the two previous Monday, which is basically almost the same as the last two previous katas, but changing some lines of code, I just computed average of both. Then I stored in the computed average (as the key), and the source name (as the value) in a SortedMap.
• Time taken: 30 minutes. 

Overall, after doing this katas I think I just tasted the bitterness and joy of doing programming. I got so annoyed when I couldn't figure out the solution, but I was jumping around when it worked. I just got also some more experiences on reading APIs, which in the past I barely looked at them. But now I understand that actually looking at every API, it will not only help you a lot, but also will make you write faster coding.

Hawaii: "Go Green" seems so far, but doable.

Hawaii is known as the one of the "addicted" consumer of oil for its daily energy consumption. 77% of energy consumption in Hawaii comes from oil, compared to the tiny 1% amount in the mainland. Because of its addiction to the oil, the cost rate consumption in Oahu is 2-3 times higher than the mainland. Even in neighbor islands, the cost can reach to the double amount of what Oahu residents pay. The reason is that the oil is imported into the Hawaiian islands, and just because of that, oil is way too expensive in Hawaii. Not only that, but if we compare to the mainland, all the states are interconnected among each other. Therefore, exchanging energy among them is possible. However, obviously among the Hawaiian islands, the exchanging is impossible. The islands are separated by the ocean and it would hard to find a way to connect all the of them and share their energy. Each island has its own power supply plant to feed energy to every household in every island, which is rather expensive and inefficient. 

Hawaii do have a way to change the problem of oil consumption. Because of its great nature environment, Hawaii is presented with a vast major opportunities to use renewable energy. Some examples are the solar, wind, biomass, and geothermal energy. However, if Hawaii has those kind of excellent opportunities to reduce the cost of energy consumption, then why not use them? One reason is that those energy production will vary depending of the time and weather. For example, if we produce solar energy, we will need some kind of source to produce energy at night. Or maybe some days we get strong winds, some days not. It does vary. Another reason is the unequal distribution of the renewable energy. An example is the Lanai island that can produces a great amount of energy using wind farms, but actually that energy is more needed in Oahu. Finally, the high cost to build the mechanisms to produce those renewable energy is an obstacle. If it is decided to build those mechanisms, then taxes will be raised and people will most likely complain about it.  

In a way to approach the energy consumption problem, the governor of Hawaii signed an approval to initiate a project that would allow Hawaii to produce its energy using 70% of clean energy by the year 2030. It will be composed of 40% of the renewable energy mentioned above and 30% of energy management consumption. Energy management should be then promoted to all residents living in Hawaii in an attempt to reduce their daily energy consumption. Using fluorescent bulbs, taking the bus or walking to school instead of driving a car are some examples of good energy management that will help a lot in this project approved by the governor. 

Tools for researchs and creating products that allow us to manage our energy consumption are still under development. Good software programs are needed to create this tools. Therefore in an attempt to learn more about energy and software development, I will attempt to do some katas about WattDepot. WattDepot is an open-source software that attempts to contribute to help Hawaii with its energy consumption problem. I will talk about this software later on, and how I did on the katas. 

5 RedBulls = 1 Midterm coming up!

So another midterm is coming up and this is gonna be a really hard one, I guess.
Below is my 5 study guide questions:

1. What are the 6 steps for an Inspection review to be formal?

Planning - Orientation - Preparation - Review Meeting - Rework - Verify.

2. What are the three "classical" problems that might occur during a configuration management?

The double maintenance problem - The shared data problem - The simulataneous update problem.

3. If we set the return value to 1 when we override the hashCode () method, does java complains about it? Is it a good coding or bad coding?

Java will not complain about it, but it is really a bad coding. Because every different objects must have a different hashcode value. However, all the objects will recieve a hashCode value of 1. 

4. What is another build tool that was talked in class, apart from Ant? Give a brief description of it. 

The other tool is Make, which is widely popular than Ant. It can support any kind of programming language. However, its syntax is more complex than Ant, which require a lot of use of the TAB character. 

It is Unix-based.

5.  What are some strengths and weaknesses when doing Manual Quality Assurance?

Strengths: Find defects involving requirements - Low false positive rate.

Weaknesses: Redone for all projects - Difficult approach for low-level implementation defects.

Good Luck to everyone on the midterm!

Cloudy Management for Coding

After a tedious coding for my Robocode that took me days, I had learnt another tools called "Software Configuration Management" and "Project Hosting". Well, if you are a sole developer then you should skip this post. However, take in account that every software project to be successful has to be done in groups and the tool I have mentioned will make life easier for project management.

For this project, I used the "Google Project Housing" and the "TortoiseSVN". Subversions, like TortoiseSVN, helps to maintain current or old versions of coding files, web pages or documentation. It was my first time using some kind of Subversion to manage my Robocode project. It was pretty straightforward in which you can commit changes easily to the whole project at once instead going one file by file. I haven't explored any deeper the TortoiseSVN to check for any available features, but so far I haven't ran into any problems.

Google Project Hosting is like your cloudy place to share your project with any other person out there. I like cloudy stuff, but so far I think there are some flaws in this Project Hosting. First, its wikis markup can be annoying. It is just some minor things, but I think I am more comfortable using HTML. Then, there is the problem when you checked out the project, and committed some changes, there might be another person who did some changes already and uploaded to the Project Hosting. Then the files might be out of sync.

Overall, I think I found SVN as a useful tool for software development that will  help me a lot. Google Project Hosting is nicely formatted to do coding project management, but still there are some flaws, and some improvements need to be done.

Google Project Hosting - SnooPSan's Robocode http://code.google.com/p/robocode-cla-snoopsan/.