When the bell rings..class is over!!!

Three things I want to get off my head.

1.If you are a Computer Science Major at UHM, take ICS 413.

2.If you are a EE major with a focus on computers at UHM, take ICS 413.

3.If you are a MIS major who is leaning towards the technical side at UHM, take ICS413.


Ok, so with that being said. I had a great time in the class watching other students tackle their development issues and try to learn how to schedule themselves to get things done. Being a little older and a non traditional student coming back to school after working a few years in Systems Administration/Engineering in some fast pace enviroments, I came adjusted for the "pop a new technology in your face and you need to know how to use it since yesterday mentality". However, I learned a lot more then I expected during this course about how to better design systems and work with others in a more directly integrated enviroment. I liked how the class was designed where we watched web cast of the class at home and did coding during the class. This lead to those initial "huh!?!" problems that are frequent in the IT world being solved by the professor or other students immediately. I definitely enjoyed working with different people on different topics during the class as I got a direct chance to see how they think through coding issues and not just the product. This helped me to find more propectives to include in my thought process enabling me to be able to pose options to issues that my team faced that were not only my primary way of doing it, but also a way I saw somebody else tackle a similar style issue.

Ok ok...I realize I am rambling on with a thought dump right now, but no better time then to let it out at the end, I figured.

So at the end I applaud all the students who gave their all during this course to become better Software Engineers and I am thankful for the opportunity to learn from everyone.

Saving everybody some Green$: GreenOMeter 2.0

During the last month or so, we (the same team as previously mentioned in my post for GreenOMeter v1.0) have been working on this application GreenOMeter. With the specifications, we started to implement functions for the 2.0 version of GreenOMeter. This time around, I feel that we were much more organized in the distribution of tasks. For the final end result of GreenOMeter v2.0, we have seperated the stop light and the grid onto two different pages, adding three more pages about the functionalities of the application and our contact information.

I have to say this time around was a very interesting experience and as this was my first time thinking in the mindset of a software engineer versus that of a programmer I see a clear in distinct difference in what outcomes the they produce. We initially thought "Hey! Let's add in every feature possible!" and I was definitely mental pushing towards that direction, ok so yea I did implement some wasted code like facebook integration to allow users to post the current chart or green days to their facebook accounts. Ultimately I applied the rules of Software Engineering I learned through the course and decided to drop it until we first determined completely how to implement all required functionality and start on that. Once we felt safe in our progress in that area we could proceed to add bells and whistles.

I had a lot of fun and I am very thankful to my group for coming together to tackle task. We developed a technique of switching task as we learned more about ourselves and each other to allow for the best possible outcome. We didn't go for a hey, let that guy do all the coding or documentation method. We even stapled off the only let the guy who seems the best at programming handle the hardest task. What we did was give everybody a decent range of task to in each area and if they got stuck another group member or the whole team would converge on the issue to solve it.

At the end of it all, we had a fully functional application that presented with a good and well thought through user interface.

Using the User Guide page on our Google Code project hosting website, you can take a look at our project.

Break from our own code...

Now that our project has been presented, it is time to look at another team's project. WattWaiter is the project that I will be reviewing this time around. Using the UserGuide provided by the team, I installed and started my review based on these guidelines. You can read my full review here.

After testing out their application, I didn't find a way to break their system. I tested different dates and inputed false information and always received the right output. A few things that I like about their web application is that it is clean cut and colorful. On the other hand, I find myself scrolling up and down a lot to view the data. Maybe make the flags smaller, make the data show horizontally versus vertically and also add the meaning of the colors. Also, I would suggest putting the logo and the date input box on the same row. There is so much space horizontally and it would save the scrolling for the user. Overall, the WattWaiter team did a good job.

Going rogue... i mean Green

During the last week, my group (Edward Meyer, Bao Huy Ung, and Alex Kan) and I, we have been working on this web application based on our previous project WattDepotCli 2.0. By using the instructions on the following page, I believe we met the requirements for the project.

Team Work
We communicated mainly by email, however our communication was not as effective as I would have hoped. Hopefully, we can communicate more effectively and resolve issues before the last minute.

Statistics
I had trouble trying to retrieve data from hackystat.

And here is the statistics from the Emma Coverage for our final build.

[concat] Emma Coverage summary
[concat] class: 89% (8/9)
[concat] method: 84% (41/49)
[concat] block: 79% (1230/1562)
[concat] line: 67% (201/298)

Using the User Guide page on our Google Code project hosting website, you can take a look at our project.

Version two point O

My partner and I had to revise our WattDepotCLI to version 2.0. With this new version we added three new commands and we also took in consideration the adjustments to be made from reviewers previously stated in their blogs from last week.

I believe that we have fully fulfilled all the requirements requested from the command specification from the following page, with the exception of our ChartCommand that doesn't produce correct output but produces the Google page. The reviewers stated that we lacked of test cases and documentations. In this version we focused most of our time on those particular issues.

We communicated via Instant Messaging for the whole project. It was easiest for both of us as our schedule didn't always coincide. We tried our best to partition the project equally.

Below is a screenshot of Software ICU for our project for the previous 7 days.
We had pretty good coverage and we kept the system health stable throughout the duration of the project.



And here is the statistics from the Emma Coverage for our final build.

[concat] Emma Coverage summary
[concat] class: 100% (27/27)
[concat] method: 96% (74/77)
[concat] block: 86% (3538/4098)
[concat] line: 78% (668.4/860)

We completed the following questions in regards to the Oahu power grid during the month of November 2009 from the source SIM_OAHU_GRID

What day and time during the month was Oahu energy usage at its highest? How many MW was this?

November 28th at 02:45:00.00-10:00: 995MW

What day and time during the month was Oahu energy usage at its lowest? How many MW was this?

November 26th at 20:00:00.00-10:00: 496MW

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

November 26th: 995 MWh

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

November 26th: 493MWh

What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?

November 4: 29,959 lbs

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

You can download our WattDepot-CLI system here under umikumakahi-2.0.1116.zip.

How I feel about other peoples success and problems.

In the recent review we did on 2 other teams projects which were ewalu and ewia for the wattdepot-cli project we have been working on which can be downloaded here. I found that I learned a lot studying the design of others programming not just from a check out it out and find good code to stand point, but as a way to determine problems that result from implementing different techniques and benefits. As for looking at the reviews of my own teams code which is currently being updates and can be checked out from svn here. I took in some really important insight into some ways we easily overlook problems like with happy path testing. I didn't recieve one review from one of my reviewers David Mau which I believe was due to a name confusion issue between him and another classmate, but I feel I was able to understand our mistakes. Next time I around I believe the key is to perform the same level review on our own code in increments as we program rather then let issues pile up or wait for others to discover them.

Looking at someone else's code

Here's a change. After a few days looking at my own code, I was starting to dream about WattDepotCLI. This week, in my Software Engineering class, the professor has asked us to do a peer review by using his review checklist.

The following links are the reviews for the team Ewalu and Eiwa. And you can also download their WattDepot version here.

Team Ewalu

Team Eiwa