Smalltalk Tidbits, Industry Rants

Today's highlight: Maurice Rabb's micro-smalltalk talk:

Microlingua, a Tiny Real-Time Smalltalk Maurice Rabb: Stono Technologies LLC Monday 4:00:00 pm to 5:30:00 pm

Abstract: Dynamic object-oriented programming languages are rarely used in small or real-time embedded systems. This presentation will discuss implementation techniques originally developed to enable Smalltalk to run efficiently on tiny consumer electronic products such as animated watches. The work has application in other domains including wireless, medical, industrial, and military equipment.

Topics will include developments since Smalltalk Solutions 2002, as well as issues around real-time garbage collection, scaleable object models, fast ROMable message dispatch and resolution, fast and consistent numerics, handling immutability, and consistent and easy concurrency. One of the speaker's goals is to enable Smalltalk to run on new cellphones. Wireless handsets represent a new frontier in computing, and possibly an enormous new marketplace for Smalltalk.

Bio: Maurice Rabb is the Director of Special Projects at Blackwell Consulting Services in Chicago. He specializes in new product development, design patterns, object mentoring, and conceptual blockbusting. Mr. Rabb is co-founder of Stono Technologies LLC, a firm dedicated to the development of new technologies for the consumer electronics industry. Mr. Rabb is a Squeaker, and earned his BS and MS in engineering from Stanford University.

This sounds like a great talk, showing that Smalltalk's range is wide.

Two Harry Potter books, that is. I stayed up way, way too late reading last night, and was able to slip in a few more pages this morning while my daughter was cleaning her room - but now she's got the book back, and it'll likely be her bedtime before I get another crack at it. Of course, I couldn't buy a second book; the stores were all sold out except for reserved copies very quickly. And by the time they get new copies in, I'll have read the whole thing anyway.

This book is darker than the first four - I suspect that when they get around to making it into a movie, it will be difficult to keep the mood up. It's a page turner - and written to a higher level than the earlier books (the author is obviously trying to stay with the first generation of readers). I'm sure people will be reading the book for a long time, so I'm not going to let slip any spoilers - and I'm only half way in at this point anyway. Thus far, I'm very pleased with the book - Rowling's done a great job.

Via Ted Leung comes a fascinating snapshot of XML development.

Via Sean McGrath:

At Applied XML, there's a talk entitled SOAP, it wasn't Simple, we didn't Access Objects and its not really a Protocol. That sounds like an interesting experience report...

Today's highlight: Dave Buck's VWUnit talk:

VWUnit - An Open Source Framework for Unit Testing VisualWorks GUIs David Buck: Simberon Tuesday 8:30:00 am to 9:15:00 am

Abstract: VWUnit is a testing framework for VisualWorks Smalltalk - it is built on top of the standard SUnit framework, and handles fully automated testing of VisualWorks GUIs. VWUnit is open source.

David Buck started using Smalltalk in 1984 and has been doing Smalltalk consulting work since 1994 under Simberon Incorporated. Known for his ray-tracing program DKBTrace and its derivative POV-Ray, David is also known as the key developer of the ElastoLab physics simulator for kids.

Last night, I decided to stop at Barnes and Noble on my way home from a gaming session. I got there are 12:30 - only half an hour after they started selling the new Harry Potter book. It was completely packed - a huge line at the registers, a huge line at the cafe - and the employees calling people up to pay by ticket number. They had sold out of un-reserved copies, and were calling people up who had pre-reserved - and all this, only 30 minutes in! I asked some staff about it, and they said that they wouldn't have more copies for about a week. Someone in ordering didn't do their homework :)

So I headed to the mall this morning - my daughter had entered a contest awhile back, and entry pre-reserved a copy of the book. They were opening at 7, and I'm never up that early. I rolled in about 11:30 - the lines were long gone, but so were unreserved copies - thank goodness we had one reserved! It's massive too - 870 pages. I hope Rowling isn't startting to develop Heinlein disease... Not only the bookstores either - I had to stop at Giant for a few things, and they had been selling the book - it was sold out in 90 minutes, according the checkers. Looks to me like no one ordered enough copies of this book.

The public store access application has been broken for a few days, and it was a matter of sloppy testing on my part when I upgraded the app server from VW 7 to VW 7.1. In VW 7, the VisualWave namespace was imported into the Smalltalk namespace; in 7.1, that's no longer the case. The Postgres app is an old wave application, and a couple of methods - in particular, a method that was needed just to open the web page - could no longer "see" a class that was referenced.

That's fixed now, and things are back in business. I apologize for the inconvenience.

The local Borders will be open until 1 AM to sell the new Harry Potter book. Since I'm off to play boardgames this evening, and my daughter is coming along, what do you think my chances are for coming home without the book?

Today's spotlight goes to Terry Raymond's talk on the Multi-Process uI in VW 7.1

The Multi-Process UI in VW 7.1 Terry Raymond, Crafted Smalltalk Monday 2:00:00 pm to 2:45:00 pm

Abstract: I will be discussing; the reasons for modifying VisualWorks to use multiple user interface processes instead of a single process, the design concepts embodied in the MPUI changes, and what the changes mean for various types of applications.

