We've been working on the project DueDates since the early month of October. Since then I've had my eye set to get to this stage of our application. I'm excited to say the least that this application has just achieved status as a genuine web application. In this 2.0 release of DueDates, it has been re-factored many times, re-designed for expandability, and fixed to interact more effectively. I'll explain the process that brought us to this point in our application and what features you'll find different from previous increments of DueDates.
Project's page: DueDates-polu
Group Members:
John Ancheta,
Anthony Du,
Yasu Kaneshige,
Erin Kim
Process:
I sometimes have to remind myself that the process is just as (or even sometimes more) important than the end result. It is especially applicable in group projects such as these. I'm proud to say that this time around I was grouped with some very strong and talented individuals. By being surrounded with this kind of environment, I felt that the knowledge sharing was much more of a solid ritual rather than an obligation. It was easy to get in touch with one another and no one felt left out. Everyone had an equal set of tasks, and we frequently spoke outside of class about the project. I also felt a sense of security, since we started very early on in this project. It felt great since the project had fresh new faces and ideas regarding the application. It was easier to communicate our ideas and worries effectively since we chatted on Google talk and Gmail (thank you Google!). So we often sat around the camp fire and discussed about which tasks needed to be done and accomplished, and for which days they needed to be integrated. We followed the concept of working fast to get things done to achieve functionality, and save room for later enhancements. I have to admit that we didn't follow the agile approach of Test-Driven Development, but eventually our testing and coverage caught up to us. It was inevitable that testing was a key aspect, but we kept it in the shadows for awhile since we were predicting a quick end-time for this application. Practically the first week was pushing to finish all required tasks needed for this web app. We did so, since we all wanted an enjoyable Thanksgiving holiday. As the days progress, there on after we kept on improving the look and feel of the application, little by little we also added new features and stripped out unnecessary pieces to enable a more defined product.
Setting goals:
One of our group members made a very nice calendar describing our jobs during the span of two weeks. This made it easier to see what we had planned ahead of time and what things were tasked to who. The breakdown of the project was very clear. Each set of tasks were derived from these milestones:
R1) Support an XML configuration file.
R2) Basic DueDates functionality
R3) Basic DueDates functionality w/ CSS.
R4) Provide sorting
R5) Filtering
R6) Email Alerts
Since we have an even group of 4, it was easier to just have two pairs working on a couple of milestones. Although the pairs were established, we still looked to each others skills to accomplish certain tasks that were related. I had the pleasure to work on R1, R2, & R4. Possibly the coolest thing out of this whole project is just the idea of building a web application using Wicket. Initially we imported a previous project DueDates-blue-v1.2 as our base code, but many aspects in the design needed to change in order to suit the needs of building a Wicket application. More things needed to be added, but basic functions enabling the features were pretty much solid. It was safe to say that we almost had everything needed to finish this application. We simply needed to provide a GUI for what we had previously built in DueDates-v1.2! The online Wicket example apps and Wicket API was a good place to absorb knowledge and derive simple practices for common tasks. I enjoyed looking at the API as a resource guide to understanding the structure and formation of components/models/markup. Soon after assimilating the facts and concepts, the transition from novice Wicket developer to intermediate Wicket developer was easy.
Layout:
- Index page - contains the user login prompt.
- Home page - contains the listings and the core purpose of the application.
- Alerts Preference page - contains a set of options to enable a user to set alert processes.
- Currently we support user authentication in a localized setting for users. In later enhancements, we will start looking into creating a database back-end using Derby's Embedded/Network Server engines which will require the user to register upon first visiting the page.
- Support libraries, including: University of Hawaii @ Manoa Library & Hawaii State Library.
- Customizable alerts and options to filter results of due dates listing. Background processing is another topic that would enhance our alert system.
- Capable of retrieving and updating multiple libraries at once.
- Easy navigation links.
I can't rule out that our project was properly assessed by Hackystat. We each had problems with it not sensing our data, or not reading our number of commits, builds, etc. Overall, the data does somewhat describeseach individual's participation in a fairly accurate manner. Currently it's the closest thing we have to gain statistical evidence about the health of a project and its affecting members.
Conclusion:
Everyday meant progress, someone was either working on the css, the html simultaneously, or spicing up a functionality for a page. We each had a hand in the making of this application. I'm very proud to say that I could be a part of it. Although we didn't successfully pull off the database back-end or background-processing, I hope that we'll revisit them sometime in the near future. As for now, the application is in good shape for general use.
Resources:
DueDates Project Page: http://code.google.com/p/duedates-polu/
User's guide: http://code.google.com/p/duedates-polu/wiki/UsersGuideWiki
Developer's guide: http://code.google.com/p/duedates-polu/wiki/DeveloperGuide
Other Resources:
Hackystat Project Page: http://code.google.com/p/hackystat/
Apache's Derby Home Page: http://db.apache.org/derby/
No comments:
Post a Comment