It's Never Over Till It's Over

No.... TeamMS, we will get you! We will make our comeback just you wait and see.

While I get worked up occasionally seeing the score between all of our matches in Devcathlon, I have to wonder what flaws are in the system. Does this score really reflect the difference between our teams? If it does, maybe there's a loophole I'm not aware of that allows me to cheat in favor of my team? Also how does system usage feel? All of us have been working on this so much, we haven't really stepped back to see what could be improved.

Flaws in the System.

Let it be noted, I was purely looking up such flaws to "improve" the system, not cheat to achieve my ultimate goal of winning. o.O

1. Teams are not locked to a set of members at start of match -- As pointed out by Zhou, a team can start a match even with pending member invites. This means that team members can join or quit a team at any point Got a crappy player? Ask him to resign. Got a potential strong player that hasn't accepted? Ask him to join immediately.

2. Event Score relation to User. -- From what I recall, the EventScores were never tied to a user. I question the scores, since there is no true way to trace which member triggered the award/penalty. I admit my team lost the NoMIAs event, no doubt. But PassTheBuild? I think there were a couple of individuals on the other team who may have triggered in a negative way.
But I don't have proof!

4. Not enough system messages. -- Creating a team/match with an identical name is not allowed. But no error message is ever displayed on the page. Only on the console. I think a console ouput panel for all pages would be a good idea. It will even applies when a match is started, or when events run.

5. Team Record not 100% working. -- This is mainly my fault. I only tested this with the initialized data. It seemed to be working with positive scores, not sure what the cause is. Weird that it's not working with negatives.

6. Score in scoreboard should be more apparent. -- It was difficult for me to know what the score was without screenscraping the page for that information. Typically scores are placed near the team logos on a traditional scoreboard.
User Evaluation

I showed the system to a friend. The good news was he was able to quickly grasp that the application was a game based on the way scores are presented. He liked the layout, describing it as clean and easy on the eyes. He liked the simplicity of the menus.

However, his main issues revolved around system messages not being obvious (e.g. user needs to login). He also thought display of information could be cleaner. He didn't like how long the list the list of match events/explanations was and suggested using a vertical scroll for that panel instead. He would like to see simple things like "see details" to be displayed in one line instead of wrapped in its panel when there's a long match name. He also wished there was slightly more graphics to sort of "wow" him.

He found it somewhat funny that teams could be in negatives. It was something different but logical in respect to this game.

Top 5 Lessons Learned from ICS 414

(In no particular order)

1. Communication is key.

2. Working with a large group can be difficult.

3. Working with others can be helpful.

4. Everyone has something different to bring to the table.

5. High dependency on others' can be dangerous. Things can slow down if one falls behind. (similar to the "coupling" concept).

Who's that guy I see in the mirror?

I think this course really strengthened me in terms of dealing with reality. When you fail, it isn't as simple as just getting a low grade. You should get bashed because a client expects something working. We may not be so fortunate to have second chance opportunities. As far as improvements, I think I am more open to working with people on a regular basis. I found myself asking for pair programming opportunities. I don't know how many times I was at Sinclair library pair programming with Robin or Phillip.

Honestly, I think my programming skills are still somewhat unpolished, but I definitely feel capable. As far as what aspect I want to work on next, it may be to take more of a leadership role.

Wow. OMG! Phew. Sighs....

Well, that sums it all up right there. It was pretty unbelievable the different things we encountered throughout this semester. I can't say it was a great roller coaster ride. It was filled with more valleys than peaks. But I don't regret being a part of the process. I think I learned something from each individual and made some friends along the way.

Spring Break!

What better way to start off spring break than with an assignment? Haha. Well to be truthful, developing on Devcathlon the Spring Break isn't too bad. I don't have to worry about limiting myself to a certain amount of time because I need to do other assignments.

What I did:

As I write this blog, I have 2 commits since we disbanded Wednesday. I probably should have broken it up into smaller commits. It's just kind of hard to stop sometimes. Time flies by when things are finally clicking, then you don't want to stop.

