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

Saving money with... WattDepot

"WattDepot is a RESTful web service that collects electricity data (such as current power utilization or cumulative power utilization) from meters and stores it in a database. The data can then be retrieved by other tools for visualization and analysis."

This week, we were to provide a simple command line interface for obtaining information from a WattDepot service. WattDepot gathers data that impacts the enviroment and the way the society uses energy, and also can saves us money on our electric bill.

By using the specifications, my partner and I worked on the Command Line Interface for WattDepot. We were able to accomplish most of the tasklist, except creating test cases. This project was an interesting way for me to learn a new way to do things in Java.

To view our code click here. Our group name is umikumakahi.

SVN Checkout:

svn checkout http://wattdepot-cli.googlecode.com/svn/branches/umikumakahi wattdepot-cli-read-only

Merging your work

"Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."
-Martin Fowler

When we started using Hudson, a popular open source continuous integration server, my teammate and I had difficulty with the connection. However, when we were able to connect, we weren't able to sync our project with the Hudson server through the use of SVN. The current setup is that whenever a member commits a new code, Hudson will verify the coding, and if it fails the build, it will send emails to the whole discussion group.



I believe that if we didn't have the connection issues, this tool would of help us tremendously by saving us time with integration.

A Quickie Midterm? Can this be true?

For our software engineering class we have been assigned the task of creating a list of 10 question that students should be able to answer quickly as a practice for the midterm. I created my questions trying to address mostly issues of sofware engineering and effective communication and not general programming.

Well here is goes...Good Luck!

1.Name three different kinds of that you can perform using junit and give an example of each.
Answer:
Acceptance, Behavioral, Unit

2.What is the difference between white box and black box testing?
Answer:
Black box testing is testing a program without knowledge of its internal working. Providing input only to confirm proper output and not what happens in between.
White box testing is testing with the ability to check the functionality of the code on the inside Having knowledge/access to the source code.

3.Name 2 benefits and 1 negative factor of distributed versus centralized as it pertains to subversion.
Answer:
Distributed systems have greater speed performing most task. Doesn't have a single point of failure. Has the flaw of not having a "czar" to constantly oversee code progress and maintain code.

4.What is the different between pmd and findbugs?
Answer:
pmd checks source code and findbugs looks in the compiled byte code.

5.What are 3 things we used checkstyle to check for in this course?
Answer:
Spacing
JavaDoc
That the open bracket was on the same line as the start of a method/class/etc..

6.Why is a professional persona important?
Answer:
It allows potential employers and others to gain knowledge of our interest and skills pass what a one page resume is able to showcase.

7.What are the three prime directives we used in this course and why are they useful to software engineers?
Answer:
That the software is able to perform a useful task. This is tested by an end user and not the developer.
That the software has proper documentation that it can be installed and used without much input from the developer. This is tested by an external installer and not the developer.
That the software has proper documentation and general good programming so it can be understood, used and modified by another developer. This is tested by external developer.

8.List 3 reasons why it's good to be a single-tasker versus a multi-tasker.
Answer:
Accomplish task faster.
Reduce the amount of errors you incur performing a task.
Reduces stress.

9.list 2 reasons why is it good to document code properly?
Answer:
To make code more readable during development and after development.
Make code understandable by other developers.

10.Give an example of a good post if you are trying to get help for a coding issue online?
Answer:
Uninitialized object error at the start of a loop.
I am receiving an uninitialized object error when running the code below.
***code directly starting the loop and then going through loop at least 2 lines below error***
Basically showcase the code thats generating the error and providing a copy of exact error doesn't hurt.

To Google or not to ...

For the past few weeks, I have been working on my robocode Robot MikeTerry. But now I want to share my code so that other developers can edit MikeTerry and make it even better. By getting familiar with Google Project and SVN client.

The only part in my conquest to put MikeTerry out there that I was unable to succeed in was to add codesite-noreply@google.com as a discussion list member, but otherwise I didn't encounter any problems.

I have learned that Google provides great features for developers. By creating Google Projects and Discussion Boards, the simplicity of having another developer look at your code became a world wide affair.


Here is a link to my discussion group

Testing: Being on point.

During the past week, I had MikeTerry (please see previous posting) doing tests to make sure he knew what he was suppose to do. MikeTerry went thru six tests case, which he successfully passed with flying colors. Here are the tests and results of this past week testing phase.

Acceptance tests are to be making sure that MikeTerry can consistently beat one or more of the sample robots that I have been using in previous assignments.

Test 1- MikeTerry VS. Fire: MikeTerry constantly won against this robot.

