Smalltalk Tidbits, Industry Rants

Scoble links to some advice for web developers and XP SP2. Looks like some of the security mods are going to require some tightening...

Every so often, I run across a customer using an older version of Cincom Smalltalk - typically VW users with VW 2.5.x. A question that seems to come up all the time is "why should I upgrade?" Now, I understand that it's a fairly big move (2.5 was released in 1995, so an upgrade involves moving across 9 years of active development). At the same time though, it's an odd sort of question - how many people are sticking with the 1.02 version of Java, for instance? Seems to me that it's the same sort of thing.

Oops - looks like Schwartz may have spoken too soon about open sourcing Solaris. He was reported as saying:

While speaking at the SunNetwork conference in Shanghai, China, Schwartz commented: "I don't want to say when that will happen... But make no mistake - we will open source Solaris."

Only to have McNealy say this yesterday:

At a news conference during the public sector technology showcase FOSE 2004, McNealy said he couldn't understand how open sourcing Java would solve anything.

I've certainly inserted my foot firmly in my mouth before, but you would have thought that Schwartz would have cleared something that big before getting slapped down....

At least in VisualWorks (part of Cincom Smalltalk), it's pretty straightforward. There are two simple paths for updating:

• File in new code. A file-out is simply code exported from a Smalltalk image - in a format that will allow it to be imported into another image. This is how I patch this server in place - I follow the following steps:
• Test my changes in a local (my office Linux box) image
• Once they work, I file out the changes. How do I know what's changed? In VW, any package has a change set - which holds all the changes since the last time that package was published. I just export that
• FTP the file-out to the server
• Using an interface I left open for myself (web based), I login and tell the server to load in one or more patches.

What does the server do? It executes code like this:

'someCodeFile.st' asFilename fileIn.

That's it. The nifty thing is what happens - not only is the new code compiled and loaded, but any shape changes required of existing objects (i.e., changes in the instance variables) just happen. I don't need to jump through a bunch of hoops; it all just works.

I take a slightly different tack with BottomFeeder. With that application, updates are delivered via HTTP download, as parcels. These parcels are either loaded at startup or at the time of download - and they replace the older version of the parcel that is in memory. Again, I don't need to worry about the details of shape changes - it all just works. Here's the code snippet that will load a parcel, and handle the warning exception that may notify me (if I'm loading over existing code:

[Parcel quietlyLoadParcelFrom: file]
	on: DuplicateBindingsError
	do: [:ex | ex resume].

And again, that's it. The parcel loads up, fixes itself into the system, and everything is updated. No need for custom class loaders. No need to write complex rules for exporting object state and then restoring it. It just works

This should have made the cut for the 3.5 release, but I forgot that I'd done the work for it. The Blog Tool now has spell check support - but you may not always want it on. So I just grabbed the forgotten code that adds a setting to toggle it on/off. It's in the latest update for 3.5 (both dev and normal).

David Anderson http://www.agilemanagement.net/Articles/Weblog/WorldClassVelocity.html points out that no one believes the productivity claims of XP/TDD advocates:

So is it any wonder, when I tell people (indeed, show them with metrics) that agile development team A is 5 times more productive than team B who in turn are twice as fast as team C at another location, that people don't believe me? After all, these programmers are only human - right? How can it be possible to go 10 times faster? Just what kind of drugs do you take to make that possible? Is it time we banned these prescriptions with names like FDD or TDD or XP in order to level the playing field for everyone else? Perhaps some police raids to dig out the story cards and some spy equipment to detect morning stand up meetings? It is disgusting that some developers can go so quickly. It has to be stopped!

No one believes the relevant numbers about Smalltalk vs curly brace languages either. I guess believing the claims would cause heads to explode and world views to be rearranged. Simpler to just be Vizzini, and shout "inconceivable!"

Damn my penchant for bad movies! There's going to be an X-Files 2 movie. The only suspense left: Can it make less sense than the series finale and first movie did?

I'm not the only one who wondered about the "24" finale. Follow the link (there are spoilers) if you want to see a good list of the dumb, dumb things wrong with the ending. The only thing that went the way it should have was the final decision of President Palmer....

Not having a Mac, it's been problematic for me to set up a decent installation for the OS 8/9 platform. OS X is easier; once it was explained to me, I was able to set up the proper directory structure without access to a Mac. VisualWorks (the tool I use to build BottomFeeder) is able to produce a single executable file for OS 8/9 - I'd need a Mac to do that though. So, these directions should work; I found them from an intrepid Mac user on the net:

Installing BottomFeeder on Mac OS 8/9

Do the following to download and install BottomFeeder on a Mac OS X system:

• Download BottomFeeder from the BottomFeeder Home Page, choosing the Mac OS OS 8/9 version.
• Uncompress the folder onto your desktop. The zipped package does not include a straightforward installer; it has, instead, the following files:
• bottomFeeder - the executable file
• bottomFeeder.im - an image file.
• two Lib files: NetManage WinSock Lib and StdCLib
• plus some folders that will be used once the app installs.
• Drop the icons for NetManage, StdLibC and bottomfeeder on Stuffit! Expander. You will end up with the NetManage and StdLibC icons looking like puzzle pieces and bottomfeeder will expand to an icon called "visual". Visual will have its creator already set to HPS7. To get the bottomfeeder.im icon to highlight the "visual" icon upon drag, run ResEdit 2.1.3 and change the creator for bottomfeeder.im to HPS7.

After that, BottomFeeder should run. Just drop bottomfeeder.im on bottomfeeder.

This is one of the times that I'm glad I didn't volunteer to chaperone my daughter's girl scout trip - to Hershey Park, PA. The forecast for the day there was a high of 62, and buckets of rain. I've been to Disney multiple times in dodgy weather, and it's never a great experience - cold and wet is just not a great way to spend an afternoon, IMHO. Of course, my daughter didn't mind - at 10, she was just looking forward to spending the day and evening at Hershey with her friends. Ah, youth :)

