DueDates: Part Deux Point Zero

Introduction
Reformulate DueDates 1.2 into a working web application using Wicket.

DueDates and Wicket
The team was able to meet all benchmarks of the system including an extra credit assignment which required DueDates 2.0 access more libraries.

For DueDates 2.0 I was able to contribute: ConfigurationManager.java, TestConfigurationManager.java, HomePage.java, HomePage.html, HomePage.css, AlertsPage.java, AlertsPage.html, AlertsPage.css, DueDatesMail.java, TestDueDatesMail.java, the project's HomePage and UserWiki.

There was disagreement over the DueDatesMail and how it sends an email to the user. The issue with JavaMail is the lack of a dedicated SMTP server. Depending on the internet provider the user may not be able to send an email through its SMTP system. However, the DueDates system can send email via the University of Hawaii mail server. But limiting the application to a single mailer hurts the program's flexibility. We agreed to allow the system to have a versatile mailer taking the chance it may fail for a user. If the email issue becomes a problem we are prepared to switch to a dedicated mailing system. I guess the best resolution is to have your own SMTP server.

Team Akala
Team Akala is made up of Arthur Shum, Jeho Jung, Daniel Tian, and myself. With more developers in a team finding time to have regular face to face meetings is a challenge. However, with Team Akala I am not sure if certain members did not have the time to meet or did not care about the project.

Only Arthur and myself met on six out of the ten working days and in those sessions we talked about where each person was in system, worked on code, and helped each other with coding issues. Jeho met with the group on two occasions and Daniel met with Arthur and I for two hours one day. I found in the previous versions of DueDates, Team Purple's success was due to the regular face to face meetings. However, in version 2.0 there seem to be less of a team effort.

Arthur blazed through the project, at one point I asked him to take the night off so Jeho and I could get some commits into the system. If you look at the charts from the Hackystat system it is clear that a couple group members did more work than others. With regards to communication I would chat with Arthur about the code through g-chat and face to face meetings. There was one day where Arthur, Daniel Tian, and I performed triple programming to get ConfigurationManager.java to work.

Kudos to Arthur for doing a lot of the heavy lifting however, I thought more of the code should have been dispersed evenly. But really hats off to Arthur he got the team into a position so that we did not have to program our tails off at the last minute.

Note: Because Arthur reorganized the package structure of DueDates 2.0, he will have a high number of commits on 12/7/2008.

Akala Development Time
The chart below represents the time spent coding in Eclipse, I am the pink line.

Note: The development time is accurate as of 12/7/2008. DueDates 2.0 was cleared for released on 12/7/2008.

Akala Commits
The chart below represents the number of commits for each team member, I am the green line.

Note: Arthur got a head start on the project and committed his version of DueDates 1.2, plus the support files for Jaxb. Explaining why Arthur had such a high amount of commits early in the development.

Akala Builds
The chart below represents the number of builds each developer invoked I am the green line.

Note: There is an error with Jeho's Hackystat sensor, he did have builds in the development.

Issues
I thought working with this system was much more difficult because of working with Wicket. My experience with Wicket is limited so it was a challenge to get meaningful code committed. I attempted to work on a progress indicator for an extra credit requirement however, it was difficult to find information and what the search engines returned was confusing. The Wicket API documentation is in my opinion lacking in detail. Trying to find out what a class or method does took some time to understand. A combination of using the Wicket in Action book, documentation and examples from the Wicket website made the coding process somewhat bearable.

Development Tools
Having worked with Hackystat and Hudson with DueDates 1.2 I do not think there was anything new to learn or discover. With this group there was less obsessing about coverage and there seem to be a focus on getting the system working first. I thought having colors represent the task portion of the project was a good idea. Group members can see the development, build, and test time was spent for this project, plus the group would know if at least two members were involved with coding. Having used Hudson with three projects, knowing the continuous integration tool is overseeing the build provides some confidence, where there is a watchful eye on the system.

Akala's Health and Status


Note: Green numbers and lines mean healthy, yellow means needs attention, red means sickness. The increase in coupling was due to the addition of several files at the last minute.

Conclusion
For DueDates 2.0, I thought I made a significant contribution to the system I got my hands dirty with a little CSS and Wicket. I should have been more assertive in getting Arthur to slowdown with the coding or do more pair programming. That way the development and build counts would be more even. I would like more of my code to make final version of the build. So for ICS 414 I intend to have my code be in the final build of whatever project we get assigned.

Wicket: An Introduction to WebApp building

Introduction
Wicket is a framework that enables Java and html to communicate with each other so robust websites operate without hassle.

My Distribution

Wicket
I have never done a full blown design of a website before this assignment. I know a few html tags, enough to link web pages, build a table, and adjust fonts. After working with Wicket it seems a html novice like myself can still develop a functioning. As an assignment I had to create a web page that implemented a stack. The page displayed three buttons and a form to take in a string. The page could push, pop, and clear a stack. Every time an action is performed on the stack/web page a table will display each push, pop, or clear.

One of the things I appreciate about Wicket is the amount of html is needed for the page.

<html>
<head><title>stack-wicket-danielma</title></head>
<body>
<form wicket:id="form">
<p> Stack Input <input wicket:id="stackInput" type="text"/></p>
<p><input wicket:id ="push" type="submit" value="push"/></p>
<p><input wicket:id="pop" type="submit" value="pop"/></p>
<p><input wicket:id="clear" type="submit" value="clear"/></p>
<table border = "1">
<div wicket:id="StackOfObjects">
<tr>
<td wicket:id="stuff">[stuff]</td>
</tr>
</div>
</table>
</form>
</body>
</html>

The html code along with approximately five hundred lines java of code can create the following.


Conclusion
My approach to the assignment should have been more agressive which left me scrambling at the last minute. I started working on the task on Monday however, I was working on small things like adding a button. What I should have was add a button and get the button to do something. I could not perform a sufficient test on stack-wicket-danielma. due to problems with the build files. My build.xml and junit.build.xml was not set up properly so I kept getting "cannot find html markup" errors for StackIndex.java, which ate up significant amount of time. Learning Wicket does take some time to figure out. However, once you understand how Wicket joins html and Java together creating good looking, fully functional web pages should be no problem.

ICS Industry Day: Trying to Get a Job