Bio: Terry Raymond is the author of the Smalltalk Professional Debug Package. He spent four years working on the development of a Manufacturing Execution System which encompases, managing a manufacturing plant model, scheduling tasks, executing the tasks in real time, and user interfaces that monitor the tasks. He has over 13 years experience with Smalltalk, going back to ObjectWorks Smalltalk 2.5 and several years experience in the development of real-time systems.

Terry created a lot of this support, for which the Cincom Smalltalk team is extremely grateful. Go register so you can hear what's new on this!

I posted on Dan Antion's talk yesterday - now today, I see that he's running a panel at StS:

I am moderating a panel discussion on remote development at Smalltalk Solutions in July. The discussion will focus on things that make remote development work, things that prevent it from working as well as it should and things that we need to make it work better.

For the purposes of this panel, remote development can be a team of distant programmers adding to a collective work, a single developer handling small portions (or large portions) of a company's development or two people in the same office who do not share an image. The goal is to learn from those doing it, how to work better when we work from a distance. The work can be commercial products, in-house development, tools or enhancements to development environments. I would like to focus on joint development, not simply development of a stand-alone end product for delivery to a remote client.

VAST and Dolphin have representation on the panel, but I would like to include the other dialects too. If you are planning to attend Smalltalk Solutions, fit the (fairly broad) profile described above and would like to share your experiences (good and/or bad), please send me an email.

Thanks, and see you in Toronto Dan

Someone from Cincom will be there!

There was a post the other day in cls looking for people interested in building a "next generation" development environment for Java. The post contrasted what Eclipse does vs. what they want to do. They point you here for a listing of points to consider. Seems to me that these guys were inspired by Smalltalk and/or Lisp tools in their desire to create a Java environment. It will be interesting to see whether they get anywhere - I rather suspect that any serious work down that path will result in re-building a significant portion of Smalltalk or Lisp along the way.

Tim Bray has some good thoughts - both on the potential uses of RSS, and on the roadblocks it faces in a business situation

Then get ahold of Simberon:

In speaking with several of my consulting clients, I've been seeing that various companies with Smalltalk projects are having trouble getting Smalltalk training for their developers. With the acquisition of The Object People by BEA, there is one less company offering Smalltalk training.

As a former Object People instructor, and in order to address this void and to promote Smalltalk development, Simberon is developing a series of training courses that can be offered on-site (at the customer's premisis) or as open courses (offered at Simberon's offices).

For information on Simberon's courses, please visit http://www.simberon.com/Services/training.htm

We would like to hear from you about your training requirements. Please take a few minutes to fill in our training survey http://www.simberon.com/Services/survey.htm

I'd also like to hear your thoughts, comments, questions, etc. Please contact me by e-mail at david@simberon.com.

Thanks

David Buck Simberon Inc. www.simberon.com

Dave's a great guy who really knows his stuff - highly recommended.

Like my notes from the Websphere and Struts talk, this is going to be a stream of consciousness sort of thing...

Steve Ornburn of GBC, David Kane of SRA speaking.

The Problem - CMM is being mandated by a lot of the government - especially defense - organizations. At the same time, there's a lot of interest in XP/Agile, especially at the grass roots level. The theory - the two are in conflict. Are they?

The answer - there are real differences, both in the approaches and in the philosophies. There are ways to meld, but they are high risk.

Right off, I notice an interesting bias - CMM is called "High Maturity", as opposed to Agile. Interesting.

Issues

• Is AD a mature process?
• Can AD fit into a high maturity shop?
• Is it worth it?

There's a map of the meta-model of software life-cycle. Highly oriented towards CMM, which makes mapping Agile to it problematic, IMHO. Now we have some definitions - Spiral development is defined as a Risk driven development model. Others are Waterfall, Iterative, Evolutionary. Requirements driven, Architecture driven. The point being made - different projects require different models based on the risks.

Agile maintains a balance between a requirements driven and an architecture driven approach. So the question here is, for what risk profile is Agile appropriate?

Safety Critical - Managed change and requirements, so the environment is stable. Their example - the Space Shuttle. Bad, bad example IMHO. I think the shuttle was more of a budget driven project with overblown process layredon, so the whole thing went badly. In any case, I'm not sure I'd use it as an example of a place that is appropriate for CMM.

Not safety critical, but unpredictable change - appropriate for Agile. Again, IMHO, this sets up a straw man that Agile is unsafe. I don't think that's fair, and I think that the overall failure rate in the software business - including in the safety critical side - is not encouraging.

This actually engendered a huge conversation - I think a lot of people here are incomfortable with the straw man being presented. For instance, one of the speakers from the last time I came here brought up the fabled 350,000 lines of code from the original Space Shuttle project - 5 years, virtually no defects. Well. Note how slowly the space program has moved - compared, say, to the early aerospace efforts - which were very much agile efforts.

In contrasting with Agile, this talk is going to focus on XP and the Agile Manifesto.

The CMMI -

