MyStack.com (sic): A Wicket WebApp

Posted on Saturday, November 22, 2008
0 commentsAdd comments

Wicket is a framework for building Java-enabled web applications. If you have done web design in ASP.NET and AJAX, then using Wicket is somewhat similar to that process and very different in other ways. However, if you have ever worked with spaghetti code, such as classic-ASP, or Macromedia’s ColdFusion MX, which I had the displeasure of working with in my ICS 415 course, then Wicket simplifies web application development by separating the business logic from the presentation logic.

I really enjoy working in ASP.NET, so I am usually very critical when using and evaluating another web application framework. What I like about Wicket is that the developer is able to use a code-behind model just as ASP.NET development facilitates. What I don’t like is being required to manually “rebuild” the web-page in the Java code-behind by adding page elements, which have to reflect the DOM. The difference here is, at least when using Visual Studio, the elements are added by the code generator to the web page, then the developer is able to directly access the elements methods and write custom event handlers for their behaviors. For example in ASP.NET, I can write custom code for a button’s click behavior in its Click event handler once it has been added to the web page. Whereas, in Wicket, I first need to manually add the button element to the web page, then manually add it in the Java code-behind page ensuring that it is added in the same container element as it resides on the web page. Otherwise, using Wicket was an enjoyable experience and roughly on par with using ASP.NET, but worlds apart from using something like Macromedia’s ColdFusion MX.

Hello, Wicket
Getting started was a bit of a task. However, my ICS professor Philip Johnson has provided a superb set of Wicket examples. To use these examples, first requires installing Wicket, Jetty, and SLF4J libraries. Instructions for setting these libraries up can be found on the Wicket examples web site. To build my implementation of an online stack application, I focused mostly on Example 04 for its session state capabilities, and then Example 02 for its form and table demos. Completing the assignment was quite simple due to my familiarity with building web pages and session state handling.
Hello, MyStack.com (sic)
This is a screen shot of my implementation, which uses the name “MyStack.com” and is in no way associated to any official company or web sites that use the same name. Although, I was not able to reach any URL of the form http://www.mystack.com at the time of this posting.



My implementation can be downloaded here.

DueDates-Silver v1.2: The Evolution of a Simple Application

Posted on Monday, November 17, 2008
0 commentsAdd comments

This week my team was tasked with adding two new features to our DueDates project. First, the project was to now support the capability of sending its results to an email account the user specified. The second enhancement was to allow scheduling of requesting and outputting the results. Actually, the first criteria specified that support was to be for either output to the console or the email—throwing an error if neither was explicitly supplied. However, we decided against requiring explicit invocation to output to the console. We reasoned that if the user is calling the application from the command line that the default output should be to the console and that explicit specification of email output by the user was sufficient to override the default (console) specification.
Gremlins, Baci, and Instant Karma
Personally, I seem to be suffering through a patch of difficult times with regards to my computer. In the past month, I have had to re-install my operating system, which required reconfiguring it once more to support the setup required for my ICS 413 course work. Then, just last week my laptop’s adapter cord frayed! That left me with no way to keep its battery charged until I forked over $100 to get a new adapter. That cost me one day of development during the enhancement to v1.2. Atop this, my commits were not being sent to the SICU correctly, which by all accounts I can only attribute to gremlins. Luckily, here my professor was able to resolve getting the commits into the SICU, but the problem of why this is occurring continues to plague me.

Finally, my latest bout of rotten luck came in the form of another wasted (or lost) day of development. While working on setting up the email feature, I kept encountering numerous security issues and NoClassDefFound exceptions for either the JavaMail Message and MessagingException classes. After working on trying to resolve this for about half a day, I committed my files and my project partner updated his build. To our astonishment, the files not only built, but ran correctly!!! There was an actual email sent to his account. We decided to break for the day, as he had been working on the scheduling issue and had been having hours of his own issues with that. Considering my recent bout of poor-quality karma, it was likely it was affecting him, as well. The next morning, I called him up, and we resolved the issue over the phone. So, a day lost, but issue fixed. Later that night, several classmates were having similar issues, which I was able to share how Robin and I had resolved it for me. This solution seemed to work for at least three other classmates. The solution was that the JavaMail mail.jar file need to be copied to both the Java JDK lib/ext and the Java JRE lib/ext directories.
One Minor Version Older And Deeper In Debt
This iteration had me feeling like Hank Thompson’s poor man in 16 Tons. It seemed the more we did, the more that needed to get done. There were just so many details and minor issues that seemed to plague me that it really impacted our success this time. While we did finish and were able to get everything implemented, the process seemed belabored and fraught with frustration at things that we felt more-or-less to be non-issues. (Non-issue: something that should be trivial, but consumes more time and resources than would seem required to accomplish.) But, all-in-all our project remained stable. While some stats climbed and dipped here and there, we were able to manage them and keep them near or at healthy levels.

