This week was the start of real development on the Devcathlon system. We were divided up into 2 teams with my team being in charge of Matches and Scoreboard. We decided our goal for the milestone was the development some mockups. We had a meeting on Saturday where we divided up tasks. I was tasked with the Match main page and the Match's browse submenu since they were similar.
For both of those pages I created tables filled with some match info. I created Previous and Next links so that in the future a user can go through pages of matches. I implemented all the links and info in the tables in Wicket. This way I can have some idea of how I would implement additional features on the Wicket side.
Checkstyle complained about having whitespace after } when I was using for:
add(...) {
...
}.add(...);
so I made a change to it so it now looks like this:
add(...) {
...
}
.add(...);
It looks a bit more awkward and if a programmer in Eclipse used Source->Format it will revert back to the original format.
In the end I made 3 commits, added code to the org.hackystat.devcathlon.ui.page.matches.browse and org.hackystat.devcathlon.ui.page.matches packages. There must be something wrong with the sensor because even though I have spent time in Eclipse my current DevTime is N/A.
Monday, March 23, 2009
Monday, March 16, 2009
Going To The Bar
This week I had some practice working with Wicket and CSS. Specifically I was given an implementation of menu bars for Devcathlon and added improvements to it.
One of the first things I did was to add a menu along with 3 corresponding submenus. Then I implemented them into the Wicket code.
I made sure that the new menu corresponded to the body tag section-3 so that the bar will work correctly.
Then I created an additional 7 to showcase the limitations of the menu bar. At first I didn't notice anything wrong with the menu bar.
But if I reduced the browser size an issue popped up.
Clearly there was a problem in the CSS concerning browser resolution compatibility. Looking into menu.css I manage to narrow the problem down to either the subnav or content CSS code. After trying out using different positions and widths I managed to get a solution that worked.
Next in the test html files I changed h1 headers to h3 headers. This caused the submenus to misaligned. To fix this I went into the menu.css and changed the top value for the submenus from 84 px to 70 px.
The only problem that i couldn't solve was how to bold the menu item that corresponded to the currently displayed page. I couldn't figure out a Wicket solution but I did find this.
A file of the work I've done can be found here.
One of the first things I did was to add a menu along with 3 corresponding submenus. Then I implemented them into the Wicket code.
I made sure that the new menu corresponded to the body tag section-3 so that the bar will work correctly.
Then I created an additional 7 to showcase the limitations of the menu bar. At first I didn't notice anything wrong with the menu bar.
But if I reduced the browser size an issue popped up.
Clearly there was a problem in the CSS concerning browser resolution compatibility. Looking into menu.css I manage to narrow the problem down to either the subnav or content CSS code. After trying out using different positions and widths I managed to get a solution that worked.
Next in the test html files I changed h1 headers to h3 headers. This caused the submenus to misaligned. To fix this I went into the menu.css and changed the top value for the submenus from 84 px to 70 px.
The only problem that i couldn't solve was how to bold the menu item that corresponded to the currently displayed page. I couldn't figure out a Wicket solution but I did find this.
A file of the work I've done can be found here.
Sunday, March 8, 2009
Up To The Minute
This week we started development on the next group of Devcathlon events. I was tasked with creating the Don't Wait Until The Last Minute event along with John Ly. For this event we had to penalize any team that did their work at the last minute.
To get the data at first we thought about using the ProjectDailyData but it turns out it would have have taken longer to process compared to just using ProjectSensorData. Another issue I encountered was how the makeBuildData, makeCommitData, makeDevTimeData worked with timestamps. It turns out that if they were all created with the same timestamp then only one of them would actually work. So we had to go in and make sure that each time we used them they would have a unique timestamp.
The event that we created will calculate the penalty for each day of the penalty duration but it won't calculate the cumulative penalty score. There was nothing in the event description that said we had to get the cumulative penalty score, just the day by day penalty.
There's still an issue of how penalties are calculated. For this event we used the BaseScoreWeight as a positive multiplier for the penalty since there was no way to gain points in this event.
To get the data at first we thought about using the ProjectDailyData but it turns out it would have have taken longer to process compared to just using ProjectSensorData. Another issue I encountered was how the makeBuildData, makeCommitData, makeDevTimeData worked with timestamps. It turns out that if they were all created with the same timestamp then only one of them would actually work. So we had to go in and make sure that each time we used them they would have a unique timestamp.
The event that we created will calculate the penalty for each day of the penalty duration but it won't calculate the cumulative penalty score. There was nothing in the event description that said we had to get the cumulative penalty score, just the day by day penalty.
There's still an issue of how penalties are calculated. For this event we used the BaseScoreWeight as a positive multiplier for the penalty since there was no way to gain points in this event.
Wednesday, February 25, 2009
On Your Mark
This week we began actually programming for the Devcathlon through Starter Events. The event that I worked on involved rewarding teams who build before they commit. They would be rewarded if they build locally before committing and penalized if they didn't. There are also bonus points that occur when a team is on a build-commit streak. More info on the events can be found here.
One of the problems I faced while programming was figuring out the scoring. Eventually I figured out that BaseScoreWeight was a multiplier for the score. But that lead to another problem with the scoring: deductions. Because of the use of the multiplier, point deductions was made much difficult. I would have gone into EventScore class and add the capability to hold deduction info. That way the points computation would be made much easier. Right now, probably the only way to get deductions to work correctly is convert them into fractional deductions, which is rather awkward. My event was later changed so that I wouldn't have to worry about deduction weight but I think this is still an issue that needs resolving.
Another problem that I had was making commit data for test cases. I made a makeCommitData method in DevcathlonTestHelper class to help me out.
Another challenge I faced was trying to figure out how the sensor data type worked. This page help me greatly but I'm still a little sketchy on some of it. Eventually I found that there were 2 different sensor data types, build and commit, that I had to make into separate indexes.
I had some difficulty with getting successful test cases. I found that it was mostly issues dealing with the timestamps of the build and commit data such as timestamps that were made that weren't in the time interval I was looking for or timestamps of builds that were after commits when they should be before.
The Devcathlon program can be found here.
One of the problems I faced while programming was figuring out the scoring. Eventually I figured out that BaseScoreWeight was a multiplier for the score. But that lead to another problem with the scoring: deductions. Because of the use of the multiplier, point deductions was made much difficult. I would have gone into EventScore class and add the capability to hold deduction info. That way the points computation would be made much easier. Right now, probably the only way to get deductions to work correctly is convert them into fractional deductions, which is rather awkward. My event was later changed so that I wouldn't have to worry about deduction weight but I think this is still an issue that needs resolving.
Another problem that I had was making commit data for test cases. I made a makeCommitData method in DevcathlonTestHelper class to help me out.
Another challenge I faced was trying to figure out how the sensor data type worked. This page help me greatly but I'm still a little sketchy on some of it. Eventually I found that there were 2 different sensor data types, build and commit, that I had to make into separate indexes.
I had some difficulty with getting successful test cases. I found that it was mostly issues dealing with the timestamps of the build and commit data such as timestamps that were made that weren't in the time interval I was looking for or timestamps of builds that were after commits when they should be before.
The Devcathlon program can be found here.
Wednesday, February 18, 2009
Making Sense of Hackystat
Recently I started working with the Hackystat API. The goal was to learn how to retrieve sensor data from Hackystat and make use of that data. I spent some time watching a screencast for Hackystat which can be found here. One obstacle that I had was in figuring out how to retrieve data from a user. From watching the screencast I learned how to retrieve data from a specific project but not. By looking at the JavaDoc it didn't take me long to find the getSensorDataIndexLastMod method that fitted my need.
I also had to create another program to make use of sensor data by finding out the day of the month that had the most sensor data. To go through the days of the month at first I used a for loop but later I realized a while loop would be preferable because there were different number of days for each month.
I found the screencast to be very informative and helpful as I went along with my programming. I wouldn't mind having a mix of screencasting and supplemental notes.
The results of my work can be found here.
I also had to create another program to make use of sensor data by finding out the day of the month that had the most sensor data. To go through the days of the month at first I used a for loop but later I realized a while loop would be preferable because there were different number of days for each month.
I found the screencast to be very informative and helpful as I went along with my programming. I wouldn't mind having a mix of screencasting and supplemental notes.
The results of my work can be found here.
Monday, February 9, 2009
Devcathlon UI Recommendation
For my recommendation for the UI of Devcathlon I will use Mockup 5 as a base. If the Inbox is implemented I would add it to the home page. The Inbox will either be connected to an internal mail system or be linked to an offsite mail system.
For the My Profile I would use the layout of Mockup 4 but remove the sidebar with the Inbox and Actions. I would switch the My Teams table with the one in Mockup 5. I would also add the About Me box from Mockup 5. To be honest none of the leveling systems appeal to me. My idea for a leveling system is based on how much points a player earns through matches and events. I would like the rankings to be related to computer culture such as Hacker and Cyber Punk to match the theme of the Devcathlon. Information on how the system works can be found in the FAQ.
For the Achievement page I want to use the color scheme and layout from Mockup 6. I would prefer if the icons were bigger while the small version of those icons can be used on the gamer card.
For a details on a single match I want to use the page from Mockup 4 but I would add Recent Points and Recent Activities from Mockup 5 and 6.
For the My Profile I would use the layout of Mockup 4 but remove the sidebar with the Inbox and Actions. I would switch the My Teams table with the one in Mockup 5. I would also add the About Me box from Mockup 5. To be honest none of the leveling systems appeal to me. My idea for a leveling system is based on how much points a player earns through matches and events. I would like the rankings to be related to computer culture such as Hacker and Cyber Punk to match the theme of the Devcathlon. Information on how the system works can be found in the FAQ.
For the Achievement page I want to use the color scheme and layout from Mockup 6. I would prefer if the icons were bigger while the small version of those icons can be used on the gamer card.
For a details on a single match I want to use the page from Mockup 4 but I would add Recent Points and Recent Activities from Mockup 5 and 6.
Mockup 6 Review
Along with the other recent mockups, Mockup 6 doesn't change much from the design of Mockup 2. The registration page, password recovery page, and create team page should have been removed due to integration with Hackystat. Same goes with being able to change email and password.
The leveling system might be difficult for those with little knowledge of the military to understand. Also I seriously doubt it's possible to create 120 achievements that is needed to hit the highest levels. Like the other mockups, the information on how the leveling works should be found in the FAQ.
There should be a link to the Achievement page on the drop down menu. Some of the new achievements that they added are questionable. For example I don't think someone should be reward for being a slacker.
Like the other mockups, the team profile page still needs an example of what it will look like with more than 1 project.
The My Matches page allows some info at a glance on a match. Still the amount of information should be reduced assuming there will be a large number of matches. Also like the other mockups, there are 2 link to My Matches in the drop down menu.
One of their strong features is standardizing achievement icons and improving the color scheme for them. Having information at a glance for My Matches is useful but one has to be careful not to go overboard. Some weaker points include some questionable achievements. It will be difficult to figure out someone's level at a glance using their leveling system. Also the number of badges needed to level should definitely be brought down.
The leveling system might be difficult for those with little knowledge of the military to understand. Also I seriously doubt it's possible to create 120 achievements that is needed to hit the highest levels. Like the other mockups, the information on how the leveling works should be found in the FAQ.
There should be a link to the Achievement page on the drop down menu. Some of the new achievements that they added are questionable. For example I don't think someone should be reward for being a slacker.
Like the other mockups, the team profile page still needs an example of what it will look like with more than 1 project.
The My Matches page allows some info at a glance on a match. Still the amount of information should be reduced assuming there will be a large number of matches. Also like the other mockups, there are 2 link to My Matches in the drop down menu.
One of their strong features is standardizing achievement icons and improving the color scheme for them. Having information at a glance for My Matches is useful but one has to be careful not to go overboard. Some weaker points include some questionable achievements. It will be difficult to figure out someone's level at a glance using their leveling system. Also the number of badges needed to level should definitely be brought down.
Subscribe to:
Posts (Atom)