Smalltalk Tidbits, Industry Rants

Well, when I made this post I should have sent email to Vassili first. Here's the much simpler way to accomplish the same thing:

    aPage
      when: version valueHolder
      valueSatisfies: [:v | v = #latest]
      enable: level

the first argument is a value model. Whenever it changes, the block passed as the second argument runs and the module passed as the third argument is enabled or disabled depending on whether the block returns true or false.

As usual with Vassili's designs, it's simple and makes sense.

Here's an interesting article on usability concerns. In looking at a US Air Force document from 1986 on creating good user interfaces, they discovered that most - 70% - of the guidelines were still applicable. Things haven't changed as much as we might have thought - this document was focused on the development of "green screen" mainframe applications. The key point is here:

You would be hard-pressed to find any other Air Force technical manual from 1986 that's 70% correct and relevant today. Whether for pilots, airplane engineers, or programmers, general lessons of the past might continue to apply, but the specific guidelines changed long ago.

Usability guidelines endure because they depend on human behavior, which changes very slowly, if at all. What was difficult for users twenty years ago continues to be difficult today. People can only remember so many things, and we don't get any smarter.

No matter how many spiffy we think UIs are now compared to then, the basics really haven't changed that much.

There's a new e-book out on RSS for marketers: "Unleash the Marketing and Publishing Power of RSS" by Rok Hrastnik. I was interviewed for the book - you can buy the book here:

http://rss.marketingstudies.net/

It's a pretty good summary of what RSS is and how it works, but not at the technical implementors level. This is aimed at marketing and sales folks who would like to know what the buzz about syndication is about, and how it can be used.

I just ran across the ThoughtWorks blog site - it's an aggregation of a number of people at ThoughtWorks who are blogging. Once you get to their page, have a look at the long list of people blogging - and all of them have feed links. Here's the feed link for the main site.

Darren Hobbs asks about threading strategies in Smalltalk relative to the ones he knows in Java:

For example with the latest release of Java you might use the nonblocking IO library and one thread per cpu, keeping all the cpu's maxed out without thread-switching, so your only bottleneck is available memory (and browser timeouts). Is there an idiomatic smalltalk equivalent?

My usual tactic for maximising throughput is to minimize the number of thread/processes running, and only hand off to another process when you would otherwise have blocked, for example on IO. Nonblocking IO support in java allows me to use just one thread for all an application's network IO, and keep the rest of the threads as busy as bandwidth allows. I don't know how to do this in smalltalk, nor even if I'm worrying about the right problem in smalltalk

The primary difference (at least with respect to VisualWorks) is the nature of threads in the language. In Java, threads (usually) map directly to OS level threads. That means that you have to manage them carefully; create too many and you'll just spike all available CPUs. In VisualWorks, threads are lightweight (green) threads within the context of a single heavyweight Smalltalk process. That makes them nearly free from an overhead standpoint.

In the context of something like a web server, this is especially true - the server I host the twenty Cincom Smalltalk blogs on is running the VisualWorks web application server, and handles a decent amount of traffic. Here's how things work in the server itself:

There's a listener process - this one sits on the application server's inbound port, waiting for connections. It runs at a high priority (70, where the scale in VW runs from 1 to 100). As connections come in, the server determines who (i.e., which web application) should handle each one. As soon as it determines that, it forks off a Smalltalk process at 50 to handle that connection, and then goes back to listening. This scales pretty well; we have yet to see any kind of issue in this server, and many of our customers handle much higher loads than we do.

Now, when I say "threading in Smalltalk", I have to be careful which Smalltalk I'm talking about. Cincom Smalltalk consists of VisualWorks and ObjectStudio - ObjectStudio maps Smalltalk processes to native threads. In VisualWorks, we can use native threads when spinning up an external API call - so we can make sure that database calls (for example) don't block the VM (important for a server!). Native threads have their own issues; when engineering ported Opentalk from VW to Opentalk, they ran into a few problems:

• As a developer, you have far less control over native threads than you do over green threads
• minimal ability to set priority
• if a native thread crashes, it can take down the entire system - a green thread crash can be handled easily via standard exception handling

Other Smalltalk implementations vary as well. Squeak and VisualAge are like VW - green threads for Smalltalk processes, and in VA, the ability to map an external API call to a native thread. Smalltalk MT, like ObjectStudio, maps Smalltalk processes to native threads. I'm not entirely certain what Dolphin does; I think it uses green threads. In any case, the point is that it varies by implementation.

Imagine my joy this morning when I discovered that there's another version of RSS out there. The dev stream updates for BottomFeeder already support it.

Dare Obasanjo reports that MyMSN now supports RSS and Atom - looks like users have a fair bit of control over what they can put out as well. There's another effect here as well - now that Google and MS are both supporting Atom 0.3 format, the eventual release of Atom 1.0 becomes pretty much irrelevant. This is a correction from earlier - I misread the post by Dare.

Torsten reports that Brett Taylor has written up a Seaside experience report (PDF).

If you've tried to post a comment via the web form with Safari, it's likely the case that you got a silent failure. I added a comment throttle awhile back to help prevent spam - the trouble is, it looks like a submit from Safari results in the server getting 2 POSTs within a few seconds of each other - I have no idea why. Very, very odd...

Update: This has a perfectly good explanation that I should have thought of - the first post was a preview, the second the actual post. Both hit the server as a post, of course. When I implemented the comment throttle, I stupidly didn't take the web form preview into account. That's been addressed; it all ought to work now.

Slashdot is reporting that "Enterrpise" is on the ropes. Hmm - could that have something to do with:

• The generally lame plot-lines they've pursued? (ooh, Vulcan emotions. No one's explored that topic before)
• The non-serious way they've dealt with enemies? "Look, those guys are trying to kill us. Set phasers on Stun".
• The completely derivative nature of last season's xindi plot (look, a sneak attack on Earth using terror tactics! That couldn't possibly be our commentary on the post 9/11 world!)

