Tyler Wolff » Programming

New INK Design Website

Tyler — Sun, 04 Jul 2010 22:31:37 +0000

During the past few days I had the chance to remake the INK Design website for my good friend Kamran Samimi, a printmaker and graphic designer from Honolulu, Hawaii. We brainstormed on a bunch of out-there ideas to present his work but eventually settled with something somewhat similar to how this site is laid out. Kamran had already been putting some of his work on a Cargo Collective site, one of the coolest web frameworks out right now, but he had reached the limit to posting as a free user and he didn’t want to pay for it since he has his own website. I thought why not take the code base from my current site and modify it to make it more project based, similar to how many cargo collective sites are. This is how it turned out:

How it was made

Just like this site, the INK Design website is powered by WordPress and the Carrington framework. WordPress handles all the content and Carrington handles how the content is put together and displayed to the user (more about Carrington in this post). Since my site already has many of the features Kamran wanted in his site like in-page ajax loading of posts I built upon what I already had, changing some CSS here and modifying some Javascript there. Getting a test site up was a fairly quick process. The good thing is, while I was creating the theming for the site, Kamran could post projects to the site simultaneously.

In-page loading of project posts

Once the site was functioning well enough I decided to give it some INK Design flavor. One of the original concepts for the site was to have one giant canvas that moved around depending on what type of projects you wanted to see and for this Kamran created a huge spaced out image of blending colors and designs to act as the background. I took this giant image and cut it up into ten smaller ones to use for the background of the site design we had created. I found a pretty nifty plug-in, jQuery Backstretch, that provided exactly what I needed to display a fixed full screen background at various screen resolution sizes. I used this to create a randomized full screen background generator. If you refresh the page or navigate to other pages you’ll see it in action. The good thing about the backstretch plug-in is that it loads up the image after the page has rendered decreasing page load time.

The one big problem in this site is that it uses a couple fixed position elements which do not work well on mobile devices like the iPad. For instance the background will scroll up on mobile safari revealing a basic gray colored background when it should remain fixed. Also, the layout gets squished together a bit more than it should on mobile browsers. Hopefully one day when I have more time I’ll be able to fix these issues.

All Tools Used

Update: this site is also featured on the Carrington framework’s homepage!

The New Website

Tyler — Wed, 17 Feb 2010 08:08:58 +0000

I have been wanting to update my website for a long time, but with school, work, and everything else on my plate last semester I could not find the time to really make it happen. Fast-forward to the start of 2010 and I have graduated, plus I have had more time on my hands to actually work on fun things, like a new website. I already had a ton of ideas for how I wanted the site to be, so I started designing / coding what eventually turned into the current version of this website.

The Concept

The basic concept I started with was to have a home page that would show small excerpts of blog posts with a corresponding thumbnail. Upon clicking one of these excerpts, the full post would then be loaded inline via ajax. In addition, I wanted to have everything align to a grid at all times. Before making this site I had seen this done on a couple of sites, but none of these were running on WordPress.

The Main Problem

With WordPress you normally have one template for your homepage and one for a single atomic post which means that a single post on its own can only be loaded via the single template. Because of this a post only exists on the homepage, where all posts are normally shown, and on its single, or permalinked page. There is no way to grab an atomic post on its own using WordPress’s default functionality. To get the layout I described above I could have made the single post template only return the post’s content and have that load through ajax via its permalink. However, the problem with that is when a user navigates to a permalinked post, all that would show up would be the content of the post. What I needed was a way to grab a post’s content on its own while also providing a nicely styled single page for permalinked posts.

How I Did it

I realized that I would have to write custom functions to query the wordpress database in order to do this, and so I started with that. Then one day I stumbled across the Carrington, a CMS theme framework that extends WordPress and makes it extremely easy to customize. The main difference between WordPress and Carrington is in how the code is abstracted and what can be done with those abstractions. Here is a diagram that shows the difference between the page load for a single post view in the WordPress Default theme and how the same in done in Carrington:

Now all this is great for customization, but why I eventually settled with using the Carrington Framework was because of the built in Ajax loading. It was exactly the thing I needed for this site as it gave me a way to show both excerpts and full posts on the homepage, while also providing a template for permalinked posts. Plus, its slick. Carrington provides it for viewing archives, but it’s easy to apply it to all posts.

