Stoplight Gadget Version 1.0

Originally, our group thought that we were making a stoplight gadget that would work with the Wattdepot server. Last Wednesday we had a meeting with our professor on exactly what he wanted us to implement in creating this stoplight gadget. This meeting cleared up a lot on confusion that we originally had. We found out that we will try to create a generic stoplight gadget that anyone can use by inputting their own thresholds. For instance a person might want to use the stoplight to help keep track of waveheights, where they could maybe set the stoplight to be green when the waves are above a certain height and red when the waves are small. So over the past week since our meeting, we got started on the stoplight gadget project.

Our version 1.0 of our project doesn't do much of anything. To make sure that we are able to get everything working together, version 1.0 of the stoplight project just returns a number that can be found on a spreadsheet from google docs. We first created a google visualization to run and retrieve the number from the spreadsheet. When we tried to simply move the code and copy the visualization into the google editor that we were using, we ran into a little bit of problems. For one thing, after we simply copied the code into the tags and saved in the google editor, we were not able to reopen the file from the google editor. To open the file in the google editor we had to open the file from a URL. After tinkering with the code for a few hours, we were able to get the code running as a google gadget. Our code can be found here.

We are looking into using an IDE that could help us with the google gadget editing since there are still some bugs with the google editor gadget online. We have just found that Eclipse has a plugin for google gadgets. We will hopefully decide to use the IDE for further development.

For version 1.1, we are planning to implement a picture stoplight with hard-coded thresholds. We also have to figure out where the user will get their data from that they will use with the stoplight gadget. We hope to get all that up and running by next week.

Software Engineering Part 2

Hi everyone! This is my first blog for the new semester. This new set of blogs will concentrate on the happenings of the second half of my software engineering experiences and projects. The class will be concentrating of further developing the wattdepot service. The professor plans on trying to create an energy conservation game for the University of Hawaii dorms by the end of the semester.

To start the semester, the class was divided up into smaller groups where each group has a task to accomplish. I was assigned to a group that is dedicated to creating a stoplight using google visualizations and also google gadgets. We have to figure out how to connect to the wattdepot server and output the current electrical output. This will be similar to the stoplight that we had to make in our last semester. This first week my group will be learning javascript since it is accompanied with google gadgets and visualizations.

We are a little unsure about what we exactly have to accomplish. So to get started on the project we have studied up on our javascript, google gadgets, and visualizations. To refresh myself on javascript I skimmed though a javascript book that I have had from a scripting class that I have taken at UH. To learn about google gadgets I did the tutorials that was given to our group by our professor, found here. I still have to look over google visualizations, but for now our group is not sure how we are going to incorporate google visualizations into making a gadget stoplight.

Ecologineers 2.1

Over the past few weeks since version 1.0 of my groups' project, there were many new additions and modifications to the program. Instead of one page that just does the chart, we have added a homepage which describes the entire project, and as stoplight page that gets the current carbon output. There is also a menu bar that allows the user easy navigation throughout the website. We have also upgraded the grid info to implement a chart. The chart now allows for users to look at data over multiple days because there is now a start dates and an end date that users enter. The users now have a choice of what source they want to choose from to view.

There is a new stoplight that tells the user the current state of the system. The stoplight shows green, red, or yellow which indicates if there is currently high, medium, or low carbon intensity. Low is green, medium intensity is yellow, and high intensity is red. The colors mean the same thing on the gridinfo page. The gridinfo page contains a chart with 3 input fields. A start date, end date, and source. To make the program user friendly, we have set the program up so that the same start and end date is one day. Ex. 10/01/2009 to 10/01/2009 will get the chart to print out the 24 hours worth of information.

Some other additions that we have made to the program was implementing ajaxpagerefresh for the stoplight page that will refresh the page every minute without the user having to manually refresh the page. We also added nice URLs, which made the URLs easier to read.

Final 413 Blog