I was successful in adding a mockup of both Team Manage submenu and Team Invitations. I got much farther wicket wise with the Manage submenu. I spent a lot of time focusing on actually adding a team. I fiddled around with the TeamManager and successfully created a team with no members, and myself as the owner. Right now, I have a genericInit() method that adds a team through Java code. So I then retrieve the list of teams to dynamically populate the Manage submenu. I just need to apply that with a wicket form and I think I am close to having a fully functional "Create a Team".

Contributed to packages:

• org.hackystat.devcathlon.ui.page.teams.manage
• org.hackystat.devcathlon.ui.page.teams.invitations
• org.hackystat.devcathlon.ui.page.teams

Number of Meetings:
1 face-to-face meeting at Holmes Building
2 Google Chat

DevTime:

Hehe... I had a little more time on the weekend than early in the week. o.O

My Issues:
Issue 44: Add mockup of Team Manage submenu. Status: Done.


Issue 49: Add mockup of Team Invitation submenu. Status: Done.

Issue 54: Implement Creating Team form. Status: Accepted.
Issue 55: Implement Team Invitation. Status: Accepted.

CSS - Confusing Stuff, Son

Alright, so the "son" was a cheap add-on to make the CSS acronym work. But hey, that's the best I can do. Anyways for the task this past week, we went back in time to rediscover our old friend (and enemy... sometimes), Wicket and start thinking of how to implement things for Devcathlon using it. Particularly this week, we worked on modifying a menu bar.

For now, our menu bars are not your fancy javascript drop-down menus, but it does it's job. Borrowing the CSS code from Kalsey (http://kalsey.com/2003/05/css_tabs_with_submenus/), we have menus bars with submenu's right below it. We needed to modify the bar so we address the following issues:

• support 10 submenus (wraps around screen, and overlaps content ?)
  
• realize the shortcomings of the submenus (due to its absolute positioning)

• indicate which page user is currently viewing (by making menu link bold)
  

Problems Encountered:

I was able to figure out the last two tasks, but not without some difficulty. The hardest one was indicating the page the user was viewing. From the beginning, I knew I wanted to add a class tag "selected" and just add a class property to the CSS making the font bold. After hours of slaying away trying to get it to work, I finally got it by adding this one line to each Menu's page (plus the CSS property in menu.css):

// from SubMenu14Page
// tags corresponding link with class, "selected" for CSS to make bold
get("SubMenu14Link").add(new SimpleAttributeModifier("class", "selected"));

My Shortcomings

The only task I was not able to finish was the 10 submenus. I assume the problem occurs when there are 10 submenus, the submenus wrap around the screen overlapping the page's content. I can only assume because 10 submenus displayed fine for me because I had my window maximized.

I tried adding padding & margins to the submenus creating whitespace between the submenu and content. Nothing. I tried adding margin & padding to the content with the same idea, but that was no good. Maybe the problem is the wrapping itself. I honestly wouldn't want my list of tabs wrapping around the screen if I purposely resized my window to be smaller.

Oh well... guess I'll find out from the others when this is all said and done. I gotta say though, FireBug (which Anthony Du pointed out to me in our last mockups) was extremely useful in this exercise. Because some of my css properties weren't refreshing when I modified the files, I just used FireBug to preview properties on the fly. Good stuff.

Distribution file: [Download Link]

Procrastination is Bad

Alright, this was my second event for Devcathlon and things were less scary and confusing. I wasn't completely lost, which felt pretty good because it meant I was making progress.

My event for this week was, "Don't Wait Until the Last Minute". Basically, the event calculates the average number of builds, commits, and development time (devTime) over the entire match. Within the last n days, if any two categories (builds, commits, devTime) exceeds their respective averages by over m percent, then the team will be penalized. The event is meant to discourage procrastination, so there won't be any last minute "rush-to-finish-up" moments.

Although the event specifications indicated to take the averages over the entire match, I opted for something a little different. If we were to continuously take the averages throughout the entire match, then the average may fluctuate if there is a lot of activity within the penalty period, making the policy a little more lenient (see below). To discourage this work around, I only took the average during the non-penalty period.