When I read movie reviews, I often wonder about some of the things that I read. Take this paragraph in a story about how scary the new "Harry Potter" flick is:

A description of some "scary moments" deepens her conviction. The transformation of a beloved character into a werewolf? "That's just one of the really hot buttons," she says: Physical transformations and monsters are especially frightening to children under 7 or 8, who can't distinguish between imaginary creatures and real ones. The fact that it's a sympathetic character who's suddenly howling and baring his teeth only makes it more disturbing.

Now, this comes from a mother (who admits that she hasn't seen the film) of some kids that age - but still, it made me wonder if she had ever met any kids that age. My daughter was in that range when the first Potter flick came out, and was that age when "Fellowship of the Ring" came out. She had no trouble - either with the books or with the film - separating reality from fiction. Neither did any of her friends, many of whom are absolute Harry Potter fanatics.

I'm sure that there are kids who shouldn't see these films - but the point is, you have to make a judgement call based on knowing your kids. Making a blanket statement that kids that age "can't distinguish between imaginary creatures and real ones" is just silly. It reminds me of the many newspaper articles I stumble across from child psychologists... nearly every time I read one, I wonder if the so called "experts" being quoted have ever met any actual children.

I guess I need to buy the soundtrack to "The Return of the King" - I kind myself scanning the beginning of the credits to hear the theme song, sung by Annie Lennox. There's something haunting about that song. It's used to very good effect in the film as well - if you pay close attention to the scene - just before the Rohirrim arrive - where Gandalf is telling Pippin not to fear death - you'll notice that Jackson used that song. This is one of the touches that I really, really like about these movies. The other one that still sticks in my mind is from the first movie. As the Fellowship walks through Moria, there's a point where Gandalf says that he'll risk some light - and he then introduces them to the heart of the Dwarrowdelf. The music that was playing then was perfect - somehow, it captured the sense of glory and loss perfectly. That's exactly the way the ROTK theme song is for me - it seems to capture the triumph and the loss of the victory in the War of the Ring perfectly. If there's another movie out there that has done the music this well, I can't think of it.

I don't normally talk about news or current events here, but I can't really let the passing of President Reagan go by unremarked. He was elected as I entered college, so my passage into adulthood coincided with his time in office, and with my first opportunity to vote in presidential elections. I admired him then, and I admire him now. I hope that he finds the sort of peace that the last ten years of Alzeimers took from him.

I've noticed that the Tablet PC is getting a lot of hype in some parts of the blogosphere. I was talking about this with a friend the other day, and he brought up something that I hadn't thought of - damage to the screen. What do I mean by that? Well, next time you are at Target (or any of the stores that have electronic credit card signing now), have a look at the screen you sign on. Notice how scratched up it is? Of course, no one is really caring for those screens, or trying to prevent scratching. Still - under constant stylus use, they take a lot of damage. Makes me wonder just what a Tablet PC screen looks like after a few months of active use. Anyone have any real experience with this? Admittedly, my thoughts here are only an educated guess based on similar technology in use....

This week, I'll be heading to Cincinnati for planning meetings - I'm meeting with the engineering team leads, the engineering manager, as well as parts of sales and marketing. Our goal is to take stock of where we are, and to look ahead to where we should be going.

This is actually more difficult now than it has been. Why? Well, to be honest, guiding the direction of the product was very, very easy from 2000 until the VW 7 release. With the chaos that had ensued in the endgame of ParcPlace/ObjectShare's life, the product had stagnated. As a sales engineer, I was always being told what the product lacked, and what we needed to to with it. That actually made life pretty simple for me when I became Product Manager - there was so much to do, and I already had a very clear notion of what things were lacking.

Now, we aren't done with all of that - Pollock and GLORP, for instance are still under development, and there are numerous tools/presentation issues to deal with. Still, most of the things in that area are moving in the right direction already for VisualWorks, and with ObjectStudio, we have decided on a tighter integration with .NET and the CLR as the way to go. These things are all in motion, and will be bearing fruit over the next few months and years.

That leaves business direction and general strategy. The technical issues are no longer the main things we have to worry about; we've caught up after the PPS stagnation, and, to my mind, gotten into a very good place vis-a-vis Java and .NET from a technical perspective. Unfortunately, the technical perspective is really not the biggest thing facing us. We are experiencing steady growth, and Smalltalk is a profitable business for Cincom - but we would very much like to make it more than that. That's what the meetings we are having are going to be about. I don't expect any grandiose changes or directions in the short term, but we are going to start talking about what should happen next.

As always, I'm open to suggestions.

Staffan Malmgren explains how the Stockholm Marathon was, kilometer by kilometer. Makes me wish I'd written down my thoughts on the two marathons I ran back in my twenties; my best time back then was 2:50.

In the comments to this post I got some good feedback:

My opinion, for whatever it's worth, is that the Smalltalk libraries have gotten pretty chaotic, not the base libraries, but all the add-ons. It's hard to know and to find what's available. This is partially a matter of organization, but even more a matter of missing documentation and the lack of appropriate documentation tools, especially indexing and searching tools.

Further along these lines, there are real gems that need to see the light of day. For example, a number of packages included in BottomFeeder would be of great help to customers if they were better formalized and documented.

That leads to a question - what packages that in the goodies are people finding useful? What packages in BottomFeeder would be worth generalizing?

Ed Foster explains why so many email newsletters get classified as spam.

How many teams have this guy?

I just noticed that this blog is the Feedster feed of the day. That's neat. I've been a happy user of Feedster for quite some time now - BottomFeeder was one of the first aggregators to support it. Half the reason I did that was for myself, actually - I have a number of feedster search feeds that I track in Bf.

One of the really nice things about Smalltalk is the ability to replace any method in any class - there's no concept of "final" or sealed". Typically, it's better to subclass an existing class and add the new behavior there (or use delegation). However, that's not always practical. For instance, in BottomFeeder, I need to do HTTP queries (to get the XML files that make up feeds). VisualWorks has HTTP client libraries, and the libraries have an easy to use API. I soon realized that I was going to have to create a wrapper library, because it wasn't going to be sufficient to do:

response := HttpClient new get: 'http://www.somesite.com/feed.xml'.

There were a lot of things I needed to deal with:

• Exceptions (Network errors, etc)
• Permanent redirection (update the url silently)
• Cookies
• Authentication (and keeping track of username/password)
• Conditional-Get
• Compressed content

and tons of other small details. The HTTP client library in VW handles some of this, and wrapping it to provide the rest at an application level was easy enough. There came a point where I ran into a small problem though - I also use my wrapper library to handle POSTS from the blog tool that comes with BottomFeeder. Under some circumstances, an exception would be raised, and I'd have no access to the original HTTP response that was received - it had gotten nulled out by the library by the time my code got control again. Now, it's arguable that it shouldn't work that way, but hey - no library is perfect. Most developers aren't the Product Manager for the tool they end up using, so - unlike me - they can't go straight to engineering and ask questions. They have to go through support and maybe get a fix, someday. The nice thing about Smalltalk is that you can track down the issue yourself and deal with it in the meantime. I've removed numerous temporary hacks of this sort as the engineering team has dealt with them. Here's what I did in this case:

In the class HttpClient, there's a method #getResponse:. That's where the response is received from the server, before some post processing (and some of the exceptions raised here can result in the original response not being returned). Easy enough; I overrode the method, storing my version of it in an extension package that is part of my HTTP wrapper library. The part I overrode looks like this:

^[stream := self getResponseStream.  
	resp := request headerOnly
		ifTrue: [HttpResponse readHeaderFrom: stream ]
		ifFalse: 	[HttpResponse readFrom: stream.].
	 resp log. 
	self originalResponse: resp.
	(resp connection notNil and: [resp isConnectionClose ]) 
		ifTrue: [ self close]. 
	 HttpException handleResponse: resp
	]

The only addition is the #originalResponse: call. I also added an instance variable to the class so that I could store that information somewhere. My wrapper library looks there in cases where it receives a nil response, so that it can better report the actual problem that was encountered. Was this critical? Maybe not - I suppose I could have gone with just reporting a generic failure and been done with it. The point is, I didn't have to - I had the option of fixing what I perceived to be a bug. Why else is that useful? Well, it's not always the case that things you report to support get dealt with the way you would like. Some are put on the back burner, some are rejected as "not bugs". The point is, being able to muck with all the code gives you the ability to route around that issue. Support doesn't believe you? Fine, you can fix it yourself. Support says it's a low priority? See the above. Support agrees that it's important, and says that it will be fixed in the next release? See the above.

With Smalltalk, your level of control over the situation is just higher. Now, do you want to start overriding the class libraries willy nilly? Of course not. This counts as a "power tool" - it's a really good and useful thing to have, but you want to be careful when you pull it off the shelf. The nice thing is, with Smalltalk, it's on the shelf, ready to be picked up at need

Advantage, or "blowing in the wind?" - Alan Trammel, manager of the Tigers, claims that the Twins are changing the flow direction of the A/C blowers based on who's at bat:

"We almost made a comeback then and had the issue of whether or not those blowers were on," Trammell said. "It seemed like those air conditioners were blowing straight in our face in the top of the ninth. There was definitely a difference in the air conditioner in the ninth inning. There was no question that there was some air blowing in the ninth inning."

The Tigers said a flag in the left-field upper deck was flapping as though it were windy Sunday, and they saw a piece of tape stuck to a vent behind home plate that was fluttering while the Twins were hitting, implying that the Twins -- who scored all their runs on three homers -- were being aided on offense and defense.

The Twins, of course, deny it:

"It borders on the ridiculous and the absurd," Twins vice president of operations Matt Hoy said. "It's a romantic concept that we can materially affect the flight of the ball, but it's just not possible."

Ah, baseball controversies :)

