It's Not Fun to Mock Someone

In my previous post, I mentioned that we were going to be working on a game called Devcathlon, based on Hackystat sensor data. Well this past week, I got first taste of what the game is like.

Our task was to create a mockup of the site and walk through the typical activity a user would experience if the game were to be played today. I tried to apply my background in games to Devcathlon. I play fantasy basketball and I thought it would be clever to model it after it. It made sense since fantasy basketball (or any sport) basically compares statistics just like Devcathlon would. What came out of that was:

• A week-by-week scoreboard -- Shows who was in the lead, who has made progress, who has fallen, etc.
• Breakdown of events -- Who contributed to what categories.
• Community Approval of Self-Reported Events -- Let the participants as a whole approve/deny self-reports. Minimum of half of the remaining participants must approve.

Other noteworthy things that came out of our mockup included a drop down type menu bar (that Phillip found) and a developer's card with achievement or badges if you will. The achievements server as a marker for individual excellence. It's fun to collect and used as bragging rights.

As a participant in the game, I think we violated a lot of the events. I didn't start or commit early. DEDUCT POINTS. It felt like we waited towards the last minute. DEDUCT POINTS. The only real positive I felt was commiting often... but only within the last 72 hours. It's hard to apply events such as "Build OK" since we only worked on HTML pages. But overall, I felt we didn't deserve any score higher than a 50, which hopefully isn't high enough to win any match.

Unfortunately, all of us did not know the proper way to set up the project on Hackystat since this is unusual with no Hudson and actual build files to configure the sensors with. So I can't provide a valid screenshot of our projects health. But judging from the log messages, the bulk of our commits were on the weekend. DevTime seems to be the only working sensor and that mostly took place during the weekend too. DevTime could be misleading though since Phillip and myself used Dreamweaver a lot to help create the pages with tables, outside the reaches of Hackystat.


So how did we score? Again I would say 0-50. It could have been in the hundreds had we spaced things out properly. Would we have won that event? Score-wise, no.... I sure hope not. But did our pages turn out alright? I would say so. I know this may contradict the encouragement of good practices. But if the final product is somehow better regardless of method/practices, I think that should be a bonus. Afterall, we don't want to encourage crappy programs either.

Games.... not all fun and games?

When I first heard that our project, Devcathlon, this semester for Software Engineering was going to be a game, I was extremely excited. This is the reason I first went into ICS. I didn't anticipate any jaw-dropping graphics or excellent music to be involved. But I've played games lacking one or even both, and still be fun and enjoyable. Can Devcathlon succeed as one of those as well? Hopefully.

What is Devcathlon?

Thankfully not a marathon or decathlon, because Wii Fit classified myself as "overweight" so I don't think I would have the endurance to participate. But Devcathlon is a game whose goals are to promote good software development practices. Software developers face off individually/collaboratively and attempt to accumulate the most points for a set period. Players are awarded points for positive practices, and lose points for poor practices. A scoreboard will be available to see where each player/team stands.

Events have already been determined and the rationale is based on the rules we try to follow in our Software Engineering course. Examples are commiting early and maintaining high test coverage. A more complete list can be found in the Events Wiki of the project.

Qualities of a Good Game

After looking over the weekly readings provided by Professor Johnson, it seems opinions vary. But there are certain traits that are commonly mentioned. Challenges/Goals, Rewards, and Story/Character Development are some that I recall.

Challenges/Goals

Games that are too easy tend to be short or cannot hold someone's interest for an extensive period. Games that are too difficult can frustrate a player and also lose the player's interest. So a balance of the two is needed. There also has to be an objective for the game to end. If the goal doesn't seem worth it, people may not play the game.

Rewards

A game can be very boring or difficult if the story progressed and no apparent growth or upgrade occurs. Tasks will get harder and your character remains the same. That seems dull. Rewards in the form of powerups, weapons, or new techniques can help reduce the feel of repetition and same-ness.

My Personal Findings

Googling "What Makes a Good Game?" leads to a bunch of hits. Besides the ones already mentioned, most articles refer to graphics, gameplay, and sound. Lot of these seem hard to incorporate at the same level as those at the commercial level.

Replay Value

In an article titled "What Makes a Good Video Game?", replay value was mentioned also mentioned. I think this is debatable depending on the game. Some games with rich storylines don't have replay value but are still considered a good game. I think since our game Devcathlon lacks a strong (or any) storyline, we definitely should try to strive for good replay value.

Other articles with similar ideas discussed:
The Other Eighty Percent: What makes a video game good?

Open Issues (edited 1/19)

Initially I thought it would be cool to somehow incorporate the points toward a more interactive game. But after reading feedback in Professor Johnson's email, it seems to be a whole different thing and direction we want to go in. So here are some thoughts building on what Professor Johnson mentioned in his email...

• Developer's Card
• Building on someone's idea of "bragging rights", it would be cool if we implemented something similar to the Xbox Gamer Card concept. (see below for example)
  
• Determine a list of achievements that a good software developer would accomplish. When a user accomplishes a task, it will appear on a card for individual bragging rights.
• Generate HTML code so you can show off the card on any web site.
  
• Examples: "Committed 25 times without breaking the build.", "Coverage has reached a 100% (minimum 1000 lines) ."
  

• Incorporate Story/Character Development (edit)
  
• At some point, it would be cool to see this "game" be more than just points and texts.
• I originally had an idea of a boxing game and using team stats toward the boxer attributes.
  

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.