What I Learned

I feel through this exercise, I learned a bit more on where to look for data retrieval and retrieving different types of SensorData. I initially retrieved all data using DailyProjectDataClient. But after realizing that I need to retrieve data for an extensive period of time, it would take forever to loop through an entire match collecting 24 hours of data at a time. SensorBaseClient allowed me to retrieve data within a time period I specified.

During my earlier encounters, I had trouble retrieving commit data. But after a (long) look through some documentation, I was able to solve it by adding a property field that was missing. On a side note, I probably would have been deducted points for this event. While I did start early, I think I spent more time towards the end.

Trimming the fat

Just this week, we were assigned to starter events for Devcathlon (the Hackystat Game). Unfortunately, things didn't go as smoothly as planned so an extension was given so we would have a chance to improve our work.

My starter event, "Best Coverage", was done for the most part. But it did contain unnecessary parts of code (e.g. retrieving build data, when not really required) and could have been improved by adding static final to some of the instance variables.

I also broke one of our Coding Standards that was set back in ICS 413 (Software Engineering 1) when I used a while loop. I am ashamed. Other than this, the main issues I needed to address are as follows:

1. Build Data

I originally imitated the KeepTheCoverageHigh class by reading in build data as well. What's continuous integration build data have to do with coverage? Nothing really. But I figured it was used because the event will be run once a day, the same interval Hudson runs. So if there hasn't been a build, then there should be no new coverage either. However, the event now ignores that, and just checks for the most recent coverage information. This is probably better since its independent from the continuous integration data.

2. Static Final Variables

This is definitely useful for other classes to use. It's hard to keep a track of string variables especially ones that are used for specific fields. It's also a pain in the butt to use the hardcoded string each time I need the field. Making static helps because I can just access it by something like BestCoverage.dayStreakKey in any classes outside of itself. Well final is simply because we don't want or need the string to ever change.

It's also nice to look in one place and never need to hunt for every occurance of the string when a change is in order.

Besides that, my event should be done. I do feel awful that I went M.I.A. yesterday and most of today. I had a slight fever and cold and decided to rest. At least I wasn't M.I.A. for 3 days, or else Daniel's event would dock some points from me. I do notice a lot of errors has been happening and I think I need to look over those errors now. That way, I learn and I know what to do if that were to happen to me.

Are You My Mountain?

"Beyond the Mountain is Another Mountain" - Haitian Proverb

Taking one out of Ronn's book, I thought I'd open up with a proverb. It's weird though. I always thought that was a Chinese proverb since I've always heard my parents say it. Anyways, it basically means there will always be challenges in life (at least from my interpretation) . There is always something bigger and better than you. You can't conquer them all.

I think the concept sort of applies here. There are always challenges in life, and there are definitely various challenges in Devcathlon. My starter event/challenge, "Best Coverage", is an example of that. The goal is to be the team with the higher coverage, but you anticipate the other team to constantly challenge and overcome your previous percentile.

For those new to the idea of Devcathlon, it is a continuous integration "game" based on Hackystat sensor data. Teams are formed and when a certain pattern of behavior is exhibited in the sensor data, the team is awarded points. At the end of the match, the team with the most points win.

Best Coverage Rules and Specifications

• Wakeup once every 1 day.
  
• Team with the highest coverage is awarded 10 points
• If the same team has the highest coverage for 5 days in a row, award 10 points.
  

Programming Process & Problems

I was fortunate that my event was similar to the example given. I simply read in the match, looped through all the teams and recovered any recent commit records. With those records, I would compare coverage and return the highest team with that data. If the team with the highest coverage is the one specified in the parameters, then award them points. Otherwise, do nothing.

Initially I had the program loop through all the teams and award the team with the highest percentage. But in the event of ties, only one team would be rewarded in my original code. So I modified it. It worked out well because its consistent with all the other compute scoring methods where you have to run the computeScore method once for each team. So I decided to only award the team with points if it has the highest coverage PLUS it is the team specified in the parameters.

