I’ve always wanted to have a deeper understanding of internals of open source projects, to perhaps satisfy my hunger for knowledge of how things are implemented in real world, learn the tricks and design technics from people way smarter than myself, to become a better developer, and to perhaps being able to contribute to a successful open source project.
Over the years, I’ve read books like Understanding Linux Kernel , How Tomcat works , and Mac OS X internals
When about 7 years ago I became a user of the Spring framework (back then it was just a proprietary framework download from Rod Johnson’s excellent book which started revolution in enterprise Java computing), I’ve jumped on board with a very enthusiastic crowd including Juergen Hoeller, Thomas Risberg, and others, who became the very first committers of the Spring framework. I started reading the source code trying to understand how things work. I was interested in the new (back then) concept of Aspect-Oriented Programming (AOP) and Spring’s approach to implementing it. I’ve started hacking the generic Interceptors and emailing them Rod so he could commit them into the CVS repository. One day Rod sent me an email saying “Why don’t you do it yourself…?” and granted me a committer access to their CVS repository. That was very satisfying to me. Later on I’ve contributed code to several areas of the Spring framework including email subsystem abstraction, DataFieldIncrementer abstraction, various AOP areas, etc.
Fast forward to around the beginning of 2006, when Ruby on Rails took the computing world by the storm with their opinionated ideas of convention-over-configuration, and the like, I’ve heard about ‘Groovy on Rails’ (the original name of Grails) and decided to check it out. I was skeptical because there were attempts in the Java world to create a framework similar to Rails e.g. Trails, Sails, etc. The results were poor, and those never took off. When I checked Grails, however, it was immediately obvious to me that this ‘WAS IT!’. The elegance of Groovy’s dynamic features combined with the power of underlying technologies like Spring and Hibernate made me look no further. I’ve signed up for the mailing list and started participating in early design conversations (mostly observing), etc. I started playing with it (starting from version 0.2). But as usual, I was curious how things worked under the hood. So, I started reading the code, and I even contributed few early patches that Graeme Rocher incorporated into the code base.
Present days – I’m not very active in the open source world anymore (well, apart from writing and releasing Grails Crowd) given the busy family life, becoming a father and all the bullshit at my day’s job i.e. trying to ‘stay afloat’ in this tough economy, etc. But nevertheless, I’d love to get back into it and start contributing. Grails project for example has tons of work to do. But in order to start contributing, one needs to understand its internals, how things work. One obvious way would be to read the source code without any guidance, but I’ve always wished there was some kind of a ‘jump start’ in the form of a writing about inner workings of the framework, showing major pieces of code and how things designed in interact with each other. There is nothing like this exists for any major open source Java framework including Spring and Grails. To try to fill this void, I’ve created a ‘community effort’ called Grails Internals Handbook For me, the purpose of this effort is twofold – first by trying to describe how major subsystems are implemented in Grails, I’d need to force myself to read the code, understand it, which will make me a better ‘hacker’; another is to provide a useful piece of info on Grails internals to inspiring Grails hackers wishing to start contributing, but wouldn’t know where to start.
I really wish that that Grails developers community would find some free slice of their busy life and be able to contribute to this book.
Happy hacking.
Later…