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.

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.