You've likely heard us Smalltalkers saying how extensible Smalltalk is. Well, have a look at Travis' latest post and see what we mean by that.

Check out the BottomFeeder Review in PC World Magazine.

I'll be in planning meetings most of the next three days; I expect that blogging will be somewhat light (unless I get incredibly bored, which is always a possibility in a 3 day set of meetings). Part of this will be talking about "where we want to be" in 2-5 years - and a large part of that answer needs to come from our development community.

The MacInTouch site covers the release of Bf 3.5.

I've said this before, as have plenty of other people I know. But over at Strongly Typed, there's a great explanation of why data entry applications suffer when people are moved from text oriented screen apps to GUI apps (web or client/server):

Have you ever watched an experienced heads down data entry clerk do their job? With a green screen system they rarely look at the keyboard and in most cases ignore the screen. They are responding to audible feed back (key press clicks, console beeps, etc) with their eyes focused on the data to be input. They remember key sequences (press 1, A, down arrow 2 times, F2 to save) to navigate. A mental model of the screens become ingrained in theirs head. They SEE the application in their head and that vision is updated real-time. They know the system because it's predictable.

In the cases I mentioned above the primary source for the complaints was the mouse. It's unpredictable. It's next to impossible to remember the cursor's position at anytime - even worse, to know the exact movement. The mouse requires visual contact with the screen, an impediment for heads down data entry.

