Due Dates 2.0 (the Web Application!) is born

Developing the Due Dates 2.0 web application was an experience that really summed up everything I have learned about software engineering in the last 5 months. I worked alongside Aric West and Mari-Lee Flestado, as team UlaUla (red) in creating this application. In developing Due Dates 2.0 I used all the tools available to me including quality assurance tools, JUnit, configuration management, continuous integration, software ICU statistics, Google Project Hosting, Wicket, and of course Java. Creating the system was to say the least a very rewarding challenge. I think our overall project turned out nicely. DueDates-ulaula Homepage.

screenshot of the login page

NEW FEATURES OF DUE DATES 2.0

The main new feature of Due Dates version 2.o is that is a legit web application, created through Wicket. The other features include a login in page that verifies users from an XML file, a result page that dynamically updates, sorts, and filters your borrowed items, and an alerts page that can schedule email notifications when items are due soon. Its a pretty cool system that is also makes use of CSS, so it looks good to the user. Our group was able to implement all of these features into the system. However, we did not add any extra functionalities to the application.

TEAM DEVELOPMENT

I really enjoyed being a part of a three-person development team. I found that overall, more was getting done with three people always working, rather than just one or two. In the past I've gone weeks without having to do an svn update, but with this project I was constantly updating and committing code. I liked the fact that whenever I went to work on Due Dates, there was usually some new code for me to check out. It was a much more efficient system working together than I've experienced in the past.

Communication was a big plus for our team. We all met a few times a week to do some planning, reporting, and programming. Right off the bat we decided what everyone on the team was going to more or less do, and we got on it. We delegated tasks to everyone through Google project hosting's issue manager. To see what tasks I worked on, view my issue log. One of the main things I enjoyed about working on Due Dates 2.0 was the fact that there were a bunch of different and unique things to do. I personally was excited to work on the CSS styles for the web app, as well as creating the XML configuration manager, since we've never done that sort of thing before. Everyone was able to bring their own skills together for this project and it worked nicely.

When we weren't meeting in person, we were meeting online, talking via instant messages. I did this a lot with the other team members and it worked really well for throwing bugged code back and forth. However, meeting in person was definitely needed for a project like this and it really helped our overall system develop. I remember on the first day we met as a team, Aric had a great idea of planning out exactly what general classes and methods we were going to have so we could all work on things even if something the code relied on was not implemented yet. This worked well when creating the Wicket classes for instance.

DEVELOPMENT PROCESS

If I could sum up the development process of Due Dates in one word I would say it was 'smooth.' For most of the time spent on development, I did not feel stressed at all. This was partly because I was working regularly, as were my teammates. Since we were committing often, we did not have much that was left to do last minute. 

DEVELOPMENT PROBLEMS

The most frustrating and challenging problem I had during the entire development process happened the night before Due Dates 2.0 was set to be finished. I had been working on the overall test suite for the system and I got stuck on testing the ResultPage class which displays a users borrowed items to screen. In testing the class, I was simply trying to update the page with some borrowed items that the test user had. It is a simple test to run manually through the web interface, and it works every time no matter what. However, when running it in a test case, it would never work. The dataview was never created. I consulted my teammates about this, as well as other students and nobody could figure it out. I spent most of my night trying to debug this simple test and wasn't able to figure it out. However, in trying to fix it, I came upon several other possible bugs in the system.

I attribute most of the churn on the last night to this bug, as I re-coded a lot of things in hope that it would fix.

Other than this bug, I didn't run into a lot of problems over the last two weeks. Our group process ran smoothly and we only had minor problems which were fixed quickly. The only thing worth mentioning was the first time I got an update conflict on SVN. This was my first time dealing with a conflict and it really confused me. I didn't know what was what, but eventually I figured it out and it was no problem after that.

SOFTWARE ICU STATISTICS

The overall status of our project reflects in our HackyStat statistics, which are nearly all in the green:

Our development time as a group was consistent, and our commits, builds, and tests were also consistent. Our coverage trend was always going up and we ended with 96% method coverage. The only thing that got messed up was the churn, which was great until the last night (when I was trying to figure out the test bug). However, the overall churn trend is more or less consistently low.

Our development trends were somewhat accurate in representing each members participation.

