Tuesday, November 24, 2009

Greenometer Review

After finishing up our very first Group project in Wicket, it is now time to review other people's work. I was assigned to review the Greenometer project. I would have to say that I was most impressed with their graphical interface. It is needless to say one of the most impressive looking project in class and their use of Google chart tool made the system a lot more user-friendly.

I would say that the system fulfils most of the project requirements. It does what it is supposed to do in a very neat fashion. I liked the addition of the traffic light object which indicates the current carboncontent level. Their source code was nicely organized into 3 packages with each of them having a specific function. I noticed that there were some files in the system that contained functions that were never being called. I am not sure why the functions are there, but I would assume that taking those functions out of the source code would increase the code coverage data in Hackystat significantly. I also suggest making test cases which tests for failure cases. This should cause the system to call some of the catch{} statements and should increase the coverage data even further.

Their Hackystat and continuous integration data indicates that they correctly configured the system to perform daily builds and regular builds after each commit. Their data also shows that they have committed their changes regularly and also shows that each person in the project have contributed to the work fairly well. The only problem with the data was the low Test values due to missing test cases, which can be easily fixed in their next version. I would say that Greenometer group did a pretty good job with the project, and I sure hope they keep up the good work!

My project review can be downloaded here.

Monday, November 23, 2009

Eco-Depot 1.0 Release

Our new Eco-Depot project is sort of an addition to our previously build WattDopot program. The new project implements the Wicket language which is used to connect Java with an html page. Wicket proved to be an extremely useful tool, while it was very difficult to learn initiallly. I am not sure about other people, but it took me hours of reading the "Wicket in Action" to finally understand how to use this new tool. It seems as though that I didn't have enough time to actually use this new tool to its full potential, as the code I punched out seemed that it simply does what its supposed to do.

This was also our first project to work in a group of 4. I was initially excited with the idea, though as time went on, and after realizing I had many other classwork to complete over the same week, it turned out to be quite of a stressful experience. I realized that we were very late in staring our project, and that we could have started much earlier if we had communicated better. I am not sure if it is because the team size got larger, but we weren't able to communicate with each other well, which delayed our project significantly.

One big mistake that we made in my humble opinion is that we never discussed about the design of our project thorougly. As I began working on my part of the project, I realized that I had no idea how other teamates wanted the project to look like. It was already late in the week so I decided that I would write down my initial design and commit the change, and see if everybody likes it. I am still not sure if that was a good move, but it was a move atleast, that was all that mattered to me at that point.

The rest of the project I think went rather smoothly, compared to how it was earlier.
The only problem was that I had work on a different project while my team-mates were working intensely on the project. I got lost momentarily then, but other than that the project came out quite well I believe.



I liked how our project came out, and I hope that for our next project we can improve on our teamwork a bit more. Our project "Eco-Depot" can be downloaded here.

Monday, November 16, 2009

Wattdepot Version 2.0

It is now time to release the version 2.0 of our Wattdepot program. In this version, we implemented some brand new commands that a user can work with. We also improved our code in many different ways. We have implemented a few more interfaces to make the code clearer and easier to read, and we have also implemented hash code so that we can map a class instance into a string literal. This way, our code looks a bit nicer and now it is somewhat easier to make modifications if need be.

My WattDepot Version 2.0 can be downloaded Here.

We had numerous problems trying to transfer all our methods into separate classes however. It seems that rewriting our code in this style was not an easy task. I ran into numerous problems with variables and class instances. When we managed to put together, we realized how easy and simple the program looks.

We were also asked to asnwer some questions which can be derived by using or tweaking some of our commands. Following are the questions:
  • What day and time during the month was Oahu energy usage at its highest? How many MW was this?
** During most of November the usage seemed to be at the highest. My value came out to be 1630 lbs Co2/MWh
  • What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
** Minimum value occurs throughout early morning of November. The value was around 1597 lbs Co2/MWh.
  • What day during the month did Oahu consume the most energy? How many MWh was this?
** So far the most energy consumed is 1630 lbs Co2/MWh.
  • What day during the month did Oahu consume the least energy? How many MWh was this?
** So far the least consumed energy is at 1597 lbs Co2/MWh.
  • What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
** Dirtiest carbon were emitted at November 4th and 5th, with value 29959 lbs.
  • What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
** Least carbon were emitted at November 7th or 8th at value 22908 lbs.

Wednesday, November 11, 2009

Review Experience