On Thursday November 20, 2008, the ICS department at UH Manoa saw presentations from seven computing firms that are based or have offices here in Honolulu. The seven companies Referentia, Oceanit, Camber, Ikayzo, DataHouse, Alion, and Concentris presented information about their respective companies. Six of the seven companies had projects with the government or military, Ikayzo's focus seems to be in social networking.

I thought all of the businesses did a fine job of presenting their organization's operations. Although, in my estimation, Referentia did the best job of focusing their presentation towards the students. Referentia's representative Aaron Ito, a former ICS student at UH Manoa pointed out what their current intern is working on along with how the company likes to develop its interns and employees. I hope the companies in attendance took note and make the same type of pitch as Referentia at next semester's Industry Day.

The most interesting tidbit I got from the presentations was the acceptance failure or I should say the tolerance of failing. These companies want to see how their interns deal with failure and in software engineering failure is as certain as death and taxes. I was amused by tools that Alion, Referentia, and DataHouse use in their software development: Ant, Junit, Subversion, etc. The same tools that are being used in Professor Johnson's software engineering class. I felt some comfort in knowing I will have the ability to work in the industry.

I was disappointed by the department's turnout, there is close to a thousand students in ICS yet less than fifty showed up. The only way to get more companies involved is if more students show up to events like Industry Day. Oh, by the way, I saw Professor Johnson in attendance where was the rest of the faculty? The representatives were throwing out a lot acronyms and intials: AWS, SQS, EXT JS, etc. stuff I have never heard before it would be nice to know about the tools before we get out into the working world.

I gave out two resumes one to Alion Science and one to Referentia the projects they were working on peaked my interest. The guys from Alion worked on Modeling and Simulation although they could not mention the client, my guess is its the military. Referentia had a cool project which displayed a 3-dimensional map of a battlefield, neat stuff. I really liked what Referentia had to offer, they seem to have an active interest in developing the skills of their interns by letting them work on real projects and pushing them into becoming solid candidates for the workforce.

I felt I got a lot information from the presentations at Industry Day and it was time well spent. I know tools the firms use for development and should not be afraid of not being able to do work. I got to hand out my resume to two companies that I would like to intern at and maybe work for in the future.

DueDates: The Next Episode part 1.2

Introduction
The coding continues for Team Purple as we add more functionality to DueDates. In addition to the new tasks we get more experience working with software ICU and having HackyStat keep tabs on our development of DueDates 1.2.

DueDates 1.2 and JavaMail
Team Purple needed to fix some issues with version 1.1. DueDates needed to be more abstract and there was a problem with the naming of the project. DueDates 1.2 requires the application to send an email notice and check when a book is due to be returned. I took on the task of implementing JavaMail into our system. Using SMTP, messages will be sent to the user when an item is due with twenty four hours. The difficulty with JavaMail is finding a mail server that does not require a password with every transaction. Unfortunately, Gmail requires authentication with each email sent regardless if it is sent within system. The University of Hawaii mail system allows messages to be sent within the network however, the user is required to have an account with hawaii.edu.
Working with JavaMail was a challenge I had to learn how email is structured and delivered. I spent several days going over SMTP, RFC-2821, SMTP using Gmail, JavaMail API, and example code. DueDates 1.2 is not capable of taking in a password for email so the user must use a SMTP server that does not require authentication for every message sent.
With each build DueDates gains more functionality but as the system grows the coding process is a little more complicated. However, with version 1.2 the process was straightforward compared to DueDates 1.1. I am not sure if it was due to the improvement in abstraction, I definitely had an easier time working with the code in this assignment.

Team Purple
When it comes to group programming the best method to accomplish the assigned task is to meet everyday to discuss and work on the code. John, Marilee, and I met for at least one hour for three days. With each meeting the group would talk about how their assigned task and decide on which direction the team should move. Team Purple has met on regular basis with each version of DueDates and we have reached every bench mark which I believe is related to consistently meeting and working on the project.

CI and ICU
In version 1.1, the team already got a taste of Continuous Integration or CI, which is a handy tool or nusisance. Depending on how you feel about having something constantly looking over your shoulder. Another tool in our arsenal for code design is Professor Johnson's Hackystat system which is used for software ICU. In my previous blog I mentioned the postives and negatives of software ICU, where the tendency would be to focus on getting coverage numbers into the green.

With DueDates 1.2 my theory was confirmed by my team's obsession with the coverage and I am just as guilty of being fixated on getting our numbers into the green. I appreciate how Hackystat monitors the progress of a design. However, I think a project's robustness and functionality should be the focus rather than getting numbers into the green.

Conclusion
I feel I am improving as a programmer with each version. With DueDates 1.2 much of my code and tests are making it into the release. But I know I have a long way to go in becoming a developer that can code a DueDates system on my own. To improve as a designer I need take on more coding responsibility and take on the tougher aspects of the design.

SoftwareI ICU: Monitor your application's health

Introduction
The teams continue their engineering of DueDates with the introduction of Hackystat a new software engineering tool that monitors a project's vital statistics. With Hackystat Team Purple will be able to monitor key vital signs during its implementation of version 1.2.

Software ICU
Being able to track the progression of a project is a great benefit to a development team. Seeing the vitals of a system as it is being developed, will in the end, be robust, fully functional, and written in an efficient manner.
For DueDates, the development teams will have their projects monitored by Hackystat. The Hackystat system, developed by Professor Johnson, keeps track of a project's development by attaching sensors to Eclipse, Ant, and Hudson. The sensors, embedded into the user's system keeps track of the programmer's implementation of the application and sends a signal to Hackystat. With a web browser the development team can see the healthiness or unhealthiness of a project as its being developed.

Issues with Hackystat
The problems I was having with Hackystat was not with the system itself but with setting up the environment variables. Because some of the dependencies were quite long it was easy to miss a typo. When trying perform a build command with Ant I was getting an error saying the class could not be located which was due to a bad enviroment variable that was mislabeled. A troubleshooting page would be a nice addition to the Hackystat website. A lot of time would be saved from trying to track down a problem.

The Patient's condition
Team Purple's condition as of this writing is in satisfactory condition. Our coverage is in the yellow which is borderline the team can improve this area by writing more unit tests which should increase our coverage to the green. However, it will be difficult to get full coverage because of the private methods. It is nice to see that our code is not overly complex and the coupling is good. My enthusiasm over the project's current state is tempered by the fact that we have not started our modifications to the code for version 1.2. For now I will appreciate none of the vitals are red and we are close to %90> coverage.