As a developer I used to think I was empowering the users by creating flexible user interfaces. Multi window applications with buttons and icons; to take advantage of a modern GUI was to deliver the best we had to offer. When the complaints rolled in about the entry screens I dismissed them "growing pains".

It took me some time to realize their dilemma. They WERE better off with the original entry screens.

Something to think about....

If you don''t think that software patents are out of control, have a look at this - Microsoft has patented the notion of an auto-generated to do list. Better not get too fancy with those grocery lists...

Cyrus wants an image:

All I am looking for here is an API that allows me to create to save the state of execution at any point and then return to that in the future. If fibers aren't the way to do that, then give me something that will. Make it a nice supported API written by people who know the runtime well and understand all the pesky issues involved so that I won't run into a situation where 3 days before shipping a product some heinous bug becomes apparent.

Saving the state of a running system... Hmmm.. Where have I seen that feature before?

Still in CicadaVille:

So I came to Cincinnati this week for a set of planning meetings - leaving Maryland, which is currently filled with 17 year Cicadas. Imagine my surprise to discover that this brood comes up here as well - and in huge numbers! There were hundreds of the little buggers buzzing around the front wall of the Cincom building (all glass).

Adele Goldberg's and Kenny Rubin's book has gotten a new plug - good review and explanation of the subject matter.

