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.