Sleep Overdue.

DueDates 2.0 is our new web application project which is supposed to display the books that are due from different libraries. Too bad it wouldn't tell me how much sleep I am due to. I'm sure it's a lot after working on this. According to Hackystat, over 110 hours of development time went into this project.

DueDates 2.0 takes our previous DueDates 1.2 and basically puts it in a web application using Wicket and Jetty. Sure it sounds easy. But it was a rough experience for me since I don't have a strong dynamic web background. Now that it's done, I feel good about it. All this Java background we accumulated in the ICS program is finally being put on display.... to something NOT LAME.

Release 2.0 was assigned new groups and I was grouped in Team Ahinahina together

• Phillip Ka Hung Lau
• Scheller Sanchez
• Robin Sanchez

Project Status & Process:

Our project was nearly complete. Nearly everything is working except the "within" feature for each individual library. We couldn't figure out how to uniquely identify the textfield for each library. We also forgot to allow the project to sort by book title. But that is something similar to the other sort methods. Unfortunately, it's getting late and everyone has other assignments to work on. So we have no choice but to leave the project as it is. Finally, we forgot to include a "within" on the Alerts Page.

We met nearly every other day in the first week and Sinclair library. But after falling behind schedule, we met close to everyday the second week. There were times where I'd spend more time at Sinclair than I did at home. A couple of times, some of us spent 12-13 hours at the library. That's dedication..... God I need sleep.

We tried to divide the task up evenly in the first week, but some of us fell behind. So the rest of us had to pick up the slack. It was frustrating early on. But they were more than willing to take additional responsibility to make up for it in the end. If I could change something, I wish we set firm progress points. It felt like a lot was crammed into the last week.


My Responsibilities

I was responsible for the Login (Index) page and some of the Display Page features. We wanted to add secure authentication. But we weren't sure if we would finish in time, so we decided to simply get it to work first. On the display page, I worked closely with Robin looking over the system requirements trying to get an understanding of what features needed to be implemented. I populated the table and applies some aesthetics to the boring HTML table that was originally there. I also worked closely with Robin to dynamically create the individual "Update" buttons for each library.

The difficulty with the Update buttons is, how do we identify which button is clicked if they are populated dynamically based on a list? The wicket ID is the same because we only specify how to populate each row. Fortunately when a button is added, it is basically creating a Button class on the fly and adding it to the page. I ended up creating a String variable within each Button class, and that helped identify which button is which.

It really helped bouncing ideas off one another. My team member's idea can inspire an idea in me. And my ideas can inspire them.

Differences in DueDates 2.0 versus Prior Releases:

This was definitely more difficult. We're still new to the Wicket classes so it was challenging trying to working with dynamic objects. I think it just takes practice. I still have a lot to learn with Wicket. I found myself constantly going between the HTML and the Java files because I forgot the model hierarchy.

Surprisingly with this release and larger group, I was able to meet more often. I suppose it just depends on everyone's schedule. Everyone had the same habit of staying up late. It was harder dividing the tasks evenly and keeping track of everything however. With tasks divided between more people, we had to constantly check on who's doing what. Is that person's task too difficult? Is that person's task too simple? Does everyone have a task to work on?

The Learning Experience:

Continuous integration was extremely helpful and prevented a lot of bugs this time. With so many files and commits, there were bound to be a lot of mistakes, uncommented code, etc. The software ICU however was a pain. I felt it didn't completely reflect our efforts. The commits on some days were insanely high for some of us. I am pretty sure we did not commit that many times in one day.

Testing/Coverage was low most of the time because we couldn't figure out how to test the application without comitting any accounts. It was our fault for not asking if Hudson had a duedates.xml file (like the users need to have). We constantly tested our applications by running it and logging in ourselves. In the end, I modified the program to look inside the project's directory for a duedates.xml if a ~user/.duedates/duedates.xml did not exist.

I think things could be improved. I think I could be more vocal next time around. I don't think I started too late, but there were some questions I could have asked earlier that would have simplify things. I thought I could have kindly offered my help (in a non-intrusive way) to see who's falling behind. I did work with Robin quite a bit. I thought our collaborations were pretty good. We got a lot of work done. I need to build on that.

DueDates-Ahinahina 2.0 - [Project-Home]

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.