development time graph

As it shows here, I have the least amount of development time of everyone in the group and Mari has the most. Aric is right in the middle. Everyone seems to have worked nearly every day during this project which is good. What is flawed in this graph is the time spent out of eclipse. This includes working on wikis and for me especially, working in dreamweaver. In addition, when looking at other trends the data seems to change: 

commit data

Here it shows that I have the most commits while Mari has the least. Aric's right there in the middle again. This is true of system builds as well:

build data

Surprisingly though, Aric and Mari ended up with the exact same amount of builds. I thought that was pretty cool.

It was good having the Software ICU monitoring our group process and system health. I can see a real change in how I work on stuff now compared to 5 months ago. I like to work regularly instead of working just a day here and a day there. 

FINAL THOUGHTS

As a software developer I would like to continue creating things in the same way I have with Due Dates 2.0. All the software engineering tools available really aid in creating robust systems. If only I had known about SVN or JUnit before, my code would have been better. Overall, I think creating this web application shows how I have grown as a software engineer. I would not have been able to do such a thing before. Although there are many, many things that can be improved on our version 2.0, I think it turned out quite well for the time we had. I hope to add to it one day.

My first Wicket Web Application

There are many frameworks available today for creating dynamic web applications, some of which are extremely complicated and hard to use. Wicket is one of the few, easy to use tools out there that works well with Java programming. What makes Wicket different from most other web application tools is that it effectively separates the logic of the actual program from the simple HTML markup of a web page.

This week I set out to learn how to use Wicket in order to create a small web application for a simple stack Java program. With this program, a user can push items onto a stack, pop items from a stack, as well as clear the entire stack. Although the functionality of the program was quite simple, creating a web application for it did turn out to be more of a challenge.

Final Distribution Package for the Web App: stack-wicket-wolfft-1.0.1123.zip

final view of the stack web application

THE DEVELOPMENT PROCESS:

After reading some of the chapters of Wicket in Action as well as reviewing some actual examples provided by Dr. Johnson,  I started to grasp some of the basic principles of using Wicket. To my surprise creating an HTML page to interface a Java program is an extremely easy and clean process. Since there is no logic in the markup, the HTML page is left as simple as possible, and can be stylized and viewed all on its own.

On the other hand, creating a Java application that works with this HTML page is a bit more complicated. I wanted to create a stack application that would employ the use of forms, basic text output, as well as table output. In addition, I wanted to give each user of the application their own session in order to store their personal stack object and data. Luckily with Wicket, this task was not too daunting either. 

To do it all, I had to create an application class, then a page class, and then finally a sessions class. All of these components essentially run together to create the stack web application. Creating the page class was probably the most challenging out of all the classes since all sorts of different HTML elements were being updated on the one page at once. 

Another thing worth mentioning is the applications use of Jetty, a web server implementation that enables Java applications to run on a server. This was used to create a fully-working web application, though I more or less just reused code to get it to run.

DEVELOPMENT PROBLEMS:

I had a good time creating this stack application. I get real satisfaction from creating something that anyone can go out and use without having to run through a console. However, I did run into some small problems while developing it all. For one I had to figure out how to alert the user when they were trying to pop an empty stack. I fixed this by creating an error response text field in the page that would alert the user if they were popping an empty stack. Something else I could have done with this was only make the pop button visible when there were items in the stack.

Something else that I ran into was that initially the stack was presented in the table in list form, not stack form. This means the first item pushed was always the top item in the table. The way I like to thing of stack is the opposite of this and I wanted to make that clear on the page. I ended up creating a method in the Stack class that would put the stack in the right visual order right before updating the data to to table. It worked out quite nicely.

Also, one of the funny errors I kept getting was from CheckStyle on the basic Stack package classes. It simply stated:

Got an exception - java.lang.RuntimeException: Unable to get class information for @throws tag 'EmptyStackException'.

This was extremely confusing because I did not even alter the classes that the error was from. I was really stumped with this one and searched all over to try and figure it out. The problem ended up stemming from the build.xml file, which was not compiling all the classes, namely the EmptyStackException class. It was something small that I missed and when it was fixed it all worked nicely together.

LESSONS LEARNED

