Smalltalk Tidbits, Industry Rants

I have a busy day of errands tomorrow, and then I'm off to Toronto for Smalltalk Solutions. Most everyone who is arriving early will be at Pure Spirits tomorrow night - hope to see you there.

I think User Friendly captures the feelings of an awful lot of fans with today's strip :)

The second edition of Caylus is out - they've got real coin tokens now, instead of the bozo stuff that wen out with the first edition. In that printing, the coins were all the same color, there were no printed numerals, and the way to differentiate fives from ones was size. Ick.

More importantly, we played a game last night and I didn't bring up the rear - I won. It took me awhile to get a feel for the game, but in the late middle of the game you really have to have progressed up the building favor chart and acquired gold - so that you can build one of the big blue buildings. Along the way, of course, you have to have built at least one green building.

It's a very cool game, but it does take longer to play than Puerto Rico. There's more good news too - it looks like you can play on BrettSpielWelt now. Cool.

The RIAA continues to be a first rate group of tools - witness their latest lawsuit:

A federal lawsuit filed this week in Rome by the Recording Industry Association of America alleges that Carma Walls, of 117 Morgan St., Rockmart, has infringed on copyrights for recorded music by sharing files over the Internet. The lawsuit seeks an injunction and requests unspecified monetary damages.

There's a small problem with the allegations:

This came as shocking news to the Walls family, who were notified of the lawsuit Friday afternoon by a newspaper reporter. James Walls, speaking on behalf of his wife and family, said they have not been served with legal papers and were unaware of the lawsuit.

After being shown a copy of the court filing, Walls said he found the whole thing bewildering.

“I don’t understand this,” Walls said. “How can they sue us when we don’t even have a computer?”

Like much of the other stuff the RIAA does, facts simply don't matter. The idea is to scare the crap out of anyone within range of the press release. I rather suspect that they have some moron who thinks he tracked an IP address to the house in question - never mind how recent it was, and never mind the possibility of unsecured WiFi (very common) being used by someone in a nearby house. Heck, before I bought my latest router, my notebook sometimes found the neighbor's setup before mine - and I wouldn't notice until I tried to access something on the LAN.

It seems that there's been some confusion over the term "Conference Hotel" at Smalltalk Solutions - especially with references here on the meetup Wiki page. Just to be clear, that means the Renaissance Hotel. So, the 7:30 meeting to get out to Pure Spirits means the lobby of the Renaissance. I'll be in the air at that time - I'll be arriving late.

While everyone throws roses at Sun and Redhat - for being "champions of Open Source" - not too many people are paying attention to what they are also funding - an expansion of the DMCA that would have made circumvention of Sony's rootkit DRM a felony. Thanks a lot guys - I'd rather you had obnoxious EULA's and stayed the heck away from the really anti-competitive stuff. Maybe someone could ask Jonathan Schwartz about this, for instance. His passion for open source in Brazil is nice, but it would be a lot more helpful if he stopped making the world worse.

Interesting. Scoble is exhausted, seemingly. Dave Winer says he's going to retire. And here's Russ Beattie, hanging it up. Looks like a lot of the early adopters have hit a wall of sorts, and decided to move on. I'm still having fun, so don't expect a let up of any kind here. It's interesting though - writing does take work, and I think I understand why most syndicated (print) columnists only write 1-3 times a week.

In the meantime, the coming week will be filled with posts from Smalltalk Solutions. It sounds like there won't be net access in the conference area (other than a very early '90's style "email garden"), so the posts may well appear in bunches early in the day, and again late. Maybe I'll be pleasantly surprised, and find WiFi - stranger things have happened :)

Wow, I haven't flown on a Dash 8 in years. I'm taking Air Canada Jazz into Toronto from BWI, and I was surprised when there it was at the end of the jetway - down the stairs and out to the turbo-prop. I'd also forgotten just how loud these things are. Fortunately, my wife got me decent headphones, so I'm enjoying Lileks' latest podcast as I sit here and tap this out.

Anyway, we got out of BWI before the thunderstorms that were supposed to head in - and the rain in Toronto looks like it shouldn't be a problem (until I try to stay dry in it, but that's a problem for later).

We had quite the crowd at the restaurant - more than double the number of people expected showed up. That gave the waiters some stress, and made the billing interesting, but we got it all sorted out. It was great to see so many people, including quite a number who I don't know - a good sign, as far as I'm concerned. Now it's off to Michael's room - he's promised us Tim-Tams :)

So I'm at LinuxWorld/NetworkWorld - at an Expo center near the CN tower. You would think there would be WiFi, and you would be correct. However, the only way to gain access is to have the show pay the (egregious) fee in order to get a code. Has the convention center considered the wild idea of offering access on an individual basis for a fee? Nah, that would bring in revenue, or something.

Sigh. A day without network access...

Scoble definitely has a passion for his work, but his post on the angst at Microsoft illustrates one thing to me very clearly: Mini-Microsoft has one thing very right: the company needs to be smaller in order to get better. Either they'll fix that themselves, or the market will it for them. Like IBM back in the late 80's.

SCI FI Wire:

Longtime Star Trek writer and producer Rick Berman, who joined the franchise at the feet of creator Gene Roddenberry, will not be involved in the proposed 11th Trek film, to be directed by Mission: Impossible III helmer J.J. Abrams, SCI FI Wire has learned.

The movie might be good :)

9 AM on Monday morning, and I'm at Travis' Efficient Smalltalk presentation. I could have gone to Alan's GLORP talk, but I've spent many, many years trying to ignore databases - no need to change that policy now :)

Travis started in Smalltalk in 1992 - he left a Fortran job to get away from a bad boss. Taught himself Smalltalk from the Digitalk tutorials "back in the day", and has been Smalltalking ever since. He moved to Key Technology in 1996, and has been there ever since. In distribution terms, the audience is pretty heavily on the VW side, which is cool.

The idea Travis has for this tutorial: dispel the "Smalltalk is slow" myth. Plays into my talk which will come up later this week - I've yet to hit a scaling problem with Silt that wasn't a problem with my code specifically. What it's not: VM optimization, or "Smalltalk is faster than language (x)" thing.

Travis: Smalltalk has one of the best "thought to code" ratios" - you can get the code you are thinking of out very quickly. It's easy to throw a prototype together very quickly - the downside being that it's also easy to write some very inefficient code. The good news: it's just as easy to fix a bad design, and to improve performance relatively easy. That fits my experience - I've never had much trouble getting rid of the bad spots in my blog server. The motto:

Make it Work, Make it Right, Make it Fast

Early optimization is truly the root of all evil. A well designed system optimizes easy. An example: "Flogging the Logging", where Travis says he didn't actually examine the problem before diving into it.

Performance tricks aren't always reusable

"The problem is the system isn't running the Sieve of Erathosthenes" - Alan Kay. So you need to review each gain in context - do they really matter given the larger issues? You have to be willing to look at old assumptions and throw stuff away. Something too few of us do: Diagnose first, code for speed second. I know that my guesses about where the problem is in my own code are frequently disproved by the profiler.

Unit tests can help - you can verify the working nature of the code as you optimize. I can certanly say that a lack of tests can make for deployment surprises.

Where does the "Smalltalk is slow" myth come from?

We don't make time for the "make it fast" part. We get working code so quickly that we tend to just ship it. Throwing faster hardware at the problem is oftena cop-out - Project managers need to allow time for optimization.

Simple profiling:

Time millisecondsToRun: []

Run it many times, and watch for simple things that throw things off - Large Integers, memory allocation. In VW specifically, dotted references (namespaces) can be an awful lot slower. Make sure to figure out the profiling overhead, because a presumed improvement may not actually exist. Make sure that you use consistent measuring methods across tests.

Profilers

Good tool to get familiar with. Nice if they can be used programmatically and from a UI. Nice if they can dump to a UI and a file. Multiple ways to view results is good too. One thing I've noticed in multiple visits to customers is how few people have ever looked at the profiling tools. I've often showed up and asked "have you profiled?" and gotten the answer "we know what the problem is". I've yet to see that be the case :/

There are different tools across implementations - VW has five, measuring time and allocation, in one process or multiple - and a VM profiler. Squeak has two options. VA ships with a very complete profiler that does sampling and tracing. It also supports some nice graphical output. You can use it interactively or programmatically. Michale Lucas-Smith points out that the Instantiations goodies includes another profiler. Smalltalk/X has some basic message tally tools. Only does sampling, and doesn't have a nice UI. Also some memory tools. Dolphin has a goodie from Ian Bartholomew that is interactive only. Has a nice UI with lots of detail.