A Bad Review is not Failure, but Feedback

"There is no failure. Only feedback."

Some rich entrepreneur said that in one of those "get rich" schemes. I don't know think I'll be getting rich. But I think it makes a lot of sense in this situation. Bad reviews/feedbacks can feel like you're getting kicked in the gonads sometimes. Once you get over the feeling, you realize the comments really make the job easier. As the recipient, I'll know exactly what to address. The project will likely make strides for the better (if I do it correctly and select the correct areas to change).

How The Reviews Are Given

Google project hosting is a pretty sweet free service. Google allows reviewers to easily insert comments within the body of the code by double clicking the line we're referring to. All within a browser. That's like commenting on an essay but without having to double-space the lines to write between. I mean what better way to point out a problem than identifying it directly in your source code?

There was one glitch when I tried to submit or publish my comments. The link wasn't always available and only after a refresh of the page, the "Public My Comments" would appear. But after the refresh, I would have to rewrite all my comments.

The Set Up

In order for anyone to comment on the code, some settings in our project needed to change first. The first thing our group needed to do was either (1) add the reviewers to the project, or (2) allow anyone to add comments. Then, we made a copy of the trunk of a repository and put it in the tags directory. Basically this made saved the current stage of the current project, so the users can comment on it. That way we could continue to work on the project, while not having to wait for the reviews to be complete.

Giving and Taking... and Taking Some More

I was responsible for reviewing three groups (Purple, Violet, and Blue). I picked up and saw some good test cases as well as some good design. I saw ideas that I would want to add to our project. Although I tried to point out as much things as I could for improvement, I feel like I walked away with more than I put in.

If that wasn't enough, our group got some more feedback. They helped point out small issues to clean up, which is good because we want to be neat and professional. We also got comments on design, which is highly apppreciated and what I was looking forward to the most. Our design is currently using a superclass Library and all libraries extend it. We were contemplating on using an interface instead since there isn't much to inherit. With an extra voice, we have more reason to switch.

Final Thoughts

I understand the short amount of time everyone had to complete the task and I really appreciate the reviewers' efforts. As of Wednesday night, our group only received four out of the six (missing: Flestado and Sanchez) reviews we expected. I previously overlooked one because it was the posted to an earlier release (r29 vs r28). I am pretty sure I didn't see the other ones though. I looked in all releases since Sunday.

I hope we end up with the remaining reviews regardless if they're just restating what others said. To me, if there are that many people that feel a certain way on a topic, it should be taken highly into consideration.


Things to Improve Next Time Around:

I need to take note of the "publish my comments" link before I start commenting too much. Rewriting all of those sucked. I noticed I forgot to add the google discuss group email in the event of code reviews. Man that made it hard to locate comments. For future reviews, it should be better.

DueDates

"Two Heads Are Better Than One"

That basically sums up the experience for DueDates. Any problem I had, I felt less worried than usual because I had someone else to consult. Someone had my back and I had theirs. My partner this week was John Zhou.

The Task This Past Week

We were all partnered up this week with another classmate to work on DueDates, an Open Source Java command-line program that retrieves checked out library items information.

Basically any UH student with an internet connection and a machine with Java 6 installed can use this program. They simply need to perform the following steps and as Emeril Lagasse would say, "BAM!" Users see their results in the command-prompt. Unfortunately, the results are not as instantaneous as the expression. It's more like "BAAAAAAM!" stretched out over 3-6 seconds.

Sample output can be seen in the screenshot below.

What We Accomplished:

My partner and I were able to meet most of the requirements for version 1. From the user's perspective, the program meets all the requirements of version 1. But from a developer's perspective, we lack testing. We did not get 100% coverage on our test cases. In fact, we sort of ran out of time to do much or any testing. We did attempt it and ran into some problems.

Problems We Encountered and Solutions We've Arrived At:

1. Emma and JUnit

• Because of the lack of javascript support in HttpUnit, JUnit Testing fails and presents an error when run with Ant. This errors seems to be apparent cause to the low coverage reported in Emma. I guess the coverage test stops as soon as the error is reported.

2. Design

• We felt that all libraries will needs it own unique way of logging in and retrieving information. So all libraries should be a subclass to a larger superclass. To keep output consistent, we decided that the superclass should have toFormattedString method. And all subclasses would use that method to keep output uniform.
  
