Off to the races

This week I made my first ever trip to a race track. "The Races" are a perfect opportunity for the class-based British society to strut its stuff, with innumerable options for different seating areas and "enclosures", each slightly more prestigious than the next. A number of people seemed to have paid extra for the ability to watch the races from the center section in the middle of the course; I can't see that the seating was any better but they did get to be seen by everyone else walking across the track before each race. Somebody even arrived by helicopter, parking their aircraft (and leaving it all night—you can see it in the photo above) in the middle of the course!
It was fun though with everyone in their posh summer dresses, running back and forth from the track to the tables to the betting windows. And we even managed to win enough to just about cover admission, food, and drinks. Not bad for an evening's entertainment.

Among other things I learned that the odds on the favourites shorten closer to the race as more people bet on them. So if you're betting on a favourite, you should do so early and with one of the betting houses near the track, which pay out based on the odds printed on your ticket. Conversely, if you're not betting on a favourite, you should place your bet at the last minute or with the betting windows, which pay out odds based on the final total of bets placed (they make a risk-free killing from a straight mathematical percentage off the top). Also, the "three-way" bets, which cost double but pay out 125% for a win and 25% for a 2nd- or 3rd-place finish, seem like a good idea for decently-ranked (but non-favourite) horses with odds between, say, 5-1 and 7-1.
So of course, now that I have a fool-proof guaranteed system, we're going to have to head back more often to capitalize on it. Or... maybe I should quite while I'm ahead.

Seaside 3 "Release Candidate"

You could say it's been a long time coming.

Seaside 3.0 began ambitiously and grew from there. We began (at least I did) with the goal of cleaning up the architecture, revisiting each aspect and asking what could be simplified, clarified, or standardized. As functional layers were teased apart, suddenly pieces became unloadable and a repackaging effort got under way. From this we realized we could make the process of porting Seaside much less painful. Along the way, we lowered response times and reduced memory usage, added 10x the number of unit tests (1467 at last count), standardized code and improved code documentation, added jQuery support, and, oh, did you hear there's a book?

The result? This release runs leaner, on at least six Smalltalk platforms and is, I think, easier to learn, easier to use, and easier to extend. Seaside 3.0 is the best platform out there for developing complex, server-side web applications. Is it perfect? No, but I'll come to that part in a moment. It is the result of literally thousands of hours of work by a small group of people across all six platforms. But this release also exists only due to the generosity of Seaside users who tried it, filed bugs against it, submitted patches for it, and eventually deployed it.

Deployed it?! Yeah, you see, not only have all the commercial vendors chosen to ship our alphas and betas, but our users have also used them to put national-scale commercial projects into production. I alluded last month to a conference session I attended, in which somebody made the statement that

The best way to kill a product is to publicly announce a rewrite. Customers will immediately avoid investing in the "old" system like the plague, starving the product of all its revenue and eventually killing it.

It was a shocking moment as I realized we'd attempted just that. At first we justified the long release cycle because we were "doing a major rewrite"; then we just had "a lot more work to do". Eventually there were "just too many bugs" and things "just weren't stable enough". And, finally, once we realized we desperately needed to release and move forward, we just ran out of steam (no quotes there—we really did).

I still think the original architectural work needed doing and I'm really happy about where we ended up, but here's what I've learned:

• When your wonderful, dedicated users start putting your code into production, they're telling you it's ready to be released. Listen to them.
• We don't have the manpower to carry out the kind of QA process that goes along with an Development, Alpha, Beta, RC, Final release process.
• We need to figure out how to get more users actively involved in the project. This could be by writing code but probably more importantly by writing documentation, improving usability, building releases, managing the website, doing graphical design, or something else entirely. The small core team simply can't handle it all.
  

Trying to apply these lessons over the past month, I asked for help from a few people (thank you!) and we closed some final bugs, ran through the functional tests, developed a brand new welcome screen, and managed to bundle everything up. We're releasing this today as 3.0RC.

We're not planning a standard multi-RC process. The "Release Candidate" simply signifies that you all have one last chance to download it, try it , and let us know about any major explosions before we do a final release, hopefully at the end of the month. From there we'll be reverting to a simpler process, using frequent point releases to fix bugs. 3.1 will have a smaller, better defined scope and a shorter cycle. I have some ideas but before we start thinking about that, we all need a breather.

I also have some ideas about the challenges that potential contributors to the project may face. But I'd like to hear your thoughts and experiences. So, if you have any suggestions or you'd like to help but something is stopping you, send me an email or (better yet if you're there) pull me aside at Camp Smalltalk London or ESUG and tell me about it.

Ok, ok. You've waited long enough—thank you. Here's the 3.0RC one-click image, based on Pharo 1.1 RC3 and Grease 1.0RC (just the image here). Dale has promised an updated Metacello definition soon. Enjoy!