Paul's Software Engineering Blog

Kukui Cup Billboard: Frame up, visuals in, a step up from mockup!

2010-04-27T00:17:00.009-10:00

After drawing up the mock-ups for the Kukui cup billboard, we are now ready to implement our design ideas. There were some changes regarding the mock-ups such as combining the core visualizations into one page and to have them update on top of each other instead of showing three tables which then transitions to the other visualizations.

A screen shot of our new visualization design.

For this week, I played around with css. I have not used css since learning it from ICS 101 so I did some research since I felt a little rusty. Nevertheless, my goal was to implement the rounded corners look for the visualizations. After reviewing css from w3cSchools and researching some example implementations, I felt ready to tackle this goal. My initial research yielded different approaches. Some used images of rounded corners and then render the four corners through html/css and on some with javascript. But after researching some more I learned that the css3 implemented a 'border-radius' property, that does exactly what I intend to do which is easier to implement and customize than the previous method. This was done through css via -moz-border-radius property. Since, as a group, we decided to use Firefox with the kiosk plug-in as the browser to display the billboard, this accounts to the -moz in front of the property which will only render to a Firefox browser. There is another property, -webkit-border-radius, which does the same rounded corners for Safari browsers.

Here is a screen-shot of the rounded corners implementation with some gradient added to the header.

Lastly, I also tried to implement the ticker tape. The ticker tape is fed from the updates students submit such as commitments. Since Ed found a very good implementation of this function, http://www.mioplanet.com/rsc/newsticker_javascript.htm, I simply implemented their script to our billboard. What I like about this implementation besides its simplicity is that I can use css to apply the appropriate styles it requires to suit the look of our billboard.

To see my implementation of the rounded corners, ticker tape and Jarret's updating visualization, click here.
Our project hosting site can be accessed here.

Kukui Cup Billboard

2010-04-19T23:58:00.008-10:00

Just after finishing up our gauge, we move on to a new project. We deviate from our usual Google gadgets and into something completely different, a status billboard. Our job is to create a status billboard of updates happening during the UH Dorm Energy Competition. Our current task is to create mock-ups of the type of information we want to display and to do some initial research on how we are going to proceed.

Here are some of our mock-ups.

This shows the Kukui Nut standing for participating dorms, its floors and its residents. It also shows the static title header and the ticker tape in the footer.

The contest prizes, tip of the day, and upcoming events. The today's event are meant to explain the who, what, where and when of the said event.

Besides creating mock-ups, we also did some research on the different things we're going to be using for this project. Since the billboard will be entirely web base, we decided to use javascript, html and css for ease of use. We initially decided on using Chrome to view our billboard in full screen after our initial testing with Firefox but we learned that our Firefox's full screen mode showed a little bar on top. So Jarret started looking around and found a plug-in for Firefox that fixes this problem and so we will be using Firefox instead.

Our goal for next week is to start implementing our mock-ups and any changes made to it. Our project hosting site can be accessed here.

My 3rd gadget for the 3rd milestone.

2010-04-13T02:16:00.006-10:00

Our team just finished our 3rd gadget for our project, Stoplight, Monitor, and lately, the Gauge. The gauge gadget works like the other gadgets we've created but combines the different properties into one. The stoplight's thresholds and the monitor's Wattdepot implementation both find its way to the gauge's properties. The gauge displays Wattdepot energy related information using a user inputted host URL and a source and also uses the gauge visualization's option to add coloring to display threshold. Here is a screen shot of our gauge gadget.

Some of the new properties we've added on top of the previous version is the addition of the host URL field for the gadget settings, the data type and time stamp showing below the gauge, the units showing inside the gadget and the title on the gadget's heading. My job for the latest version is to implement the host url requirement and replace the data-type with the units that is shown within the gadget. I had to search for the right implementation from the visualization API in order to the add the units.

During our gauge development we didn't really have any problems it since my last post. I am still using Eclipse to edit the xml files. Other than that we didn't have any problems with the development of this gadget.

As for improvements, we are planning on adding basic error checking for the setting fields. We are also planning on making a better user experience by turning the host URL field into a drop down menu with the appropriate Wattdepot servers and do the same with the source list.
Our updated project host can be accessed here.

Wattdepot Gauge Gadget

2010-04-06T02:29:00.004-10:00

After last week's initial preparation of the gauge gadget we are to implement and retrieve data from Wattdepot. This was not really a huge problem for us since we integrated wattdepot for the monitor gadget we created for the 2nd milestone. This task was delegated to me and Jarret the threshold and refresh.

The biggest problem that we had while working on this project was debugging our code. Both Jarret and I tried to find the problem as to why our gadget won't load the gauge visualization. After looking through the code for 3 hours we found out the problem and it was a typo. We were passing a different div id as a parameter from our div tag's id. This just shows our real need for a better editor and a better way on running our gadget for testing purposes. We had to commit to our trunk every time we need to correct our code no matter how minute. I am currently using Eclipse with the basic plug-in for xml to edit the gadget. This was problem was really not a big deal since it was meant for testing purposes. I started out with a requirement to enter the whole data source url as to test our gadget's ability to retrieve from a source, google spreadsheet. The div tag was later replaced by a different id later on when I implemented wattdepot, which only requires a source string not the url.

During our 3 hour mishaps we sifted through the code trying to figure out what was wrong. It was a good opportunity for me to learn more about the gauge visualization and also by looking through the visualization api.

Here is a screen shot of our Wattdepot Gauge Gadget with the Kailua House as its source and monitoring the power consumed of the said source. Our host site can be accessed here.

Gauge Gadget

2010-03-30T02:09:00.001-10:00

For our new project, we are still working with gadgets but this time around, we are to use advance google visualization tools. The visualization that was delegated to our group is the gauge visualizations. Our first objective for this project is to get a simple gauge visualization working with hardcoded data to be evaluated and then create a gadget based on the that visualization. Other things that we had to do include when creating the gadget is to create a common look and feel for all the gadgets in the iGoogle page. Since we cant change other google gadgets' look, such as gmail, we are basing the look for our gadgets with those look. Prof. Johnson suggested that we install other google gadgets along with our gadgets to create the common look.

