Saturday, September 27, 2008

Emma & JUnit

"EMMA is an open-source toolkit for measuring and reporting Java code coverage. EMMA distinguishes itself from other tools by going after a unique feature combination: support for large-scale enterprise software development while keeping individual developer's work fast and iterative."-- Taken from EMMA

I am real fortunate to have learned to use EMMA with JUnit test cases. I found the software to export a great html interface and easy-to-navigate pages with clear and concise visual representations of what functions and lines were hit and not. This feeds to the approach of "test driven development". The key is not to develop test cases that is geared for coverage, but to deveplop good test design which will yeild 100% coverage. I can easily see how a novice programmer using EMMA will just write test cases to obtain 100% coverage under the EMMA output. According to the paper "How to Misuse Code Coverage", written by Brian Marick, he gives the following tips:
  • Think of what the feature in the interface that condition corresponds to.
  • Rethink how you should have tested that feature. Don't worry about how to satisfy the coverage condition, or think too muhc about other missed coverage conditions in the same feature.
  • Run the new tests and recheck coverage. You should expect to satisfy the missed coverage conditions in the feature, even tho you didn't specifically target them.
  • Repeat for the other features
The bottom line is: don't give into the urge to satisfy the '100%', as tempting as it is, don't design test cases that way.

Unfortunately, that is easier said than done. I found myself looking at which functions I didn't cover, then just writing test function which uses assertSame to see if they work. Then I took a step back, but double-thinking it, I since the detail of the missed lines were so small there really was no other way to do it.

Recently we were given the task to modify code that satisfies the 100% coverage but have it fail test cases, just to prove that having 100% will never be sufficient. I was confused to how I would actually implement something like that... I initially took a wrong approach and modified JUnit test cases, then took a different route and had the data structure mess with the cases instead. Successfully that was correct and was quite easy to accomplish. The idea is that the cases assume the best, but don't expect a the unexpected. The functionality is right, but only to a certain extent.

Source:

Wednesday, September 24, 2008

Ant.Lab

Goal

The goal of this in-class exercise is to help you get oriented to the build system standards for this class, and the use of Checkstyle, PMD, and FindBugs to improve the quality of your Java systems. .

Automated Quality Assurance vs. Manual Quality Assurance

After reading John's review of my CodeRuler assignment, I found most of his points to be valid and equitable. We did miss some key points as far as Javadoc format and content, simplifying if-else statements and function calls and some formatting errors. If I were to go and fixed the issues that John picked out, I would take an estimated 5-10 minutes on styling issues, and perhaps another 15-45 minutes with redesign and implementation. On the flip-side, when running an automated QA, seriously amazed by how much the human eye can miss! 500+ Checkstyle errors/warnings alone. This is a serious efficiency improvement, mainly because it literally took seconds to generate this huge list, each with this own reasoning, and explanation.

When considering actually sitting down and taking the time to fixing some of these (extremely) minor errors, the time-cost factor comes into play. After running eclipse formatter through each of the files downloaded from IBM, it dramatically reduced the amount of Checkstyle errors across the classes. PMD produced about 30 of priority 1 & 3 errors throughout the project, all which seem very easy to fix. These findings are definitely something that a human eye will not catch verbatim.

Conclusion

I'll conclude by saying by saying that the Automated QA is worth the integrity and quality of your project. It will be a time consuming process, but the caliber of your code will be at best. It is easy to spot hard work when you see it. The last thing you want to be judged on are your flaws.

Tuesday, September 23, 2008

Ant - Stack

Objective

  • The Ant build system
  • Open source Java automated quality assurance tools (FindBugs, Checkstyle, PMD)
  • The course standards for build system structure and packaging.
I was first exposed to Ant through my internship last year. Initially, I was confused; there was too much unknown functionality and processes that took place during an Ant run-time. I was told that Ant is like a Make in C, simple enough right? I took a look at the .xml files and tried to trace through them; I was completely boggled by the syntax and functionality. After visiting the .xml files in class and tracing them step-by-step, the ambiguity has slightly cleared up. Ant was made to speed up the production, implementation, testing, and development of software. Another benefit of Ant is that it helps with the migration of software from one platform to another. The evidence is relevant, I'm assured that this tool is a powerful tool and will be implemented in my future Java software productions.

