Sunday, November 27, 2011

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. 

Tuesday, November 8, 2011

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.

Tuesday, November 1, 2011

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.