I've been frustrated with the Star Trek universe for years. Paramount needs to send Berman and anyone who looks like Berman on a permanent vacation, and find a real set of writers. For starters, they could look at some of the alumni from SG-1...

Chris Double reports that Avi has set up a new Seaside site. Also notable - the Seaside license has changed over to the MIT license.

This is very good news - Google is getting out front in the fight against comment spam. I'm going to have to look at supporting this in my server:

If you're a blogger (or a blog reader), you're painfully familiar with people who try to raise their own websites' search engine rankings by submitting linked blog comments like "Visit my discount pharmaceuticals site." This is called comment spam, we don't like it either, and we've been testing a new tag that blocks it. From now on, when Google sees the attribute (rel="nofollow") on hyperlinks, those links won't get any credit when we rank websites in our search results. This isn't a negative vote for the site where the comment was posted; it's just a way to make sure that spammers get no benefit from abusing public areas like blog comments, trackbacks, and referrer lists.

I was getting very, very tired of fixing the wiki pages on the uiuc VW Wiki. Apparently, they have a fix that they plan to implement - in the meantime, something like 100 pages got spammed repeatedly yesterday. That was annoying to cleanup. However, there's a simply way to revert a Wiki page back to a former version. It was a manual process to gather all of the pages along with their last good version, but now I have that. I think - based on the time interval - that the spammer is running a script that edits a set of known pages and inserts his set of bozo links. Well, now I have a script that simply resets all of them. Check out the Recent Changes page - see how closely bunched all of those changes from one system (mine) are? Fight fire with water, I always say...

I've started to doubt that the noFollow thing will put a serious dent in spam. Don't get me wrong - having the ability to mark a link as ineligible for crawling is useful in and of itself, and will at least help with bogus page-rank. However, it's not going to fix the problem itself.

Look at the strategy behind email spam - the cost of sending the email approaches zero, so the spammer only needs a miniscule response rate to make it worth their while. This is in contrast to direct mail, where there are actual costs involved. Over time, sending mails back to people who never buy anything has a real cost - doing the same with email is virtually cost-free. Sadly, the same thing applies to spam in comments, referer lists, and wiki pages. Page rank is a nice bonus for these people, but it's not really the driver. With no actual costs, they can keep pounding away, happy to receive whatever tiny percentage of click-throughs they get.

For an example, just look at the spam pounding that the UIUC VW Wiki has been getting. Yesterday, more than 100 pages were defaced, most likely by a script. They ended up getting restored quickly (see my previous post), but over the course of the day yesterday there were 3 mass defacings. None of them stayed up long enough to guarantee a bot crawl - but they were up long enough to get found, and for some small percentage of people to - gosh knows why - click through.

While this is a good and useful idea, I don't think that the level of celebration ringing through the blogosphere is warranted - the impact of this will be minimal at best.

Update: a few posts along similar lines of thought:

• Freeform Goodness
• Take the First Step

Sean McGrath has an absolutely priceless commentary on the optional typing hullabaloo over in Python-Land.

Looks like Croquet is getting some press attention - the Croquet blog points to a Forbes article about it. And obtw - you can subscribe to the Croquet blog here

I see posts like this and I realize how small the impact of Smalltalk and Lisp have been on most developers. Have a look below:

At one time or another, every programmer has imagined what it would be like to work directly with the deep structure of code. Some of the best minds in the business are working to make that happen. The legendary Charles Simonyi, who left Microsoft a couple of years ago to pursue his vision of intentional programming, says deep structure is at the core of the toolset his new company, Intentional Software, is building. Sergey Dmitriev shares Simonyi's vision, and his company -- JetBrains, creator of IntelliJ IDEA -- wants to do something similar with its next-generation toolset. These projects are still under wraps, but another champion of deep structure is working out in the open. Jonathan Edwards, currently a visiting engineer with MIT's Software Design Group, has built a prototype system that he is demonstrating in a screencast at subtextual.org.

There are big ideas at work here. In Edwards' prototype, programming, testing, and debugging are just different ways of interacting with a program's tree structure. Edwards' 2004 OOPSLA paper, Example-centric programming, explores one of the benefits of this arrangement: the examples (or "use cases") that drive program design are worked out the context of the living and evolving program. We've all heard this stuff before. I may yet go to my grave without emacs ever having been pried from my cold dead fingers. But it's worth pondering, now and then, what we could do with tools that didn't think of programs as strings of text. Full story InfoWorld.com

