Smalltalk Tidbits, Industry Rants

Jonathan Schwartz does it again. In a great exercise in hand waving, he says this:

Sun is not a threat to GNU/linux. Innovation is not a threat to GNU/linux. dTrace is not a threat to linux. Nor is Solaris 10, nor Janus. Nor is our new comp plan.

Well duh. Now, Is Linux a threat to Sun and Solaris? Look no further than here, and make sure you notice what Sun's number's look like without the MS sugar money. I wrote about that here. Michael Lucas-Smith has some related comments here.

In this post, I talked about how MS' security model is still too little, too late. Take a look at Steve Wart's comment - he makes an excellent point:

Check out your referrer spam -- even the most obscure blogs are getting thousands of hits a day. Do you think these companies are doing this manually? "0wners" of the zombie nets will let you get your URL added to thousands of web sites for a small fee.

That's why this happens. The early stuff was pranks - it's business now.

With interest in Continuation based web applications growing, it's a good thing that I stumbled on this Seaside tutorial on the CST wiki. The spam that some moron added to the bottom has been removed, so have a look!

I've got the conversion from the Http-Access codebase over to the cleaner NetResources package (both in the public store) done. NetResources is a cleaner, simpler network layer - it's removed all of the Http stuff from my code and sloughed it off to the library (where it belongs). I've not completed the testing, but the early results look good. Next, I can start on the Twoflower to WithStyle conversion. Once I'm comfortable with that, an improved BottomFeeder will be available. It'll require a VM and Image replacement; in addition the library changes, the new version will be based on the recently released VW 7.2.1.

Bruce Badger explains how to be truly productive.

Joseph is giving a talk on the future of Smalltalk today in Basel. If you're nearby, check it out

The Register reports that the UK's navy is going to use Windows as the platform on some of their ships - including ones that carry Trident missiles. Color me unimpressed with that choice....

This panel discussion at OOPSLA has gotten Alan some attention - his blogged has been linked off of the msdn architecture site (scroll down to the OOPSLA links - the one that mentions the J2EE vs. .NET shootout). Go Alan!

A few of us got to talking about Sun, IBM, and Java on the IRC channel, and here's what came out of that - this may well qualify as "you had to be there", but anyway:

[22:55] <michaell> what sun did was this. They built their own kind of microwave, made lots of them, put them in stores all over the country, then gave them away for free. Every other microwave company that didn't have locked-in customers gets hit hard, but demand for the free microwave can't be met and people who already have microwaves that work don't need a new one yet

[22:56] <jarober> what they did is give IBM a stick to use, and then they bent over to get beaten

[22:56] <michaell> every one that didn't have a microwave "because it leaks radiation" suddenly jumps in and grabs one, because it's free

[22:56] <michaell> then IBM comes along and says "We can service your free sun microwave for only $10000"

[22:57] <jarober> heh

[22:57] <michaell> so people turn to sun and say "We didn't pay anything for this microwave and now we have to pay IBM $10000 to fix it when it broke because you used dodgy parts." To which Sun replies, "Can't talk now, building another batch of microwaves to give away."

[22:58] <michaell> So then microsoft comes along and says "Well, how about you buy our microwave at a market reduced price and we also support you, for $1000". So people buy Microsoft microwaves, forgetting all the old microwaves that were only $50 still work just as well.

[22:59] <michaell> That flooding of the market is like walking in to a market place where vendors are trying to sell their wares and pulling out an electromagnetic powered loud speaker and talking over every one, then shutting it off - every ones ears are ringing so no one can sell anything there any more.

In that chat, this is michaell.

I'm leaving late, but I'm off to ESUG in Koethen, Germany. I'll be there for part of Camp Smalltalk as well; I don't leave for home until next Sunday. I've missed 2 days of the conference, so I have some catching up to do - better late than never. I'm hoping that the remnants of Frances don't screw with my flight plans - the leg to Germany leaves from Charlotte, NC this afternoon (4:30 pm). Crossing my fingers on my way out the door...