Installation

If I could sum it up in one word: Easy. I decided to tackle this class on my Macbook Pro; this is the first time I'm using OS X as the operating system of choice in a Java Development Environment. Class variables are very easy to setup through terminal. I felt that the entire installation process was drag and drop, defining paths, then command line tests.

Stack


Now the stack project that was easy to setup and install. I used Terminal to utilize and execute the tools: checkstyle, findbugs, javadoc, junit, and pmd. I found all of the tool extremely easy to use and fixing errors were as clear as black and white. I was surprised how everything was visually easy to naviagate through with the help of self-producing .html files with links to warnings, erorrs, and solutions.

Components

  • Checkstyle has a huge impact on the aesthetics of your code, this will dramatically prepare your code on a visual level. This really takes eclipse's built in "formater" to the next level.
  • Hands down, my experience with Findbugs has been incredible. Throughout my college career, I was bombarded with typical error lines like "syntax error on like 144 near ' ". I was blown away by the descriptions and recommended fixes that Findbugs produces. It really takes the strain away from formulating error fixes.
  • PMD is a very cool tool that handles error and messages with priority levels. This tool finds possible bugs through empty statements, dead code, suboptimal code, overcomplicated expressions, and duplicate code.
Review Process

After invoking the ant targets, and having them produce the corresponding html files, it was just a matter of command-tabbing between eclipse, terminal, and Firefox. I found myself just fixing errors and cycling through the three. It was elegant, yet troublesome. if the entire process could be done in 1 window or application, I feel that this would have been much more efficient. The actual error correcting was a peice of cake though, mainly becuase the tools tell you what to do. "Use this instead of this, line x." "Needs a white space after '{' " As far as this assignment goes, it really easy to use Ant, and adapt to the process of fixing errors.

stack-erinjuneilkim-6.0.923.zip

Sunday, September 14, 2008

CodeRuller Review

Objective

  • to provide you with practice in identifying violations of our Java coding and documentation standards
  • to give you a chance to look at another person"s CodeRuler implementation

Overview

I was assigned to tackle the code done by the 'lau-sanchez' group. After downloading, compiling, and running the application, I was able to test it against several of the prebuilt AI that came with the application. The Ruler was actually implemented surprisingly well, after testing it against multiple opponents, they won all their battles. The in class demonstration against the Smart Split and the Gang Up was successful as it made a come back and won the game! Even the programmer, Phillip Lau, was surprised that they won.


Dissecting the written code was somewhat of a different story. First, looking at someone else's code, you want to feel that you can pick it up and have it be at a level of consistency where you don't have to pull your hairs out to figure out what is going on. Fortunately, this code was easy to read through and follow in the aspect of: class use and structure, function calls, and strategy of this Ruler. Even the logic of each method preformed the tasks with noticeable efficiency. On the contrary, I could note that there was almost no uniformity in the JavaDoc of the different functions throughout the class. Problems vary from having extra indentation spaces, made up "@tag" names, capitalization, and extra tailing asterisks(*). Inconsistency was prevalent throughout the functions as well, there was one function with almost no indentation across for-if nested loop, while other for-loops had a three-space indentation. Many would agree that this just really reduces the readability of the code, luckily they are really easy fixes.

Below are the specifics with respect to the ICS Java coding standards and the Elements of Java Style rules.


Lines noted with an asterisk(*) represents more lines that what has been stated.
FileLinesViolationComments
MyRuler.java*ICS-SE-Java-1Code is not within the package hierarchy "edu.hawaii"
MyRuler.java4ICS-SE-Java-2Do not use the wild card "*" in pimport statements
MyRuler.java7,8,9,*ICS-SE-Java-6Made up JavaDoc statements? (@date, @course, etc...)
MyRuler.java11,15ICS-SE-Java-6Supposed to be one continuous JavaDoc statement
MyRuler.java15,16,17,*ICS-SE-Java-6Indentation is incorrect and extra (*) in the closing comment
MyRuler.java42,54ICS-SE-Java-6No JavaDoc
MyRuler.java83,87,90ICS-SE-Eclipse-2Spacing is at 3 instead of 2
MyRuler.java96,97,98,*ICS-SE-Eclipse-2No indentation here
MyRuler.java101,102EJS-2Use curly brackets for clarity and readability
MyRuler.java111,133,142,*ICS-SE-Java-6Capitalize the beginning of these sentences
MyRuler.java159EJS-9There is no indication of what 25 and 3 represent and why they are used
MyRuler.java86,117,124EJS-7Space between the close parenthesis and open curly bracket