Creating this simple web app was more challenging than I initially anticipated. I spent a lot of time looking at the Wicket examples, trying to figure out the best way to create the application page, and still it wasn't working for me. Yet, now that it is all done, I feel I have a fairly good understanding of the Wicket framework. All the work spent on figuring out different ways to do things resulted in more knowledge of how things work. I do feel comfortable with Wicket and I know I will be using it in the future to create even more extensive web applications.

ICS Industry Day at UH Manoa

Today was the ICS Industry day at UH Manoa, an event I've been waiting to go to for awhile now. High tech companies from all over Hawaii come in and do presentations on what their company does, while showing some of the real life jobs that are available to a newly graduated student. Since I am a senior computer science student, I was extremely interested in seeing these presentations. I was also interested into seeing what sort of internships are available currently. Sadly though, I was not able to stay the entire time due to a 12:00 class I had (which I left early in order to get back to the presentations). 

All in all I was able to see the following presentations:

• Oceanit - A company based on Oahu, Kauai, and Maui that works on a wide range of 'innovative' projects for the government. They do a lot of Research and Development work.
• Alion Science - A larger company that also does a wide range of things, including software modeling for the military. 
• Concentris Systems - A company whose primary focus is on developing technology for the military. They developed the 'Indestructible Instant Network' system.

I have to say that I was really impressed by all the presentations. Growing up in Hawaii but traveling around the world, I never really saw Hawaii as an innovative place with high standards. However these companies are doing really innovative things! And in Hawaii nonetheless! It was really cool for me to see this.

OCEANIT

The Software Manager of Oceanit, Scott Libert, was an extremely friendly fellow. Even before the presentations had begun he had introduced himself and was telling me about what they do at the company, as well as what types of internships they have, etc. I learned that Oceanit likes to be on, as Scott put it, 'the bleeding edge,' constantly pushing the limits of technology. They've done some really cool stuff there, like use nano technology to make building structures more robust, as well as create technology that can check and see if people are in a building before entering (for military usage). It's really cool stuff to say the least. 

After Scott did his presentation, I went and had a talk with him about their internship they have for the summer. He was really nice about everything and gave me a bunch of information on what the interns do, as well as how to go about getting the internship. What's nice about their internship is its project based, so at the start you are given some project which you complete over the course of the internship. A recent intern just developed an iPhone application for the company. 

ALION SCIENCE

This was a pretty fun presentation put on by two guys who work for the company in Hawaii. They basically work on making simulations for the military, sort of like video games. What was great about their presentation was that they presented some of the facts about working as a software developer in the real world. I believe one of them stated that "you spend 80% of your time looking at other people's code or old code, rather than creating your own." He was making a point about how having good documentation is essential. They also mentioned a lot of the things we use in ICS413 like SVN, Continuous Integration, and JUnit. It felt pretty good to know all about those things and they stressed how important these technologies are to any project.

CONCENTRIS SYSTEMS

After initially leaving the presentations and going to my math class, I found myself extremely uninterested in what was going on, so I decided to pack up and go see some more presentations. I really wanted to see the Ikayzo (makers of techhui.com) presentation but I was too late. What I did get to see though was the presentation by Concentris Systems, which develops wireless technology primarily for the military. The presenter seemed really informed on just about everything and it was nice to actually see some of their physical technology there (he brought in a portable network module).

Concentris does some really cool stuff with their Indestructible Instant Network devices. What this basically does is set up network nodes on these little portable modules, which then all connect automatically in the most efficient way possible, thus enabling solid communication. What makes it indestructible is the fact that if one node goes down, the network is still in tact and running. Very cool stuff. They've developed all sorts of things that can use this technology, like land mine robots, or submarine docking communication. I was really surprised to see their plans for the future which were really large. For instance, with their network nodes, they are creating a user interface that links up to google earth and displays exactly where each node is on a map. This is integral for military units.

FINAL THOUGHTS

Overall I realized that there are in fact some really great technology companies in Hawaii that I could definitely see myself working at in the future. I've always planned on doing the big mainland move to get work elsewhere. However, there is a lot of stuff going on here now. Its really great for Hawaii. It's also good to see that these companies are still hiring workers all the time in light of the current state of the economy. I would recommend all ICS students go to presentations like this.

