Smalltalk Tidbits, Industry Rants

There were a lot of comments on this post, as well as posts on other blogs. Peter William Lount has some more commentary up today

I think Scoble hasn't thought this one through:

Om Malik says that the personal blog is dead. Oh, yeah! Well, personally, I know a whole lot of people who are publishing blogs for just their friends and family. You wanna read some blogs that have very few readers? Just click randomly on the page at Weblogs.com. You'll find lots of blogs you haven't heard of yet. The question is, are any of them interesting?

Or, visit MSN Spaces and look at the "just updated" part of the page.

But, sadly, OM is right. It's getting harder and harder to keep up with the rapidly-spreading blogosphere. In the end, it's going to be automatic tools that really help you find the good stuff.

You mean like TV killed radio? Or do you mean the way Radio had earlier killed off magazines? And as useful as Amazon's "readers who bought this also bought blah" is, I still tend to focus in on new books by authors I already like. In the same way, I seriously doubt that I'll cede control to a search bot for all my news - I'll continue to personally look for people who I find interesting. Search will get better, but it will augment, not replace what we do now.

The first day of the show is over. It was a good day - lots of good conversations with users of VisualWorks and ObjectStudio, lots of good presentations. My notes are up - scroll down. I'll get Niall's copious notes at some point in the future and post those as well. I got the pictures from Andrew McNeil, our guy in Sydney, Australia. Here's how I looked this morning, talking about the product roadmap:

Andreas Toenne of Heeg is going over the DotNet connect for VW. .NET is Microsoft's managed platform (their answer to J2EE). Huge, growing library of windows libraries and services. It's (in theory) the future development/deployment platform for Windows based applications. It is easier to work with than C++ - a big step up. Not as productive or simple as Smalltalk, but a step up for the C++ world. The .NET connect is our way of interfacing VW applications with a C# (or other CLR based) application. Most of this talk is demo again. The demo is a simple one - captures mouse clicks, and sends them to VisualWorks to chart.

First step - install the DotNet connect into the environment (load the parcel using the parcel manager). Second step - create (edit, compile) the C# application. There are already some pre-generated links for things like WindowsForms.

Next - start the wizard. The wizard allows you to adjust settings - what to import - the assembly or assemblies in question, for instance. The wizard imports all the methods/constructors (notifying you of problems along the way) - allows you to filter out any you don't need to hook to as well. What's generated is some C++ code that needs to be compiled (an nmake file is created as well).

Important here - you need not buy anything from MS here - you can download the free tools from MS (all command line). You can also, of course, work with VS itself.

Next - Load in the generated Smalltalk code (the wizard created that as well). Right now, this is a set of (load order important) .st files. By the next release, this step should be a lot simpler. What comes in is a namespace, some stub classes that are needed, and an external interface class that hooks to the DLL (generated in the step above).

Finally, we need to link up the events that are coming from the dotNet dll with your Smalltalk code - here you need to write some code. I'm sitting at the back of the room here, so I can't actually make out the code itself - there are demos shipping with VW 7.3 (including the NC). At this point, you often need to go back to the generated C interface and change the relevant API to be threaded.

There are a few choices for talking to a .NET application:

• Expensive
• Web Services
• Intrusive
• CORBA
• COM
• Direct (the DotNet Connect)
• Custom marshalling
• Communication via TCP or C calls
• proxy in the .NET world

The way in for us is through the unmanaged bridge that MS put in for all the existing C/C++ code out there. On the VW side, a proxy layer was built to manage that communication.

Limitations

• The CLR is a superset of C# or C++
• Not all legal types are importable
• Some illegal types are not detected
• No support for Mono at this point

