In keeping with the topic of energy, I have begun working with WattDepot. Though better explained on the project page for WattDepot, the basic information is that WattDepot provides the capability to retrieve energy data from sensors. Though WattDepot clients may be written in many languages, I have continued to use Java as my language of choice. (At least for programming; English is slightly better suited to entries such as this.)
As with a few previous systems, I have completed a set of simple katas to help in acquainting myself with WattDepot. These are as follows:
1: SourceListing: Connects to a WattDepot server and prints all sources on the server with their descriptions.
2: SourceLatency: Connects to a WattDepot server and prints all sources on the server with their latencies, where “latency” is defined as the time elapsed since the last measurement was taken.
3: SourceHierarchy: Connects to a WattDepot server and prints the hierarchy of the sources. This is possible through the use of virtual sources, which combine the input of multiple physical sources to produce a result that may often be more useful for real-world analysis.
4: EnergyYesterday: Connects to a WattDepot server and prints all sources on the server with the total amount of energy each source consumed on the previous date, sorted in ascending order by energy consumption.
5: HighestRecordedPowerYesterday: Connects to a WattDepot server and prints all sources on the server, sorted in ascending order based on highest recorded data for the source.
6: MondayAverageEnergy: Connects to a WattDepot server and prints all sources on the server with the average energy consumption on the past two Mondays for each source.
To start from the beginning then, SourceListing was a moderately difficult exercise. This difficulty is primarily the result of being unfamiliar with a new system. Once I knew what resources I had, actually completing the kata was not terribly difficult. This first kata took approximately an hour to complete.
Next was SourceLatency. However, SourceLatency is practically the same as SourceListing, with only the difference of printing latency instead of descriptions. As a result, the code is essentially SourceListing with a few additions to make it print the latency of all sources. This made SourceLatency perhaps one of the easiest katas, and it was completed well within forty-five minutes, even accounting for time spent going back in to remove various Checkstyle, PMD, and FindBugs errors.
In contrast, SourceHierarchy was the most complex of the katas, and it shows in that it took at least ten hours of programming alone, more than all the other katas combined. A fair amount of this difficulty was due to the way that Source.getSubSources was implemented: since the method returns a String rather than a list of Source instances, some String manipulation is necessary. I somewhat suspect that there is another, better way of working with the subsources, but I have yet to find it.
I also had to learn how the hierarchy worked, and I am still not entirely certain on some points about the hierarchy. For example, if B is a subsource of A and C is a subsource of B, then by transitivity we can deduce that C is a subsource of A. However, I do not know if the getSubSources method would account for that or if it would only return those sources that are immediate subsources.
My solution to printing the hierarchy involved a recursive method. This method keeps track of the “depth” that the current source is at; that is, how many levels of subsourcing lie between the current source and some root. I am not quite certain how I got the idea of using recursion, but by last Thursday I was already thinking of it even though I would barely have been working on it at that time. Although I am rather proud of the method and of thinking of it myself, I am not certain how efficient it is compared to a more linear algorithm. Then again, the recursive certainly seems a lot better than any of my other plans, which would have involved messy processes requiring multiple arrays to store sensor data and hierarchy depth.
After that intensive process for SourceHierarchy, I then moved on to EnergyYesterday. EnergyYesterday required that the list of sources be sorted based on the energy consumption of the sources, so some sorting algorithm was necessary; I chose merge sort, and thus a variant of it appears in my code. This kata was also where I began to notice the problems with having to deal with a server. If I constantly made calls to the server for sensor data, the chances of some error occurring would increase, and so my code only asks for data about the sensors once. The data is then stored in a String, actually the very same one that would be used for output. Though not as intensive as SourceHierarchy, EnergyYesterday still took about two hours to complete.
One bit of code that I am still annoyed with also started in EnergyYesterday, though I did not truly realize the problem until getting to MondayAverageEnergy. In order to calculate the energy consumed in the previous day, it is necessary to know what and when the previous day is. Since WattDepot uses the XMLGregorianCalendar class, I decided to do the same. Unfortunately, as far as I can tell the XMLGregorianCalendar class does not automatically fix its values to avoid invalid situations. That is, if “yesterday” is in a different month, then the days would have to wrap around and the month would have to be decremented. While understandable, it also results in a large portion of my code in the last three katas attempting to resolve those sorts of issues and prevent them from causing problems.
While SourceHierarchy was the most complex kata, HighestRecordedPowerYesterday was possibly the most frustrating. My original plan had been to test at intervals of fifteen minutes; however, this took up far too much time and the connection to the WattDepot server would invariably time out. Even increasing this to intervals of an hour did not help in all cases. It is at times like these that I wonder if the name is really “What Depot?” insofar as the server never seems to be working when it has to. The solution that I implemented placed a try-catch statement to handle the cases that did time out through making a new connection to the server and moving on. This is perhaps not ideal, but it works, and the user does have a message informing him or her why about half of the sources do not have a valid power level. It might have been a good idea to shift some variables around so that the list gets whatever was the highest power consumption and time for that source before losing the connection. Another issue, though less significant, was the formatting. It was necessary to print out the times at which the highest levels of power consumption were; however, the String#format method was uncooperative and would refuse to accept certain conversion characters. This also led to a brute force solution where I simply took care of that formatting myself instead of using the format method. In the end, HighestRecordedPowerYesterday took about two and a half hours to finish.
Finally, MondayAverageEnergy was very similar to EnergyYesterday. The process of gathering data was almost exactly the same, the differences being that it was necessary to gather data from two separate days and that it was necessary to extend back even further than just a single day to find data. This helped find some of the problems in EnergyYesterday: while it is quite easy to miss the wraparound error described above when you only have to move back a single day, missing the same error when one must look through up to fourteen days in the past becomes quite difficult. Unfortunately, also as described above, the solution that I found is rather awkward. MondayAverageEnergy took a little over an hour to finish.
Despite all the difficulties, the programming and problem-solving processes themselves were quite enjoyable. There are certainly some issues in my solutions, and working on some of the code past midnight historically has a negative effect on the quality of my work. However, the additional experience with Java and Ant is in and of itself valuable; the fact that this work has some practical value makes it even more important.