[GSoC09] Devcathlon & GSoC

Reflecting on GSoC
The summer has ended for most of us and I'm glad to say that lots of progress has been made since my last entry. Devcathlon has given me lots of ups and downs in the past week. After successfully building the system with a persistent layer using Hibernate, many items such as the UI and game functionality still needed to be dealt with. Although not all objectives were accomplished in the last iteration of Devcathlon, I did have a chance to touch face with many of the issues that will need to be resolved in the next upcoming release of Devcathlon. They seem minor but can sometimes prove to be quite tedious and lots of code digging. This summer's venture has been the most time consuming, yet an overall rewarding experience. I felt that this program has given me greater insight into what development is in a larger based environment. The project at times could get very lonesome, though I did find ways to get motivated again. Many long afternoons and late nights have given me a real appreciation for time. During the last week of GSoC, I granted myself "time" to dedicate myself to the last moments of Devcathlon for this summer. It was difficult since my coding was usually compressed into one weekend which consisted of two days and a lot of distractions. The difficulty of clearing my mind from one project to the other proved to push me to my limitations. Something had to give; so I gave my last focus this summer to Devcathlon (I know it should have been my first and foremost focus). I know that it's too late to turn back the clock, but I've learned a valuable lesson and something about myself along the way.
Devcathlon's beginnings
The starting of Devcathlon was a very hodgepodge of wicked Wicket fun. People were still getting used to the framework's concept of MVC and Wicket's flexibility and support of components. The building blocks of Devcathlon centered around exploring these new grounds. I felt that this Summer was to pay homage to what I've learned from using Wicket and my previous encounters with other frameworks. I did incorporate changes to the workings of the profile and team sections, but others were left out due to time constraints. Using models is a must in the MVC framework. And using them correctly shows that you really know your stuff. I had to spending many moments re-reading the chapter on models and detachable models. They are very important in the development process and I wished it had been used more frequently in Devcathlon's 1.0 release. Also reusing views and controller functions ensure that you are also being DRY. I could see that some of those concepts were being injected late into Devcathlon, but others were still very traditional. I honestly saved what I could, and some were forgiven.
Working with Devcathlon
When getting along with an existing system (like Devcathlon) which had multiple people before you developing; you tend to see bits and pieces of the puzzle that fit together. Once you fit those pieces together then the next piece becomes a search. I felt that many of the things I didn't understand from the beginning was an inevitable search to find that missing link. After a while I got used to seeing the patterns people made in their code and what they would often do. I would also tend to have my opinions on certain paths people took when coding. I can't say that Devcathlon was entirely me, because it isn't. For this reason, it was difficult to make hasty changes to the code base. I wanted to respect the code done before me even though some things could have been done better and much more efficiently. I'll suggest some later, but the point is that Devcathlon had a personality to it as do any open source project out there. I've begun to notice how difficult it is for teams to collaborate and come to terms with what is standard.

Technical Review of Devcathlon (pre v2.0)
If you've got a class (model) then use it!
There are many instances when creating a form that I would see no models ever being used. Variables that can be easily referenced using the binding of an existing class model would have relieved the purpose of recreating them again in the form class.
Panels are great, but don't go overboard!
Following the DRY concept, one could really go overboard into drilling everything down to a label component is reusable and can be turned into a panel. Unfortunately this could lead to unnecessary growth of files which would make it much harder to manage. Just know that things can always be re-factored eventually after knowing that they are needed in more than one place.
Keep our styles clean yet explicit.
CSS files were all over the place and some still are and will need to be removed. A little helpful note on what the style pertains to would give nice clues as to where to find it in the markup. I found this to be difficult when certain styles were overriding others. Please make up you mind!

Find the project, here along with all the main updates: http://code.google.com/p/hackystat-ui-devcathlon/

Closing thoughts
The overall experience was quite a journey from start to finish. I had an absolute pleasant time, keeping my mind busy this Summer. Hopefully as school starts my mind will start to cool off... NOT! ;)
Also many thanks to my mentors who tried desparately to help motivate me and to keep me on track. Apologies to anyone I may have offended during the course of this Summer (I meant every word). And I wish the best of luck to future GSoCers.
Long live the code and tradition! Cheers!

[GSoC09] Overcoming a hurdle

If you were wondering why I haven't been blogging lately, then it's because I hit a "wall." I thought after taking the first few blocks off I would be free of trouble, another layer gets built, but only stronger and thicker than the last. I have to say that this project, in addition to this summer's workload has had a profound impact on my performance as a programmer. I've essentially realized my limits and as usual would draw insight from these experiences.
So I cleared my head this past week and started to extract what I had done on the branch copy (for db development) and slowly transitioned to the main interface in the trunk of our repository.

Below are some notes for myself and to future developers of Devcathlon:
Issues building a DB with a pre-existing system designed by multiple users:
These are the issues I ran into with Devcathlon that seemed to really give me the most problems.
The integrity of our DB:
There were many places in the application where (when we would test) that checks were made by the DB and not by the application before hand. This was mainly due to how DevcathlonTestHelper was built, to create and immediate delete a record, without concerning itself with other dependent constraints. In some instances, this would occur while testing team resignations which required two teams with a user being the team owner of one team and a member of the other. So by deleting one of the teams, this would cause a constraint error which is totally valid but not handled by our initial test helpers. Modifications were needed in this area.
*A special note on a test db: It would be beneficial to setup a Devcathlon test db for creating and dropping tables while developing in Devcathlon. This would keep your tests cleaner and ensures the integrity of all records.
In addition to changes to the DevcathlonTestHelper, the DevcathlonConfiguration needed to be initialized for all events defined in the configuration.xml file. This was needed in order for all event subclasses to properly map with the abstract event class upon declaring any particular event. Errors would occur when an event was not initialized by the ConfigurationManager.
The other problem relied on the fact that certain classes needed to be mapped (mirrored) that were originally built via JAXB. I.e.: The Project JAXB generated class needed to be mirrored in Devcathlon and renamed as TeamProject for persistence.

Thankfully seeing the "BUILD SUCCESSFUL" message (noted @ 5:45am this morning) appear after running 'ant -f verify...,' I finally felt a large weight lifted off of me. I'm now happy to know that the DB is settled and I'll be able to sleep better tonight.

This week:
Test events and single matches (08/19-20)
Work on UI improvements (08/19-21)
Clean-up old wicket panels (08/19-21)
Documentation: Installation & Issue notes (08/22)