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.

DueDates Project Review

Premise: In this posting, I’ll continue from last week’s first iteration of our class project called DueDates. This week I was tasked to evaluate three DueDates project groups and also receive seven reviews of my implementation of the same project. Again I’ll be using Google’s Project Hosting site as my primary source code versioning and issue tracking system tool.
Setup for Review: So how do I put out a package to the world for developers to critique and annotate my work without interfering with my main code-line? Well, SVN provides a concept of creating snapshots of your production line code, called “tags”. Tags are meant for production version-labeled releases of a project. It provides a workable copy of the file-system at a certain point in time of your project. This can be easily done by the commands below. *Note that this would be exactly what a reviewer needs to do prior to evaluating your work. *Also to get the BASE_URL, you may try using the command: svn info - displays the details of the current svn repo. Or svn info | grep URL for just the base url.

svn copy BASE_URL/trunk BASE_URL/tags/review_release
-m “Tagging a review release of main line”

My Review Process: Google’s Project Hosting review tools provide developers the essentials to annotate and evaluate project source code in an effective and efficient manner. It gives reviewer’s, who must first be members of the project, the ability to leave comments within the actual project source file. When the source file is finalized and the reviewer is satisfied by their comments, then they can easily publish those results to the project. After the comments are published, the owners of the project are notified by email(s) of those comments. This definitely made my job as a reviewer better, since I’ll be able to optimize my time to focus on reviewing the project code, and it gives the owners of the project immediate feedback.
Reflecting on Results: During this review process I’ve gained insight into how to improve my code as well as learn the mistakes that I’ve made throughout the course of my implementation. In many ways, I could say “I approached it all wrong,” but by the indication of some feedback, I was also doing something right. Documentation was the main thing I knew that would have to be sacrificed due to our time constraints. Therefore, people were totally oblivious as to what my project expected as an input and output. The project was a total black box, in the front, middle and back. Since I did not pay close attention to my audience, it was difficult for people (both users and developers) to use or expand my system. However, I’m glad to say that there were some people who reached out to support. It was evidently helpful and gratifying to us both. During this process, I also found a way to “switch” between production lines. The reason for this was that I needed to repair the broken tag distribution for review. Before doing this, I sent out a mass email detailing the reasons. Here are the commands to switch between the trunk and tags (it also goes the same for any directory layout that you build through SVN):

svn switch BASE_URL/tags/review_release

Pretty nifty, huh? Indeed, I thought so too. After I got done making changes to the review_release version, I quickly switched back to the trunk's main code line to continue coding on the trunk. I was surprised to notice one reviewer who really felt inspired by my implementation of an error logger (ErrorLogger.java). My first intent for this class was to just parse out the command line arguments, but it became something more along the lines of a stack dump error logging tool. It currently parses out the arguments, separates them by [args] => [options - prefixed with a hyphen] [parameters - non-hyphen parameters (actual values)]. Options are pre-populated with somewhat of a unix/linux inspired command, "-v" or "-verbose". The final feature was the ol' error handling messages (friendly or verbose) depending on the passed options. Overall there were lots of small details that needed to be worked out of the beta stages of this increment. My goal from this point on is to sculpt out the essentials of the application, make it more abstract or general, and extended upon new ideas.

A lesson learned: I wanted to express this on my last posting but it was difficult to express matters under certain time constraints. I’ll start off by mentioning about what went wrong in my group’s implementation and then how we are currently going about to improving ourselves for future increments. I would like to tag this project during this point in time, called “death by email”. My group partner and I only had one official meet outside of class during the first week of working on this project. In my opinion it was horrifying to communicate with someone for the first time and barely knowing them. We both made the mistake by not getting to know each other better outside of class. Due to this slight alienation, we caused each other to have flawed predictions of one another. These preconceptions proved to be inaccurate and misleading. It was very difficult to see whether or not a team member was having a hard time with the project or if they were suffering from other external issues. During the course of this project, I learned that you are only as strong as your weakest link. Apparently we both had strengths and weaknesses. If we had communicated better straight from the get-go, and came together to pick at our flaws, then the project would have turned out better as a whole. My project group member and I have been taking the time out of our busy schedules to do regular fact-to-face meetings that last at least 30 minutes long. We’ve started to put this into practice rather than having to deal with just emailing each other progress reports. Hopefully we’ll be better off in our next increment, this coming week.

DueDates Project (Part 1)

Premise:
I have been tasked this past week to assist in the creation of a project called DueDates. DueDates is currently a program that enables a user the ability to check the status of items they may have borrowed from one or more library systems. It is meant to generalize the interface between the user and their list of items, whether they be books, bills, tasks and etc. For this project, I will be accompanied by the following tools and source code: Google's Project Hosting, SVN, Eclipse, HTTPUnit, and sample code, DueDatesBootstrap.zip