Bruce Badger brings up the Code Crawler (VW and Squeak). It pulls out tons of metrics and has good reporting tools. Somewhat reminiscent of the old Arbor Probe tool.

Patterns for Performance

This is a set of examples that illustrate a theme (or category) that overlap. While few performance issues are exactly like another, they often share the same general problem. While Travis includes numbers here, he's saying to take them with a grain of salt: YMMV.

The first thing - recalibrate your expectations. Optimization tricks are often not reusable:

• Not across different VM's
• Not across different versions
• Not across different OS platforms
• Not across different contexts

All of which explains why early optimization is such a bad idea. So some "old chestnuts": "Everyone" knows that string concatenation is slower than dumping to a stream. It turns out that concatenation is actually faster now, because it's been rewritten. You can get faster with streams by properly sizing up front, but it illustrates the power of old assumptions.

Another example: Many people thing that #at: would be faster if it offered an unsafe version. So Travis wrote a faster #at: in Smalltalk/X. In Smalltalk/X, you can inline C code - so you can do "primitives" directly. So into a demo - remove the bounds check, remove the small integer check - and then test. It turns out that making that change doesn't actually speed things up that much - which has to do with changes to the underlying hardware. Again - when doing performance testing, you have to be willing to toss old (possibly outdated) assumptions.

Use a different algorithm

Chisel away at the profiler results - difficult to see the forest from the trees that way. Big gains are usually found in new algorithms, not in small tweaks. Smalltalk's thought:code ratio makes that easier. If the algorithm itself is slow, then the profiler won't help much.

An example: #indexOfSubstring:at: - in VW, the library uses the simple, direct algorithm. There's a publically available algorithm (Boyer-Moore) that's faster.

Similar idea - use a different (data) representation. The RB does this with a replacement for a dictionary that does linear searching - since the data sets are small, it's a win over the overhead of dictionary hashing. Sometimes, the "slower" CS answer is faster.

Another example: OrderedCollection can grow from both ends. What if all you need is a Stack? He implemented a Stack class that only uses #lastIndex. It's 2X faster for normal use, but is slow if you do need to add at the front.

Use a real object - don't just keep a dictionary, or a collection around and start adding helper methods to the wrong classes - create a real class so that you can isolate problems. There are simple wins too:

somePerson name is slightly faster than somePerson at: 1 - and it reads easier, which is probably more relevant in the long run.

Sometimes it's a win to do the new algorithm in Smalltalk rather than trying to optimize down in C - the C code is harder to write, so production of a new algorithm is so much easier. If you can get it to be "fast enough", you can just stop.

And we're back after the coffee break - much needed, since I'd only had one cup before this all started. So back to the examples.

Savvy Math

Transcendental math is great (I blogged about this last week). The VM and image take care of problems for you, either via double dispatch, or via failure/coercion/retry. There is a performance hit for this convenience. So in general, SmallIntegers in Smalltalk are highly optimized, and are no work for the collector. In most Smalltalks, putting the higher generality number on the left can be much faster. i.e.,

100.0 * 10000 is around 4x faster than 10000 * 100.0. So even in Smalltalk, knowing your implementation issues helps. [ed - I had to get iterations up to a million to see a difference in VW]. Fractions are very cool, but they are also very expensive. If you don't need them, don't use them. So for instance:

(a/b < c) is much slower than (a < (b * c))

simply because of Fraction math. Division is expensive in software math in general, not just in Smalltalk.

In math issues, zero is "special" - Nothing is slower than a UHE. An #isZero check is much faster than catching the ZeroDivide exception.

In some cases, limiting the production of new objects (in order to not create GC need) can help. In particular, this can be a big win in graphics work, like translating rectangles. Coding a specific rectangle move method that doesn't create objects as a side effect can end up creating far, far less garbage to clean up.

This also comes up in working with collections - most of the extant methods return new collections instead of changing in place. If you need to work with large collections, creating your own versions that modify in place can be a big win. Examples:

