Out of sheer curiosity I checked out the RadRace results for 2006 from Javapolis (is there a running theme here?) to see what toolkits the guys who seriously churn stuff out quickly are using. The toolsets were as diverse as anything you’re likely to see, some proprietary, some big-vendor, some open-source. What I thought was interesting was the conclusion at the end of the keynote presentation – Whatever toolset you choose, get to know it in detail and stick to it. Makes sense. It’ll always be faster if you’re not reaching for the manual every time you need to do achieve something that’s fairly standard.
However, the only way to learn a toolset is to do up a system with it. Maybe in evaluating a new tool, which seems to be a regular thing these days, we need an example project that you have to work out. By coding it up, you learn what the strengths and weaknesses of the toolkit are, and have an objective basis for comparison. If you can exclude the domain knowledge factor, such as by having the database design already done and well understood, it could be a useful learning tool. And far better than the standard handholding projects covered in most framework books, since you have to work out stuff for yourself.