Example Pseudocode:

computeScore(match, team, event) {
 if(hasHighestCoverage(match, team) {
   awardPoints();
 }
 else {
   awardNothing();
 }
}

To award all teams,

for( Team team : match.getTeams()) {
 computeScore(match, team, event);
}

Testing

While that went well, testing wasn't so smooth at times. Because the wakeup period (or frequency of event) is 1 day, I tried to add build data and commit data with Timestamps 1 day apart from the previous. For some weird reason, that would throw an error. I noticed the example didn't require such, so I ignored it myself.

At first, I was only testing with one team in a match, which is not practical with such an event. I also realized the TestHelper class only included a simpleMatch method that included only one team. So I took the method and modified it slightly to add an additional team. It would throw an error when I tried to use the same project for both teams. So I created two separate projects to go along with the two teams to avoid the problem .

Final Thoughts

I don't know if it was a good or bad thing for my task. On the one hand, I was able to finish my task and did have to implement additional things that other events didn't require, such as the additional test method. However, my task was similar to the example so I don't really have experience retrieving data outside of coverage. I have noticed in my inbox, some of the discussion questions. I haven't been able to really answer most of them.

Hopefully that knowledge others are gaining will eventually be passed on to me. It feels like there's still so much to learn. I would definitely keep the screencasts. I have a very short memory sometimes and it's nice to know I can walkthrough the lecture and examples again.

Sensor this, Sensor that

Hackystat Data Retrieval

Wow, so this past week, we've finally gotten to see what it is generally like retrieving data from Hackystat's DailyProjectData records. This is to prepare us for the Devcathlon, which is based on Hackystat data. This was not terribly bad (thanks to the screencasts, see below). I just need some more time with the system. I guess these things will come more natural when I do this more and more.

There were a couple of new classes and libraries that were introduced. We mainly worked with the SensorDataClient where it processes the request and retrieves it.

I originally had problems because when I retrieved my sensor data instances. It did not match what I saw in my project browser, momentarily. I was not sure what caused the discrepency. I even looked into the ProjectSummary class to further look into what caused the discrepency by printing the tool and owner of each event. But it eventually went back to normal.

Otherwise, everything went smoothly.

Screencasts

A lot of information was introduced. As I mentioned earlier, this wasn't as difficult as it could have been because of screencasting. Professor Johnson had just began something new with our class this past week. He would record his screen (a.k.a. screencasting) and do basic exercises relating to Hackystat with us. When the lecture was over, he was kind enough to upload it (as .mov files) to the Hackystat project page.

I think the screencasts are pretty cool to watch. The camera zooms in enough so the viewers can tell make out everything. We have a good shot of the exact activity that is taking place. I typically enjoy learning by watching so I hope the screencasts continues. I don't have any particular concerns right now, since I can probably find my answer in the JavaDocs too.

The screencast are (most importantly) useful. There are times where I feel like, "Oh, I forgot something he shown us in class." Also, if someone is sick, they can easily catch up on what was shown in class. Overall, I think this is pretty cool. More teachers should do things as such. Then again, it'll be hard to motivate attendance otherwise.


Download Link: [LINK]

Devcathlon Proposal

After completing my reviews in my previous three posts, I think I see a lot of things I like from all mockups. I think if I had to choose, I would use mockup4 as the basis. Then inject a little bit of everything from the other mockups. Some memorable ideas and I remember are...

1. Create a Match

a. Data Facilitation Sliders, Calendar Wickets, Drop-down Boxes, and Text-Boxes

I definitely think one of the other groups had a great idea for the "Create a Match" page. It was John Ancheta's vision where he used Sliders to help set the scoring values of each event. Also on his page was the option to use preset scoring settings such as Beginner, Normal, and Advanced.
They could use the presets as templates and then use the sliders to customize any category they choose. Automatically the preset status would switch to "Custom".

I think this is definitely a useful thing that many would use instead of setting everything themselves. I personally wouldn't care to set all those scoring values myself, especially my first time. It'd be great to use the preset ones by the developers.

When I'm filling out a form, I prefer to click on things rather than typing if possible. So a calendar wicket would be nice for the user to input start and end dates. Drop down boxes help show the options for settings that need to be within a certain range. Otherwise, text boxes for everything else.

b. Match Commissioner

This is really a spin-off to Mockup6's GameMaster idea. But each match should designate one participant to be the Match Comissioner. The match comissioner would be the one who has control of the settings to their individual match. When editing match settings, basically he/she will have a screen similar to that of a "Create A Match" PLUS an additional section where he/she
can reward or rescind point events.

I think this is good because it helps reduce the responsbility of the GameMaster. Otherwise, the GameMaster will have hundreds of matches to manage, and when will he find time to do anything else? Let people worry about their own matches and the GameMaster can override other things and individual matches if he so chooses.

2. Compare Badges

This is a must if we're going with the badges idea. It's always fun to see where one stands next to someone you admire and think highly of. It's also fun to see how far you've come compared to that person. Hopefully people will use this as additional motivation to collect all the badges.

3. Expand/Collapse

Anthony's expand/collapse using the SpryCollapseablePanel is nice. We have two versions of collapsing on our pages and this definitely needs to changed to have only one. Otherwise our page looks like it was created by more than one team different teams (which it is but we don't want it to appear so).