someCollection asSortedCollection first (or #last)

instead, try: someCollection fold: [:a :b | a min: b].

You save the creation of a throwaway collection. With the test data, it probably doesn't matter. With real data, it can make a huge difference. Side note: Martin Kobetic and Michael brought up this post from Alan, which uses streaming as an alternative approach.

Another thing: using simple file "database" access, over-use of Filename>>construct: might be expensive. Hmm - I'll have to examine that in my blog server.

There's always the old standby - caching. For large objects this can be a nice win based on the way the VM stores large objects. Along the same lines - don't do expensive things over and over again. Sometimes, this will result in ugly code that ought to be commented. For instance, in VW, RBScanner>>scanToken:

scanToken
	"fast-n-ugly. Don't write stuff like this. Has been found to cause cancer in laboratory rats. Basically a 
	case statement. Didn't use Dictionary because lookup is pretty slow."

        "code omitted"

Another interesting thing: in general, using a MessageNotUnderstood handler is faster than asking the object if it #respondsTo: Although, if you are using this for backwards compatibility, you probably have other problems.

Collections often have a "lifecycle" - i.e., you add things once, you sort once, and then you're done. Quite frequently, the code keeps switching collections based on early needs - you'll know you have this if you see lots of #asOrderedCollection (etc) in your code.

Simple minded standbys (cache a computation in a temp variable, for instance) can often have big impacts as well. This goes back to the fact that implementing in Smalltalk is very easy, so it's easy to an inefficient piece of code into production.

Skip Framework overhead

Don't swat flies with howitzers! Use the simplest object that could possibly work. An example - ExternalRead/WriteStream is a general solution for most needs. You can use an IOAccessor directly if you write enough files that there are performance concernns - and it can be faster. Another example: ComposedText does a lot, Label does a lot less. Label is tons faster if you don't actually need any of the features of ComposedText.

Another example: The XMLParser. The parser framework does everything you would ever want, and builds up a document. If all you need is to find a tag or tow, a simpler string search might suffice (iirc, the Web Toolkit does a fair bit of this).

Inlining can make code easier to read, and can also turn up chances to optimize in other ways. This brings to mind Terry Raymond's defactoring tools. It can make a difference whether you use #isNil instead of #ifNil: - small, but noticeable. Someone points out that the when IBM started inlining #ifNil: (and friends) in VAST (quite awhile ago now), it broke a number of proxy frameworks. Back to the howitzer comment.

Primitives

Down to the "metal" in Smalltalk. There's variance amongst primitives, especially in the graphics area across platforms. So an example: say you need to draw diamonds. Obvious: #displayPolygon: Not as obvious: create a mask and draw that. The results between these two vary a lot between X11, other platforms, and VNC (and likely things like Terminal Server). You need to be aware of your platform in cases like this.

As a last resort, you can make your own primitive (noting that this makes code harder to develop. install, and share).

Make it look faster

Users don't like being left out - include them. Get feedback, and be aware that fast is in the eye of the beholder. An example: The Windows "flying folder" copy is 20% slower (Win 2k test) than XCopy. Most users think it's faster, because they are getting feedback.

Summary

Smalltalk doesn't have to be slow - it's usually misuse of tools that cause problems. Check your assumptions, and look at the algorithms you use.

There was a contest between the Seaside tutorial and lunch, and since I didn't get breakfast, lunch won. I think I'll try to get into the second half of it; I might have a bit to post on it in awhile.

I walked into the Seaside tutorial halfway through - which isn't bad, as it happens - a goodly proportion of the audience is non-Smalltalkers, so a fair bit of what I missed was an intro. With that out of the way, I'm getting the actual Seaside/Ajax part of the talk. I can't unzip the Scriptaculous library at the moment - I played Civ4 over the weekend, and haven't rebooted yet. Par for the course; the Windows file dialog is hosed.

So - a brief warning about what Ajax is, and how over-use could slam a server, and then it's off to the races. Back after a reboot, and I was able to extract the files. Stupid game :/ So here's a screen shot of the Squeak browser, with a view of one of the callback methods - it's handling one of the asynch calls back from the browser, and rewriting the appropriate pieces:

Some of the scriptaculous code is included in the image as methods (answering strings), and I had a question about that - whether having that be in a separate, loadable file might be easier. On the other hand, using either Squeak or VW, you could just as easily file-in replacements for those methods, as I do for patching this server. The positive of having the javascript in the image is that it's all versionable together. Here's a snapshot of what I'm talking about - one of the javascript methods in support of drag drop inlined as a string:

The funny thing for me is that some of this stuff is oddly familiar. The original VisualWave had bits of javascript support in it, so that you could handle events for widgets (selecting in a list, for instance). Of course, with Wave, the whole form was both submitted and redrawn as a synchronous HTTP POST - but the widget handling issues are much the same.

Side note at this point - all of this Seaside/Scriptaculous integration is available in the VisualWorks port (big hat tip to Cincom's Michel Bany for that).

Question about persistence: there's nothing specific for Seaside, but people use a variety of things. Object dbs (Omnibase, for instance), or GLORP, or a number of other things that are available from vendors and the community.

A question: What about the "classic" approaches? Ruby on Rails is a nice, clean way to approach the old fashioned style of web app - works very well, is very clean. You end up writing a lot of state machine style code in your application though, and it gets harder and harder to maintain. Seaside removes all that overhead from you. So RoR will serve you well if you have a simple "db to web" app to build. If you need to manage state, then Seaside is easier.

You can still work with CSS/templates, they just get integrated right into the Smalltalk image (like the javascript example above). They also support having that loadable from files, of course - DabbleDB does it that way, and their graphics arts people never see a Smalltalk image.

Another question: What about having "clean" URLS? Not easily possible for an entire Seaside application. You can have bookmarkable sections that slam extra stuff in the URL that will deal with that.For instance, DabbleDB is built on Seaside, and does have "clean" urls as entry points.

Steven Kelly:

Still, if we meta-meta-developers are doomed to build a poor replica of the development platform we work with, I'm happy to be working with a platform that knocks seven shades of spots off the one the MS team has to use. Could that be the reason MetaEdit+ is 100 times more compact, runs on 5 times more platforms, is 10 times faster starting up, and 5-10 times faster to use ? :-)

That might have something to do with the platform that MetaEdit+ is built on.

We have a general STIC meeting on tap now, and Bob Nemec is introducing himself to interested Smalltalkers. As Bob says, STIC needs input and help from interested Smalltalkers, not just from the vendors.

First up, the explanation for why we're at LW/NW - we want to get a presence beyond the existing community - get people who don't know us yet to see what we're about. We'll be back at this venue for 2007 for sure, and we'll see how things go from there.

So what do we intend to do? First off, revamp the STIC websites (stic.org and whysmalltalk.com). The idea is to give something of a better cross vendor view of what's going on in Smalltalk. Bob pointed out that - "back in the day" - comp.lang.smalltalk was the main forum. USENET has feaded, and there are now tons of disconnected forums - mailing lists, wikis, blog sites, etc.

On to Monty Williams of Gemstone, who handles our finances. Most of our revenues have been from hosting StS, and then waiting to see if enough people sign up. What we want to see now is people getting the individual memberships (which gets you access to the 25% discount code for this show). One of the big helps of being at LW/NW brought up from the audience is this: it's easier to get corporate to pay for attendance of StS at LW/NW.

Back to Bob Nemec - he'd like to see STIC help hook up user groups and interested speakers - from vendors and elsewhere. Good question from the audience - for the interested Rubyist (etc - this is an example) - what does Smalltalk have that a Rails developer would be interested in looking at? That's one thing that the STIC website should have information on. Here's where I interjected something simple - we cannot do this without people in the community stepping up to the plate.

Another question - why LW/NW? Why were they interested? We got in to a large extent via the sheer persistence of Suzanne Fortman, and her efforts to work with the LW/NW people. They were willing to work with us, but this year was year one - we'll have more going on next year after having worked with them now. We'll be back here in Toronto next year, and after that? We'll have more ability to get things lined up with a full year's run-up time. To get a keynote, we needed to get someone speaking at a non-technical, C level whose schedule lined up.

Another question: "What does my $40 membership buy me?" In past years, it bought you a $75 discount for StS. This year (and rolling forward), it will buy you a $300 discount on StS. We intend to do more (revamping the websites, etc) - but the discount is a good buy all by itself. Or as Bob Nemec puts it, you're buying marketing dollars for STIC.

Good suggestion from Bruce Badger - there are Linux groups (schools, universities, etc) that always need speakers. One easy thing to do is to volunteer to speak. Many publications are just as hungry for content - what you need is a good angle (a company that solved a problem, etc) - not a technically oriented "why Smalltalk is great" piece.

Scott McNealy has stepped aside (or been kicked upstairs). I'd say there's hope for Sun, but the new CEO is "give it all away and make it up in volume" Jonathan Schwartz. Someday, there has to be some revenue brought in from the software they spend so much money developing...

Adriaan van Os has some pictures from the first day (and the weekend, I think) of Smalltalk Solutions.

Chronos noticed that LtU ran with my post on exception handling in Smalltalk. The raw panic demonstrated by some of the posters at the idea of a developer being able to deal with an unexpected situation is amusing.

The title is actually from Oscar Wilde - he is reputed to have said that when he first entered the US and he was asked what he had to declare.

With static type checking, it's like trying to declare that no shot on goal is possible, and thus there's no reason to even play the game. Heh - Brian apparently started in on this talk at customs, after they asked him what he was speaking about :)

We are in are in the era of "Architectural balkanization in the post linguistic era". Brian says there are three ideas that have come out of OO and Smalltalk:

• Dynamic Polymorphism - dynamic dispatch - easy as pie, great for wrapping stuff. With dynamic compilation, you can replace things at all levels - module, application, component.
• Callipygian Compilation - JITs - hotspot VM's, the work of Deutsch and Shiffman.
• Reflection - grew out of Lisp. self representation, introspection/intercession.

Smalltalk-80 - "Everything I know about OO I learned from the Image" - browsers/IDE, Windows/GUI, JITS, building up from objects. The notion that the program was built out of mutable objects was what really stuck.

With reflection, you can have a manifest (which, to Brian's mind, explains XML's popularity). You end up with user configurable code. You can cope with things at runtime that you haven't seen before with ad-hoc reflection.

Last summer, Brian worked on MOP and multi-methods in Smalltalk - produced a paper on it, which reflects his particular style of humor - there's a segment on whiskey consumption :)

Asynchronous messaging is only now coming into vogue. Brian asserts that this was prefigured by Actors.

One of these is true (the second)

1. Meta Considered Harmful
2. "Meta" Considered Harmful

The Vision: Languages built out of objects instead of text. Open Languages, Open JITters, A framework for languages. Compile time is anytime. A part of the Smalltalk vision early on was Linguistic Imperialism (to be fair, Java has this going too).

The Reality

Utopian moncultures are good idea incubators, but not actually workable. We live in a pargmatic, heterogeneous, polyglot world. We need to work and play well with others. As Brian puts it, there was a schism in 1997:

• Objectivists
• Pragmatists
• Formalists
• Academics

They all retreated into their own conferences and languages. Heh - "Of Slugs and Bugs" - a tale of types, or "How Star-Crossed software lost the Mars Climate Orbiter". So you had a perfectly good spaceship, with perfectly good software - and yet it dove into the ground as it was told to do by the software. The culprit: A "Simple" unit conversion.

The carpetbaggers came in with their own pet theories as to how it happened - no testing, bad methodology, bad management, bad integration, bad testing.... lots of text got written. The root cause: using English measurement units in a software file that was input into something that expected metric units.

The previous Mars probe that used the same software worked fine, but they changed the number of solar panels on the MCO - so they had to use the thrusters more often to compensate for the way it ended up moving. They had software to track the changes this introduced. When they reused some old code to compensate for all this, the developers assumed that the English-Metric conversion was already in the system. It wasn't, so the frequent use of the thrusters ended up introducing a larger and larger error into the landing scheme.

There were plenty of papers at OOPSLA that said that having units added to Java would have prevented this. Sadly, paper is not executable. The bottom line was that the code for MCO was a hatchet job: "Faster, Better, Cheaper - pick two". There was no end to end testing - the programs were late. Managers trying to save money don't win games - the players still have to suit up. The reused code was trusted because it had worked before (in different conditions).

In the end, it blew because reading code is, in general, hard. Large bodies of code are unreadable (we are all in denial over this.

The Olfactory Method

If it stinks, change it. Code Smells are a subtle indication of a problem. The end-to-end principle applies to programming languages too. You can just leave the goalie in at runtime instead of pretending that type theory disproves the need.

The program model is the central thing. Programs built of objects can be changed. That lets you use dynamic polymorphism to swap things out. Software isn't like "real" engineering. We can't type each line of code three times, for instance :) What we can do is leave the goalie in. We can engineer our objects to test themselves. The network and databases are slower than reflection. Runtime type errors? Welcome to the 21st century - we have to learn to deal with them.

Static languages throw away all the information we need at runtime. Why? It's not 1982 anymore. No one is infallible, and we have to realize that bugs will continually exist. This is a lesson I've learned with BottomFeeder - generally speaking, I ignore runtime errors and let the program run. And somehow, it does :)

