DueDates 2.0 Wicket App

Premise:
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.
  

Features:

• 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.
  

ICU of our project:
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/

Stack on Wicket

Premise:
The purpose of this entry is to explain my experiences on creating my very first wicket web application written in Java. Wicket is a web framework written in Java and its sole purpose is to create web applications. More information regarding wicket and the tools I used to deploy my application can be found below:

Apache's Wicket Framework WICKET
Tools and dependencies:
JETTY
SL4J

Stack-wicket:
My very first wicket application is very similar to my earlier blog entries about stack. This application proved to be a good starting point to get to know Wicket's framework. I started out by creating a Wicket Form, and made the subsequent labels, an input field and submit buttons (push, pop, and clear), and results table to layout my application. After successfully starting the Jetty server and running the application through the browser, then my next step was to add functionality to the buttons I had previously created. Before adding the functions to the buttons, I created a session class to handle multiple user's by keeping a copy of the user's stack and variables (input field) in a session. Next comes the easy part, adding functionality to the buttons by creating anonymous ("on-the-fly") classes. I never knew there was a name for on-the-fly classes that really comes in handle when you need to just tweak a few override methods (onSubmit()) without having to create a new subclass.
Issues:
Upon creating this application, I ran into a few bumps and annoyances. One thing that bothered me the most was configuring my environment to support wicket and its subsequent dependencies (.classpath, build.xml). A lot of these issues were minor, but it's quite detrimental in a sophisticated application like this. Other than configuration issues, I also had ones that involved coding. Many of the coding issues were reported back from running "ant -f verify.build.xml," one of which involved serializing the Stack class. This, along with a few other modifications were made to the Stack class. After trickling down and resolving all errors from FindBugs and PMD (they're best buddies), I was able to pass verify and run the application successfully.
Download Distribution:
The copy of my distribution of stack-wicket can be found here.

Conclusion:
Overall the application was quite self-explanatory. You create a stack and you have only a few options to operate a stack (push, pop or clear). The knowledge I gained from this experience was basically figuring out a good work-flow for creating web applications using Wicket. I now have a better understanding, along with a process of thinking when creating these kinds of applications. It's something to get used to, and the concept can be easily assimilated into other similar web frameworks.

ICS Industry Day '08

Today I had the pleasure to catch the last hour of a presentation given by Concentris. I came out of the presentation feeling very impressed about the concept of "meshing." Especially in the military environment and infrastructure, concepts like these are extremely useful in creating applications like video surveillance, intricate sensors, unmanned ground vehicles (bots), VoIP communications, IED response and avoidance, and lots more. The presenter was also reaching out for higher end programmers, such as front-end web developers. I thought, "well yes I have some experience in that... but do I really wanna stick to just doing that for the rest of my career, after just being exposed to all those other possibilities? No, of course not!" So one of the greatest things taken from this experience was my pure sense of escapism from my usual norm. I felt that after being here with my colleagues that I need to diversify myself and branch out to other topics that are foreign to me. Data security and networking have always lingered on the tip of tongues of many of my work associates, and I'm beginning to see its importance in my being an ICS student to know these things. I also had the pleasure to meet with some people from Referentia. Referentia was glad to speak with me first. They couldn't help but see a young face and wanting to talk to them. I'm used to the gesture, given being at job fairs like these, you are forced to shake hands and become engaged. I did that exactly, but it was less hectic since the hallway wasn't heavily packed. Unfortunately I didn't have the chance to witness their presentation, but they were quite informative in giving me a brief talk about what they do and what possibilities they hold within their company. I spoke with one of their interns, who has been working for them for about two years. Come to find out, the intern is actually an Electrical Engineering major but started working on many software-related things. He explained a lot of the tools used in his development environment that matched exactly to tools enforced in my ICS 413 class. It was incredible to see how things like quality assurance tools and continuous software development tools were being applied to real world applications. The main thing I took from this experience was the goals and expectations of companies. I wanted to get to know the skillset neccessary to obtain jobs similar or just like these. Of course, these job descriptions don't scare me since they do also offer internships which prove to be a great way to gain valuable experiences in the work field. I also experienced the notion that diversity in the field of ICS is a must, to gain full knowledge of areas supportive in real life applications. I'll be sure to carry on these experiences into my continuation as a student and future computer scientist.