You know, it's not like this stuff doesn't already exist. I realize that it's likely news to Gosling, who seems to think that he's the first one to have ever thought of parse trees. As for Simonyi, I think the phrase "Hungarian Notation" tells me everything I need to know about what his vision would look like... almost certainly a place I'd have no interest in going.

Seriously though, live code isn't a new thing at all - Lisp has been around a long time, and so has Smalltalk. Everything that is talked about above - it's been out there, implemented and in use for (literally) decades now. I guess that - for lots of developers - if it doesn't use curly braces and semi-colons, it simply doesn't exist...

After a few comments in this thread, followed by this post, I thought I should address truly large feed subscriptions in BottomFeeder. By default, I set a memory ceiling of 128MB in Bf - that was an attempt to make it a sociable client that wouldn't grab memory like a sociopath on your desktop :) Now, that's resettable - you can set that figure higher in Settings>>Memory. If you really want to read a few thousand feeds - then I'd make the following settings changes:

• Memory: set the soft limit to somewhere around 300 MB, and the hard limit to 500 MB or above
• Network
• Turn threaded updates on
• Turn "Limit the number of threads during update" on

The latter will cut down on how many concurrent xml docs stack up for parsing at once during update cycles. The lower limits are kind of tuned for what I consider "normal" usage - a few hundred subscriptions at most.

Reflective Surface just read a book called Calculating God, a fascinating little Sci Fi book by author Robert J. Sawyer. He's written a number of good books - I particularly liked End of an Era, which posits an odd ending to the dinosaur era. Sawyer's a fun author, and his books are a fast read.

This could be good news for Heinlein fans if the screenplay doesn't get the all too typical Hollywood treatment. I've always thought that The Moon is Harsh Mistress could make a great movie - now, maybe we'll see the effort made. For the record, I wasn't that down on the film "Starship Troopers"...

Compared to my interest in the previous post, news of X-Files 2 work just makes me yawn. The big question: "Why?" Yeah, I know the answer is "too make money?" :) Seriously though - the series had jumped the shark many seasons before the end, and the first movie was pretty lame...

Ben Hammersley's Dangerous Precedent explains why the excitement over "noFollow" in the Blogosphere is misplaced:

This is the key point. If rel="nofollow" works, if it's applied universally, it will actually have the reverse effect. It actually gets less effective the more it is implemented. Why? Because the comment spamming sites are in competition with *each*other*, and not with any legitimate businesses. They're not so much trying to get the best pagerank for their term, as trying to get a better one than their rivals. That's a key distinction. If the playing field is levelled by rel="nofollow", then everyone involved will be forced to try all the harder to get their links out there. The blogosphere will be hit all the harder because of the need to maximise the gains. As there's no more effort in hitting 6 million blogs as there is in hitting 1 million, this really won't bother the spammers one bit. All it does is shift the problem from the high pagerank blogs we here might have, with rel="nofollow", custom sanitize settings, and mt-blacklist in full effect, all the way over to the less technically adept. And that is one enormous customer service problem heading towards Blogger, 6A and the rest.

That's about the size of it. You really have to keep in mind that spamming costs the spammer nothing - so these techniques don't really affect their behavior. See Phil Ringnalda for more along these lines.

Update: Ben Hammersly updated the post I linked to with this excellect observation - one that I certainly hadn't thought of:

Meanwhile, Scoble points out how it can be used in other ways, and undermines the second aspect of the attribute: as respecting rel="nofollow" will involve losing an enormous amount of implicit metadata, any tools that are interested in that will be forced to ignore it. Technorati will have to choose if it's a site that measures raw interconnectivity, or some curious High School metric of look-at-that-person-but-don't-pay-her-any-attention that the selective use of the rel="nofollow" attribute will produce. For many purposes, this would mean the results are totally debased and close to useless.

We aren't as pathetic as Raleigh :)

Yes, picking inauguration day was probably not the brightest idea on our part. When I suggested the 20th instead of the 13th (I was out of town on the 13th), I hadn't thought of this :) In any case, it looks like taking the DC Metro to the Gallery Place/Chinatown stop is the best way to go - and according to the metro's planner, it's open today and tonight. Once you get there, walk north past the MCI Center to the Starbuck's at 800 7th street, and you'll be there. The meetup starts at 7 PM - with all the inauguration hoopla, it's probably a good idea to give yourself plenty of time. I'll have the latest Cincom Smalltalk non-commercial CD's if that's any motivational help :)

In the thread that followed this post, I was asked whether I had read this OOPSLA 04 paper. I had a brief look last night, and more this morning. Here's what jumped out at me:

What is new here is the application of this technology "outside the box" of a debugger.

A debugger is used in a different mode than the editor - first you edit your code, then you switch to the debugger and manually run the code with some inputs. The debugger presents an entirely different UI and mode of interaction than the editor. The goal here is to eliminate this mode-switching by unifying the debugger and editor into a single tool with a consistent UI. This can be described as an example-enlightened editor.