Randy Coulman with Key Technologies is going to talk about Acceptance testing with Fit, FitNesse, and FitLibrary. This is going to be more of an overview of the tools than anything. Randy: Working for Key and doing Smalltalk for afive years.

The example we'll use - the game "Mastermind". Basic idea - you set up a "code" (colored pegs in sequence), and your opponent tries to break the code. Randy broke down the rules into a set of Fit tests using the Fit Wiki server (FitNesse). Fit is the acceptance testing framework from Ward Cunningham. FitLibrary is a set of additional fixtures. Available for:

• VW, VAST (port in progress)
• Java
• .NET
• C/C++/C#
• Python
• Ruby
• Perl
• PHP
• et. al.

Randy is the maintainer of the Smalltalk (VW) port. The idea is that you write the tests in HTML pages, and then run them on any back end - thus making the acceptance testing live above the implementation lavel. The developers create fixture code that runs the tests themselves. The writing:

• Subclass the desired fixture class (ActionFixture used directly most times)
• implement #signatureFor: to provide type adaptor information
• Implement the necessary instance variables and methods

ColumnFixture

This is the simplest one - each row is a different scenario. Each column is either and input or an output. The expected outputs are compared to actuals, and then the test is marked red (fail) green (pass). Rows and columns refer to the HTML table used for presentation.

ActionFixture

You create "workflow" type tests with this. There are actions to deal with - start, enter, press, check - you create a helper class to implement. This one can be brittle.

RowFixture

This is used to check a collection of results (eg - results of a query). The order of the rows doesn't matter, it's smart about matching up rows. It will show missing/surplus rows.

Then there are a set of extension fixtures - DoFixture, SetUpFixture, SetFixture/ArrayFixture, CalculateFixture (and more). Randy has a few implemented, is doing more.

DoFixture

Must be the first one on a test page - it's a "workflow" fixture. Takes over execution of remaining tables. It's less verbose than an ActionFixture.

SetUpFixture

Used to set up data for a test. Similar to givens in a ColumnFixture - no feedback in the table

Set/ArrayFixture

Similar to RowFixture, but easier to write. You just create a set and it gets auto-wrapped. In SetFixture, order is irrelevant, in ArrayFixture, it matters.

CalculateFixture

Similar to ColumnFixture - no header markup needed to distinguish givens and expected values.

Now a demo of the way it works - I'd take a picture, but it turns out that I can't email myself pictures from here - which means that I need a real camera :) You can download all this stuff and try it out:

• In the public store
• http://www.fitnesse.org
• Questions for Randy? Email him or hop over to the IRC channel - he's usually on during PDT work hours as "randy"

"How do I debug a test?" Well, in Smalltalk it's simple - you use the debugger that's right there, and slap in a breakpoint. It's a little more complicated over in curly-brace-ville.

I arrived a bit late, or Blaine started early - on with the talk. Where does pain come from? Tight schedules, fragile design, inexperience, unclear vision, poor coding practices, broken contracts. Despite your best intentions, some of this creeps in. You end up building up a "software debt" where you least expect it. The Tools? SUnit, Reflection, Version Control. There are the ancillary things you get from reflection (MethodWrappers, etc).

SUnit can be used to help "enforce contracts". It helps the team remember decisions that might otherwise be forgotten. Using reflection, Smalltalk makes it easy to check existing methods for various things - calls to things that should not happen at runtime, etc (eg - #halt left in the code).

Dumb Bugs Detection

SUnit and Lint are your medicine for finding stupid stuff. Helps you find code smells that have arisen via poor coding practices. The nice thing about Lint in Smalltalk is that it has a programmatic API - you can set up ad-hoc Lint runs that are scripted, without having to use a UI. The RB, of course, has a UI for it.

MethodWrappers can raise flags when contracts are broken. They are a good way of checking legacy code - you can add before and after blocks to methods, which can check pre/post conditions. You'll want to make sure that you unwrap the method wrappers afterwards, of course.

I'm missing some of the flavor of this talk - Blaine is moving from the presentation back to his Squeak image to show code and tests, and demonstrate. So bear in mind, with each thing (like Method Wrappers), he's showing live examples.

Broken Window Detection

SUnit and Metrics are your "canaries in the legacy code mine". You don't want to use these as sticks to beat people with; rather, you want to find out what's happening. Blaine recommends these three:

• Cyclomatic Complexity - good for finding spaghetti code
• Average Message Sends - lower scoring ones turn up data only objects
• Coupling - take all your message sends, and compare it to the methods your class actually implements. You end up finding "god" objects.

Keep the metrics simple, because complex metrics will just add complexity to your process.

SUnit and Source control interrogation- exposes volatile objects and code smells in the system. It can turn up possible objects for code review. Pragmas allow you to add meta data to methods. Helps pinpoint "private" violations, and class to deprecated methods. It's better than relying on method protocols.

Selling Reflective Testing

You need team consensus for metrics - what will you use, and how. You want to start simple, so you can get early success. Be positive instead of using it as a stick. Start encouraging refactoring sessions.

I took a break for the 3 pm session - up in the vendor area, there were customers that wanted to talk to me. So now, I'm back downstairs, and attending a talk on one of the things I've warned against - technology migrations. Karen hope, late of USF&G (which itself was bought out) is giving the talk. Karen started with Smalltalk in 1992, and has worked in VW, VSE, and VA. She worked in Smalltalk continuously until 2004 - with 1994 - 2004 being with the insurance company. She's now an independent consultant.

The application she spent time on was an insurance policy writing system (commercial, small business liability). It won a number of internal and external awards and kudos, including a Smithsonian Innovation award in 1997. The application also won early adopter awards from an insurance industry consortium between 2001 and 2003 (ACORD).

There aren't any code examples here, or consultant bashing. The decision to translate the app was made by corporate, not by the developers or application architects. The actual migration dates from 2004 - and the recurrent theme here is simple: Smalltalk good, Java bad. [ed: I'd modify that by again stating my general theory that technology migrations are almost always a very bad idea, and always spend huge wads of cash in order to stand still).

Karen's opinion after this experience: She would not want to work in Java, and would always recommend Smalltalk.

Heh - Karen adds an acknowledgement to Jeff Sutherland for a 1995 talk called "Smalltalk, C++, and OO Cobol: The Good, the Bad, and the Ugly". That appeared in Object Magazine in May of 1995.

Back to the application. With final deployment in 2004, the application was multi-product, multi-language, and multi-interface: Smalltalk, Java, HTML, WebSphere, HTTP, RMI, ACORD XML, app specific XML, JSPs and Javascript. The initial application was all VSE, and ran on a notebook. It evolved steadily over time. It started with a single business product, and ended up as a full end to end insurance policy writing system.

There were over 2000 domain classes (describing the insurance domain). It used an O/R framework (TopLink), homebrew UI/MVC frameworks, and included a workflow management system. They were one of the early adopters of the ACORD XML system, which allowed them to do comparative pricing quotes in 3rd party systems. The application architecture:

• 4 Smalltalk multi-processor servers (hardware). 6 edits/rating Smalltalk image clones, 4 domain Smalltalk image clones, and 2 XML translator Smalltalk image clones.
• 2 additional servers - downstream/extractor Smalltalk clones
• Bootstrap Java code NT service managed groups of clones on Smalltalk servers. Each ran as an independent Windows process. Each clone had independent caching strategies, but had access to a shared cache.
• Round Robin dispatching initially, went to a more sophisticated load balancer over time.

The system ended up having over 99% uptime statistics. The average real-time edit/rate took 8 seconds. The average number of rates was 200/hour, and they had 75 developers on average. Between 1996 and 2006, they had over 40 production code base releases. So in 1996, what was at stake? There was a total redirection of IS resources (they actually started in 1993). At start, they had 2 Smalltalkers. They went on a massive training/hiring cycle. They created an unprecedented partnership between the business and IS.

In 1993, they chose Digitalk (VSE). At the time, Windows was not predominating, so they wanted to keep their options open - recall that Digitalk did create a Mac port early on. What about 1997 (ParcPlace-Digitalk merger era, VSE was taken down by PPD management). They decided to stay with Smalltalk, even though they were on a moribund product. They were able to push 4 production releases a year - they did not believe that they could do this with a different technology. They started moving parts of the application to VAST.

