DueDates Project (Part 3)

Premise:
Surprise! We just released our DueDates-v1.1 this morning. The project has had numerous breakdowns and rebuilds since its first code release last month. In many ways we've accomplished some new features and have enhanced a few old features. I'll explain some of the changes (including self changes) and some of the difficulties that we endured during the past two weeks to release this third increment of our implementation of DueDates.

Re-design and Enhancements:
After the first two increments of this project, I've come realize how much planning and thought is needed to get a good, concise and obtainable goal. In my last posting, I mentioned about using a MS Visio-like diagramming tool, called OmniGraffle (only for macs) which assisted me in my planning and development. Likewise, I would like to emphasize how much help this tool, along with all the quality assurance tools, such as JUnit, CheckStyles, and EMMA has helped us in the continuation of our development for this project. This is almost like a thank you note to those building tools which automated the process of that us humans lack naturally. In some ways it has influenced me to program more diligently and carefully. Here's a quick rundown of the changes in design and class structure, and how it has impact the project outlook as a whole.
So I sat down one day to quickly draw out the current stages of our application. It was nothing fancy just a lot of holes to fill in and extra spaces that weren't needed. It was easy to say that a rework would be the easiest. Meaning I could say that working from a clean slate would help clear the pallete of confusion, but I knew from the back of my head that not everything will go as plan if I didn't approach the problem the right way. So I put aside all old tactics and really, in a sense, reworked the way I processed a problem. I thought more about the small steps I needed to take (not too long of course). Every step had its kinks to be worked out and every event thereafter was followed by a branch in another direction. I was more concerned by the path of the project rather than succeeding at the next step. This methodology I built myself gave me some room for errors, but also enhanced my skills in reasoning. "Have I made the right choice to place this method here, or is it better to not have it at all." Sometimes the best solution is not the solution. I felt almost like a sculpture, breaking down the pieces of clay, smoothening the edges, molding the sides, and continuously deciding and critiquing. Finally a masterpiece starts to unravel, and something that I've envisioned in my head comes to life. Following this notion of obtaining what is necessary and discarding what is useless has resulted in our new design. In this new design, I focused mostly on the command line arguments because it serves as our vessel to communicate to our users and it is the most prone to errors. I felt that without this interface being perfect/semi-effective then we would have no functional application. We've extracted more abstract classes, made use of more subclasses, and made room for other possibilities for future developers. The thing I'm most proud of is the Argument abstract class. What brought on this simple abstraction was its wide generalization in other systems. I've seen arguments in Linux/Unix or even Windows DOS that work the same way via terminal/command prompt. I broke down arguments (user input) into three essential categories: 1) options, 2) options with parameters, & 3) and essentially parameters. The creation of this class has spawned off numerous "parser" classes that utilize the same idea. This gives more room for future developers to create their own interpretation of an argument parser and make it work for themselves. I'm almost confident to say that, 80 % of the dedicated features for this project can be found in our LibraryParser class. The LibraryParser (which extends from Argument) holds most of the essential makeup of our functions. Some other enhancements worth mention are the new options: "-sort" and "-within". To get a better grasp of these two options, I would recommend visiting our project page, here. There you'll find links to our user and developer guides. Hopefully you'll find the project useful and interesting. However, I would be more happy to see developers voice their opinions toward the details of some classes and how they can improve/extract. If a developer comes out saying, "Oh this looks useful, maybe I might be able to use this for my app." then I've somewhat served my duty as a open source developer. Also, I believe this passing of knowledge is beneficial for everyone and shouldn't be confined. Although there might be mistakes, those mistakes are much more beneficial by learning from them.

Reflection:
During this third part of our DueDates project, I've helped myself revitalize my process of development and in turn, given a better insight on how I code as a programmer. I've never in my past 2 years as a ICS student realize the beauty of coding. The marriage of art and coding has made me become more open minded to the possibilities of a joyous application. Of course to balance the experience, I've also stumbled upon some mishaps and fluctuations in my coding path, but that has only enhanced the fun in it. Again the past few weeks developing on this project has been very rewarding for myself and the team. I've become more adept to develop using Google's Project Hosting site (SVN), quality assurance tools, and coding in teams. Hopefully, sometime in the future I'll aspire to newer projects that challenge me (in this kind of level) as an ICS student and developer.