Folks,

Here's the idea. Over the last few years, there have been a lot of changes
in Squeak. Lots of new technologies and interfaces have been added, or have
been made available. For quite a while, we've been talking here about the
advantages of using Squeak for software development. However, it seems to me
that there is a lot of frustration at the same time. The frustration comes
from a couple of directions, usually lack of documentation and lack of
example.

Here in the States there is a television program called 'Monster Garage'.
The premise is simple; take a stock vehicle and turn it into a special
purpose vehicle. For example, one of the shows revolved around converting a
hot dog cart into a 130 mile per hour dragster. The rules are simple. The
vehicle is designed on the first day. On days 2 thru 6, the vehicle is
built. Day 7 is race day.
There are two teams, a design team and a build team. The group is given 3000
USD to buy parts. If the challenge is successful, each member of the team
gets a set of tools. If unsuccessful, the team is forced to watch as their
vehicle is destroyed in spectacular fashion.

So here's the idea: There are a couple of areas that would help the
community in general. First, an example of how Squeak can be used in the
'real world'. Second, how to 'think in Squeak'. Third, to tie together some
of the newer packages so that everyone can see how the packages can be used
in practice. All of this placed in a public forum that people can look at.

I started thinking of an appropriate application. Here's what I came up
with:  a weblog server http://minnow.cc.gatech.edu/squeak/3437. Here's my
thinking on why this is an appropriate task. The application must be simple,
yet non-trivial. In my opinion, just a few clever snippets here and there
don't really get someone involved in a language. The weblog server is a
straightforward data in -> store data -> massage and output data batch
processing deal.

If you're a newbie coming from the traditional web processing world, Pearl,
Python, Java, etc you recognize the problem, and get a close first hand look
on why we're excited about Smalltalk. If you're already in the Squeak world,
it gives you a chance to see how to tie together some of the more recently
introduced parts of Squeak. I think that another important part of this is
to produce documentation saying, "Here's the design decisions we made,
here's how we implemented it" The documentation need not be verbose, just
straightforward.

Another important quality of this concept; the team will have a set amount
of time to finish. This won't be one of those things where you spend months
trying to just define the perfect weblog server with a billion different
features. Also, it limits the commitment of time of  the challenge
participants.

So, I'd like some feedback on what people think of this idea. On Monster
Garage, the team usually consists of a couple of experts in a particular
field, the rest are usually very skilled 'jack of all trades'. In the weblog
server, there is an HTTP part, a data store part, and a XML-RPC part. Also,
note that this is group developed, so there's the opportunity to introduce
things like Monticello and XP/Agile programming. In general, the challenge
should have as few rules as possible. However, you should also know that the
goal is to help people grok Squeak in the context of the application, not
build something that can withstand a thermo-nuclear blast. Not necessarily
contrary goals, but elegance and straightforwardness are easy to explain and
teach.

If this is something that people are interested in participating in, I'd
like to hear about it and some details as to what you think an appropriate
time frame for the challenge would be.

Jim Benson