I spoke at ESUG today, after Mark's talk. Here's a picture Suzanne snapped while I was talking:

The talk went pretty well - I had a good crowd, and they seemed interested. After that, Suzanne and I spoke to a few people and headed out. She's on her way back to California, I'm taking a short break here in Brussels. I'll be posting some pictures we took on the tour yesterday in a few minutes.

It's after lunch, and Mark Johnson is up to talk about VA Smalltalk. I blogged both talks on this at StS. The difference here is that Mark is a marketing guy, not a technical guy - so the tone of this talk should be somewhat different than at StS. On to his agenda:

• Who Instantiations is
• Relationship with IBM
• Roadmap information

Mark has been at Instantiations since 1999, in Marketing and Business Development roles. His charter at Instantiations is to promote Instantiations tools - Smalltalk and otherwise. For those who don't know, Instantiations is a small (25 staff) company in Oregon. They were re-founded in 1997, they mostly partner with IBM, working with Rational, Eclipse, WebSphere.

They've been selling a bunch of VA add-ons for ever since Instantiations was re-founded out of the wreckage of ObjectShare. Late last year, Instantiations started working with IBM at the Raleigh lab to provide 2nd and 3rd level support for IBM. More recently, Instantiations was able to announce and offer VA Smalltalk. They are an Advanced IBM Business Partner. They have been a VisualAge Smalltalk Solution Team Member, member of STIC, and also associated with similar programs for Rational tools, WebSphere, etc.

Now we see the slide that IBM showed at StS - the "either run or walk to Java" slide. Even the maintain Smalltalk slide calls that a "Staged Transformation". Mark is pointing out that Instantiations is taking over marketing and support, so that there's no need to migrate - the choices IBM are laying out are to migrate now, or go to Instantiations.

VA Smalltalk 7 (Instantiations Product):

• Lengthens viable life of VAST applications
• 100% compatible with VA
• Includes VA Assist, WidgetKit/Controls, GF/ST
• Modernized product
• Fully Supported (by Instantiations)
• Roadmap for the future (out 2 years)
• Instantiations is 100% committed to product development

The roadmap:

• VA 7: Summer delivery (late August, early September) - VA 6.0.3 with the additional components listed above
• VA 7.5 (Next year)
  • ANSI support
  • More modernization
  • Integrate RB
  • Newer Windows Widgets
  • More WS* stuff
  • All additional migration stuff

• VA 8 - follow link above

They plan to evolve their own pre-existing tools as well, and integrate them more fully into VAST. Small note - GF/ST will remain a "goodie" (i.e., unsupported). By contract with IBM, they have to include the migration assistance tools from Synchrony Systems. The release was delayed somewhat by the slowness of the 6.0.3 release from IBM. Still on track for Windows GA version shortly (within a week), with Linux, AIX, and Solaris by end of August. Looks like you can contact Mark for a copy of the slides.

Mainframe stuff is still at IBM - Academic licenses are not free. hmmm.

Suzanne Fortman is talking about Smalltalk promotion in the community at large, and specifically at Cincom. No slides - this is a general introduction on her part to this community. I blogged about her StS talk here.

It's raining out, so it's a great time to be inside and hear about the new buzz terms as they hit Smalltalk. Andy Berry is going to cover what SOA (Service Oriented Architecture) is.and what the business benefits and risks are. In particular, he'll cover how it interacts with Smalltalk.

What is "architecture"? Let's pretend that you won the lottery and ask a builder to build you a new house... Heh - Andy has a picture of what you have in mind, and a picture of what the builder actually produced (I lived this one when we had our house built - we didn't get the cathedral ceilings at all where we wanted them...). Like Andy says, the builder always has a rationalization at hand to explain why things went the way they did.

So... consider a city, where you end up with lots of buildings. You want it to all mesh. Now, apply that to IT - you have apps for Sales, Billing, Q/A (etc) - they probably are all silos. They should all tie together (eg - a Sales Enquiry should be able to "turn into" an Invoice w/o any hard work). The bottom line - a suite of applications that work together this way will save money.

An IT architecture must tell us how to link things together. Has to consider both the business itself and the world around it. At this point, imagine a circle ("The World") with boxes for your customers, your suppliers, your company, and your enablers. That's what your architecture has to tie together.