DueDates: ICU downtime (postponed v1.2 release)

Premise:
This entry is to describe the efforts put out to releasing our next iteration of DueDates. Unfortunately this entry will be a sad one, since we have not yet released the entry and that things currently suffering from issues.
The ol' time constraint came back to bite us...
This will be a very short entry regarding my experiences this past week of working on DueDates. I will assure you that it was not a pleasant one. Considering the time constraints and last minute changes to arrive to an "elegant" solution. I took the time yesterday to work on refactoring my custom class parser called Argument. The plan went well in separating the options and options with parameters. By separating the two and making them extensible, I made them into separate classes. This made it easier to keep track of options with parameters since now the parameters are contained within a list of the option. I also refactored the LibraryParser class since I felt that it was too overbloated with things and it went against the name of the class being a called "parser". So I stripped it down into two separate classes, one being called DueDatesParser which dealt with argument parsing (extends from Argument abstract class) and the other being called LibraryManager which handled the manipulation of options being passed from DueDatesParser (sort and within functions, etc.).
PMD vs. FindBugs
After testing this fine on my local machine, it was finally time to build the stuff through ant -f verify.build.xml. It came to my attention how much things can break when you think you've got a solid idea going. My utter frustration was over how PMD and FindBugs would not come to an agreement when it came down to overriding equals & hashcode methods. I have a superclass, Option and a subclass of OptionParam. Option implements the comparable interface thus forcing me to override methods of equals and hashcode. In FindBugs, it would complain about the equals and hashcode methods not being overridden in the subclass. So I defined the two methods and just called its super methods (eg: super.equals(obj)). Now when I run ant verify again, it doesn't pass PMD, since PMD is now complaining about "UselessOverridingMethod."
Currently the project is at a halt and I will need to attend to this matter with my partner to resolve this issue. Hopefully we'll get something out and running by the end of today. Newly awaited features such as "-console", "-email" and "-wakeup" are still going to be featured on this next release. However we'll need the time now to resolve these issues first. Sorry for the inconvenience of this release and thank you for your patience.

DueDates on HackyStat

