The actual coding portion--using the JavaMail package and the Timer and TimerTask classes--was pretty easy. Getting the compiled JAR file to run, on the other hand, was quite confusing. Initially, I built our JAR file by uncompressing JavaMail's
mail.jar and including it within our JAR file. However, this resulted in a `java.lang.SecurityException`. I googled the problem and fiddled with the contents of the JAR file to no avail. Finally, Ronn suggested that I put the required mail.jar file in the Java JRE's extensions folder (it actually doesn't seem to need to be in the Java JDK's extension folder). I am still hoping for a better solution; that our program depends on users installing a separate, external package seems less than ideal.We spent some time trying to increase our system's code coverage, decrease the coupling, and generally make our system more object oriented. Towards these goals, we created a new ResultsList class, which is basically an ArrayList class with some added, customized methods to sort, filter, and convert the object to a String. I am not entirely sure that this was a good change. On one hand, this reduces coupling, the methods are easier to test, and the code seems "cleaner" in general. On the other hand, any developer who wants to extend our system must work with our implementation-specific ResultsList class, whereas before, they could have used any implementation of
List<BorrowedItem>, which is slightly less specific.Problems and Hackystat
Besides getting the program to run from the JAR file, which was by far the biggest problem we had, we also had some trouble increasing our code coverage. We weren't sure how to fully test the Email class without actually sending out email (I'm not sure that's even possible). We created some tests for the
argparser method of our DueDates class, but the rest of the methods are largely "untested". According to Hackystat, we have a questionably healthy amount of code coverage. This doesn't really concern me too much because the untested methods basically call other methods, which do all the work, and those methods are tested; the "nuts and bolts" of our system are sound.Also according to Hackystat, our project has had quite a bit of code churn this week. This reflects the creation of the ResultsList class and the refactoring of other classes to use it, as well as changing the methods and fields in the DueDates class to be package-level accessible (as opposed to private). These were needed changes, and the yellow level of churn doesn't concern me.
When I was working on the project, I found myself thinking about how the changes I was about to make would affect my statistics on Hackystat. For example, I would question the creation of a new method, or even using an if statement. I don't think this is a healthy approach to programming. I should focus on creating something that works first, and then refining it. But I think with increased transparency comes some measure of increased scrutiny, including self-scrutiny.
Group Process
Erin and I only got together one time this week to work together. We figured out how to use Timer, TimerTask, and JavaMail pretty early on, we thought that it was straightforward, and we thought that everything would be pretty easy this week (which, for the most part, it was). However, we did discuss the project every day over IM, and use screen sharing software (when it worked). Towards the end we did encounter some problems that we might have avoided if we got together more, and as a result I think our code is a bit "messier" than it could be.
I am looking forward to this next stage in our project. We have gotten used to working in pairs where we have a lot of control over our project, and it will be interesting to see how a larger group will work together.
No comments:
Post a Comment