Conclusion
The class is fortunate to be able to get hands on experience with Professor Johnson's Hackystat system. I can see how Hackystat is both an effective tool and detriment to the team. Because seeing a red number can be a killer to a team's confidence. The strength of Hackystat is being able to see the code is fully functioning, it is not too complex, and each class is not overly dependent on each other, as well as other aspects of the project. Tracking the vitals of a system will prove to be beneficial with the end result of the application.

Code review: Learning from others

Introduction
DueDates version 1.1 gets reviewed by the other development teams in class. Team Purple was assigned to review Team Blue's DueDates and assess their version 1.1 code and documentation. The class, also was assigned to evaluate Google Project Hosting's code review tool because of issues from the previous Code Review.

Team Blue's code
Arthur and Erin did some nice things with their code like the user interface that I mentioned in the review of version 1.1. Another method I liked was their Comparator method, which handles the data structure that is used to store the book's due date and information, it also does sorting of values. I modification I thought needed to be done was to handle the due date as a Date type rather than a String. Because strings sorted lexicographically using the character's Unicode which could cause a problem when sorting 11/11/2008 and 4/4/2008 the sort will place 11/11/2008 ahead 4/4/2008.

/**
 * Returns a Comparator object that allows BorrowedItem objects to be compared according to their
 * due dates. The comparator is defined as an anonymous nested class.
 *
 * @return Comparator A comparator to compare BorrowedItem objects according to their due dates.
 */
public static final Comparator dueDateComparator = new Comparator() {
  public int compare(BorrowedItem item1, BorrowedItem item2) {
    int comp = (item1.yyyymmddDueDate).compareTo(item2.yyyymmddDueDate);
    if (comp != 0) {
      return comp;
    }
    // Compare the rest of the fields so that two BorrowedItem objects compare to zero
    // if and only if all their fields are equal.
    String item1Info = item1.libraryName.concat(item1.formattedResults);
    String item2Info = item2.libraryName.concat(item2.formattedResults);
    comp = item1Info.compareTo(item2Info);
    return comp;
  }
};

One area I thought Team Blue could use improvement was with their unit tests. A programmer needs to know how a system will respond to invalid values such as null or inputting an integer when a string was expected. A thorough test will catch most errors and bugs before a user gets to wreak havoc on an application. I suggested to Team Blue to test their Comparator to make sure it sorts what they expect to sort. Another test that should be performed is to make sure exceptions are thrown at the right time. Also, kudos to Team Blue for their homepage, job well done.

Team Purple's review
Team Violet was assigned to review our system and honestly I expected to get blasted in the review, I am always expecting the worst with reviews, but Anthony and Vincent were not too critical. Vincent did point out the expandability issue which does concern me a great deal. Adding more libraries to DueDates will make Team Purple's version one huge class. However, I thought Anthony's assessment of our code was insightful and will assist us in developing a more robust system. The review of Team Purple's system showed deficiencies in our code that will problematic when performing a build. Both Vincent and Anthony had problems with verifying our DueDates due to a JUnit error. Vincent could not successfully import Team Purple's code into Eclipse because of problems with HttpUnit, I think its a build path issue.

Emma coverage tool:
[concat] Emma Coverage summary
[concat] class:   67%  (2/3)
[concat] method:  44%  (15/34)
[concat] block:   18%  (156/874)
[concat] line:    18%  (36/199)

The Emma coverage does not concern me because version 1.1 does require more testing which should improve the coverage. Overall, Team Violet gave us valuable information that helps us improve the system.

Google Project Hosting
In the review of DueDate version 1.0, some flaws of Google's Code Review tool were discovered during the assessment of other DueDates implementations. Google had made some modifications to the Code Reviewer but I think it needs more improvement because it is difficult to locate a review if the reviewer does not provide a link. Although, someone doing an assessment should notify the development team tof a pending review, sometimes the person may forget to send a notice or assume the analysis would be easily found. Perhaps a function, where upon publishing a review a notice is sent to the team.

Conclusion
I am hoping that my review of Team Blue's system was insightful so they can make improvements to their code. Unless I hear differently from the development teams I review I am not sure of what kind of modifications can be done with how I look at a system. But I suppose one area I can improve upon is with explaining how a team should modify their program. I feel that I am not giving a complete picture of what I am trying to convey.

DueDates: Suffering and more coding

Introduction
We continue our work with DueDates and making the system fully operational. For this evolution of development the group needed to implement changes from the peer review, add a sorting mechanism, include the Hawaii State Library, and test all implementations.


Team Purple
As a group the team went through the same process as in version 1.o we felt meeting every weekday for at least a hour was most effective. Meeting on weekends is difficult for the team because of family and work issues. At every meeting the team would talk about what needed to be done with the project. Usually John would think up something new or find a way to modify the code. We did our best to assign the work as evenly as possible. Although some tasks with DueDates 1.1 were more difficult than others. For version 1.1 John wanted me to take the lead role however, due to the complexity of the project and time constraints I had to hand the reins back to John. The approach in which Team Purple is using in my opinion works quite well. My feeling is the more time developers spending working together more the system improves.

1.0 Versus 1.1
Starting a project from scratch is much easier because you do not have that excess baggage of code that needs attending. After the code review and performing some modifications of our own. The project became much more difficult to adjust because we still had to fix or modify the code and still maintain the integrity of the previous version. I found John and myself making constant revisions to the unit tests after discovering modifications to DueDates.java was not working the way it was intended.

The Code
We were able to meet all of the specifications for this weeks assignments however, I think the system is not as functional compared to other teams. DueDates does not have an user interface which is due to time constraints we wanted to make sure version 1.1 met all of the specifications before making additions.

The Issues
One of the biggest hurdles in DueDates was the sort option, when the user invoked -sort[due date or library] the library books should sort in the order of the due date or library. Initially I was going to implement some kind of sorting algorithm. However, Professor Johnson suggested using the Collections.sort method built into the Java library. I went with a Comparable interface that takes in the date, book information, and library code. But the issue with using the Comparable interface is overriding the equals() and hashCode() methods. I have never done an override of the equals or hashCode methods and it took a while to figure out what I needed to do and also John lent his expertise in the matter.