Another wonderful resource I found for use on this site was jQuery Masonry, a layout plugin that auto-aligns elements based on a given grid. I’ve always loved sites that auto-align elements of different sizes so I was happy to apply that same look to this site. I had to hack the initialization part of the plugin a bit to get it to work right with Carrington right but it turned out to work great! I love this plugin.

Technology Used

Overall, I am very satisfied with how the new version of tylerwolff.com turned out, though there are still problems to be fixed (IE7 layout, contact form messages, etc). In the future I plan to repair these problems, as well as add more content to the entire website. I might even write some more entries on the making of this site, going through some of the custom code I had to write to get everything to work together. What’s cool is the site is now featured on the Carrington homepage and showcase page. Check it out ↓

In the GREEN with HackyStat!

Tyler — Fri, 07 Nov 2008 02:32:00 +0000

THE DEVELOPMENT OF A SOFTWARE ICU

A software ‘Intensive Care Unit’ is basically a set of tools for assessing and maintaining project health. It is very much like a hospital’s ICU, as it monitors health via vital signs, except that it is monitoring a software project. Of these vital signs, some can give one a very clear idea of how a project is doing. Measures of this type include things like code coverage, complexity, coupling, code issues, and churn. For instance, if a project has bad code coverage, it is invariably lacking in some areas, thus being less ‘healthy’ than it should be. There are also measures like build counts, unit test counts, project size and development time, which give project health indications. However, with these measures, it is harder to say what is healthy and unhealthy since every project is different. They are there for one to manually interpret and analyze.

What’s so interesting about a software ICU is its use in collaborative software. When there are projects being developed by multiple people all at once, its hard to know the current state of a project without manually running tests and doing analysis. When this is done, you then have to share these results with other teammates and that is another task in itself. With a software ICU, daily builds can send vital sign information to a central tool that analyses all the results in an effective way. This way, all project members are able to see the projects current status at any point, from anywhere. Everyone can see how everyone else is working on a project, as well as how consistent code is committed. A software ICU is a valuable tool for doing all of this.

Hackystat, developed by Philip Johnson, is one such tool for measuring a projects overall ‘health.’ Scheller and I decided to set it up to monitor our Due Dates project, along with the other teams working on their versions of Due Dates.

USING THE HACKYSTAT SYSTEM

Installing and using all the HackyStat sensors was a long, yet essentially easy task. Luckily, with the Due Dates project, Scheller and I were already using JUnit, Emma, CheckStyle, Findbugs, and PMD. This meant we only needed to install a few more tools on our system. These included SCLC, Javancss, and DependencyFinder. The eclipse plug-in worked seamlessly with the IDE. That took no time at all to install. Integrating the Ant sensor was just as easy.

The main problem I ran into was getting the svn sensor to work. When I initially went through the hackystat tutorial, I did not have to set up anything regarding username and passwords since everything was passed through the command line:

ant -Ddefault.account= -Ddefault.password=
 -Ddefault.sensorbase= -f svn.build.xml

I forgot about this when using it on the Due Dates system so I kept getting errors. Luckily hackystat provides an abundance of user wiki pages to help solve these types of problems. I realized I had to create a UserMap.xml file that held those parameters for me.

Other than that, I did not run into much trouble installing the system and its sensors. I set up a daily build task on hudson to build the system each day. I was really anxious to see how our system would hold up in the hackystat software ICU.

DUE DATES GOLD CURRENT HEALTH

After setting up everything to send data to the hackystat sensorbase, I was then able to check on the current health of our Due Dates system. I was relatively surprised by the results:

Project View of Due Dates Gold in Hackystat Browser

All the vital signs are green, meaning our code is healthy. Our coverage is in the 90′s and there are no code issues. In addition the complexity, coupling, and churn values are all very reasonable. I was pleased with these results, although there are many areas for health improvement. For one, our system could definitely add some more tests to the test suite. Although our coverage is good, our test case number is fairly low.