• Meets the needs of software organizations
• Is as upgrade to the sW-CMM
• Benefits from best practices contributed from all three source models (the older ones0

CMMI is best described here. Ranges from Level 1 (Chaos) to Level 5 (Optimizing, Continuous Improvement). So, the question - can XP/Agile methods be mapped to CMM continuous improvement standards? IMHO, a lot of this was covered by Scott Ambler in his XP Brazil talk - it's all about what you pack vs. what you actually need (overhead).

Requirements and Software planning map pretty well from Agile to CMM. For instance, stories capture requirements, customer interaction deals with ongoing planning. etc. What they say Agile misses is doing organizational change - because, in their opinion, Agile (especially XP) is more focused at the raw development level - not at the corporate level.

CMM really wants a definable process, so that said process can be evaluated. Given things like emergent requirements (etc), can a CMM definable process be defined from XP? CMM had notions that process is akin to manufacturing - it can be defined and refined, somewhat like an assembly line. This isn't how Agile looks at this. CMM has moved somewhat away from this view. So based on all this, the claim is that one can map the XP processes to CMM level 3 pretty easily.

"Fixing" XP - Agile omits process ordering; this can be addressed. Comment from the crowd - CMM is largely mandated from above, in order to get the "good housekeeping seal of approval". The engineers often don't buy into this, and it all becomes worthless. The way to make this mapping work is not to get overly detailed. CMM is partly about artifacts (reproducability), while Agile isn't. Another example - XP teams use whiteboards and other ephemeral documents - CMMI wants documentation and artifacts. This will have to be addressed carefully in order to make a CMM assessor happy.

Lots of things are not dealt with at all by Agile - subcontract management, Technology Change Management, Process Change Management, etc. IMHO, that's because these are not practices day to day developers need to worry about. Ultimately, CMMI is aiming at a broader scope than XP/Agile. IMHO, CMMI is aimed up at the CIO level, not at the project/project manager level.

A Level 5 Shop Improvements are selected based on quantitative measurements. How do you get that? It could easily be via Agile methods. What if the shop is less than level five? Be prepared for resistance and turf battles (for instance, architects and QA folks, for whom there is no defined role in XP). If that's not resolved, you get politics - which destroys projects quickly.

Next question - is the attempt worth it? Is Agile succeeding through a self selecting, superior developer crowd? Is it just that better programmers succeed, almost without regard to the practices?

Agile - focused on small to medium sized projects, assume a high level of customer trust CMMI - Frequently applied to large, complex projects, often require detailed conceptuial models before cutting code, often used as part of a formal acquisition process

Ultimately, I think one of the big issues with trying to relate software to real engineering is best practices - construction (for instance) has a suite of best practices. In software, we don't really have an agreed upon set of best practices. We are still arguing over what they are.

I'm taking notes on the Agile/CMM - can they be used together? talk at WOAD. I'll have a full set of notes online later this evening. Interesting stuff, great questions from the audience.

In a Register interview, Nokia VP Erik Anderson cut loose - here's the best line from the whole thing:

No one is eating the regulators, and they spread like rabbits. A Ronald Reagan only comes along every fifty years or so. The trouble is no one is eating the lawyers.

Heh - No one is eating the lawyers. Now there's a solution :)

Zope author Jim Fulton talks about Python and Zope, and gives Smalltalk a mention:

EuroPython: You've used Smalltalk extensively. When did you move to Python and why?

I started using Python in '94. This wasn't really a move from Smalltalk. I needed an object-oriented interpreter that I could use for some scientific data processing applications at the U.S. Geological Survey.

I got heavily into Python and didn't really (and still don't) have time for Smalltalk any more. This is a shame, because there's lots of intereting Smalltalk work going on.

EuroPython: Why did you decided to use Python when developing Bobobase, Aquaduct, ... and at the end of that road, Zope?

The alternative at the time was Java. Python is superior.

(I didn't consider perl, for obvious reasons. At the time, there wasn't a readily accessable Smalltalk implementation.)

One of the many reasons that I think dynamic languages are the future, and things like Java and C# are transitional. There's more of interest in that interview; go read the whole thing

I am going to pick out a different presentation or tutorial from the upcoming Smalltalk Solutions show to highlight for the next few weeks. Today, let's look at Dan Antion's talk. One of the things I hear a lot is that it's too hard to find Smalltalkers. Well, look no further than this talk; Dan addresses that!

The problem for us was finding good fulltime developers willing to work in a small shop with a limited career path. We opted to go with people who want to work in this field, but don't want to follow the traditional path. The demo in this case, is a presentation of methods and experience. Object-oriented programming (Smalltalk) poses unique obstacles to training novice programmers. Training at the high school level is sharply procedural and must be overcome. Many of the "easy" projects have already been completed and added to the class library, so carving out initial meaningful projects is a challenge.

Our success, measured by quantity and quality of products produced vs. costs and the career success of the students, indicates this approach is viable. The approach is best described as an "artisan-apprentice" relationship. Traditional formal training assumes an understanding of the business environment that doesn't exist, and self-study often leads to adoption of bad practices. In addition, we are actively working with a local high school, though their School-to-Career program, to improve career guidance and the math and computer science curriculum.

Now, Dan's discussing high school kids and grads - but the same applies to college kids. Penn State has had great success training people in much the same fashion. So if you think getting Smalltalkers is hard, come to Toronto and hear Dan out!

CNet reports on IM and archiving:

Instant messages should be treated the same as e-mail messages and archived for three years, the Nasdaq Stock Market regulator told its members.