"A Service Oriented Architecture is a way of including everyone - Customers, Suppliers and Enablers - as partners in your IT system" So, an SOA is an architecture designed around services. What's a service? posit a taxi driver, who you call to take you from point A to B - the taxi driver has provided a service. Side note - how the driver gets paid is an interesting point all by itself.

Services:

• Business Oriented - don't tell the taxi driver how to drive
• Asynchronous - I make a request, and it later happens
• Normally, you get what you ask for

Returning to IT - Always ask yourself - can I imagine myself doing this? If so, it could probably be made into a service. A service to submit an invoice is high enough level to call a service. Where does this fit - design/architecture level, or code level? Is SOA:

• The most important development in the last ten years?
• An interesting development that your company should monitor?
• Just a messaging application?

Andy falls into camp two above - start thinking about it, and see how you could/should use it. Consider doing an internal project before trying to go outside the company's walls. So Andy asks us: Can you think of three business oriented services that would allow parts of your company to work more effectively together?

Implementation:

• Do it yourself
• Us a supplier like IBM, Iona (et. al.)
• If you do that, make sure you get monitoring

One option is to use what's called as ESB (Enterprise Service Buss). InfoWorld just did a wrap up on those, iirc - I think I threw rocks at it :) The basic idea is that you wrapper your applications in a messaging layer. What goes on the "bus" - messages - typically, Web Services messages.

At the implementation level, a web service is a service delivered by XML encoded messages. Andy is referring us to "The Semantic Web" by Berners-Lee. This is where you end up intersecting with the "Web 2.0" folks - including the RDF crew.

So what are the benefits? You automate (as much as possible) your communications flow with your suppliers. A simple example of this sort of thing is how we (Cincom Smalltalk) handle "goodie" submissions from authors. They register with us, and then have access to an FTP site. Our normal build process pulls the latest from there - thus eliminating the need for reminder emails. The upshot here is to end up with an architecture rather than a set of isolated silos. You should end up automating out a bunch of things with customers and suppliers.

The risks? At this point, you'll be an early adopter - meaning that you'll inclur extra costs, and be off the wrong way if the buzz ship moves along. How can you mitigate that? Andy's suggestion is that Smalltalk helps here, by dint of its flexibility - and it's supported in Smalltalk (VW and VA, for sure). More:

• Don't bet the business - start small
• Ensure access to mentors that have done this before
• Choose a product before you start implementing.

At the end of this, you want an architecture, not just another "cool" use of buzzword bingo technology. Start small, get buy-in from the right people in your organization, and try to pick an obvious starting point to prototype.

Back to that taxi driver and payment - we just hand him money. Translated to IT, what we really want is "pay as you go" services that are metered. Yes, it sounds utopian - but it's probably a level of outsourcing that will work.

On a more pleasant note, we had a nice walking tour of Brussels today. I started out heading to the airport (by train - my car is stuck in the garage due to this hostage situation). Picked up the wife and daughter, had a cab run us back here. We then went up to VUB to meet up with everyone.

We headed out on the tour after lunch - we had a nice, very funny guide. I'll have some pictures to post tomorrow or the next day - I'm too tired to play with the camera just now. Anyway - things ended at a brewery (only one running in Brussels), and that tour was kind of fun - although the warm air in one room triggered my jet lag and sent me to sleep.

Back at the Uni for the banquet and awards - the prizes went as follows:

1. RoelTyper
2. SqueakSource
3. Intensional Views

There was a funny "10 things I hate about Smalltalk" speech at the banquet - things like "I hate how productive it is - think about job security!", but delivered in a humorous way. All in all, a good day.

Joseph Pelrine: "Anytime we run code, we are testing". So in fact, we test code all the time - SUnit simply formalizes the process. Heh - the demos are all in VA, and Joseph felt compelled to announce that this shouldn't be taken as any kind of endorsement of one ST over another - all the code he's going to talk about is available for multiple dialects.

Smalltalkers should be proud that unit testing spread out of Smalltalk - it's another thing that we originated. The cross dialect versions of SUnit originated at a Camp Smalltalk in 2001. "This talk is about the interesting and cool stuff in SUnit that no one knows about or understands". JUnit - it's a big, fat version of SUnit - apparently, the elegance has been lost, and the other revs for other dialects have come from the JUnit version.

Now it's demo mode. Joseph has added descriptions to assertions (which can be logged) - allows you to see something about the failure without having to jump into the debugger. That would help when running a long set of tests. So - instead of:

self assert: someBooleanDescription.

We add:

self assert: someBooleanDescription description: 'Describe Failure Here'

Another thing is that it's often the case that - instead of just stopping on a test failure, we want to resume (perhaps other tests depend on this). So, Joseph has added a resumable test case that lets a failure get logged (see above), but doesn't stop.

"Unit tests are the only valid functional specification of a system"

Moving along - what about TestResources? In the simple case, we have #setUp and #tearDown (set a test up, tear it down). If you run a lot of tests, this could get expensive if you are using the same resource over and over again (say, opening an HTTP connection, opening a db connection, etc). A TestResource is a way of allowing such shared resources to move across multiple test cases. If the TestResource initialization doesn't work, none of the affected tests are run at all. Basically, it's an extended #setUp/#tearDown. It uses that same API as well. Like test cases, you derive new TestResources from the common superclass TestResource.

On the class side of the test case, you add a method like this:

resources
		^Array with: MyTestResourceHere 

Sometimes, you want to be able to use other tools with your testing - thus ExtensibleTestCase. The example - a simple test that compares two strings, failing if they don't match. What the extension does here is hook a text differator into the results - Joseph has used it to hook SUnit to ENVY Q/A and TestMentor. Nifty example - Joseph has a demo that hooks the "Debug" option to SmallLint instead. The hookup? An abstract class that specifies which methods are test methods (instead of the default, which picks up all the ones that begin with 'test'). Then, an override of the #performTest method to have it run the right test, and then apply SmallLint (or what have you) in case of failure - specifying which rules to apply.

This is actually one of the really cool things about SUnit - you can whack this sort of thing into the framework easily. Doing the equivalent kind of hacking in Java (or C#, et. al.) would be much more complicated.

Coming features:

• Remove TestRunner - better integration in all major dialects
• Integrate the description (first part) with hover help, so that moving the mouse over the list of failures will show the results w/o having to jump in
• Integration with a logging framework that Joseph has (Toothpick). Came out of someone wanting log4j like capability - Joseph decided to see what such a thing would look like if you did it right.
• Make TestErrors and TestFailures into new objects, instead of just exceptions.
• Integrate Continuations, allowing you to backtrack to the error state - note - that piece won't move to all dialects.
• What Joseph really wants to do is create a tight common core, and have other people configure specifically for each dialect.

Joseph has a download site for lots of the stuff he's talked about here, plus other stuff (like the Smalltalk Balloon graphics, Knights of the Square Bracket logo, etc). Look here.

Question: Why do so many people misunderstand/misuse TestResources? There hasn't been enough explanation - it's been passed by word of mouth and code reading. More needs to be done there - there's a manual at the link above.

Question: Two roles for helpers. One is for "heavy hitters" to do dialect specific work. Another one is for people to read/review the new TestResource manual.

After lunch - Rowan Bunning is up to talk about WithStyle. They see the kinds of things they can do in WithStyle as a counterpoint to AJAX style web development - why sacrifice the power of that client you have burning up cpu cycles?

• Intro to WithStyle
• Basic Examples
• Architecture
• Applications and Case Studies
• XML WithStyle
• WithStyle V4
• Future Possibilities

Heh - I'm using WithStyle to blog about the talk - WS is the editor behind the BottomLine blog tool. Where is SwS - Canberra, Australia. They've been working in Smalltalk for many years (at Wizard, in VA). Many community projects: LibTidy, LibXSLT, NetResources, BottomFeeder, BottomLine, NetResources, WebDAV interface, Typeless. They really are tireless this way - they have provided a ton of useful tools.

Rowan is the XML WithStyle Product Manager - he's got a blog as well, as does Michael Lucas-Smith. WS is:

• XML UI for Smalltalk
• CSS based rendering
• 100% Smalltalk objects
• Open and Highly flexible
• Building a synergy between the desktop UI in Smalltalk and the web browser

So - why should we care? This stuff is end user configurable (as opposed to the typical desktop UI). It uses technology that is smack in the mainstream (XML, CSS). Allows you to move between the web and the desktop easily, and brings the full power of the desktop. Differentiators for WS -

• Targeting business apps, not general web space
• Many deployment possibilities
  • Intranet/Extranet
  • Thin Client
  • Embedded desktop/fat client

Stable V3 engine now (used in BottomFeeder/BottomLine). Released EzyXML (editor). Supports CSS2. Supports scripting (Smalltalk). About 33,500 lines of code - working on V4 (Pollock based).

Some demo apps - the example browser, the slide viewer - showing how you can build small apps quickly using WS. I can attest to this - moving BottomFeeder from Twoflower to WS was not at all hard. The Architecture:

• Developer Tools
• Editing - rich editing on top of a schema)
• Layout (CSS)
• XML
• Network layer - download manager and protocol services