As more development goes into the Due Dates project these values are sure to change and there will be more trend history displayed. Hopefully our project will be able to stay in the green. I really think having a software ICU like HackyStat monitor a projects status is extremely valuable. It is a great way to see the overall health and status of a system, thus making it easier to make improvements. Software development on a whole is made more efficient.

Further Exploration in Configuration Management

Tyler — Wed, 08 Oct 2008 10:56:00 +0000

After working on a professor’s project and creating my own stack project (link to past post), I thought it would be interesting to collaborate with another classmate using google project hosting and subversion. Usually when I’ve worked with others in the past, everything is planned out before each person programs or edits code in order to reduce code clashes and redundancy. Configuration management was never a part of these projects and I have to say it was a challenge sometimes.

A good example of this was when I was working on the codeRuler project with Daniel Tian. He and I would send each other source files that often would not match up with each other, creating problems with the program on a whole. It was rather tricky to figure it all out. Even deciding who would create the final build was a bit confusing as we both had slightly different versions. It would have been nice to see how the workflow would have been affected with configuration management tools.

COLLABORATIVE SOFTWARE DEVELOPMENT

For this, I decided to collaborate with Jeho Jung, a fellow classmate also working on his own version of the stack project. After I was added to his project on google project hosting, and he was added to mine, we ventured out to verify each others project. I couldn’t believe what happened next.

Upon check out of his source code, the ant verify process resulted in a ‘BUILD FAILED.’ And if you can imagine, the same thing happened with my code when he ran the verify script on it. I was really, really confused about it all since I swore I had verified it all before hand. However, what I failed to remember was when I slightly edited a test case before check-in. That’s what screwed it up for my stack project. Jeho’s project had a similar problem but his code had errors mainly from missing test cases.

Since we were working on each others code in pair programming style we each went through each project and fixed the problems accordingly. It all went smoothly and either of us were able to update the others project on google code. It’s really cool how it all syncs up. I imported his project into eclipse and updated some of the javadoc comments. Then I checked in the changed files to his project repository and it was all set.

He did the same with my project and after verifying the build, everything was fine. I have to say it was an extremely streamlined process. For one, using CM tools makes working together on a project extremely easy and efficient. We could switch computers and still update the same project simultaneously. The subversion tools built into google project hosting make this super simple. Its great! It is also nice to get automated messages whenever a project you’re apart of is changed (through the use of google groups).

INSIGHTS

Collaborative programming with another student really opened my eyes to the simple problems that can occur when programming by yourself. A big surprise for me was having a program that I thought could build successfully fail when another user was checking it. Who knows what sorts of things I could have missed on my own. It’s really useful to get another programmer to work with so these things are found and fixed.

Collaborative programming also showed me the importance of using configuration management tools like google project hosting and subversion for development. Code review and production was instantly streamlined with the introduction of these tools. If only I had used these tools while creating the codeRuler program with Daniel Tian. Things could have been done much simpler and more efficiently. Configuration management is essential to collaborative programming projects.

If ever I work in a group setting again, I will not hesitate to use subversion and google project hosting. I’m sure my other classmates would agree. Overall, it really seems to me that the use of configuration management tools along with other tools like those for quality assurance, make for more stable builds and more efficient system. I plan to use them all in the future.

Experiences with Configuration Management

Tyler — Tue, 07 Oct 2008 20:38:00 +0000

During my years as a computer science student I have never used configuration management tools, though I’ve known about them. I’ve never used them because they were never required in any of my classes and because frankly, I’ve never had a real use for them. Most of the programs I have written have been small and have been developed solely by me. But when are these configuration management tools essential for maintaining a project?

SUBVERSION

Before diving into subversion, I decided to think about some of the basic instances where using a configuration management program is useful:

When groups of people are working on a single project
When there is a system with multiple versions
When working on a large system
When projects branch of to separate versions

Since I use Mac OS X, I could not use the ‘ultimate’ subversion client, TortoiseSVN available to windows users. What I did was install another good subversion client called SmartSVN. I found it extremely easy to set up, and after making a new directory on my system, I connected directly to the stack-johnson project on google project hosting. I then checked out the version in the online repository to get the most updated version of the program on my local machine. SmartSVN makes everything very simple and pretty intuitive.

the smartSVN interface with the stack-johnson project view

