A well-written book on producing Open Source

Due to a recently found interest in applying open source project management ideas in a closed commercial software development environment, I started reading a great (and free!) online book - Producing Open Source Software by Karl Fogel. Although not exactly a "new" book, it still contains a lot of fresh ideas and field experience on producing OSS.

Rubber duck debugging revisited

I have always enjoyed thinking out loud - especially when thinking about complex technical problems, but have never given much attention to this process until a colleague of mine pointed out a catchy term (which for some unknown reason I wasn't aware of) for this process - Rubber Duck Debugging. Other (common?) variations of this are the Cardboard Programmer and the Cone of Answers. Here are a few more patterns I thought of naming (haven't tried them all in real life, though):

Preschool debugging

Goal: To have a more interactive communication experience as compared to a cutout or a ducky.
Method: You need to have really good relations with a colleague's preschool kid for this. Or better yet, to have your own offspring ready for action. Take a 3-5 year old kid to your computer and start explaining the piece of software you're working on. Use domain-specific language as you please. Continue until you get tired of the why-questions or one of you gets cranky. Don't be surprised if it is you - the little devils can be quite persistent.

Grandmother debugging

Goal: To explain the software details in non-domain specific terminology.

Method: Similar to preschool debugging, but "use" a foreigner to the domain of your software solution. Bonus points for actually employing a grandmother. Try to explain the software in terms that the foreigner would understand. Use analogies, if needed - extra bonus points for applying sewing or knitting terminology in case of thread management issues.

Blind man debugging

Goal: To find lack of coherence in a user interface design.

Method: Take a "blind" subject - a person that has never seen the user interface you have designed, give the subject a piece of paper and a pen. Take a usage scenario to be executed on the interface and describe the user interface elements to the subject. Let the subject draw the UI elements in the execution order of the flow, eyes closed. Take the drawing and compare it to the described design - UI elements that are most inaccurately positioned compared to the original are probably the hardest to find for a regular user. (Haven't tried this one - just based on a hunch)

Persisting mutable objects in Tapestry

Since Tapestry makes it easy to persist application state by using the @Persist annotation, I tend to have a habit of using mutable state objects and then stumbling on problems when changing these mutable persisted values do not result in updates to the underlying session store.
Here's a sample page class:
On the page template, we simply display the current state and an action link to call the onActionFromChangeState event. Everything seems to work - the state object (List) is lazily initialized and new items are appended to it.
Long story short, Tapestry does not detect the changes to a mutable persisted state object. Unfortunately, the way HTTP sessions are usually implemented in many servlet containers, changes to the mutable state are still persisted (bypassing the Tapestry's persistent field invalidation mechanism). This can cause unexpected and hard-to-trace problems later, when trying to switch the persistence strategy for a specific state variable, e.g. from the session to the client strategy.
For instance, here we try to change the previous sample to use client-side persistence instead:
But when calling the onActionFromChangeState, nothing seems to happen. The state is transferred from the server to the client and back, but this always contains an empty List. This corresponds to the empty List initialized on the first render request.
To demonstrate that this is really the case, we can use a simple hack:
Now the changeState action works once again, since the PersistentFieldConduit responsible for recording the change of the field value is used. Although this kind of a "hack-y" approach works, the moral of the story seems to be quite clear - be very careful when persisting mutable values.

Bean property expressions with Java and Tapestry

Tapestry has a couple of nice features for accessing bean properties in a loosely coupled way. One of them is a reflection-based PropertyAccess and the other one a runtime-generated proxy called PropertyConduit. Both of these are very comfortable to use - just specify a property expression and you're good to go. Unfortunately, in larger projects, these String-based property expressions tend to become a bit difficult to maintain as you're re-factoring the beans the expressions refer to.

So, just for fun, I decided to experiment with an alternative for PropertyConduit - to create the conduits during compilation and have an ability to chain these together into more complex expressions. For instance, if we would have two bean classes:

Then we could refer to and get the "bestFriend.name" property as:

This would ideally be type-safe and the *Properties classes auto-generated.

The initial proof-of-concept that I came up with contains two classes describing the property expressions:

For testing purposes, three classes were created:
To automatically generate property expressions for a set of bean classes, an annotation processor was implemented, which yields the following result (for the bean classes specified above):

And a simple test scenario to check that everything works as expected:

Will need to test this out on a larger scale now, for possible performance and memory usage problems :)