4. Team Cards

My group talked about this if we decide to go with team badges. There was a whole problem of preventing freeloaders from getting the badges onto their developer's card. Our solution was to let those teams have their own card. Any team badge would be awarded to the team and not help your individual status. Teams could also level up, but we haven't exactly talked about a level system for teams. Maybe something low would be "School of Fish". Something high would be "Software Giants".

5. My Profile additions

a. Add a Friend

The feature has already been shown. Users clearly can associate themselves with friends. We just have to implement a way similar to how social networks handle these operations.

b. Trophy Wall

Maybe someone doesn't have the time to attempt collecting trophies but still helps contribute to a lot of the team's scoring total. This is an additional way of showing off past victories. Just like one would have in their child's bedroom to look at their trophies, each user would have a section on their page with a shelf-like table of trophies [see below for example of Yahoo's Fantasy Profile Card]. Sorry people, nothing lower than third place here. We don't want to award mediocrity.

It doesn't add toward your profile points but its still recognition. Clicking on the trophy would bring you to the details of the finished event.


6. Friends Leaderboard

In addition to the hall of fame, users might want to see how they simply compare to their list of friends. A simple table with each person's profile points and recent achievements would be nice.


Layout wise, I think we're pretty set. White and a chrome-like blue is a nice way to work around. There are some aesthetics that we could improve on such as the look and feel of the developer's card, but the overall concept is what was important. I think we have a pretty good foundation.

Review of Mockup4

The final review of the Devcathlon is my group, Mockup6.

How many "clicks" does it take to get to the center of what you're looking for?

I think our group tried to present so much information on one page. So the price we had to pay was that it requires users to click a lot of things to show everything. Of course, this can be solved with an "expand all" type link. Once users get used where things are, then the selective collapse and expand concept will be useful.

This design can be good and bad. We need to be careful on where and when to use this. Anthony took the time to understand how to get expanding and collapsing to work with AJAX and JavaScript. However, we didn't have time to see the final product and discuss it's effectiveness. In the end, it was cool but there was concerns if the use is suited for its purpose in class.

I think we used it best in our "Team" page. It fulfilled multiple purposes. First it presents all members in a simple list. But what if I wanted to look at who the strongest member is? Instead of navigating through each member's page, we can now expand their card by clicking the member's name and comparing two or more at a time.

Forms

We didn't get the chance to redo a lot of the forms. So we have the same problems as I've mentioned in my previous mockup reviews. The forms need to be reconstructed in a way where it doesn't seem overwhelming but still cover a lot of aspects. White space helps this.