• SOLUTION: Created superclass Lender, with subclasses UhManoa and HawaiiStateLibrary. All within placed inside a subpackage, "library".
  

How We Worked:

I thought we did a pretty good job accomplishing most of the tasks considering how busy the other's schedule. Both of us had midterms at different times throughout the week. Nights when I was free, my partner needed to study. And the opposite applied when my partner was free. But even through all of the schedule conflicts, my partner and I were still able to meet about 3 times for about an hour each meeting at Hamilton library.

There's nothing much more we can do. It's midterm time and it's good that we can even find time to work with one another. I think the number of face-to-face meetings was about right. We didn't exactly meet on weekends but we communicated through IM. I do wish there was somewhere more casual and laid back to meet. However, it's hard to find somewhere with WiFi and food to eat.

What I Learned:

It's different thinking about future releases of this project. It's difficult to know what to expect for future libraries. It's also difficult to run tests since all accounts could generate different results. Except in my friends' cases, they all have no books checked out.

Google Project Hosting keeps everything very public. Every single update is documented. Not only do you want to think for the future, but you want to put out your best impression to the world. You never know who wants to contribute and who is critiquing your work. Since our real names are published, there is pressure to write clear, well-documented code.

CM Lab

In the previous entry, I was bickering about how there are too many steps to this configuration management process. While I have not fully mastered everything, I still must say it is not that easy compared to the previous assignments. However, there are good news. That is I'm getting the hang of checking out, updating, and comitting with TortoiseSVN.

The Grunt Work is Becoming Bearable...

Luckily for us, the project all contained a similar URL and I only needed to change the project to stack- of whoever it belongs to. Nice and simple. I guess I somewhat already noticed that the googlecode.com password is the same for all projects. If I wasn't already sure, this third time using it confirmed it. I haven't looked into it, but hopefully there's a way to create our own password. I would hate to need to copy and paste that weird set of characters each time I set up a new project.

Check Out, Update, Verify and Commit

I verified both before and after I finished working on Phillip's stack. All was successful so hopefully I don't get a message back about how I messed things up. That would be awful. I really did everything in my power before commiting. I treated it as a commitment to helping while not destroying.

I've only edited minors things. The stack project name in eclipse was simply "stack". I changed it to "stack-klau4" for a couple of reasons. The first was mainly because I already had 3 other stack assignments imported into Eclipse. I need a way to distinguish between the others. The second is because I think the assignment requests for us to include our name in the project.

Everything else seemed okay in the code so I just touched up some JavaDoc for consistency. I noticed in one method, there was an @exception while others (that also included thrown errors) didn't. I even looked up Elements of Java Style to see. It's weird how I never noticed that the book suggests we include @exception tag whereas CheckStyle will complain about not including @throws. To keep with Philip's documentation, I added @exception to the others, but also left the @throws for CheckStyle's sake.

Looks like I See the Light at the End of the Tunnel

Early on, it felt like I was driving through a tunnel with no headlights on. Lost and confused, often times at a stop, trying to figure out how I'm going to finish this. But as I use all of the sites and TortoiseSVN all together, I am beginning to get used to how things work. I can see the light at the end of the tunnel.