Some of the things that we are going to be working on is to decide what of information to use for the gauge. Another would be to fix the problem of overlapping gauges. The overlap occurs whenever the gadget size is adjusted.

Our project hosting site can be accessed here.

Two on Two: 2 Gadgets for 2nd Milestone

2010-03-09T00:25:00.013-10:00

For our second milestone, our group has finished two gadgets. The Stoplight gadget, which is a universal gadget that takes a user input source and displays a stoplight image based on the a given threshold, and the Wattdepot-ui-monitorgadget, which is a monitor that connects to the Wattdepot web service and displays the power/energy consumed and the power/energy generated of a given source.

Stoplight Gadget

Features

Automatic refresh
Title feature
Customizable image size
Able to parse both integers and decimal values
Error handling

Version 1.7 is the latest version of stoplight gadget. The most prominent feature of this version is the automatic refresh is much cleaner. During our meeting with Prof. Johnson, he noticed that our gadget will look a little more professional if our gadget refreshes only the relevant and dynamic information. As in the case for our stoplight gadget, the image, data and the message. These dynamic information will only refresh whenever the image or the data changes and the rest will stay the same . This means that we don't have to refresh all the information whenever one changes. It also eliminates the spinner icon for each information, which appears when the gadget retrieves data. Other functions include the adjustment of the gadget height. This was an aesthetic modification because our gadget allows users to change the image size and when the image is set to small there are extra whitespace below the message. Lastly, we changed the location of the gadget title from the gadget window itself to the top center section of the gadget main display frame.
For the full list of all the features visit our ReleaseNotes wiki.

Wattdepot-ui-monitorgadget

Features

Automatic refresh
Able to connect to Wattdepot web service
Error handling

For our latest version of the Wattdepot monitor, we also implemented the new refresh function explained in the Stoplight section above. This feature is much more prominent in the Wattdepot monitor since each of the information displayed is a result of the retrieval of the proper data to be displayed. From the source name to the last checked time stamp, the spinner icon always shows up for each information displayed which turned out to be an eye sore. For the my milestone contribution, I added the error messages to be displayed as part of my error handling. One of the problems I encountered is the appearance of the spinner icon along with my error messages. This gives the user a false sense of anticipation for more information to show up. The solution to the problem is the implementation of the new refresh function itself. Since my error message is due to a missing user input, other information that needs to be displayed might be dependent to the missing input and therefore will show the spinner icon to no effect.
Since we only worked on the Wattdepot monitor for only a month, we only have 2 versions being version 1.2 as the latest.

After the 2nd milestone presentation, we are to change our group project for the second half of the semester. We had a chance to change project after the 1st milestone but I enjoyed creating gadgets that I stayed in this project. The group isn't decided yet but this is the reason why I signed up for the HEEP gadget team for the 3rd milestone.

Never say never: Improving Stoplight Gadget

2010-03-02T01:16:00.006-10:00

We are closing in on our 2nd milestone , this day next week, and we are in confident on finishing the two gadgets in time. For this week, we are still working on the Stoplight gadget, a continuous work of improvement, as well as the Wattdepot gadget. The Stoplight gadget had a major rework in terms of the formatting of the data it retrieves from. During our weekly meeting, we agreed that our messageSourceUrl formatting was too error prone from the user end. A user might get confused on setting the upper and lower bounds that relates to the corresponding message to be displayed. Our solution is to create a new format. This new format differs by having two columns, one to include the integer values to be evaluated and the other with the corresponding messages.

A significant feature are the empty spaces to visually show the upper and lower bounds of the values to be evaluated. In conjunction with the format change, we also stopped parsing the value as integers and instead parsed them as floats to better represent values a user might use which includes decimal values. Jarret created an updated message script to facilitate these changes. The updated script can be seen here.

As for the Wattdepot gadget, the main improvement we did was that we've successfully got our gadget to connect to the Wattdepot server. We are mainly using tests information gathered from Wattdepot. Other changes includes changing the source into a user input source instead of drop down menu, lowering the retrieve interval from minutes to seconds and including the source and the type of data in the gadget itself. The type of data that a user can choose from are Power Generated, Energy Consumed, Power Generated, Power Consumed. The data types' description can be accessed to Wattdepot's site.

New gadget! Wattdepot Gadget

2010-02-22T22:15:00.002-10:00

For this assignment we start a new gadget but we also worked on polishing our Stoplight gadget. The main thing we had to do is to give a user choice on what size the image is shown. This was the solution we came up with since we couldn't get the scalable image working within the gadget. Some other things we did was to add a 'title' input to personalize the gadget. We also had to a few typos and completed information to our gadget and our project hosting site's user guides, which Robert pointed out.

In conjunction with polishing the Stoplight gadget, we also are to create a new gadget that retrieves data from Wattdepot. Wattdepot is an electric database that we used for last semester's projects such as the Oscar web applications and the resulting Ecologineers web application. This gadget retrieves information from a source and displays a set of data which can be anything from current power use to overall power consumption. These are information are displayed after filling out the required information such as the source, refresh rate, and the type of data. The main information that is to be displayed consists of the power (kW) and a time stamp of the current refresh and the the last checked.

Stoplight Gadget 1.4

2010-02-15T23:58:00.010-10:00

Stoplight Gadget version 1.4 is the last version that our group is going to work on. Our meeting with Prof. Johnson last week has resulted in the introduction of a new gadget idea. It was only an idea so we didn't go into details and so the meeting shifted into how our group is going to finish up the Stoplight Gadget and get it ready for publication. I thought that this was a good idea since I feel that if we added more functionality to our gadget it beats the purpose of having a gadget that is easy to use, returns a concise information to the user and most importantly keeping it clean and uncluttered. For our final version, it is mostly about three issues that we've discussed which are error handling, unit addition, and the stoplight image. The stoplight image is still one of the problems since we tried to have a scalable image in order to accommodate users with lower resolution screens. Some other things we talked about in the meeting is the addition of better message and mainly the addition of the units.