Also as mentioned before in the other review, we could use some extra components like a calendar widget to help facilitate input. I saw some really interesting ideas in another mockup and think we can use a combination of everything in my proposal for Devcathlon.

Layout and Organization

I must admit, things varied on a page by page basis. We have two different expanding and collapsing features. One that actually shows the animation of collapsing (using SpryCollapseablePanels), while the other is an instantaneous collapse and expand. I credit both of my teammates for exploring these options. If we all finsihed the same time, we probably would have went with the SpryCollapseablePanel to maintain consistency.

But everyone's pages still maintained a nice level of readability. Anthony's team page used well placed white spaces in the expanding cells. Nicely centered with good padding all around. It really made it readable despite all the information it held.

Strengths:

1. Expand/Collapse --- This is definitely something useful that will help. This helps reduce the amount of information shown unless requested for by the user.

2. Badges/Achievement --- I like our achievement page mainly because I think unattained badges are shown in a nullified way. It is grayed out.

Weaknesses:

1. Inconsistent Tools --- We should have used the same collapse/expand throughout all our pages.

2. My Profile --- Too much content horizontally. Needs to be redesigned to neatly arrange the Inbox and Actions menu.

3. Redundancy --- Inbox and Actions appears on both the home page and the profile page. Although not a major issue, it's probably better to commit to only one place so users don't get confused. Initially we were going to take out the home page. But we forgot to relink the logged in page and remove the home page.

Review of Mockup6

Continuing from the previous post, I turn my attention to Mockup6.

Mockup6's also signs into the same home page. There wasn't much difference from the original. So basically their ways of performing actions is the same as that of Mockup5. All actions can be found on that one home page.

Navigation

A lot of the pages are easily reached within 2-3 clicks, especially with the menu bar at the top.
The way to get to the ranks & level explanation page was nicely incorporated into the developer's card. Instead of simply stating the level, the group Mockup6 used a miniaturized thumbnail/icon of the level and abbreviation. I think this is great idea.

First, pictures are more interesting than text. Experienced users would be able to tell immediately what the rank is. New and inexperienced users will likely wonder what the level system is. I can't say this for everyone, but the first place I would try to click is the rank itself.

I do have an recommendation though. If the rank and level mean the same thing, then perhaps the label should be omitted. Perhaps a tooltip (text balloon that displays when mouse hovers) would make sense here.

Layout and Organization

It seems everyone has a good grasp of properly using white space, because almost everything in this group looked evenly spread out. I didn't have to strain my eye looking for content between bodies of text.

There is one page that has weird spacing. I am not sure whether it was intentional or if its my browser that's displaying it improperly, but the gamemaster page has weird formatting. The form could use an additional space after each section. It would serve as an extremely quick, small area for your eyes to take a breath before continuing on.



Overall Feel

The layouts on each page all feel the same. They look consistent from page to page, with similar table designs and color scheme. One page does stand out and that's the achievement page. I like the achievements page. The alternating shades for each row typically helps viewers to easily trace a row's details. I thought it was something to interesting to see. Personally I think the achievement table doesn't need it since there isn't a lot of text in the description column. There is only about one line each. Plus the badge icons helps create more padding between each row.

But the idea is something that I would definitely keep in the back of our minds. In one of my later blogs about Devcathlon recommendations, I plan on incorporating the alternating row shades in a boxscore that contains only text and barely any spacing between rows.

Strengths:

1. Levels & Rank --- The ranks & levels page was nicely incorporated into the developer's card. Also instead of simply providing the text, the users provided a miniature thumbnail of the rank. To me it says a lot more than just putting the text. Those who know the system won't have to look it up. Those who are unfamiliar will click and learn.