Then in 1998, USF&G was purchased. This changed things. The new management team also had a policy writing system, and the new CIO had been a part of that. They ended up with years of political infighting over which system would prevail. This was also when the depths of "Smalltalk is dying" and "Java is the future" was out there. Simultaneously, the fat client application was getting fatter, so they did need to make some kind of change to address that. Moving parts of the application to a server looked like a win in maintenance and deployment terms (no need to deal with variant clients, etc).

In 1999-2001, they started moving to a SOA based architecture as they converted code from VSE to VAST. They needed to respond to competitive pressures to allow for browser based rate quotes. They also made the database less application specific, allowing for more general reporting. It also simplified their O/R mappings, and made asyncronous processing easier. They also tightened the UI/domain separation, which had creeped away from MVC over time. At this point, they were adding Java components as part of the server-side WebSphere deployment. In 2002, the VSE client was retired, and all Smalltalk code was now server-side VAST.

Then management decided that they should transfer the whole thing to Java [ed: this is the point where I'd call what they did a mistake. VSE was moribund - a migration was necessary. VA --> Java? Lots of money to stand still].

They started with a "throw the code over the wall" service - a North Carolina based company. The project was cancelled after they had a partly working system. The test cases they had delivered to the vendor allowed them to do a VA Java based system that ran and reproduced their test cases (and found errors in a few test cases and in Smalltalk code). There were some Java patterns in use that they didn't like, and they worked with the vendor to change them.

So here they were with a cancelled, partly working system. Management again decided that they wanted to go to Java anyway. In 2003, they employed a NY based company to do the translation. They worked hands on with the project team, and the company had to devote resources to the job full time. As with the prior effort, this was late, but not unreasonably so. The new code replaced the Smalltalk server with a WebSphere server. An additional task was to change from using DOM (XML) objects to actual domain objects on the back end. So that had to move into the new server as well. This worked, and was deployed (partially) in 2004. It looked like it worked, was robust, and stable.

There was still the downstream processing to translate - at this point, yet another insurance company bought them out. So between 2004 and 2006, the entire application was announced to be dead, with the new company's .NET/VB system being the incumbent.

Now onto the migration efforts from Karen's perspective. She has nothing bad to say about them. The code delivered for translation was very large, and beyond what they initially expected. Interestingly, BFS is still running at this point - the company in question hopes to sunset "soon".

What were the bad things? Moving from dynamic typing to static. It made the developers vastly less productive. There were things that were hard to translate:

• Blocks (not iterators) - areas where they passed blocks around. These were very hard to migrate, and had been natural to Smalltalkers. The resultant Java code did not look at all like what they had started with.
• Java Dates suck. Rates are date driven, and this gave them a lot of trouble. They had to spend a lot of time to correct discrepancies between processing differences between Smalltalk dates and Java dates. They had to re-engineer the whole area.
• Heavy use of Class behavior and Class Instance variables. You just cannot get the same kind of behavior between the two languages - you solve problems differently
• In Smalltalk, methods would have multiple return types - systems could return domain objects, or error objects. This required major re-engineering efforts. Again, you solve these problems differently in the two languages.
• Primitive types or Java Objects for magnitude type things. The Smalltalk code makes assumptions that Java cannot satisfy easily.

The Smalltalk code was "too Smalltalky" for the translation (again, design is language specific IMHO). They had DNU handlers, descendants from nil, #perform, etc. Then there's the whole utility class issue - final classes in Java (String, Date) that would simply be subclassed in Smalltalk. Joshua Bloch, call your office :/

There were problems dealing with marshaling errors on the Java side - these were easy to debug in Smalltalk, but a near impossibility to deal with on the Java side (something Brian Foote spoke of this morning, actually - the Java side has thrown the information away). Then there are casting errors. RMI was slow, especially with ST to Java (and vice versa) marshaling. maintaining parallel Smalltalk and Java domain objects made forward progress on code hard to do. The new system was not an improvement for users - the values they were getting from the existing system was different than the ones from the new ones (the problem was in the test cases, but the users didn't care).

Specious reasons to translate:

• "Smalltalk is dead" - not correct
• "No one knows Smalltalk" - teaching someone Smalltalk is trivial. The learning curve is not steep, and the big problem is at the domain level, not the language level. The Smalltalk code was easier to understand and maintain
• "Write once, run anywhere" - So is Smalltalk
• "Java is free" - The amount you spend on the IDE/tools is trivial compared to the productivity costs
• "Java is State of the Art" - When they translated, it was simply Smalltalk in Java. It didn't use any "bleeding edge" stuff
• "Get it translated and you're done" - the basic translation is hardly the end, as outlined here. You ten need to maintain the new Java code, which is more Smalltalk-like than stock Java developers will like

You'll need more RAM to develop in Java and simultaneously looking at the Smalltalk. Lots of the normal Smalltalk code will end up being unreadable Java. The bad Smalltalk code will be awful on the Java side. If only a few people understand the Smalltalk, no one will understand the Java code.

What would Karen do differently? They should have just re-written the entire ratings module, and possibly taken advantage of (now available) off the shelf components. Possibly would look at Web Services. Would examine other things than just Java. The reality is that these decisions are never made by the developers, they are political decisions made by management. A question came up about how they would have improved performance in Smalltalk - bearing in mind that she would have had engineers who were busy with migration to attack that - and architectural changes (to a server based scheme) would have helped regardless. [ed: I'd also refer to Travis' talk, which is my experience as well - an algorithmic change is quite frequently the right answer).

What about the good? The new system was faster (rate processing went from 8 seconds to 2) - but it's not an apples to apples comparsion. The Smalltalk system was a fat client, and the Java system was a server based system. They also ditched an EJB component that they had been using with the Smalltalk system. They ended up with higher up time and better processing of large (complex) policies. And, of course, the executives were happy. The business partners were tolerant at best... (lots of money was spent).

Here's my take - They started translation efforts in 2001, and kept at it - one way or another - until late 2004. So that's over three years of churn that could have been spent on actually solving problems that had value to the business. It also involved large sums of cash flow on two levels: Consulting fees to two different firms, and the soft cost of retraining a large number of developers who were competent with the Smalltalk tools, and had to ramp up on new stuff. Useful quote from Karen in this regard: The users didn't care that they were migrating - they wanted the same behavior.

PR. Differently:

A spinning instructor at Washington, DC's Sports Club/LA mocked President Bush without realizing (believe it or not) that a first daughter was in his class!

I figured out a long time ago that people who think about politics differently than I do also have money to spend on products :) It's one thing to have a friendly "over beers" conversation; it's something else again to hold sway in a professional setting.

Avi Bryant and Andrew Catton - talking about DabbleDB. A couple of years ago, Avi made the point that there was a niche in the web space that Smalltalk could hit - so he's followed the argument down with his own startup. They sell, host, and service the DabbleDB application. Right now, they are a few weeks away from launching - and they've gotten a fair bit of buzz across the blogosphere and in the tech publications.

DabbleDB came out of their experience in consulting - the ad-hoc spread of semi-shared data that really should have been fully shared (eg - emailed spreadsheets). Had they tried this a decade ago, they would have gone the whole VC "take the money" route. That's not the way they went - they believe in a "late binding" approach to business planning. Once you take venture money, a lot of options get closed off - you are committing to a specific set of plans. So Avi's take:

Taking Venture $$ is a premature optimization

They have two good Smalltalkers with a couple of laptops. They use available WiFi and open source code, and they deploy on cheap, hosted Linux boxes. [ed. I'll interject at this point - you could use commercial software all the way down, like Cincom Smalltalk, and not pay a dime until large amounts of revenue arrives]. Another quote from Andrew:

Get a Job.... the Smalltalk will follow

Andrew started off in a lab, and sure enough, they were using Java and WebObjects (etc, etc). Eventually, there was a need for a quick hit application - which he delivered in Seaside. That sort of thing started the process of building credibility for their Smalltalk approach. Over time, this enabled them to move larger and larger projects over to Smalltalk. The next step:

Quit. Formed Smallthought, and offered to support the Smalltalk applications on a contractual basis.

That allowed them to "hit the ground running", working on their first contract 80/90 percent, gradually shifting over to more and more time on DabbleDB.

Back to Avi - Smalltalk is the crucial technical advantage for them - it's also a psychological advantage for them. They have had interesting conversations with people talking to vendors who surmise that any purchaser won't want a Smalltalk app - to which they answer "Yeah, but if it wasn't in Smalltalk, it simply wouldn't exist".

Now Andrew is giving a demo - you can go watch the video for a taste of that.

An interesting commentary at this point on the expectations of business users as opposed to your "standard" tools (RDBMS, mainstream languages and tools). The guy typing into Excel expects to just enter text. The people using the stock tools expect to "lock down" everything with types. The two modes stand in opposition to each other - Dabble lives over on the spreadsheet side of things, with the user in control of what they enter - and how) it gets interpreted. End users do "ad-hoc refactoring" of spreadsheet data all the time - but they usually can't do that with the IT systems they get.

One thing they realized early on: The Right UI was Critical, and they also realized that most developers (themselves included) are not good UI designers. They brought in an expert in that area right off. Another lesson - networking was, and is, crucial. Attending the right conferences, seeking out (and talking to) the right people. A simple example: the various "geek dinners" you read about from time to time. Avi started out getting geek dinners going with Roland Tanglao in Vancouver (which, apart from Avi's early participation) took off - but ended up forming a set of connections that helped him off eventually.

They've discovered that blogging and blog-related PR is a great launching point. They get 2000-3000 visitors per day. It also helps a heck of a lot with Google page rank, which, all by itself, attracts eyeballs (and possible interest.

Fascinating little side note when someone asked about using Gemstone. The Squeak connection to Gemstone is not maintained, which would mean moving to VW and getting a license. Which actually demonstrates the value of commercial software - you get support for various things you might want at some point :) The flip side of that - bear in mind that - as Avi says - they are trying to replace shared Excel usage, not replace large scale database applications. The infrastructure you need really does depend on the scope of the problem you are trying to solve.

Avi: You would go through a lot of pain to get something far less flexible in Rails (never mind static languages). Using an RDBMS on the back end would be a boat anchor ([ed - for example - Salesforce.com does a fraction of this kind of thing, and likely at a much larger effort on their part]).

What's Pier? Pier is a CMS and application development framework. The basic problem space is a configurable Wiki tool. Magritte is a generic framework for describing classes and their instances (dynamically).

Magritte lets you build views, reports and editors. Also data validation, querying, and for object persistence. It's a meta object framework for those things.

How do they work together? Magritte is a meta-model that is used by Lukas for building Pier with Seaside. You can build web apps using Pier, and have a layer riding on top of Seaside. Pier started life as SmallWiki (a contributed piece in VW at this point). In 2005 he switched to Squeak. The name changed because it's neither Small nor simply a Wiki any longer :)

With the changes, Lukas cleanly separated the view and model from each other. Seaside is the default view in use. Also started getting serious about testing and test coverage. He also added a storage framework, but it's not really in use - he's still saving the image and storing "transactions" as change sets. He's working on a binary persistence solution, and other people are working on plugging in prevlayer.

Now Lukas is doing a small demo of Pier - you can install the code into a Squeak image from SqueakMap. His eding capabilities look similar to things I've seen on Wikipedia - you can have links point either to new pages, or to new sections embedded in an existing page. Since he's using Seaside, that lets you make use of extant Seaside widgets, but in a way that's natural within the editing structure of Pier.

The UI view is all stylesheet driven, so it's as easy to "skin" as any other web application.

On to Magritte - "Describe once, get everywhere"

An example of the dynamic capabilities - the various editors in Pier (that are used for page creation) are created on the fly by Magritte. Lukas uses some naming conventions with class methods in order to get the descriptions picked up.

Where is Magritte used? Certainly in Pier. Also in a product called Aare, a workflow definition and runtime engine. Also used by the Seaside hosting business, and in Conrad, a conference registration system (used by ESUG?).

A general fear - auto-generation frameworks can feel like a straightjacket. Lukas has tried to deal with this by allowing for widegt pluggability (of course, on the web, CSS solves a fair bit of that).

Interesting question came up on the form editor, as to whether any of the data could be pulled from a DB. That would involve a new project to plug in.

Advantages of Magritte:

• Change description, all editors catch it
• Automatically builds views and editors, handles queries, etc
• Extensibility of all classes ensured
• Fully customizable - auto-generated stuff is replaceable

For more info, visit Lukas' websites - Magritte and Pier. Magritte is under the MIT license.

Bruce Badger is the current chairman/admin of the OpenSkils group, which promotes the skills and availability of people who want to find various kinds of consulting work. The talk is covering the application server that Bruce has written to support the website. So first off, he's doing a few definitions for the benefit of non-Smalltalkers in the audience - the Image. Apache, while running, has a footprint (an image). A Smalltalk image can save its running state and be started up again - possibly on a different machine/OS altogether.

To demonstrate, he's showing a quick workspace demo of a printIt operation. "A demonstration is like TinkerBell - it only works if people believe in it" :)

So one architecture has Apache at the top, CGI between that and VisualWorks, which is the server. The application logic is in VW, and the data is stored into a PostgreSQL database. What Bruce advocates is the smallest number of components possible - because it simplifies configuration and deployment. With most J2EE servers, there's an impressive number of XML files to get properly set up. On the other hand, having too few components can be just as bad.

The smallest possible? Run the HTTP server right in the Smalltalk image, and use the database for persistence. Again, a demonstration using the Swazoo web server (a contributed piece from the community that you can load into VW). The cool thing? Inserting a breakpoint into the handler that takes the request, and we can poke around in the guts of the HTTP server and see what's going on. Not that you have to; like any other HTTP server, you can treat it as a "black box".

There's still a bit of an "impedance mismatch" between objects and database tables. This consumes both developer time and runtime resources (re-assembly of the object when taking out, and disassembly when storing in). The analogy Bruce uses? An OO database is like parking your car in the garage and heading to bed. An RDBMS is like taking it apart and hanging the parts on the wall first - and then re-assembling it in the morning.

So what if your back end is Gemstone? Gemstone is actually more than just an OODBMS; it's a full Smalltalk environment with a multi-user image. It's also transactional and highly scalable.

So using GBS (the interface between GS and VW), the persistence layer between the application and the db has shrunk. Like any database, there's performance tuning that you have to deal with. What they could do is run the entire Skillsbase system in Gemstone - no app/persistence separation. There are two issues:

• The Gemstone VM is slower than the VM for VW
• The class library for GS is less extensive than VW's

Next issue - one instance of the application isn't enough.

• Option 1: Many threads per process - involves semaphores and locks, hard for developers to follow - and if they are native threads, you get big differences between development time and production time, because the native threads are non-deterministic
• Option 2: Many processes - simpler for developers, but each process does use more resources.

In Smalltalk, an image tends to be one process, where the threads are managed by Smalltalk. A Gemstone image supports multiple processes called Gems. You get separation by transaction. Changes to objects are local to a Gem until you do a commit.

So with Gemstone, the impedance mismatch goes away - you simple #commit the objects when you want them to be stored. Sometimes, you do need to work with an RDB. It can be simpler if it's not being used for ongoing application persistence, but instead as a "read-only" resource.

With multiple processes, each requires the whole application, and you may well have shared data across them. This can lead to memory waste. You can have the multiple processes use shared memory for the code and read-only data. Making some of that data writable is harder, but possible - Gemstone does this with a shared page cache. There's no developer effort for using this. This becomes invisible to the developer. With this approach, you don't need session affinity (the shared page cache deals with that problem).

What about developer efficiency? They use VisualWorks because it's the best development platform available. They express everything in Smalltalk that can move between VW and Gemstone, and it's all versioned into the Public Store Repository. So they develop in VW, and deploy on Gemstone. This allows them to focus on the problem at hand - no XML configuration files, no differences between runtime/deployment time. Or as Bruce puts it -

Stuff Just Works

The shared page cache makes their application essentially stateless (which helps with scaling). The Gems run as OS Processes, so they make use of multi-processor machines nicely. A commenter points out that the way hardware is going, the shared page cache might well help less - due to blade farm type deployments and the need to start replicating the cache. On the other hand, deploying multiple non-shared images in that setup would be less expensive - I think it depends on the problem you need to solve, and the available hardware resources.

Looks like Dr. Dobbs has noticed Seaside.

The final talk of Smalltalk Solutions 2006 - I'm sitting on on Michael's WithStyle talk. This year, Michael's talking about Version 4, which is Pollock based. SwS consider themselves user interface enablers. They started looking at doing Gecko style stuff in Smalltalk, and looked at Twoflower (limited, no CSS, and at end of life). So they started creating the WithStyle platform. Their idea was to use the technology to create products, but have been open to the idea of letting others use the base platform - as BottomFeeder does.

WithStyle version 3 uses the current UI in VW (Wrapper). WithStyle 4 uses Pollock + XML & CSS. Pollock gives them capabilities that they simply didn't have in Wrapper.

So there's a basic divide: Web GUIs and Desk GUIs. Client interfaces are richer and more configurable, but harder to get deployed. Web GUIs give you CSS styling, cross platform capability, and ease of deployment. Simple example of both on screen, complete with a runtime exception: the demon of demos is present :)

What SwS is doing is combining the two into a view - Pollock widgets and CSS styled text/graphics flowing together. What their platform gives you is the style changing capabilities of CSS in a client UI with all the typical client widgets being available. He's busily eating his own dogfood - the presentation is using WithStyle 4 and a presentation framework that is part of it.

Now a brief demo of XML WithStyle, their XML editing product. It's what we use in the BottomLine blog poster that's part of BottomFeeder.

What standards do they comply with? XHTML, CSS 2.1, the XML for Pollock (they call this Smalltalk UI XML), XIncludes, XML-Events, XML-Schema, XSLT, Docbook, CSS3 (ongoing as events warrant), and any other arbitrary XML. What's being detailed?

• XHTML
• XML-Events
• Smalltalk UI XML (detailed on their website)
• DOM2 Events
• CSS 2.1

For XML Events, they are using the new Announcements framework in VW. It gives them the ability to send much more information along with each event. They've defined a set of standard announcements that developers can use to customize applications that use WS.

They have also created a sandboxed environment for allowing Smalltalk scripting on a page . At present, it enables Smalltalk scripting. The scripting has been integrated with XML-Events. They might be able to support ECMAScript/Javascript, but that depends on what IBM will allow with Smee - something they acquired with Micromuse recently. The script model looks pretty approachable, with a bunch of typical script variables available (the ui, the URL, etc).

They have extended CSS 2.1 (in the way allowed for by the standard), allowing Pollock widgets to be controlled (layout wise) by CSS flow control. This is all encapsulated in the Smalltalk UI XML stuff mentioned above. Question came up about XAML and XUL - they intend to look at (and likely support) those, after they get this base down. XUL will require Javascript support (so see the caveat above).

One thing they pride themselves on is trying to get CSS 2.1 right. They are not fully compliant at this point, but then again - no one is :) At this point, what you're missing by not being here is a demo of a complex bit of CSS and XML-Events, complete with Smalltalk scripting - including a bit of reflection that gets snagged by the sandbox.

