Solution To Sequential Transaction Processing In Message Driven Beans

In a WebSphere Application Server transactions will come off the JMS queue sequentially but will be processed in parallel by having a message driven bean be instantiated for each transaction. This can cause some transactions to finish processing before other transactions that were further up in the queue. Obviously this can cause havoc if you need your transactions to be processed sequentially. The solution is to limit the number of message driven beans that can be invoked.

For WAS 7.0 enter your admin console and go to your "Activation specifications" setting under Resource/JMS. From there go to the setting page for the activation specification that corresponds to your MDB. On that page there should be a setting called "Maximum concurrent MDB invocations per endpoint" which should be set to 1 so that only one MDB can exist at a time.

Crossing The Finish Line

After several months of effort, the first prototype for the Devcathlon system has been completed. I am actually rather proud at what I've been able to accomplish. I've learned quite a bit this semester about Java, Wicket, CSS and even non-programming lessons like conflict resolution! Probably the most important thing I learned was how to work well with others.

Future Improvements
Here are some ways Devcathlon can be improved in the future:

For the front page the matches panel and comments panel should either be paginated or use some other way to limit the amount that is displayed. The comment panel should at least display the user who made the comment. The event panel should display the name of the event. The dates in the event panel need to use a better display format. There are too many event scores with the explanation "No explanation for this score was provided". In the future these events needed to add explanations.

I don't understand why by default a user's e-mail is in brackets in the Profile page. For the Profile Browse page there's no hint that clicking on a person's picture will link to the person's profile page. Either have the picture change when a mouse hovers over it or place the link somewhere else.

In the main Match page when clicking on a "see details" link that is located past the first page of pagination on the Matches panel it will refresh the page and set the pagination back to the first page.

When creating a team there should be an option to pick and choose who's going be on a team rather than inviting everyone who's on a project. By doing this it will avoid a user accidentally accepting an invite to a team that he doesn't belong. Also when invites are created the person creating the team should be able to make a message that describes the purpose of the team invite.

When a match is created, the person creating the match should also be able to make a message that describes the purpose of the match invite. At the moment matches can be started when all team owners accept even if there are team members who still have to accept or decline invitations. This can cause scores to be skewed. Once team creation allows the ability to choose specific team members, as I suggested in the last paragraph, matches should not start until all members of each team have accepted team membership. As for whether or not a team member can be added or removed during a match, that is a grey area.

What Doesn't Work
The "Most Team Wins" and "Most Team Points" panels in the Hall of Fame page don't work at the moment. It's understandable for all developers in "Most Developer Points" to have 0 points since there aren't any User specific Events in the system. Those types of events should be created in the future.

Outside Feedback
In order to get a fresh pair of eyes, I asked my friend Vincent who is studying abroad in Japan to give me feedback on the system. He found to UI to be too bright. It might be a good idea to have custom UI styles for different users.
He said that the front page should have a statement stating the purpose of Devcathlon. He found the Events panel on the front page to be confusing with too much redundancy. He suggested that Events should have tooltips so that when a user hovers their cursor over them they get a short description. He also suggested that the "Most Team Wins", "Most Team Points", and "Most Popular Events" panels should be condensed to top 5. At the moment it displays all the teams and all the events in the system.
He noticed that "Records & Matches" panel in the User Profile page and the Team Profile Page needed links to their corresponding match detail pages. For the "Hall of Fame" page he suggest it will look better if all the panels were the same size and that each of them should contain only 10 items.

Top Five Lessons Learned from ICS 414

1. Communicate. With this project I realized how important it was to let everyone know what you're working on and to find out what others are working on. This doesn't stop when the meeting is over. While working on files that may affect other developer's work, it's prudent to give notice to that developer when doing so in order to prevent future conflicts.
   
2. Rise up to the occasion. When you see something that needs to be done you need to have the initiative to do it without anyone telling you to. I found myself throughout this project on multiple occasions having to take on additional work in order to make sure the project reached completion.
3. Patience. Sometimes I found it really difficult to wait for a developer to finish a component that I needed to rely on. Sometimes it was warranted and I had to take over and do it myself. Other times though the component was completed in a timely manner and I was worried over nothing.
4. Don't assume the worse. I'm going add a caveat to this one by saying that the individuals in the peer review who I don't want to work with in the future hasn't changed. For the other individuals though I would say that over time they have improved quite a bit.
5. Make use of each individual's skill set. Some people are good a Photoshop, others at CSS, and others at coding. The trick is to make sure that the amount of work they're given for their skill set is equivalent to others.

So It Begins...

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.

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.

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.

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.

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.