@Override
  public boolean equals(Object obj) {
    
    if (obj instanceof BookInfoRecord) {
      BookInfoRecord pair = (BookInfoRecord) obj;
      return pair.getDueDate().equals(this.dateDue) && pair.getBookTitle().equals(this.bookTitle);
    }
    return false;
  }
  
  /**
   * Overriding default hashCode. 
   * 
   * @return Returning a unique BookInfoRecord hashCode.
   */
  @Override
  public int hashCode() {
    return this.dateDue.hashCode() + this.bookTitle.hashCode();
  }

Continuous Integration
For this week's version of DueDates we were introduced to Continuous Integration using Hudson. The teams got to park their project on Professor Johnson's server. If you have never used Hudson or Continuous Integration, it is like a pet cat or dog if you do something it does not like it will let you know, which can be a letdown. The development team has to always remember to verify before committing and building. Not verifying before a commit should be considered a mortal sin because you hate to see a red dot and rain clouds, which means your current build failed.
Keeping continuous watch on a project's condition is good and bad. The good thing about Continuous Integration is that everyone involved with the system is always aware of its current condition. The team knows the condition of the build, who caused the failure of the build, and why it failed. The bad thing about Continuous Integration, in my opinion is that unnecessary need to keep the sun up. A developer can become obsessed with striving for a blue dot and the sun that they lose focus on the project.

Improvements/Conclusion
To improve my effectiveness, I have to take on more responsibility in the development. With version 1.1 more of my code made it into the distributed version. However, I still would like more lines code making into the next distribution and the only way to that is to continue programming.
I feel with each week I am improving as a programmer I am starting to see it in my code and problem solving. But I still have a long road in front of me I am no where near the likes of John or Ronn.

Code review: The Good, The Bad, The Ugly

Introduction
First off I needed to come up with clever title for the blog and I thought The Good, the Bad, and the Ugly was appropriate for reviewing code. I would like to mention that in no way is the title a reflection of my fellow classmates' programs. I will however, point out what I thought was specifically good, what was generally bad, and make a general statement about what was ugly.

When it comes to programming I am still in that in-between phase of, I know enough code to write a simple application and but do not have enough experience to tackle a full project. Because of my experience, for the review, I could only comment on portions of code I was familiar with and used minimal examples to show what I thought was proper or made more sense in my estimation.

The Good
Overall, the code I saw had good ideas the kind of stuff I wish we implemented in our DueDates. The Blue Team: Arthur and Erin's program did some cool things I especially like their interface which prompts the user to choose a library.



The Green Team: Jeho and Yasu concatenated the values from the respective website which will help to present the information in a meaningful way.