This will be my last blogpost for my 413 software engineering blog. But fear not all you people out there, I will be back blogging about new experiences in my 414 class next semester! My first software engineering experience has been a good one. This experience has reinforced my belief that I chose the correct field and enjoy working with software and coding.

The most important thing that I have learned this semester is to always plan out the entire project before even starting on it. Every project that was assigned this semester was very interesting and fun to work on, but I had the problem of always flying by the seat of my pants while working on them. Instead of planning out and really thinking about how I wanted to implement the assignment, I would just start coding and get small parts done without looking at the bigger picture. This caused many problems later in the project since it took a lot of work to put everything together. The best example is the first wattdepot CLI assignment. My group had a poor implementation idea where we didn't take into account what we were trying to implement. We just finished all the methods and threw all these methods into one file. We didn't think about how hard the code was to read and expand on. We later had to refactor all of our code, we also made the code more readable and easy to expand upon by adding a command map that would handle all the user inputs.

I also learned about different quality assurance tools such as checkstyle, pmd, and findbugs. These tools were a burden at many times during the class since they would nit-pick at such small things, like a missing space after a comment, which would cause our build to fail. Although they would annoy me, I have learned a lot using these tools, since they made me a better programmer. They made me realize that some of my code could be optimized and to make sure that I always comment. This was also the first semester that I needed to use JUnit. Making test cases were very useful since it allowed me to make tests for small parts of a program. The JUnit tests saved time testing the program since I would not have to run the entire program to test a small change. I could just test the small change using JUnit.

Another important thing that I have learned in this class was working in groups. This class gave me my first experience working in groups and the various programs that helped with the group projects such as Git or subversion. We used subversion in class and I have seen how it has helped with the process of finishing an assignment.

Overall, I have enjoyed my 413 class very much. I have never worked so hard in a class before. This class was very intense and I have felt like everything that I have worked on in this class is very useful and relevant to real world experience.

Review of GreenSmart 1.0

We are reviewing other groups projects again for our ICS 413 class. I was assigned to review GreenSmart's project. When I first visited their project site, I was very impressed with their home page. It looked very professional with the screen shot of their system, and also a good description of what the project accomplishes. They had good wiki's that explained what needed to be done to run the system as a client or as a developer.

I was not able to break their system as error messages were produced whenever there was bad input or there was no output. The only problem I had with the error message that I didn't like was that it said "Error:" for each error message. I would rather like to have seen something like "Invalid input, please only input integers." or something in the nature that tells the user what is wrong. This is the only negative I found with their program.

Looking at their actual java code, I could not tell that the program was written by more than one person. The code was easy to follow and I found nothing wrong with their documentation. I think that they could have setup two different packages, where one package was the wicket and another package has the wattdepot commands.

My full review can be found here.

Ecologineers 1.0

Imagineer that! We are embarking on a quest to improve the life of the entire world. When I speak of we, I am talking about me and my 3 other ecologineer group mates. We are writing a program that uses the WattDepot system, which I talked about in my previous blogs, to give indications of when there is a high amount of carbon being emmited. This new system uses the Wicket system which allows for html to run complicated java programs almost effortlessly. Using the Wicket platform, we are making a webpage that indicates the amount of carbon being emmited at a certain time of the day.

Learning the Wicket language was very difficult at first. Extending the Webpage and Webapplication classes were very confusing at first, but I slowly got the hang of it. One thing that I still do not understand after working with wicket is exactly what the 'serializable' class does. I hope after I read more up on it later that I will understand the serializable better.

I was very pleased with the way our group worked together. We all got along great and also are able to get things done when needed. The only bad part was that we started working on the project a little late which caused us to spend long nights getting the program up and running by the due date. I am okay with the design of our project. I think that we could have made the program a little more efficient at getting the thresholds, but other than that small kink, I am pleased with our implementation. Some kinks in our program is that we didn't get all of the validations to work and some input causes the program to crash. For example, putting extra 5 digits in the year field will cause the program to crash. We didn't figure out a way to fix that bug yet and will have that bug fixed by version 1.1. We also were not able to get the rows of our table that we generated to output the corresponding colors. Instead we just put a column called 'Intensity' that has a text output of what the row color should be. We should also have that fixed by version 1.1 of our system.

