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.
Subscribe to:
Posts (Atom)