The Release of Due Dates Version 1.2 [team gold]

This week marks the release of Due Dates version 1.2 [Project Homepage]. With this new version comes two new features: an email reporting service, as well as a timer-based reporting function that allows the user to automatically have the program run at some specified interval of time. Both functions have been integrated into the Team Gold release of Due Dates and everything functions well.

This release also builds upon many fundamental changes to the source code. Classes have been stripped down and simplified. More checks have been added to ensure program robustness and a more exhaustive test suite has been created with well over 90% coverage. Due Dates v1.2 is definitely an upgrade from Due Dates v1.1.

GROUP PROCESS

This weeks development process was much the same as it has been the past few weeks. Although I had time to meet up, Scheller was really busy and so we were only able to meet up a couple times. Otherwise, we communicated via email, IM, or phone. Initially, we talked over program design and test design. We set up a bunch of issues that we thought would be the most useful in modifying the system. This was all good.

However, I found that Scheller and I have two different development styles. I like to get started on things early and he does stuff later. This can be attributed to Schellers heavy workload, but it really is hard to collaborate efficiently like this. Most of the time I felt like I was working alone on the project. I would just keep him updated with what was going on. Scheller did create some good code for the project though. He implemented the self-timer for running Due Dates on a schedule. 

Overall, the development of Due Dates v1.2 could have been better if Scheller and I had worked similarly on the project. Although the state of project meets my initially expectations for the program, things could have been done more efficiently. I would still like to meet up more in person, or at least communicate more on all things relating to the program. Hopefully on the next version of Due Dates, this can happen.

DEVELOPMENT

Development for Due Dates v1.2 went really great for me this week. I attribute this solely to starting early. I did not have to rush on anything the entire week, and I was able to really think out my ideas for the system. I felt like I was ahead most of the time which is not a usual thing for me. I hope to keep up this sort of development style with future developments of Due Dates.

DEVELOPMENT PROBLEMS 

The biggest problem we had in the development of this release was trying to get the DueDates.jar file to run correctly. The reason it was so challenging was because the program now uses JavaMail, and referencing these libraries is quite different than most libraries. They must be put directly in the system frameworks rather than referenced in the build classpath. It was especially confusing for me since my computer runs on soylatte 1.6 for its Java JRE, not the usual Java release.

Initially I had a lot of help from other students like Arthur Shum and Ronn Reeves. At one point, Arthur and I did a screen sharing thing through a messenger program called iChat, which allows him to control my computer. That was cool but it did not solve anything. We were copying the mail.jar file to the lib/ext of my Java framework, the right thing to do. However, it was still not working. 

Eventually I realized the only difference between my computer and Arthur's computer was that I was using soylatte. Thus it had to be a problem with that. Then it dawned on me (with the help of Arthur and Ronn). Instead of having the mail.java file in the system framework directory, I needed to put it in the soylatte directory on my system. This simple change fixed it all and the jar file ran fine after that. I was really stumped by this whole problem. I'm really glad it was eventually sorted out.

CONTINUOUS INTEGRATION AND SOFTWARE ICU

The development of Due Dates v1.2 was monitored by HackyStat, a software ICU program reviewed in my last blog post, In the Green With HackyStat. Essentially what this does is monitor all the vital signs of your program as well as monitor the development process. Due Dates had sensors sending data to HackyStat throughout the last week and it was great to visit the project page and see the results of this. It was nice to see current values and trends having to do with things like complexity, coupling, coverage, tests, development time, etc. I usually checked it a few times a day, just to see. I am happy to say Due Dates v1.2 is still all green.

What was cool about all this was that the Hudson continuous integration server ran a daily build that would send sensors back to the HackyStat sensorbase. This meant there was an automated build each day just for the software ICU. It was great to have the Hudson server do this.

FUTURE DUE DATES IDEAS

With Due Dates v1.2 there were a lot of improvements in functionality and there were many improvements in the source code. I am very satisfied with how it turned out. Yet, I know this program can be made even better! Something that will definitely be done in the next version of Due Dates is to create an online application for users to use. This will make it ten-fold easier for the average person to go and use Due Dates. We will be using Wicket to do this. It should turn out really good.