The picture above is our hackystat ICU chart. This chart indicates that we do not have adequate test cases, and also that we have uploaded a lot in a small amount of time. Our coverage report is small, since we didn't test any of our wicket code.

A distribution of our project can be found here.

Revamping to WattDepot 2.0

In this blog, I will talk about upgrading our team's WattDepot User CLI to version 2.0. This was a very tedious task since it required a lot of refactoring of our code. The majority of our groups effort was put into refactoring our code since we implemented an interface and used a Hashmap to call our commands. We made the mistake of finishing all of the commands from 1.0 instead of getting the hashmap to work. This made us take a few more hours than it should of since we just added more code to refactor. There were also a few new commands that was added into the new version of WattDepot. The new commands can be found here. The three new commands were a lot easier to implement now that we were more familiar with the API. Also, the commands were changed from version 1.0, which were easy to fix after we implemented our Hashmap and interface. I am glad that we have finished the assignment and got everything working.

I thought that my group partner and I worked well together. I felt that we each held our own and did the tasks that we assigned for each other. We met regularly about 2-3 times a week in sessions of about 3-6 hours at a time. This gave us plenty of time to work on the assignment.

I believe that our system wasn't the most efficient way to implement the user CLI, but we were able to get the job done. Having the refactor the code created some problems, but we were able to workout the details and get all of the commands up and running. We tried to take care of as many of the issues raised by our reviews of our system. The reviews were very helpful since it gave an outside perspective on our system that we were not able to see ourselves. Our design of the system still has some kinks, especially after we broke up the commands into their own classes. To get all the commands working, we had to extend the UserCommandInterface class since it held some key methods that could only be accessed if we extended the class. This was a design error by us since we were not able to access the client information from the main class since we didn't ever pass it as a parameter. To summarize this, we have each of the classes in the command package having to extend the UserCommandInterface and the UserCommands class. The names are a little confusing since the UserCommands class is the interface and the UserCommandInterface holds the CLI menu methods.

We did not write tests for every class which tells me that we do not have good test cases. This was a pitfall because we did not write test cases at the same time that we were writing code. We tried to write out the test cases at the end of the code for the old commands from version 1.0, but again we ran out of time. We were only able to cover 76% of our class, 63% of our method, 44% of our block and 46% of our line code.

Looking back on the assignment, I feel that the goals of this assignment was to give everyone in the class group experience, which is something that was lacking in previous ICS classes. We were also introduced to some pretty cool tools that helped the group project go along smoothly. Using subversion was a big help since we were just one click away from updating and commiting our changes to the project. The new tools that I was introduced to were Hudson and Hackystat, which were both interesting tools. Hudson was a good tool that helped our group keep our project healthy and not let it stay broken for long. Hudson was a build tool that is very useful since it verifies the system all the time with helps when either me or my partner forgets to verify. Hackystat was another interesting tool which told us all about our code. Here is a printout of our code. This printout told us that we needed to write more test cases to help cover more of our code. Also, since our design of the system was pretty bad, our code is very complex.


What day and time during the month was Oahu energy usage at its highest? How many MW was this?
November 2-6, 9-13, 16-20, and 23-27 all had a usage of 995MW

What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
November 2-6, 9-13, 16-20, 23-27 all had a usage of 493MW

What day during the month did Oahu consume the most energy? How many MWh was this?
dunno how.

What day during the month did Oahu consume the least energy? How many MWh was this?
dunno how.

What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
4th, 5th, 16th, 17th, and 30th of November. 29,959 pounds of CO2 were emitted.

What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
7th and 8th of November. 22,908 pounds of CO2 were emitted.

Our distribution file can be found here.