DueDates 2.0: Herald of Aric 2.0

My final project in Software Engineering is a culmination of the many different techniques and tools I have learned over the last semester. This includes using Eclipse, Ant, Findbugs, Checkstyle, Emma, Hackystat, Hudson, SVN, Wicket, Junit, Google Project Hosting, and something called Java to create DueDates-ulaula 2.0. The project was a team effort from Tyler Wolff, Mari-Lee Flestado, and myself to create a web application with the following features:

• A login page that would make use of an XML file to authenticate users.
• A results page capable of displaying a dynamic list of libraries, based on user data. The page can update and display lists of books due at the users libraries, and can be sorted and filtered.
• An alerts page capable of enabling a process to generate daily email updates for one or more of their libraries.
• Use CSS to create a consistent and pleasant web application.
• Adhere to the three prime directives of open source software engineering: the program accomplishes a useful task, a user can easily install and use the application, and a developer can easily change and extend the functionality of the program.

Our team was able to mostly fulfill these requirements, though there are several areas I would still like to improve in the future. There are "extra credit" features that we were not able to get into, but would be good extensions to implement in the future. It could also use more testing on typical user machines to make sure that the many tools on my computer aren't keeping the program alive even though a user would have problems.

Problems Encountered and Solved

After various administrative tasks, the first problem we encountered was simply deciding between our DueDates 1.2 projects to see which would live on. Though I really like what my own could have been capable of, I did not feel it was quite ready for the task. We end up using Tyler's, DueDates-gold, and it worked out well with minimal changes necessary. This was of course accompanied by the various issues of getting our classpaths set up properly. We also found that as we went along our testing suite became more and more burdensome due to the length of time to complete so some mock-library testing was set up that would be able to exercise most of the code, but skip over the parts that relied on library sites. From there, most issues simply had to do with learning how to properly use wicket features, such as checkboxes, and also various troubles with WicketTester that took some time and team effort to get.

Group Dynamics

Our group worked quite well as a team, though mostly somewhat separately. We met in person just a few times a week to go over planning and design issues, crank out any pressing problems, and get a feel for who would be working on what. We then would be in regular contact through Google Talk. I found it to be generally a better experience than working with only one other person for adding to our breadth of comfort zones and skills. For example, Tyler did almost all of the CSS and layout as he was most skilled and interested that area. I found myself jumping around a lot, perhaps too much, but enjoyed both adding to the code and also keenly looking for problems in the code. More people also meant potentially more conflicts while working on the same code, but luckily the project was of large enough size that this was not too often an issue. I believe we all contributed fairly equally to the project overall, though not necessarily in specific areas. Our Hackystat dev time showed fairly consistent work, especially from Mari. Tyler and I had several days where we didn't work on the project. I know my official time feels a little low, not taking into account my times staring at the code just trying to find an error, or Mari and Tyler's time working outside of eclipse on the wiki guides. And though Mari shows the most dev time, Tyler and I generally built and committed more often. Each one of us has at least one category where we lead by a large margin, which I think shows more of a difference in development style than any overall large difference in effort.

Continuous Integration and Software ICU

During the course of the project we used Hudson and Hackystat to keep continual updates on the health of the project.

This is the final portfolio analysis from Hackystat for the two weeks of development. Overall the health of the project was fairly average, Development and commits took place regularly, though increasingly toward the deadline. Coverage was around 60% through most of the project, but improved near the end, though this was more reactionary and indicated a lack of test driven design, an approach we occasionally used, but often would get forgotten. Our coupling showed a steady rise, but I don't think this was bad considering the larger number of classes necessary compared to previous projects. The statistics are not all-telling, but I did find useful for getting a feel for where the project was at and where it needed to get to.

More to learn

As I continue to grow as a software developer there's definitely some areas I want to improve on. The first is on general design. I want to get better at being able to see just what a class, method, or application is going to need ahead of time so there's less changes to be made later. I also really want to get better at test driven design. I do it in pieces, but too often get sidetracked away from the original intent. However, that which I see I feel is very useful. I also would like to expand in the more social areas of software engineering - specifically improving my leadership skills and also taking more effort to pair program. Many times during this and other projects I would come across (or submit myself) a problem in a commit that I know never would have occurred had I been working directly with that person. Years of working on my own in computer science classes, without many of the tools I now know, and with testing always at the back of my mind rather than the front, makes it difficult to break some of these old habits. However, this project has definitely improved me bit by bit in all of those areas and I look forward to the next leap forward as a software engineer.