In the GREEN with HackyStat!

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.

The Release of Due Dates Version 1.1 [team gold]

For the last week and a half, my partner Scheller Sanchez and I have been working on Due Dates Version 1.1. This new version has many new features compared to the last one, including support for the Hawaii State Library, a sort option, as well as a within option. All in all what ended up happening to our original code was a lot of redesign, a lot of review, and then even more redesign. Visit the project homepage to check out how it turned out.

VERSION 1.1 DESIGN

A lot has changed in the design department of our Due Dates implementation. Some of the things we initially made for future extension, like the LibraryVault class, we found were obsolete for this version because they were not abstract enough. For this very reason, I redesigned the overall structure a lot, first by putting all the methods for every library in the LibraryVault class, and then by making the LibraryVault class an interface for each separate library to implement from. This, I think turned out to be quite efficient as one can now add libraries easily based on the interface.

Another big change in version 1.1 was the creation of the ItemDue object that holds information about a borrowed item. Using this object, we were able to create an overall List of all the items that were due, allowing the program to sort through them, as well as perform other functions on them.

Also, Due Dates version 1.1 uses the open source ArgParser libraries to parse the command line arguments. These libraries are super useful in specifying command line options and ranges of certain arguments. Using the argparser definitely added to the robustness of the overall system, and it will allow for future additions to the program as well.

TIME CONSTRAINTS WITH VERSION 1.1

Since the release of Due Dates 1.0, I have been loaded with huge amounts of school work. In the last week and a half I not only had two midterms, but two large midterm projects due, not including Due Dates. For me, this was the main thing that slowed progress down on developing the system. I really spent all my extra school time working on Due Dates and it still was not enough.

What I had to do to really get things done was reserve certain days for working on Due Dates, and just work extra hard on it during these times. Although it was not the best system for doing things, it worked out. It was also nice that the system was reviewed twice in this time, helping me to narrow down what the most important things were to do.

COMMUNICATION PROBLEMS AND GROUP PROCESS

Another thing that changed since the last release of Due Dates was communication between our group. It turned out to be much, much harder to meet up in person this week since Scheller and I both had huge amounts of other work to do. By last week wednesday, the original date for the release of the system, he was still unable to help out on Due Dates because he was stuck working on another project. It was hard to collaborate on things because of this.

When we met in person a few times we went over some issues to do as well as some design problems we had to solve. This was good, but it was far from planning everything out. At some point last week I realized I had to just start trying out my new design ideas for Due Dates version 1.1. This was not efficient since I was the only one doing things, and because of this I had to redesign the program a few times over. Things didn't run as smoothly as they did with the release of version 1.0.

Sometimes it took awhile to contact Scheller, but eventually I would get some sort of answer. Luckily we could communicate via instant messages, and luckily we were using configuration management software. It could have been worse. The truth is this version of Due Dates probably could have been better if we had worked more together on it. We did our best for the time period, and I tried my best to release the program up to specifications. I hope for the next release of the program I will be able to meet up with my group a lot more in person. That seems to be the best route for creating collaborative software.

WORKING WITH THE HUDSON SERVER (Continuous Integration)

For the development of version 1.1 we had access to the 'Hudson' server, which is used for the continuous integration of our system. This was, to say the least, really, really, really useful. I could not believe how many times a build would fail on there when I was positive I just checked it on my home machine. On one occasion, I would fix some problems that were found and that would cause even more problems (this had to do with declaring 'private final static' variables and the order of those words). I would commit thinking that everything was a-okay, but the build would fail and hudson let me know each time. Having a back up check using continuous integration is essential.

On the other hand, it was a bit much to always have the system build on Hudson. On many occasions I wanted to commit my code to the server for my partner to look over but the code did not pass verify due to QA errors that popped up. I would always end up spending a long time fixing these errors, when all I wanted to do was commit the code I had so far to show my partner, regardless of the errors. For a while I ended up committing code that would fail the build because of this. That's why we probably still have 'cloudy skies' on hudson.

FINAL THOUGHTS

Overall, working on Due Dates version 1.1 was a lot more of a challenge compared to version 1.0. There were a lot of factors that caused this (time constraints, group process, etc), but I still believe the final outcome turned out great. The program runs nicely now and has all the functionality needed. It is now very extendable too! Developing the next version of the system will be interesting.