Companies are being advised to keep archives of all their IM communications for at least three years. The National Association of Securities Dealers (NASD), the U.S. regulator of the Nasdaq and securities market, told its members to treat instant messages the same way they treat e-mail in response to the growing use of the technology in large companies--particularly in financial houses.

Interesting. That will likely drive many shops to pick up "enterprise" IM applications. That raises a problem though - I use AIM because lots of other people use it - i.e., the network effect. I don't communicate only with people within my company either. Not to mention that I work from a home office, not from a central office. While I'm not in the finance sector, lots of firms now archive email in case of lawsuits, and IM conversations will likely fall under the same sway. But - there are simply too many channels to capture - multiple email accounts, multiple IM systems, IRC, blog posts, comments left on other people's blogs, USENET - there's simply no way to capture it all. I don't know what the lawyers would say about that, but it's just hopeless....

Danny Ayers points out an interesting fact about Advanced Search - no one uses it:

Tim Bray comments on search engine usage patterns, noting that Nobody Uses Advanced Search (except search professionals) and that few people look at more than One Page of Results. Could there be a simple explanation to these patterns? i.e. nobody can be bothered to click to another page. Tim remarks on how search engines no longer limit their first page to 10 hits, so in effect subsequent pages have been brought forward. Well what if the advanced controls (remodelled to be as friendly as possible) were on the main search page?

A refactored advanced search may not get used all the time, more than a few percent, but I bet you'd get a lot more users than the current half-dozen CIA librarians.

This plays into something else I've had on my mind recently - the concept of a "beginners" interface and an "advanced" interface. This implies that the better idea is to make the "advanced" interface as easy to get into as possible - since a significant part of your audience will never leave the default view. How far does this extend? I'd be interested to know how many non-geeks use things like skins. Also, how many Windows boxes stay with the out of the box color scheme and font selection? I suspect rather a lot.

I posted on a thread in cls here. That thread kept going, and generated the following:

I said: No, ParcPlace did most of the damage to Smalltalk. Java was conveniently available while the most well known Smalltalk vendor of the time killed itself.

and Andy Bower responded:

I don't think this is really true. The "self destruct" attitude of ParcPlace had a lot to do with the driving existing Smalltalk users away from the language (mostly to Java) but I fear it had little to do with Smalltalk's ability to attract new users. In my experience, Java was hyped by Sun to do most of the stuff that Smalltalk did, but in a form that was more readily accessible to traditional C, C++ programmers. And I do mean "hyped" since, for a long time, Java was not ready for prime time.

As an example, when we were building Dolphin Smalltalk for a UK company (Intuitive Systems) back in 1995 the customers of that company got wind of Java and asked why we weren't intending to use this new hot stuff Internet language. They (the customers) effectively railroaded the use of Java for new projects and the Dolphin development was shelved. Subsequently, Object Arts acquired rights to Dolphin in 1997 and has continued its development since then. It is interesting, however, to note that the Java development that Intuitive began in 1996 was eventually cancelled after 18 months (and a huge number of developer-years) because in those days Java was not ready for the creation of large scale projects. Intuitive then effectively became a VB and C++ shop!!

So, yes, in our case Java did eat Smalltalk's lunch. The really irritating thing is it couldn't keep it down and ended up barfing it all over the sidewalk.

Best Regards,

Andy Bower Object Arts Ltd.

Andy does have a way with words!

I heard this on the IRC Channel today

[Steve] Jobs has a reality distortion field that warps space around him, our management has a reality disruption field that keeps reality from entering their awareness

I read with interes Mark's comments here:

Java rules the server side. While some Smalltalk environments like VisualWorks have absolutely awesome web services support, the quality of free Java server side tools like Jakarta Tomcat, JBoss, Enhydra application server (not to mention many good, but expensive commercial products) make Java's use on the server a no-brainer. As per item 2, if you design and implement a Java based web application, don't you want to feel confident that your customer can find people to modify and maintain it?

By this argument, no one should have adopted Java in 1995, or 1996, or 1997 for that matter. Likewise, we should just give up advocating what we truly believe to be better solutions to problems, and just "get with the program". I'll note in passing that Mark posted heavily on politics a few months back - would he advise the same course of action with respect to that field? If not, why not?

What Mark's argument boils down to is "everyone does it, get with the program". I seem to recall my mother having words with me on that subject, a long, long time ago :)

Forrester Research thinks the Oracle deal will go through.

Sun is lending verbal support to SCO - check out what Jonathan Schwartz is saying about the mess:

"IBM has been using Linus [Torvalds] like a tool and exploiting the open-source community." Those fightin' words come from Jonathan Schwartz, executive vice president for Sun's software group. He doesn't think IBM's Linux sales have been kind to CIOs, either. "They've been spreading IP [intellectual property] radiation" to companies that get their Linux from IBM because of Big Blue's contract problems with SCO Group. Sun, he hastened to add, has crossed all its t's and dotted all its i's with SCO just in case the Unix/Linux legal claims have merit

Meanwhile, ComputerWorld reports that wags at the JavaOne show were saying that IBM needed to buy Sun in order to save Java. Sun counters that with all the money they have in the bank, it's a non-issue. I seem to recall that ParcPlace had plenty of money circa 1996. Somehow, it wasn't enough to make it through 1999. Sun has more cash on hand - but they have a bigger run rate as well. Time will tell.