What's coming?

• XHTML Editing
• XForms
• XHTML Forms
• More and better CSS 2.1 support

And we'll see how it goes over the next year - I'll be right on top of it, since BottomFeeder is going to move to Pollock, and uses WS already.

Of course we had a runaway log file on the day when no one was watching - we were all here, at Smalltalk Solutions. Then, it took me a bit (being tired and all) to figure out why the server wouldn't restart. I finally tried a local build on my notebook, with all the same files - and sure enough, I had uploaded the latest version of a parcel in ascii mode.

Dohh. It's all back online now - sorry about that!

I missed this in the announcement of Schwartz taking over:

Sun's vision is more relevant today than ever before and is embodied in the product and service breakthroughs it has recently brought to market - from the 'pay-per-view' utility computing Sun Grid and the eco-friendly 32-processor-on-a-chip Coolthreads system, to Sun's innovative software pricing model for the Java Enterprise System and the open sourcing of Java[tm], the Solaris[tm] Operating System and the UltraSPARC T1 chip. The industry has clearly recognized Sun's innovation and the Company has received scores of awards, including Best Server Solution from Waters and the eWeek Excellence Award for Solaris, and is setting numerous record-breaking benchmarks with its UltraSPARC and SunFire systems.

I added the emphasis. The revenue from Java (such as it is) for Sun is in licensing. If they toss it out as Open Source, that would presumably end. Exactly what benefit would Java development bring Sun then? Especially given the fact that it removes any real need for you to use Sun hardware?