It turns out that there is a silly (but annoying) bug in BottomFeeder 3.5. On the technical side, I transitioned from change/update to trigger events (in terms of event notification). However, in the process of doing that, I dropped one event by the wayside accidentally. As it happens, that was the event that toggles menus/toobars on a change from online to offline (or vice versa). The easiest way to spot that bug is to toggle the online state and watch how the toolbar doesn't change back. I've uploaded an update to both the normal upgrade path and the dev upgrade path to fix this; you'll need to restart in order to see this take effect. Of course, if you know how to dive into the running Bf application, you can just pop up an inspector, and execute this:

	| viewer |
	viewer := RSS.RSSFeedViewer allInstances first.
	viewer feedManager when: #onlineStatusChange: send: #onlineStatusChange: to: self.
	viewer onlineStatusChange: true.

At which point, it will work properly.

I'm working on two new things for BottomFeeder:

• A synthetic GUID for all items, whether they have one or not
• A Newspaper view mode at the feed level

The first one is a little technical. Atom items have an ID, and (most) RSS 2.0 items have a guid. These items are (in theory) unique enough to compare across feeds (although they likely shouldn't be trusted outside a given feed). In any event, not all items have them, so I've taken to lazily generating them using an md5 hash. I need to do some testing on this before I roll it out; I don't want to have the current "is it new/old" code cause issues for users, as it has in the past.

The other thing is a new view mode at the feed level (possibly at the folder level as well). The idea here is simple - say you turn this on (either globally, or for a given feed). When you select a feed, all of the relevant items get displayed in the html view as a set of "Newspaper stories". The relevant items would be either

• All new
• If no new, all today's

This is a view mode that some of the other aggregators out there support, so I've decided that it's a good idea to add. It's basically done (at least for the purposes of the dev stream, even though I haven't pushed it yet) - but I'm not going to add it as a non-dev feature until the 3.6 release. Any thoughts or comments are welcome.

Brad Abrams talks about the (supposed) conflict between developer productivity and performance:

Well, today I had a heated discussion with some of the smartest people on the CLR about the balance between developer productivity and performance.  The debate goes something like this: 

Me: Feature X will make developers more productive, so we should do it!
Other Guy: Feature X will make developers apps so slow it will not matter, they will use something else...

Anyone want to take bets on the liklihood that "Other Guy" actually tested anything out and profiled it? Maybe the feature in question would be too expensive - but the all too common approach to this issue is argument by assertion

One of Sun's bloggers has an eye for the obvious:

Where this starts to fall apart is with the .NET and Mono libraries. The Java API writers have always been very careful not to introduce an API which does not make sense on all platforms. This makes Java extremely portable at the cost of not being able to do native system programming in pure Java. With .NET, Microsoft went ahead and wrote all kinds of APIs for accessing the registry, accessing COM objects, changing NTFS file permissions, and other very windows specific tasks. In my mind, this immediately eliminates .NET or Mono from ever being a purely system independent platform.