The error handling issue, which was delegated as my job, was to add a text error messages to be displayed whenever a user input and data source errors arise. The process was not that hard but it took me a long time to finish it and go through my initial testing. It was mainly because of how I edited my code locally and then commit the changes through SVN and lastly test inputs through iGoogle with the gadget editor. This is one of the more frustrating time for me since I know that there are alternatives out there such as Google's own deskstop application. This is something I am highly considering in regards to working for the next gadget project.

Even though this is going to be the last version that we've worked on, I know that this project will never be labeled as finished. The Stoplight Gadget project will be an ongoing project to improve not only because it will be published but a way to showcase this as my accomplishment for possible employers.

Our project Hosting site can be accessed here.

Google Gadget: 1st Milestone

2010-02-08T23:12:00.003-10:00

For our first milestone, we are to present a working and professional looking gadget that is simple but useful. Our version 1.3 Stoplight gadget is our project's first milestone. The gadget's functions include automatic refresh and threshold related messages, other functions that was implemented from the past versions include stoplight image, user inputted data source and threshold values. The stoplight messages is something that Yichi and I worked on and it was a little hard. After some research, we learned that the the gadget can only send and receive one query at a time so our solution was to separate the gadget query for the data and messages. Two script files, one for to display the stoplight image and the other to display the message, were created as a solution. Some other enhancements are purely aesthetic enhancements and it includes a better stoplight image and a drop down menu for the required input fields.

Since we've built our gadget by adding new functions on top of older ones for each version, I find that working on this first milestone project was fairly easy. The things that we've worked on most is improving the functions from the old versions and then implementing the new ones that we decided should encompass version 1.3. Such is the case with our stoplight image. During our meeting with Prof. Johnson, he told us that we needed a better image, one that shows the different colors clearly and resembles a real stoplight for a professional look. Other things we had to do was a major organizations of our files. Having the 'trunk' directory contain only the latest source codes, 'branches' as our individual repositories, and 'tags' which contains our gadget's past versions. We also had to improve the Stoplight Gadget site to reflect upon the changes we've made and to add user and developer guides.

After this first milestone we are planning on continuing with this project. For our next version we are shooting for the inclusion of error handling, scalable stoplight, and also maybe implement the 'plug' images from the HEEP project. I had a great time working on this project with my team. We always try and meet up at least twice a week which helped us delegate jobs easier and to keep us on track.

Stoplight Gadget 1.2, a leap from 1.0

2010-02-02T00:53:00.003-10:00

For this week's gadget version, we've managed to combine two version functions into one, hence the leap from 1.0 to 1.2. We have combined two similar functions that we seemed easy to do so. Our initial meeting with Prof. Johnson had resulted in the split of these function into different version. The two functions are user input data source and the threshold values. Some of the other things we have accomplished is the addition of the stoplight image itself. Since we only have to display the stoplight for different threshold values it was fairly easy to implement the stoplight.

My task for the combined version was to do the user input threshold values, but since we decided to combine it this job fell into Yichi's hands since he was doing the other function, mainly the input data source. My new job was to research for a solution to a problem that we've encountered during our implementation of the new functions. We needed to find a better way to access our script and xml files because they were saved from Yichi's Unix account. We initially tried to gain access to these files through our Stoplight Gadget project hosting site. We have presented the problem to our weekly meeting with Professor Johnson and they have provided us with the best information to solving our problem. They have suggested that we needed to change the svn:mime-type of the files were trying to access. It turns out that Prof. Johnson had encountered such similar problem and has written a blog entry about it. The posting was very helpful but a reply to the posting helped me directly with my problem. It links to a different project hosting site called Flexlib and within its Wiki pages they explained how to access the SVN config to enable auto-props and provided a list of file format values.

After finding out how mime-type works, we have discovered anther way we can access our scripts withing Google project hosting and without changing the properties of the file. When browsing the files in the source, there is a link to the view the raw file in the right details panel. This is the easiest way for us to link the our scripts url with the gadget.

Next week will be our first milestone for our Stoplight Gadget and we hope to be able to have a version ready for release. Some of the function that we'll be working on are the addition of messages that interprets what the stoplight is showing or to return errors, scalable image and error handling.

Stoplight Gadget v1.0

2010-01-25T20:17:00.007-10:00

This week's accomplishment included a finished Stoplight Gadget version 1.0 and a project hosting site called Stoplight Gadget. Version 1.0 is just our starting point for the whole project which is mostly about setting up the requirements and getting a feel of the basic functions. Our group meeting with Prof. Johnson has been the most significant part of this and last week's work. The meeting clarified all the gray areas about this project. First, we learned that our stoplight is supposed to be a general stoplight that people can download and use with relative ease. We initially thought that our stoplight is about Wattdepot and therefore constrained by it's functions; A stoplight that bear some similarity with last semester's Oscar WebApp. We learned that our stoplight gadget is supposed to work with any data, something that users can add to their iGoogle page and be used for different data by entering their own threshold and data source.

During our meeting, we also outlined the various functions and requirements for each version that we need to produce. We decided to create the basic functions first and then expand from there on. For version 1.0's visualization aspect, our gadget displays an integer that was taken from a hard coded source, which is from google spreadsheet. From that basic function we turned it into a gadget. Our next assignment is to add more functionality such as an actual stoplight image, a hard coded threshold, user inputted data source and the accompanying user interface.

An important lesson I learned from the first two weeks of working on this project is that a clear and concise instruction on what the project is about is a very important feature of software development. It helps developers to easily plan an outline of how the project is to grow. Extensive and periodic group meetings is also an important part software development in order to fix problems that arise during development period and to keep the group heading to one direction.

Stoplight App

2010-01-19T00:22:00.002-10:00

New year, new semester and new project. Welcome back everyone and glad to have you back to ICS 414 Software Engineering weekly blog entry. For this semester, Prof. Johnson decided to continue on with last semester's sustainability project, Wattdepot, and use it a the key theme for this semester's projects. Prof. Johnson has given us 6 sustainability projects and let us decide which one we want to work on. The projects are Wattdepot Apps, Google Stoplight, HEEP website collaboration, Kukui Cup Design, Kukui Cup Prototype and Energy Meter. Another thing that is different is that we have to meet up with our professor every week which is different from our class time to discuss and present our weekly project development.

