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.