String bookInfo = "";
bookInfo = bookInfo.concat(String.format(format, "Due Dates", "Book Information" ));
for (int i = 1; i < bookinfo =" bookInfo.concat(String.format(format,table.getCellAsText(i,">

The Orange team: Aric and Daniel used an Abstract class and method which I thought was interesting and something I was not thinking of when we were going through the preliminaries of the first DueDates assignment. Using Abstract should be able to give the group the ability to reuse the code when needing to add more libraries to the application.

The Bad
I did not see code that was troubling however, I saw bad documentation and a lack of testing. One group had only one test case and a what looked like a test in the constructor of the unit test. Another group had zero test cases, other than running the code they could not check for valid or invalid values. I saw a class that had one proper Javadoc for a method.

The Ugly
Again, I did not see bothersome code except for trying to read the code to the left (sorry Aric and Daniel), its an implementation of one of their classes with html tags filling every line. My eyes hurt after looking at the file. The code was not bad it was just hard to read as you can see.




Team Purple's code
For the most part the reviewers: John, Arthur, Vincent, Ronn, Daniel, and Yasu liked our implementation with a few of them making suggestions on how to improve our code. One thing I would like to implement is an interface for an user to enter information instead of having to do it through the command line. The team needs to improve the way DueDates retrieves information from webpage with a table. I agree with Ronn's assessment of abstraction however, that should be no problem when we need to make the adjustment in future versions. We do have a nagging xbeans.jar issue that causes an error with JUnit and the verify which needs to be fixed before we can start the next the phase of the project.

Issues with the review tool
I had problems getting the comment window the code review. I was attempting to open the window by clicking on the line number when I needed to be clicking on the line of code. That bit of brain-lock prevented me from reviewing the code for a day. A couple gripes about Google's code review besides having to click a line of code to enact the comment window. With my comments only one set appeared in one of the group's code, the other teams' reviews were stuck in another page so it was difficult to know if the comments were saved. In case I need to make a change to a review it is complicated to find the comments I made to a file.

My Thoughts
Doing code review is helpful by improving the system that is being reviewed and the reviewer gets to see how other programmers are implementing their programs. By looking at people's code a developer may see a whole another way of doing things such as Team Orange's use of Abstract. So for a future project a developer can take advantage of the knowledge they gained by looking at other programmer's code.

Conclusion
We were told to spend a hour on each team's system which was barely enough time to go through the documentation, verification, and examination of the application. Because DueDates is still in its infancy the project is small enough to inspect and still understand how the application is suppose to work. Other than my small mishap with the comment portion of the code review. The only improvement that I see with reviewing code is spending more time examining programs. Also, getting the developement team and the reviewer together to go over the comments, if possible. Such a meeting maybe helpful for both the reviewer and the programmer.

DueDates

Introduction
Finally we were given an assignment that exposes to the class to software engineering. The task for week nine and for the rest of semester is to develop an open source project. DueDates is an application that helps keep track of borrowed books and should evolve into a rental tracker. In this week's blog installment I will talk about the overall development, the team, the issues I encountered, and my opinion of the assignment.







Screen shot of Team Purple's project site.

The distribution, executable, and Javadoc
DueDates source code
DueDates jar file
DueDates Java Docs

The Team
For week nine's development evolution I am assigned to Team Purple which is made up of myself, John Ancheta, and Marilee Flestado. John having the most experience out of the group took the lead role, assigning tasks, choosing the development scheme, and overseeing the entire project. The group met Monday through Friday for at least one hour to mull over code and figure out which issues needed attention. Each time the team met we were able to make meaningful additions to the project whether it was through documentation or coding. With three team members we performed trio programming with John being the conductor. I felt that the process was efficient and should not be altered.

The Development
We decided to deal with only the Univeristy of Hawaii at Manoa library website. The feeling was to keep the project simple, fullfill the requirements first and make additions to the project if there was time. The most challenging aspect of the code was dealing with command line input for the unit test and JUnit build file. John and I investigated Ant's and Java's documentation for a solution. After a day of searching John found an answer to the problem. Java's System class can handle standard input allowing the unit test to take in arguments from the command line.

 /** Instance variable, instantiated to take in a command line argument. */
private static final String "variable" = System.getProperties().getProperty("args");

/** Instance variable, instantiated to take in a command line argument. */
private static final String "variable" = System.getProperties().getProperty("args"); 

To deal with the JUnit build file so the command line arguments could be passed in when invoking ant -f, we made use of sysproperty.

<sysproperty key="<arg1>" value="${<arg1>}"/>
<sysproperty key="<arg2>" value="${<arg2>}"/>

Another interesting aspect about DueDates is working with screen scraping and getting data from a website. The backbone of DueDates is the task of retrieving salient information from a library or rental internet site. To handle the parsing of data we are using HttpUnit an open source website-unit tester. HttpUnit is a nifty tool that allows the developer to check on links, tables, frames, etc.
DueDates is written in Java so it will run on any OS supported by the platform. The nice thing about DueDates is it's open source not only is it free but any Java developer can make a contribution to the project. The big thing I realized about working with open source development is the vast amount tools that is available for free.

The Pitfalls
Being an absolute beginner in project development I felt overwhelmed with the entire process. For starters, I forgot that I needed to update the local directory because I proceeded to commit my version of the code to the repository overwriting Marilee's files.

The Updates page is a mess I was continually making updates to the repository without checking the Issues page and not inputting the issue that I was modifying. After making a commit I would swear at myself for not listing the issue in the comment area thus making the issue un-trackable. After several warnings from John about losing points I finally got the hang of working with SVN client and made doubly sure an issue is listed in the commit.



My Thoughts
The highlights of this assignment, we are working on a true project which is open source and putting to use the tools we learned in the first eight weeks of class. The lowlights of the exercise, to be honest I was quite fearful of the project. After looking at the specifications I was not sure with where to start or what needed to be done. Thankfully John was able to take the lead and guide the team through the process. After learning from John's development experience, I feel confident that I can be a more contributing factor in the stage of the project.

Conclusion
I am excited about this project and hopeful that the class can create a fully functional DueDates application. With each week I am learning something new which adds to my programming experience. I also, see that I do not have to be frighten of the next task because I have the tools in front of me to complete the work.

Configuration Management lab

Introduction
On Wednesday October 6, 2008, the class got more practice working with configuration management and Google Projects. The assignment also involved more pair programming as we performed updates and commits to the respective sites.

The lab
The assignment involved more pair programming, because I had wrapped up the first configuration management tasks over the weekend I was partnered with Arthur Shum, who also finished the exercise. The lab had Arthur and I doing similar tasks as the previous configuration mangement assignment. Since our project sites were already set up it was just a matter of adding each other as a member, downloading and modifying the code. After doing a brief scan through Arthur's code the best thing to do was modify the JavaDocs. The point of the exercise was to get acquainted with Google Projects Hosting and Subversion, not hack our partner's stack implementation. Arthur added the .classpath and .project he also modified the verify.build.xml in stack-arakaki project.
Made an interesting discovery with Eclipse while working on the lab. When importing a project into Eclipse, the sub-directory being worked on does not transfer to the application's workspace. So there is no need to change directories when verifying and committing a project.See the screen shots below to get an example of Google Project Hosting in action.


A screen shot of SmartSVN with an update of stack-arakaki.


A snippet of changes to Arthur's TestClearStack.java, notice the JavaDocs.


Arthur's stack project update page after a commit.


A posted update from Arthur's stack discussion group, notice the changes made to the JavaDocs.


A snippet of a posted update from Daniel's stack discussion group, Arthur added .classpath, .project, and modified the verify.build.xml to the project.

My thoughts
Before taking ICS 413 and working with a configuration manager any alteration of source code was either overwritten or saved along with ten other copies of the same file that took up space on the hard drive. If I was programming a project with a partner the code would be exchanged via email and I assume their method of file management was about as good as mine. So having a tool like Google Project Hosting and Subversion is a real treat because I would hate having to deal with a project that has fifty different classes and over ten thousand lines of code. Keeping track of all of those files without configuration managment is dangerous and complicated. Files could get lost, overwritten, or not updated.
The programs I have worked thus far have been small and easy to manage so the need for configuration management was unnecessary. However, as projects become more complicated I appreciate that we have access to Google Project Hosting and Subversion so we can focus on the programming.

Conclusion
No frustrations with this assignment, things went smoothly and without complications. It was a good exercise in the sense we got more practice with updating, modifying, and committing source files using Subversion.

Configuration Management

Introduction
This week's assignment is a continuation of the class' introduction to the tools of software development. To manage the source code throughout the coding phase we are going to use Google Project Hosting which uses Subversion for configuration management. The exercise involved the installation of a SVN client, modification of source code from Professor Johnson's stack project, and creation of our own Google Project page.

Install
Download the latest version of SmartSVN, yes, I have a Mac and enjoy using the machine's UNIX box. Did not experience any problems with retrieving and installing SmartSVN. The installation portion of the assignment gave me the least amount of frustration.

Modify code from Google project
Retrieving and making changes to source code required some effort on my part. SmartSVN, in my opinion is not intuitive, it took a few minutes to figure out how to connect to ICS 413's repository. The area I had difficulty was with setting up the repository profile. I had issues with locating the menu for adding profiles (see the screen shot below), maybe I should have looked at the tutorial first. After a moment of swearing at the computer, I was able to connect and download all the necessary files to make a changes to the stack's source code. Did not find anything meaningful to alter within either the stack implementation or the unit test. The best thing I could come up with was altering the JavaDoc comments in one of the methods. Upon checking for a successful commit, I found the update section of Google Project Hosting a nice feature. I like that everyone can see who did what to the project. That way you can shoot an email to someone for a job well done or lambast them for screwing up the class.


Screen shot of the update page from stack-johnson.


Screen shot of the trunk from stack-johnson.


Screen shot of the changes I made to stack-johnson.


Screen shot of SmartSVN with the profile manager.

Create a new Google project
Setting up a new Google project seemed like an easy task, adjusting the page and adding members to the site. What should have been a twenty to thirty minute task took over an hour. I was trying to commit my stack-arakaki directory into the repository and was repeatedly denied access. SmartSVN, was attempting to open the project site using the http protocol. After poking around SmartSVN, I discovered when attempting a commit the application was using the wrong setting from the repository profile for my Google Project Hosting site. SmartSVN was trying to call up the site using http. After more searching I found the relocate command and was able to change the protocol to https. It was frustrating to spend so much time on such a simple task.

My Thoughts
Configuration management is not a new topic for me, in ICS 212 (program structure), Ravi Narayan introduced the class to source code management on UNIX using SCCS or Source Code Configuration System. Using SCCS on UNIX is not fun especially when you are bad at keeping track of which version of the source code x.x was updated the previous night. Or a programmer may decide to go with a previous version but has no idea which file holds the code that is needed, which will lead to ineffieciency. So having a GUI configuration manager like SmartSVN is sweet, no need to guess where a paticular version of code is ever again.
With regards to figuring out the issues with protocol and profile I just poked around SmartSVN until I found a solution. Did not feel the need to jump on Google and do a search. Despite being frustrated with portions of the assignment I still find this exercise as well as other tasks thus far, to be valuable. I think it is important to have your patience tested every once in a while for two reasons 1) to keep you humble and 2) to appreciate the small victories when learning something new.