Smalltalk Solutions registrations are coming in, and we are looking to have a great show - just take a look at the presentations schedule and the Tutorials schedule. We have well over 100 people coming to the show now - don't miss out! Register now!

The NYC Smalltalk Group has announced their upcoming schedule of events -

We have the following events scheduled:

When	What
June 2003	Not meeting, postponed to early July
July 9, 2003	Using PostgreSQL from Smalltalk - Bruce Badger, Openskills
August 2003	Summer break , as is our custom
September 17, 2003	Part 1 - Reuse through Totally Objects Frameworks David Pennington, Totally Objects - The Smalltalk Resource
	Part II - Round Trip Objects - an Emergency Claims system experience report Dan Antion, American Nuclear Insurers, West Hartford CT

Check it out if you are in NYC!

Interesting post from Ara at Memory Dump:

Many OS projects just don't look clean and shrink wrapped. Working with many of them is like doing a open heart surgery! That was exactly the feeling I had when I ran JBoss for the first time with all those endless logs it spits!

I think the reason for this problem is that OS attracts geeks/elites only, but you can't create a successful product by just employing elites or charismatic frontiers. You need a mix of challenge and deep thought, plus some get-it-done kind of guys that view the thing from client's perspective and try to soften the hard edges of the product. With geeks you have some guys who can just draw amazingly beautiful sketches, but it's not a painting. With only get-it-done guys you just have some beautiful colors on the board, but it's not a painting either. Only a combination of both parties can create a beautiful Van Gogh painting :-)

That's probably true for an awful lot of the OS projects out there, and I'm not sure that there's a decent answer to the problem.

So far, SCO's increasingly threatening noises don't seem to be fazing anyone:

So far, however, AIX users seem completely indifferent to all of this legal wrangling. In a quick survey of half-a-dozen AIX system administrators working in businesses, none of them expressed the least concern about McBride declaring that they no longer had the right to use AIX. In AIX circles, at least, SCO's actions continue to be seen as idle threats.

So, is this just blowing by?

A tip from Anthony Lander led to this interesting Inquirer story on the whole SCO mess. It's entirely possible that most - maybe all - of the matching code originates from BSD:

"Now, it seems to be quite likely that the matching Linux-System V code shown to the "experts" by SCO came from one of these files. And all because this is the original BSD code, which got copied everywhere."

This isn't a new theory. Ever since SCO first filed its lawsuit against IBM there has been speculation that they're basing that on old BSD code that was added to both AT&T System V Unix and many other Unix versions. But what's different here is that a process is proposed to identify all such common BSD code, eliminate it, and perhaps do some other things.

interesting, and entirely plausible.

The Register has some issues with XML. Mostly, it boils down to efficiency over the wire:

But according to some, it's not wonderful at all. XML and its close relatives Web Services come with three major problems: fat, bandwidth-eating formats, poor security, and high server loads.

All these issues are addressable, but don't fool yourself. XML may easy to write, but it could prove hard, very hard, to deploy successfully.

Many industry figures, like Steve Vinoski, Iona's chief architect and vice president of platform technologies, are worried about Web services performance. The main reason is that XML, unlike less popular, older binary-based interoperability standards like CORBA's Internet Inter-ORB Protocol (IIOP) and Microsoft's Distributed Component Object Model DCOM), is text-based, which means that data transmitted in XML format is bulky.

How much bulkier than binary? Schmelzer says XML formatting can fatten up a file by as much as 10 to 20 times. That's a lot of bytes to transfer even at Gigabit Ethernet speeds

Yes, Iona has a bone to pick as a CORBA vendor. Doesn't mean their wrong though. They also point out that compression is only a partial answer, since the compressed data will be converted to Base64 at a 30% volume markup. Then there's security, for which the only current answer is SSL.

Actually, the more I think about this, the more I agree with this post from a few days ago. Web Services is treading the same path, with most of the same big issues, as CORBA did.

Loosely Coupled has a post on how to fix Sun - I'm not sure I agree with his take:

As a systems manufacturer, Sun has one huge advantage over its main competitors IBM and HP, who are saddled with huge professional services organizations (IBM in particular). With spending on IT services plunging through the floor, those overheads are going to look more and more of a liability in the coming months. That in turn will make customers wary of being sold propositions that are designed to maximise services revenues, thus driving business into the arms of rivals who don't have such a huge consulting burden to bear.

I'm not sure I'd call it saddled with a consulting group. Both of those outfits have been building up their world-wide consulting staffs, and getting a fair bit of their revenue from them. But the next paragraph makes no sense to me:

Sun could do well out of promoting itself as the champion of lean, low-maintenance, consulting-lite computing platforms. The fact that its underlying hardware is actually proprietary is neither here nor there. As IDC analyst Dan Kusnetzky recently explained, it won't even matter what operating system people are running: "Widespread virtual-environment adoption will speed the current trend toward OS commoditization and decrease OS importance in IT infrastructures, he said," reports searchEnterpriseLinux.com. "IDC is certain that businesses will move to on-demand and virtual computing," and neither operating systems nor the flavor of the underlying hardware will matter any more, provided they do their job well enough.