Some of the other teams also did great implementations of Due Dates for version 1.1. One worth checking out is Due Dates (Team Silver). I did a review on their system and it is just really awesome. Watch out for the next version of Due Dates coming soon...

Software Review Part Deux

After much time was spent re-working and changing the Due Dates [Team Gold] system to include new standards, Scheller and I were assigned to do a software review on Team Silver's Due Dates program, as well as have our system reviewed by Team Orange. This turned out to be a real eye opening experience for me, as I saw what other groups were capable of and what could be improved on our teams implementation. Since last weeks software review, I didn't really know what to expect since I was reviewing a new groups system.

REVIEW TEAM SILVER

Ronn Reeves and Robin Raqueno were the developers of this Due Dates system and it really was a pleasure reviewing their system. My first impression after viewing just their homepage was WOW. 

I mean look at that page! Compared to what I saw last week in other projects and what my own project homepage looks like, I was blown away. This project was definitely portrayed in an informative and professional way. I loved this. But how did the actual code fair?

After downloading their source code and checking it all out, I was not surprised to see top notch code. Their package structure was organized nicely, as was their class structure. Everything functioned correctly and was done really well. I found their system could really be extended by anyone, even the user. This was because libraries were added through an xml file where the data for each library was held, and this could be updated. I was very impressed by this function. It really was a task to find anything serious to comment on in their code, but I found a few things here and there worth noting.

What was interesting was to see how this team implemented ArgParser, and open source command line parser, since we had also implemented that in our system. Not only did they implement the parser to work for correct arguments like -uhm 12345567 wolff, they made it work for arguments without the library declaration, something more like 12345567 wolff. This was a pretty cool thing I thought, since it would minimize user errors when adding command line arguments.

Overall, doing this review was really nice. It was intriguing to see how a top notch team implemented their system. I think I was able to help as well, if not with their actual code, but with their user/developer guides which were missing a few important things (Their results). In addition to all of this, I got some new ideas for our system.

TEAM ORANGE'S REVIEW ON OUR PROJECT

A review on our Due Dates system was really needed and luckily we had an excellent review team do it - Team Orange, Daniel Tian and Aric West. Our initial review page outlined everything we wanted to have reviewed and they responded to basically everything we asked for and more. I was expecting comments on our class structure, testing and a few other areas, but they found some things I would have never found on my own that were of equal importance. After refactoring our system to have the DueDates name instead of the DueDatesGold name, I forgot that this screwed up jar creation and basic building capabilities. They caught this. There were also some really great comments on the code itself. They gave some great suggestions on some general design issues that needed to be addressed.

I think it is so important to have others try to build and run your system, especially when your dealing with an Open Source Software development project. Many things like jar creation work perfectly on our computers where we've developed everything, but once someone else tries to do these things on another machine, there are errors. Having a review done like this is great for pointing out these errors.

GOOGLE PROJECT HOSTING REVIEW

Doing this review was fairly similar to doing it the last time. Adding comments to peoples code was easily done and check-out was easy. However, I found it much easier to read the comments on our system, as they are all logged on one overall page. Something funny that did happen though was when Daniel Tian did his review and half of his comments appeared on r39, while the others appeared on r40. We couldn't figure it out.

A function I would love google to implement is something that sends you the info about your review that you've done. I have no way of accessing the review I did on Team Silver's system. The only way would be to get a link from them. It could be made easier if that were automated, or if there was a dedicated page for it all.

Overall, this software review was a great experience for me. I sort of got inspired from looking at Team Silvers code, and Team Orange really gave our group some good ideas for improving our system.

Time For Review! Software Review that is...

After working with Scheller Sanchez on the first release of Due Dates, I was ready to take the next step in expanding and enhancing the overall system. Since it is still in the first version, Due Dates is far from being a perfect system. There are many things to improve on and a lot of things to extend the program to. Many times, an efficient way of evaluating everything is by performing a series of reviews on the program, pointing out what does not meet requirements and what design features could be improved.

Doing Reviews

