Monday, November 24, 2008

Learning How To Wicket Good

This week we are preparing to launch the DueDates program on a worldwide basis over the internet. For that to happen, all the programmers in the class will learn how to use Wicket, which combines java programming with an html web interface. We will discover how to integrate wicket with our professor’s stack program.


Problems everyone has them
Implementing wicket was a big deal for me, never doing any actual web programming in my past experiences. Programming the wicket part of the stack would have been very difficult if we never have been supplied with any examples from our professor. The examples helped a lot in setting up stack with wicket, like on what to create and what steps to take. Everything was going smoothly for me; all the parts on the java side were working fine, until I had to implement a web table that can store the elements of the stack.


This was a problem I had, creating a somewhat dynamic table for the stack elements. I went over and over on the contents from the Wicket in Action book; I found something’s that could have worked, but didn’t really make sense to me. So I looked over the internet for tips, and didn’t find anything. So I just settled for the bare minimum and displayed the stack on a single row of the table.


Also another problem I had was for errors, such as trying to remove an element from the stack when it is already empty. I couldn’t really approach this problem, since I committed most of my time trying to solve the table of elements problem. I had an idea of creating a label and having it display when ever the error occurred, but there just wasn’t enough time to implement that idea into the program.


The Experience
I was not able to finish the full requirements set by our professor. There is no one or thing to blame really; I just had poor time management during this assignment. Although I got a lot of the assignment, wicket is a very good tool for implementing a web interface for java programs. It was easy to pick up and see all the patterns of how it works, such as establishing ids for things that will appear in the html file from the java file. I learned also another on going lesson from this, “Have Better Time Management”.


My Stack Wicket DownLoad

Monday, November 17, 2008

Power and Responsiblity

This week we continue to upgrade our, team-silver, DueDates project. For version 1.2, we will be adding the new feature of sending the results to either an email or straight to the console and to check the user’s account for live updates from the library’s website. We split the task evenly, Ronn being responsible for the email feature and I was responsible for the update check feature. Even though it was a simple upgrade we met on a regular basis, just like on our previous improvements of the program.

You've got Mail
The new email feature is possible by integrating an open source java program called JavaMail. This new open source program, JavaMail, requires the user to supply not only an email address but also the email’s SMTP server. For email’s that require an authentication for the SMTP server, JavaMail has the option of authenticating, but that was the hard part. Most email providers require that the program authenticate the server being used, which made this problematic for finding an email we can use to test. Luckily my work place, University of Hawaii Star Degree, uses Microsoft Exchange as the email provider, which made it possible to use my email from there as a test dummy.

Updates Anyone?
The one part of the project I was responsible for was having the project check for updates of the user’s library account. This was possible by using java’s TimerTask and Timer, which are already included in the Java package you needed to download for the use of the program. Checking for updates requires the user to provide an amount of time of when to check the site, the time was calculated in milliseconds in a day. It was necessary for me to break out some of my old math skills, which I haven’t used in a long time, to calculate the right amount of intervals to enter and provide a formula for our users on how to calculate their own intervals of time.

Damn FindBugs
We had some problems in this version of DueDates, the small problem was finding an email address for testing the email feature and the big problem was integrating the update check feature with our program. Well the email problem was easily solved, which I mentioned earlier; but the update check, on how we integrated this feature with our program, was getting an error when doing a FindBugs check. FindBugs, a quality assurance tool, didn’t like how we were passing the original user’s input to the TimerTask. After a day of attempting to restructure the project for this new integration; what I thought was so confusing and causing me to run around in circles, was simply solved by just cloning the user’s inputs. Who would have thought that the solution was something so simple? Once these dilemmas were resolved, we are finally ready for the release of version 1.2.