Also, we took the opportunity to do many things, including cleaning up code (causing a major code churn event one day that was mostly due to sorting methods and arranging class behaviors more appropriately), and implementing three new classes (Email, Messenger, DueDatesTimerTask) with associated interfaces.
What’s on the Horizon?
It appears DueDates v2.0 will be in development soon and a projected migration to a web based application. From the first day we met, Robin and I intended this to be the targeted platform for our DueDates project. All the “measure twice, cut once” practices we have been using coupled with using TortoiseSVN, Hudson, the HackyStat SICU, JUnit testing, and the many other tools have put our project into a state that should facilitate this migration with moderate ease and resource management.

It’s Called A Head-to-Toe Exam For A Reason

Posted on Friday, November 07, 2008
0 commentsAdd comments

I was quite excited this week when presented with the idea of a Software ICU (SICU) for gauging the health of a software project based on a number of “vital signs”. Just like an Intensive Care Unit of a hospital, the idea of a SICU is to provide round-the-clock status monitoring a software project, in this case, the patient. The patient’s vitals consist of both measurable statistics that can be compared to a set of agreed upon quality development norms, as well as, additional statistics that offer insight, although somewhat ambiguous and less deterministic, as to a project's health.

Measurable Vitals
• Coverage Testing represents the amount of code a project’s test cases cover.
• Complexity determined through analysis of branching and looping in the project.
• Coupling reflects the bounding of the project classes to other classes (external and internal) and reliance by other classes (external and internal) upon them.
• Churn represents the amount of code change over a period of time.
• Code Issues determined by the number of compilation issues a project incurs.

Less Deterministic Vitals
• Size (LOC) reflects the size of the project in lines of code.
• Development Time reflects the aggregated development time of project members.
• Commits reflect the number of SVN commits members have made during the period.
• Builds represent the number of builds members have made during the period.
• Tests represent the number of test runs members have made during the period.
I’m a programmer, not a doctor, Jim!
A SICU allows a programmer to put on the hat of a software doctor, or perhaps more precisely, become a software surgeon. This is because, a SICU provides project team members the opportunity to focus attention where the patient most needs it. Just as a real ICU monitors the appropriate vital signs for its patients, when one or more of these vitals needs attention, the team of experts is able to focus quickly and exactingly where the problem is occurring. A SICU provides developers a direct measurement of the health of their project, and where vitals deviate from the accepted norms; they focus their attention and bring the patient back inline with those norms.
Exam Room 2 Is Open.
If you have been following my blogs over the past few weeks, you should be well aware that my partner and I have been working on the project DueDates-Silver, which queries libraries to return the items checked out by the user to a console window. Our objective this week was to connect our project to the electrodes and other measuring equipment provided by the Hackystat system. Just like an ICU, Hackystat provides all these measurements from a centralized location.

There were many steps to connect all the Hackystat electrodes to the DueDates-Silver project to get monitoring of its vitals on a daily basis. However, Hackystat has an excellent set of tutorials which make the process very clear and easy to follow, implement, and achieve with little hassle or issue.
We’ve got a pulse, doctor!
Being quite anxious to see what the vitals of DueDates-Silver would be, I took the time to get our project set up as quickly as possible. I was very pleased with our initial set of vitals, which continue to reaffirm the “measure twice, cut once” philosophy our project has used from its inception. Our vitals were:

vitals

It should be noted that the Size(LOC) column is not calculating appropriately at this time and should reflect at ~2400 lines of code.
When May I Schedule Your Follow-up Exam?
The information a SICU provides a team of developers is so empowering. It empowers them to focus on what is important and needs to improve, but more importantly it provides a holistic approach to management and evolution of the project. While DueDates-Silver fairs moderately well by its initial readings, it has room for improvement. I would like to decrease the project’s complexity to the range of 1.0 to 1.5. The coupling is manageable for now, but I would not like to see it increase much. And testing will continue to be a challenge to maintain at 90% as each new code line, block, method, and object class requires new tests be added to ensure the coverage remains at appropriate levels.

DueDates v1.1: Further Progession Into Open Source Software Development

Posted on Monday, November 03, 2008
0 commentsAdd comments

