Wicket is Killers!

Holy hell, this past assignment was on Wicket. And that was a lot to take in for one week. I had a lot of things going on this week: birthday parties and cleaning up for apartment inspection. So I really only had time on the weekend to work on this. Stupid!

I managed to finish almost the entire assignment. I didn't get the chance to apply any test cases and PMD was throwing errors that I ran out of time to fix. But the stack page does run and the stack functions do work properly.

Considering this was done within the last 36 hours, I thought I did pretty well. I can only imagine how much better (heh, maybe not much) it could have been if I was able to spread this out throughout the week.

Problems:

The most annoying problem I constantly ran into was Eclipse not closing the port properly. So when I would try to run the wicket app, it would give an error. I would have to completely exit out of Eclipse and come back in. Other than that, the only problem is really self-error. I constantly had to correct the java and html files so it would match structurally.

What I Learned:

Nothing.... nah nah. Wicket seems pretty powerful. I can't say much since all we did was use forms and tables in this assignment. But the fact that we were able to incorporate our Java code is pretty sweet. I was wondering when or even if it was ever possible. I can't bring myself to show off to family and friends a command-line program or even a generic GUI. It's just not that impressive. So it's good to know there's something like wicket that ties it all together.

stack-wicket-johnly: Download Link

SPAM!

This week's task was to add two new features to the DueDates project. Email and Wakeup. As easy as Dr. Johnson made it sound, it was slightly more difficult. But because it was so "simple", we decided to split up the tasks this week. I was responsible for Email. Both of us finished our tasks.

SPAM anyone!?

First off, we are using JavaMail to implement the email feature in this release.

Email is dependent on the user's ISP smtp server. I never knew that until Arthur Shum pointed that out. Thank you for that. I am still surprised that anyone can send email without any form of authentication. Don't look now, but open opportunity for one of my favorite can goods, SPAM! I don't know if I should be mentioning this, but this is quite dangerous. Users can actually spam people if they input someone else's email and a very small wakeup interval.

Dang Hawaiian Telcome, Being Safe and All.

I couldn't quite seem to get it to work with Hawaiian Telcom's server. I googled the error message I received. All sites indicated that it just needs authentication. Unfortunately, I don't have the master account information (or any login for that matter) so I couldn't get any further. But I did discuss it with my partner John Zhou and another classmate. They confirmed my code worked with RoadRunner's SMTP server w/o authentication. Since I couldn't test my system at home, I drove down and did some hacking at Hamilton Library as well.

Bigger Problems?

Because there are so many possible ISPs, the big variance can severely affect performance guarantee. Currently if someone is using Hawaiian Telcom's service, then it is very likely they won't be able to use the -email feature. I've been trying to find a way to check if the provided smtp server requires authentication, and if it does, then prompt user for the fields. No luck yet. Will work on it some more later.

Group Meetings

We met a couple of times this week for about 30 minutes each. We were mainly checking up on the progress of each other, and answering each other's question on installation issues with JavaMail. Otherwise, we worked quite independently. It was still kind of neat how everything worked without each other's source code as they should since they're not dependent on each other.

Improvements and Summary:

In regards to predictability, this version was harder. This was slightly harder for me to implement only because Hawaiian Telcom's SMTP server was not working for me. Once I got to UH, it was working just fine. I am concerned for unknown ISP's though.

This was really my first time I actually posted a question to the ICS group. It was very helpful. I'd probably ask more questions rather than wreck my brain over things. Maybe even try StackOverflow too.

Get the Paddles Ready! CLEAR!

Well my mother always wanted me to go into the medical field. Now I can pretend to be a doctor. Special patients that require extra attention need to be placed in a Intensive Care Unit (ICU) and monitored for vital signs. Any major decline is a red flag and calls for attention.

What is Software ICU?

We, software engineers, aren't biased and prejudiced like that. Almost all projects (that contains multi-stage implementation) deserves to be monitored for these "vital signals" as well. In humans, vital signals include: blood pressure, heart rate, temperature, etc. When referring to software, these vital signals are: coverage, complexity, coupling, churning, and code issues. We monitor these with HackyStat, which utilizes sensors tied together with the tools we have used throughout this semester to transmit the status of the project.
Individually, one weak vital sign is not dangerous but should be tended to. Multiple weak signals are definitely a sign of danger of quality dropping severely and should be addressed immediately. Why is this important? Well just like how doctors don't like it when patients die, we don't want our programs to be on the verge of death either. Strong health is likely to indicate robustness.

Patient Status

Time to put the very little medical terms I learned from one of my favorite shows, House M.D., to use!

The program is all set up and in a stable condition. I ran into complications when trying to configure the subversion sensor. But after a differential and consult with a couple of classmates, I ended up creating a UserMap.xml file. A snapshot vital signs of our project is below:


Diagnosis and Treatment

It appears the program is allergic to crappy test cases, thus the crappy coverage. Until I or my partner give the patient steroids (better and more extensive test cases), the program can be considered to be in a medically induced coma (since it is not going to change unless we do something).