Be Responsible
This new version of the program can either be very useful or a good way to pull an office prank. It is useful because, you can check for updates and at the same time receive emails of those updates. Also it can be a good tool for pulling pranks by spamming a co-worker or co-workers in an office, spamming them with meaningless things and having it being from anyone you want it to be. I thought about playing with this tool to pull an office prank, but declined. It just made me realize how much power we, software engineers, have with all our modern technology. “With great power there must also come great responsibility” – Stan Lee.

DueDates v1.2
User Guide

Friday, November 7, 2008

Take 2 of these and call me in the morning

Checking into the ICU
This week we checked our project, DueDates, into the Intensive Care Unit (ICU). This ICU is similar to what a hospital’s ICU is just like, just with no beeping sounds all over the room. It checks the vitals signs, but instead of heart rate or blood pressure, it checks on complexity, coverage testing, coupling, churn, code issues, size, development time, commits, builds, and test. The ICU for program projects checks the trends on those vital signs and displays it on a graph, showing if there is an increase or decrease in vitals.

To have the ICU project monitor you’ll have to install it into your own computer and also become a member of the online monitor. The actual monitor on both your own computer and the online monitor are called HackyStat. The installation on your computer, is a plug-in for the Eclipse IDE.

Dilemmas checking in
When I installed the monitor onto my own computer, the installation went smoothly. The main problem I had was altering a system environment variable, which is needed to connect your local computer to the online monitor. After an aggravating night of trying to fix what was wrong with setting the environment variable, I sought the help of my professor on the next day. After just a simple glimpse of my environment setup, he spotted the problem. The problem was just a simple misspelling, instead of spelling it as “ARGS” I spelt it as “AGRS”; big difference right? Getting past that small dilemma, I was able to complete the whole installation. Then i was able to see the vitals of the patient.


Current Patient Vitals


The Diagnoses
This program vital monitor, HackyStat, is really awesome, makes me feel like a doctor. Well not just like any doctor, more like Frankenstein; mostly because we actually created the patient, the program. Following the HackyStat installation, I see that the patient’s vitals are stable but cane be improved. To improve the stats we need to give further testing, instead of lots of exercise and a balanced diet for a regular human. Before we do the testing though, team-silver has to take the patient to the operating room.

Monday, November 3, 2008

Need an Upgrade?

Upgrading a program can always be fun or troublesome, depending on how you look at it and the amount of work involved. The silver team, Ronn and I, were given the chance to add some new features and do other improvements to our DueDates program. Also we were able to make some corrections that we over looked in version 1.0, with help from the results that we received from our peers before and during the 1.1 upgrade.

New Features
The new specifications of the 1.1 version of DueDates was to add in the “sort” feature, which enables the user to sort the rented books by either its due date or by the location where it was rented from. Also another feature was the “within” function; which was to calculate, when given a number, the books that are due within that range of days. These new additions were not so hard to implement into the program. When designing the initial version, we always kept in mind that we wanted to make it easy to further upgrade the program somewhere in the near future.
The Process
Before adding the new specification to our program, we wanted to make some changes to the system’s structure. In the first version, we both wanted to use a XML repository to store the libraries; which would serve something like a table of libraries, with each library as a row in the table. So we took this opportunity to integrate the XML repository to this new version. We both sought out and looked online for guides on how to do this process, I for one was excited to see how this could be done. After searching for a day, we found some very good articles and instructions on how to add XML into our program. Also during the search we found an open source program, Argparser by John E. Lloyd, which would make the inclusion of the new specifications easier to add into the program.

Adding in the two new features, the XML repository and the Argparser, took some time. When we included the Argparser at first we incorporated the source files; but that cause so much errors, some were easy to fix and some were mind bending. After hours of error solving we just simply decided to just add the Argparser jar file into system’s library, making it still apart of the program just not with the all the errors. In the addition of the XML repository, this was very interesting on how it stores the libraries. With this, both users and developers of the program are able add in a library of their choice.

With the new features added on, we were able to now add in the new specifications. Integrating the “sort” function was simply done, due to how our system was created, we just had to make minor changes to file that involved such a function. Also with the “within” function of the program, it went the same way; because both functions were related to the same files that need to be changed. Adding these functions as options for the users of the program was easily included, due to the Argparser we recently added.