Ladies and Gentlemen, it’s my pleasure to now introduce to you DueDates-Silver v1.1. DueDates v1.1 has come a long way since just two weeks ago when v1.0 was first released. In this release, my project partner, Robin Raqueno, and I strove to make it satisfy even more of the Prime Directives of Open Source Software (OSS) Engineering. (You can read about these directives in my blog JFreeChart: Open Source Charting Solutions.) And, the “measure twice, cut once” methodology first embraced during the development of DueDates v1.0 continued to pay off while enhancing the project to meet the specifications of DueDates v1.1.
OSS Priorities
While we had new specifications to build into the latest release of DueDates, my top priority was having our project add a linchpin in the form of an XML file that held library data. This XML file would bind the project together in a data-centric way that both Robin and I had envisioned in the project since development of version 1.0. It would also provide excellent OSS support of the prime directives by freeing users and contributing developers to easily expand the project to include their own set of libraries without much effort. By simply following the repository template we provide, they could add their own library information and even remove the libraries that we provide. Peers who reviewed our project were amazed at this, believing it to be a great feature and one that all DueDates project should incorporate.
New Specifications
This version of DueDates supports sorting of results by library or by the date items are coming due. A second specification was to support a query of items coming due within a specified number of days. Also, prior to the v1.1 release, we had a peer review of our project from which we were to incorporate any additional suggestions as appropriate and possible.
Measuring Again, Cutting Again
Robin and I really didn’t have many issues completing this week’s tasks and moving DueDates v1.0 to DueDates v1.1. Prior to adding the new specification, we looked into two aspects of changes to our project. First, we wanted to move to an XML based repository for our library data. We searched for a day on the topic and eventually found this article from Sun Developer Network. Following these instructions, we were able to add this feature to our project without much effort.

Our next goal was to find an appropriate command line parsing software to assist us in that task. We found an absolutely wonderful OSS command line parser from John E. Lloyd called ArgParser. This did everything we needed, along with providing bells and whistles.

After resolving those issues, we set about the task of adding our new specifications. We were basically able to do this over the course of the first few days of development, leaving the remaining time to do our peer review projects and provide additional testing of our system. The biggest change in implementing version 1.1 was to alter the UserLibraryInfo (ULI) class from being a single object class to a collection object class. Version 1.0 allowed ULI to take in only one user-library pair and query results for that single value pair. The latest version allows multiple user-library pairs to be added to the ULI object and all queried at once.

Having abstracted the problem out even further this week allowed us to make an additional change to the project that allowed the user to specify the library repository (XML data file) that they want to use from the command line. The remaining time we spent testing and updating our User and Developer Guides per the comments from our peer reviewers.

Conclusion
We used continuous integration during the development of DueDates v1.1. We failed a few times, but these were mostly due to changes in our project structure that did not get updated properly when committing the changes to Google Code’s server. We altered our project structure, moved files around, and deleted files. Occasionally, the old file had not been removed from the local repository or the SVN repository which would cause builds to fail. But in general, I think striving to keep a sun on the Hudson server was a motivator to not break the build.

Robin and I continue to work well together, and even received high praise from our peers this week on the quality and the direction our project has taken. We have several ideas for our project once it moves in to a GUI world and look forward to that opportunity.

DueDates v1.1: A Pre-Release Review

Posted on Saturday, November 01, 2008
0 commentsAdd comments

This week I was provided the opportunity to review the DueDates-Yellow project designed by John Ly and John Zhou. Likewise, with a DueDates-Silver v1.1 being released soon, Scheller Sanchez and Tyler Wolff, the project leads for DueDates-Gold, were asked to review our project.
Google Code Reviews
This review process was easier to do in regards to using Google’s project review system via Issue Tracking and branching of the project versus creating a wiki page and then needing to locate all the review comments throughout the various code files. While there were a few issues with locating comments using the updated methodology, there were only a few places that one would expect to find those entries.

Reviewing DueDates-Yellow
Overall, the code style and implementation for DueDates-Yellow is fine. However, its biggest issue, in my opinion, is that the problem space has not been abstracted at the necessary level to manage maintenance and ease the implementation of future development objectives. There are several instances of similar branching structures and class definitions which provide the opportunity to abstact the problem space further. I tried to provide a constructive, objective review of DueDates-Yellow without being overly critical of the project’s implementation.
DueDates-Silver v1.1 Review
Scheller and Tyler provided very good comments. Most of their comments dealt with details, but very important ones. Several good catches included the lack of information stating that Java 6 or higher is needed, and that the QA instructions have been missing since v1.0.

For the most part, it seems that Tyler was very impressed with our implementation and project structure. In particular, he thought that all DueDates projects should be required to include an XML repository to hold the library data for the application. I would have to say he paid our project one of the highest compliments one developer can give to another:

”Your groups project is the real deal. I think if the class ever merges to one project we should merge to this version.”
Future Reviews
There’s not much I would do differently to do future reviews. The improved Review Issue tracking mechanism on Google Code has much improved the process. The only change would be to have a better understanding of where the review comments go upon completion.

Newer Posts Older Posts
Subscribe to: Posts (Atom)