Smalltalk Tidbits, Industry Rants

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....

A friend of mine who attended Java One said that the whole vendor area was smaller than he expected - this may well just be a sign of the ongoing down turn in vendor participation at trade shows. Still, this story from InfoWorld is interesting:

This year, IBM dropped its sponsorship of the show after last year being a platinum sponsor, which is the highest level available, and had a reduced presence on the show floor where it demonstrated its Rational developer tools and Pervasive Computing offerings, but omitted its popular WebSphere product line.

IBM speakers also kept a small footprint at the event, appearing in none of the keynote addresses and in only about a dozen of the more than 400 technical sessions

So does it mean anything? Hard to say.

I've noticed that BottomFeeder could, with enough feeds, start taking up large amounts of RAM. Running in a development environment showed that I wasn't generating any leaks, so it was either MemoryPolicy, ObjectMemory settings, or both. I've been twiddling with the MemoryPolicy settings for a couple of weeks now (with some good help from Terry Raymond) - but that wasn't solving the whole problem.

Then it occurred to me what was probably happening - premature tenuring. VisualWorks allocates new objects in Eden (and uses the two survivor spaces to manage new objects). When survivor space fills up, and new objects aren't ready to die yet - they survivors have to go somewhere to make room for the new stuff. That somewhere is Old Space. So what if you allocate a lot of new objects quickly, and they keep filling up the survivor spaces? You'll get rapid tenuring of objects that would otherwise die. These end up in Old space, where they won't die until you your system runs against a memory limit (either the one imposed by MemoryPolicy or a hard system limit). At that point, you'll see the compaction and GC icons a lot if the allocation pattern continues, because those new and survivor spaces still aren't big enough - and growth is capped. I've talked about this issue before; this is kind of a continuation of that earlier post.

So what do you do? You go look at ObjectMemory class - #spacesAtStartup:. I had to create a new base for this because changing the settings here require an image save, and BottomFeeder (and most end user Smalltalk apps) never save the image at runtime. What the settings allow you to do is scale the various space sizes up. Now, why is this a problem in an application like BottomFeeder?

Consider what BottomFeeder does - every N minutes, it wakes up and trawls through your subscriptions, looking for new content. That means do an HTTP query (grab text). Parse the results into an XML document (a largish new object). Then create item objects from the xml, and check against what we have (more new objects). I am currently subscribed to 140 channels, which makes for a lot of new objects - fairly quickly - during an update scan. So with eden and the survivor spaces set to their default sizes, lots of these objects end up in old space, which is not where they should be - none of them are really "permanent" from an application perspective.

I ended up sending this message as part of the new build:

ObjectMemory sizesAtStartup: #(10.0 10.0 3.0 1.0 1.0 2.0 1.0).

The important numbers are the first two - they ask the system to make eden and the survivor spaces 10x bigger than they normally would be - and with that increased size, there's less chance of premature tenuring. This is an important thing to keep in mind for all kinds of applications - what looks like an application level memory leak may well have a system level root. Now, it's always a good idea to look at what's going on before you start mindlessly twiddling these numbers - if you have a dependency issue, where lots of objects are ending up in the DependentsFields shared variable, for instance, you have an entirely different problem. So keep this technique in mind, but look at the behavior of your application before applying it.

I upgraded this server from V 7 to vW 7.1 yesterday, and that meant a few changes to the applications here - one critical one to the piece that reads in the initialization files, since I had made a change to that application a few months ago. I got everything updated except the NC app. Sorry for the problem; it's all better now

Ara Abrahamian lets loose with a UML rant:

Imho the biggest problem of UML and MDA-based software development is that, well, the code isn't even close to what you've diagrammed! I mean take a look at buildings around you. It's easy to map what the architect drew on his board to the real tangible building. With UML the diagrams are something the designer guy draws and understands but the real program has very little resemblance to it! The designer prefers to speak a more engineering-oriented language, UML, while the masons (developers) don't like or understand it because they have to build the damn building and the architecture they are given by the modeling guy is so different from what they build. They speak two different languages. That said there is value in a engineering-oriented bureaucratic approach too, after all the civilization is built by architects rather than masons, right? So fix the gap otherwise just shut up and don't preach it :-)

