Russian Continuations

Andrey Larionov just posted a Russian translation of my article on the use of continuations in Seaside. Hopefully it's accurate... I certainly have no idea. :) He says he's going to try to start a series of articles on Seaside so keep an eye out for that if you can read Russian.

In other news, I'll be on vacation in Portugal for the next 10 days, likely without Internet access. I'm hoping the weather will get warmer than currently predicted but as long as the rain holds off I won't complain.

Seaside at The Chasm

I've seen two references this week to Geoffrey Moore's Crossing the Chasm. I haven't read it yet but I've added it to my list.

Kent Beck describes the book's theory of market segments like this:

1. Enthusiasts — will try new things for the sake of novely
2. Innovators — will try new-ish things for the sake of business improvement in spite of some risks
3. Early majority — will adopt proven products provided there is no perceived risk
4. Late majority — will follow in adopting established products
5. Laggards — the name says it all

He then goes on to highlight these observations of Moore's with regard to high-tech products:

• The gap between innovators and the early majority is particularly wide (the “chasm” of the book title), stymying many promising innovations
• Marketing is fundamentally word of mouth, but people in one segment don’t converse with people in other segments. This creates a chicken-and-egg problem in gaining traction in a segment.
• Messages that work for one segment don’t work for the next. The time to switch is when a product seems to be gaining momentum, because that segment will soon be exhausted.

Eric Sink adds:

One of the ideas in [the] book is that new innovations don't go mainstream until they become a "whole product".

Now Kent is talking about JUnit Max and Eric is talking about Distributed Version Control Systems (like git, Mercurial, and Bazaar) but this got me thinking again about Seaside's positioning and how to grow our user community. I think GLASS, by providing integrated persistence, is a big positive step towards making Seaside seem like a "whole product". But what else is missing? Deployment/admin tools and documentation spring to my mind and I'm hoping to make a start on the latter with some of the posts on this blog. But what else?

Growing support by major Smalltalk vendors helps reduce the apparent risk within a small segment of the market but, for many people, Smalltalk itself is seen as a major risk. So part of making Seaside less appealing would involve either de-emphasizing its use of Smalltalk (not really going to work—people will notice eventually) or reducing the apparent risk of Smalltalk itself. That's no small task and the vendors, I'm certain, have this at the front of their minds. Still if anyone has any thoughts on how Seaside in particular can contribute to that effort, I would love to hear them.

One of the major perceived risks associated with Smalltalk, of course, is the relatively small number of developers using it. Thus we have a feedback loop there: more users means less risk, which means more users, and so on.

So three important questions, I think, are:

1. What does Seaside need in order to be considered a complete product?
   
2. What can Seaside do (other than growing the community) to reduce the perceived risk of adoption?
3. What can Seaside do (other than reducing perceived risk) to grow the community?
   

No answers yet; just questions. If you have any thoughts, please share.

Advanced users don't customize

I was scanning an old post of Joel Spolsky's and found this quote really rung true for me:

"But wait!" you say. "It's important to have options for advanced users who want to tweak their environments!" In reality, it's not as important as you think. ... Most advanced users use several computers regularly; they upgrade their computer every couple of years, they reinstall their operating system every three weeks. It's true that the first time they realized you could completely remap the keyboard in Word, they changed everything around to be more to their liking, but as soon as they upgraded to Windows 95 those settings got lost, and they weren't the same at work, and eventually they just stopped reconfiguring things. I've asked a lot of my "power user" friends about this; hardly any of them do any customization other than the bare minimum necessary to make their system behave reasonably.

It kind of surprised me that it was true, though: I used to be an obsessive preference tweaker but that animal urge seems to have died out along with the desire to immerse myself in video games until 5:00am. I still troll the preference dialogs of any new application, looking for options with as much clout as the Turbo button on old 386 machines, but I can usually close these dialogs without saving.