In other news, I hear that the sun rises in the east, and that politicians in opposing parties often argue....

For the development stream, I've released a newspaper view for BottomFeeder. How does this work? At the moment, there are 2 settings - one feed level, one global. If you set the global, then you'll get the newspaper view whenever you select a feed in the tree. If you set the feed level setting, you'll get newspaper view when selecting that feed. What's that do?

• An HTML summary is created for:
• All new items for that feed
• If there are no new items, all today's items for that feed

The summary will show the title, the date the item came in, the category (if any) it has set, and the conten in a page. Each item will be set into this page view, and the result shown in a zoomed HTML view. If you need to get back to the list of items, you simply toggle off zoom mode and select any item of interest. This is my first cut at this, so any and all feedback is welcome.

With some feedback from a few early testers, I've made a few adjustments:

• There are global and feed level settings for
• Having newspaper mode on
• Showing full content for items in newspaper mode, or just a short summary
• I've modified the way the items are displayed to provide a little more information
• If you have the global newspaper setting on, and you select a folder, you'll get newspaper mode for all feeds in that folder.

This stuff is only available in the dev stream; it's going to require documentation updates, and, in my opinion, more shakeout. It should be a really nice addition to the next release of BottomFeeder.

I've got a few search feeds set up in BottomFeeder, and every so often it leads me to a real gem. Consider this bit of silliness, for example:

Second, he introduces us to a cool reflection tool called Lutz Roeder's .NET Reflector. However, he goes and says, "The .NET Framework introduced the world to the concept of reflection which can be used to examine any .NET-based code, whether it is a single class or an entire assembly." Are you joking? Java has had the Reflection API for years. They were the innovators there.

It gets better:

James also talks about the .NET build tool called NAnt and the .NET based unit testing tool called NUnit and doesn't even mention the original Java-based projects these bad boys were based off, namely Ant and JUnit respectively. Quite expectedly, he does mention Microsoft's upcoming MSBuild technology (which competes on a feature basis with NAnt) which will ship with Visual Studio .NET 2005.

I hardly know where to begin with this utter lack of knowledge. I suppose I could point to this paper on reflection in Smalltalk-80 - note the 1989 date on the paper. The Java guys were the "real innovators" here, eh? I think not. And JUnit was the "original" unit testing framework? You might have a look here - page down until you see the SUnit link, and read the description. These guys remind me of some of the people I went to college with - for them, if it was north of Manhattan, it simply didn't exist (or at least, it shouldn't have :) ). An awful lot of the Java community wears the same brand of blinders, and seems to believe that everything in computer science - and in OO in particular - was invented by Sun and Gosling. Sheesh.

I'm meeting with an important customer that is visiting Cincom in Cincinnati (from France), so blogging will be light to non-existant - I'm off immediately afterwards to the airport and home. In the meantime, try and wrap your head around this post on the nature of self from Steven denBeste. It's thought provoking, to say the least...

Over on Ralph's blog, the topic of sandboxing has come up. It's a great discussion, but there's one thing I don't always agree with:

The main bad thing that could happen is that imported code could change existing code. Smalltalk makes it easy to change code. "Obect compiledMethods removeKey: #copy" will remove the copy method from class Object. It would be very bad if imported code could do this to a running application.

While blowing away methods in base classes would be bad, blowing away methods in general may not be - in BottomFeeder, an update to the application can make major changes to base application code - and sometimes to overridden methods in various libraries. It's a complex issue.

Eric Sink makes an excellent point about positioning:

If you are #2 in your category, you want to be #1, right?

Wrong.  You can't choose to be #1, but you can certainly choose to be #3 or #4.  The worst thing you can do is to try and beat the #1 player at his own game.  Instead, realize that not everyone in the market wants to play that game.  Offer those people an alternative.

Me-too-itis won't ever widen your market. You need to give people a positive reason to look at you, not a laundry list of reasons that point out how you are "just as good as" the other guy.

Matt Croydon notes that Maryland (where I live, as it happens) is rolling out WiFi at visitor centers on the highway. That's very cool.