In addition to sidelining the debugger, this approach supplants the need for a Read-Eval-Print-Loop: the canonical exploratory UI to an interpreter. Expressions typed into a REPL are instead now just example snippets in a source file, with their results appearing in the example view rather than inserted into the transcript. Results are automatically refreshed whenever the code changes, which avoids the hidden pitfalls of anachronistic definitions

Here's the part where the Smalltalkers realize that yes, in fact, there's nothing that fascinating here: A debugger is used in a different mode than the editor - first you edit your code, then you switch to the debugger and manually run the code with some inputs. The Smalltalk debugger is both a debugger and code browser - it's not the separate tool that the author discusses. I'm sure that this kind of tool looks very interesting to people using the mainstream languages - while to those of us using Smalltalk it elicits mostly "I've had equivalent capabilities for years now". Not identical mind you, but very much akin.

After that section, the author discusses unit tests, and how they are useful as examples. Nothing to argue with there - many developers view unit tests as something close to a documentation replacement. The unit testing assistance that the tool offers looks interesting, but - in theory, you write the test first. Thus, picking out a code snippet that qualifies as an assertion puts the cart somewhat before the horse. On the other hand, I hardly qualify as a testing purist, so this kind of support likely would be useful - if it helped generate a unit test. As outlined, it suggests that the tool is obviating the need for a separate test. That's likely a bad idea - once the initial developer leaves, this artifact goes with him. A separate unit test survives as a marker.

Ultimately, I'm not convinced that it's a good idea to encourage people to not write separate tests - which is what this paper argues for. Tests, like code, are primarily communication - a link between the original author and the future maintainer. Code maintenance always goes on longer than initial development, and any increase in the communication between the original author and the future maintainer is a good thing. The path suggested by this paper would reduce communication... not a good thing at all. I realize that the author posits a new set of IDE tools where all of this is integrated - and if it was all tied together, it would be more impressive. I still don't see it as much of an advance over the Smalltalk debugger I currently have though.

There's an interesting op-ed piece in Computerworld - I was taken in by the notion of a "Toxicity Survey". Everyone in the marketing sector has read Moore's "Crossing the Chasm" - Thornton May says it's time to move on:

Inappropriate and outdated mental models on why and how technologies enter the organization: The days of "crossing the chasm" are over. Geoffrey Moore, the creator of this once-dominant descriptive framework, has moved on; vendors should too. The simplistic, product-centric characterization of customers as innovators, early adopters, early majority, late majority or laggards has given way to a much more fragmented and nuanced set of behavioral buying clusters. Just as society has fragmented into categories such as soccer moms, NASCAR dads and underemployed knowledge workers, so too have technology entry points atomized. Most vendor marketing programs haven't been successful at targeting the tribal leaders of these buying clusters.

I'll have to give this one some thought. In most marketing circles, Moore's chasm work is near gospel - certainly the conservatism of the late majority is evident in the space. The rest of the piece is thought provoking as well. I'll have to chew on this one.

Well, well. I've been saying that WS* is the new CORBA for awhile now, with the only significant difference being port 80. Looks like the IT press is starting to think similar thoughts - have a look at Alexander Krampf's op-ed in SD Times:

Is it me, or does all of this seem eerily familiar? I can't help comparing today's Web services hype to the CORBA boom of the 1990s.

What happened and which technological revolution did I miss that makes all this a reality? It must have been XML and SOAP. But wait 14while XML is a great way to store and exchange information, it does so in a very verbose manner. And SOAP is really just another RPC protocol that happens to use XML instead of a binary data representation.

Deploying Web services requires a stack that includes XML parsers, Web servers and additional infrastructure. I just don't see that huge a difference between what Web services offers to me today and what CORBA offered to me five years ago. Back then, I needed to know IDL (Interface Definition Language). Today, I need to know all the different Web services schemas. And keeping track of the various standards and specifications is another enormous challenge.

I recall watching the ParcPlace distribution team trying to keep track of the vast array of CORBA services that were spinning out in the early to mid 90's - and believe me, the view of WS* specs rolling out looks like the same thing all over again.

This is probably the best advice on WS I've read yet (it's a good general point as well):

Web services are yet another tool in our increasingly large arsenal of integration approaches. They have many admirable characteristics and will make a valuable contribution in helping businesses operate more efficiently and serve customers better. Let's just make sure that when we choose Web services, we do so because they are the appropriate solution for each integration problem and not because we have a free Web services stack sitting around with nothing to do.

Just in time to deflate my own sense of importance (witness this post) comes this from Doc Searls - here's a link to the NASA page he references:

January 10, 2005: NASA scientists studying the Indonesian earthquake of Dec. 26, 2004, have calculated that it slightly changed our planet's shape, shaved almost 3 microseconds from the length of the day, and shifted the North Pole by centimeters.

...

None of these changes have yet been measured--only calculated. But Chao and Gross hope to detect the changes when Earth rotation data from ground based and space-borne sensors are reviewed.

All I can say is... wow.

Lambda the Ultimate points to a critique of OOP. Needless to say, I don't agree - but then again, you won't learn anything by only reading things you agree with :) I'll make one small comment:

Consider the profound contradiction between the OOP practices of encapsulation and inheritance. To keep your code bug-free, encapsulation hides procedures (and sometimes even data) from other programmers and doesn't allow them to edit it. Inheritance then asks these same programmers to inherit, modify, and reuse this code that they cannot see -- they see what goes in and what comes out, but they must remain ignorant of what's going on inside. In effect, a programmer with no knowledge of the specific inner workings of your encapsulated class is asked to reuse it and modify its members. True, OOP includes features to help deal with this problem, but why does OOP generate problems it must then deal with later?

Why does OOP generate problems it must then deal with later? All this leads to the familiar granularity paradox in OOP: should you create only extremely small and simple classes for stability (some computer science professors say yes), or should you make them large and abstract for flexibility (other professors say yes). Which is it?

I'd say that this has more to do with black box development vs. white box development than with OOP per se. But heck - don't take my word for it - read the whole thing.

I linked to this post by Phil Ringnalda earlier - he makes the point that spammers are going for quantity, not quality - they spray their efforts far and wide (because they can), and don't really care if the effort succeeds. Like Phil, I've got the logs to prove it :) Now, I don't suffer nearly the volume of spam attempts that sites running the common blogs servers do - hello, security through obscurity. Still, I get a daily ration of attempts. I turned off comments on all posts that fall out of the RSS feeds awhile back - I downloaded all the posts and scanned for spam a few months ago and was unpleasantly surprised to find a fair amount of spam lurking in posts that I had long since forgotten. The fact that I've disabled comments for older posts hasn't entered the consciousness of whoever tries to spam the CST blogs; every day there are attempts, and every day it's to the same small set of old posts. To quote one of my colleagues here at Cincom, and so it goes...

PR Opinions (naturally enough) likes the analytical groups:

The influence of the analyst community in the technology purchasing decision is a much coveted resource. It is one of the reasons that technology vendors are anxious to access, inform and influence these analysts. Typically the bigger vendors spread their analyst budget around a large number of firms. However the smaller firms, with limited funds have a far more difficult time and often budget decisions are driven by broader marketing requirements. With this market dynamic there is always risk.

I have been working with industry analysts in North America, Europe and Asia, on and off, for well over a decade. In my experience, the majority of analysts and their firms, offer impartial, informed and valuable advice to their clients - whether those are vendors, end-users or a combination. But as with any market (think Public Relations ladies and gentlemen!) you always have rogue elements who offer biased, "pay-for-play" services which are about as valuable as you'd expect.

Hmm - you can check my archive for my somewhat more jaundiced view. They offer this view by James Governor:

"Suffice to say that sometimes the industry analyst business looks something like the Mafia... some analyst firms appear to run a sophisticated version of the protection racket. If you pay up we let you do business - if not we can make life real hard for you by smashing the place up/downgrading your products. Its an open secret in the business, the corpse out in the backyard we all catch occasional whiffs of...It is becoming increasingly clear that the industry analyst business is ready for an overhaul."

Now, I'm not sure that I'd go quite that far - but the bias in the tech industry is somewhat akin to the much talked about media bias thing in politics - it's not that the media are purposely slanting one way - or that analysts are purposely slanting one way either. It's more that they are all coming from the same "culture", and you get an inadvertant "groupthink" thing going. This is why many media stories (think the OJ trial) get a real herd mentality behind them, I think - and it's also why the analysts tend to mirror the IT industry supposed consensus.

What you get from the analyst groups is their distilled notions of popularity - not any kind of meaningful technical analysis. That's fine as far as it goes, and it does have value. You should just be aware of what you are getting.

Last night's Smalltalk meetup went pretty well - I ran into some old and new faces. We retired to Fuddruckers from Starbucks (thank you Victor for arranging that!) after we ran out of room in the corner of Starbucks. We had a good time - kudos to Matt for arranging it. I look forward to the next one.

I share a lot of Rogers Cahdenhead's frustration over RSS 1.1 - it's another solution in search of a problem - see here for the format that exists due to antipathy for Dave Winer. However, there's a reason I added support for it to BottomFeeder - I just knew that Id get asked about it, and it's simpler to pre-empt that and just add support. It was simple enough; I subclassed the RSS 1.0 handler and overrode 4 methods in the subclass - done. I'm entirely unclear as to what problem it solves, but there it is...

I'm only now getting back to work - we had the in-laws over for a brunch, and my morning was swallowed by my own mistakes. Last night, on my way to Smalltalk Meetup, I lost my phone. Somehow, it slipped out of my pocket on the metro - so much for that. I went to the Verizon store this morning, and ran into a few hurdles. They were actually quite nice - they let me replace my old phone for the upgrade price even though I had no insurance and had bought the new phone just 6 months ago. It still took forever - the guy in front of me in the service line wanted a personal introduction to every feature on his new phone, and I had to wait to get my address book transferred from my penultimate phone to the new one - complicated by the old phone's complete lack of charge. That ate up 2 1/2 hours. I'm happy with Verizon's service, I just wish it hadn't chewed my morning up...

I made a comment in this post's comments about the memory requirements for BottomFeeder. By extension, it was about memory usage in VisualWorks applications in general. With that in mind, let's take a look at that. If I bring up a base VW 7.3 development image, and execute ObjectMemory dynamicallyAllocatedFootprint, I find that I'm using 14 MB of memory. Where is that coming from? There are two places:

1. Perm Space - all the classes and objects that start off in the image
2. The rest of the memory spaces:
1. Eden
2. SurvivorSpace
3. LargeSpace
4. StackSpace
5. CompiledCodeCache
6. OldSpaceHeadroom
7. FixedSpaceHeadroom

You can't do much about perm space without doing a strip (typically with RuntimePackager). The other spaces are well documented in the class side comments of ObjectMemory. You can find out how much space they take up this way: ObjectMemory actualSizes. That will return an array full of numbers, representing the bytes used. In a base (development) image, they look like this:

#(307200 61440 204800 40960 655360 591904 204800)

You can adjust those with the #sizesAtStartup: message - it allows you to send multipliers (x factors) by which to make those bigger. For instance, if you are going to be creating lots of objects quickly, it might make sense to make Eden and the survivor spaces bigger. That's still not a lot of space - at present, BottomFeeder is taking 65 MB on my desktop. Most of that is oldSpace - i.e., objects that have become permenent within the context of the runtime - my feeds, items, etc.

I mentioned that I had preloaded a lot of code - I have. Things like Opentalk, all the network libraries, SOAP, just rafts of stuff. That's something like 16MB of stuff in my base image. Now, I'm not really trying to limit what I load or take stuff out at all - I pretty much just package the image (i.e., make it a runtime) and go. You can do a lot better, and many people do. For instance, Liberty Basic - that's a 3mb download, and it's a Smalltalk application.

It looks like forward marketing and legal departments are going to keep running into each other - last week it was Apple, this week it might be Microsoft. I have a feeling that the whole concept of confidential sources is going to get a real test before this is all over.

Looks like there's a security breach in Java - anything older than the latest. I still say that trust relationships matter more than sandboxes, because developers - all of us, whether we use static languages, dynamic languages, whatever - we all make mistakes, and in far too many cases we only learn about them later...

We didn't get the huge snowfall that had been predicted yesterday - more like 4-5 inches. That's enough for good sledding, especially when the temperature stays down around 20 (Farenheit). My daughter and I got the toboggan out, and headed for "the hill" - a nice steep slope in the neighborhood. Lots of kids and adults had already gathered, and more piled in all afternoon. We had a pretty good time - it was so packed kids were periodically getting bowled over by other kids on uncontrollable sleds - the rubber inflatable kind. We stayed out a fai while - I didn't even have to clear the driveway, because my neighbors did that for me (to be popular in the winter here, try being the only one in your neighborhood with a snowblower :) ).

Looks like a slow Sunday ahead. It's cold outside - 16 Farenheit - and winds are gusting to 30. Meanwhile, the traffic through BottomFeeder seems light - I don't have anything to rant about :) There are the football games in a few hours - I can watch the Eagle march over Atlanta (I'll be shocked if it goes the other way), or the Steelers get trounced by the Pats (again, I'll be stunned if it goes the other way). I suppose more coffee might be in order...

We got off with a small snowstorm and winds - just look at what Massachussets is dealing with:

SNOWFALL ACCUMULATIONS OF 28 TO 38 INCHES ARE EXPECTED ACROSS EASTERN MASSACHUSETTS...GENERALLY 20 TO 30 INCHES ACROSS CENTRAL MASSACHUSETTS...MUCH OF SOUTHWEST NEW HAMPSHIRE AND RHODE ISLAND... AND 1 TO 2 FEET ALONG THE CONNECTICUT RIVER VALLEY IN SOUTHWEST NEW HAMPSHIRE...WESTERN MASSACHUSETTS AND NORTHERN CONNECTICUT. A FEW SPOTS IN EASTERN MASSACHUSETTS MAY REACH 40 INCHES BEFORE THIS STORM WINDS DOWN. DRIFTS OF AT LEAST 6 FEET ARE LIKELY ACROSS EASTERN MASSACHUSETTS.

If we got that much snow here, things would be shut down for a week. We've had 30+ inch accumulations twice since I've lived in Maryland - I was driving the Washington beltway a week after the last one a couple years back, and they were still removing snow (with front end loaders). This area simply doesn't have the kind of equipment you need for that.

Update: You can get National Weather service RSS feeds here

When I first turned the game on a couple of hours ago, here's what I was wondering - why the heck are the refs out there with no gloves?. I understand why some players don't want to wear gloves (better grip on the ball and all that). But the refs? What's up with that?

Johnny Carson died last night. For those of us roughly 40 and over, Carson personified late night - more than Leno, more than Letterman, it was "Hereeeees Johnny!" - for an awfully long time. heck, "Carnac the Magnificent" is still a catch phrase around our house. Rest in Peace.

Well, it looks like I called the early game correctly. Now let's see about that AFC game...

Looks like I called the Pats/Steelers game too. No big surprise there - I don't think these games were hard to call. Patriots/Eagles it is - and I'm not calling that one yet :)

Ten is a good number has some interesting information on how the soundtrack for "2001: A Space Odyssey" came to be.

Ben Hammersley points to two disturbing facts about internet usage:

According to the Pew Internet Survey:
Only 38% of users are aware of the distinction between paid or "sponsored" results and unpaid results...two-thirds say they could walk away from search engines without upsetting their lives very much.

Meanwhile Brian McWilliams points out a recent survey by Forrester Research (PDF), that has 41 percent of U.S. internet users have made purchases in response to spam.

Just in case the overwhelming volume of spam was confusing you...

Ted Leung makes a good point - you are what you write. The new norm in interviewing is being Googled, and - if you have a blog - what you've written there will show up.

Recently I've been doing a bunch of interviewing at OSAF, and I'm experiencing something new. Of course, we all know that people Google each other before meeting each other, so I sort of expect that people will Google the folks that they are interviewing / interviewing with. Recently, some of the folks I've interviewed have brought up information that they Googled on me (predominantly from my blog) during the interview. This has lead to brief moments during the course of the interview where I really felt like I was being interviewed (which of course is really always true). Just more first-hand experience of the way that blogs and search engines are changing our day to day lives.

I remember being told about my permanent record back when I was in school - I think this means that I actually have one now...

The Slashdot crowd weighs in on Schwartz' open letter to IBM:

"Sun's President and CEO, Jonathan Schwartz, yesterday published an Open Letter to the CEO of IBM, Sam Palmisano, in which he alluded to "behavior reminiscent of an IBM history many CIOs would like to forget" - a reference to Sun's frustration that IBM isn't supporting Solaris 10 with WebSphere, DB2, Tivoli, Rational and MQSeries products. In his "Dear Sam" letter - circulated via his blog - Schwartz refers first to the "long history of partnering" between Sun and IBM, and claims Sun customers have made repeated calls to IBM about having the choice to run IBM products on Solaris 10." *cough* Kettle, meet Pot.

Heh

The good news is, corporate sent me a new notebook. The bad news is... they sent me a new notebook. Transferring software is always so much fun - memo to Microsoft - get that bozo who thought up the registry over here, and let me slap him around a few times. Are you listening Scoble? Your software people may have found application level ini files somehow inelegant, but they allow for easy movement. Sigh. Moving on from that nightmare, there's the font nightmare. What's with the extra jaggy fonts on XP? My old notebook doesn't look like this, and yes - I tried setting ClearType - exactly zero effect. Grrrrr.

Update: I found the ClearType setting turned off under "effects" when right clicking on the desktop; I guess the MSDN pages on the MS site that claimed to be turning that on were not completely accurate. In any case, it looks better now. Still mystifying - was it off by default from MS, or from my IT group's build?

The saga continues. I love the way files get copied across the network - a random amount of time spent in a dialog stating "Preparing to copy", followed by a slow motion transfer of bits. Then there's directory sharing - whether you can share a given directory or not seems to be a random event - when I wanted to share "Program Files" (in order to transfer my mail client), I was told that I could drag the folder over to "Shared Documents", or I could walk through the network wizard, which seems to have some other purpose entirely. Which part of "just open up the effing machine, darnit" isn't clear here? Why do I have to walk through a million steps to accomplish something that ought to be simple? I swear, it would be simpler to burn a CD....

Interesting tidbit from Slashdot here:

"In a very low key announcement on his blog, Ben Goodger, lead developer for Firefox, has announce that effective from a couple of weeks ago, he has become a Google employee. In practice his day to day job won't change that much, in that he will still lead Firefox through its forthcoming releases, but with Google paying his wages, we can be sure that new and interesting overlap between the Mozilla Foundation's browsers and Google's services are sure to develop."

Is this just "funding" of ongoing Firefox development, or something more interesting?

The unadulterated stupidity that is Windows networking continues. Let's see how Windows can irritate the crap out of me now:

• In the middle of a huge file transfer, decide that "wow, I see another wifi network. Let me disconnect you from the one you are on to inform you about it"
• In the midst of a large transfer, simply offer a cancel dialog when, for no good reason at all, you can't transfer a specific file. Claim that it's in use, and force me to start all over again. Whatever you do, don't offer an option to skip and continue
• When I restart the transfer, don't offer to only grab only the files I already have. Force me to decide one by one, or just do a wholesale replacement

Thank you, Microsoft. The next time I have to fork over my own money for a machine, it's going to be a Mac or Linux box - because this just sucks. Hey Scoble - the Tablet stuff is completely irrelevant, because your base networking code is just a pile of steaming dung. Next time you visit the campus, make sure you let the Windows networking team know what a complete mess they've made of Windows.

Tim Bray relates a small story about Canadian customs and pc/software imports - I had a funny experience at the border once with Cincom Smalltalk non-commercial CD's. I declared them as I went into Canada to attend a conference - I had about 100 with me. The agents I met had the devils own time trying to figure out how to charge me for importing free software :) In the end, they charged me $50 CDN and off I went. They didn't hassle me - it just took them awhile to figure out what to do.

Ian Bicking has a post on exception handling - specifically, on handling arbitrary exceptions:

But there's other cases. Anytime you won't be there to babysit a process, you need to handle unexpected exceptions. For a command-line utility, you can read the exception when it occurs, no big deal. But for a long-running or batch process you need to intelligently deal with exceptions. Also for processes that are run by non-developers: you want to capture the error information so a developer can look at it, and then try to keep going if you can.

