A peek at other peoples code.

I was able to review another group's project code and see what they had done. It was very interesting to actually examine all they had accomplished. It made me even more determined to improve my group's work and get coding!

There are a lot of different details to consider when reviewing a project. My professor very eloquently wrote the list for it in his website. These are the main points.

• The build
  
• System Usage
  
• Javadocs
  
• Naming conventions
  
• Testing
  
• Package design
  
• Class design
  
• Method design
  
• Overall feel and look of implementation
  
• Documentation
  
• Software ICU data
  
• Issues management
  
• Continuous integration
  

Take a look at the review I wrote based on these criteria. Link.

I felt that Ecologineers' web application was at the brink of success. This group has done good. They managed to produce a web application that worked. Although they need to polish their implementation and their user interface, they're on their way to creating a solid application.

GreenDepot 1.0 , but not quite

It's my very own web application. This week through the work of a group of me, Edwin Lim and Nathaniel Ashe, we were able to create a humble web application that dealt with carbon density during a 24 hour interval. It's a culmination of all that we've learned in ICS 413. We're using everything from continuous integration tools like Hudson to open source sottware like WattDepot. These types of software have been discussed on my blog before, but now they're all part of the project my teammates and I are working on. Take a look here.

GreenDepot is a software source software as well. It's primary use is to gauge at what time of day is the most efficient for power consumption. As of this moment, I'm sorry to report that our project is unsuccessful in meeting the criteria set a week ago. Our professor wanted certain things done by now and they are not. What we have is a Wicket web application that takes a date and stores it in a variable. We've even managed to calculate the all the carbon density data for all the hours of a day, but haven't been able to output to an appropriate medium.

Now what's Wicket you may ask? It's a web application design tool. It certainly has many functionalities. It quite a long time just to understand how Wicket worked. This tool is one that works toward creating an application without using too many different types of languages. All you need is html and java. With a combination of markup language and high level programming language, the results seem pretty good. Things are kept simple by limiting programming to only two languages. It allows people to quickly go through it and understand it. However, I bring up again my results. It was not easy learning this new construct.

Another factor that led our team to meet only a few of the goals was that again, our communication failed. I mentioned in my last blog that communication between Edwin and I was difficult at the start. It didn't get better this week either. We weren't able to effectively decide what to do and so time was wasted. Nate our new teammate was well new, and it took some time for us to set up ways to communicate. Ultimately it kept us from deciding on what to do and how to do it.



As you can see from the HackyStat evaluation, our performance was not great. We were behind from the start and so had to rush at the end to make some progress. If we are to continue in this project and be successful I think we need to communicate more and be able to work together more frequently. It's only when we are working as a group that things are getting done. One team member might get stuck on something and the other helps out. Most of our problems have been solved that way.

WattDepotCli Version 2.0

My partner and I have updated our WattDepot Client project. This improved command line based program can now take 3 more commands and provide you with a good idea of what is happening in the grid of Oahu's power plants.

In terms of functionality I feel that our client program does everything it's supposed to. Yet, it's not the shiniest of code. There's a lot of polish that needs to be applied still. More tests and error checks can still be applied to the program in order to cover some vulnerabilities. That's probably one of our weaknesses. WattDepot-Cli-Umikumalua still needs more polishing. What we were able to do was to create more exceptions to handle things like null pointer errors and making sure that a source/power plant existed before we threw that name into a function. These tests and error handlers have made things look better, but it hasn't made me feel safer about it.

I've worked really hard on upgrading the way the command line interface works. Before, the interface was really just one big class that was extended. But now, I understand how to make a interface and how to use different classes that are highly flexible and scalable. If I wanted to add more functionality to just one command, there would be room to expand and it would not cause all kinds of havoc.

A new tool I was introduced to was HackyStat. It's a type of monitor that tracks your actions when your developing software. So it can show you how often you've updated your project and code, or how much time you've put into a certain task. It's definitely worth looking into. I say this not because my grade in class depends on it, but because when it comes to productivity you should want to have some insight into what you are doing and what you think you should be doing. It's another way of reflecting on your capabilities and habits. Even if it's that helpful or improving your skills, it can still serve as proof that you did something.

Although it may seem to be a complicated and unimportant system, I have used this client software to derive some useful facts and insights into how my island home of Oahu operates.

Using this Client I built, I conducted a test for the month of November to determine which day had the maximum and minimum power generated and which day had the maximum and minimum carbon emitted. These tests looked at a particular plant or a network of plants and calculated the amount of carbon or power that was emitted for a particular day based on an interval of checking. What I found out was quite interesting. Our habits shine through even in the data. Based on the outputted data (which you can access here), the SIM_OAHU_GRID was at the peak during weekdays. A peak day like November 16th and 17th saw 995 MegaWatts of power being generated within the Oahu grid. On the other hand during the weekend, energy emissions were down to to 665 MegaWatts of power being generated which is about two thirds of the usual power consumption. The results for carbon emissions were in the same pattern as for power generation, as expected. Since there was more power being generated the carbon emissions rose as well. Emissions ranged from a weekend low of 22.8 million lbs to the weekday 29.9 million lbs of carbon. I would like to think that Oahu is a very industrious city and most of our power consumption is used during weekdays because of businesses.