To test out the other subversion commands I corrected some of the test code in TestStack.jav by adding @Test to some of the test methods. This is one of the first things I noticed in the stack source code and it definitely improved the system on a whole by enabling those methods to run in JUnit. After verifying that the project worked fine, I committed my change in TestStack.java and bam, my updated code was a part of the main line project.

That is what I think makes using a configuration management tool like subversion so cool. If many people are all working simultaneously to optimize some system, it makes things go really fast. Within a couple hours there were updated test cases and Javadocs in the stack program and it was much better than it was initially. Tools like subversion are essential for group work. It makes things so much easier. I can also see now how it is essential for versioning purposes. Its like an intelligent central backup, stemming from many sources.

GOOGLE PROJECT HOSTING

In order to get even more experience in using project hosting and subversion I set out to create my own stack project on google hosting. Google always impresses me with their different applications and technology. It seems like they have created everything anyone could ever need on the web (including this blog site!). In addition, everything is done so simply, while maintaining powerful functionality. Google project hosting is no exception to this.

I went in and created my own personal project called stack-tylerwolff. It took about 2 seconds to do the initial set up and I was then ready to check in my program to the web. What was a bit

confusing was adding files to the project. I had to start up SmartSVN, check out the project into a directory (empty project), add files to be version controlled in that directory, and then check-in those files to google project hosting. This took me awhile to figure out but I eventually got it all to work nicely. Once everything is synced up to your local directory, check outs, updates, and commits can be done instantly.

Its really convenient that google project hosting incorporates subversion into their hosting infrastructure. On the project page you are able to view the source file directories as well as a changes list. Google makes it really easy to see everything that goes on with the program from start to finish. What’s neat is that after adding Jeho Jung to the project, he was able to update and better the program from his home computer. It is really a great thing!

Overall, the hardest thing about creating a working project on google project hosting was creating a mailing list through google groups. I spent the bulk of my set up time trying to figure this all out. What I eventually realized was that I had set the group to be private, which meant group members (mainly codesite-noreply@google.com) did not have the proper permissions to post emails to other group members. When I fixed this problem, change messages were sent out to everyone added to the project and it was all good.

Subversion is such a great tool for working together on a project. Checking code in and out can be done instantly and getting updated project files is equally as quick. I can’t imagine how one would work on a group project without it. In addition, google project hosting is so user friendly and easy to use. Creating projects and maintaining them through google is a smart idea. I can see now that the use of both can really optimize software engineering on a whole.

Code Coverage Using Emma

Tyler — Tue, 30 Sep 2008 05:56:00 +0000

Emma is an open-source Java code coverage tool that I recently added to my collection of Java quality assurance tools [Ant, JUnit, CheckStyle, PMD, FindBugs]. What it essentially does is check that every line of code in the source files is run though using class, method, line, and basic block coverage methods. It can be a very handy tool for testing as it makes sure that every line of written code is tested (though there still may be bugs). It is another form of white box testing since it analyzes the internals of the program.

To see how it all worked, I decided to run Emma on the stack system I worked on last week using the other Java tools. Initially, the method, block, and line-level coverage of the system was around 75%. For a small program like this, test coverage of 75% could be fully improved by adding more comprehensive test cases. It was my goal to get the entire program to 100% coverage.

PROCESS & PROBLEMS

I decided to work on this exercise with another classmate Arthur Shum, to get a feel for paired programming. We both worked on our own computers but we went through everything together and resolved problems that arose. It turned out to be a very productive programming session. The installation and set up of Emma was very easy, just like the other Java tools. I was surprised at how nice the Emma html output is. The two classes Stack and ClearStack had color coded coverage markers – Green for covered code and Red for non-covered lines of code. This made it extremely easy to point out what needed to be tested.

To get full coverage I had to go in and make more unit tests for the toString and getTop methods of the Stack object. I also had to make some new unit tests for the getTop method of the ClearStack Object. This turned out to be a rather simple task, but it was great because I got to write some more of my own JUnit tests. I feel a lot more comfortable writing tests with JUnit.

