Well, that wraps ESUG 2004. It's been a good two days - I wish I could have seen the first two. I'll be linking Niall's and John's reporting as I get it. On to Camp Smalltalk, and then home.

Stephanne Ducasse and Michele Lanza are behind Moose - one of their grad students, Tudor Girba is up to discuss Moose. It was started in 1997 at the University of Berne. So to start - we define some basic terms.

• Re-Engineering - you go from idea, to design, to code. As time goes by, you end up losing the original structure and cleanliness. Re-Engineering is the process of getting back in the right direction.

A high level view (i.e., a class diagram) does not qualify as reverse engineering. Moose is a re-engineering tool. It can be use to create metrics, do evolution analysis, and show diagrams of the code. The basic metrics can answer questions like - How much code, how many classes, how many methods per class, how many lines per method, etc.

Visualization can provide a quick overview. A spatial orientation can give you a quick look at what you have, allowing you to use other tools once you focus in.

Evolution analysis looks at how the code evolved (how did we get from there to here. History can tell you which parts are change prone, and can tell you how you arrived in the place you are at now.

Moose is a VisualWorks tool. By selecting a specific version of the code (a model), we can examine various aspects of the system. Moose is an environment for re-engineering. It can work with C, C++, Java, Cobol, VisualWorks Smalltalk, and Squeak Smalltalk. It could be extended to deal with other languages as well. It's available under the BSD license (free). It's research driven, but has been validated in industry. The rest of this presentation is a demo - you can get a lot of that information at the website - and you can download it here

Up next - Markus Denker on AOSTA. Markus is doing this work for Squeak. We already have JIT systems for the commercial systems, and even an (unreleased) JIT for Squeak. What this is about is "hotspotting". This is all done at the Smalltalk level, using the profile information created by the JIT compiler. The system would compile to optimized bytecode, but get turned off for debugging purposes. The main areas:

• Profiled execution of (unoptimized) areas from the JIT
• Collect type information from the PIC (Polymorphic Inline Cache). Needs to be readable at the Smalltalk level
• Inlining (from the above)

Where is it? The design is done, but not tested, The bytecode transformations (to SSA) is done, and works in VisualWorks. The backend - a transformation out of SSA is being done now, with a simple code generator (In Squeak - works with some examples now). SSA stands for Static Simple Assignment.

Two steps:

• Deconstruct the SSA
• Generate Bytecode

The main problem that can crop up is that some optimizations end up with wrong results - you need to fix that up - which makes the algorithm more complex. There's an answer to this called the Phi-Congruency Method.

To do - lots - dynamic deoptimization (for debugging). Possible experiments:

• AOSTA for Squeak with a JIT
• Does it make sense for an interpreter?
• Exupery as a backend?

With a byte code to byte code translator, what else is possible?

• Enables more late binding
• An API for changing the language semantics and implementation at runtime (for example, the meaning of inheritance)
• Squeak has MetaClassTalk, but it's slow
• iVARS are accessed via offsets
• offsets calculated at compile time
• makes changes and experiments harder
• Make a MOP more practical
• Allows a much simpler system

Bottom line - could enable a lot of things that aren't (directly) related to performance.

Petr Stepanek is talking about Gemstone, and comparing it to relational technology. So - starting with the object model. If you are using Smalltalk, then you have one - the example in this case is a call center (CRM) system. The problem is that the underlying data (object) model is not immediately known, and will be changing over time. This customer wants live development on a 24x7 system. They have looked at various commercial CRM systems, and have not been impressed - so they opted for a custom system.

Live Development, constant change to a running production system (you mean, that thing that critics like Isaac says customers don't want?) - that's what they want here. They did a fair amount of reading for possible solutions, including the ValueWithHistory idea put forth by Kent Beck - where you use Decorators on objects instead of instance variables. They ended up with what they call a Linked Object Model (if I can get a copy of the presentation, I'll post a link - there are some pictures on the slides). In general, they have a "cloud of data" with various links between the objects. They use a Node class which holds links between objects. They ended up with the following rough choices (the picture of the object model is complex :)

• an RDB with two huge tables (Links and Nodes)
• plus additional tables for Node subclasses
• Or an OODB (they selected Gemstone)

So how do you get at the data to change it - write accessing methods!

Setter

Link new
	node1: aPerson;
	node2: aName;
	meaning12: 'name';
	meaning 21: 'person';
	hook

Getter

^OneLinkTraverser new
	node1: self;
	meaning12: 'name';
	validAt: Timestamp now;
	node2.

Slower than direct accessors, but they have been able to deal with that. They keep links in Gemstone, and they implemented the OneLinkTraverser class (etc) in Gemstone (so that it runs on the server). They have also implemented aggressive caching. The pros and cons:

Cons

• Complex - not immediately obvious or "natural"
• Confusing - inspecting is complex (solvable with Trippy in VW via #inspectorExtraAttributes) - not solvable in Gemstone

Pros

• Less work - no idea how they could do this (well) in an RDBMS
• Past data handled same as current data
• May change model with no GS class migration on a live system
• High chance of committing transaction in GS
• Can still use GS indexes.

On the business side, this is great for complex models that change over time - which this one does. Past data is important, and easily accessible. Fast responses for requests from any direction are supported in this model, and that's critical in this business.

I arrived a little late this morning, and found Avi talking about Seaside and web applications. This is actually the same talk he gave at Smalltalk Solutions 2004, so I'm going to sit back and enjoy the talk this time.

Carsten Haerle is talking to us about Smalltalk in teacher support. Schools may have hundreds of PCs and thousands of users, with many applications to install and manage - typically without a dedicated system administrator. This leaves the task to teachers, who are also trying to teach the students. Another problem is making PC's tamper proof - including the ability to roll back to a known state after each class. There's also the need to do internet filtering, and make sure that the same content is displayed/transmitted to each PC.

They wrote an application Beno which integrates a few other (non-Smalltalk) Windows applications: DX-Union - that handles deployment issues - management of what should be where, etc. Another application - Dr. Kaiser - makes PCs tamper proof. NetO handles screen transmission, and Cobion/Time does internet filtering. Beno is an integration platform for all of these applications. This created a single point of interaction for all of the supported functions. So, now comes a demo - something that doesn't come across well in a blog :) What he's showing us is how you can use Beno to push an installation (In this case, the Google Toolbar) out to a set of managed PCs.

It's a cool and useful suite of applications - written in Dolphin Smalltalk. They are the biggest distributor of this kind of software in Germany. Why Smalltalk?

• Cost savings in Smalltalk
• Faster Development
• Better Diagnostic capabilities
• Able to do this with a 6-7 person team - could not have done that with VB or C++ or Delphi

Unlike a lot of Smalltalk applications, this is a shrinkwrap application, and they are likely going to get MS logo certification. Which Smalltalk? Dolphin, which they consider to be the replacement for Digitalk Smalltalk.

Update: I made some corrections to the text based on an email from Carsten.

Christian Haidar is talking about how his company uses Smalltalk to build products - including development, marketing, and pricing. He started with a contract to build a simple chart program He built a system he called smallCharts in 3 man months over the course of a year. That went well, and the system went into production. As a result, he trademarked the term smallCharts. He then got a contract to build something similar for the parent company - so he founded a company and got the job done in a few months. He's now gotten a second contract for his new company. What did Smalltalk have to do with any of this?

• He did the project only because he could use Smalltalk
• Change requests that came from clients were quickly addressable
• The ability to explore external data sources (stock market feeds) dynamically (see this post from Bruce Badger - it's the same idea).

What's different about running a small company? Worrying about profits, dealing with people (negotiations), Organization, partners, bureaucracy (of prospects, and of your own). Small stuff - company logo, website. It has to get done :) Other things that come up - professional delivery, testing, bug tracking and support - it stops being a pet project on sourceforge and starts being a product. What about marketing?

It was easy when he had one customer. After that, it took legwork. He had to get his message out to decision makers and use word of mouth - get both himself and his product known. All the things that engineers in a large company rarely think about :) Then there's the whole problem of pricing - rental, license, what? Figuring out who the competition is isn't always as easy as you might think.

So what were his early mistakes? Lack of marketing, and an under-estimation of how long it would take to build things. Even more critical, he underestimated how long a prospect would take to make a decision.

DB Systems and Daedalos Consulting are telling us about their train scheduling system for the German railways - they call it RUT-K. The system (rail) is big - 40,000 passenger and freight trains, 65,000 kilometers of track, and 8500 crossings and switches. The trains run at different speeds to different stops. There are 400 users of the system in 7 offices across Germany.

Managing a train schedule is like putting together a huge puzzle

The system handles:

• Exact construction of train paths
• Timetabling by train
• A structured database holding multiple versions of the timetables (with variants)
• Distributed data storage and data editing capabilities

The system allows for interactive development of train paths and schedules, with user inquiries answered by possible answers. The inputs are the objectives - train path and stops (including times), as well as the actual circulation of the train. The system creates a detailed timetable without conflicts and calculated running times. Potential conflicts in a user's desired path/schedule are displayed , and the system supports graphical editing of train paths and schedules. Reports for this can all be generated.

The system has to generate these visual schedules quickly, and detect (and make users aware of) conflicts rapidly. They managing hundreds of MB of data in the client application. They have gotten some smart people on board to define appropriate algorithms for solving these problems in code - successfully. The system is client/server, using Oracle as a back end. The development environment has migrated from VW 3.1 and Envy to VW 7.x and Store. They also have an offline version for laptops.

RUT-K is not the only Smalltalk application used in the railway system - their scheduling/planning system and some of their back office systems are also done in Smalltalk. The system has been deployed since April 2003. Why has it been successful?

• User involvement at all points
• Detailed specifications
• Short development iterations
• The organization and team
• Smalltalk
• Reuse of components across applications
• Easy build process
• Powerful class libraries

I've seen the application in their offices, and it's very impressive. We are seeing a demonstration of the mobile version running on a laptop with test data. I'll have to see if anyone with a digital camera has shots to post.