The Wattdepot apps are just a continuation of last semester's project and Google Stoplight is a stand alone application based on the Wattdepot stoplight page using Google visualization. The others are newly introduced projects that included collaboration with Hawaii Energy Efficiency Program (HEEP) to create a web application that will be included with their upcoming website and UH Electrical Engineering in creating a smart energy meter with the Energy Meter project. The last two are part of the Kukui Cup Competition that includes a project mock-up creation by the design team and the UH dorm integration by the prototype tech team.

For this project, I am part of the Google Stoplight. I picked this project because I wanted to try and do some of the extra components that was included in the Wattdepot apps, which is the use of Google visualization to help graph and chart hourly carbon output. The main difference is that we have to use Google visualization to incorporate the stoplight information. So far our group have only met yesterday and we talked about the things we have to do. We just delegated jobs such as the creation of project hosting site and we also talked about our experience with Google Gadget tutorials.

Ecologineers v.2.1

2009-12-19T00:27:00.004-10:00

For this assignment, our professor decided not have a final exam, instead we were given the opportunity to improve our web apps. Since our last presentation, we took the critiques as the basis to improve our application. The critiques are mostly aesthetics that involves applying the best user interfaces given what our application is set out to do. These includes decreasing the size of our logo, which for some reason is supposed to be intuitive enough for us to realize and change right away, having default values for our grid info page and setting our pages so that they fit nicely with a lower resolution screen. The last problem provided a very typical mistake I think what novice programmers face when creating user interfaces, and that is we assume that people who eventually will use our application will have a similar computer set up just like ours. I learned from this class and the provided UI video lecture that we need to broaden our perspective to be able to account for a larger set of audience each having different different computer set ups.

Other than fixing our user interfaces our professor has given us some more functions to choose from as extra credit. We initially planned on doing five functions but as we go through our finals we wound up just doing two. Those two were the nice URL function and the AJAX stoplight page refresh. These function were not that bad to implement. Our team tried to learn AJAX just for this particular function. As for the function that didn't make it, date picker, and google visualization, we tried to implement them but were having problems that we just abandoned them. One thing to note is that during our presentation for version 2.1 we told how we were having problems with our date picker and one of our fellow classmates pointed out the bug. This made me realized that when an application is deployed, it's users can be very helpful in finding bugs. But I woudn't count on them because I learned from a different class that fixing programs already deployed are costlier than finding them during dvelopment.

All in all I really enjoyed working on this project. I also enjoyed working with my group. I'm really taking this experience as a good indication of how the professional programmers work in the real world since I plan on being one.

Oscar WebApp Code Review: WattWaiter

2009-11-24T18:01:00.006-10:00

For this assignment we are doing code reviews on our fellow classmates' Oscar web applications. I am reviewing team WattWaiter with Remy Baumgarten, David Mau and Kevin Chiogioji as members. This review is based on a new checklist that has some new points that includes Wiki Documentation, Software ICU, Issue Management and Continuous Integration.

My overall feel of the application is that it was designed, both the program and the application interface, very good so much so that it could almost be passed as professionally built. The negative things I have to say are mostly nitpicks that this checklist looks for. Other than that it was a very robust application.

The full review can be found here.
The WattWaiter web app can be accessed here.

Ecologineers: Oscar Web Application

2009-11-23T07:02:00.007-10:00

As we continue along working in bigger teams, we explore more and more on how to develop applications. For this assignment, my group from the previous WattDepot project got teamed up with another two man group. Just like my original group, we all worked perfectly together. We set up plans, delegated jobs and met up regularly. I had as much fun on this project just like the last one.

As for the project itself, it was very daunting at first to hear that were going to learn a new framework that were going to use for this project. Our professor repeatedly reminded us the importance of this framework during lectures and especially at the project screen cast. The reading (Wicket in Action by Martijn Dashorst and Eelco Hillenius) alone was a little hard to comprehend but just as other languages, you learn by doing it. We were given some example applications to show us how the new framework works. As we progressed on our project we quickly learned that Wicket wasn’t as bad as we thought it would be. It turned out to be straightforward. When we tried to implement Wicket with our code we had some small problems. One problem was actually merging the form and table page. We initially planned then delegated the two jobs to two of our people, one of them being me. When we tried to merge the two together we hit some snags where our Wicket tags were not being passed into the HTML tags. Another problem, which I think was a big one, is that our color tags won’t render the color. Since we ran out of time we just left it as is which instead of passing the HTML color it passes the color words instead.

Since we were introduce to Software ICU in the last project. We also implemented it for this project. From the look of the screen shot from above, our coverage was fair since we only had six test cases. Our devTime, Commit, and Build has some steep increase because even though we did the initial set up then met up regularly and discussed the plan, we didn’t actually started to code until weekend.

All in all I really enjoyed working on this project and not to mention with my group. I really got a feel on how to develop real word applications. This is also a good project to learn good sustainability practices since any user can download, run and use our application to help decide when to use or not use an appliance.

Our project site can be accessed here and our distribution file here.

WattDepot-Cli 2.0: Second time is the charm!

2009-11-16T06:51:00.007-10:00

As we wrap up on our WattDepot-Cli project we gain more perspective on how the software development works. In this assignment we are to update, improve and add new commands to our version 1.0 of WattDepot. We are still working with our initial partners and as for our group, it has never been better. Even from the start of this project my partner and I communicated every other day and delegated jobs. Our jobs weren’t so concrete which gave us a little flexibility so that we can do other things outside of this class. We also met twice a week not including the time we spent working on our projects in class. All in all my experience with my partner in producing the WattDepot client was a pleasant one.

In terms of our client, we have improved our methods by reviewing the changes in the commands provided in the WattDepot wiki and suggestions coming from last week’s code review. One of the things we did was to add the necessary comments and improve our Javadoc so that any developer can understand our code and use our API for reference. We also have added more test cases. Most are still happy-path tests but now we’ve included some behavioral test such as our validation tests. Even with more test cases our coverage is still under the healthy 90%. Our coverage is 63% because some of the new commands and old commands didn’t get tested. Other than the coverage being low, we did find that writing test cases was much easier when we refactored the commands into their own classes.