Conclusion
Configuration management through SVN is a necessary tool in software development even when the coding team consists of one programmer. The need to keep track of the constant updates made to a project without the by-products of locking or clobbering is crucial to developers. As will save time and headache allowing the programmers to spend more time in developing code instead of managing code.

JUnit Lab

Introduction
The JUnit Lab exercise had us working with JUnit but more importantly understanding how testing is not bulletproof. The assignment also had the class working in pairs, offering more experience with pair programming, I was partnered with Tyler Wolff.

The Distribution
Stack-JUnit-Lab-Arakaki

The Task
For the main portion of the assignment Tyler and I needed to add a bug to the stack implementation from the Testing assignment. The bug had to be added in such a way that the coverage was still at one hundred percent. We also had to write an additional JUnit test case that exposed the bug and failed, but the coverage had to remain at one hundred percent.
Tyler and I added a bug to the getTop method in the ClearStack class. The original getTop method returns the top of the stack. In the modified method, getTop returns a pop of the stack. Returning a pop of a stack can cause issues with data retrieval especially when the intent was to peek at what is on top of the stack not retrieve the item at the top.







Once Tyler and I figured out a bug to introduce that maintained full coverage. We came up with up a test that calls getTop twice which returned an expected failure.



In both cases where JUnit implemented and ignored the bug test, Emma returned one hundred percent coverage. Here I thought Emma would have returned less than full coverage. But it seems Emma only checks if the method is being invoked.

The other part of the task was pair programming and team problem solving. I am always apprehensive about coding with another person. Because I am never sure if the other person can operate in a professional manner. Also, I question my abilities. Can I hold up my end of the bargain? But there was no problem with this assignment I had worked with Tyler in a previous in class lab and I found that we were an efficient team. Tyler and I clearly communicated our insights to each other so that we were able to finish much of the exercise in class.

My Thoughts
After meeting the requirements of the assignment I had come to realization that certain testing tools are not bulletproof. An innocent mistake like returning a pop instead of top can lead to horrible consequences. If a lazy developer sees that Emma is returning full coverage they could misinterpret that to mean that code is fine and is ready for deployment. Also, with JUnit, if that additional test had not been implemented no one would have caught the returning of pop bug in getTop. JUnit would have green lined the test and allowed the code to move onto the next stage of development.

Conclusion
Really the lesson here is to keep track of all changes to the code. A small adjustment can lead to big mistakes which is costly in time and money. Again code testing tools are not bulletproof, bugs can crawl through and wreak havoc. So a programmer needs to be vigilant and not be fooled by one hundred percent coverage. Because as Tyler and I just proved, full coverage plus a passing JUnit test does not mean error free code!

Testing

Introduction
For the Testing assignment, we needed to make improvements to the Stack implementation. The goal of this exercise was get to acquainted with Emma and JUnit. The task also had the class making minor adjustments to test cases and programming as a team. For this assignment I reached out through the class Google-group to search for a programming partner and John Ancheta was available to do some code fixing.

The Distribution
stack-arakaki

Working with Emma
This was my first time working with Emma and found it to be a nifty tool. I appreciate the application is letting me know which parts of the program are being neglected. However, the stack implementation contains four to five methods which seems rather trivial for a program like Emma. It would be interesting to see when a Java application has two hundred plus methods. I think when an application has so many moving parts you need Emma to check which method is being utilized.

Working with JUnit
As I have said in past blogs I do have limited experience with JUnit. So it did not take long for me to bang out a few test cases. I think I was able to help John with some of the JUnit method calls. I am a big fan of JUnit, I find writing test cases for an application only strengthens my understanding of how the tested program works. If I need to maintain the application over time I already know the program works and can quickly make the necessary adjustments. The difficulty with JUnit is trying to come up with what kind of tests should be implemented. In the past I was taught, test any method that is longer than one line and with the stack project there were several methods that more than one line of code. I know that this is only an introduction to JUnit I expect we will be writing more useful test cases in the coming future.

Pair Programming
After much thought I have come to realization that with pair programming the tasks seem to take less time to complete. John and I were able to reach 100 percent coverage in an hour. In the interest of time I suggested that we code at the same time. We perused Emma searching for which methods were not being invoked, after finding the necessary information we divvied up the tasks. From my point of view John and I worked well together if either one of us encountered a problem we discussed the issue and suggested a solution, which is how all pair programming sessions should operate.

My thoughts
For the Testing assignment I found pair programming an enjoyable experience. Although I suspect that not all coding partners are going to be like John. As for what I was feeling throughout this assignment, I felt a little fear when going through specifications for the exercise. The apprehension stemmed from my inexperience with Emma and the fear of not being able to recall JUnit code. But as I sat down and started working on the assignment the fear went away, found myself enjoying the activity of checking and fixing the stack implementation.

Conclusion
A programmer should never put all of their faith into programs like Emma. Clean and robust code is what we should all strive after but humans do make mistakes so it is to our advantage that we have development tools like Emma and JUnit. Thus far all of the assignments have been real treats to work with as I learn something new with each exercise. The Testing task exposed John and I to pair programming an area of software development that must be learned because as future programmers we need to start learning how to work within a team.

Stack Overflow