The biggest problem I ran into during this whole process was having my correct code suddenly error in eclipse. This would happen to me almost every time I made a change to one of my test classes. Arthur was having the same sort of problems with his project and eventually he found out that if you rename the containing directory each time, the problem was fixed. It was really a pain though. I just recently found out this was happening because I was running Ant (from a terminal window) and Eclipse simultaneously. Both were compiling the class files into the same directory and this was confusing the system.

Eventually got 100% coverage in the stack project. Arthur did the same and it was all done rather quickly. Stack project with 100% code coverage: stack-tylerwolff-6.0.929.zip

One interesting thing I observed during this exercise was a line of code that produced a yellow coverage marker in the results. I noticed this happening in Arthur’s code for his Stack class and it took us awhile to figure it out. After analyzing my test cases for that class we realized that he was not checking both cases for the if statement. To get full coverage, we needed to test all boolean cases, both true and false. This, I thought, is a pretty smart function.

However, I can see where getting 100% code coverage does not equal a fully tested, bug free program. Emma really only checks that all lines are tested. What would happen if some important factors were left out in an if statement? Or what if the system utilized a function that deleted something when it was supposed to only view it? All this would still get 100% code coverage if there were basic unit tests, yet it would still be buggy. I realize that it is not enough to rely on code coverage tools like Emma. Still, I think it is definitely a worthwhile tool to use on projects. It works quickly, efficiently and can improve the robustness of your code.

Bug Problems with 100% Code Coverage

Tyler — Tue, 30 Sep 2008 05:41:00 +0000

Test coverage has many limitations in the programming world. When I first heard of tools like Emma I really thought using them would make my programs totally robust and bug-less. However after reading articles like this, and working on getting 100% code coverage with my Stack project, I am starting to think otherwise. Would it be possible to introduce a full fledged bug into code that gets full code coverage?

INTRODUCING A BUG

My programming partner Daniel Arakaki and I decided to create a version of our previous stack system that would have 100% coverage in Emma using the existing unit tests, as well as a significant bug that could ruin the system if it were ever put into real use. After contemplating it for awhile, we came up with a plan to introduce a bug by changing a basic function call in the getTop() function of the ClearStack class.

by simply changing this method:

  public Object getTop() throws EmptyStackException {  return this.top();}

to:

  public Object getTop() throws EmptyStackException {   return this.pop(); }

we effectively introduced a bug into the system that would (using our current test cases) get 100% code coverage using Emma. We ran it through JUnit and Emma and sure enough it all worked fine. Final stack system with introduced bug: Download.

Imagine if this stack system was put into any sort of real use. There would be EmptyStackExceptions all over the place and if you ever did want to see what object was at the top of the stack, you would effectively screw up the stack structure. Any calls to pop after that would return a different object than expected.

The funny thing about it is that all this could potentially happen just because of one wrong letter in the method (p instead of t). To put it in perspective, imagine if this bugged stack system was implemented on a vending machine. If there was a button to check item availability and a user pressed it, they would get a free item. In the long run the numbers wouldn’t add up for the company supplying the vending machine and money would be lost. If a programmer bases all their tests on code coverage results, their code will be flawed.

CONCLUSION

I think code coverage tools like Emma are very useful for programming. Code testing and optimization becomes more efficient, and it can at least help one to test their code better. The thing is, you cannot rely on them for all your testing needs. It was very easy to introduce a significant bug into the stack system and still get full coverage. It was only when I added another test case that checked for multiple getTop() calls that the problem was found. I, for one would not have though about this potentially being a problem in the original stack program. I guess it comes down to how thorough you want to test your code, and this cannot be fully based on code coverage. It is only a tool to help you with it.

In addition, another downfall of code coverage tools like Emma is that they cannot account for lines of code that should have been written, which means code that has 100% coverage could still have bugs. Overall though, I still think code coverage tools should be used to help in testing. They are quick and efficient and can really improve testing. I will definitely will use Emma as I write tests to my programs knowing all of this.

Using Ant/QA Tools to Build a Robust Program Package

Tyler — Wed, 24 Sep 2008 07:11:00 +0000

As programmers there are many tools out there that streamline the writing process and optimize code. Some tools create all in one programming environments to work in (IDE’s), some tools help you to build projects, and others do all sort of cool things that clean-up and optimize code. Previous to taking ICS413 I was never exposed to these technologies (apart from IDE’s). I never knew the power these sorts of things hold in a programming environment.