As for new materials that we learned, we used a program that displays the current condition of our program. It is called Hackystat. Hackystat retrieves information from our local and Hudson builds and the amount of time we spend in Eclipse. It measures and displays different categories that are pointed to the overall health of our program.
Here’s a screen shot of our program information.

The overall health of our program is a little stable. The reason for this is because of the lack of testing (30%) which consequently affected the coverage. The screen shot also shows the increasing trends of our development time commit and build because we worked on it mostly on the last four days before the due date.

The last part of this assignment is to answer some question regarding information that we gather from our program.

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?

Unknown

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

Unknown

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 Wattdepot client version 2.0 can be found here.

Code Review: A subtle but rewarding learning experience

2009-11-11T00:19:00.002-10:00

Some people might not like the fact that their code is to be reviewed or to be the person who does it but I believe that there is a rewarding experience that results from this experience. I, for one, value the effort a person did to look how our overall product came out to be, some of which say that we didn’t commented enough for them to understand our code. Besides having a working system, our class’s third prime directive states that our code should have a good developer-level documentation that provides the inner workings and therefore should make it easy for them to understand and expand. This is particularly true in our assignment which taught me a valuable lesson since we have to create our user interface client upon the WattDepot system. The documentation on the WattDepot system helped us implement the commands that were assigned. Another comment I took into consideration was the design which didn’t really surprised me since we didn’t follow the design requirement. Our system grouped all the commands into one class instead of having each one of them in its own class. This is particularly an important point since it restricts our system’s extensibility. This design is now an important part because we are adding more commands into our client and this task would’ve made our jobs a lot easier. This I also think that the checklist that our review is based on also helped on how I will improve our client. All of our command methods are expressed to have “side effects” and therefore is a design problem that we have to address.

Overall I found this assignment worthwhile. Having another person not just examines but also gives suggestions on how to improve our system is a good way for me to actually be a good programmer. Not only did I have fun working with my partner but I also enjoyed reviewing other people’s system and hope that they find it helpful.

WattDepot Client Code Review

2009-11-09T04:06:00.009-10:00

After working for more than a week on the WattDepot client, we have to review our fellow classmates' client for this assignment. This review is generally a way for us learn how to both give constructive criticism based of a checklist and apply them to our existing code to improve upon for our upcoming updated release of the WattDepot client.

Eha
In general the client works good, it does what it supposed to do. Some of the things that I find a little weird was the chart output which has some rather small points and therefore a low chart considering that given the same arguments other clients produced a proportional chart. As for the design, the only thing is that it did not followed the design requirement of having each commands in it's own class. This is important so that the client supports extensibility considering our next assignment will have new commands.

The full review can be found here.

Elua
When I first tried to review this group's client I had some problems some problems such as not being able to run the jar file. After using Eclipse to run the client I encountered a bigger problem, for some reason only the 'help' and 'list summary' commands work and the rest didn't especially 'quit'. After some time they released a second version which only fixed the non-executing jar file and from that second build I based my review. Their client followed the proper requirements and all their commands worked perfectly. Their test cases were also some of the things that they have done a good job.

The full review can be found here.

Full Scale Software Engineering Project: WattDepot

2009-11-04T07:20:00.004-10:00

Continuing from my recent post about a new concept we learned, we get our hands on an interesting programming practice called Continuous Integration. For this assignment, we were partnered up and create a command line interface for the WattDepot system. WattDepot is a web service that collects information about Oahu’s energy and power production/consumption. My partner, David Joel Lazarro, and I had to implement various commands to be used on the stored WattDepot data. We planned on splitting the commands in two and as we started working on our commands, we got our first experience of practicing continuous integration. We initially didn’t get the hang of it. We rarely commit to our repository, waiting until a full working method, both tested and verified locally, before committing our changes. But as we progress in this project we learned how to properly practice it. We did have some problems such as fixing merge conflicts since we didn’t really have any set design plan. As our code continued to grow, we finally found a good rhythm that tied our code into a unified look.

As for WattDepot, we implemented all the commands that were assigned. This is one of the first times where I had to build on someone else’s code in this scale. Having a good documentation and API really helped me understand the inner workings of the WattDepot system. This reinforces the importance of the third prime directives first taught in this class. The commands were mixed in terms of implementation difficulty, but I noticed some recurring similarities within some consecutive commands, which made the whole thing not so bad. Halfway through our given time for this project we were told improve our design strategy and implementation. This threw us of a little. The new strategy is meant to improve the scalability, reusability and efficiency of the command line interface. My partner and I understood the design strategy that was shown to us and we tried to implement it but to no success. This is the reason why we didn’t really have some good test cases for this project. The new strategy could’ve helped us design better cases instead of having just acceptance tests. Our methods were designed in way that it is constrained by the parameters preventing us from testing the instances of commands. This would’ve been easily implemented if we followed the new strategy’s design of having the commands in separate classes.

All in all I thought this project gave me an insight to the world of software engineering. Planning and implementing this project was just as fun as meeting up and working with my partner. I also thought that having a project that teaches us the importance of sustainability, especially in these times, is a cool way to really get our attention.

Our distribution file: Ekahi.

Continuous Integration

2009-11-02T00:17:00.003-10:00

For this assignment we were introduced to a new practice in software development called Continuous Integration. The main objective is to commit changes frequently so that any errors are quickly detected and easy enough to solve. This builds the repository gradually instead of committing a huge change that it doesn’t look as the original and committing these changes can lead to clobbering of update changes.

To practice continuous integration, we are using Hudson. The creation of a new job within Hudson fell to my partner. From what I saw him do, the set up went good and we were up and running in no time. The other tasks that fell onto me were to initially build within Hudson and then create a small change from my local copy and committing it. This ensured that Hudson detected the changes and it worked as such. The next task is to commit a broken code and check if Hudson’s build report shows a failed build. I then received an email report saying it did so. Lastly, we fixed the bug and committed the changes and made sure that Hudson’s build is back to normal.