I participated in three reviews - one for duedates-blue, one for duedates-orange, and one for duedates-green. I found this to be a really insightful experience. As Scheller and I designed the structure for duedates-gold, we often wondered how other teams were laying out their system. I personally really wanted to see how far other teams were taking it. By doing these reviews, I got to see just that.

It was really interesting to see how teams structured their systems. To see certain functions - like the program menu function in duedates-blue - actually implemented was extremely useful. I personally had been thinking about implementing that sort of function on our version of Due Dates. Now, I can better judge the use of a program menu in our version. Another thing that intrigued me was seeing how different groups did different things. For instance, one of the groups I reviewed had large amounts of code for parsing the command-line input. Another group had a relatively small amount of code for this, yet surprisingly they did basically the same thing.

For some of the teams I reviewed, it was easier to pick things out to comment on, and for some teams it was a bit harder. Nevertheless, I found some overall problems I'm sure others had found as well. One of these things was Exception handling. Every project I reviewed just showed a stack dump upon exception. This is not good.

Receiving Reviews

The Due Dates - Gold system was reviewed by:

• erinjuneilkim
• creightonokada
• aricwest
• jnancheta
• anthony.m.du
• john.km.zhou

What was cool about all this was that even though Scheller and I specified specific things for each member to look at on our Review.wiki page (documentation, testing, class structure, etc), most of them went out of their way to inspect some of the other code as well. We got a lot of great feedback, good and bad, about our program design and how are program fairs in general. I was surprised to see comments about things I would have totally missed on my own. A good example of this is the command line program requirements. Scheller and I both forgot to integrate the -uhm command in our program but luckily Aric West commented about it.

I am usually really strict about how I program things. However, I do let things slide from time to time and I forget about them. It really is great to get an outsiders perspective on the internals of the program. Having these reviews done on our program can only improve what the future system will become.

Problems with Google Project Hosting's Review Tool

I couldn't believe how many problems I ran into using Google's built in review tool. As a reviewer, my main problem was publishing my so-called 'draft comments.' Half the time there was not a 'publish your comments' link on the page and I was left stuck, wondering what to do. On the first review I did, this occurred and I navigated back a few pages to see what would happen. Somehow by doing this I lost all my draft comments and I had to re-do them. After that instance, when there was no publish link, I realized the only way to fix it was to navigate to different pages until one did pop up. This actually worked well since my comments didn't disappear anymore, but it was a real hassle at first.

I also had big problems trying to see the comments that were left on our source code. This is actually something I'm still trying to figure out! It seems like only some of the comments made actually show up when you browse to the file, and others are left hidden. All six reviewers did post reviews, but they didn't all show up together. When I first looked at the source code, there were only reviews from anthony.m.du, john.km.zhou, and aricwest. In addition, these reviews were sometimes there and sometimes not there. It was really confusing! The way I found the other reviewer's comments was through a link in one of the gmail notifications, of which I only received for two reviews. This link brought me to some other page that listed all the comments on their own. What's better is that aricwest's comments were on both the source code side and the comment page. I have no idea why it does this but I'm just glad I figured out a way to see them all. 

What I learned from it all

After doing reviews, receiving reviews, and dealing with Google's review tools, I can now see the importance of a software review. For the past week I have been trying to think of ways to improve the structure of Due Dates gold. Now I think I have a better idea of what needs to be done. The reviewers of our code really help in creating a better system overall.

Creating My First OSS Project: Due Dates

PROJECT: Due Dates

PROJECT PAGE: http://code.google.com/p/duedates-gold/

TEAM: Tyler Wolff and Scheller Sanchez (team gold)

OVERALL CONCEPT: Due Dates is a program that will go and retrieve information about various items that you (the user) have borrowed, including their due dates. The application can be used for library books, videos, or anything else with a due date, and it can be extended to any source that has an online login. As the tag line states - "Never pay a late fee again!"

project homepage view

THE SYSTEM