This week's coding review have helped me a lot. Looking at other people's code and to see how they approached the project was very interesting and a good learning experience. While viewing others' codes, I sometime wondered to myself "why are they writing it this way" or "how can this be efficient?", but as I took my time and began to figure what that piece of code actually doing, I oftentimes thought to myself that what they are doing is actually a more efficient and organized way of coding.

While I was reviewing other people's codes, I cannot help but to notice that most of the codes were very well documented and commented. This struck me because I could not remember if I documented my own code that well. All I could remember about my code is that I rushed through it in an attempt to finish up all of the commands. Now I know that if there are improvements that can be made into my code, one of them would be to add more documentation and comments. I thought most of the code I reviewed was very well done. Even though their code may not have the full functionality of the commands, its interfaces and such were build quite well.

I would have to say that viewing somebody else's review about our project was also very helpful. It seems that everybody who was assigned to do our project review have completed it, and they did a very good job. I have learned through looking at some of our review that we still need to work on our interfaces and class structuring. This seems to be a somewhat of a difficult task, but since now I have a better idea of how to structure our code, I think we can do it. This code reviewing overall was indeed a very helpful experience.

Monday, November 9, 2009

My WattDepot Project Reviews

Punching out lines of code while your brain is in your programming mode feels great, and one cannot help but to assume that the codes you just typed out was perfectly written. Unfortunately this is not always the case, and it certainly helps to have other people have a look at your code to make sure that you have punched out a quality code.

Our assignment for this week was to review other group's projects. For this task we followed this guideline to make sure that we have checked every part of the project. Interestingly, our professor instructed us to be as evil as possible when reviewing certain parts of the project, especially when it comes to checking for bugs. I started by compiling the code, and running it with variety of different inputs to see if the code checks for input errors. Following are the two projects that I reviewed.

elima
eono

Wednesday, November 4, 2009

WattDepot

WattDepot is an interesting project that we have been working on over the past week or so. Its function is to retrieve various useful information such as energy consumption, carbon emission, or power consumption from the WattDepot server. My experience with building the WattDepot program was a valuable one. It seems that the world is headed towards the notion of energy conservation and knowing how to deal with this type of application certainly would benefit us in the future.

This WattDepot project turns out to be our first real group project this semester. As our class exercise, me and my group mate discussed about the overall design of the project and also about how we wanted to work on the project and when. I feel now that it is really important that we discuss the details of the project before we start touching the code. That way, we can both be sure that we know exactly what to do. It sounds very simple, but it is an important concept.

Building our project was not an easy task. The assignment basically was split into 10 parts, or commands. My group mate and I decided that we will split the work in half and this idea turned out to be quite efficient. The only problem we had with building our commands was that it was fairly difficult to check if the output we got was indeed the correct one. Only after checking with other groups we were finally able to see whether the output was correct or not. Although this was quite a bit of inconvenience for us, it actually motivated us to go out and ask around other people about their outputs.

Building our interfaces was a farily complicated task. We were able to set up our project so that it implements multiple interfaces for different set of codes. For example, we set up an interface for class file that contains all the functions that deal with the commands, and we set up another interface for class file that deals with parsing of strings. We were; however, not able to write all of our commands into separate classes, and have the them hash to String variables. We were able to build about 9 test cases that test various functions in our project. I would say that most part of our project turned out fairly well. We may need to work a little bit harder on building the functions into separate classes.

Here is my distribution file.

Monday, November 2, 2009

Continuous Integration

Last week in class, we were introduced to a yet another convenient tool called Continuous Integration. Continuous Integration is a tool that helps us stay in track with our project and reassure that the project in the repository compiles and passes all the test cases. It can also provide you with a graph indicating all of your test case results.

We are going to be using this Continuous Integration for our upcoming project. Our project is fairly big in size, so implementing this tool should help us manage our projcet and keep in track of changes and failures quite easily. We are also using the Continuous Integration tool with hudson. Hudson enables us to schedule periodic builds and tests so that we can be certain that every little changes that we made into the project does not result in unsuccessful builds or failure to pass the test cases. The idea here is that sometimes, running the test cases only once after making some serious changes to the project may not be sufficient. Instead, hudson allows us to continously build and test to make sure that the project is in a good shape.

I am quite pleased with my experience with Continuous Integration and hudson. The set up process was fairly straightforward and I was able to observe the automated build and test almost immediately. I hope to employ this tool for my future project as it is a great tool that reassures that my project is ineed in a good running shape.