Smalltalk Tidbits, Industry Rants

Via Dave Buck comes news of this Java roundtable discussion:

Borland's Ted Shelton said Java's use is declining in the world because of a perception that vendors compete against one another too much. Java grew up without any serious alternatives, but now Microsoft .NET is maturing and will be a "ferocious competitor" to Java. He even heard about companies putting Java projects on hold pending their evaluation of their .NET projects.

Lol. Java got big because Sun gave it away and the whole early net buzz was around it. Maybe companies are finally noticing this - something I commented on quite awhile ago. Maybe the absurd complexity of things like EJB is strating to sink in. Perhaps people are noticing that Cobol and VB developers are interested in solving problems, not arcane syntax and curly braces :)

Since August of last year, I've had a Kyocera 2135a. It's an ok phone, except for one horrible problem - I've had to replace it 5 times. Why? Becase every 6-10 weeks, the headset port just stops working. Today I replaced it with a newer Kyocera. Right off, something irked me about the phone. When I'm on conference calls, I often mute the phone when no one needs me - that way extraneous office noise doesn't bother the rest of the call. Well, with this phone, there seems to me no way to get to the mute option if you have typed in anything (like, say, a passcode) after the phone call started. Well that's just great. You know what? I don't care about mobile internet access. I don't care about text messaging. I don't care about email on my phone. But it would be nice to have access to core phone functionality.

I expect very little of telecom providers, and they never disappoint or surprise me.....

The usual suspects are off creating a new format for posting to a web log and for syndicating web log content. I look at this, and the first thought that comes to mind is why? RSS 2.0 explicitly allows for extensions via namespace; it also seems to cover the basic ground that is being gone over yet again by this group. The thing of it is, RSS is just starting to be widely adopted - by news organizations and bloggers. Adding yet another format will add some interesting chaos into this mix. what need is this filling? What does RSS 2.0 not do that needs doing so badly that we need a new format? A reasonable blog API, yes - that needs to be done. The blogger API is hideous, and the MetaWebLog API isn't any better. That's a limited goal though, and I suppose it isn't nearly as much fun as re-inventing things that already work.

I posted yesterday on this aspect of the case - now CNet has a story from an IP lawyer that reinforces the point:

Some open-source software projects require contributors to provide legal documentation of ownership in the code they submit and use digital signatures to authenticate those submissions. These types of measures should continue to be improved and be implemented more broadly within the open-source community.

Another confidence-building step would be for the distributors or developers of open-source software to move away from offering their products "as is" and find ways to indemnify customers from any liability for intellectual property infringement. Some in the community might suggest that this step is too radical and that it runs counter to their ideals. However, by not offering at least some degree of comfort to their customers through indemnification, they risk ceding an important market advantage to those proprietary software companies that do

Read that carefully - what it implies is that safe open source efforts require a legal department to verify that everything is ok. That may not be bad advice, but it certainly throws a wrench into the efforts put into projects by small guys - not to mention being a call for full emplyment of IP lawyers. If this advice gets taken, the costs to the larger OS efforts (Apache, Linux, etc.) go up. Who wins in that scenario? MS, of course. And SCO provides a convenient fall guy, so that they don't get blamed.

Today's spotlight is on Anthony Lander's talk on adding encryption to an MSN IM client:

Adding Strong Encryption to the MSN Instant Messenger Network presentation Anthony Lander: independent consultant Tuesday 9:15:00 am to 10:00:00 am

Abstract: This talk looks at the design and implementation of Pongo, an open source MSN Instant Messenger client written in VisualWorks Smalltalk. Pongo adds a strong encryption layer to MSN IM enabling users to have encrypted conversations over chat. This talk looks briefly at the MSN protocol, and the implementation of the Pongo client, but focuses primarily on understanding the design of the encryption layer. Participants should have an intermediate understanding of Smalltalk. No knowledge of encryption is required.

Bio: Anthony Lander has been programming in Smalltalk for over ten years. He has worked on a variety of projects developing database connectivity frameworks, communications switching software, law enforcement applications and real-time 3d video games.

I've watched the Pongo Project progress on the IRC Channel. I've also been inlcuding it as a plugin to BottomFeeder for quite awhile now. Anthony has worked hard to get the encryption working properly with the MS services; come here how he did it!

Amongst a bunch of stuff on copyright law that I don't know enough to comment intelligently on, Cringely points out who the real winner is:

Microsoft is smart and quick. They are no doubt angling to take advantage of this new chaos in the software industry. If history repeats, Microsoft will make very good business decisions. Everyone else will make very poor, if not stupid business decisions. The result will be that Windows will be stronger, and Microsoft's own CRM products, acquired when it bought Navision (the Danish CRM company), will gain a foothold in the market against PeopleSoft and Oracle. A year from now, Microsoft will be a vastly more powerful business even than it is today, which is saying something.