You'll want to read Ian's entire post; I'm only excerpting a small amount here. This does illustrate something of interest to me though - for a deployed application (especially a deployed client application), you want to be able to catch all exceptions. In Smalltalk, that's straightforward - the system already does that.

During Smalltalk development, an unhandled exception will give you a notifier (which offers you the option of debugging). Clearly, that's not what you want at runtime. On the other hand, you would like something like this:

• Catch all exceptions
• If it's possible to continue after handling the problem, do so
• If it's not possible to continue, at least save work and quit cleanly

In a VisualWorks application, the way you accomplish this is to look at class Notifier. What you can do is create a new class - either a subclass, or a separate class that implements the API - and swap it in as the default exception handler. When you package with RuntimePackager, it does this with it's own handler (default behavior - log the error and quit). You can change this behavior to anything you want - on a per exception basis. Very powerful, and extremely useful.

So, relative to my various posts on the joys of Windows networking, I now have a question - if I want to copy across the network, why is the DOS XCOPY command so much faster than the Windows shell copy/paste operation? I can't believe that the little paper animation is slowing things down that much; something else is at work here. Very odd.

Ted Leung makes some interesting points about development tools and the power they give you - if those tools actually grok the system they are being used to build

With Python, the tools are different. Right now I use a combination of Emacs and ipython for much of my work. When I start having to interact with code in the application layer of Chandler, then I find it useful to have Wing in order to present a usable debugger interface (I can hear James Robertson cringing all the way from the other side of the country). But none of these tools really understand what a Python program means either.

This is one of the biggest failures those of us in the Smalltalk (and Lisp) communities have - the failure to properly explain to people what it is we have, and why it's of value. Apparently, all most people see is that Smalltalk is different (and to many people, different = bad all by itself). Ted points out the value underneath the hood, and it's something we need to be better about explaining.

I've been watching 24 for 3 years now (through one absurd plot point after another, but nevermind) - the pacing is what I like better than the stories. Sometimes though, the absurdity of a situation just jumps out and bites me. A couple of examples come to mind from the ast two episodes:

• Jack has to keep the suspect (Kalil) from leaving the gas station long enough to get satellite coverage. He decides to fake a holdup.

Ummm - how about slashing the tires of his car? Or perhaps walking into the store and just being a jerk, forcing the clerk to pay attention to him? That one passed quickly, but the next one was a whopper. The terrorists are using the internet to broadcast a show trial, and the rescue forces are 20 minutes out - so they decide to bomb the place. Ummm - did anyone think to call the power company and just cut the power to the site? They knew where it was - a local blackout would have been easy.

It's things like this that jar you out of the plot and into "wtf??" mode during it. "Enterprise" does that all the time - and 24 is getting worse about it. At least there's Sci-Friday on Sci-Fi channel :)

Panopticon discusses Singletons, mostly (but not exclusively) in the context of VB. I thought this deserved some comment:

In most languages, you have to manage singleton objects yourself. This is usually accomplished by sealing the type (i.e. making it NotInheritable), making it uninstantiable (i.e. making its constructor Private) and exposing a shared property called something like DefaultInstance that returns, well, the default instance. If only the language would do that management for you automatically, how nice would that be? If only...

In Smalltalk, Singletons are typically by convention (there are exceptions; built in things like SmallInteger, for instance) rather than enforced. For instance - say I want a single instance of class MyWebService - I'll typically write code like this:

Smalltalk defineClass: #MyWebService
	superclass: #{Core.Object}
	indexedType: #none
	private: false
	instanceVariableNames: ''
	classInstanceVariableNames: 'default '
	imports: ''
	category: 'Web Services'

"class methods"
new
	^super new initialize.

default
	^default isNil
		ifTrue: [default := self new]
		ifFalse: [default]

reset
	default := nil

The idea is, all usage runs through the #default method. Now, this has pros and cons. The obvious con is that we don't have enforcement of singleton status, merely a convention. You can be a little more rigid by moving the lazy initialization into the #new method - but even then, developers can always invoke #basicNew. The point is, it can be gotten around with some level of effort. Paradoxically, that's also a pro - because it makes ad-hoc testing easy. We can create a new instance "on the side" without munging the "default" instance.

As is always the case in Smalltalk, the decisions are mostly left in the hands of the end developer rather than in the hands of the system. Is that a good thing? I think so, but YMMV

It certainly looks like ebay will sell anything - you think they could be more careful with their wording? Hat tip to Mike

The MPAA wants nothing less than to overturn the betamax decision. If they get what they want, it could get very, very ugly...

Slashdot reports that the Enterprise folks aren't giving up on the show - no, they plan some real stupidity to wrap things up:

"It seems Star Trek: Enterprise isn't about to go down without a fight. TrekToday is reporting that Jonathan Frakes and Marina Sirtis will guest-star on the season finale of Star Trek: Enterprise, to reprise their Next Generation roles of William T. Riker and Deanna Troi. Hello stunt casting! The news has been confirmed on Sirtis' official fan site."

Thank goodness for quality SciFi like BattleStar Galactica - where the characters actually seem to have substance, and a third dimension...