How does commoditization of hardware and the OS help Sun? They have a high end OS and expensive boxes; the industry trends work against them, not for them. The Java group only makes it worse - it's a big boat anchor, likely costing more than it brings in, and promotes the following message: the hardware and OS are irrelevant. This is the very last message Sun should have been promoting over the last few years. Then the suggestion comes that Sun should buy Dell. Why? So that Dell's low cost operations could become high cost? Sun has less than no experience at the low end; they wouldn't have the slightest idea of how to deal with Dell. And I seriously doubt that Dell would want to be bought by Sun anyway. I just don't follow this post at all.

Next up is a talk on Struts. This is being given by Peter Campbell of Java Enterprise Solutions. He's going to explain Struts from a "what is it" standpoint, which is of great interest to me. VisualWorks now has the Web Toolkit, which is equivalent to ASP/JSP/Servlets. Is Struts something of interest?

Struts is a control layer based on Servlets, EJB, Resource Bundles, XML, and Jakarta Commons. Struts is a variant of MVC for web apps. Uses Servlets and JSP. It's an app framework that you build web apps on top of. Struts is basically the Controller - it relies on other things for the Model and the View. More or less, it wraps the Request and Response objects, and handles communication between the back end (Model) and the Request/Response.

For the model, Struts can talk to EJB, JDBC, some O/R layers. For the view, it's typically JSP (Could be XML, etc). From the front (HTML) end, the struts interface appears as a tag. So the HTML guys will be able to work with it fairly easily. The heart of this appears to be the configuration file, which is an xml file specifying the association of page actions to domain model actions. It specifies allowable page transitions. It does not do transactions; that's presumed to all happen at the model layer. The actual controller is some subclass of ActionServlet, which specifies what we are going to do, and via the configuration file, delegates actual actions (Command Pattern) to the model. The biggest hurdle is trying to share the configuration file - the latest version of struts allows for sub-config files. Another possible limitation - one cannot chain actions in the config file - you specify an entry point.

The model is your application. In this world, it's generally a set of one or more Java Beans. This doesn't imply all EJB's (and in fact, this speaker is arning people off of that). Heh. There's an admission that when you do this, you don't want to allocate objects too quickly, because the JVM won't easily keep up.

I'll say this - the tags you put on the page to deal with data transfer from form to application look really nice. I'm sure this simplifies the front end construction of forms a lot for the HTML guys. Not that it's difficult to do that transition in Smalltalk; here's how I typically grab form data in a VW servlet:

model := BlogUser new.
model getInputFrom: request parameters.