Process:
The hardest part in any project is the process. I found it difficult at first to plan out a reasonable and consistent plan. Many times a plan might backfire or doesn't go as you'd expect, but after a few moments of reading up on the project's needs and wants, I finally came to conclude some possible project enhancements:
User Interface:
End-users are left with a couple of command line options that makes too many assumptions as to what is required by them. Another problem was that the resulting error dumps (Java Exceptions) were being outputted in a very cryptic manner. To solve this, we could suppress the messages and also provide an extra parameter to display other misc stack dumps for developers.
Functionality:
The sample code, DueDatesBootstrap only provides sufficient code to initialize, connect and grab responses over the network to a fixed number of supported library systems. We could provide general library system templates, and pass required parameters to them. This might not solve all internal problems, such as HTTP parsing, but it will provide a step in the right direction.

Execution:
Setup:
Even some practices needed to be re-iterated. I found myself needing to take the time just to refresh on the syntax of SVN. I keep getting this notion that I need to do a "svn import", but that's only when I'm locally hosting my SVN repositories. Google's Project Hosting site skips one step in the common "svn import" and "svn checkout" process that I'm used to. Another minor problem was knowing which folder(s) needed to be included on revision. In most common development environments, only the source, custom libraries and configuration files are worthy of inclusion to the repository.
Plan:
The first thing I noticed about the initial DueDateBoostrap program was its lack of "friendly" error handling. It occurred to me that possibly building an ErrorLogger for this system would be most beneficial not only for this project but also for others. My goal from here on was simple, build an error logger that simply takes in at least one (supported) option and deal with auditing the errors. Although my approach is simple, it does the job with a few left out features. This error logging system lacks the ability to audit with level of warning types. In future enhancements I would like to incorporate a more sophisticated level system that weighs the severity of an error/exception.

Conclusion:
I enjoyed taking the time to get my hands on a new project again. Here I can step back and think about new ideas that I have yet to explore and hopefully, along the way make changes to better the application as a whole. Its always important to know that there are some ideas that work for certain situations and some ideas that work for others. I have learned from the past that large projects like these amounts to the overall effort and not only the ability of one individual. I believe that in this high collaborative society, esp. for software engineers, that we are only as strong as our weakest link. Learning to accept the fact that you are not the lone programmer these days will better you for the actual development setting. The setting is ever changing, people come and go, while many of us still have to learn to adapt rapidly. This project proved to be quite a learning experience for both me and my team member.

Stack on Google's Project Hosting + SVN (Part 2)

Premise:
In this posting I will attempt to build upon where I left off from my previous entry regarding SVN and Google's Project Hosting (GPH). My experience portrayed here will both reflect the ease and comfortableness of using SVN in a group oriented setting.

Experience:
My project is currently being hosted by Google's Project Hosting and all members of the project have SVN command privileges to add, delete, or commit changes. Likewise, I could also do a checkout of someone else's project using the same command ("svn checkout...") under "Source" tab in GPH. If I've been given membership to this person's main code line, then I'll also have full write access to their master repository. This means that the changes I make locally will reflect on the live repository once I perform a "svn commit -m...". I will attempt this very concept on a group member's project. After checking out the source from the member's repository, I am given a local copy of the project. Before attempting to run the program or make any changes of my own, I ran "Ant" to assure the code that I've just checked in, integrates well without error. If errors do occur, then I'll either have to notify the discussion group or make the changes myself.
Currently the project appears to be at a solid state without any conflicts or obvious errors. The actual error didn't occur until I used Eclipse and Ant simultaneously to execute tests and run verifications. It turns out that the given build.xml file provided by this project conflicts with Eclipse's class build directory path. Eclipse assumes ownership over a folder while Ant secretly writes to that directly after each build. Eclipse complains by throwing a "ClassNotFoundException". The easiest way to fix this is to create a folder in the project directory called "bin" and modify the default classpath in Eclipse to point to this directory. You can make this slight modification in Eclipse by going to "Project>Properties", under "Source" tab and change "Default output folder". At this stage, the current changes I make here are done locally and will not yet affect the main code line until I've committed. Now I will verify if my changes work for this issue by simply replicating the steps which brought on the error. Once everything seems to work with both Ant and Eclipse, then it should be safe to commit my changes. But before committing my changes, I'll first do an "svn update" to see if the project has changed since the time I was working on my fixes. This should be done before and after every commit to ensure that your code integrates well with other project member's code and to relieve later efforts of having to resolve more difficult conflicts.
Systematic procedures to keep integrity of code in-sync with master repository:

• svn update - brings your current local copy up-to-date with the current revision
If conflicts need to be merged, then resolve these problems before continuing on.
• Make your changes on your local machine
• Run Ant's build tools to verify your code changes.
• svn update
• svn status - to see if the files you've modified are correctly marked with 'M'
• svn commit -m "some informative message about the changes" - post changes to master codeline
• Continue the process again.