One thing Avi is managing to do with Seaside and DabbleDB is get the IT press to notice that Smalltalk is still around, and people are creating cool things with it. Doctor Dobbs has an article from StS at LW/NW on Seaside.

Avi and Andrew presented at DemoCamp while they were in Toronto.

When I restarted the server, I brought back a bug in the Conference survey application - if you've tried to give us feedback over the last 24 hours or so, it's been down. It's back up now - tell us what you think.

Dave Winer today:

I'm participating in a discussion in Palo Alto today with a bunch of people from the web communityin the Bay Area and Senator John Edwards. The terms of the discussion are that we're allowed to acknowledge that we're at this meeting, but we're not allowed to talk about what's discussed here.

Dave Winer in 2003:

There may be another law here. It goes something like this. When you meet in private with someone else to talk about something other people are interested in, we all lose. So, for example, if Pete should go to a private meeting where something relevant to Paul is discussed, and Paul doesn't know about it, Paul's knowledge can't be applied to the process.

Private meetings are fine, I guess, so long as Winer gets invited. Otherwise, they just suck.

STIC, and Smalltalk Solutions at LW/NW, makes some waves:

A programming language that launched more than 25 years ago is enjoying a renaissance at the LinuxWorld/NetworkWorld show. Developers discuss the advantages of an object-oriented approach

The show went well - the talks were well attended, and the vendor booths got a good amount of traffic - I know that Suzanne was a little overwhelmed on Tuesday. All in all it was a great show - and we'll be back there next year

Less is better is having adventures pusing Ruby onto the CLR:

I should have known better, but I failed to account for blittable vs. non-blittable value types in RubyCLR. I explicitly avoid boxing value types in RubyCLR by blitting the value type into memory that I explicilty allocate for the Ruby object. All of my value type marshaling tests were done on sequential layout types such as Point whose layout in managed memory is the same as they would be in unmanaged memory.

Do you get the idea that putting a dynamic language onto the CLR is kind of like trying to dress up a pig? The pig is still ugly after you're done, but it's annoyed.

Suzanne got lucky - she was given a room with a view of the Blue Jays' field (the Renassance has a number of rooms that double as box seats) - the shots below are from a game between the Blue Jays and the Orioles, all from her toom. Suzanne invited a bunch of people up - I watched a game with her, Bruce Badger, and his wife. Here are the Jays on the field:

And the Orioles (who got creamed):

And one more:

Now, if the Yankees are in town for next year's show...

Suzanne sent along a few more pictures - here's Avi and Andrew talking about Seaside:

And here's a shot of Cincom's booth, with the chaos of non-Smalltalk development shown:

And finally, Bob Nemec, new STIC director at the STIC BOF:

I'll post more if I get them, or link to other stuff that turns up. See you next year in Toronto!

Joi Ito has posted a few times now about meetings inside "Second Life". Is this a trend, or a fad? It'll be interesting to see which way that runs - will we be expected to have a virtual presence in places like that soon?

Charles shares his here. I was asked on Wednesday night what my favorite presentations were (surrounded and asked, actually - it was kind of amusing all by itself). Hmm. I enjoyed both of the talks that Avi and Andrew gave - for two guys that work via IM most of the time, they mesh really well on stage. They've been giving their talk at other venues as well, and it really shows.

What else? Blaine gave a good talk. He was funny, self deprecating, and well prepared. Travis' tutorial on Monday was very good as well. It went more as a guided conversation than as a presentation, which was good. I liked the fact that he recognized the non-steady state of optimization - over time, as venor products and OSs change, the things you need to worry about change as well.

Overall, it was a great time, and I'm looking forward to going back next year. I'm still not sure whether Chicken Curry counts as a "traditional Irish favorite" though :)

It looks like some pirates are getting more ambitious:

After two years and thousands of hours of investigation in conjunction with law enforcement agencies in China, Taiwan and Japan, the company said it had uncovered something far more ambitious than clandestine workshops turning out inferior copies of NEC products. The pirates were faking the entire company.

Evidence seized in raids on 18 factories and warehouses in China and Taiwan over the past year showed that the counterfeiters had set up what amounted to a parallel NEC brand with links to a network of more than 50 electronics factories in China, Hong Kong and Taiwan.

In the name of NEC, the pirates copied NEC products, and went as far as developing their own range of consumer electronic products - everything from home entertainment centers to MP3 players. They also coordinated manufacturing and distribution, collecting all the proceeds.