It's been a bad idea to vote against MS winning for years now; this could easily be the next winning round for them....

Interested in getting started with a Smalltalk application server? You can try out VisualWorks and Gemstone in their NC forms free. VW on a single CPU starts at $6000, and Gemstone has just introduced a starter package at $7000. So you can build fully network and web enabled server applications - including a nice persistent store on the back end - for a combined $13k. That's very competitive with the Java app servers. Have a look!

Software vendors - both formal shops and open source, spare time projects - have some preferred method of bug collection. Some use a web form, some use an 800 number - many OS projects use the SourceForge bug tracker. Scott Johnson points out the limitations in reference to a complaint he had about Evolution, and the response that came back on it:

Now Jason argues that I Should have gone to the Ximian site and found the right place to put the comment and then submitted it properly all nice and tidy. Well that's just not going to happen in the real world. Its difficult to find here to put stuff on a web site, figure it out, etc. Until that's a standard thing, users are going to put comments everywhere, even in blogs*. And as someone who has been a product manager most of their professional life, I can honestly tell you this:

• Commentary on your product even in the wrong place is better than no commentary
• Commentary even negative is better than no commentary

One thing that I do think that Jason has missed is that public rants -- IF THEY ARE CREDIBLE** -- serve a real purpose. They make a company very aware that there's an issue and perhaps some incentive to get it fixed. That's huge. And someone else posted in the comments here "how would I like it if someone did that to me for one of my products (Inbox Buddy)?". Well sure I see the issues but you know something -- if I screw up badly enough for someone to write this kind of rant then I should have my feet held to the flame. Yup. That's right -- I may be difficult*** but at least I'm consistently difficult.

I have to say that I agree with him. Yes, I'd rather see bug reports go through our support system or through one of the mailing lists we monitor. The reality is, they crop up in comp.lang.smalltalk, on people's blogs and websites, and in the Smalltalk IRC Channel. They also arrive in email sent to me and to other well known Cincomers. Is this the most efficient way to get them? Maybe not, but it's how it works, and as a software vendor, we just have to deal with the reality. Raging against the nature of reality really isn't going to do us a lot of good. We try to encourage people (gently) to use the preferred channels, but that's about as far as you can go that way.

There was a short outage of the application server this afternoon. I had a complaint that the Public Store access was broken. I took a look at that, and realized that I had done something very silly when I migrated the server from VW 7 to VW 7.1 I had neglected to load in the PostgreSQL access libraries - and that, of course, made it rather difficult to access the database in order to grant new rights. That's addressed now, and the application works. So it's all back to normal, finally. Next time, I'll have to pay a lot more attention to the upgrade....

Today's highlight: The Mysteries of the RB Rewrite Tool

The Mysteries of the RB Rewrite Tool (aka roll-your-own ""refactorings"") tutorial (extra cost applies) Don Roberts, John Brant: Refactory Monday 2:00:00 pm to 5:30:00 pm

Abstract: At the heart of the Refactoring Browser is a general transformation tool known as the "Rewrite Tool" all of the refactorings use this tool to transform the actual smalltalk code. It is possible to use this tool to create your own custom transformations. These transformation might be refactorings but can also be used for any task requiring changing a lot of code. It has been used for migrating between dialects of Smalltalk, replacing a data-access layer with a different one, and converting an application to use ANSI standard exceptions.

Participants will learn the syntax of the rewrite tool along with the concepts necessary to create their own rules. This tutorial will consist of many examples of the various types of rules.

Bio: John Brant and Don Roberts are the co-creators of the Refactoring Browser, the first commercially viable refactoring tool for any language. They are consultants and have spent the past several years working on various projects in addition to developing the RB. Don has recently gone legit and is an assistant professor at the University of Evansville.

This talk will show the true power of the refactoring engine - well worth the time for the serious Smalltalker.

CIO Magazine is talking about Open Source as a solution:

In a November 2002 CIO survey of 375 information executives, 54 percent said that within five years open source would be their dominant server platform. Today, major enterprises are running mission-critical functions on open source, big vendors have lined up to support it, and reliable applications have emerged.

And CIOs who have implemented it report huge total-cost-of-ownership (TCO) reductions.

It's now clear that within five years, open source will transform how software is developed, sold and supported.

When CIOs need help with their systems and software, they don't have to depend on vendors with their own agendas because when an open-source app doesn't work, administrators can look at the source code, figure out why and write a fix themselves. If they're having trouble, help is just a newsgroup away.

Read that again, and note that this is CIOs talking, not a bunch of wild eyed evangelists. The ground is shifting, and IT shops that don't notice are going to be saddling their firms with higher costs than their competitors. That won't be noticed immediately - but at some point, it will be.

Now that I've finished the 5th Harry Potter book, I can get to bed earlier. Yawn.....

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 :)