Test 2 - MikeTerry VS. Crazy: MikeTerry constantly won against this robot.

Behavioral tests make sure that MikeTerry that his movements and strategies are on point.

Test 3 - Clockwise path: As part of MikeTerry’s strategy, he needs to move clockwise; by doing this test I was able to see that MikeTerry always used a clockwise path without making any changes in his coding.

Test 4 - All 4 corners: One of the other strategies is to move to all four corners, which MikeTerry did successfully without any major changes in his coding.

Test 5 - Out of the center: I wanted for MikeTerry to stay within the outter wall radius and he did it consistently.

Unit test verifies that MikeTerry ‘s individual methods calculate the correct output values given various input values.

Test 6 - Firing: MikeTerry tested that his firing power was consistent. He needed to fire his enemy at the power of 2 or less when the enemy is in the range greater then 200 pixel.

During the testing phase, I discovered that my coding style didn't require alot of changes for testing. Here is MikeTerry tests and results.

Coach's last words: It is easier to code with testing in mind versus coding like a mad programmer and finding bugs everywhere to drive you to be even more mad.

Extra training for MikeTerry

In the world of rumbles and tournaments, in order to win, you must train. As part of training for a Robocode tournaments, one must assure that his or her code is error free. To do this, I called upon the help of specialized trainers.

What each trainers do: (according to their respective websites)
Ant: It is a Java-based build tool
that evaluates a set of dependencies, then execute commands.

Checkstyle: It provides checks that find class design problems, duplicate code, or bug patterns like double checked locking.

PMD: It scans the Java source code and looks for potential problems like:

•Possible bugs - empty try/catch/finally/switch statements
•Dead code - unused local variables, parameters and private methods
•Suboptimal code - wasteful String/StringBuffer usage
•Overcomplicated expressions - unnecessary if statements, for loops that could be while loops
•Duplicate code - copied/pasted code means copied/pasted bugs

FindBugs: It looks for bugs in the Java programs. It can find bugs by simply inspecting a program's code: executing the program is not necessary.

During the training sessions, MikeTerry was able to work on shortening his comments, labeling his parameters properly, and putting in the author tag. With these trainers MikeTerry's muscles (code) became more effective. The encounters between MikeyTerry and his trainers were unexpected. I had expected a few querrels and stubborness on either party but they worked pretty good with eachother. No particular problems. As the main trainer for MikeTerry, I have learned from his other trainers that my standarization coding must improve and how many ways I can improve other programs training. I really like these trainers as they simplify the training and elimate most of the tedious tasks that I have to encounter during a training.

After the training with the other trainers, MikeTerry and I worked on his level of energy for the next tournament. He was already well trained but with the increase of energy, he will be able to last longer in battles.

Here's a look at the before (this is a .jar file) and after (this is a .zip file) of MikeTerry's code.

In the blue corner, we have the contender MikeTerry v1.0...

In my previous posting, I reviewed the sample robots that we were assigned. And on Monday, we have a tournament with the advance robots that we wrote. As I prepare myself for the first RoboRumble, I am excited to see the competition.