In the layout layer, V4 uses Pollock styled by CSS. Michael and I have talked about this for all or part of the BottomFeeder UI. In the editor, there's spellchecking (external C lib), text editor behaviors, structured (schema based) editing, and XML and Object backmapping. BottomLine (the BF blog tool) uses this stuff.

What applications are there? Embedded Browser/Editor, Web App Client, WYSIWYG editor, BottomFeeder, BottomLine, Seaside Rich UI, ExyXML. Next, demos - he showed of WS in BottomFeeder and in the BottomLine posting tool. They were pretty darn easy to integrate, and made my life massively simpler. The concept behind the Seaside Rich UI is to allow Seaside usage in a thin, non-browser based UI. Instead of JavaScript/AJAX, you get Smalltalk - i.e., a smart client. EzyXML, and editor that's been deployed at the ACS (Australian Federal Level government). XML WithStyle - a more full content edting system, hooked up with network services (including WebDAV). Beta available now, plans to get to DocBook and HR-XML. Features multiple undo/redo, specllcheck. Based on open standards - uses XSLT and CSS. Highly configurable.

Coming up - V4

• Better "Box" model
• CSS3
• StyledXML
• Speed, flexibility (Pollock based)
• Drag/Drop editing
• Before/After (CSS)
• Paging
• Zooming

Once they get to Pollock, they intend to allow embedded widgets - i.e., Pollock Widgets in WS forms. They will support HTML Forms, and Pollock's XML UI definition. They would like to get to XForms, XUL, and maybe Avalon.

Question - what about licensing? It's still being worked up - something will be announced soon. We've been concentrating on getting the code ready.

Question - Seems to be a little slow? The demos are on the Mac, where VW performance in general has been an issue. That's being addressed by Cincom.

David Shaffer on testing Seaside components. David's been doing a fair bit of Seaside work, and teaches Smalltalk at Westminster University. He and his students do a lot of Seaside work. Small aside here - there's a lot of Squeak/Seaside at this conference, especially in comparison to June's Smalltalk Solutions.

Some of what's up in Seaside testing:

• Tests run on the server (i.e., access to the tested component)
• Uses the Smalltalk debugger
• Web test runner
• Available for Squeak and VisualWorks (hat tip to Cincom's Michel Bany for the port)

Provides a test harness with a simulated web browser environment. You render the component into the harness. Setting up:

testComponent1
	self newApplicationWithRootClass: SCTestComponent1.
	self establishSession.
	self assert: (self lastResponse stringWithId: 'main') = 'hello'.

The nice thing here - you don't need to drive the web app to a specific point - you can do actual unit/component level testing. You can follow anchors this way, and then make assertions (as in normal unit testing) about where you should be and what state you should be in. The simulated browser environment hands back an XHTML DOM (XMLElement). The framework provides convenience methods for extracting useful bits.

Side point from me - it seems to me that you could combine this with WithStyle to provide a more visual unit testing framework - and they have a whole lot of useful code for dealing with XML.

So what can be tested?

• State - often tests of state are less brittle than display tests
• answer - components that provide a Seaside answer
• callbacks - components that provide hooks

For Seaside, you need to be able to backtrack, and the framework handles that as well. Other possible topics:

• Sessions are accessible
• There are hooks for configuring applications
• The history in the web test runner is "live"
• Marking interactions for visual inspection (so that you can look at the actual output later - important for GUI level examination. Note - framework masks self as Mozilla).
• David's site

Not tested - visual appearances, although snapshots (see above) can be saved. JavaScript not fully supported, but working with a JavaScript test framework (Selenium) for that. He would like to make the APIs consistent so that test cases could move back and forth. Other frameworks:

• SmallHttpUnit - VW, runs outside the server, excellent API for accessing page elements
• HttpUnit - Java, external as well
• Cactus - runs in server (Java) like HttpUnit
• Struts has a framework as well

Question - would using WS or Twoflower for display help? Not so much. Having a "is it basically right (visually)" would be nice, but most visual issues are on the order of "looks ok in Mozilla, it's screwed in IE" sort of problem ("up level experience" notwithstanding).