Feel free to take a look at my distribution package and the WattDepot-Cli project page. here

My Experience with Software Review

I was tasked with reviewing a project of some fellow peers and also to provide insightful feedback to help them better their results. While I did this, a few revelations came to me through their own feedback of my project. The comments have made me aware something.

A major point stressed in the beginning of the semester by my professor in ICS 413 was that when you are creating Open Source Software there are "three prime directives." One of these directives was being able to create software that users could work with effectively and understanding it. I feel that, I have been weak especially in that department. A common comment I got was "it needed more error checks." It reflects bad on my understanding of interfaces because one of the most common habits people have is to use something without reading the manual. I need to make it so that human error is not a major factor in the program. I know I cannot totally provide a solution to the things that can happen, but testing and error checks can help.

I also learned about development through this review process. It was quite surprising and amusing. I learned that I had some strengths and also weaknesses in programming and so did my peers. I never thought to do validations for certain inputs like the html address, but the others did. One of my strengths was that I had a strict coding standard in terms of grammar and getting the details right. When I used the command line built by the other students, it was bad. Their system was not as clean as mine, but they had better program testing. Whereas I had done more happy tests to make the program work better on the command line, they had done testing to provide coverage on the unit and behavioral level. I was kind of narrow minded that way. What I was focusing on was the way the program ran and how the user felt. That's why I was really annoyed when the other programs did not work as expected. For example, they had a help command that printed the syntax of the commands to be inputted. But it didn't work. I had to tediously check the source code to figure out exactly how to input the values and get the right results. On the other hand, I had worked very hard on this portion of my program.

This review has led me to look at programming in a changed manner. Although students are taught not to work together in the first years of computer science, it's become essential in software development because of the different techniques and approaches other programmers have for a specific task. It's made me want to continuously seek input from my peers in order to get a well-rounded outlook on what needs to done to write good programs.

A review of my peers program

Now that my partner and I have built a client, it's also important to review the source code of our peers. Our assignment was to review how well it meets development standards. Their WattDepot client should be similar to our own client. Last week we were tasked with implementing a command line program that worked to provide information using the WattDepot project servers. This simulation of Oahu's power grid was meant to challenge our skills and teach us new practices. Now we're at the review stage, the new objective is to reflect on our project as well as look at our peers product and determine the quality of it.

The standards I try to compare against is laid out on my professors page for ICS 413. Link
These are the two projects I reviewed. The link to the review is below.
WattDepot-Cli-Elua
WattDepot-Cli-Eha

I found that the client for Elua worked for the most part, but wasn't very refined. There are still a few things to be worked out in order for the user to easily use the commands.

Eha on the other hand is not a optimal build. In my opinion, the source code could be drastically rewritten in order to give the program room to expand. At this point it looks like spaghetti code.

WattDepot Client

I recently worked with a partner on a project called WattDepot-cli. Our objective was to creative a command line client that could process certain instructions and gather information based on the simulated data from WattDepot. I learned a lot from this project in terms of working with another person and how a long term project functions.

The first thing we did was look at continuous integration software. Hudson was created to help users steadily update their projects in order for the project to grow and be configured in an efficient manner. I have detailed the use of it in my previous blog. It's worth a look for those who appreciate speedy updates. Link

A second threshold to cross was learning the basics for WattDepot. It's a sort of stepping stone toward creating a smart grid for electric companies. WattDepot functions as monitoring software that gathers information on how much a certain power plant generates in a certain period of time.

The initial learning curve was pretty steep. What was difficult to understand was the way WattDepot worked. What helped was using the wiki on the project site. It was very informative on how to do what I need to do. Link
For example, one of the commands had to calculate the total emissions of carbon emitted per day. I had closely look at the all the methods in the WattDepot Client to really understand what I had to do. My partner Edwin was responsible for the list sources, list source summary, list sensor data {day}, and list sensor data {timestamp} commands. I was responsible for the remaining ones power generated {day}, power generated {timestamp}, chart {source}, and list total. Yeah, that list is really ugly so please check out the wiki site because it is very helpful.

I have to say that Hudson wasn't very help in the very beginning. It actually slowed us down at the start. We hadn't divided up the work yet and my partner and I were both waiting for each other to update. This miss-communication wasted a lot of time. But once we got going in a good rhythm the updates to Hudson was very useful because we had certain parts to work on and they didn't interfere with each other so there was no integration problems. We used subversion strictly to update our own commands to put the whole command line program together.

Because we wasted a lot of the time, our program is not of the highest quality. We also suffered from a lack of communication. Like I have said, the first few days were into the project was pretty quiet. Not to mention we made one of the greatest errors, not exchanging cell phone numbers. In the modern age it doesn't matter what type of bandwidth you have, cellphones still beats email.