2. GameMaster --- In class, we mentioned that there will almost definitely need an overseer of all matches and override controls. But in my previous two groups, we have been totally focused on a typical registered user's view that we forgot all about this. It's good to see a group thought of it. They have some good ideas on the gamemaster page as well such as the adding of badges and the changing of preset match definitions (such as beginner's, normal, advanced).

3. Slider bars --- Although not functional, but I think the concept is good. It gives users a visual idea of how difficult they are setting things by seeing the scale. This also helps facilitate input.

Weaknesses:

1. Integration --- There are negative to tight integration. Because it will be part of one big project browser, we would be forced to use HackyStat's layout and appearance as discussed in class.

2. Level Up System --- Don't get me wrong. I think the rank system they came up with is logical and interesting. But the level up system has some minor flaws. Because badges have different point values, it would be sort of cheat to level up for those humorous badges. For example, I could have 5 slacker type badges and level up. But someone with 2 true badges like 100% coverage and commiting regularly doesn't. Is that really fair?

3. Lack of true programming badges --- It's nice to have humor, but the true purpose of the badges is to award good programming practices.

Review of Mockup5

Well after 2 weeks of mockups for Devcathlon, its time to look at what we got. The benefit of having three different versions is we can take what we like from each and fuse it into one.

To not forget any one page, I'll think I'll just quickly put my thoughts about some of the pages I come across and then summarize the site's overall issues toward the end.

The Home Page: (Command Central)

The user interface is similar to what there was in the first round of mockups. The first page you see when you login is the home page. The home page consist of a lot of the links to perform the basic actions as well as new events that prompt your attention. Actions include:

• My Profile
• Create a Match
• Accept/Decline Match
• My/Others' Pending Requests

I think this idea isn't a bad one depending on the official layout of "My Profile" page. Because the home page is the first page you'll see each time you login, users would more likely remember some of the content on the home page (assuming it won't be congested with text and other content). At the cost of one additional click to the home page, all major actions (CREATE, ACCEPT/DENY, etc) can be found in one "stored-in-the-back-of-your-mind" page. The page is simple and somewhat empty, which is good because we don't want anything to take attention away from new activities. It forces you to be aware of new events.

I mentioned that this would be good depending on the "My Profile" page layout. If the My Profile page is cleanly presented and doesn't have too much content to divert your attention away, then the home page can be done away with. Basically, if the content can be presented in a way where it doesn't get lost with everything else on a page, then it's a perfectly fine solution.

Filling out the Forms

The forms consist of mostly simple text-boxes and dropped down boxes which don't appear confusing. It's practically impossible to screw up the dropped-down boxes to become invalid field parameters. So I can understand why there are no explicit explanations on the page. The text boxes are slight concern I suppose. But almost all the text boxes are fields such as descriptions, which are completely variable for each object.

The only text box that may cause an error is the "Team(s) to invite" box, if a specified team does not exist. But frankly, users experience similar procedures when registering their HackyStat projects, or even when sending emails. If a team does not exist, then I assume the page will just return an error message specifying the problem.

There is one unique field so far, and that is the "File Path" for the self-report photo proof. I like the way it is now. Users are only allowed to specify the file by using the Web Browser's file dialog box thing-a-ma-jig, so no problems should arise. I would hate to allow users to manually type in the file path and getting an error. Is it "\" or is it "/"? Or is it ":" for Macs? Let the web browser (or OS) figure it out.

Achievements

This group was definitely creative with coming up with good programming related achievements. The use of cat icons was funny but I think adding in different themed icons would help spice things up even more. I didn't quite get the relation between some of them.

Overall Screen Spacing (White Space and content)

The current layout of most pages is good. The use of white space in between most items are well used so contents are easily readable. The only form I think could use a little more white space is the "Edit Profile" page. The type of information collected is fun and interesting. But it seemed packed tightly together one after another. White space will give users a little breathing room with their eyes.

The page is also the longest of all pages, requiring users to scroll down. Personally, I don't like my forms to be too long. I prefer forms that breaks up into smaller parts with intermediate save points. I hate having to refill input values, especially on long pages, if something went wrong. I think MySpace has a pretty good concept where profile information is broken up into tabbed categories.


Organization

Most of the pages follow the same consistent layout. They all follow a 3-color scheme: white, light blue and moderate dark blue color. When there are pictures, they are the same uniform size (with the exception of the "achievement" page) aligned neatly in what I assume is a table.

I think the achievement page feels a little different. The varying widths of the images makes the page looks unbalanced. The black stands out a little too much. It feels like the rest of the page subtlely ties together and then BAM! Black! Like an octopus squirted ink on the screen.

Strengths

1. Compare Achievements -- Cool concept which brings out the individual competitive side. I think it could use a row that shows the total achievement points at the bottom/top to compare.

2. My Matches -- I definitely like the simplicity of the My Matches page. I think too much detail on that page makes it hard to manuever through. If the user wanted details, then he/she could easily go to that page.

3. Match Details -- The Match Details page has the feel of an official sport box score. The competitors main scoreboard is at the top. Play-by-play at the bottom. The only thing missing is a box score where it shows who contributed to what.

Weaknesses

1. My Profile --- The layout has changed, where the tables are no longer in-line but instead on a new line per table. This is most likely accidental though and can be corrected.

2. Achievement Layout --- The usage of black on that page stands out too much. Different sized images makes it look uneven.

3. File a Self-Report Even --- This is really my initial problem from mockup2, but it hasn't been addressed. I think this action would be common and might as well be on the Home Page instead of the Team Page. In the form, the user can select which match he wants to request that point award with a drop down box.

Badges, Badges, Badges

This week, we were assigned into new groups to continue building mockups of Devcathlon (the Hackystat game). My group consisted of Robin Raqueno and Anthony Du. I thought we did well as a group. We didn't start early but we still kept a reasonable schedule considering it was Super Bowl weekend and everyone just wanted to spend time with their families and friends.

So the focus for this mockup was to (1) create three new award events, (2) create three new badges, and (3) come up with a level system when a user accumulates so many badges.

As a group, we were able to quickly reflect on our bad habits and use that to our advantage. We all sort of just went "oh yea!" or "that's right." So between the three of us, we came up with the following:

1. New Events
• Falling Coverage Trend (DEDUCT) -- Often times we found ourselves writing code without test cases. We normally just bring our coverage back at the end. If the falling trend continues over n days, we felt a deduction is warranted here.
• Team Communication (AWARD/DEDUCT) -- Communication is key. Although hard to keep track, perhaps all involved users need to file once a week "Self-Report Event" with topics discussed. If no type of reports has been on file for 7-14 days, then it definitely indicates that no communication has been established. DEDUCT for no communication, AWARD for consistent. Awarded on a 1 or 2 week basis
2. New Badges
   
• First Time for Everything -- If the user successfully wins a match, this badge is acquired. It's encouraging to have a simple badge to start off your profile. (unless you're constantly stuck on bad teams) . That is why this badge is worth less points towards leveling up.
  
• Master of Building -- Successfully committed 25 consecutive times without breaking the build. How many times have we heard stories or experienced first hand where someone forgets to verify and the build is broken? We thought 25 times was a hard number to reach and if someone can reach that number, then he/she probably already developed a good habit of verifying before commit.
  
• Most Valuable Player -- The high scorer in a match regardless of win or lose. This is a tricky one. Because if the other opponents are crappy, then this badge can be easily attained. We can possibly have further restrictions, such as MVP of match where the "match point total" exceeded n points.
3. Levels system
• Human Evolution -- This just came up as a silly comment and we decided to roll with the idea. The evolving from chimp to man is an indication of intelligence. Just as we begin as crappy programmers to more experienced. No one wants to be called a chimp, so that should be extra motivation to gain badges and level up.

As a group, we came up with some pretty good ideas. I thought our team meetings were very productive. And that should be an additional rule to Team Meetings to get the points. I've been to meetings where it's just okay, "you do this, you do this." No in-depth discussion if my perception is the same as others. Is it better or worse?

Robin and Anthony both introduced different ways of expanding and collapsing content through AJAX and Javascript. I thought it was really cool and I think I definitely walked away with some new material. I definitely think we probably would have scored in the high 100's or even mid-200's. Good stuff, good stuff.

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.

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.