Other tidbits:
You can run the command, "svn log" to view the history of revisions made on the current project. Notice the last revision is listed first and its corresponding comments regarding the changes are made right below it. Also note that the optional commands like "svn log", "svn diff -r M:N filename", or etc. can be done easily on GPH's site. Its much more convenient and easy to read compared to using terminal. In my opinion, the most useful operation is svn's diff command. GPH provides a complete visual, including a side-by-side view of both files under different revisions. I only wish that GPH had a feature to produce patches along with having the ability to do diff's. Patches would be pretty useful for situations when you do not have full control over the master repository. So rolling out your own set of "diff" changes to fix a general project issue would be useful when you need to send it to a user group or mailing list to explain about your changes. From there your patches can be determined by the owners or other members, as to whether or not your patch should be applied to the main system. GPH solves the problem of communicating with members of the group project (via Google Groups), but does not make it easy for current members of the project to apply these patches/changes.

Conclusion:
Subversion is a code-management repository that enables you to keep your source code stored on a remote server (in this case Google's Project Hosting Server) that can be accessed by multiple members/users. Subversion makes collaborating with multiple users a breeze because users can checkout copies of the source code to their local machines, make edits, and then send the changes back to the SVN server. At that point, team members can update their local copies with all the team's changes. SVN manages the changes made to each file so that you aren't automatically overwriting your co-worker's work! Even if you are the sole developer, storing your project source under Subversion is a great way to keep a remote "backup" of your code in case your development machine is compromised or if you fall victim to a situation resulting in data loss.

Stack on Google's Project Hosting + SVN

Premise:
The purpose of this post is to experience the process of building your own source code management system by using both a live server (Google's Project Hosting) and Subversion (SVN). Source code management enables project teams to effectively share and collaborate with each other while keeping track of their development process. A part of the construction process consists of using good foundation practice tools, such as SVN to help ease the pain of manual code tracking and tasking.

Setup:
1. Install Subversion
You'll need to have a copy of Subversion installed on your local machine. If you're running Mac OSX or Linux/Unix, then that'll be all you'll need. You can simply download the binaries/source straight from Subversion's site, here. Otherwise, If you're a Windows user, then I would recommend installing the latest version of CollabNet's TortoiseSVN. TortoiseSVN is an easy to use GUI version of SVN for Windows that can be interfaced (in version control) to support any filesystem item (files, folders, etc). Although the subsequent steps follow the basis of a Linux based platform, the process of login in and setting up the first checkout, add, commit, and update are conceptually the same.
2. Create a Google Project
Google's Project Hosting (GPH) is a service which enables team-project members to collaborate in an effective development environment. GPH provides project workspaces with easy to use UI member controls, issue tracking, mailing group lists (via Google groups), and most importantly Subversion. Although you are not restricted to use Google's Project Hosting, I would recommend it if you want to quickly get something up and running for your co-workers or the world to see. If your intentions are to use some other advanced remote server, then you'll have to look elsewhere for that. I'm simply portraying the use of one possible solution. If you'd rather take another approach, then here are some of my recommendations on how to approach the same level of likeness to Google's: 1) Get and install Subversion, 2) Install Apache on your server, 3) Configure Subversion to work with SSL and Apache, and 4) Install Trac - issue/task management software. The more detailed instructions can be found here.
3. Initialize: Revision 1
To get started with GPH, you're required to obtain/already own a Google account (as with anything from Google). Next, redirect yourself to GPH's site here and click on "create a new project." This will instantly create a project and provide you the necessary parameters needed to describe your project. Once all the forms are out of the way, navigate over to the "Source" tab. Here, you'll be presented by Google's nicely suggested commands to run SVN. You could now just copy and paste the following into a terminal window.
"svn checkout https://stack-anthonydu.googlecode.com/svn/trunk/ stack-anthonydu --username anthony.m.du"
Quick explanation of these commands:

• "svn checkout" - pulls the SVN tree structure (svn>(tags)/(branches)/(trunk)) from the specified server. This will only need to be done once.
• "https://.../svn/trunk/" - url of source code. It can be a remote or local server
• "stack-anthonydu" - project folder name
• "--username anthony.m.du" - google account username for server access.

Once you hit return, the GPH server will verify your credentials with a pre-generated key. You may generate a new one or use the one pre-generated key under the "googlecode.com password" link. After you successfully checkout, SVN will display a message noting your very first revision. This marks the end of possibly the hardest part of setting up your repository.
4. Adding & Committing files
Now switch to your project directory. Notice that their is a hidden ".svn" folder in your directory which stores information about the current state of your repository. The next logical step is to add files to your main code line. Use "svn status" to see which files have not yet been added or added but not yet committed. The files that have been added will be prefixed with the letter 'A', and one's that have not been added will be prefixed with '?'. Unfortunately there is no easy way to recursively add all files and subdirectories using a terminal/command line. You might think that a simple svn add * would do the trick, but this command is NOT recursive. So I looked around for a quick and dirty script that will simply add all newly, non-committed files to svn. Here's the script in its most rawest form: "svn status | grep "^\?" | awk '{print $2}' | xargs svn add"
I have made this into a command of my own to simply be called anywhere called "svnadd." This can be done by saving the one-liner script into a file and storing it into the "/usr/bin/" directory (only under Unix/Linux platforms).
For a list of commands provided by svn, you may simply type "svn help". Now that you've made changes to your repository by adding files, the next step is to commit your changes to the main repository. This can be simply done with the command "svn commit", followed by a meaningful message describing the changes you've made. In this initial process, you can name it along the lines of "project initialization."
Transmitting file data .............................................
Committed revision 2.
This marks the end of Revision 2.