TASK 1

The main goals of this exercise were to 1) become familiar with the ANT build system, 2) become familiar with Open Source Java automated quality assurance tools, and 3) learn more about the build system and packaging standards for our ICS413 class. The first task was to simply download and install the specified Java tools on our system:

Checkstyle 5 Beta - checks source code mainly for layout issues based on a coding standard.
PMD 4.2.3 – Checks source code for things like bugs, dead code, overcomplicated expressions, etc.
JUnit 4.5 – A framework for writing and running automated tests.
FindBugs 1.3.5 – Uses static analysis of byte code to look for possible bugs.
Ant 1.7.1 – A Java based build tool. ‘Make, but without Makes wrinkles’

In addition we were to download the source stack package to test these tools on. It turns out that this task was one of the more challenging parts of the assignment. After I downloaded each tool, I had to go and edit some environment variables on my machine so they would point to the respective tool. Since I use a mac I had to edit my .profile file to add some environment variables like this:

export ANT_HOME="/Users/tylerwolff/Documents/ICS/Tools/apache-ant-1.7.1"export CHECKSTYLE_HOME="/Users/tylerwolff/Documents/ICS/Tools/checkstyle-5.0-be$export FINDBUGS_HOME="/Users/tylerwolff/Documents/ICS/Tools/findbugs-1.3.5"export JUNIT_HOME="/Users/tylerwolff/Documents/ICS/Tools/junit4.5"export PMD_HOME="/Users/tylerwolff/Documents/ICS/Tools/pmd-4.2.3"

Luckily a friend in class helped me get to this point. Otherwise I would have been at a loss at what to do. I also needed to change the path to ANT 1.7.1. After I finally managed to finish this all, I ran some tests to see if I had installed everything correctly and it worked just right.

TASK 2

The default stack project was already set up with all the xml files needed for the ANT build system. All I had to do was go in and rename some of the variables to add my name to the project . The most complicated thing I had to do in copying the project was to go into the verify.build.xml file to remove the statements referring to the ‘emma’ tool which is not in use yet. I found the ANT xml files to be extremely easy to understand and decode. Its almost like an upgraded MAKE system. I guess thats why they themselves call it ‘Make, but without Make’s wrinkles.’

TASK 3

After copying the project, I worked on and finished fixing the problems associated with it during class, with the help of Daniel Arakaki. We used each tool, found the bugs or errors associated with the project, and continued on to fix the problems within the source code. All in all, I have to say it was a very streamlined process using the QA tools. They run instantaneously to produce a very readable page of errors. Although I was not surprised to see errors arise after invoking each tool, I was surprised at how easy it was to understand what the errors actually were. Many of the tools, like PMD and FindBugs even go a step further by linking the errors to full descriptions with examples. This made it really easy to fix some of the errors. For instance in the Stack.java file PMD suggested that instead of using implementation types like ArrayList, use an interface. I was a bit confused by this at first so I clicked the error link and it gave me a concrete example of what they mean and how to implement it. It’s a great system!

The rest of the errors were checked and now the project verifies perfectly.

Finalized stack system: stack-tylerwolff-6.0.923.zip

Overall I feel comfortable using these programming tools now. I don’t think I will program anything from now on without them. ANT especially makes it really easy to compile and build entire systems. I like how you can use it to invoke quality assurance tools as well. Its so easy to go through and use these automated tools to better your program. I really think its a good thing to do. I love that fact that you can even learn from using these tools as they show you new errors and changes to make to them.

Thoughts on Automated vs. Manual Quality Assurance

Tyler — Wed, 24 Sep 2008 03:22:00 +0000

When programming it is always hard to get the code looking and working right the first time around. More often than not, we miss the littlest, most minute details in our program code and it fails because of it. Those are the times when it is ultimately useful to get an objective, outside view of your code.

In addition to having another programmer look and check for errors in your code, there are many automated tools that scan your code for possible errors. Some of these tools like Checkstyle and PMD scan your source code for things like formatting and code efficiency errors. Other tools like FindBugs scan actual byte code for bugs. Using these sort of tools can make your code optimal and up to standard. But how do they compare to actual human quality assurance checks?