Give people a gigabyte of storage, and who knows what they'll do with it. Over on slashdot, we see that someone has written a blog server on top of gmail. Sometimes, the most fascinating uses of a technology are the things it wasn't designed for...

I am finally back at the hotel in Koethen. I arrived in Frankfurt at 7 am (local time), and got a ride up here with one of my colleagues in the Frankfurt office. That was a long ride - 4 hours. We got here about noon, just in time for a scheduled social outing. We headed out to a railroad museum located near one of the old East German coal mines. The trains and tenders there were fascinating, and the tour guide did a very good job, even though he spoke very little English. Lots of cool machines there. We also had some coffee and cake, which I definitely needed after the long flight and drive.

From there we went to the site of one of the old coal mines, which they are now calling "Ferropolis". It was run by the former government until reunification, when it was shut down. It was a massively inefficient strip mining operation - 1/3rd of the power generated was used just to power the mine itself. It was also brown coal, which apparently burns very dirty. They are in the midst of a large cleanup, and the mine is being filled in as a lake - it should turn out quite nicely once they get that done.

There were some truly large machines they had preserved - they had been in the mine itself, but had been conveyed out for a large scale monument to the past. They ranged in age from 1944 to 1986 - that last was one of the most rusted out, oddly enough. The machines are ranged around an arena, up on platforms - they now have concerts down there (Metallica has played there, appropriately enough). They are refurbishing some of the offices to act as discos, and trying to make the surrounding area into parkland. All in all, an ambitious plan for one of the "rustbelt" areas of Germany

Then, we headed to the Wurlitzer park area for dinner. Alan showed a few people his progress on tools for Store using GLORP - including the ability to read a Store repository from a VA Envy image. Very nifty. We had a good dinner and pleasant conversation, followed by a (late) walk around the town and lake. The trip back to the hotel had a delay based on some kind of traffic problem (an accident?), but we got back here just before 11:30. A full day, and I'm definitely ready to get some sleep. I'll be taking notes during the sessions tomorrow, and there's supposed to be WiFi access in the conference room. We'll see.

There's WiFi here at the conference itself, but I was unable to get dialup working at the hotel last night. It looks like I'll be connected only during the day. There's a busy schedule of evening events, so maybe that's ok. I'm not speaking until tomorrow, so I can just sit back and listen to the business track today. Right now we are hearing Monika Laurent (Cincom marketing) talk about business and technical marketing as it relates to Smalltalk.

One of the persistent theories you'll see bandied about is this: "You can make up for low prices with volume". This works in one of a few circumstances:

• Even with the low price, you are still profitable - i.e., you are willing to trade a level of profit margin for increased market share.
• You have enough money that you can afford to take a temporary loss in a business in order to drive out your competitors. You'll then recover by raising prices back into a profitable range
• You have a loss leader that drives other (profitable) business. In this case, you are willing to lose money in one area because the gains elsewhere (directly or indirectly driven by the loss leader) are larger than the loss

The key thing is that one of those things has to be true in order for a losing business to make business sense. Microsoft follows a loss leader theory with their development tools, for instance. They really don't care whether they make money from their development tools, so long as their adoption drives sales of Windows (the OS) and Office. IBM uses Eclipse as a loss leader to drive sales of things like WebSphere and their services business. Various airlines have lowered prices dramatically on specific routes in order to drive a competitor out of that space - afterwards, the prices rise back into the profit zone.

And then there's Sun. Sun's business depended (and still depends) on the sale of Sparc based hardware running Solaris. What that means is that anything which commoditizes hardware is a net negative for Sun. This is obvious to anyone who's paying attention - which apparently doesn't include Jonathan Schwartz:

As I've said, I'm a big believer in the idea that volume wins. And we invest (much to the occasional befuddlement of our friends on Wall Street) to support that thesis - most notably in the propagation of our programming platform, Java.