Sometimes I worked for long periods of time. In a larger group, there is likely a chance that someone else updated the project in between my commit. I need to get used to updating the project more often. I simply commit once the project passes verify. Another concern, or more of a question really, is the empty packages I am seeing. I noticed when I import the projects I've obtained through TortoiseSVN into Eclipse, there are a couple of empty packages that appear. It is weird how when I commit mines, those empty package don't exist. I am not sure how important this is (probably not seeing how they're empty). But it did make me wonder what was causing it. Perhaps I'll figure it out another time. Is it something everyone's computer is doing except mines, or is it just one person in the entire group responsible for it?

Config Management and TortoiseSVN

TortoiseSVN

This assignment seemed to be much more overwhelming than any of the past assignments. By configuring TortoiseSVN (which oddly enough isn't slow at all) to Dr. Johnson's stack project, each one of us ICS 413 students modified the project in some way to (hopefully) better the overall status of the project.

Rolling Up the Sleeves....

I don't know if its my fever and headache affecting my thoughts, but it seemed as though this assignment required much more setup than the previous tools. The installation to TortoiseSVN was the easiest part of the assignment. But afterward installation was complete, there are so many URLs to keep track of.

https://stack-johnson.googlecode.com/.....
http://code.google.com/hosting
http://groups.google.com/group/stack-johnczly-discuss

And not to mention there's the codesite-noreply@google.com to add to the discussion group, and the googlegroups email address to add to the project page for update and commit email notifications. I'm getting another headache just remembering the process. I found myself constantly referring back and forth from the assignment page and the google pages. This can create quite the confusion. Hopefully after the lab and the next project, the process will be burned into my brain. I'll know how to do all these trivial tasks of setting up projects like I know the back of my hand.

Doing My Part

Well, we don't have an assigned role or assigned area of focus to work on. So my part is not clearly defined. Basically my goal was to change something I felt was beneficial to the project and avoid corrupting its current state. It's amazing no conflicts seemed to have occured so far with so many students working on the stack. I was worried, since I started the assignment late. Had there been an error, I don't know if I can contact the previous commiter to fix it in time.

Anyways once I updated and verified the stack, I noticed the coverage was not at 100%. My first intentions were to increase the percentage slightly (leaving some work for others). I thought the stack was identical to the assignment we've been working on all semester. But turns out, it was different. EmptyStackException has three constructors, and only one was being covered in our JUnit testing. I couldn't quite figure out how to get the other two constructors to be covered, but I thought something such as the following

throw new EmptyStackException("Empty Stack");

Unfortunately, PMD complained and I couldn't come up with a solution to solve both problems. To save time, I noticed that there was some inconsistency between JUnit test cases involving expected exceptions. I fixed that problem and moved on. Hopefully someone will improve the coverage. I can keep track of it now with TortoiseSVN's log.

Reflection of This Long Assignment

Everything is so public in these assignments. It really adds pressure to check your work. Everyone can see who was the last to edit the project and who is to blame if something stops working.

I know google project hosting is free. But seeing as how group members of a project would love to receive notice updates, Google should have combined the best of two worlds and created a mailing utility within the Google Project page. That way there is no need to create an additional group and mailing list. They basically ask for similar information. Referring back and forth between Google Groups and Google Project is kind of a pain. That is just my opinion. Then again, it could be the Tylenol talking.

In addition to these lessons, there is one more I learned. Take your flu shots. Programming while sick sucks.

This was an eye-opening experience. It shows that a team is useful in more than just offering you help. They are also there to place blame! There's no lying with TortoiseSVN. Hopefully, my commit didn't cause any problems. I checked with verify before commiting. Build was successful.

StackOverflow: Temple of Knowledge (and Badges)

First Impressions:

The very first page I visited on StackOverflow was the “About” page to learn more about the site. I really liked their description of themselves and the tone they used in it. They didn’t brag about who they were. Instead there were quite frank saying things such as,

“What makes us special? Nothing, really.”

To me, it set a message that says there are no egos here (at least from the moderators’ side). There is no need to worry about shame when asking questions. We don’t think of ourselves as tremendously superior guys so you shouldn’t feel inferior to speak up.

Types of Questions:

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." -- Rick Osborne

That’s some incentive to comment and be organized there. Haha. That was a reply to a question asking for everyone’s favorite programming quotes. I liked the fact that not all questions and answers are boring and textbook-like. They also aren’t limited to only debugging. I don't know if that violates their original idea of "programming" type questions. But I enjoyed seeing the different varieties. Some questions I saw involved programming interview questions (useful to prepare yourself). Others involved how to work with "incompetent" group members. All good stuff.

Fast Responses:

StackOverflow looks like a very active environment with a lot of credible members providing answers. Some questions under the hot section received 5 answers and about 50 views in only 30 mins. That’s a pretty fast respond rate. So it would make sense to expect a good number of responses in a one day’s worth. I know I will be back to ask more questions. I already see some questions on TortoiseSVN. I’ll be sure to search and even ask questions on StackOverflow if I come across a problem.

Plus, I need to get me some of those badges! I think the badges were a good idea. It provides some extra motivation to answer questions well. Hopefully, no one is cheating the system and voting up for their buddies though.

JUnit Lab

Emma reported 100% coverage for my stack project (download). Good. Awesome. Done?

Nope. As the readings pointed out, there could still be a bug. To prove this, we will purposely insert a bug into the Stack project and show this can happen even with 100% coverage.

Program with a bug? What kind of 100% is this!?

Emma cannot read between the lines. It cannot determine what is a good test. It only reveals what lines have been used in the test.

As hinted in class, if the Stack's list were a static size, then an error like IndexOutofBounds (or something similar) should happen if the number of objects pushed on exceeds the maximum length (limit) of the stack. Emma would never be able to report such a case because it doesn't check the boundaries. It only checks the test cases given by the programmer and if the line was ever executed in its respective class.

Unfortunately, I could not figure out how to create a list object with a static size. The list would dynamically extend itself and make room for more objects even when I set an initial size for the object. The only way I know how to resolve this is to change the list to a simple array. However, I avoided that since the Stack's entire project manipulated that very list. To change that would mean to change practically everything.

So instead, I implemented a test that would push on a very large number of objects onto the stack. The point was to exceed whatever the Stack limit is and throw an error. Since I didn't know this limit's exact amount, I started with base 10 and increased it exponentially to determine the limit. My test would throw an OutOfMemoryError after 10,000,000 pushes.

How Do We Know if the Test is Good?

So there are still bugs to discover even after achieving 100% coverage. It's scary because how does one know when they are truly finished and left with a good test? I have no clue. Is testing ever really absolute 100% perfect. I doubt it. It's probably better to let other hackers try to crash your system if you have that luxury. I didn't, but I do have other blogs to check out since we're all working on the same assignment. Some things are just more apparent to others. But the more scenarios and equivalence classes tested, the more robust the test and program will be.

Emma Testing, 100% Good or Bad?

100% on a test! Sweet, that means my test (download)was awesome!

Unfortunately that isn't always the case when it comes to testing programs. Our newly introduced friend Emma (who is not a hot import model sadly) is a useful tool to check test coverage in programs. I've grown accustomed to thinking 100% is considered the perfect mark. No changes needed. Can't be any better. But Emma changed that.

Emma: The Flirt

100% is Emma's way of flattering you. It's a semi-victory message. On one hand, our test cases have reached every single line of code. But the other hand, just because I was able to reach every single line, it doesn't necessarily mean I exploited every single crack in the code.

When I was attempting to achieve 100%, my main mindset was not to exploit all possible errors. I just wanted to quickly run a test that would incorporate all the missing lines. My tests were moderate at best and were not as complete as it could possibly be. In the readings about equivalence partitions, it mentioned that valid tests fields include those that are valid and invalid. I've tested possibly the more obvious ones in a Stack. Pushing and popping, popping and empty stack, and retrieving the top of an empty & nonempty stack.

A Little Voice In My Head

Okay, so it's not exactly a voice in my head. But, one invalid test never crossed my mind until Dr. Johnson brought it up in class on Monday. And that's the boundaries of a stack/list (the upper end). I tested the negative (zero) end by popping an empty stack. But I never tested the maximum end.

I tried looking into the max size of a list, but it appears dynamic in terms of size. The list grows regardless if the programmer sets the initial size. It is likely there is some unknown limit that could result in an error. Maybe popping 1,000,000 objects could do it. I wouldn't know. I didn't test it.

I would say that improving line coverage improves the system slightly. It can verify methods are working properly by testing output. But it does not reveal everything. The fact of the matter is a bug can still exist if Emma reports 100%. 100% coverage does not necessarily mean it's a good test. But good tests should have 100% coverage plus robustness (and speed). A good tests looks beyond the surface and reads between the lines so to speak.

Ant Lab

00. Purpose:

After being introduced to Ant and the other tools available that help check for potential bugs and non-standardized formatting, we apply these new tools toward our previous assignment, CodeRuler, and see how we measure up to the standards we have set in this course. We are to run CheckStyle, FindBugs, and PMD.

I will be focusing on messages mainly on our written code, MyRuler.java, and not too much on IBM’s supplied classes or methods. Their standards are different from the ones we set so it is unfair to judge theirs.

01. Nervous Going In

I have to admit I am a bit nervous going into this assignment still. Unlike the Stack assignment, my code is about to analyzed by a machine and I am anticipating a lot of lines of “use incorrect (xxx)” or “missing that”. I am the farthest thing from the greatest hacker in the world. Hopefully I learn from the mistakes and bad habits and all of these tools (Checkstyle, PMD, FindBugs, etc) will present less findings in the future. Until then, I’ll get my ass handed to me by the machine.

02. Checkstyle Findings

Checkstyle found many of the errors my reviewer, Philip, found in my CodeRuler program. There were about ten errors in all, several of the same type. Below is a list of what checkstyle returned (the bold are those not indicated in my review):

[checkstyle] C:\eclipse\workspace\Game\src\MyRuler.java:3:8: Unused import - java.util.Iterator.
[checkstyle] C:\eclipse\workspace\Game\src\MyRuler.java:5: Using the '.*' form of import should be avoided -
er.*.
[checkstyle] C:\eclipse\workspace\Game\src\MyRuler.java:11: Type Javadoc comment is missing an @author tag.
[checkstyle] C:\eclipse\workspace\Game\src\MyRuler.java:23:3: Missing a Javadoc comment.
[checkstyle] C:\eclipse\workspace\Game\src\MyRuler.java:58:3: Missing a Javadoc comment.
[checkstyle] C:\eclipse\workspace\Game\src\MyRuler.java:102: 'else' construct must use '{}'s.
[checkstyle] C:\eclipse\workspace\Game\src\MyRuler.java:176: 'if' construct must use '{}'s.
[checkstyle] C:\eclipse\workspace\Game\src\MyRuler.java:182: 'if' construct must use '{}'s.
[checkstyle] C:\eclipse\workspace\Game\src\MyRuler.java:191: 'if' construct must use '{}'s.
[checkstyle] C:\eclipse\workspace\Game\src\MyRuler.java:193: 'else' construct must use '{}'s.

One of the new errors Checkstyle found was the curly braces {} not being formatted properly or worst yet, non-existent. Another error is the missing javadocs for IBM’s supplied methods. These reported messages points out all the areas we were too lazy to edit and overlooked because those methods were given by IBM. (Note: I should run and hide in shame. )

02a. CheckStyle - If IBM were an ICS 413 student

Holy smokes, IBM’s other classes turned up a lot of messages though. Thank god we aren’t responsible for fixing those… are we? If they were in our class, FAIL! Haha. Well... not likely, but coding standards are very different.

03. PMD Findings…. YIKES!

[echo] PMD found 36 problem(s).

That’s what stared at me when I ran PMD. Luckily I am only responsible for ten of those. A couple interesting points brought up here. It recommended for if-else statements, we should try to present our passing cases first rather than failing cases. It was called ConfusingTernary:

In an "if" expression with an "else" clause, avoid negation in the test. For example, rephrase: if (x != y) diff(); else same(); as: if (x == y) same(); else diff(); Most "if (x != y)" cases without an "else" are often return cases, so consistent use of this rule makes the code easier to read. Also, this resolves trivial ordering problems, such as "does the error case go first?" or "does the common case go first?".

03a. PMD - If IBM were an ICS 413 student

26 problems were not mine. That's all I'm going to say.

04. FindBugs…. Impressive

DB_DUPLICATE_BRANCHES: Method uses the same code for two branches

I knew FindBugs looks for potential code that could cause code to crash. So I was quite shocked to see this. This “bug” seems to focus more on enhancing code rather than potential problems. Anyways, it was useful and I was able to reduce the if statements so there was no duplicate code for the two branches and instead used simply one.

05. Conclusions: Automated vs. Manual Quality Assurance

I think Checkstyle has its limits in some aspects. Philip made some good points where he pointed out areas of redundancy in comments. It was something Checkstyle couldn’t identify because it does not interpret the content of the comments, at least I think so. It only checks if comments exist and if they are in proper format. So I definitely must thank Philip for his efforts for going above and beyond just looking at syntax. That is not saying I am ungrateful for tools such as CheckStyle, PMD, and FindBugs.

FindBugs and PMD are useful for finding really technical issues that perhaps beginner/intermediate programmers are likely to mess up on or not notice. Issues like using the correct modifiers (i.e. final, static) and object types. Concepts that I do not have full grasp of yet, I can rely on FindBugs and PMD to point out for now. I intend to learn more about these as they arise.

Also, I think I have gotten used to the fact that I am bound to code with errors. I am just more concentrated at correcting what Ant presents to me.

Stack

00. Purpose

To become familiar with the tools Ant, JUnit, PMD, FindBugs, and CheckStyle and apply it towards the Stack project found on the ICS 413 Schedule page. Inside the Stack project are errors that were purposely left unfixed and our job is to use the tools to find and eliminate them.

File Download

My completed distribution zip file can be downloaded here: stack-johnczly-6.0.925

01. Expectations: Trying to Say No to Fear

In regards to the "no fear" attitude, I wasn't exactly on board from the beginning of this assignment. I was actually a bit derailed and a bit concerned working with the Ant XML files. I thought we would need to create those ourselves, which struck some fear into me. I can understand most of the lines in the XML files but if I had to write one myself right now, I have a fair amount (or a lot... depending on your definition) of doubts and fear. But once I read the assignment, a lot of that went away and I got going at a decent pace.

02. Fixing Stack using Ant, JUnit, Checkstyle, FindBugs, and PMD

Majority of the problems were quick fixes (e.g. setting final to variables, fixing curly brackets, and javadocs, etc). There were two brought up by PMD that caused me to scratch my head. The (1) empty catch block and (2) the LooseCoupling: avoid using implementation types and use interface instead.

First was the empty catch block. I must admit I would have done the same thing Ronn had done. Never having any program in production at a professional level, I would have put a System.out.println() for two reasons.

(1) For the sake of putting something inside the empty statement, making the message go away.
(2) Because there is a fail message, it would make sense to have a pass message as well. By the way, it was awkward to test FOR a failure rather to test for no errors.

So I learned something new. Instead of purposely trying to catch an exception and throwing fail cases, we can use the new annotation in JUnit 4. I won’t attempt to summarize IBM’s explanation to avoid screwing it up. So quoted directly from IBM’s page,

In JUnit 4, you can now write the code that throws the exception and use an annotation to declare that the exception is expected:

@Test(expected=ArithmeticException.class) 
  public void divideByZero() {
    int n = 2 / 0;
}

If the exception isn't thrown (or a different exception is thrown), the test will fail.

The second problem I ran into was labeled LooseCoupling. I was initially confused by LooseCoupling. I did not understand what they meant by using the interface instead of implementation types such as ArrayList. It took me awhile. I googled different things and finally came across a post about Interface Programming. It recommended using List (interface) instead of ArrayList, making it

List<Object>

Now the example provided in PMD makes so much more sense. It's one of those times where I look back and go, "D'OH!" In my opinion, they should have put the correct example and a incorrect example rather than just putting it in comments. Maybe I am just tired. Although I fixed the problem, I am unsure on why this is a better case. Hopefully someone can answer that question for me. I am guessing it is because it's more general, and the users can interchange if needed between LinkedList and ArrayList to utilize the different characteristics.

NOTE: It's weird however after eliminating the last problem found by pmd, the echo message didn't set a value for pmd.failure.count so the message I received when running ant -f pmd.build.xml resulted in

[echo] PMD found ${pmd.failure.count} problem(s).

I assume that is the same meaning as PMD found 0 problem(s).


03. Conclusion: Veni, Vidi, Vici

I was able to complete all the tasks and fixed all the errors present in the stack project. I would not have spotted a lot of the problems without the help of the these tools. Ant and all the other tools are tremendously useful. I feel much more comfortable using the tools and learning how to interpret the messages.

At the end of this assignment, most of the fear has gone away. I guess once I got going, it just didn't seem so scary.

Reminder to self:
(1) The plugins folder that FindBugs looks for when invoked does not exist. Do I need one?

CodeRuler Review

Purpose:

Last week, groups were formed to write code for the IBM plugin game CodeRuler. Now that the fun is over, the task this week is to analyze the code formatting and see if it follows the coding standards of Elements of Java Style and our ICS supplemental standards. I was assigned to review Raqueno-Reeves's CodeRuler project. Their source code can be found at the following link: Raqueno-Reeves CodeRuler.

JavaDocs:

The JavaDocs are well written. The intro or description to the class was detailed and useful. It covered everything from purpose of class, strategy, and citation. Each method began with a good concise sentence that summarizes the function of the method.

My only complaint is when describing some of the parameters, perhaps there could be a more detailed description. Some parameter description seem redundant (e.g. xPos - x position). Perhaps a more useful description would be "the current x-coordinate of peasant/knight/etc". I just noticed some of the javadocs did not provide a description on the return value of certain methods. Considering the amount of detail in other areas, I think it was just a minor error that was probably overlooked.

Structure & Logic:

Everything looked good. At first, I was sort of wondering on the method movePeasants. It is quite short which made me wonder if it deserved its own method. But looking at it again, there is a lot going on in the setDir that is worth documenting as a separate entity. Creating the method movePeasants also keeps commands looking parallel in orderSubjects. It would have been weird to have seen....

makeUnits();
for(...){
  move...
}
moveKnights();

Formatting:

File	Lines	Violation	Comments
MyRuler.java	52,187,214,*	ICS-SE-Eclipse-2	Code exceeds 100 characters
MyRuler.java	94,231,236,*	EJS-9	Variable names represented by single char

I like the detail. I personally don't know how many one-line comments is too much. But I like the amount of information given. I thought the comments were helpful and the formatting is readable. Although I didn't look too much in detail, I think the code can be manageable.

Conclusion:

Well first on their strategy. Dang! This thing captures land pretty fast! Its initial knights don't normally last very long. But the amount of land claimed makes production of backup knights overwhelm the opponent. Back to the formatting, I am still fairly new to the standards introduced this semester. I may be misjudging at certain things. Considering it's only been a week since these concepts have been introduced, I thought Robin and Ron did a really good job formatting their code.

CodeRuler

Introduction:

CodeRuler is IBM's fantasy ruler simulation game which runs as a plugin to Eclipse ID. The goal is to come up and implement a strategy to not only stay alive but dominate the competition. As the player, we write the Java code for our ruler and try to beat out the rest.

In addition to writing the Java code to our ruler, this is also our first time working with another classmate as we continue to familiarize ourselves with Eclipse and hopefully have some fun.

Partners:

Yasuyuki Kaneshige
John Ly

Download Link:

CodeRuler (Kaneshige-Ly)

Evaluation Runs:

	yasuyukikaneshige -johnczly vs Gang Up Ruler	yasuyukikaneshige -johnczly vs Migrate Ruler	yasuyukikaneshige -johnczly vs Split Up Ruler
Test 1	634 – 36	477 – 5	444 – 48
Test 2	536 – 119	656 – 0	571 – 77
Test 3	549 -54	565 – 10	556 – 108

My strategy was simple. I had my knights attack the closest enemies. As simple as that was, it worked for well for 1-on-1 battles against the sample rulers. My peasants running around the border was an okay strategy but definitely not the best. However, it did claim land at an above average pace.

Of the three, the hardest to face was Split Up Ruler because it would divide up their knights. However, it is still predictable in the way that they still target peasants first. With my peasants running around the border of the map, it was fairly easy to defeat the knights and keep my castle.

Lessons Learned:

The one on one battles and one versus two battles were simple after a couple of runs. After observing one or two rounds I noticed their first target is the peasants. So adjusting my strategy accordingly, I won. However, four ruler (or more) battles, however, are difficult.

I wanted to implement something similar to this code my partner Yasu found. Peasants would find any unowned land and claim it. The knights also had a smart system of attacking. If attack level is low, they retreat and target peasants to replenish their strength. It was amazing to see but incredibly hard to implement. I just couldn't quite get my version to work in time so I had to revert back to my original strategy.

Coding-wise, I often found myself trying to clean up my code and trying to comment things properly for my partner to hopefully understand it. I usually do not have readibility as my primary focus but I felt it should be in this case. I guess this is because most of the code up to this point have been one-and-done. I would turn it in for an assignment and never look at it again. I think I need to get used to commenting and documenting so external developers can understand as well as myself if I ever need to look back. My audience has grown and so should my programming style.

Working with a partner is good and bad. There's always the pressure to do well because you don't want to see your partner suffer the consequences. But there's also lot of good that comes with the territory. Yasu helped come up with ideas that I probably would have never thought of. It's like the saying goes, "two heads are better than one."

Although my code didn't come out the way I wanted, our code still faired decent against the three other rulers.