I ran Checkstyle, PMD, and FindBugs on my CodeRuler solution to see what sort of errors were found, and compared these results to what two of my other classmates found in my code. Here’s what the automated tools found:

Checkstyle : 24 errors in MyRuler.java (67 errors total including IBM classes)

20 errors due to lines over 100 characters long
3 Javadoc errors
1 error due to using a import wildcard statement ‘*’

PMD: 10 errors in MyRuler.java (36 errors total including IBM classes)

All priority 3 errors with code suggestions

FindBugs: 0 errors in MyRuler.java

As this was my first time using these automated tools I was surprised at how easy and simple they are to use. Instantaneously errors are found and presented in an extremely efficient way. Checkstyle proved to find many formatting errors and described them all well. With PMD I was surprised to find that they not only show the errors but links to full descriptions with examples. How great is that! FindBugs found no errors but I’m sure if the code was more substantial and complicated it would have.

CONCLUSION

Compared to Manual QA checks, I think the automated tools did an amazing job (at least with my CodeRuler classes). When Arthur Shum and Aric West did a check on my code they found many of the same problems – wildcard import statement, long lines of code, javadoc problems, etc. However, what they were able to find were more complex formatting problems such as redundant inline-comments, confusing code segments, and bracket placement. A lot of these problems would essentially make the code even more readable and Checkstyle did not find them. I think a Manual QA check is essential if your code needs to adhere to very specific standards.

PMD found some errors that I think would take another programmer awhile to point out, especially with long code. It is possible that a programmer could find all these same errors. However, PMD finds them instantly and presents them so well. I actually learned a thing or two from looking at the errors in my code. The errors gave great suggestions into making the code more efficient and readable.

Overall, what I think makes Automated QA so great is that is instant. These tools can be acquired and used in a matter of minutes. What’s more is that using them can even teach you new tricks. If there are still problems in your code, such as logical errors, then manual checks can be done. From what I’ve seen by doing this, using a combination of both automated and manual quality assurance checks can make your code optimum.

Code Ruler Peer Review [Flestado]

Tyler — Mon, 15 Sep 2008 07:08:00 +0000

When I first opened the MyRuler.java file from Mari-Lee Flestado I did a quick scan over all the code to get an overall impression of it. At first glance I found the code to be clear and organized. I saw lots of clear, logical statements and many single line comments. It took slightly longer to realize the strategy the code implemented but overall I had a really easy time understanding the specifics of the program. Her ruler worked very well for what it was when I tested it out. It implemented exactly what her strategy specifics outlined. When I first started coding out my codeRuler I thought of some of the same strategies she used like creating more knights and peasants when the opposer has more.

The javadocs throughout the code were there but weren’t too specific. The single method added had a simple overall description that outlined what the code basically did, although it was not formatted correctly.

The overall structure of the class was done quite well. If I were to code something out like this I would hope to have it organized in this same manner. Its clear, concise, and easy to read. The logic of it all was simple and the strategies implemented were clearly done.

After scouring the code for any sort of violations I found a few that were not up to the standards outlined in The Elements of Java Style (many violations occurring in the example IBM code borrowed). Here is a table of my findings.

CODE/FORMATTING VIOLATIONS FOUND

File	Lines	Violation	Comments
MyRuler.java	44, 53, 57, *	EJS-7	no whitespace included in line between () and {
MyRuler.java	38, 79, 87, *	EJS-7	no blank line between logical sections of code
MyRuler.java	1,2,3, *	EJS-8	Tabs used, not converted to whitespace
MyRuler.java	109	EJS-9	‘np’ is not a meaningful name
MyRuler.java	38, 43, 52, *	EJS-37	comments repeat code, does not add useful information
MyRuler.java	105, 110, 120, *	EJS-76	Expression statements used instead of block statements
MyRuler.java	20, 98	ICS-SE-Java-6	Does not start with a capital and end with period. Should be a more complete sentence.

Overall, I found Mari-Lee’s code to be very clean and easy to read. With a little bit of time editing, her code will be looking top-notch and up to standards.