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]