A majority of this list could have been avoided if they took the 2 seconds to have eclipse format the code...

Conclusion

Its not always an easy task to pick up someone else's code and trace it,(no brainer). When a programmer formulates ideas and flowcharts in their brain, most of the ideas are convoluted when it translates from a thought to text on a computer screen. The coding standards/conventions have helped ease the pain over the years. After the encountering the problems and difficulties in this assignments, I feel that these constraints are imperative to the coding society, even if it takes something as stupid of a rule as "Use meaningful names." to be published in a book. Saves us a lot of time, and ultimately-- money.

Sunday, September 7, 2008

CodeRuler

Objective

Taken from assignments page:

  • Become more familiar with the Eclipse IDE.
  • Begin to understand the complexities of working effectively with other people on a software project.
  • Have some fun!
What is CodeRuler?

Taken from the IBM Site:
"The game has a simple premise: You are the imperial ruler of your very own medieval kingdom. Your peasants and knights depend on your brilliant strategic thinking, agile adaptability, and superior Java programming skill to survive, increase, and prosper. Your objective as a player is to write Java code that simulates this ruler. The gaming simulator pits your ruler against up to six opponents' rulers (or the included sample rulers) and determines the winner."

For this assignment, I have collaborated with my partner, Daniel Arakaki. The scope of this program was somewhat small, so implementing a single class together was a little tight. We did find an elegant solution tho: we decided on one person to handle the peasants and another to handle the knights; since it takes both units to strategically win the game. Daniel was actually a really good partner; he had a significant amount of strategy and implementation ready a week prior to the deadline. Our only form of communication was through email, and yet, speedy replies and effective communication was in play. On the contrary, I do think that the assignment could have been handled individually, which could have taken away the stress and worry about your teammates end of the bargain.

Strategy

Things to keep in mind:
  • Peasants who can claim and work the land.
  • Knights who can fight battles and capture other rulers' peasants, knights, or castles.
  • A castle that can create more knights and peasants. The more land you have, the faster it creates them.
The strategy really is two part: Peasants and Knights.

Peasants
As far as peasants go, there isn't really much that they can do. Move and claim. How in the world do you come up with a strategy for such a brainless class? Initially looking at IBM's Code sample, I noticed the way that they randomly assigned directions for each of the peasants. I stopped and pondered if there is a better way. Maybe to migrate as a pact? Disperse? or optimize the random movement? I decided to take the last approach and restrict the peasants movement to reduce the amount of moves a peasant makes in its own claimed territory; making wiser directional choices will help increase the amount of land claimed in a smaller time frame.

Knights
I feel that knights have a lot to do with if you are going to win the game or not. Who do you attack first, the peasants? Other knights? Go strait for the castle? Daniel was the mastermind behind this one. Daniel went ahead and implemented a peasants > castle > knights precedence, which is somewhat effective in some cases.

Conclusion

As far as the Eclipse IDE experience, its only beginning to grow on me in a positive way. Some of the experiences include: the easy importing of jar files, import statements, auto-JavaDoc filling and generating, easy indentation edit, cascading function/variable name changes, I mean the list just goes on. I'm just excited to see what else it has in store for me.

As I took a look at the programming aspect of the assignment , I found the the way the classes were structured and coded were perfectly. The inheritance hierarchy made the object easy to interact with each other, as they held similar properties and functions that weaved this game together. Here is an illustrated example (taken from the IBM Site):