After a couple of days of using Hudson and practicing continuous integration, I find it as something I would definitely use in the future. Besides the automatic email notifications of any build failures, I find the logic behind small incremental changes as something that can improve any team based projects. This approach reminds me of the divide-and-conquer strategy which applies to the planning and then implementation of creating software.

Midterm Study Questions

2009-10-18T23:34:00.008-10:00

Here are some study questions for the our midterm.

Update: Added the answer to the questions

1. What are the three prime directives?

The system accomplishes a useful task
An external user can install and use the system
An external developer can understand and enhance the system

2. Give one example of a basic Collection class and describe it

Sets: no duplicates and add works differently
SortedSet: traverses elements in their "natural order"
List: Ordered collection and like an array with flexible size

3. Give three examples of our class Java Coding standards.

2 space indent
No tabs, only spaces.
Left curly brace on preceding line; right curly brace on its own line
100 columns of text maximum maximum
JavaDoc layout standards

4. What are some advantages of using Ant vs. Make.

Java-based
xml is simpler than a Makefile
Built in Java support and its tools
Easier to extend in a portable manner

5. Why do we have to run Ant once in order to import distribution files to an IDE.

So that Ant downloads the necessary libraries needed

6. Write a sample Ant Target code.

<target name="TestTarget" 
        description="Target that does nothing.">
</target>

7. What are some advantages of Git over SVN.

Allows users to work productively even when not connected to a network
Makes most operations much faster since no network is involved
Allows participation in projects without requiring permissions from project authorities
Avoids relying on a single physical machine. A server disk crash is a non-event with distributed revision control

8. What is the difference between White box and Black box testing.

White box testing tests the implementation of the code where it accepts an input and produces the appropriate output
Black box testing tests the expected output given the input

9. What are the three classic CM problems and describe them.

Double Maintenance: prevents multiple copies of the same file and must be updated independently
Shared Data problem: allows two or more developers access the same file/data
Simultaneous Update: Must prevent clobbering when two updating the same file at the same time

10.What are some properties that defines an OSS.

Free Redistribution
Source code availability
Derived Works

Configuration Management: Subversion

2009-10-13T23:51:00.003-10:00

In this assignment we have to practice using subversion as our centralized configuration management tool using TortoiseSVN as a subversion client and Google Code to host our source projects.
All in all I find this assignment very helpful in any group projects. Tortoise was very easy to use and install. When I first imported my source codes to Google host, I accidentally uploaded other directories such as bin, lib and build. Tortoise was easy enough to use where I just deleted my local copy and committed the changes to Google host's copy. As good as Tortoise's function are, I find it weird that I have to right click within directories to use all of its function instead of a graphical interface such as those in SmartSVN. Setting up Google host site was just as easy as using Tortoise. All tasks were completed except for adding a codesite-noreply@google.com. I posted to the appropriate forum so that they can add the link to our discussion manually.

You can check out my host site here and discussion here.
Updated WallEE.

Testing: It's not as easy as it sounds!

2009-10-07T03:07:00.010-10:00

On this assignment, we have to create different test cases for our Robocode robots. These test cases are Acceptance, Behavioral, and Unit tests. Acceptance test are tests that simply checks if our robot beats one of the sample robots in a given number of rounds. Behavioral test are tests that makes sure our robot’s movement, firing, or targeting are doing what they are intended to do. Lastly, there are Unit tests which verify our robots’ method output given different inputs. The later might have to be written after our robots’ code is "refactored".

We were given a heads up on the what these test are when we described possible test cases on our partner’s robot during lab. Describing these tests was easy enough but little did I know that implementing these seemingly easy test was going to be so hard.

For my acceptance test I used SittingDuck and Corners against WallEE. As for my behavioral test, I created a test to make sure my robot turns in the right direction since WallEE is based on sample walls, it turns left towards and perpendicular to the first wall it sees. Lastly my unit test consists of testing how my robot fires a bullet with power proportional to the distance of the enemy. This was the hardest to implement because I did not have the methods that was in accessible in WallEE such as determining the distance between WallEE and its enemy. This was a great opportunity for me to modify my code in order to have a “testable” block of code, which I did but to no result. It was hard for me to “refactor” that specific code so that I can test it and at the same time preserve its original function. So I did most of the distance calculation within my test which I know is not a good idea because it does not preserve the encapsulation of my code.

I don't feel that my tests adequately ensure the quality of my robot because I only have four test cases. Two of which are acceptance and one of each behavioral and unit tests. What I would have done is to test my other movement strategy which is WallEE treading back to where the enemy was to get another shot.

After implementing the test cases for the junit, I ran Emma which is another build tool that measures and reports Java code coverage. Here are the results:

Class - 86%
Method - 88%
Block -84%
Line - 85%

From these result I learned that Emma will doesn't really look at TestBedAssert which accounts for the missing coverage. Some of the code in WallEE's class was not run, onHitRobot, since most of my test enemy is a sittingDuck robot.

All in all this assignment was hard but very rewarding. The practice we get from creating not just only any test cases but good test cases will help us write codes that are both easy to understand and easy to test.

The new distribution file of WallEE can be downloaded here.

Build System: Ant

2009-09-29T20:47:00.007-10:00

As we progress and improve our robots for the improved robot Robocode rumble, we were introduced to a very useful build tool called Ant and its dependency manager called Ivy. We also got a first hand experience with the Ant code which was provided by our professor. We are to adapt this Ant code with our code and invoke 3 quality assurance tools.

ant -f checkstyle.build.xml
ant -f pmd.build.xml
ant -f findbugs.build.xml

The only problems I had after running checkstyle were with the javadoc and missing package info. The first one was really easy to fix. All I had to do was add the necessary @param that was left out. It is interesting to see how after revising my code to follow our class' java coding standards and having it reviewed by a classmate, that this necessary javadoc information was overlooked. This is where the quality assurances come in handy. The automation of tasks such as looking for coding standard errors helps achieve the 3rd prime directive, which informs an external user by providing a correct java documentation.