If you consider global sourcing for a minute, you can see how easy it would be for a factory in China to think that it's really dealing with the host company and not a set of fakers. This kind of thing is not going to be easy to stop.

While I was at StS, Nintendo announced the "street name" for the Revolution - they are using Wii (pronounced "we"). 1up.com has more details - there's rampant speculation going on about an early release of the system. It's definitely "wait and see" time here.

Not only did Andres win the StS Coding Contest, he's found some Smalltalk blogs I didn't know about. Here's one (not updated recently) that covers Visual Smalltalk (really!), and here's one that covers Dolphin.

I just saw Ephraim Schwartz' April 24 column - and it shows that the power of "silver bullet" thinking is alive and well in IT. He's not the one having delusions; he's pointing them out. The silver bullet here is "the one unified IT" thing:

Last week, Accenture signed a seven-year applications outsourcing deal with Unilever to run all of Unilever’s application development, implementation, and support. Unilever believes it can save approximately $700,000 in the first year.

At the same time, Accenture will be migrating all of Unilever over to a single system based on SAP’s offerings. The theory, and it is just a theory at this point, is that IT efficiency -- in this case, moving from a thousand different systems to a single vendor solution -- is a competitive advantage.

Unilever is no small company, so you have to figure that they have a lot of disparate IT systems floating around. Sure, having a unified system might be ideal - in the abstract. The road from here to there is twisty at best though - and will involve all of the typical political infighting as various teams fight to preserve their own business processes, rather than get subsumed by the "one true way" being touted by the consultants and the new system.

If they end up saving any money on this, it will be many, many years in the future - and there will be various levels of collateral damage along the way. The first bit will be the concept of first year savings. They might save that, in raw personnel costs (if the number of IT staffers that the article implies will get fired actually do get fired). The soft costs in that first year are going to be enormous though - rewrites are never simple.

If your CIO, CTO, or CEO decides to go to the SOAExecForum, then be prepared to face huge piles of angle bracket based buzzword bingo when they return. Just look at some of the platitude-based business ideas:

What is SOA?
SOA (service-oriented architecture) is a broad framework within which enterprises build, deploy, and manage services; these services are coarse-grained application components that can be called upon by other applications using standard protocols. The primary objective is a more agile application infrastructure that responds swiftly to shifting business demands.

Sounds all enterprisey to me. What's next?

Why is SOA critical for my organization?
Service-oriented architecture (SOA) represents a momentous shift in the relationship between business and IT, requiring significant changes in resource allocation and new perspectives on planning and executing IT initiatives.

Hmm. Where have I heard that before? Maybe back in the 90's, when websites started popping up? Before that, when client/server was all the rage? Sometimes I wonder if they just do a copy/replace operation on the templates. Here's the critical bit:

Who Should Attend
Focused on the growing needs of all vertical industries including Financial, Education, Government, Healthcare, Transportation, Manufacturing, Telecommunications and more, the SOA Executive Forum is tailored to the meet the educational needs of senior technologists and business decision-makers

Definitely enterprisey. Make sure that none of the implementation people attend, because they'll have a bunch of WTF??? kind of questions to ask. Best to bring the formerly (and never) technical, so that the buzzwords can flow freely, and the high powered consultants can sell services in a risk free environment. Batten down the hatches if your senior staff attends this event; it could suddenly get all enterprisey in your shop.

Via Bob Congdon, we learn from Jason Kottke where HAL learned to sing :)

Scoble points to the mess that Warren Kremer Paino Advertising might be making for the State of Maine's tourism business - after Lance Dutson criticized them, they tossed down what can only be described as a SLAPP suit. Boy, there's a way to generate business - whenever you get criticized, make sure you sue the guy behind the criticism. Dunston was completely unknown before this suit; soon a search for their firm will turn up high pagerank criticism of this (I wonder if the geniuses at that agency have googled for "Dell Hell" recently?)

I'll say this - it's really bad publicity for Maine, and worse for the agency. Ask yourself - would you want to hire an agency whose best skill seems to be creating negative PR events for you to deal with? Follow this story and I bet you'll see the State of Maine finding a way to break the contract - and it'll serve that agency right.

I have two suggestions for the *cough* smart *cough* folks over at the agency that suing Dunston:

• Go buy this book, and read it over and over again until you understand it.
• Find a web designer, fast. Your site looks like something from 1997.

Update: Scott Johnson has a different take, based on a conversation he had with Tom McCartin of Warren Kremer Paino. Here's the thing though - whether Lance Dutson is in the wrong, or whether McCartin's agency is in the wrong isn't the big thing anymore - the suit is. If the Boston Globe had run the stories that Dutson did, do you think McCartin would be suing them? Of course not. He's created a negative PR event whether the case has merit or not.

Andres Valloud gives a detailed report on the coding contest at Smalltalk Solutions.

Via Suzanne Fortman, I received some conference photos taken by Brian Foote. It's been a busy day; I may not get them online before tomorrow

It turns out that I do have time to post Brian's pictures. I'm including the captions he suggested :)

Eliot doesn't even need to say a word

Do you want to tell me again that VW isn't the best?

Joost, Bruce, and Michael

Cool Shirt, Michael

Prolly Jim Calling

Baseball, beer, and Smalltalk Marketing

Michael points to a way to pay Anthony Lander back for the "start of StS" dinner on Sunday night - the one where he got left holding $260 of the tab. If you left early, or think you might have underpaid - or just want to help Anthony out - then follow this link.

It looks to me like the Warren Kremer Paino Advertising agency is still living in the early 1990's - the huge impact of the internet as a meme spreading mechanism hasn't really occurred to them yet. I've talked about this at conferences, as I discuss my job of promoting Cincom Smalltalk.

When you want to evangelize, your first task is to point out the good (and hopefully unique) things about the product/service you are promoting. The other thing you do is use aggregation and search tools to look for commentary on your product/service. You do this for a couple of reasons:

• You'll find some success stories that you didn't have to work for
• You'll find other people who are natural allies
• You'll find the negative commentary

The last one is crucial - there's simply no escaping it. Any reasonably sized community will attract gadflies, and you'll have to deal with them. You don't want to pull out the big legal hammer unless there's really no choice - and you certainly don't want to pull it out as your first response.

Which gets me back to what I wrote on this the other day. If you are involved in PR, there's something like the Hippocratic Oath involved: First, do no harm. Meaning, don't create negative PR events for your clients. What do you think the Warren Kramer Paino agency has done for the State of Maine with this huge suit against a small-time blogger? They've created a negative PR event. This is actually worse than the negativity that came of Jeff Jarvis' "Dell Hell" posts - that was an act of omission, as Dell and it's marketing folks tried to figure out what to do in the face of negative publicity from a channel they probably hadn't been looking at much. Here, the PR staff has gone out of its way to create a problem - and both they and the client will be left holding the bag. Heck, go ahead and Google them now - notice how the negative stuff has floated right to the top? That's not how you want net searches for your firm to work, and they have no one to blame but themselves for that.

It's the end of the week, and the end of April - time to have a look at my logs. BottomFeeder downloads ran at a rate of 145 per day last week - the details:

Platform	BottomFeeder Downloads
Windows	441
Linux x86	127
CE ARM	95
Mac X	86
Update	65
Mac 8/9	62
Sources	27
HPUX	25
Solaris	24
Windows98/ME	23
AIX	21
Linux Sparc	14
SGI	3
Linux PPC	3
CE x86	1
ADUX	1

Looks about normal - it's a good thing, to my mind, that the Win 98/ME downloads are dropping. When they are down to the same level as the Alpha (which is an ancient rev of Bf now), I'll be even happier. The HTML page results:

Tool	Percentage of Accesses
Mozilla	64.4%
Internet Explorer	25.1%
MSN Bot	4.3%
Other	4%
Megite	1.2%
Opera	1%

No changes of note in the HTML page accesses either - on to the RSS tool distribution:

Tool	Percentage of Accesses
Mozilla	28.1%
BottomFeeder	15.3%
Net News Wire	10.7%
BlogLines	8.7%
Other	8.3%
Internet Explorer	4.8%
Safari RSS	4.1%
Google Feed Fetcher	3.8%
BlogSearch	1.7%
Planet Smalltalk	1.5%
Magpie	1.4%
RSS Bandit	1.3%
SharpReader	1.2%
JetBrains	1.1%
Liferea	1%
News Fire	1%
MSN Bot	1%
Feed Reader	1%
NewsGator	1%
Feed Demon	1%
Attensa	1%
Java	1%

And that looks about lik eit normally does too.