I have applied these instructions to my first GPH, called "stack-anthonydu" (same project from previous blog posts). This project can be accessed, viewed/downloaded, but not modified by public users. The master repository goes unchanged unless you own or are a member of the project. Here is a link to my stack-anthonydu in all its glory.

Conclusion:
I learned that version control should be part of your daily-standard arsenal. After this brief introduction to configuring and getting a feel for Subversion commands, I was quick to appreciate its vast potential for sharing and publishing source code. In my next blog post I'll further explain my experiences using my newly committed stack project.

Stack Overflow - Programmer's Q & A Haven

What is Stack Overflow?
Stack Overflow is a web application written by collaborative programmers for programmers with programming questions. The site initially requires nothing when you first visit, but to be able to gain further editing privileges, then you must sign-in using a new or existing OpenID account. OpenID is a one-stop sign-in or sign-up account used to help ease the pain of remembering login names for different sites. Upon successfully registering for the site, you’ll be immediately given the ability to edit your personal account info, easily search for a question or answer (either by tags or textual search), and post questions or answers. Soon, after you make your first post, moderators, or users who have gained high reputation will rate the prevalence of your post given the appropriateness and popularity. You’ll be given points depending on these factors, which then will correspond to your abilities on the site. If you gain higher status in your reputation, then the site awards you the ability to edit yours and other’s posts almost like a wiki. At times you might feel that Stack Overflow is giving you a hard time, but it does it for good reasons. The most popular attraction of this site is its strict rules on postings. Since posters must stay on topic, the site’s reputation and purpose gets further established in the community. The simplicity and specificity gives Stack Overflow a name in the community of programmers as a “programming FAQ” site, rather than a sub-category amongst other contending search topics. Also, it helps eliminate the trouble of irrelevant or duplicate questions. In my opinion, this proves to be a good strategy than most other social networking sites that deal with a conglomerate set of topics, like Digg or SlashDot. Its unique moderation and rating system makes it an ideal example for newer social networking sites to follow.

What were my Stack Overflow experiences?
Stack Overflow is a "programmer's haven" for Q & A's. I have posted one question regarding the goods and bads of using more than one level nesting in Ruby on Rails. Hopefully, the question will get picked up by the community and I'll get an answer that will suit my needs.
Here's a direct link to the question: http://stackoverflow.com/questions/164520/to-nest-or-not-to-nest

Overall, I think the service will be a good addition for programmer related sites. I've definitely given this a good rating on my StumbleUpon and bookmarked it for future visits.

Stack + Emma + JUnit

Premise:
In this experiment I'll take a look at testing techniques and programming coverage using both JUnit and Emma. All programs in this experiment will be edited and tested using Eclipse with built-in integration of JUnit's plugin. Emma is an open source Java coverage tool that integrates well with Ant. I will be running Emma and building my subsequent tests from command prompt (using Ant), while making changes that reflect improving coverage in Eclipse. The program below is the remanence of my previous "Stack" post. I will be using the Stack program as the basis of running my unit tests.

Improving Coverage:
The goal of this experiment is to improve code line coverage. Emma makes this very easy to accomplish by using a few commands from my previous setup of Ant. After executing the following build command: "ant -f emma.build.xml," Emma conveniently gives quantified metrics for class, method, block and line converage. Emma is also nice enough to provide an html (emma/coverage.html) summary describing the covered, partially covered and uncovered code line executions. It also indicates the file and highlights each line with a neat color scheme: green - fully covered, yellow - partially covered and red - uncovered.
Initial Emma Coverage Metrics:

• class: 100% (3/3)
• method: 73% (8/11)
• block: 69% (65/94)
• line: 75% (15/20)

Analysis of uncovered lines are specified by filename, percentage of coverage and methods containing non-executed code lines:

1. ClearStack.java, (50%), getTop() & isEmpty()
2. Stack.java, (79%), toString() & top()