For extra credit Professor Johnson pointed the class to a website called StackOverflow. The StackOverflow website appears to be gathering place for programmers of all types: OOP, scripting, database, etc. The purpose of StackOverflow seems to be a help desk of sorts where coding questions get asked and answered.

As someone who is striving to someday be a professional programmer StackOverflow seems a little intimidating. There are coders asking questions for which I have no answer because I lack the background and expertise. However, I was able to come up with a question that has been bugging me since ICS 211. Basically, I wanted to know how to improve my design skill i.e., I am tired of programming from the hip, how can I be a better programmer? Within hours of posting the question I received eight answers from people who I assume are professional programmers. The replies were pretty much in the same vein think before coding, understand the specifications, experience helps, etc. Not that I think the answers were lame and did not get anything out of the post. The responses were similar but each reply shared a pearl of wisdom which I hope to apply in the near future.

After searching for question which I thought I could suitably answer. I found myself thinking should I reply to the question? Because from what I gathered all of the answers were from industry folk who have done some serious coding. My biggest project to date was a pseudo database from ICS 311. So I felt like a little kid amongst the grown ups. But I figure what is the harm in throwing in my answer? Hopefully, I will not get flamed for such a pitiful response.

By the way my question on design improvement received five votes which promoted me to scholar, whatever that means.

automated QA vs. manual QA

Introduction
For this assignment the class revisited their code from CodeRuler and implemented Ant, Checkstyle, Findbugs, JUnit, and PMD on the CodeRuler program. The goal of the exercise was to get an understanding of human versus machine quality assurance.

The task
I was partnered with Tyler Wolff and he was able to work on his stack while I got to work on MyRuler.java. After getting a feel for invoking the various builds with Checkstyle, Findbugs, JUnit, and PMD in the stack assignment. Performing quality assurance on MyRuler.java went a lot smoother than checking the stack assignment. After invoking the tools on MyRuler.java it was discovered that the creators of CodeRuler did not follow established coding conventions. Checkstyle returned numerous tab errors from the classes built by the CodeRuler makers. Regarding MyRuler.java, Checkstyle returned six errors which ranged from a missing period in Javadocs to using an asterisk in import statements. PMD returned fours errors that range from changing to an arrayList to labeling the switch statement. Findbugs did not find errors in MyRuler.java.

In this assignment the comparison of human error checking to machine error checking revealed how the two look at code. First, the computer will not consider the overall strategy of MyRuler.java, it could care less about how the knights attack the peasants first. When quality assurance tools run through the code. The only bits and pieces the tools care about are how the curly braces being in the right place and do the Javadocs have periods at the end of the sentence. When a human looks at the code they do care about the knights attacking peasants and strategy implementation. A human also cares about the curly brace being in the right place, because such nuances goes to readability. If a human cannot read the code how can they maintain the application? But when it comes to a co-worker or classmate examining code that spans over a thousand lines they might miss that @return statement. Having both a human and machine performing quality assurance on a program can only lead to readable-functional applications. The human can catch strategy flaws while the computer will catch style and coding defects.

Conclusion
A person is really good at catching overall design deficiencies however, they are mediocre at best when it comes to picking out coding errors i.e., bugs, class usage, improper declarations, etc. Machines are better at finding improper declarations and making suggestions as to how something should be declared.

Stack

Introduction
The stack assignment had the class implementing various quality assurance tools for software engineering in preparation for future assignments and beyond. Personally, the exercise had me working with environment variables in UNIX and writing a batch file, two things I have never done before so I would say this was a challenging exercise.

The Code
stack-arakaki

Task 1
Downloading Ant, Checkstyle, Findbugs, JUnit, and PMD was the easy part of task one. Setting the environment variables for all of the tools was a time consuming process because it was my first time at setting the environment variables in bash. What took a lot of time was from searching the web on how to set the path and implement the batch file. Although the experience of writing the path on bash was valuable I think I messed up the path for X11 (yes, I have a Mac) because I cannot start Open Office on my machine. The next step of task one, the moment of truth to see if I set the environment variables correctly. Invoking all of the tools on a stack filled with several errors. It was quite fulfilling, after spending several hours tinkering with the batch file, to see the correct output from the various tools.

Task 2
The second part of the assignment was less difficult compared to task one which involved copying and renaming stack. Also, a repeating of the invocation from task one using Ant, Checkstyle, Findbugs, JUnit, and PMD.

Task 3
Part three of the assignment was the most enjoyable, witnessing the tools in action and making the necessary adjustments to the code. I found PMD and JUnit the most powerful of the four tools in this task. PMD, was especially useful at making suggestions to which methods or classes would work better in the application. No java programmer can write effective code without JUnit. Authoring a proper and complete unit test will save a programmer many hours of grief of having to hunt down buggy code. Checkstyle and findbugs are decent tools that helps with the coding process but were not as powerful PMD or JUnit.

Conclusion
I really enjoyed this assignment, I learned how to write a batch file and make changes to the enviroment variable in bash, something I found valuable. I gained knowledge with five new coding assurance tools Ant, Checkstyle, Findbugs, JUnit, and PMD. By applying the five applications I was able to fix a stack implementation that filled was with errors and coding standard violations. So the stack exercise was beneficial and a good learning experience.

CoderRuler Review

Introduction
The CodeRuler review assignment give us an opportunity to analyze code, from the CodeRuler assignment that was written by other students in the class. The review also, exposes the class to detecting and understanding violations of the course's coding conventions.

Team Reviewed and Link to their code
du-okada-ancheta

Links to their blogs
John Ancheta
Anthony Du
Creighton Okada

About du-okada-ancheta's code
The du-okada-ancheta's code is well organized despite having three different authors. The method structure within the MyRuler class is laid out in a systematic way. The way methods are lined up it seems to follow du-okada-ancheta's strategy of having enemy knights chase runaway peasants. The methods appear to perform each task efficiently as possible. I especially like the knight protecting the castle, a nice addition to the assignment, very cool.

JavaDocs
The team of du-okada-ancheta's MyRuler.java lacked a simple statement that summarizes the code's operations. However, the team did provide bullet points for what each object is suppose to do as the program runs. Several methods lacked information on parameters and return type.

The Code
Overall, the coding was well done but there were some conventions that were missed. The instance variables should have a new line separating each declaration. Also, '}' should have its own line where some conditional statements had an 'else/ else if' preceding a '}'. There were some naming convention errors, some variables lacked appropriate titles, instance variables and methods calls were missing 'this'. Other than the issues with naming and coding conventions, the code was readable and easy to follow.

