[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!