Premise:
After the release of our DueDates v1.1 project, we've been sitting back while waiting to see how our implementation is being tested and used. So far we haven't had any responses (weren't expecting them), but we will be graded for it as a class project. The purpose of this week's blog entry is to detail my experiences working up to using a software auditing system started by a professor and a group of alumni, called HackyStat. I took the time this week to explore its features and understand its impact in continuous development. HackyStat is truly optimized to help you and your team members better the "health" and quality of your product.

Setup:
Setting up the "ICU" program called HackyStat wasn't such a difficult task. I could understand that it might be more of a challenge for newcomers getting used to using quality assurance tools, but at this point we've surpassed those tasks. Most of my efforts were directed towards getting to know what each of the product's dependencies did. I was also more interested in knowing how it was put together. Yet this blog entry is about my experience using the product, so I won't digress any further from the topic. For long time Eclipse users, Hackystat provides a workable plugin suited to cope with settings in Eclipse. This neat looking .jar file (provided from the project's home page) contains the necessary module to easily install HackStat onto your local machine. Once you install the plugin on Eclipse, navigate over to the server hosting HackyStat. Once you are there, register as a member, verify your email and eventually log in to host your project. HackyStat project browser is the home for all the projects you may have hosted on the live server. You may take advantage of the numerous tools used to assess your project's health, and assists in understanding your project's level of efficiency or defficiency. In many ways it could show the path or direction your team is heading. This notion of knowing what your project looks like underneath a microscope has made me more cautious (but not too cautious) to the details of my enviroment. Of course, this tool does a good job at pin pointing the areas your project lacks and what areas it is excelling at, but it still needs that extra human element to interpret the data coming back. After getting through installing all sensor on your machine and successfully building and sending data to the HackyStat sensor server, what's left for you to do? It is up to your team members to address those issues to better the weak links or connecting factors relating to your project's health.

Experience:
I have yet to explore all the neat features of HackyStat, but in my short experience, I could see the potential of the product. In some ways, HackyStat seems to have this ghostly feel to it. I sometimes feel like I'm being watched, well of course I am, but it creeps me out more knowing that these sensors are constantly doing updates about my progress and assessing my activities. This may be intrusive and a violation of my privacy, but if its intensions are to assess the project as a whole, then my contribution as a programmer and team member of this project is necessary. HackyStat as a whole is a good project assessment tool, used primarily as an "ICU" monitor for your hosted projects. However, HackyStat doesn't assess the matters of the team members individually. As a whole the team members make up the team, but areas that are beyond the reach of HackyStat's sensors are not accounted for. I'm prone to say that these factors can and will inhibit dangers and warnings to the health of your project. You should use HackyStat as an indicator to pick out these flaws and to fix them within the confines of your project group.

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.

DueDates Project Review (Part 2)

Premise:
In this third increment of our DueDates project, we've been given the chance once again to review and get reviewed by our fellow colleagues for this application. Along the way I'll also explain about my experiences gained from this review and during this past week.

GPH Review:
We've managed to, at this point, do everything through Google's Project Hosting (GPH) site. Again, Google has given us the tools to code effectively in a real world environment setting. If you navigate over to the source of any project (that's hosted by GPH) there will be a new featured link next to the "search trunk" called "Request code review." The new feature makes it easy to request a code review amongst your team members or outside code reviewers. You are able to note a description of the review, branch path, marked issue status, and labels.
Overall the reviews from team duedates-red were positive and fairly short. There were still a few things we needed to provide to accompany our code, such as our wiki's. We've managed to well document our code in JavaDocs but have yet to utilize the GPH's homepage and wiki's features. Hopefully by the end of this review, we'll have a better and more concise explaination of our project on our project's homepage.

A positive experience:
In this third increment of our Duedates implementation, we've gotten a chance to better understand the structure and hierarchy of our program. Though it was difficult to grasp a clear plan in the beginning, we began to see the path lit up as the programming process progressed. It became much more beneficial to use programs beyond the use of Eclipse and quality assurance tools. Personally, I resorted to using a modeled approach to plan out our class structure. If anyone owns a mac or just wants to learn more about mac software, then I would recommend something called OmniGraffle. It is almost like Microsoft's Visio, but for the mac. After experiencing this newfound tool, I've come to realize the power of organizing my ideas, in a sense, on "paper". The program also gave me the ability to quickly implement an idea, and if i decide that the idea blows or doesn't live up to the overall design, then I could simply discard it and update my program in the same matter. This helped me develop a sense of awareness of the project's path and direction and it even provided me a clearer perspective in coordinating myself in a project like this. It also coerced me to program in a TDD fashion. Speaking of TDD, I became very TDD this past weekend. I actually got reacquainted with two very familiar friends, JUnit and EMMA. Yes, can you believe it? I actually used EMMA! EMMA proved to be very helpful in cases where I needed to better sculpt the usefulness of some functionality. Maybe a statement that wasn't being tested via JUnit, really turns out to be unnecessary for the overall application. I questioned that to myself when I had a low percent coverage. Could this mean i could do just the same amount of work with less code and more coverage. Well in some cases, yes! You can pick out certain things that can't be detected by other QA tools, because EMMA forces you to review those statements you think are needed to test the overall application. If you look deeper, then you'll see that maybe sometimes it's best to not even have that subject there in the first place. JUnit on the otherhand would not tell you that you need a test case for missing arguments. So the marriage of JUnit and Emma makes a good team in assuring better quality and sensible units of code.

Conclusion:
After taking this time to review other projects and assessing our own, I have gained new knowledge in the process of developing in a test driven environment. I have also gained the ability to strengthen my overall model (class) organization and program structure.