I proceeded to first improve the most trivial test cases indicated by Emma for files Stack.java and ClearStack.java. I was able to raise the line-level coverage to 99.8%. However, I was stuck at a partially uncovered item in the isEmpty() method of the ClearStack class. In this case Emma has no further input other than to say that this is a line that needs more tests. It took me a while to notice that the isEmpty method needed to thoroughly be tested for both true and false cases, when initially I only had one. This minimal unit test boosted my line-level status to 100% and thus achieving what looks to be good code, right? Unfortunately, I was drawn to notice a couple flawed attributes that adhere from my tests and the confluence of using Emma as a fully trustworthy tool. Although my first intentions of this experiment is to improve code coverage, I've also come to realize Emma's vita flaw that could potentially separate good testers from the bad. I've also notice how Emma's tricks the programmer into thinking about only achieving code coverage, rather than helping the coder gain greater insight into their code analysis. Even at 100% coverage, my tests are not completely tested in terms of its context. For example, one unit test required that I needed to test the toString() method in the Stack class. In my TestStack class, I did the toString() method test by simply asserting the expected output while having prior knowledge of what toString() must express.
Here's my test case: assertEquals("Testing stack toString", "[Stack []]", stack.toString());
I found that this test builds upon the assumption that stack.elements works. I needed to conclude to myself that this statement truely executes without flaw, so I tested the List's toString method.
2nd test case: assertEquals("Testing list toString", "[]", stack.elements.toString());
It turns out that my curiousity only led me to remember that Collections have a default format of outputing elements in a form of an array-like string, enclosed with square-brackets. The point of this assertion was to distinguish the mindset of good and bad testers. Good being the ones who take it a further step by objectively analyzing the hidden points being made by their program, and bad ones who leave after the 100% coverage which may or may not be truely 100% valid.
Overall, Emma is still a great tool that should be used continuously in pre-development to production stages. However, I would not recommend using Emma in the middle of a project, unless the task is minimally affected by the program as a whole.

Here's a link to the final Stack code: stack-anthony.m.du-6.0.930.zip

Conclusion:
I learned the importance of building my programs using some sort of coverage tool. Although, coverage tools evidently determines if our code is tested for certain conditions, it limits us from determining the thorough aspects of what our program is truly expressing in terms of context. Upon questioning the effectiveness of converage tools, such as Emma, I've come to realize that there is no better tool than human analysis. Sure we can ease the pain of manually checking whether or not our code is executing like it should, but we must also take into account for its lack of human ingenuity and influence. Since we wrote the program using our own patterns and processes, we should also rely on our instinct when it comes to assessing our own work. I feel that the usage of Emma should go hand-in-hand in the beginning stages of developing test cases. Again, the concept of incremental programming should be exercised for assuring the quality of your code. As for future use, I would recommend using the integrated plugin called: EclEmma for Eclipse. It works very much like Emma. It also gives visual highlights of what code has been tested or "covered," as well as the usual quantified metrics provided after every build.

Automated vs Manual QA (CodeRuler)

Overview:
Simply compare the validity of human QA and automated QA tools on previous CodeRuler project.

Running Ant + CodeRuler:
QA Tool: QA Violation (Comments)

CheckStyle: Line Type Javadoc comment is missing an @author tag. (JavaDoc issue)
CheckStyle: Line contains a tab character. (Format issue)
CheckStyle: Unused @param tag for 'int'. (Logic issue)
CheckStyle: Expected @param tag for ‘x’ or ‘y’ (Logic issue)
CheckStyle: Line is longer than 100 characters. (Format issue)
CheckStyle: Type Javadoc comment is missing an @author tag. (JavaDoc issue)
CheckStyle: 'static' modifier out of order with the JLS suggestions. (Logic issue)
CheckStyle: Missing a Javadoc comment. (JavaDoc issue)
CheckStyle: '}' should be alone on a line. (Format issue)
CheckStyle: First sentence should end with a period. (Format issue)
**CheckStyle errors: 101152 errors across 10 files

PMD: Avoid if (x != y) ..; else ..;
PMD: Avoid unnecessary comparisons in boolean expressions
PMD: Private field 'castle' could be made final; it is only initialized in the declaration or constructor.
PMD: Avoid using if statements without curly braces
PMD: Avoid using implementation types like 'ArrayList'; use the interface instead
PMD: Substitute calls to size() == 0 (or size() != 0) with calls to isEmpty()
PMD: These nested if statements could be combined
PMD: Document empty constructor
PMD: An empty method in an abstract class should be abstract instead
PMD: Return an empty array rather than null.
PMD: Document empty method
PMD: All methods are static. Consider using Singleton instead. Alternatively, you could add a private constructor or make the class abstract to silence this warning.
PMD: Return an empty array rather than null.
**PMD errors: 60 errors across 3 files

FindBugs: 439 lines of code analyzed, in 11 classes, in 2 packages.
**FindBugs errors: 0 errors and 0 warnings!

Conclusion:
Obviously, this would have been a nightmare without some kind of automated tool system for checking styles and coding rules. Upon receiving the numerous style errors, these QA tools give a descriptive audit of exactly when and where each error occurs. Using QA tools helps our code exist in one or many standards depending on the situation. After seeing what a mess things could be when we go against the standard, I'm now leaning more toward coding in a much safer and higher quality standard environment.

Software Quality Assurance

Overview:
Quality Assurance (QA) of code is the basis of source code analysis development. The quintessential part of distributing your code with high quality production standards is that it ensures a good product (reliable, maintainable, and manageable) and enables other organizations to easily pickup your software.

System Requirements:

• Java: JDK 1.4 or higher
• OS: Windows, Linux, Unix, or Mac OS X

QA Tools:

• Ant - "Anther Neat Tool" used to assist programmers in scripting custom automated build process similar to that of "make" for C/C++.
• CheckStyle - used to help ensure that your Java code adheres to a set of coding standards. (static analysis)
• PMD - used to enforce certain coding rules. (static analysis)
  
• FindBugs - is another static analysis tool that examines your class or JAR files looking for potential problems by matching your bytecodes against a list of bug patterns.
• JUnit - used to incrementally assert test conditions/statements that presumably matches an expected outcome.

Installation:
The installation process is quite simple once you get the hang of it. Below is a quick walk through of installing the above QA tools on both Mac OS X/Linux platforms:

Mac OS X (Unix) / Linux Users:
** the instructions below can also be tailored for Linux users too, but just with slight differences.

Fortunately for mac users, Java and Ant come pre-installed with the latest version of Mac OS X (10.5.4). All I ended up doing was export the path variables (JAVA_HOME & ANT_HOME) to point to the installed locations on the system. *If you need to install it manually, then you can consult to instructions here.

• $ cd
• $ emacs .profile
• edit file by adding the following:
• export JAVA_HOME="/Library/Java/Home"
• export ANT_HOME="/usr/share/ant"
• save and close the file
• $ source .profile
• you can also check to see if your environment variables have been added by typing:
• $ env

Once you get the hang of just installing one tool, the rest follow the same methodology for both Unix and Linux platforms. Below is a generalized version of installing and updating the environment variables

• Download and extract: qa_tool (e.g. checkstyle, pmd, findbugs, etc.)
• $ cd downloads/
• $ wget qa_tool_url
  
• $ unzip qa_tool_version.zip -d /usr/local
• Update environment variables
• $ cd
• emacs .profile
• add the following env variables
• export QA_TOOL_HOME="/usr/local/qa_tool"
• save and close file
• $ source .profile
  

Stack + QA:
The program called stack will help us test our newly installed QA tools.
Setup project:

1. Download project source code here: stack.zip
2. Extract source project into development directory (workspace in Eclipse)
3. Open Eclipse and select File>Import, General>Existing Projects into Workspace, select root directory by browsing to where the stack source was extracted, and click on Finish.
4. Right-click on stack project, Refactor>Rename>stack-(username)
5. Edit build.xml file by renaming the project name to match "stack-(username)"
   

Running Ant + QA tools:
At the command prompt/terminal, switch to the location of your stack project folder and run the following Ant commands:

• ant clean compile
• ant -f checkstyle.build.xml
• ant -f dist.build.xml
• ant -f findbugs.build.xml
• ant -f javadoc.build.xml
• ant -f junit.build.xml
• ant -f pmd.build.xml
• ant -f verify.build.xml

The last statement should render a BUILD FAILED plus something similar:
:stack-anthony.m.du directory
$ ant -f verify.build.xml
Buildfile: verify.build.xml

clean:
[delete] Deleting directory /Users/admin/Develop/java/stack-anthony.m.du/build

compile:
[mkdir] Created dir: /Users/admin/Develop/java/stack-anthony.m.du/build/classes
[javac] Compiling 5 source files to /Users/admin/Develop/java/stack-anthony.m.du/build/classes