getInputFrom: aDictionary

	aDictionary keysAndValuesDo: [[:key :value |
			self setAspectFor: key to: value].

setAspectFor: key to: value

	| selector |
	selector := (key, ':') asSymbol.
	(self respondsTo: selector) ifTrue: [[
		self perform: selector with: value first].

However, having a standard set of tags for the HTML guys is not to be underestimated. Using JSP 1.1 standard tag libraries and these mappings is likely to allow for very quick mock ups and front end implementations. The way this is set up, it looks like the web toolkit should be able to support struts, given the appropriate back end framework - since we already support JSP style tags and servlets. So what we would need is an equivalent to the ActionServlet and the associated library. The hard part looks to be in the creattion of the XML file - you get examples, and have to customize. Presumably, you use some xml editor to do that.

You create

• An ActionForm class to mediate between view and controller
• Action classes for each logical request
• ActionMapping (in XML) for each logical request that needs mapping

In the Action class, you implement an execute method. This is where things flare off from. Hmm. What would be fascinating would be a conversation between someone advocating a Struts type approach versus someone advocating a Seaside based approach. Anyway, Struts is pretty small - about 100 classes. I guess we should have a look at this approach.

So here am in northern Baltimore at at a WebSphere seminar hosted by a local company, Noospherics. I actually know the speaker - George Kosmides - from way back. He was a Smalltalk guy back in the day, and is now working with Java. My presence here has already done some good - he's identified Smalltalk as the source of many ofthe ideas behind Java. This is going to be a stream of consciousness kind of report.

Now he's relating J2EE as a natural progression up from JSP and Servlets - i.e., something to simplify and scale the back end. The explanation offered is that the business model belongs in the EJB layer. Side note; I've heard this presentation. Heck, back in 1997 I was giving this presentation as D-Wave (Distributed VisualWave). There's truly nothing new under the sun; we just keep re-inventing the same wheels....

Hmm. Now we have some JDBC, and the fact that we can easily plugin any back end database. Well. One, that depends on the SQL being used. Two, what about O/R mapping? I'm not sure the explanation of JSP as a "refinement" of servlets is a good one; more of a complementary item, I think. Also no warning about the possible unmitigated growth of code on pages being a bad thing - something I learned the hard way in the implementation of this blog...

Now onto JTA - the transaction mapping piece. No mention that the vendors tend to value add this into proprietary heck.... JMS as a mapping on top of messaging services like MQ. Kind of amazing to me just how many of these things Sun has implemented. JMS actually sounds useful - having a standard messaging mapping for Smalltalk would be highly useful.

Now that we have the buzzwords out of the way, he's moving up to the architecture level. Heh. The supposed existence of XML standards between suppliers and vendors. I've got customers who live in the middle of the supply chain; they tell me that more than half the work is writing adaptors between systems, as standards are followed mostly in the breech. Ho ho - J2EE makes it easier to build a standard application architecture. Never mind the analyst reported high failure rates in this - which, I think, is more related to the attempt to build "the one true architecture" than to anything else. I think he over simplifies the "auto-scaling" of J2EE applications. Sure, if the application was written properly. Scaling is almost never a matter of "just" adding a server to the mix.

On to process. I don't take it as a great sign that RUP was on the last slide, and UML is on this one. Sounds heavyweight to me. Here we go - one must do modeling first (and I don't think this sounds like Scott Ambler's agile modeling). Here we have a big emphasis on UML and a process (RUP). We are about to cover the most commonly used diagrams in the UML. I've seen this before - a subset of the developers get so enticed by the diagramming that they never come back out..... So what are the most commonly used?

• Use Case Models
• Class Diagrams
• Sequence Diagrams
• State Diagrams

One of the things I disagree with here is that a design really can't be done withut regard to the implementation. You'll make different choices based on deployment platform (OS), network connectivity, language, database, etc. At the highest level, you can be abstract. Once you start getting to the level of specificity detailed in UML (down to class and sequence diagrams), it makes a difference.

Interesting. As the straw man for analysis and design, he's presenting waterfall as the alternative to be avoided. I'm sure there are still waterfall projects; but is anyone still advocating it? Ok, this sounds better - he's emphasizing testing and spiral development. On the other hand, RUP is what he's sayiing "we've all moved towards in the last five years". That was true from a mindshare standpoint 3 years ago. Is it still true? The supposed ease with which we can add new layers into our component model is being overstressed, IMHO. It almost never actually works out that easily. What about XP and Agile? Ahh - he's saying we need RUP, but we need testing from XP. Hmm. He doesn't seem to know a lot about XP/Agile - for instance, he's implying that test-first is optional. Bottom line, he's sure you need the RUP process.

For those of you wondering after last night's post, this qualifies as early for me. No snickering :)

There's a seminar in Baltimore tomorrow on WebSphere and such. I decided to have a look after getting encouragement from a former customer at the St. Paul Companies (used to be USF&G, and a VSE customer). I'll have the laptop, and expect to be taking notes during the talks. If there's Wireless access, I'll post, but who knows. I have to get up at an unnaturally early (for me) hour as well - it's been many years since I've driven into Baltimore during rush hour.

I'm changing that old standby based on this year's weather. There are lies, damn lies..... and Doppler Radar

If you are in Ottawa July 3rd, make sure to visit the local STUG:

The Ottawa Carleton Smalltalk Users Group is happy to announce the next meeting on July 3, 2003:

A new MacOS X Smalltalk

Dorin Sandu, Mark Suska, Ambrai.com

Date:	Thursday, July 3, 2003
Time:	6:30 PM
Location:	Carleton University (see details below)

We will introduce a brand new Smalltalk system that runs natively under MacOS X. After a tour of the development environment, we will cover the design and implementation of the user interface framework including the native interface to the OS. Time permitting, we will review VM design issues and discuss future development plans.

The meeting will be held in Room 5115, Herzberg Laboratories (building 13 on the map - (http://www.carleton.ca/cu/campus/map.htm )). Pay-parking is available in Lot 1, 2, and parking meters can be found along University Drive. Free parking is available across Bronson Avenue opposite Lot 5.

Please RSVP to david@simberon.com if you plan to attend.

David Buck

Enjoy - the Ottawa group is a great bunch!

Here's what customers like to here:

Oracle's $5.1 billion takeover play for PeopleSoft, a rival software company, undoubtedly puts Mr. Ellison in the middle of a bloody corporate battle. But whether he eventually leaves the ring in control of PeopleSoft or not, he may already be the winner just by making the hostile bid.

If Oracle ever reaches a deal to buy PeopleSoft, Mr. Ellison has said he intends to shut it down and transfer its customers to Oracle's eBusiness Suite software. But a takeover is viewed as remote because of possible antitrust objections and since PeopleSoft's board has already rejected the offer and filed a lawsuit on Friday against Oracle, accusing it of unfair trade practices.

I'm sure that makes the end customers feel all warm and fuzzy. And the analysts are already helping out:

Ted Kempf, an analyst at Gartner Research who advises companies about software purchases, told his clients last week to avoid PeopleSoft until the takeover fight was resolved

Wow.

There's been a "why are you bothering to advocate Smalltalk - Java won" thread going on in comp.lang.smalltalk and comp.lang.java.advocacy. It was the usual blend of time-wasting until this came up:

Technically Java the language is now well out of date.

There are better languages out there now - but they lack Java's volume and momentum.

I don't know how far its initial surge will carry Java - I currently expect it to last for quite an extended period.

Which is interesting. The poster is saying - "we know there are better answers. But this is somehow more comfortable". That's worthy of comment all by itself, but the follow-on comment cemented it:

and there's the key, lady and gents!

So it's all about momentum then? I wonder how happy these people would be in a skyscraper built under that philosophy, or a bridge. "We know these materials are second rate, but golly, everyone uses them!". This is one of the major reasons, IMHO, that the public in general, and engineers in particular, don't take software developers seriously. As a community, we like fads better than we like facts. We like trends better than we like things that work well. We would rather drop what w have, even thought it's working, and go with some new, trendy thing. The funny thing is, developers tend to sneer at this sort of sheep-like behavior in other domains, from politics to fashion. Interesting how they conform, just like most people, within their own domain.

If the VW GUI - codenamed Pollock - work is of interest to you, then head to Smalltalk Solutions and register for these two talks:

• http://www.smalltalksolutions.com/schedule/presentations.htm#Shuster0
• http://www.smalltalksolutions.com/schedule/presentations.htm#Shuster1

SCO says they have pulled IBM's Unix license. Now it gets ugly...

David Buck got an article on slashdot after reading this post. So this is slashdot once removed then?

This morning McNealy let loose with more silliness:

"Consumers more and more will demand Java based mobile devices like phones and PDAs essentially ending the consumer era of software sold separately," McNealy said. This is especially important for the gaming industry. Those guys get really mean when they can't play their Java-enabled games."

This is truly amazing. Most consumers of phones have barely heard of Java, or C, or VB. Or Smalltalk. Nor do they care. What they care about is that the application/game mix on the device they bought works, and solves whatever problem they want them to solve. If McNealy really thinks that consumers are clamoring for Java, he needs to have his meds adjusted. The makers of phones may care. The end users most certainly do not.

If you are following the dev builds of BottomFeeder, then you may want to take a look at Rich Demers' new documentation:

• The Users Guide
• The Concepts Guide
• The Tutorial

With MS announcing that IE is going to be part of the OS, period - a few questions come up. The .NET guy puts his finger on them:

Last month, they announced the cancellation of IE for Windows, saying that new versions would only be part of OS upgrades and that their stand-alone browser was dead. Assuming they manage to ship Longhorn in 2005 (doubtful, given their deadline track record), and it takes 2 years to get good upgrade penetration, that means it'll be 2007 before we can assume something besides the fairly buggy and only moderately standards-compliant IE 6 -- assuming they're even interested in increasing their standards compliance.

This month, they announced the cancellation of IE for Mac (which was a far better browser than IE for Windows). Their claim is that user-requested features require tie-in into the OS, and since they don't control the OS, they're giving up altogether.

This is what Microsoft thinks will help them hold the browser market? Getting off of one platform entirely, and leaving an already 3 year old browser to sit for ANOTHER 4 years before it has good penetration? I've noticed a steady slide already of visitors to my site. Six months ago, the visitors were using Netscape/Mozilla about 1% of the time. Now it's 7%.

I see the same uptick of Mozilla users here. Apparently, MS doesn't think that the 4 year gap from Netscape 4.7x to Netscape 6 was a significant factor in their decline. I think that's the most significant factor. Sure, a browser that ships with the OS makes for a nifty default. But if the default is stagnant long enough, some percentage of your user base will wander off the reeservation. Either MS doesn't care what browser you use, or they have made a serious mis-calculation. The traffic numbers over the next few years will tell the tale.

There's an interview of James Gosling in ComputerWorld discussing the IBM backed SWT GUI framework for Java. I'm amused by the interviewer's consistent complaints that the SWT is "proprietary" - is he clear on what that means? Java itself, while freely available, is proprietary. In what way is availability of the SWT different than anything else in Java? The fact that it's an idea that didn't originate at Sun, maybe?

Q: Is it dangerous for that proprietary elements are surfacing for Java?

A: The SWT folks, because it is so proprietary, it's very nonportable and lots of people actually care about portability. So it hasn't been getting the uptake. It's been annoying rather than alarming.

It's interesting to me how SOAP has so much hype, and (apparently) so little actual usage. The blogging world has adopted XML-RPC and simple post mechanisms; Amazon sports two API's - SOAP and a simple url based system. The latter is much more heavily used. This seems to mirror what happened with CORBA - a lot of hype, a few vendors got heavily into it, and a few IT shops made heavy use of it. The rest yawned. Manageability explains it like this:

I also think that standards groups tend to choose the lowest common denominator of innovation. That is, standards groups tend to only approve innovation that they all collectively grasp, however in most cases innovation tends to be grasped only by a few.

Another problem with standards groups tend to create documentation rather than implementation. That is a fatal flaw which I explored in "Be Liberal in What You Accept, Conservative in What You Send". The lack of a standard compliance implementation undermines interoperability, the core essence of standardization.

It's interesting that standards groups give the participants an illusion of choice. Unfortunately, history clearly shows their fate is preordained.

There's something to this. Standards that grow up around actual usage patterns are going to fare better than the "theoretical" ones.

According to CNet, The Council of Europe is trying to put in place a media-wide version of the old "Fairness Doctrine". The theoretical goal is to ensure that someone being criticized can have their response; the likely actual result will be that controversial topics will be avoided in order to avoid trouble. Go read the article - it could affect all manner of online communications in Europe soon.

We actually got through a day without rain here - and a good thing too, since my daughter's end of the year girl scout picnic was today. That went off without a hitch - we had clouds, but no rain.

I've been reading and hanging out all day, not doing a lot. Except waiting (sigh) for the rains to return....