As you can see, shared functions through the IObject interface lace the individual instances of peasants, knights, and castles. The IObject coupled with the World.java class/functions make room for easy programming. Which brings me to my next point. A speed bump that I encounted in this assignment was to actually strategically think of how the best way to "rule the territory" was. Long story short, the coding is much easier than coming up with some type of strategy, but at the end of the day, I can easily say that this was a fun and engaging assignment.

Results

Our Score on the left, Computer on the right

v. migrate
508 - 14
582 - 16
390 - 4

v. gang up
135 - 436
140 - 433
182 - 399

v. split up
120 - 405
136 - 392
116 - 417



Source

JavaDoc

Monday, September 1, 2008

Open Source Software Engineering

Overview

OSS?
This journey to have download, install, and use a Java-based open source system was quite... difficult. First being new to sourceforge, my initial impression of the service was overwhelming. The site consisted of: millions of projects, billions of downloads, varying categories, and ability to create your own project just to name a few. Then the question of OSS (Open Source Systems) come into play. Why are we even concerned with using OSS? Well, after reading up on it, long story short: The OSS development approach has helped produce reliable, high quality software quickly and inexpensively. Onto the experience.

The Install
The open source projects on sourceforge are very extensive in functionality, usability, compatibility, and amount of dependencies required. After browsing categories and filtering "Programming Language: Java", I found my self going through program after program, looking at supported (OS) operating systems, the amount of dependencies I had to install, check if the dependencies were compatible with my OS, most even required a back end database then they expected you to already have installed. Luckily, after an adequate amount of time searching for something plausible, I can across Arcus, https://sourceforge.net/projects/arcus/ .

Taken from the Arcus site:
"The main features of Arcus are
  • 3D display of the cube, including animated rotations and layer turns.
  • Besides solving the cube (that is, from any pattern getting to the state with one color on each side), Arcus is able to get from any pattern to any other goal pattern, which is a more general task.
  • 3D Pattern Editor to specify the goal pattern.
  • Pattern Store to gather and store pretty patterns.
  • Keeping track of each turn, allowing the user to bidirectionally walk through the cube's history.
  • Easily configurable Look and Feel, colors, mouse behavior, etc. Most of the changes take effect immediately."
Two files to work with:
- arcus-0.3.2-source.tar.gz
- arcus-0.3.2.jar

The .jar file is the actual application. In the .tar.gz file you'll find the source code, as well as the readme, makefile, change log, etc. I used the eclipse environment to create a new Java project, imported all the .java files with the accommodating packages/directories. Headache isn't over yet, error galore... Luckily Eclipse finds the causes of these errors and recommends solutions with a single click. I found that the main cause of errors were package name/declarations and my file hierarchy. I guess the way that eclipse imports them, isn't complementary to the import statements. I successfully fixed all the errors across the java files, unfortunately, they were still filled with warnings... The project was successfully able to compile, but upon execution, I hit an "Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError". The application failed to execute after that.

The Three Prime Directives for OSS Engineering
01. The system successfully accomplishes a useful task.
02. An external user can successfully install and use the system.
03. An external developer can successfully understand and enhance the system.

I actually found this application to be very useful. Its great for people who don't know the trick to actually completing the Rubik's Cube puzzle! Keep in mind that it doesn't give out tips or instructions, mainly because the functionality of the application is to analyze the algorithm used to solve the cube. The website does give out instruction for compilation, though I guess it takes a little bit more configuration for Eclipse. I'm still fairly new to errors pertaining applets and such, troubleshooting them would take a considerable amount of time. The user interface is excellent and the ability to rotate the cube, go step by step, see a rotation log, etc makes this visually pleasant. The Java classes are easy to follow and the methods/variable are logically sensible. The underbelly of the program lives in the algorithm of the Rubik's Cube. By all means an external developer can enhance the outcome. The other classes mainly pertain to the gui's, models, etc.

Conclusion
In conclusion, I am walking away with more appreciation for the difficulties involved with achieving the Three Prime Directives of Java-based Open Source Software Engineering. Even with a simpler project such as Arcus, such tasks are more than trivial and require more troubleshooting and thinking. I would imagine for a bigger project, even getting the dependencies correctly installed and configured would take a substantial amount of time.