junit.tool:
[mkdir] Created dir: /Users/admin/Develop/java/stack-anthony.m.du/build/junit
[junit] Running edu.hawaii.stack.TestClearStack
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.071 sec
[junit] Running edu.hawaii.stack.TestStack
[junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 0.031 sec

BUILD FAILED
/Users/admin/Develop/java/stack-anthony.m.du/junit.build.xml:18: Test edu.hawaii.stack.TestStack failed

Stack + QA tool fixes:
**description of errors can be found in build directory under tool directory subfolder in html format.
JUnit errors:
junit.framework.AssertionFailedError: Testing stack top of three expected same:<3> was not:<1>
at edu.hawaii.stack.TestStack.testNormalOperation(TestStack.java:37)

**edited top() logic in file: Stack.java

Checkstyle errors:
[checkstyle] /Users/admin/Develop/java/stack-anthony.m.du/src/edu/hawaii/stack/Stack.java:52: Expected an @return tag.
[checkstyle] /Users/admin/Develop/java/stack-anthony.m.du/src/edu/hawaii/stack/Stack.java:79:3: '{' should be on the previous line.

**made fixes to those minor style checks in file: Stack.java

PMD errors:
5 total:
Private field 'one' could be made final; it is only initialized in the declaration
... again for both 'two' and 'three'
**added final to all three declaration statements in file: TestClearStack.java

Avoid using implementation types like 'ArrayList'; use the interface instead
**replaced with List interface declaration in file: Stack.java

Consider simply returning the value vs storing it in local variable 'obj'
**replaced with returning top value instead of storing in file: Stack.java

FindBugs errors:
Method new edu.hawaii.stack.TestClearStack() invokes inefficient new Integer(int) constructor; use Integer.valueOf(int) instead
Method new edu.hawaii.stack.TestStack() invokes inefficient new Integer(int) constructor; use Integer.valueOf(int) instead
**replaced declaration with "Integer.valueOf(int)" in file: TestClearStack.java & TestStack.java

Final Stack + Ant Run:
amd:stack-anthony.m.du admin$ ant -f verify.build.xml
Buildfile: verify.build.xml

clean:
[delete] Deleting directory /Users/admin/Develop/java/stack-anthony.m.du/build

compile:
[mkdir] Created dir: /Users/admin/Develop/java/stack-anthony.m.du/build/classes
[javac] Compiling 5 source files to /Users/admin/Develop/java/stack-anthony.m.du/build/classes

junit.tool:
[mkdir] Created dir: /Users/admin/Develop/java/stack-anthony.m.du/build/junit
[junit] Running edu.hawaii.stack.TestClearStack
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.105 sec
[junit] Running edu.hawaii.stack.TestStack
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.015 sec

checkstyle.tool:
[mkdir] Created dir: /Users/admin/Develop/java/stack-anthony.m.du/build/checkstyle
[checkstyle] Running Checkstyle 5.0-beta01 on 5 files

pmd.tool:
[mkdir] Created dir: /Users/admin/Develop/java/stack-anthony.m.du/build/pmd
[echo] PMD found ${pmd.failure.count} problem(s).

findbugs.tool:
[mkdir] Created dir: /Users/admin/Develop/java/stack-anthony.m.du/build/findbugs
[findbugs] Executing findbugs from ant task
[findbugs] Running FindBugs...
[findbugs] Error: The path /usr/share/findbugs-1.3.5/plugin does not seem to be a directory!
[findbugs] No FindBugs plugins could be loaded
[findbugs] Output saved to /Users/admin/Develop/java/stack-anthony.m.du/build/findbugs/findbugs.xml

emma.tool:
[mkdir] Created dir: /Users/admin/Develop/java/stack-anthony.m.du/build/emma
[instr] processing instrumentation path ...
[instr] instrumentation path processed in 90 ms
[instr] [3 class(es) instrumented, 0 resource(s) copied]
[instr] metadata merged into [/Users/admin/Develop/java/stack-anthony.m.du/build/emma/metadata.emma] {in 2 ms}
[junit] Running edu.hawaii.stack.TestClearStack
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.261 sec
[junit] Output:
[junit] EMMA: collecting runtime coverage data ...
[junit]
[junit] Running edu.hawaii.stack.TestStack
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.254 sec
[junit] Output:
[junit] EMMA: collecting runtime coverage data ...
[junit]
[report] processing input files ...
[report] 2 file(s) read and merged in 7 ms
[report] writing [xml] report to [/Users/admin/Develop/java/stack-anthony.m.du/build/emma/coverage.xml] ...
[report] writing [html] report to [/Users/admin/Develop/java/stack-anthony.m.du/build/emma/coverage.html] ...
[delete] Deleting directory /Users/admin/Develop/java/stack-anthony.m.du/build/classes

emma.echo:
[xslt] Processing /Users/admin/Develop/java/stack-anthony.m.du/build/emma/coverage.xml to /Users/admin/Develop/java/stack-anthony.m.du/build/emma/coverage.brief.txt
[xslt] Loading stylesheet /Users/admin/Develop/java/stack-anthony.m.du/lib/emma/echo.emma.xsl
[concat] Emma Coverage summary
[concat] class: 100% (3/3)
[concat] method: 73% (8/11)
[concat] block: 69% (65/94)
[concat] line: 75% (15/20)

verify:

BUILD SUCCESSFUL
Total time: 7 seconds

**Here's a link to the new build: stack-anthony.m.du-6.0.921.zip

Conclusion:
I learned that functional software products must also have high quality attributes to pass being labeled a legitimate software product. Besides meeting your company's functional requirements, your software must also verify with quality assurance guidelines. In doing so, software products will be more reliable, maintainable, manageable and even distributed in a timely matter with functionality. In another exploration, I would like to find ways to quantify the quality assurance of source code. The elements of benchmarking your QA is most likely related to process aspects and operations. Perhaps, we could benchmark the number of errors or unsuccessful builds using Ant or some other tool.

CodeRuler Review

First look:

I was assigned to review Daniel and Erin's CodeRuler implementation. In the first trial their ruler outperformed against the migrate ruler by a large margin. Unfortunately they weren't too successful against either smart-splitter or gang-up rulers. In both trials (smart and gang) their ruler performed the same way by killing all enemy peasants before capturing its castle. But by the time they captured the enemy's castle, their first castle gets occupied by knights of the opposing team. While they attempt to re-capture their first castle, no peasants are being produced in their second castle. The opposing ruler keeps producing knights after every turn, thus covering and protecting its castle. Their ruler consistantly battles the knights, but unsuccessfully captures back their first castle. For every battle lost between their knights and the opposing team, the enemy gains battle points and they lose precious points from not claiming land. Although the end result is not fully desired, there is much to learn from this implementation.

Review:

Besides what the CodeRuler strategy implies, this review is based on the creators' coding style and class logic structure.

JavaDocs:

The provided JavaDocs for this MyRuler is quite clear and concise. The method summary is descriptive and easy to follow. You can almost get the gist of what each method is intended to do without looking at any code. However, I would like to see a better introduction to their MyRuler class by describing more of their strategy rather than listing the resulting trial matches.

Class logic and structure:

The overall class structure is simple and easy to follow. Each method provides a readable description that matches the code segments. Method references are nicely encapsulated and broken down into smaller reusable routines. I found it much easier to read each function due to the fact that this group followed good naming conventions. As for the effectiveness of their code, I would have to disagree with one routine called: buildUnits (line # 231). I found this method to be less effective in the process of replicating more peasants at each captured castle. This method stops the production of peasants when the team has only one aquired castle. Due to this limitation, other methods relating to the movement of peasants, such as: optimizePeasantMove (line #413) was wasted during gameplay.

Coding style:

Below are some minor code style violations within the MyRuler class. Most of these errors can be set to fix automatically (format) or easily avoided the next time around.

File	Lines	Violations	Comments
MyRuler	93-94, 100-101, 143-144, *	EJS - 5, ICS-SE-Eclipse-2	opening brace should be at end of the line that introduced the block.
MyRuler	87, 88, 175, *	ICS-SE-Eclipse-2	Some lines exceed the 100 column max limit.
MyRuler	155, 159, 177, *	EJS – 7	Increase white spaces by placing them between keywords (if, for, while, switch) and parenthesis or braces to better readability of code.
MyRuler	4	ICS-SE-Java-2	Must explicitly specify each class import rather than using a wildcard “*”.
MyRuler	130, 133, 146, *	ICS-SE-Java-10	Needs to pluralize names of collection objects.
MyRuler	96, 117, 168, *	EJS - 49	Omit subject in method description to reduce redundancy.

Final thoughts:

After reviewing the coding style and class structure of this CodeRuler implementation, I learned that documenting your code is just as hard as implementing it. Maybe a better approach to programming would be to self document first and then extract code statements and method functions from that as you build the application. The all important methodologies of "Top-Down" programming would be an essential skill to practice for even the simplest of classes or methods. This should be applied also to the way we program and document our work. Overall, Daniel and Erin did a good job and I hope they take away as much from this as I did.

Here's a link back to each member's blog. There you can also find a link to their source code.

• Daniel Arakaki
• Erin Kim

Lessons learned from Code Ruler

Overview: CodeRuler is a Java programming game based on the Eclipse IDE. It is intended for testing skills in Java programming as well as strategic reasoning. The basic idea of the game is to capture other opponents' castles and claim the most land resources. In doing so, the player with the highest score wins the game!

MyRuler Group Members:

• Ancheta, John
• Okada, Creighton

Strategy Outline:

Break knights and peasants into smaller groups with specific objectives.

InsideCastleGuards

• they will stay and move around inside the castle.
  
• they will capture any opponent knight inside the castle.

OutsideCastleGuards

• they will attempt to capture any knight that moves too close to the castle.
  
• they will roam around the castle area capturing opponents peasants.
  
• they are the first line of defense against opponent knights.

KnightCastleInvaders

• they will attempt to capture opponents' castle.
  
• they will attempt capture of opponents' peasants that they encounter, but they will not chase them.
  
• they will avoid contact with opponents' knights.

LandCapturePeasants

• they will attempt to capture unoccupied land and opponents' land.
  
• they will attempt to avoid capture from opponents' knight.

KnightDistractionPeasants

• they will attempt to get opponents' knight to chase them, leading the opponents' knight away from the castle.

Sample Game Results:

	MyRuler vs Migrate	MyRuler vs Gang-up	MyRuler vs Split-up
1	503-36	455-117	412-182
2	540-32	455-140	513-119
3	462-40	370-156	466-234

Lessons learned:

• Eclipse became a good companion for this project. I consider it an all-purpose IDE and has well lived up to its expectations for all backgrounds of developers. The built-in JavaDocs generator has proven to give ease and painless professional documentation.
  
• Java still surprises me with its wealth of runtime exceptions. Here's one that I found annoying and difficult to fix: "ConcurrentModificationException" - impermissible for one thread to modify a Collection while another thread is iterating over it.
  
• I learned that large projects such as this requires a large amount of effort from each person. It was difficult to have long continuous meetings due to our conflicting schedules, but we found other ways (email or online-chat) to communicate efficiently. 

Improvements:

My first recommendation for future projects that require the service of more than just one person would be to use some kind of source code version control like SVN or GIT. It seems cleaner to do it under version control rather than passing back and forth document copies through email, which requires you or your team member to patch-up manually. I also would recommend a task tracker such as Edgewall's Trac for project management software. A handy project or task management software (preferably open source) would be helpful for keeping track of project goals, tasks and progress.

Reflection:

I enjoyed taking the time to experience programming this Java based strategy game. It proved to be well worth my time and a great learning experience for myself and my group members.

CodeRuler source: du-okada-ancheta.zip