MikeTerry v1.0 (Here is MikeTerry's code)
My robot’s name is MikeTerry, he is base on the sample robot Walls. The difference in my robot is that his fire power is based on enemy distance and if he is loosing, his fire power will be at 3.

I kept it relatively simple.

Practice Rounds
MikeTerry vs. Corners - Winner MikeTerry
MikeTerry vs. Crazy - Winner MikeTerry
MikeTerry vs. Fire - Winner MikeTerry
MikeTerry vs. SittingDuck - Winner MikeTerry
MikeTerry vs. RamFire - Winner MikeTerry
MikeTerry vs. SpinBot - Winner MikeTerry
MikeTerry vs. Tracker - Winner MikeTerry
MikeTerry vs. Wall - Winner MikeTerry (depending on starting points)

Training for next tournament
During the time following this tournament, I will train MikeTerry's strategy to beat the sample robot Wall.

Word of wisdom
It is hard to find one strategy to beat all the sample bots, it is easier to focus on beating as many as you can versus all of them.

The mole: Analyzing enemy’s strategies from the inside.

Before the big day of RoboRumble, I infiltrated into the enemy’s code, looking at the samples provided in the Robocode package I previously downloaded. The enemies called Walls, RamFire, SpinBot, Crazy, Fire, Sitting Duck, Corners, Tracker are analyzed in terms of movement, targeting, and firing, and their strategies are scrutinized. Here is what I discovered while I was in enemy base.

Enemy Name: Walls

Movement: He will move away from the enemy whenever he is hit, he will travel along the wall.
Targeting: He rotates around the board while shooting at the enemy scanned.
Firing: He always fires at the same strength.

---

Enemy Name: RamFire

Movement: He tracks the enemy and attempts to ram him.
Targeting: He looks to gain bonus points by keeping enemy scanned alive to ram
Firing: He fires according to how much energy the enemy scanned has remaining.

---

Enemy Name: SpinBot

Movement: He spins around in a circle while shooting at the enemy scanned.
Targeting: He turns in a circle while scanning for an enemy.
Firing: He shoots on a constant strength depending if the enemy’s spotted bearing meets the criteria of being greater then -10, away and less than 10.

---

Enemy Name: Crazy

Movement: He moves in odd movements attempting to throw off robots without good tracking systems. If it hits wall, it reverses direction and it always does this if it hits a robot and its caused the collision.
Targeting: He looks for any enemy.
Firing: He always fires at a set strength once enemy is found.

---

Enemy Name: Fire

Movement: Only moves when he is hit.
Targeting: He spins his gun while scanning for an enemy.
Firing: He fires depending on the enemy’s health.

---

Enemy Name: Sitting Duck

Movement: He doesn’t move
Targeting: He doesn’t target
Firing: He doesn’t fire.

*He is definitely not an enemy that I will take any strategy from*

---

Enemy Name: Corners

Movement: He will retrieve to the corner while scanning for an enemy.
Targeting: He targets the first enemy he scans.
Firing: The close he is to the enemy, the more powerful bullets he will use.

---

Enemy Name: Tracker

Movement: He will not move until an enemy is targeted, he will follow and maintain a distance from the enemy.
Targeting: He concentrates on one enemy until it dies.
Firing: He will fire at the same strength.

---

With the opportunities of being on the inside, I was able to take some of the strategies in consideration for my warrior robot. Now I have to go prepare for battle. At war we shall meet again.

(image source: http://davidalves.net/images/robocode/robocodeII_logo_idea.gif)

Plastic Surgery for Robots

While observing Paul Galiza’s Code, I realized how important standardization was in the world of programming. As I look carefully at his code, I was amazed by the differences that people can have for coding the exact same function for the same project. Having a standardized coding helps future users and the author to decipher what is actually happening in the code.

After reading The Elements of Java Style, I started editing my robots’ code (from last week’s project) to meet the standards. I felt that I was a plastic surgeon giving my robots makeovers. I got so into editing my codes that I wanted to give a makeover to all of my previous projects to meet that same standard but I decided not too as I will probably start dreaming about coding and won’t be able to make the difference between English and Java after awhile.

Here is a link of my newly improved robots.

OSS Experience

This post will be on my review on a Java-based Open Source System. My overview is based on the Three Prime Directives which are:

Prime Directive 1. The system successfully accomplishes a useful task.
Prime Directive 2. An external user can sucessfully install and use the system.
Prime Directive 3. An external developer can successfully understand and enhance the system.

Overview

The open source package I chose to evaluate for use for my software engineering course is java2HTML. This package can be downloaded at http://sourceforge.net/projects/java2html/.
The objective of this application is to provide a simple-to-use tool which converts Java Source Code into a colourized and browsable HTML representation.


Prime Directive 1

This package successful meets the Prime Directive 1 by accomplishing the task of converting Java Source Code into an easily readable HTML code which can be uploaded as a simple method for none HTML/CSS coders to share code they have developed on the web.


Prime Directive 2

This package meets Prime Directive 2 as it can be successfully installed as a stand alone application without task more complex then setting the proper directories.


Prime Directive 3

The package meets Prime Directive 3 as an external developer can successful understand and enhance the system with basic Java knowledge up to the point of being able to ulitize a jar file.

The package does provide sufficent documentation to utilize all of its functions without reading any of its code.

FizzBuzz Application

During the first day of Software Engineering class, we had to write the FizzBuzz application on paper which was hard since I didn't remember all the java syntax at that moment. One of this week's assignments was to write the appplication in Eclipse. After a 10 minute review of the Java syntax this application took me about five minutes to implement. It was a good way for me to get back into the groove of programming since I haven't been done it for quite some time now. I didn't encounter any problems during the writing of this application.

The code below implements the FizzBuzz application.

public class FizzBuzz {
//FizzBuzz application prints FizzBuzz for numbers that are both multiples of 3 and 5. It prints Buzz for mulitples of 5 and Fizz for multiples of 3.

  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);
      }
    }
  }
}