For the first version of Due Dates, my partner, Scheller and I decided to implement a system for use with only one library - the University of Hawaii at Manoa Library.  This would enable any UH student to use our application to view what books they have borrowed and which ones are due, thus making it a useful system (Prime directive #1). We decided to do this with the addition of some extendible features to expand the functionality in the future. For this stage of our program, it would include these classes.

• LibraryVault - an object to hold information about a given online library system. Object holds the site URL, the login form's name, and the two parameter names within form.
• DueDatesGold - this is the main class that uses LibraryVault objects in conjunction with user defined id/passwords (or any type of login information) to gather information about borrowed books and their due dates.

This initial structure, however simple, would give great functionality into accessing UH Manoa's library system, as well as allow for some future program expansion. The way we see it, since there is a LibraryVault object, many libraries can be set up initially from outside sources, like a file or even a database. Because of this, methods like the login method can then be used for multiple library systems, thus abstracting the code a little more.

However, because our first version of Due Dates only deals with the UH Manoa Library system, the overall code is not simplified that much.  In addition the program works through the use of command-line arguments (the UH student's ID and last name). This means, it runs from a terminal with no interface capabilities. The output is just as informative though, and it can be run very simple through the use of a jar file. Anyone can download and use it (Prime Directive #2):

Sample Program Output

GROUP PROCESS

Sheller and I decided early on that we would communicate everyday about the project, whether it be in person or through the use of an instant messaging program. What ended up happening was that during the last week, we met up almost every other day in person for a couple hours, to talk about the program and work things out. This was definitely to our advantage and it worked well for both of us.

At our initial meetings we planned out the system while issuing specific tasks to each other on the project page. We even met once in Hamilton Library so we could borrow some books (for program testing!). In some of our later meetings we programmed together or edited existing files. What I found interesting was how much can get done while working together. We set up the project page instantly and put up issues just as fast. Its much easier to program as well because you can physically show the other person your code without having to send them the file. A big initial problem we had was getting Eclipse to recognize the HttpUnit classes. We worked together trying to fix it and finally found a temporary solution to the problem. This was later resolved in class.

Something that we did not do a lot at our meetings was commit files to the project repository. I don't know if this was because we never got to a final stage with our code or because we just never thought about it, but it probably would have been more efficient to commit/update code right then and there.  Overall though, it was really nice working with Scheller on this project. We both did what we planned to do and everything ran smoothly. 

SETTING UP THE PROJECT

Hosting the Due Dates project on Google Code was really great. It allowed for really easy collaboration between Scheller and I. Creating a public project page for Due Dates was something I really enjoyed. It is sort of like marketing it as a product and making it accessible to everyone (Prime Directives #2,#3). I gained some experience making a wiki page for Developers to build and modify the project. Since the project does have external dependencies like HttpUnit, I had to create informative instructions for installing and using those tools. I used lots of screen captures and descriptions to explain it all.

The issues log was a great function of google projects that I did not previously know about. After adding issues to the list, Scheller and I were able to go through each of our specific tasks, noting when they were completed. It is like a complex to-do list that really makes it easier to reach project goals as a group.

TESTING THE SYSTEM

Testing for the Due Dates system was a little different than past tests I have done. I personally was responsible for testing the login method and the method that gathered data from the UH Manoa library. I tested for correct login information, as well as incorrect login information. For the due date information, I made test cases with users who had no books borrowed and with users who did have borrowed books. I made sure content was correct and exceptions were caught. 

It was interesting building a test suite from the ground up as I have never done that before. I've only ever added to other test classes. The things we were not able to test for were external dependencies like internet connection, internet errors, etc. This could be done in the future though.

FUTURE IMPLICATIONS

One of the coolest things about the Due Dates program is its extendable capabilities. Scheller and I talked about this a lot since there is so much that could be done to enhance the system. For one the system could employ a better command-line system as well as support multiple libraries. It would be really cool too if a user was able to add their own libraries without extra coding on the programmers side. In addition, some sort of graphical interface would be great. It would make the program look even better.

CONCLUSION

Overall, the building of this project as a group was a eye opening experience. I have never really done this sort of thing programming before and it really showed me the possibilities of open source software development. If many people were all working on this project at the same time, who knows how great the program could become. And it is all done so easily with Google Project Hosting and subversion technology. Hopefully in the future this project can really expand and develop.

Further Exploration in Configuration Management

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

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

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

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

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

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)

1.         20 errors due to lines over 100 characters long
   
2.         3 Javadoc errors
   
3.         1 error due to using a import wildcard statement '*'
   

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

1.         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]

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.