The other problem was not as easy to fix like adding the missing javadoc information. After looking at the results of running checkstlye, which I thought didn't help because it displays the same error message, I checked the original system to see what was missing and it turns out that within DaCruzer's directory is an html file that describes the package. So I did created the same file which describes my package.

After running checkstyle, I tried running the other quality assurance, pmd and findbugs, and did not get any errors.

These quality assurance tools are very helpful in producing robust system that corrects coding standards, improve code efficiency and packages easily. I had a hard time understanding what the Ant code does at first but now that we had hands on experience and understanding each line during a class discussion, I feel like this is something I can use in the future to be better programmer.

Updated WallEE can be downloaded here.

Test bout against Sample Robot!

2009-09-21T02:52:00.009-10:00

We are getting closer to the big fight and in the process testing and refining our robots against the sample robots we reviewed. Ever since our group discussion on designing counter measures against sample robots, I have been planning a robot that will win against all of the sample robots. My strategy is similar to the sample robot Walls. After reviewing each sample robots, I learned that Walls outlast the other robots by avoiding enemy fires, since it travels a long distance along the perimeter of the wall. I am adopting Walls because of this attribute, hence the name of my robot WallEE. I added some movement where whenever it scans an enemy, it goes back so that it will have another chance to shoot at the enemy. Another thing I added is just a simple avoidance strategy where it changes direction if it gets hit.

My robot did great against each sample robots. I purposely added the avoidance strategy just to defeat Ramfire and Walls itself. Those were the only robots that sometimes would fare better than WallEE. This is one of the things I had to improve on, to get a better percentage of winning. I realized that these two sample robot wins because they cornered mines. So I added a firing criteria where my robot fires a bullet with its power relative to the enemy's distance. This strategy, coupled with the avoidance strategy improved that percentage. I learned that I have to improve my robot's overall functions, movement, tracking and firing, so that it is equipped with different functions counter the sample robots

I learned from this experience, that adding functions to counter a specific enemy strategy is inefficient. I have to improve my robot's overall functions, movement, tracking and firing, so that it is equipped with different functions to counter the sample robots. This would be something I would've done differently. I would've tried a strategy that works on most enemies since it's too tedious to plan a counter for every strategy.

Download: WallEE

Robocode Sample Strategies Reviewed

2009-09-15T23:44:00.019-10:00

After creating our own movements and reviewing other people's implementation, it was a nice change of pace to review the sample robots the contributors of Robocode have created. I got an insight to some simple strategies for creating the best robot. Studying their implementation have shown me different methods I would have not known or use otherwise. This have helped me plan a strategy for the upcoming Robocode competition.

Review Tasks:

Movement: How does the robot move? Does it have an avoidance or following strategy?
Targeting: How does it find a target to fire?
Firing: What is its criteria for firing?

Wall
Movement: This robot moves around the perimeter of the wall in a clockwise manner. It does this by turning left and by going ahead to the wall it is facing. It has an avoiding strategy which moves the robot back if the enemy who shot it is in front and ahead if it's behind.
Targeting: Its targeting mechanism is very basic that it uses the game's call to scan which does it automatically whenever the robot moves or turns its body/gun/radar.
Firing: It also has a very basic firing system where it fires at an enemy whenever it scans an enemy robot.

RamFire
Movement: This robot searches for an enemy and ram it then when it hits its enemy if fires a bullet with power that depends on the enemy's energy. It does this by relying on the enemy's bearing which in turn determines how the robot turns in which direction.It has no avoidance technique since its primary objective is ram enemies for bonus points.
Targeting: Its targeting is dependent on how the robot moves when it changes it's direction.
Firing: The robots firing mechanism depends on the enemy's energy points. It fires a low power bullet if the energy level is low. The robot's purpose seems to use ramming as primary technique instead of firing bullets.

SpinBot
Movement: This robot moves in a circle and fires an enemy when in range. Its avoidance strategy is its circular movement.
Targeting: Its targeting mechanism is pretty basic, it fires whenever it scans an enemy.
Firing: Since its targeting is basic, this robot fires a bullet with a power of 3.

Crazy
Movement: This robot's movement just like its name suggest is crazy. Its erratic behavior resembles a chicken with its head cut-off. It has a set amount of pixel movement and changes direction each turn. It changes reverses direction whenever it hits a wall or another robot and then returns to its original behavior. Its erratic behavior is its avoidance strategy and consequently does not follow any following strategy.
Targeting: Considering its crazy moves, the targeting mechanism lacks the same extremity, it just follows the gun's heading.
Firing: This robot does not have any criteria for firing. It just fires when an enemy is scanned.

Fire
Movement: This robot mostly sits still and only moves when it is hit. It moves back and fort whenever it gets hit each time. Its avoidance strategy is useless if not close to nothing since it only moves so that it never gets hit in the same place twice consecutively.
Targeting: Its targeting system is basic. It relies on the gun's turning as a way to scan for enemies.
Firing: Its firing criteria is to shoot the enemy with a high powered bullet if it's target is close and lower powered bullet when near.

SittingDuck
Movement: This robot does nothing therefore there is no avoidance or following strategy.
Targeting: It does not find a target.
Firing: And does not fire.

Corners
Movement: This robot moves to the top left corner and just stays there. It changes corner for the next round whenever it dies.
Targeting: Its targeting system is average since it first checks to see if there is a robot in it's path and if there is starts it's custom firing method. It also only scans a 90 degrees radius that is adjusted depending on the corner. This however could be a potential flaw that limits the robot's firing range since it stops and fires at an enemy before it even gets to it's corner.
Firing: This robot's firing criteria is to use a bullet power relative to the enemy target's distance.

Tracker
Movement: This robot's following strategy is to close in at a chosen target and moves within 100 pixels of that target and fires. It moves back a little if gets too close.
Targeting: Since the robot's strategy is to follow a chosen target and gets close enough to fire, its targeting depends on the gun's turning.
Firing: This robot doesn't have any special criteria. It mainly shoots a higher powered bullet whenever it gets close to an enemy.

Upon writing my review for each robots, I realized that the best strategy is to balance the movement, targeting, and firing methods. All three aspects have overlapping functions that when combined properly can build one of the best robots.