There are a few customizations I do any time I have a new computer (like deleting useless icons from the Dock or its equivalent). There are even customizations (like setting the refresh rate of the monitor higher than 60Hz so it doesn't hurt my eyes!) I do on every machine I touch. Firefox settings come with me whenever I copy my profile onto a new computer (I want my bookmarks). Other than that, if I can't share the customizations between computers (with an NFS-mounted .bashrc for example), I try to keep them to a minimum.

Of course, with Linux this issue is much less of a problem. I once had a system that I had to expand by putting in a second hard drive. As a result, I ended up with /home on its own drive. The next time I re-installed the operating system I was delighted to find my desktop and all my application settings exactly as I had left them.

Book: The Long Tail

I found myself in a bookstore the other day and the limited selection of English books made it seem like time to check out The Long Tail (note the link is not to the same edition that I read).

The thesis is interesting: that consumer behaviour is changing due to increased selection, decreased distribution costs, better filtering and recommendation tools, and expanding access by amateurs to creative tools. The idea is that selling a few each of a million different things can now constitute a sizable and legitimate market. The history of mail order and consumerism in the United States also held my attention and there were pearls of interesting information about particular industries and companies thrown in.

Those were the good parts. But man do you have to wade through an enormous heaping pile of repetition to find them! I mean, I complained about the repetitiveness of Don't Think of an Elephant but The Long Tail makes that slender tome look like a particularly succinct haiku.

Anyone near me while I was reading will be able to confirm my level of frustration: every chapter or so I would snap, get up, and complain to whoever was nearest at the time (sorry!). Right down to the last chapter, we were still being treated—in every subsection!—to a paragraph-long definition of "long-tail economics" and its effects on commerce and consumers. Yes! Ok! We get it already!! The book should ha... I said we GET IT!!! The book should have been called The Long Read[1].

Basically The Long Tail should have just been an essay. In fact, it was just an essay so I wouldn't waste your money on the book. And if the original essay leaves you wanting, you can always try Wikipedia.

Don't Think of an Elephant also came out of a collection of essays so maybe this is a lesson for me (though it ought to be a lesson for authors). I bought Freakonomics at the same time as The Long Tail and I see it is also a collection of essays; so that doesn't thrill me with enthusiasm. Can anyone give me any comfort on that one? At this point even boring would be ok as long as it isn't repetitive...

[1] Credit for the title goes to Andy Stote. ;)

Seaside 3: Server Adaptors

This is the next in a series of posts looking at changes in the upcoming Seaside release. Check out the other posts on partial continuations and exception handling.

The upcoming release of Seaside will feature some changes to the now-familiar WAKom. The existence of various subclasses like WAKomEncoded and WAKomEncoded39 was beginning to point at a usability problem and we wanted to facilitate running Seaside on multiple ports out of the same image.

First of all, we have introduced an abstract class, WAServerAdaptor. Server Adaptors provide an interface between Seaside and a particular server or connector (e.g. Comanche, Swazoo, AJP) and are able to start and stop server instances on the correct ports. Most importantly, they are also responsible for translating between Seaside's WAResponse and WARequest objects and the native requests and responses required by each server.

Server Adaptors are configured with a port number and a Request Handler. They are also configured with a Codec, which specifies the character conversion that should be performed when converting the requests and responses. Character encoding issues are complex, however, and we are still playing with those interfaces so I will leave that discussion for another time. Server Adaptors get registered with an instance of WAServerManager (currently a singleton) when they are created and the Server Manager coordinates starting and stopping the servers.

To create and start a new Comanche adaptor, you could simply execute:

adaptor := WAComancheAdaptor port: 8080.
adaptor start.

Alternatively, you can use the new Control Panel (implemented with OmniBrowser) to create and configure your adaptors. You can now create and run multiple adaptors of the same type. You can even configure multiple adaptors on the same port (perhaps to facilitate testing different servers or codecs) though only one can actually be running at any time.

Note that WAKom and its subclasses still exist for backwards compatibility in this release and will start an appropriately-configured instance of WAComancheAdaptor. These classes, however, only support running a single adaptor instance at a time and will be removed in a later release. Once created with WAKom, the adaptor will be visible in the Control Panel and can be manipulated there just like any other adaptor.

I mentioned that Server Adaptors can also be configured with a Request Handler. Why would you want to do that? By default, all Server Adaptors dispatch incoming requests to the same default Dispatcher. But perhaps you have an admin interface that you want to run on a different port so it can be firewalled to an internal network. Perhaps you want to make Seaside's web config tool available through an SSH tunnel. Or perhaps you have an XML-RPC interface or a status page for integration with a service monitoring tool. Maybe you just want to transition your application behind a load balancer to a new instance with different configuration options. Whatever the case, if you just want to configure a new Dispatcher using the web interface, the Control Panel has a context menu option called "Use new dispatcher" which will give you a new blank starting point on that Server Adaptor. If you have an existing Request Handler somewhere you can tell the Server Adaptor to use it like this:

adaptor requestHandler: myRequestHandler

Using a Dispatcher at the root will allow you to configure multiple Request Handlers at different subpaths but you could just as easily use an instance of WAApplication, RRRSSHandler, or any custom Request Handler subclass (more on this in a future post) if you want all requests to be handled in one place.

Seaside on Industry Misinterpretations

I spent some time this afternoon talking to James Robertson and Michael Lucas-Smith of Cincom for the Industry Interpretations podcast (episode 125). We talked a bit about the history of Seaside, partial continuations, the goals for the next release of Seaside, and some of the challenges (like getting debugging working). And probably some other things I've forgotten.

In fact, I know for certain that when we finished recording there was something I wished I had mentioned. I figured I'd blog about it when I posted about the podcast but, of course, now I have no idea what it was...

Update: The thing I forgot to mention on the podcast was another difference between a partial continuation and a full continuation. Evaluating a full continuation replaces the entire stack of the running process; a partial continuation can be evaluated—much like a block—so that, on completion, it returns to the context where it was evaluated.

On an unrelated note: I'm toying with the idea of making the trek to Potsdam for the German Squeak users meeting. Any other Seasiders planning to attend or have any idea how much someone with only elementary German would get out of it? :)