The documentation covers all the limitations (I didn't get all of them down here). The performance is very good - method calls and returns are very fast.

Future steps:

• Next version: NConnect
• 100% integration with VisualStudio
• Project-Wizard generated solution
• DotNet GUI inside VisualWorks Windows (without any detour through COM)

You can see a high level view of this in our DotNet Whitepaper.

Alan, Len, Andreas, and Mark are demonstrating a usage of Opentalk to publish data from ObjectStudio to the web. It's a simple demo - an SSP page and servlet on the VisualWorks side, with Opentalk used to communicate back to ObjectStudio for the data.

"get the name from the form data and then use it to get data from ObjectStudio"
name := self request anyFormValueAt: 'name'.
data := self class defaultServiceReference select: name.

Note - you can't just expect to pull a stock ObjectStudio client/server application and push it behind a VW web application - you have all the single user/multi-user issues that would need to be addressed. The summary from Alan - it was more work to create the simple HTML pages than it was to code up the data transmission piece.>

Question: Has anyone used this in the real world yet?
Answer: Yes and no. There are some OST customers using the preview version that shipped with 6.91. As well, Opentalk itself has been used in production by many people using VisualWorks.
Question: What about the documentation? Is it well documented?
Answer: Yes, the documentation shows all this.

Now we have the first technical talk of the talk of the conference, after my overview of product directions. Alan's talking about Web Toolkit - the VW Web Application server capabilities. This all started (for VW) back in 1995 with VisualWave. in 2001 we introduced the Web Toolkit with VW 5i.4 - an ASP/JSP compliant toolkit. It started out sharing most of the infeastructure with Wave, and has been increasingly sharing infrastructure with Opentalk - instead of 2 server frameworks, we are converging towards one.

Why WTK? "Standard", but better. It's simple, reliable, secure. It's also easily debuggable - i.e., - slap a halt inside an ssp page and bang - into the debugger. Contrast that with the equivalent in WebSphere (etc) jsp - lots and lots of extra boilerplate. What Alan is really on about is the latest and greatest in WTK, along with some tips

• Internationalization
• Scalability
• Headless and Subsystems

With 7.3, we have better international character support. One of the issues is that the web started out very English-centric, and international support has been very much a catch up game. One of the main things we did in 7.3 was to separate the locale and charset - which had been tied together in previous releases. What are the main charset issues?

• The web runs on ISO-8859-1
• International characters can be in domain names, urls, forms, etc....

The probem with URL encoding? What encoding is it? The standard seems to be converging towards utf-8. Typically, browsers use the encoding of the page containing a linked url. This tends to get ugly. Here's what we do:

• Try utf-8
• If it doesn't decode, it's not utf-8 (go to next encoding)
• If it does, we'll try to see if we could resolve the result (to a servlet, wave app, etc). If we can, we do
• Can we find a session (in WTK/Wave)
• If so, does the session have an encoding? If so, try it
• Fall to default if not
• Configurable - you can change/disable it
• Form data is different - you just have to know. Use accept charset and hope that the browser honors it.

What about scalability? Pure Smalltalk scales quite nicely (proxying from web server directly to the WTK server or exposing the WTK server directly). Gateways allow connectivity and interoperability. We've got a Perl gateway in this release, primarily for use with Apache. We also updated ISAPI. NSAPI and FastCGI have been deprecated. Configuration of these can be a pain - you need to check the doc for your web server carefully.

What about memory tuning? You need to look at both ObjectMemory and MemoryPolicy. In 7.2.1 and 7.3 we have modified these - LargeSpace has been made much bigger - this is to deal with socket buffer issues. The upper bound has been moved down to 160MB, so you need to check that. We have implemented some buffer reuse, but it's not yet optimized. You really, really need to test this out for yourself!

Load Handling? There are now parameters for:

• Within an image
• Maximum connections
• Process priorities
• Socket parameters
• Delay on accepting new connections
• Accept that you can't handle everything
• Better to serve a smaller number of connections well, instead of a larger number badly
• Degrade gracefully

There is an Opentalk based load balancer that ships with the product. There is also a more general (and more generic) Opentalk balancer that well be adapted to replace the WTK specific balancer. We do not support session migration.

Subsystems/Headless support. We added a defined startup/shutdown procedure to this release. Before, there were a few big methods in ObjectMemory that did everything. We've refactored it all. They are kind of like Unix run-levels. There are subsystems for the Windowing System, for User Applications (main() ), for Opentalk. This replaces being a dependent on ObjectMemory. That's still supported. You can specify pr-reqs and command line options. This makes headless operation more definable. You can easily drive it this way:

WindowingSystem canActivate: false.
WindowingSystem canActivate: true; activate.

There are a number of useful command line flags:

• -headless
• -headfull
• -pcl
• -filein
• -doit (evaluates code and runs)
• -evaluate (evaluates code and quits)
• -settings (specify an xml settings file)

You can disable these for end user applications!

Heeg has created a nice goodie called VisualWAF - it's a layer above WTK for application development. There's also Seaside, which is now shipping as a goodie in 7.3. Then there's WithStye, an XML editing/display toolset for VisuaLWorks.

Question: from Georg: What do you use to create a simple, easy to edit website? I recommended WithStyle, and Andrew McNeil has demos available.

Question: What about multi-language websites? You can have specific tags that specify their encoding. Answer: That's fine, the server is ok with that. It's only an issue with form data, query data (etc) that comes back - need application specific logic there.

Comment - several people would be interested in the WithStyle demos - we'll have that going in the "Meet the Experts" room.

Len Lutomski and Andreas Hiltner are up with the new Opentalk for ObjectStudio stuff - they'll have a live demo of VW <--> ObjectStudio interoperability. Cross platform as well, with the VW side running on a Mac.

So, There's a demo of a chat application (shipping on the CD) - and they'll go over the cross dialect portability issues. First, what's Opentalk? Opentalk is the framework used in VW for the creation of communication protocols. ObjectStudio 7.0 contains a release quality version of Opentalk ST-ST (Smalltalk to Smalltalk). ObjectStudio was extended quite a bit to achieve this - the upshot is that Opentalk in ObjectStudio is identical (at the user level) to Opentalk in VW - so user code will move between the two easily.

ObjectStudio now supports multi-image applications, including VW images on non-Windows systems. This extends support for OST features to VW users, and of VW features to OST users.

Now they are showing the demo - chat windows on Windows in ObjectStudio, and their analog over on the Mac in VW.

Len's now going through some basics. Three topics:

• request brokers
• initial references to remote objects
• pass modes

This stuff is all discussed in the doc. A request broker implements the API of interest to applications. A protocol implementation consists of

• an adaptor - mapps ST messaging to a protocol type
• a transport - implements transport layer (e.g., TCP)
• a marshaler - marshals/unmarshals objects onto/oof the wire
• a dispatcher - regulates message handling on either end of the wire - typically process per message

Creating a broker (you can specify the address for systems with more than one network interface). A broker is actually a fairly complex object - the simple API below flares out to define all the parts described above (adaptor, transport, marshaler, dispatcher). That means that you can customize these parameters, or derive your own protocols and slot them into this api easily.

"create it"
broker := RequestBroker newStstTcpAtPort: 1900.

"start the broker"
broker start.

"stop the broker"
broker stop.

Now, why would you want to customize the dispatch? In VW, a new process is just a lightweight VW process. In OST, it's a Windows thread. That could tie a Windows system down quickly - you'll want to configure pool dispatch. There's some basic protocol for testing connections - echo and ping. Echo sends an object across and then gets it back. So you test marshal and unmarshal on both ends.

Now, to actually accomplish something you need to reference some object on the remote side. A reference is a local proxy object that re-implements doesNotUnderstand: to forward messages. When you send a message to a reference, you are sending it across the wire. There are two ways:

• Programmatic construction
• Server registry

"create"
broker objectAdaptor 
	export: someObject 
	oid: #greeting.

"reference remotely"
remote := clientbroker 
	remoteObjectToHost: 'localhost' 
	port: 1907 
	oid: #greeting

"server registry"
broker registerService: Random new id: #random

"client"
remoteObject := (clientBroker
					activeBrokerAtHost: 'localhost'
					port: 1907)
				serviceById: #random.

What about pass mode control? Pass mode is how it's transmitted - for instance, by reference or by value. Copying a large object across the wire can be expensive. Passing by reference is cheap, but messaging that object may be expensive. You need to balance the two. By default in Opentalk, most things (not immediates, literals, few others) are passed by reference. You can override that at the class or instance level - there's an API to coerce the pass mode. You can customize down to the instance variable level if desired. Opentalk supports several pass modes and pass mode controls - check the documentation.

What about cross dialect issues? You need to be aware of them - they are all documented. Base classes are mapped already - so VW and OST collections pass between each other seamlessly. There are some disparities in Magnitudes:

• OST Decimal, VW FixedPoint
• Float/Doubles (ObjectStudio only has the equivalent of the VW Double)

The error messages coming from OST and VW will differ as well (i.e., the error strings from things like MNU, for instance. That wraps things up, and unfortunately, time was a little rushed. I think a number of people are going to want to see this in the demo room later. Another upshot - having done this, porting Opentalk to ObjectStudio means that it should be fairly easy to port over to other Smalltalk implementations.

I've got dialup in my room here - very, very slow dialup. Also very, very unreliable dialup :). I'll be taking notes at the conference and posting things up nightly, but I don't think I'll be able to keep up with all my normal reading - the connection is just too dodgy.

In a post explaining Python for Java developers, there's a hilarious paraphrasing of a comment on RegEx:

XML is not the answer. It is not even the question. To paraphrase Jamie Zawinski on regular expressions, "Some people, when confronted with a problem, think "I know, I'll use XML." Now they have two problems."

Heh. Oh, read the entire post as well. Everything he said about Python relative to Java goes for Smalltalk as well.

I may well be off email until Friday - the hotel I'm at has no broadband, and dialup looks dicey - seems that you have to request a room with an analog line, and I haven't done that yet. I'm in the Frankfurt Cincom office today, and they block email access unless it's going to their servers... which I don't use (for reasons that are way to stupid to go into here). So bottom line - if you don't get an email response from me this week, don't be too surprised.

I'm on the flight to Frankfurt as I write this. Supposedly, my presentation for the conference is all done - it's on the CD that the marketing folks are going to hand out at the show. Like most presenters, I'm simply incapable of leaving well enough alone - I had to twiddle with my slides.

As it happens, the presentation is going to be my standard "where we are, where are we going" spiel. I haven't been happy with that presentation for quite some time now - it's repetitive, too wordy, and too long. You could say that it needed refactoring. So, with nothing better to do before they turn the lights off on the flight, I've gone ahead and refactored my slides. As soon as I have a network connection again, I'll upload the new presentation to our Wiki

One of the things we have been looking at is re-hosting ObjectStudio onto .NET. This is research at present - we have not committed to such a project! As it happens, I'm writing this while I'm on my way to the User's Conference in Frankfurt - and I ran across Larry O'Brien's latest article in SDTimes. He's talking about "little languages" (what most people call Domain Specific Languages, I think) - and in the midst of that, says the following:

A fundamental premise of .NET is that a platform that is explicitly designed to support multiple languages and programming approaches is superior to a platform, notably Java, whose design is dominated by the needs of a single language. I am convinced that Microsoft is sincere in trying to give the .NET managed platform as much flexibility as possible, albeit for the purely mercenary purpose of being in a position to explout advances as they enter the mainstream

Hmm. That explains why VB didn't change at all once it morphed into VB.Net, right? ,NET supports any language, so long as it ultimately behaves a lot like C#. Going back to our ObjectStudio plans - we've taken a good initial look at the platform, and our engineers have found a number of issues - any Smalltalk built on top of .NET is going to have to make a lot of compromises, because there are a lot of things you can't do:

• Interactively modify the system
• save and restore an image
• swap object identity (#become:)
• change the class of an object
• change the superclass of a class

Some of those might seem like things you wouldn't 'normall' need - say, changing the class of an object. On the other hand, have a look here, at one of my posts on BOSS Schema migration. BOSS is the VisualWorks object serialization framework; schema migration involves changing the class of an object as you get it back from disk. Would you have to implement a framework that way? Clearly not, or else Java wouldn't support serialization. On the other hand, it's how it was done in VW, because it was pretty easy. Some of the other problems get right into the guts of typical Smalltalk operations, like interactively modifying a system (any time an end user applies an update to BottomFeeder, for instance, that happens).

Ultimately, .NET only looks like it supports multiple languages and paradigms from the narrow perspective of the C language family - many things we take for granted in Smalltalk are simply inconceivable to those guys. if you can't imagine it, you don't even know that it's missing. Now, I'm sure that one could build a middle layer over the top of the .NET runtime to deal with these issues - but it would be hard, and the resulting system would be slows. Supposedly, many of these issues will be addressed now that the iron Python guy is working for Microsoft. We'll see...

I'll be offline for awhile later today - I'm heading to Frankfurt, Germany on an overnight flight. I'll be speaking at and attending the Worldwide User's Conference - I hope to see a lot of Smalltalkers there!

I've gotten a number of questions about how to build a BottomFeeder development image. I've finally got a set of basic instructions up on the site - follow the download links and grab the first download available under the DEV links (scroll down). Here's what you'll need to do first:

• Get a copy of VisualWorks NC
• Register with Software with Style in order to get access to WithStyle sources.
• Get an account in the Public Store so that you can grab the latest code
• Follow the script instructions in this zip file

When you uncompress the file, you should preserve the directory structure. You may need to adapt the script file based on what you do there. Enjoy!

Blogging Roller explains everything you'll ever need to know about child behavior:

I've got a theory about why kids can make parents so angry. They don't realize it, but kids emulate their parent's verbal and physical mannerisms all the time. As you watch your child you can see bits and pieces of your own personality. They pick up on the little phrases that you repeat. They repeat them too. When your kid starts to fuss or throw a tantrum or otherwise behave like a jackass, he does it in a way that reminds you of yourself, your mannerisms, and your personality. You see your own inner jackass reflected in the actions of your child. Your kid learned how to be a jackass directly from you, it shows, and boy oh boy does that piss you off.

One of the things that helps a lot in a product manager's job is knowing what people are saying about your product(s). One way of doing this is face to face communication, and it's usually the best way. Unfortunately, I'm not really able to visit with all of our customers on a regular basis - there are too many of them, and they are too widely scattered (all over the world). We have local people, and they talk to customers (and in turn, to me) - and I visit with various customer groups at shows, conferences, etc. Still, it's not enough - I really need to get more. Enter the BottomFeeder

One of the more useful things I built int Bf is support for the RSS/Atom feeds that various search engines support - you can get results in a feed from:

• Google
• Feedster
• BlogDigger
• Amazon
• Yahoo

And many others. I don't use pubsub, because their whole email subscription system was an extra step; call me lazy. It also helps to check Technorati on a regular basis. What I've done is set up search feeds for these engines looking for references to these terms: Cincom, Smalltalk, VisualWorks, ObjectStudio, James Robertson, BottomFeeder. I run across comments made about my company and/or its products pretty darn quick this way; it fills in the gap created by the impossibility of meeting regularly with all customers - not to mention the fact that it finds commentary by potential customers as well.

If you're involved in product promotion or customer relations in any way, you need to be tracking this kind of information. Get yourself an aggregator and start searching!

Peter Williams Lount addresses what Birdman's Land calls OO's Achilles Heel:

"When everyone defines their own objects, then all [Object Oriented programming] does is bog you down trying to convert between two mismatched items."

I don't think this problem is specific to OO at all; it's a general domain level problem that has cropped up in many places (how many people have tried to define a generic "Person" object or data structure, for instance?). Peter's got a long dissertation on that subject; have a look

Strongly Typed misconstrues the terms again:

WOW! There's quite a discussion going on regarding Stongly-Typed languages and Dynamic Languages.

A common point that I see in the discussion is compile time / run time checking. A strongly typed language will do type checking at compile time and reduce run time errors. Because of that dynamic languages will require the programmers to be more responsible.

Strong typing has nothing to do with whether the check is at compile time or runtime. Smalltalk, for instance, is strongly typed - you can't get a type error. If you send a message to an object that doesn't understand it, you'll get a well understood exception. C++ - which I guess is "strongly typed" in Richard's world - forces type declarations up front, but you can, via the wonders of casting, send wholly inappropriate messages to objects and get nice, malformed core dumps. Yep, that's safe. Hmm. Java lets you walk into that same minefield with casting, although the results are far less dangerous (the runtime system deals with them far more gracefully). His example is laughable:

I believe strongly typed languages yield better encapsulated code because requirements are explicitly presented up front. To illustrate this, lets make believe. Let's pretend we have a method called foo:

Public Function Foo()

End Function

All we know about it is that it returns a numeric type. But we only know that because we ran a few tests and made a reasonable assumption. Assuming that it returns a Integer type we go on to code. At some point we end up using the value from Foo in another call:

FooBarProcessing(VarFromFoo)

We run it and everything works great. Days go by and everybody's happy. But unexpectedly, after our code was released, it breaks.

What happened?

After an hour of debugging we find Foo returned a value of 100,000. FooBarProcessing only works with a 2 byte integer. Something we didn't know at compile time. We only found this out because we obtained the original source code and traced it through. So much for encapsulation.

That break isn't due to dynamic typing, but due to a lousy type system - one that every C based language shares, btw - in this case, his "fix" is to declare the variable an int (likely a 32 bit value, but that's an implementation detail left floating around to bite the developer). Now, let's examine that in Smalltalk - where the number would not be constrained to a range (unless there was a domain reason for doing so, in which case we would enforce that via code). In Smalltalk, there is no such thing as overflow for integers. So yeah, this is a typing problem - it's a problem with the typing system that Richard thinks is saving the day.

Mark Derricutt extolls the virtues of full closures - and his post gets picked up by Sys-Con, an online Java 'zine.

Binkley says that you can do hot (runtime) patching in Java now - from this article we get the following:

But ah-hah! We do, we can use a different implementation of FunctionTable which stores the method body as a String in Derby and uses BeanShell (or Janino!) to invoke it. So a method invocation is completely configurable at runtime! Not deploy time, runtime. If you find a bug, you can fix it without a redeploy.

Uh, yeah. Go read the whole post to see just how simple it really is. meanwhile, all I have to do in Smalltalk is load in a new version of my code, and I'm done.

Rich is blogging again, and has an update on Smalltalk Doc. It is in preview for VW 7.3 (which will be out any build now :) ). It's not so much that ST Doc is "not a priority" as Rich says; it's more that it's one of many priorities we have. So many priorities, so little time...

Why do some languages catch on while others don't? It's all about facial hair. I guess Alan Kay needed a beard, or a bigger mustache...

A common need in any application is Windows that cooperate - child windows that close when their parent closes, etc. It turns out that it's pretty easy to set that up in VisualWorks - I've needed it in BottomFeeder, and I'm sure that most Cincom Smalltalk developers need this capability at some point. So how do you do it? Let's start with the 'main application window' - add this to the #postBuildWithMethod:

postBuildWith: bldr
	super postBuildWith: bldr.
	bldr window 
		application: self;
		beMaster.

That sets the 'main application' window up as a master - child windows will receive most of the same window events and follow them. Now you need to set up the child window. Let's say that it opens up from some method in the main application:

openSomeTool
	| tool |
	tool := SomeTool new.
	toolBuilder := tool allButOpenInterface: #windowSpec.
	toolBuilder
		window application: self;
		beSlave.
	tool finallyOpen.

What's going on here is that you are registering a specific window as the 'master', and another as the 'slave' - which means that a set of events received by the master window will be passed along. If you want events passed equally, then use #bePartner to all involved windows.

It turns out that you can customize the set of events you care about - a quick look at #beMaster and #beSlave in class ApplicationModel shows this:

beMaster
	"Send windowState events to other ApplicationWindows that have the same 
	application as us. Effectively the dual of beSlave."

	self sendWindowEvents: #(#close #collapse #expand ); receiveWindowEvents: #(#expand )

beSlave
	"Receive windowState events from some other ApplicationWindow that has the 
	same application as us. Effectively the dual of beMaster."

	self receiveWindowEvents: #(#close #collapse #expand ); sendWindowEvents: #(#expand )

You could easily add your own custom versions of #beMaster and #beSlave - and either expand or contract the list of window events. You can also use #sendWindowEvents: and #receiveWindowEvents: to tailor the event stream. It's all pretty easy to manage.

The script tool has made it easier for me to follow a bunch of comics that I like - I can easily scrape any of the feeds on the comics.com site into a local RSS file that I can subscribe to. Here's the script I use:

contentBlock := [:builder :chunk |
	| lnk |
	lnk := 'http://www.comics.com', chunk.
	builder link: lnk.
	builder title: 'Monty: ', Date today printString.
	builder description: '<img src="', lnk, '">'.
	builder pubDate: Timestamp now].

out := 'monty.xml' asFilename writeStream.
writer := RSS20_SAXWriter new output: out.
writer prolog.
writer startRSS.
writer startChannel.
writer title: 'For Better, For Worse'.
writer link: 'http://www.comics.com/comics/monty/index.html'.
writer description: 'Monty'.
writer pubDate: Timestamp now.
writer startItem.
writer title: 'Monty: ', Date today printString.
content := 'http://www.comics.com/comics/monty/index.html' asURI valueStream contents.
str := content readStream.
str throughAll: '<IMG SRC="/comics/monty'.
str upToAll: '<IMG SRC="/comics/monty'.
str throughAll: 'IMG SRC="'.
rest := str upToAll: '"'.
contentBlock value: writer value: rest.
writer endItem.
writer endChannel.
writer endRSS.
out close.

That script works for any of the comics on that site; all you have to do is change the titles and urls. I'm now subscribing to a bunch of the things there.

Yeah, this sounds like a plan:

The way the Internet was built might be part of the problem, he said. Its open architecture allows Web surfing, but that openness makes the system vulnerable, Mr. Tenet said. Access to networks like the World Wide Web might need to be limited to those who can show they take security seriously, he said. Mr. Tenet called for industry to lead the way by "establishing and enforcing" security standards. Products need to be delivered to government and private-sector customers "with a new level of security and risk management already built in."

Hmm - will someone let Mr. Tenet know that the net isn't solely a US thing? Could someone else explain why a decentralized system is inherently more secure than the centrally monitored system he sounds like he'd prefer? Sheesh.

Looks like IBM wants out of the PC business:

IBM, whose first PC in 1981 moved personal computing out of the hobby shop and into the corporate and consumer mainstream, has put the business up for sale, people close to the negotiations said Thursday.

While IBM long ago ceded the lead in the personal computer market to Dell and Hewlett-Packard so it could focus instead on the more lucrative corporate server and computer services business, a sale would nonetheless bring the end of an era in an industry that it helped invent. The sale, likely to be in the $1 billion to $2 billion range, is expected to include the entire range of desktop, laptop and notebook computers made by IBM.

Things get bought and sold between businesses all the time (think Lexmark) - but I have to wonder about one thing - what does this mean for the Thinkpad line? I've used a lot of laptops over the years, and the Thinkpad has been one of the nicest I've seen.

The Cincom Smalltalk Worldwide User's Conference starts next Tuesday, December 7. We'll be hosting Smalltalkers from various countries in Europe, the US, Canada, and South Africa. Come here user stories like this one from Peter Fichtner. We'll see you there!

Colin Putney has a good roundup on how Smalltalk is evolving.

I see that Sony - a company I usually think of as "getting" marketing - has come down firmly on the side of stupidity. While Ken Jennings was racking up victories on Jeopardy, lots of people were getting interested. It seems that Jason Kottke was just generating too much postive interest for the legal beagles at Sony. Apparently, he posted some spoilers for the last show, and Sony went all medieval on him. Interestingly enough, the Washington Post did the same thing, and Sony didn't so much as mumble. I guess only the small targets without big lawyers matter. I'm far less enthusiastic about the PlayStation 2 than I was a few hours ago. Good job, Sony legal. That sound you're hearing is a prospect sauntering off.

I guess Dave doesn't realize how many huge sites run on things like PHP, Perl and Smalltalk:

I've been getting lots of mail about the programming project described below. My challenge will be to try to organize the energy to actually create the needed software. People ask if C# or Java would be okay, and the answer is, of course. I basically meant "compiled code" as opposed to interpreted code. Static instead of dynamic. We have to cut to the metal. I also need to write up a spec that explains what the software does. Anyway, let's give it a couple of days to gestate. In the meantime you might start writing code. ";->"

I've uploaded a new development build of BottomFeeder - all the changes are also available via the normal upgrade route (assuming you look at the dev stream). What's the change? Michael Lucas-Smith let me know about a change that would make the html display faster - they haven't turned it on ay SwS because it's not yet compatible with the editing of XML that they are concentrating on. For my purposes in BottomFeeder, that's irrelevant though. Have a look - you should see much better responsiveness

Here's an online video showcasing Self. Interesting, and illustrates the benefits of dynamic systems nicely

Now here's some honest marketing for you - Scoble explains why he's not moving to MSN Spaces. Microsoft pushed out an announcement on their new blogging service (competing with Google) last night. Here's my biggest question on this sort of thing - MS and Google are supporting free blog hosting "for the masses" now. What's the revenue model here? Advertising I suppose... but on low volume blogs (which most are) - is that enough? Here's another thought - what's the upside for MS and Google in giving away space and bandwidth? What am I more likely to buy from them as a result? Just curious.

Darren Oakey makes a common mistake when discussing typing:

He's got a reasonably good technique - every function has a test that passes nulls to it - so very quickly you understand how your app deals with nulls. However, I'm not sure I'm buying in. This is like the smalltalk type arguments on weak typing compared to strong typing. Sure, we can rely on tests to ensure the robustness of the code - but there's a lot in me that says that's not the answer - I'd rather rely on the compiler if I can!

One problem - Smalltalk is not weakly typed. It's just not manifestly typed. C is manifestly typed and weakly typed.

It's not for everyone, but I've been weeding out some of the partial content feeds - the ones that I would like to read, but tend to blitz by due to the teaser content. I've now got 4 scripts that create local full content feeds in order to replace the partial content feeds provided by the authors. I suppose this isn't the sort of thing that makes them happy; after all, it means that I'll be completely avoiding their html page (and thus, their sponsors). On the other hand, it's making my reading experience much more pleasant. If you're interested, see this wiki page for details and a short example script.

While explaining why he blogs, Dave Winer explains something interesting about product development:

When I started blogging it was mostly to get a bunch of stuff off my plate, ideas I couldn't do anything with, things I wanted even if I couldn't create them. I hoped other people would read this stuff and someone would create what I wanted, and therefore increase happiness. Over the years I learned that this very rarely happens. People really want to come up with the ideas, even more than they want to be successful.

This sort of thing is very noticeable in open source projects - the developers will work on what interests them, regardless of what kinds of polish might be required to "finish" the product. This befalls commercial products as well; it's quite common to run across areas of a product that fall victim to the "80% rule" - 80% (the interesting aspects) of some feature get built, while the remaining 20% of "spit and polish" never happen - because it's considered uninteresting by the developers.

I've come to the conclusion that only a real user base motivates people to "finish" products. And even with a real user base, the less income that is tied to the work, the less likely it is to ever get done...

The Cincom Smalltalk Worldwide User's Conference is rapidly approaching - don't miss this chance to hear about our future plans directly from engineering! We also have outside experts coming in to talk - like Joseph Pelrine on SCRUM. We'll get started in Frankfurt, Germany next Tuesday - see you there!

All I need now is Pooh flying Piglet as a kite. The wind is really blowing this morning - I just chased my trash cans down the street.

Ziggy makes some comments about version control, and exhibits some odd ideas about Smalltalk in the process. His prime objection makes some sense - "everyone" else uses file based systems (like CVS) for version control, and Smalltalk's failure to "get with the program" holds it back. There's some truth to that - but there are also some very good reasons why most Smalltalk systems don't fall back to CVS style systems.

It's not that it can't be done, or hasn't been done - VSE used PVCS as a backend (even though it hid it pretty well). ObjectStudio users tend to use SourceSafe or other Windows version control systems. The real disconnect comes with systems like VisualWorks, Squeak, or VisualAge Smalltalk - all classic image-based Smalltalk systems. Avi explains the issues well here:

The thing is, when you move away from code and into arbitrary data files, most of the useful features of *any* version control system go away. How well does the darcs theory of patches work on images? Can CVS insert its conflict markers into a Word file? And how many times do you need to cherry pick changes from a patch someone committed to an obscure branch of that project timeline? The most you usually need or are able to do is to associate a specific revision of a binary file with a specific version of the code, and it would be trivial to extend Monticello [VCS Avi has worked on] to do that if the need came up

Here's the commentary that I wondered about in Ziggy's post:

Smalltalk, on the other hand, doesn't integrate well with the version control systems we have all grown to love (or at least tolerate). Avi Bryant points out that these problems don't really surface for Smalltalk developers, because the Smalltalk VM can keep track of every change, and tag each change with more metadata than SCM tools can possibly capture.

Sorry, but I don't buy it. I call this "Smalltalk Disease" -- the arrogant tendency for Smalltalkers to dismiss a problem because they can mutate a Smalltalk image to nearly eliminate it. (And, if they haven't done it themselves, or the necessary features aren't present in your VM, then at least someone has done elsewhere, presumably in some production environment.)

OK. So you can upgrade your VM to handle versioning and merging of Smalltalk methods. Fine.

What happens when you want to version something else, like, data files, documents, or images? I guess CVS/Subversion/darcs/etc. aren't so useless after all....

Hmm - it's not a VM level thing - the code and parse trees are all available at the Smalltalk level - which is a large part of what makes them easy to deal with. The common Smalltalk VCS systems - ENVY, Store, Monticello - all deal with code artifacts at that level, and use some kind of back end (typically a database, although Monticello supports multiple back ends) to store source code. One could posit a CVS style back end, and I've seen it done - our partner Heeg has plugged in such systems for customers on a consulting basis. As to external artifacts? As Avi says, it's not that big a deal to extend that way, and - in fact - VW 7.3 (which will be released very soon) can handle external artifacts. It's become a big deal because of things like the Web Toolkit, where there are ssp files (and image files, etc) that make up part of the "whole system".

There are issues with the various Smalltalk VCS systems - ENVY doesn't handle merges well, Store has had problems with the nature of its db schema - and, as Avi mentioned in his post, Monticello is not perfect either. The point is, the various file based systems aren't perfect either, and they simply don't mesh well with image-based development.

Update: Colin Putney comments here, and Patrick Logan has some thoughts here. Ziggy makes follow up points over here

d2r links to Don Park's post about finding conversations. As it happens, BottomFeeder already does that. There's an option in settings (Do Item Cross-referencing) - if you turn that on, then items you subscribe to that are referenced elsewhere in your subscribed content will get flagged. I did that about a year ago, I think - it was a user request.

Sriram Krishnan calls it "The Tyranny of the Geeks"; you could also call it the triumph of the overly anal retentive. Sriram has some good, solid points in the linked post - I especially liked his takes on edit and continue, dynamic languages, and RSS aggregators. Go have a look.

I've mentioned the plugin that lets you write scraping scripts a few times recently - I've just posted a wiki page that goes through the basics - and links to a few example scripts. The main change to the script tools since Bob did the initial work is the integration of a few SAX drivers. If you look at the example scripts, you'll see that having the SAX drivers makes it a lot easier to produce scripts. If you can get at the source of a web page, know a little bit about Smalltalk streams, and can follow the examples, you should be able to produce scripts. I'd suggest creating them in the development environment - all you really need for that is the script tool and vwnc - you don't need to create a BottomFeeder development image to play with this stuff

Ryan Lowe is talking about comment spam issues. I've got a far simpler solution in place on this blog server, and it seems to be working. Now right off, I don't get hit a lot - I'm not running one of the common blog servers, so all my http api's are different. That helps enormously. I've been surprised that the wfw:comments api hasn't been abused more, but what do I know? In any case, what's the thing about most comment spam? Lots (and lots) of links. I simply scan all inbound comments, and archive off (without posting) any comments that have "too many" hrefs (never mind how many that is :) ). It's simple, but effective.

Slashdot is reporting that a trailer is up for the ROTK Extended edition. Apparently, 50 additional minutes of footage are coming in. I know what I want for Christmas :)

Greg Reinacker has a post up detailing some of the requirements he has for new employees. The post is actually a short explanation of nearly everything that's wrong with IT hiring (and by extension, development). Go ahead and look at his list - do you see a description of the problem domain anywhere ? Nope, just a set of Windows (and C++) specific technical jargon you have to hurdle to get past the bar. One thing I've learned over the years is that domain specific knowledge is far, far more valuable than technical trivia - if you hire a competent person, the technical stuff can be learned pretty quickly. Hiring managers unwittingly eliminate a lot of great potential hires by making lists like Greg's.