Conforming to Java Coding Standards

2009-09-14T00:51:00.003-10:00

After reading the Elements of Java Style I can't help but admit that my coding style is not that great. I have used one-line comments placed right next to the code, which I thought seemed convenient since it immediately follows the code it refers to. Instead I figured that it is better to add it before the code declaration since we are only allowed 100 characters per line, which is part of our class' own coding standard. Since I imported the Eclipse formatting template I didn't really have any problems reformatting my robots to conform with the assigned coding standards. All of the work was changing the javadoc to third person, making sure it ends with a period. Another thing that I had to do was to add <code>...</code> tags since I included method names in my javadoc.

My updated source code.

Practice run in Robocode, gearing up for the Big Fight!

2009-09-09T06:13:00.006-10:00

Robocode is an excellent program that lets users design their robot's function and puts it to the test by facing off with other robots. For this assignment, we familiarize ourselves to the program by creating simple functions that teaches us movement, radar control and targeting.
These functions are:

Movement01: The minimal robot. Does absolutely nothing at all.
Movement02: Move forward a total of 50 pixels per turn. If you hit a wall, reverse direction.
Movement03: Each turn, move forward a total of N pixels per turn, then turn left. N is initialized to 10, and increases by 10 per turn.
Movement04: Move to the center of the playing field and stop.
Movement05: Move to the upper left corner. Then move to the lower right corner. Then move to the upper right corner. Then move to the lower left corner.
Movement06: Move to the center, then move in a circle, ending up where you started.
Tracking01: Pick one enemy and follow them.
Tracking02: Pick one enemy and follow them, but stop if your robot gets within 20 pixels of them.
Tracking03: Each turn, Find the closest enemy, and move in the opposite direction by 100 pixels, then stop.
Firing01: Sit still. Rotate gun. When it is pointing at an enemy, fire.
Firing02: Sit still. Pick one enemy. Only fire your gun when it is pointing at the chosen enemy.
Firing03: Sit still. Rotate gun. When it is pointing at an enemy, use bullet power proportional to the distance of the enemy from you.
Firing04: Sit still. Pick one enemy and attempt to track it with your gun. In other words, try to have your gun always pointing at that enemy. Don't fire.

The problems that I encountered were from Movement04 and Tracking02. I thought that movement04 was pretty hard because it involved trigonometry. After several failed attempts of trying to figure it out on my own, I asked my friend about it and he mentioned a website where he found a code that does what we needed to do for movement04. The code helped me a lot in figuring out how to do movement04 especially with the trigonometry functions. As for tracking02 my problem was getting my robot to stop within 20 pixels away from my enemy. I tried factoring in the sizes of my robot and my enemy into the calculated distance between, since the distance is calculated from the center of each robot, but it never worked. It is one of the problems I still need to work on.

All in all I thought that it was a fun assignment. As challenging as it is, I think that this is a good exercise for us not only to use open source materials but to apply different fields such as Math as tools needed in programming. My ideas for a competitive robot will most definitely involve Math since I plan to focus on movement and targeting.
My sample code can be found here.

OSS Experience: TV Guide Browser

2009-08-31T01:13:00.000-10:00

Goal: Apply and learn the Three Prime Directives of Java-based Open Source Software
Program: TV-Browser
Source: http://sourceforge.net/projects/tvbrowser/
Download: TV-Browser

Overview: TV-Browser is a TV guide that gathers information on the shows that the user is interested in. The program has extensive array of functions that the user can customize to fit their need.

Prime Directive 1: The system successfully accomplishes a useful task

In terms of functionality the program is extensive enough to deliver different user experience by customizing different functions such as favorite shows, specific time slots, show links, user ratings, etc. I find that all of these functions are useful but they are executed in a way that most people would find hard to use. The manual, that is accessible within the program itself, was useless since it's just a link to the program's Wikipedia page. I also find the whole layout too simple, where the show information are in different panes. A user might want a good flow of the things he or she needs.

Prime Directive 2: An external user can successfully install and use the system

I downloaded the program and installed it with great ease. The installation process was straight forward. The customization features starts with the installation where the user have choices which services or plug-ins will be installed accompanied by a short description of what they do.

Prime Directive 3: An external developer can successfully understand and enhance the system

The program have developer-level documentation, which can be found on the developer page.

Overall, I find this program very interesting but I would change most of the interface for me to use it more. All the functionality is included but the program missed on the implementation that would make the program user friendly.

Fizz Buzz Program

2009-08-30T22:53:00.004-10:00

It was pretty interesting that the very first thing we did in class, after learning everybody's name and expectations from this class, was to write a comparable program that prospective programmers might expect in a job interview.
The program is called FizzBuzz, which prints the numbers from 1 to 100 and substitutes "Fizz" for numbers divisible by 3, "Buzz" by 5 and "FizzBuzz" by 3 & 5.

I did manage to write the program correctly but it was a little different from the one we did as a class. For my "FizzBuzz" line I have:

if (i % 15 == 0) {
  System.out.println("FizzBuzz");
}

And as a collective class effort we came up with:

if (i % 15 == 0) {
  System.out.println("FizzBuzz");
}

It was interesting what everybody came up with considering there are different approach for solving the problem. I realized that our class' approach was better in terms of style and efficiency, my approach had two comparisons whereas the class' had only one.
So when I wrote the same program in Eclipse, I used our class' solution.

Here is my FizzBuzz Code:

/*
* Prints out the number from 1 to 100 but
* substitute Fizz for all multiple of 3,
* Buzz for 5 and FizzBuzz for 3 and 5.
*/
public class FizzBuzz {
  public Static void main(String[] args) {
    for (int i = 1; i <= 100; i++) {
      if (i % 15 == 0) {
        System.out.println("FizzBuzz");
      } else if (i % 5 == 0) {
        System.out.println("Buzz");
      } else if (i % 3 == 0) {
        System.out.println("Fizz");
      } else {
        System.out.println(i);
      }
    }
  }
}

As for Eclipse, I have been using it as my IDE since ICS111 so I learned a few shortcuts and it took me no less than 4 min to write and run the program with no problems.