NOTE: I don't remember if steroids is what they give patients with severe allergic reaction. Let's just pretend I'm right. Don't worry, I won't be treating any of your family members any time soon.

To end this blog entry, I want to give an idea of what we look like. To the right is a slightly better looking team (House M.D.) of us software engineers. The program is in good hands.

2 Libraries Greater than 1

"2 Libraries Greater than 1". That holds true for both, features and time required.

Continuing from the previous blog's theme, "Mo Money, Mo Problems", I wish I had some money. At least that would compensate for the some of the time spent on this version instead of enjoying the weekend. The new features just don't quite seem worth it. Haha....haha... heh... heh... too bad I'm serious.

At least we were able to accomplish all the tasks. Of course, test cases could always be improved. We also didn't get time to discuss as a group the reviews we received. Oh well, there's always this week.

Problems We Faced:

Our plan was to create a BorrowedItem object for each book and throw everything into a list. With everything in one list, it would be easy to sort. Initially I passed the list into a method, sorted it, and then returned it. But my partner, John, mentioned a better way of overriding BorrowedItem's compareTo and sorting the list with the Collections.sort method. Other than that, everything was pretty simple.

How We Worked (and How I Wish Zippy's had Wifi):

We stuck to our previous method and continued to have face-to-face meetings. Unfortunately, we weren't as free as last time and we were only able to meet twice for an hour each at Hamilton library. Communication was not as strong due to it, but we still managed to get the tasks done. We discussed things over AIM on some of the days we didn't meet face-to-face. Hopefully with all midterms done (and some of my partner's projects from other courses), we can get back to efficiently working on a daily basis.

Maybe by some miracle, Zippy's will have free WiFi soon. I mean that would be sweet to scarf down a $5.50 Spaghetti and Fried Chicken plate lunch (hell of a deal) and do some ICS. Now, that's some extra incentive to go face-to-face meetings!

1.1 greater than 1.0

Version 1.1 was definitely more challenging than Version 1.0. More factors had to be considered such as how are we going to retrieve and sort things from multiple libraries and how to filter out results up until a certain date. Version 1 did not need to consider any of this and only print out results.

What I Learned:

Continuous integration can be great. It can help automatically check the project's status as soon as anyone commits. We would know without updating the project locally. But it also has a tendency to be wrong.

It had me more worried about our system. Maybe because shortly after my first commit after adding the project to Hudson, it failed! Weird that it passed locally. I initially had my date printed using Calendar.SHORT where instead of numeric months, it prints out the actual text (e.g. Jan). But Hudson couldn't recognize it. Strange. Anyways, I reverted back all was fine. Sunny day in Hudson.

I really think we should layout a plan early on for the next version. Regardless of how the other's schedule is, we know what the approach is and therefore, we can easily understand one another's approach. Before we thought of storing all items into a list, there was some complicated approach that just seemed more than it needed to be. So yes, draw up a blueprint early on. So we're all on the same page.

Mo Features, Mo Problems

This week's code review was based on Version 1.1 of DueDates (or whatever we finished up until Wednesday). DueDates v1.0 (reviewed last week) only retrieved information on items checked out from the UH Library. DuesDates v1.1 adds the feature of retrieving information from 2 libraries (one or both simultaneously), and some search filters such as -within and -sort. I think the addition of these new features can be summed up best from the words of Biggie Smalls with a slight variation,

"Mo Money Features, Mo Problems".

Who I Reviewed:

Team Red. I thought Team Red did things pretty similar to my group. The branch that was copied wasn't complete in terms of features. But program design was very similar in terms of throwing all items into a list (I am pretty sure that's where they're headed). That was good because it made me feel better about our design as well. If two groups come up with the similar idea, then it's likely a decent idea. There is a possibility that it could be a bad idea, but that would just suck for the both of Red and Yellow, wouldn't it?

Anyways, with most of their grunt work done, they basically need to tie it all together. I did notice their test cases could be stronger. I've only mentioned ones that I know that are not dependent on user's parameters, such as testing for expected exceptions. Chances are Team Red would have gotten to it eventually anyways.

The Reviews I Received:

Team Silver helped review our code. They helped point us a lot of ways to error check, which was good. I was so busy on working on how the program operates properly, I didn't have time to implement any error checking. Team Silver was extremely helpful and detailed in what he found and even had design cases suggestions. Sweet! Haha... I ought to ask Team Silver to review our stuff more often. But why put the guys through that kind of torture?

My only concern is how much of those can I address before Monday? I am going to need to prioritize and see which one I will need to go through.

Final Thoughts (Before I Go Eat Lunch)

I think this week's code review was more needed compared to last weeks version of DueDates. It will probably be more and more helpful as we continue on the DueDate project. With the program continuously growing, it's easy to overlook things. A third-person's perspective can help detect and spot errors.

Before I start addressing the issues brought up, I need to address my stomach. Next Stop, Zippy's.