I can't say I disagree with his assessment of the value of UML...

So Slashdot has a story on Jackpot, Gosling's latest take on devlopment. It's occurred to him that having the program parse tree around makes things like refactoring easier. Gee, he could have called Don and John and had them explain it. I bet they would have even been willing to use small words.

Even if his view is limited to Java, you don't suppose he's ever heard of Eclipse or IntelliJ?

This explains the Apple development of Safari. Found via Matt Croyden

I stumbled across this site and decided to take a crack at implementing Smalltalk tests - I started with package Shootout (in the public store. Have a look at the package comment.

I just read all the recent posts on Steveen Smith's site. I blogged this one earlier, but there are other excellent posts there. Go have a look.

I spotted this on Being Effective:

My ability to be an effective change agent depends completely on my ability to influence my teammates and management. They aren't going to do anything differently just because I say so.

I need creditability with people who are managers. And that creditability takes many forms -- it could be about my knowledge and skills; it could be about who I am as a person; it could be about a shared interest. Whatever it is, that person will invest more time in communication with me than someone else.

Let's say I have creditability with Noel who is a third-level manager. Now I have periodic opportunities to make proposals to Noel. If our interactions create a return for Noel, I'll continue to have opportunities to speak with him. Otherwise, I'll lose access.

One way I can lose access to Noel is to tell him that things aren't working because he doesn't know what is really happening. That's like yelling "Fire!" in a crowded building. You are going to get arrested.

Yeah, I've wasted plenty of time complaining about things that just deflate me in the eyes of management. It's too easy to do - all you need to do is feel strongly about something, and then fail to translate it into language that the other guy can deal with. pick your battles

There was another brief server hiccup this morning - I just updated the application server that runs this site from VW 7 to VW 7.1. Sorry for any inconvenience this may have caused...

Wired has a story on Sun's problems. The basic problem is simple:

Share prices of nearly every publicly traded Silicon Valley firm have plummeted since 2000, of course, but few have fallen as precipitously as Sun's. As of early May, its stock, down 94 percent from a 2000 high, was trading pretty much exactly where it was in 1996, when the computer maker was in the early arc of its dotcom-fueled rocket ride. In its heyday, Sun sometimes sold as much as $5 billion worth of computer equipment, software, and services in a single quarter, but over the past few years quarterly revenue has dropped to nearly half that. Revenue fell an additional 10 percent in the first three months of 2003, marking the eighth consecutive quarterly decline.

The interesting thing, to me, is the "build it and they will come" attitude that sems to pervade Sun's strategy - Java is simply the biggest part of that view. Heres's the attitude in all its glory:

Forget the stock price and flagging sales, he argues, and focus on Sun's record of innovation. Technology, he insists, will turn the company around. He talks up a next-generation chip potentially 30 times faster than the microprocessors currently running Sun's most powerful machines. He and his team also point to a pair of software initiatives, N1 and Project Orion, that some of the company's biggest brains are hard at work on. "With all we've got up our sleeves, mate," declares Andy Lark, the New Zealand-born marketing chief, "we've got the competition quaking in their boots." That's quintessential Sun: The tech industry is ready to write off the computer maker, but McNealy and company are smugly imagining future glory.

I've seen this "our technology is so good that nothing else matters" business theory before - at ParcPlace. ParcPlace didn't have nearly the pile of cash that Sun does, but it also didn't have the burn rate. I suspect that what Sun needs more than anything else is what ParcPlace needed - new executive management. ParcPlace got it too late, and it's looking more and more like Sun will suffer the same fate. Watch the Java crowd be utterly baffled by this, since they still seem unclear on the "who controls Java" concept.

I was trying a quick update of the blog, and it took longer than I thought - if you got an error, it's because of the twiddling I as doing...

If you've wondered why VW 7 made strings immutable, read this explanation of the concept by Andy Bowers of Object-Arts:

The literal String object that contained the characters ($s $m $a $l $l $t $a $l $k) is still there it is just that you have replaced the first indexed element of the object with $S. Then anything that referred to that String will now be referring to the new form, i.e. 'Smalltalk'.

So in LearningWorks, and earlier versions of some modern Smalltalks, you could try this:

string1 := 'smalltalk'.
string2 := string1.
string1 at: 1 put: $S.

string1 "Display it" -> 'Smalltalk'
string2 "Display it" -> 'Smalltalk'

While it looks like two variables, string1 and string2 have been oddly modified by this seemingly innocous act of modifying one of them this is not really the case. The key point is that Smalltalk treats variables differently from other languages. I only really "got" this point originally when someone explained that Smalltalk variables don't actually contain the object data (as they do in C++ for eg.) but actually they are "slots" that hold pointers to their objects. So effectively, Smalltalk variables are a bit like references in C++ (if that helps). So in the example above, string1 and string2 are holding a reference to the same object (the literal string 'smalltalk').

You might then wonder why modern implementations have made the modification of literal strings illegal. Well an example from early Dolphin Smalltalk might serve to illustrate this:

You may already know that you can use the #, message to concatenate one or more Strings together (in fact you can use this message to concatenate any sequenceable collections).

string1 := 'Smalltalk', ' is ', 'Great'.

However, if you take a look at the implementation of the #, message in SequenceableCollection then you'll see that, because it has to take a copy of the source string each time, then this might become rather inefficient for a large number of concatenations. So, most of the time, you'll be advised to use Streams when concatenating large amounts of text. This is how you do it:

stream := WriteStream on: String new.
stream
    nextPutAll: 'Smalltalk';
    nextPutAll: ' is ';
    nextPutAll: 'Great'.
string1 := stream contents.

This may seem a rather long-winded procedure to tag a few strings together but, trust me, it's not really that bad in practice. Anyway, the point of this anecdote is that the above is almost the same as:

stream := WriteStream on: ''.
stream
    nextPutAll: 'Smalltalk';
    nextPutAll: ' is ';
    nextPutAll: 'Great'.
string1 := stream contents.

And we found that several of the Dolphin developers used this form and got into a terrible mess. To be honest, I'm not sure it was their fault since I think that some early Smalltalk texts may have suggested it. So, what is wrong with creating a WriteStream on a literal empty string? Well, possibly nothing in some Smalltalk implementations. However, when we were designing Dolphin we took a leaf out of IBM Smalltalk's book and decided that it would be a good idea to share identical literal strings wherever possible. So, if you use the same literal string in more than one place in a method we only create one instance of the string and both places that use it share the same object. We also discovered that in the entire image there were initially a lot of empty literal string ('') objects. Hence, we made the Dolphin compiler, when it saw '' inside some Smalltalk source, always refer the same single instance of THE empty literal string (i.e. there is only one empty literal string object in the entire image).

This means that, if you did a (WriteStream on: ''), you would be writing over the top of the contents of the single empty literal string. This in turn meant that, if you ran the above code, every reference to an empty string in the entire system would suddenly turn into a reference to "Smalltalk is Great". Although most of our users would have agreed with the general sentiment of this phrase, few who tried the above code snippet would have agreed with it when their code browsers suddenly started filling the contents of empty methods with "Smalltalk is Great"!!

Anyway, the result is that Dolphin now throws an "Attempt to update read-only object" exception if any attempt is made to modify a literal string. I believe that the recent change to VisualWorks to throw an exception in similar circumstances now brings all the mainstream Smalltalks into line with one another.

I hope this helps rather than hinders....

Best Regards,

Andy Bower Object Arts Ltd.

Mark Pilgrim pulled an interesting stunt the other day. By sticking a script into the description tag, any aggregator that

• Uses a full browser
• And does not strip out script tags

is open to all kinds of interesting exploits. BottomFeeder is immune.

Sun posts some irony:

Innovation happens everywhere. That's the nature of life. Alas, it just so happens that it often gets ignored or otherwise overrun by various kinds of steamrollers

Yeah, that Java steamroller has developers everywhere using sub-standard solutions.....

Via Jeff Zeldman comes this report on the sorry state of HTML. 99.29% of the documents in their sample were not valid HTML. Wow.

Spotted in cls and the vwnc mailing list:

SIXX 0.1g is now available for all major Smalltalks - Squeak, VW, and Dolphin XP. http://www.mars.dti.ne.jp/~umejava/smalltalk/sixx/index.html

For Squeakers, there is also a SAR version

SIXX is a XML serializer/deserializer for Smalltalk. You can exchange almost all Smalltalk objects among images.

0.1g improvements:

• SixxReadStream can now read corrupt SIXX files with best effort (recovery mode).
• Now SIXX avoids sending readFrom: with String parameter.
• A SIXX Time generation test fix for different locales.

SIXX is driven by many users' feedback. I would like to say thank you to all of the contributors...

Cheers,

---

[:masashi | ^umezawa]

The SCO suit may give us a test of the GPL. CNet reports that SCO GPL'd their unix by shipping it with bits of Linux in it:

Several organizations argue that SCO Group's shipment of a Linux product undermines its current attack on the operating system's intellectual-property underpinnings, but SCO says the argument is baseless.

SCO says proprietary source code underlying Unix has been illegally copied into the Linux kernel. SCO critics argue that because the company shipped a Linux product under an open-source license, that Unix code no longer is proprietary.

But SCO, which has staked its future on its Unix intellectual property and how it's licensed, believes opening the source code would require a deliberate act the company didn't in fact undertake

Two things come to mind. First, will this mean a legal test of the GPL? If so, it should be interesting to see how that falls out. Second, I'd like to see SCO apply that "deliberate act" theory to the other side of their suit.

Tim Bray points out the correct steps to good code:

Once you get past that pledge, the order of this essay goes quickly off the rails. Gray deals out several thousand words of detailed and useful information about performance issues in CLR, and only halfway through the essay does he introduce the "CLR Profiler" and give advice on how to measure what your code is actually doing. This is probably wrong, because I think the way to write fast code is simple and has been well-known for a long time. Here it is:

1. Design and code your app, trying hard not to do anything really stupid, and striving for flexibility.
2. If it's fast enough, don't worry any more.
3. If it's slow, get out your profiler and measure things until you understand where the problem is.
4. Fix the problem, which may well require major refactoring, but that's OK because that's probably coming at you pretty soon anyhow with the next batch of requirements. Furthermore, you couldn't have avoided it because nobody is smart enough to predict where the bottlenecks will be in a complex application before it's running.

That's a perfect summary of how to go about getting a clean, maintainable application that is as fast as it needs to be.

I see that Sun is still not getting it at Java One. Via Simon Phipps comes this statement from Jonathan Schwartz's keynote:

The threshold that we call someone a developer, is going to be dropped significantly ... Sun have historically treated the developer with respect. Giving them the attention and kudos they solely craved. Java developers are real developers; they don't want to be labelled with the Microsoft VB/Marco crowd. Sun will have to be very careful in how they are going to take this forward without alienating and devaluing the current developer base

This comes in the context of talking about expanding the base of Java developers. That's just brilliant - a call to attract mor people that calls the users f the most popular toolset "not real programmers". This is actually one of the many reasons I dislike Sun more than MS - they come across as far more arrogant. Simon believes that the answer is to expand the range of languages on the JVM:

My personal view is that the way to expand the developer community is not to 'drop the threshold' but rather to expand the range of languages that target the Java platform. That's why the discussion in this morning's keynote concerning the embrace of programming languages like PHP and Jython (Sean will be pleased!) is so important. PHP and Jython programming isn't dumbed-down - it's just the use of the tools that are fit for the job, and embracing a wider range of tools simply expands the scope rather than lowers the bar.

There are two problems with this:

• The JVM is just horrible for dynamic languages (Smalltalk, Lisp, et. al.). I suppose most of the Java elite doesn't care, but they should - interest iin dynamic languages seems to be increasing. Watch Sun continue to not get it here
• As Ted Leung points out, this many languages idiom is what MS is pushing. Ted says: One of the supposed benefits of Java is that there is only one language that you need to know