Troublesome
With all upgrades, minor or major, there will always be problems. The dilemmas we encountered in upgrading, was adding in the Argparser. When we initially added the source files, we got so many errors. Like mentioned earlier, some were easy and some were hard; but it seemed that when we fixed one error 5 more would appear. We then resolved that issue by not including the source files, but using the program’s jar file. Another problem we had was the QA (Quality Assurance) tool, PMD. The errors we received from this the tool was such a bother. It caused us to go back into our implementation and revise some changes we did to this new version of DueDates. I know it has its reasons for giving us those errors, but PMD (Pretty Much Depressing) can be troublesome.

Keep Moving Forward
This advancement in our program went by smoothly, giving the amount of time we had and the amount of work we had to do. We met as much as we could in the process of upgrading the program, meeting every other day; but once we finished a large chunk of the work we met via Skype. We also divided the amount of work evenly and also helped each other when ever one of use hit a brick wall. With great team work, we were able to conqueror the battle of upgrading.


I didn’t make as much commits to the Google Project page, fearing of the Hudson checks would give us rainy days. Hudson was like an extra professor checking our work. Overall this was another good experience for our futures, working in a team as a team. Also using new programs and integrating other program languages to our system was educational. As I mentioned before we originally thought of further upgrades to the program, which is the reason for its structure. So all we can do now is to “Keep Moving Forward” –Meet the Robinsons, hopefully advancing with a Graphics User Interface.


Links:
Argparser by John E. Lloyd

Saturday, November 1, 2008

The reView

We, Ronn and I, had the honor of receiving a review from both Tyler and Scheller, team gold. They both looked over all the specified aspects of our project. Both had very encouraging, interesting, and insightful inputs about how our project turned out.

Receiving New Aspects
We received many praises from both reviewers, which was very encouraging. Both liked how organized our project was, splitting the program into packages. Tyler mentioned how he liked the use of integrating XML, another programming language, into our project. Also he liked how our Google Project page had a professional sense to it. Scheller gave us a good idea on users that rent out more than just books, such as video rentals from the library. This idea will be developed in future versions of the project.

They both also spotted things we over looked in the progress of the project. Scheller pointed out on our program not working with versions lower than Java 1.6, a computer run time environment need to run certain program. Tyler saw that we did not include Quality Assurance tools in our developers guide. He also cited that a user should not need to set an system environment variable on their system in order to use the program, and he had a nice quick solution to the problem which was to include all required libraries the program uses in the IDE’s (Integrated Development Environment) project class path.

The Offering
Ronn and I also had privilege to review another group project; which is the group of John Ly and John Zhou, team yellow. I saw that team yellow is still in development stages of some new features of the program, features such as sorting books by either due date or library. Also that they could reduce the size of they’re program, due to redundant logical use of code. We, both my partner and I, gave some tips on how to reduce the size of the program, as well as a structural improvement for future development. They’re program worked to the bare minimum without any errors, which to me is still good.

The Google View
Using Google’s Project Hosting is getting easier the more I use it. The further use of Google’s Wiki syntax for creating issues; I’m beginning to get the hang of things. Also thanks to other classmates, I learned of new short cuts when things don’t appear like how I want them to. For instance when making a numbered list, when published for public view it appears that each item on the list is number 1 and not in decreasing order. Also our professor showed us a tip on being more organized on having people review our code; instead of searching through our code for comments, we can just refer back to an issue dealing with what the comment is about on our code which displays the comment easily.

Summing It Up
After looking over both reviews, I see that we still have more improvements to do to the program. Having an outsider’s aspect on our program was very helpful; having them point out things we did not see or thought about. I also hope on concluding my review of team yellow, that they take our comments open minded. Criticism, reviews, or call it what you want; in creating a product there is always room for more improvements, no matter how perfect it may appear.