And in the J2ME mobile handset platform, the dividends are beginning to appear - in the form of the single most popular platform those devices have ever seen (as measured, of course, by volume - which happens to be a handy precursor for revenue for every network service imagineable). That volume begets more volume, more licensees, more apps, more infrastructure. And so forth.

There's a reason that the Wall Street crowd is befuddled by Sun's investments - it makes little business sense. Look at what Java has achieved - the platform no longer matters. Want to build an application server? It'll run just as well on commodity intel hardware as it does on Sun's expensive hardware - which leads to a drop in sales volume for that expensive hardware. This is clear as day - commoditizing the platform has been a godsend for IBM, and ruination for Sun. Mobile phones? Is he kidding? First off, the margins on sales of those are tiny, and second, Sun isn't building them. Maybe JVM licenses are profitable there, but only for a much smaller company. Look back at my initial three reasons for selling at a loss:

• Is Java leading to higher sales of Sun hardware at lower profit margins? Clearly, so
• Is Java causing temporary losses as it drives other companies out of the field? Umm, no. IBM is cleaning up, and Sun has virtually no presence at all in the software (applications) field
• Is Java a loss leader? In a sense, yes. Unfortunately, it's a loss for Sun, but the beneficiary is IBM. This isn't a long term help for Sun

Volume really isn't enough, unless it's part of another strategy. For Sun, volume seems to be an end in itself, and that's why Wall Street is unimpressed.

Don Park links to Scoble explaining a problem at MSDN:

RSS is broken, is what happened. It's not scalable when 10s of thousands of people start subscribing to thousands of separate RSS feeds and start pulling down those feeds every few minutes (default aggregator behavior is to pull down a feed every hour).

Bandwidth usage was growing faster than MSDN's ability to pay for, or keep up with, the bandwidth. Terrabytes of bandwidth were being used up by RSS.

So here's my set of questions:

• Do the MSDN feeds support conditional-get?
• Do the MSDN feeds use mod-gzip?

If the answer to either one is no, then the problem isn't RSS - it's with Microsoft. So which is it?

Martin Fowler explains what a closure is. It's a valuable explanation for non-Smalltalkers who keep hearing how useful they are :)

I missed the first day of ESUG 2004 - I was enjoying the labor day holiday. However, John McIntosh was taking notes! Enjoy.

I see that Synchrony Systems has a partner in Europe - Tricept. I'm hearing the same "modernize your Smalltalk application by moving to Java" pitch that I heard at Smalltalk Solutions. There's an interesting problem here, but it's not the one you think I'm going to bring up. One of the big pitches here is that you'll need to take your old client/server application and make it into a server based application. Yeah, that'll work.

Back in the old days, ParcPlace had a pitch like this when we released VisualWave (in 1995). We told people that you could just load Wave, and bingo - your old application would be instantly web enabled. It's not that easy. Client/Server applications tend to have a huge number of single user assumptions baked in, and transforming an application to be server capable is not a matter of changing look policies (widgets to HTML widgets), or translating from Smalltalk to Java. It's fundamentally about rewriting your application.

When you hear someone pitch you on the notion of using tools to "modernize" your Smalltalk application (i.e., move it to Java and make it server aware) - you need to understand just how deep the money pit is that they want you to fall into. It's not a surprise that the people pushing this represent service companies that bill by the hour :)

Niall Ross is talking about the value of Smalltalk - in the context of JP Morgan's experience with VisualWorks and Gemstone in the Kapital project. What is Kapital? Kaital is a risk and value management system. It deals with complex financial products and figuring out their actual value so that buying and selling can be done profitably - in other words, you don't want to offer a product whose value statement is "take my money". It's used in three ways:

• batch jobs - run overnight, all night, every night. This derives a map of possible risks
• interactive - the traders manage their books, value trades, etc
• housekeeping - weekend runs clean data, archive, verify, do sanity checks, etc

Kapital has a team of 30 developers and 500 end users across New York, London, and Tokyo. Ultimately, it's the enabler of $Large revenues for the investment bank. Niall had to remove the actual number :)