Findings

File	Lines	Violation	Comments
MyRuler.java	183,185,210,*	EJS-5	Indent nested code, each '}' should have its own line.
MyRuler.java	230,356,358,*	EJS-7	White space, new line after each new instance variable.
MyRuler.java	105,136,137,*	EJS-9	Variables need a meaningful name.
MyRuler.java	139,141,144,*	EJS-29	Need to add 'this' before calling instance variables and methods
MyRuler.java	7	EJS-41	Need a summary to describe the application in JavaDocs.
MyRuler.java	99	EJS-46	Need version number and date in class comments in JavaDocs.
MyRuler.java	200,201,284,*	EJS-54	Need comments for parameters in JavaDocs.
MyRuler.java	353,564,766	EJS-46	Author's name in class comments only.

Conclusion
Aside from the naming and format conventions, the code of du-okada-ancheta's was well written. The team of du-okada-ancheta had a decent strategy which has them beating the toughest pre-made opponents in the game. After looking at du-okada-ancheta's MyRuler.java I wish I could re-code and have my methods do a better job at conquering the opponent.

The CodeRuler review was a decent task which made me realize some of the coding and strategic errors I made while putting together my team's version of MyRuler.java. So for the next coding assignment I will do a better job at implementing error free code.

Lessons learned from Code Ruler

The members of the group who implemented the code. Erin Kim and Daniel Arakaki, Erin tackled the peasants while Daniel handled the knights. Erin did a fine job with coding the movement of the pawns. A link to the copy of the code. http://www2.hawaii.edu/~danielma/ics413/dan.m.arakaki-erinjuneilkim.zip Results

Team	1	2	3
dan.m.arakaki-erinjuneilkim vs Migrate Ruler	508 - 14	582 - 16	390 - 4
dan.m.arakaki-erinjuneilkim vs Gang Up Ruler	135 - 436	140 - 433	182 - 399
dan.m.arakaki-erinjuneilkim vs Split Up Ruler	120 - 405	136 - 392	116 - 417

What did you learn about Eclipse I have been using Eclipse since ICS 211, so I already understand how powerful an IDE Eclipse is for developing Java applications. For ICS 413, I installed the latest version of Eclipse for Mac and found the editor to be no different than the version I used on my PC. I noticed there is a plugin called Subclipse which is a tool for souce code control. When I have the time I will implement Subclipse so I can get a handle on the changes I make to my code. With code control I will not have to worry about overwriting a version that I did not mean to change. What did you learn about CodeRuler I found CodeRuler to be a nice warm up for the semester. I wish we had more time so I can have my code defeat some of tougher opponents in the game. CodeRuler did open my eyes, made me realize that I have much to learn about Java and programming in general. What did you learn about Java For CodeRuler, I relied on the material that I was familiar with and did not venture very far into new territory. Java has an expansive library and I did not take advantage of the tools that were available. The reason why I did not implement things like Collections and List was that I found it easier to work a simple array to deal with the knights, peasants, castles, etc. Taking the path of least resistance is a habit that I need to break if I want to become a stronger developer. Also, I am already familiar with javadocs after having to properly document code in Mike Paulding's ICS 211 course. Mike would have the class write javadocs in the appropriate format or else major points were taken off. What did you learn about working with another person. In a professional setting you do not get to choose your co-workers and in the case of the CodeRuler exercise my first partner was chosen for me. I will not point out my first collabrator, Professor Johnson knows who this person is, I found their attitude towards the CodeRuler assignment unprofessional. I emailed this classmate after going over the assignment, finally got a response from this person after a week. Thankfully, Professor Johnson assigned a new teammate, Erin, and we were able to crank out some code. Erin was professional, communicated well, and delivered the code as promised. I wish I could have done a better job with the knights so I could match what Erin did with the peasants. Conclusion CodeRuler is a great exercise the application got us thinking about Java again and it was nice to have some fun with an application. I suspect that the next coding assignment will not be as much fun but I am still looking forward to challenge.

02. OSS.Experience

Introduction
The exercise Open Source Systems Experience exposes students to working with open source projects. The task also makes sure we understand the three prime directives of open source development.

Overview
EasyEclipse is an open source system that distributes various versions of Eclipse with each release tailored towards a particular area of development. For example a Java developer can download an Eclipse IDE tailored for Java programming. Or a Rails coder will be able to use Eclipse without having to search for Rails libraries and plugins. The EasyEclipse version under review is geared for Java programming.


Prime Directive #1: The system successfully accomplishes a useful task.
At that heart of the system is the EasyEclipse plugin that allows users to add an Eclipse distribution. EasyEclipse is useful in the sense that developers will find it convenient to retrieve a version of Eclipse that is dedicated towards their area of development without having to hunt down a necessary plugin. EasyEclipse provides many tools for the Eclipse IDE ranging from web development to Java coding for mobile devices.

Prime Directive #2: An external user can successfully install and use the system.
Installation of EasyEclipse is a simple task where any Windows, Mac, or Linux user can install the application with minimal effort. EasyEclipse's help page instructs the user on which systems are valid and how to perform an install for each OS. There is also a FAQ page to alert users of common inquiries.



EasyEclipse is intended for an experience programmer who is looking for a powerful interactive development environment for their next project. Documentation for EasyEclipse is found by clicking on Help> Help Contents, a guide will open on the machine's default web browser. So access to the internet is necessary in order to use EasyEclipse's Help function. Within the Help function the developer will find how to set up and adjust the work area to an overview of Java development. Making the switch to EasyEclipse a painless task.

Prime Directive #3: An external developer can successfully understand and enhance the system.
The developers of EasyEclipse set their system up for anyone interested in creating plugins or making improvements for the next build. The EasyEclipse team maintains a CVS or Concurrent Version System where source code for the application and plugins are available for developers to make their additions. EasyEclipse code follows Java coding standards with proper indentation, naming convention, and comment. With some time the source code can be interpreted and understood so a developer can start working on a new builld.

Conclusion
EasyEclipse is an useful application for developers looking to make the switch to an IDE like Eclipse. EasyEclipse is well documented so any programmer can jump in and start working. The people responsible for EasyEclipse has done a good job at making their code understandable and available so any developer can jump in and make a contribution.