So why does it matter that this is done in Smalltalk? Kapital is a very hard problem. The issue here is simply delivering any system at all. The domain requires a meta-model in order to actually define the financial systems being modelled:

• All objects can value themselves
• All objects can walk their graph to explain themselves
• domain models are in VW only; GS is a memory extension

It took 1.5 years to get the models right. The reason Smalltalk fits for this is that meta-modelling is so easy in Smalltalk. The domain in this business is rapidly changing and unfixed - which makes it very hard to deal with in more static systems (e.g., Java). Kapital survived by delivering value early. Smalltalk enables meta-modelling because the meta model of Smalltalk is available - everything is an object, and there are few reserved words. Nothing gets in the way. For instance - the lack of (static) typing removes the obstacles that would otherwise stand between the developers and the models.

Kapital survived the PPS/ObjectShare meltdown, and got past the Gemstone/Brokat problem as well. Management was nervous, but the traders needed the value that the system delivered - there was too much money at stake to stop development for an N month/year migration effort, during which no updates would happen in the existing system. Smalltalk allows the developers to work very closely with the traders. Example:

• New financial product (can't say what) was introduced
• Every client of every investment bank asked for it
• For a (longish) period, only JPM could offer it, because they were the only bank that could actually handle the new product with their software systems
• Result - JPM gained 100% of the business during that period, which helped drive new client relationships
• Competitors got into this with expensive staff increases and dodgy spreadsheets - Kapital managed to expand with small amounts of new code

Rapid delivery has distinct value in this space. Another benefit is scalability. The Kapital system (over 10,000 classes) is delivered to traders as an unstripped (i.e., as a development image prepared for application use). This means that production problems that are unique to production runtime issues can be found, debugged, and fixed. Performance has never been an issue that they could not overcome. Smalltalk has allowed them to figure out real bottlenecks with full tool support.

Re-engineering is far, far easier because everything is available and accessible. An example:

• Kapital started with 200 financial time series objects (curves). Now has 70,000
• retrieving their keys (descriptors) began to slow an important UI operation. Users were unhappy
• re-engineered to use lazy synchronization for this
• Re-engineering this core part of the product was easier because there are no hidden bits, no final classes, etc - everything is open

Another thing that is easier is data migration. The domain model changes over time, and this has to be managed. Data is lazily migrated as it's loaded from the persistent store, and then saved in that state as necessary. This means that they don't need to do explicit schema migrations that stop operations when new revs come out - it all happens automatically. This means that developers can run the latest codebase agaiinst copies of the production database without having to upgrade everything. Data upgrade on release takes less time.

What would they like to do better?

• They would like to have performant meta enabled collection classes
• Would like to more easily find and get rid of dead code. In a 90 MB image, they think they might have 20MB of it
• Same problem with dead data
• Like the rest of us, they would like to enforce better coding standards

More information: A press release and some more information

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.

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.

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.

I noticed this morning that MS is longer providing full content in their RSS feeds, and I commented on that here. Since then, I was told that the MSDN site supports both mod-gzip and conditional-get - and that they still had bandwidth issues. I was skeptical, to say the least. So, I fired up a VW image and tried the following:

HttpClientModel get: 'http://blogs.msdn.com/MainFeed.aspx'.

I stepped through the request in a debugger, so that I could see exactly what happened. Sure enough, the request asked for compressed content - but did not receive it. I got back a textual response with the feed's contents. As I stepped through, my code cached the necessary information for a future request (i.e., the requisite information for conditional-get). Then I immediately executed the same request. Still not compressed content, but another surprise - the exact same response (i.e., same content) - not a 304. So, color me unimpressed. The problem isn't with RSS, and we don't need some snazzy updated version of nntp. What we need is for someone to provide a cluestick to the people behind msdn blog feeds. To see a large number of people who are unclear on the concept, read the comment stream from Scoble's post

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.

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.

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.

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

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.

Well, I'm at Camp Smalltalk today. I'm mostly just enjoying the atmosphere - I'm not really participating in any of the projects (like GLORP). Instead, I'm getting the Twoflower browser component in BottomFeeder replaced with WithStyle. I've made progress this morning - I've got basic display working. That allows me to move on to two related areas:

• Menus. I need to get the menus that currently pop up in the Tf pane to also pop up (and work) in the WS pane.
• HTML adjustments. With Tf, I was doing a fair bit of pre-processing, as there were various image display issues. I've cut all of that out (leaving the API present), as WS does a much, much better job.

I also seem to have some lingering issues with the new NetResources code to deal with - but there's definite progress. Stay tuned for a better Bf!

I've been making steady progress on getting BottomFeeder to use WithStyle. It was kind of odd to be working on this at Camp Smalltalk today; the rest of the people in the room were pairing directly - I was getting pointers in the IRC channel from Michael. It wasn't pairing, exactly - but it got me over a few humps. I've made some more progress during my train trip - I had to leave early, as I'm flying out of Frankfurt tomorrow just before noon. It's a 4 hour train trip from Koethen to Frankfurt - so I've had plenty of time. It's been a good trip, but I'll be glad to get home again.

Jeremy Allaire asks an interesting question - when will Microsoft get commoditized?

I've been spending considerable time looking at the economics of software manufacturing and distribution in the face of open source and offshore software development, and it strikes me that in the near future Microsoft will clearly face an erosion of their core software margin business as a result of the commoditizing economics of clone software manufactured in China at 1/100th (or less) the cost of manufacturing the software in Redmond. 

Well, there are some differences between hardware and software. With hardware, anyone can clone once the specs are available. Software just isn't like that. For one thing, "the specs" are usually very loose (say I want to clone Word. Where are the specs?). Look at ongoing efforts like OpenOffice, for instance - it sucks, and in most of the same ways that Word sucks. Network effects play a role here as well - for shops that have built a lot of behavior on top of Word, Excel, Outlook (etc) - "close" just doesn't cut it.

So yeah, the Chinese (or Indian, or whatever) developers are loads cheaper than the old hands up in Redmond - but they can't easily replace something like the Office Suite. There's another problem as well. At present, the overseas shops don't seem to be doing anything that would make them more productive - which is how Japanese and German manufacturers made hay back in the 60s and 70s. Sure, someone will bring up CMM at this point.... and I'm sorry, but a shop that makes a fetish out of huge stacks of mandatory metrics in endless reporting streams may be a lot of things, but more productive isn't one of them.

Now, maybe if some of these enterprising overseas shops took note of dynamic languages and XP, they might get a critical leg up on the local guys. But no, so far it's the same exact curly brace languages and the massive overhead of CMM. Until that changes, I don't think MS has a whole heck of lot to worry about from that direction.

ESUG was a good experience - like a small scale version of Smalltalk Solutions. There weren't that many people from the US or Canada - Smalltalk Solutions usually has more people from Europe attending. It's also a smaller, more intimate show - for most of the conference, there was only one track - which meant that I never had to try and figure out which of 2 (or 3) interesting talks to attend.

Probably the only bad thing was the lack of air conditioning in the main conference room. We had to close the Windows during talks in order to banish street noise - and with 100+ people all packed in the room, it got warm fast. Beyond that, it was quite nice - kudos to Stephanne Ducasse and the rest of the ESUG organizers for doing all the hard work necessary in order to bring this off.

Now the irony part - the conference was in Koethen, which is in the eastern portion of Germany (what used to be the GDR). You can still see signs of that era - lots of rundown/abandoned buildings, and a general feeling that "everyone" has up and left. The hotel was small, but pleasant - and I was able (after some experimentation) to get dialup internet access. We had good WiFi at the conference facilities, so it all worked out pretty well. Then I traveled back to Frankfurt (Main) for my flight home. I had a hotel in the city, which was nice enough - and as expensive for one night as the one in Koethen had been for three. No internet access. They claimed to have DSL, which didn't work. They also had WiFi, but no one I spoke to had any idea what a WEP key was. Dialup didn't work, since the phone system was digital. Heck, to make a call home I had to wait on hold for the MCI operator to pick up, since the phone wasn't processing any keypad input. So much for modernity - I had an easier time of it in Koethen.

That aside, it was a good trip. I would have liked staying for another day of Camp Smalltalk, but I didn't want to be away from home that long. I'll be back in Frankfurt in December, for a Cincom Smalltalk customer meeting - we are putting on a 2 1/2 day conference for people using the product. We are charging for the show - I'll have more information on that as it becomes available.

It's a long flight from Frankfurt to Pittsburgh - I wasn't really up for a non-stop BottomFeeder hacking session. I bought the USAirways headphones for this trip, and it was actually worth it. After a few hours of hacking Twoflower out and WithStyle in, I was ready for a break. I paged through the list of movies - I had already seen "Shrek 2". Sure, it was good, but worth a second viewing? Not really. Then I noticed "Miracle" - the story of the 1980 US Olympic Hockey team

Now, I've seen this movie before - my wife bought it for me last year. It was a tremendous film the first time through, so I decided to watch it again. It was every bit as fabulous the second time through. I remember those Olympics - it was my senior year of high school. I don't know if I watched the first few games - I've never really been a big hockey fan. I do remember that I started paying attention once they beat the Czech team, and watched the rest of the way through.

The movie captures so many things correctly It starts with a bunch of news clips (very short - just a few seconds of each) from the 70's - the fall of Saigon, Watergate, Carter's election, gas lines, the hostage crisis, the Soviet invasion of Afghanistan. It had been a decade of doubt for Americans, and the start of the movie really captured that - and it set up the hockey team as what they became by the time of the game against the Soviets - a single point of unity for the country. Ironically, that game was not the gold medal game - that was against the Finns afterwards. Things are different now - there's the internet, hundreds of cable tv channels, and the Soviets are long gone - but at the time, it really felt like the whole country came together to watch those guys play - and win - against the Soviets.

There are so many places in the movie that just make you live through that team's preparation and win. I can't recall another movie that captures the time and the time's essence so well in the context of its subject. I'm sure that I'll end up watching it many, many more times. If you don't have the movie - run out now and get it. You'll be glad you did.

Ryan Lowe asks why syndication formats like RSS and Atom don't support feed deltas by default. This is all in reference to the MSDN master feed cluster you know what. I've thought about this some since the last time I posted on it; I've come to a simple conclusion:

A master feed covering 1300 blogs is a truly stupid idea

It's too big, tries to cover too much... etc. This isn't a technical problem - it's a marketing problem. In other words, it's exactly the sort of problem that Scoble should already know how to solve - if there are feeds which are logically related, then there's value in clustering them. Otherwise, there's not. This is a sorting out issue; someone at MSDN needs to build smaller buckets...

Yes, within a paragraph Jonathan Schwartz again shows that he has no business managing mice, much less humans:

I'm watching with amusement as IBM prepares to stub its toe with their new, curiously named "OpenPower" low-end boxes.

Now, I will freely admit I am entirely confused by what they're doing. Why on earth would you ship a proprietary computer that doesn't run your own operating system (AIX)? If I were trying to freak out my installed base, that's exactly what I'd do.

Hmmm - possibly because they recognize something Schwartz never will - the smell of money. He's confused on something very simple - IBM is happy to make money on hardware they can mark up while keeping the overall costs low by using an OS they don't have to maintain themselves. Sun has yet to figure this out; they still think that people might care about Solaris on intel. Yeah, all the people who care live over here

As to the rest of his article singing the praises of the massively parallel Sparc - sure, it's a cool piece of technology. I'd say he ought to look at the size of the market for those kinds of systems - for every one prospect who both needs (and can afford) such a system, there are scads more who will just buy commodity intel boxes and slap them in racks. Heck, he could ask the Cray guys...

On the very day that I reacquired silver preferred status on USAirways, they file for bankruptcy again. I sure hope my pile of miles end up somewhere useful....