Smalltalk Tidbits, Industry Rants

Brian Marick writes about the interviewer/interviewee problem:

Dave Liebrech talks about people who are not business experts interviewing people who are. He uses investigative journalism as a model. What struck me most was this:

The interviewee *believes* the interviewer has a perspective different from their own, or has an incomplete understanding of some of the areas.

This brought something else to mind for me - accuracy and what we believe based on what gets reported to us - through any outlet. Think about the last time you say any technical topic being discussed by a reporter (possibly even in the trade press). If it's on TV, radio, or in a general newspaper, it's highly likely that there were many slip ups and factual errors (my friend Mike likes to point to Consumer World reviews in this regard). So when we read these things, we laugh about the inaccuracy - and then move on to reading about subjects we don't know as well without batting an eye.

What the interview thing raised for me is this - just how accurate is the rest of the stuff I read? If the tech journalists can be so far off base, what about about the political, economic (etc.) journalists? Just how much of what they report is being filtered not through bias (about which one can read tons of material) - but through sheer ignorance? It's probably a good idea to look at all journalism with a very, very jaundiced eye...

Via Doc Searls comes a link to James A C Joyce on why blogs are boring. This kind of strikes me the way complaints about bad TV or radio strike me - are people unaware of the "off" switch?

James Britt points to #Smalltalk - Don and John's work is starting to get noticed by the .NET crowd.

The Register tells us why the scourge of viruses won't end anytime soon:

Was the vector some l337 0-day 'sploit? Nope. Was it a complex multi-layer program leveraging several unpatched vulnerabilities? Nope. It was -- wait for it -- an executable attachment in an email. What genius! The author of Novarg (or MyDoom, or whatever you want to call it) really put his noodle to the test when he cooked this one up, huh?

So long as we have users that will open anything they get sent in email, we'll have this problem. Even better anti-virus systems won't help much here - the sorts of users that will open anything are highly unlikely to install (and keep updated) an anti-virus system. Sigh...

One of the things that recently got a lot better in BottomFeeder is character and font handling. I have to thank Alan Knight for most of the improvement - his work on Web Toolkit has given him a lot of experience dealing with encoding on the web. Here's how things work in Bf:

• Download the XML (RSS or Atom) page from the server
• Parse the XML into Objects
• Display the feed data to the user

The difficulty came right there at the beginning. The HttpClient in VisualWorks will use the correct encoding to get the content from an Http response object - assuming that the encoding has been set in the header. If it's not set, what it does is assume (as per the standards) that the content has been encoded as iso-8859-1. The trouble comes in when the content is sent without a content encoding header, and is encoded in something other than iso-8859-1 - you'll end up seeing a lot of bad characters in the resulting stream of data

Well, that's the standard way of dealing with this, and so - in some sense - "correct". The trouble is, end users couldn't care less about following standards if it means crappy looking text to read. The upshot is, I had to start playing some of the same games that I suspect browsers play - looking for other encoding information in the text. At the moment, Bf looks in two places:

• Once I have the content, I scan through looking for <meta http-equiv="Content-Type" tags. If I find one, I go ahead and grab the encoding set there as the proper one to use
• I look in the XML attributes for encoding information - things like this: <?xml version="1.0" encoding=. Again, if I find that I grab the encoding information

Well, at this point we have a problem - the content has already been decoded as iso-8859-1, and, based on the new encoding information, we know that's wrong. What to do? Here's where Alan's tip saved the day. The following code snippet sets things right:

decode: text with: encoding

 	^[(text asByteArrayEncoding: 'iso-8859-1') asStringEncoding: (encoding asLowercase)]
		on: Error
		do: [:ex | text]

That undoes the iso-8859-1 encoding, and then decodes the text with the proper encoding information gleaned from the document. The results of this simple snippet of text have been really good - I'm seeing far fewer garbage characters in the text of the feeds I access. I still see some (especially in the Meerkat feeds), but I can't do a lot when there's no encoding information at all - iso-8859-1 is as good a guess as any in the complete absence of information.

This is the sort of thing any user-agent on the web is going to have to go through. For good or ill, encodings simply are not universally set in the http headers. Maybe they should be, but they aren't. I don't expect it to get better either - remote hosting services pretty much ensure that

Proving that politics invades every field, this development in the ongoing Atom/RSS imbrogolio takes the cake.

Via StronglyTyped, a nifty map of WiFi hotspots in North America

This story has some interesting things on food safety:

Cutting boards are another area of concern. Turns out that wooden boards are safer than plastic, because the cellulose in wood absorbs bacteria but won't release it. Plastic absorbs bacteria in a different way. "When a knife cuts into the plastic surface," said Professor Dean Cliver, of the University of California at Davis, " little cracks radiate out from the cut. The bacteria seem to get down into those knife cuts and they hang out. They go dormant. Drying will kill, say, 90% of them, but the rest could hang around for weeks."

Makes sense; that's why plastics that you send through the dishwasher often get dyed the color of things you wash - the plastic absorbs it all. This is the part that runs counter to lots of "conventional wisdom":

In one experiment performed by Professor Cliver, raw chicken juices were spread on samples of used wood and plastic cutting boards. Both boards were then washed in hot soapy water and dried, then knives were used to simulate cutting vegetebles for a salad. No bacteria appeared on the knives cut on wood, but there were plenty on the knives used on a plastic board.

We use glass, which I think obviates the whole issue. But I'm sure a lot of people use plastic thinking it's safer. Sometimes it's what you know that's not so that's most dangerous. Read the rest; fascinating story.

I might be able to make some progress on getting BottomFeeder packaged for the Mac this week. One of the engineers has gotten me VNC access to a Mac, and I should be able to get the packaging done - it doesn't look hard at all. I'll post again on this subject if/when I achieve something!

I've followed the packaging directions for OS X that come with VW (amazing what happens if you read the shipping documentation) - and I think I have a "proper" OS X packaging on the download pages now. I'd appreciate hearing about any issues this packaging has.

Lisp and Ruby users have a few words about J2EE as well:

J2EE applications tend to grow like cancer until all resources of the host have been consumed. At my day job we've written over one million lines of Java implementing a simple internet marketplace. We do use a code generator to do most of the grunt work, but only because we cannot create the necessary abstractions within J2EE. Using a code generator is like enumerating all the parts and assembly instructions for a house instead of just writing "home". Java has no meta.

The MS .NET crowd is in the same boat....

After a couple of suggestions from engineering, I went through my build again, and made sure that all the networking code that should be there is on the build. There were some Mac specific classes that I think may have been being stripped out of the build; in any case, I've got a new OS X build attempt posted. I've got it structured as an OS X application - something I can do without having a Mac. I'm in the process of getting access to an OS 9 machine (remotely) that should allow me to do a build for that platform as well. I'll gladly take any and all feedback on the latest OS X build I've posted.

I found this post via a Feedster search for BottomFeeder I use to see stuff I might otherwise miss. I noticed that there was a reported issue with the Atom support - and sure enough, it wasn't quite right. It turns out that the Blogger Atom feeds are set up slightly differently from the ones I tested against (off the Atom Wiki). This is what I love about early adoption of in-development specs - everyone goes their own way, and tool builders end up having to support all the variations. In any event, I just posted an update to the Atom support in the Dev stream for Bf; I may try to extract it for the normal update stream as well.

Ted Leung has some interesting comments on the dangers of promotions. Linking to a Fast Company article, he quotes:

Picasso wasn't interested in becoming a curator. Meryl Streep is an extraordinary actress, but that doesn't mean she wants to or would be any good at running a studio. Why does corporate America insist on taking your job away from you if you're good at it and serve it up as a promotion?

It's not quite that simple; there are, in fact, people who want to move up the chain. For the most part though, this fits - we all know plenty of former tech people in management positions - many of whom don't belong there. Heck, this makes me wonder if the huge failure rates in IT projects is related to this problem. The problem is twofold:

• Convincing corporate managers that they can keep us happy without promoting us
• Convincing ourselves of this same fact

The latter point may be the hardest - the reality is, even with increased pay, many people would consider years in the same position as being stuck.

Ben Hammersley points to a summary of RSS by Mark Pilgrim, which documents the existence of 9 different (and incompatible) versions of RSS. This is one of the prime reasons that news aggregator authors continue to get mail asking something like this:

Your aggregator - (insert name here) - has trouble with this feed: (insert http link here)

Now, Atom was going to make this all better, right? Maybe it would have, if people hadn't insisted on deploying it before it was ready. I count myself among the guilty here - I've got Atom 0.2 feeds on this blog. In the wild, there's Atom 0.2 and 0.3 - and since the specs aren't done, there's slight variations in implementations, as different sites see the spec differently. Blogger is mandating that users pick RSS or Atom (why they can't do both is a mystery), so their take on 0.3 is likely to be semi-definitive. What does this mean? Look for the variance to get worse, and then worse again...

Tongue slightly in cheek, Charles Miller explains why Java programmers have it so hard:

We're surrounded on all sides, you see. To C programmers, we're children who can't handle real complexity. To Smalltalkers and Lispers, we're misguided souls groping towards a better way, but trapped in the wicked grasp of Sun's marketing. To Perl and PHP nerds, we're too busy over-complicating things to ever get anything done. To Ruby and Python hackers, we're already dinosaurs. And to everyone, we're apparently the COBOL of the 21st Century.

Pretty much every other language has its niche. You can point at it and say that it's useful for this, or it pioneered that, or you'd use it in this circumstance. The only people who say anything like that about Java are, well, already Java programmers. C# programmers might look on Java as a slightly embarrassing parent, except we're the competition, and it's better to just not mention us at all.

Heh. I wouldn't say trapped in the grasp of Sun marketing; I'd say trapped in the grasp of a bad type system...

I've been pushing builds of Bf for OS X for 2 days now, and I think I finally have it - although confirmation from someone with an OS X box would be appreciated. There were a few issues with my packaging:

• One of the XML manifest files listed the wrong name for the VM - I fixed that
• The OS X VM expects an image called 'resource.im', and I was shipping 'bottomFeeder.im'. I changed that
• There's a known issue with some OS X networking setups that can cause a socket error when trying to get the host address. Since this happens at startup, it's kind of a problem. I've got a patch that works around that in the build

I'm hopeful that I've got this working; if so, I can move along to fighting with OS 9...

Update: As youcan see from the comment below, the OS X build works. It doesn't have the Bf splash screen (I have no idea how to provide an image in the right format without access to a Mac - help welcome!), but it installs and works fine as a double clickable app. I'd like to thank Holger Kleinsorgen and Ralf Propach for their help this morning, and Roger Whitney and Bruce Bolden for their email help.

Program chair Alan Knight has pushed out another call for participation:

Smalltalk Solutions 2004 is fast approaching, and we need your participation! Smalltalk Solutions is a premiere venue for Smalltalk professionals, regardless of dialect, to meet and exchange ideas. We are currently accepting proposals for all varieties of talks involving Smalltalk technology and including presentations of other areas of technology from a Smalltalk perspective.

This year's conference is taking place in Seattle, Washington, May 3-5 2004. Presentations may be in the form of:

• Technical Presentations
• Experience Reports
• Technology Demonstrations
• Half-day Tutorials

Presenters receive a free conference registration (one per presentation). Tutorial speakers will also receive a small stipend.

To submit a proposal, please go to http://www.smalltalksolutions.com/participate/participate.htm or email Alan Knight

Proposals should be received by February15, 2004.

get those cards and letters in!

Salon has an interesting article on a show I've seen only once, but found interesting - "Bands Reunited". It's an interesting article, and a great show - catch it sometime if you were listening to music during the 80's....

Amtrak to offer WiFi at their stations. Now, if we could get it on the trains running up and down the Northeast corridor....

Via Bob Congdon comes news that won't make the intel boys happy - MS is releasing a 64 bit preview of XP - for the AMD cpus. It's about time to stick a fork in the itanium...

Ryan Lowe has reached the end of his rope on the (lack of) security in MS products. To be fair, newer revs of Outlook (etc) have most or all of the dangerous features off, and most people will never turn them back on. The main problem is the legacy of win98, winME - and even win95! - clients out there with dated software. Too many of these people are out there, running on DSL or cable modems, always on, and apparently always infected. I cut MS no slack on this stuff. It wasn't necessarily clear that these services were a problem when 95 shipped; but it should have been by the time 98 went out, and clearly was by the time ME shipped. And yet here we are, still in hackers paradise. Backwards compatibility is a big deal, I know - we try very hard to achieve as much of it as we can in Cincom Smalltalk releases - but for some issues, there are overriding concerns.

The Register points out that many, many office workers don't think that they have any role to play in security at all:

Two-thirds of the 1,000 people quizzed by market researchers TNS in January admit they are not aware of even the most basic virus prevention measures. Meanwhile a third of those polled in the Novell-sponsored study said they are too busy to check their emails before opening them.

Depressingly, nine in ten of the workers quizzed believe that have no part to play in preventing the spread of viruses, preferring to leave responsibility to "their IT department, Microsoft or the government".

This was in a survey of UK office workers; the rest of the report is even more depressing...

Rich has a few interesting thoughts on the way promotion and technical advancement work in large companies.

Dare Obasanjo jumps on Mark Pilgrim for using XML 1.1. Now, from reading the warnings Dare links to, it certainly sounds like most people should avoid 1.1:

Everything you need to know about XML 1.1 can be summed up in two rules:

1. Don't use it.
2. (For experts only) If you speak Mongolian, Yi, Cambodian, Amharic, Dhivehi, Burmese or a very few other languages and you want to write your markup (not your text but your markup) in these languages, then you can set the version attribute of the XML declaration to 1.1. Otherwise, refer to rule 1.

Well, regardless of what people should use, rest assured that they will use 1.1. Now, we don't have a 1.1 parser in VW at this point (we likely will by the next release). In the meantime, after a couple of small hacks, BottomFeeder handles Mark's feed just fine. I've posted the update to the dev stream; I may back it down to the regular stream if I don't see any issues with it

This is one of the really nifty things about using Smalltalk, actually - anyone use Java or .NET, and using the shipping XML libraries, is kind of up the creek - you can't easily make small changes to these libraries, and even subclassing could be problematic (I have no idea if critical classes in these frameworks are declared final, but they could be). Meanwhile, I was able to deal with this in a work-around kind of way in minutes - and I'm no parser expert....

The Industrial Light and Magic folks won't be sleeping much if they have to stick with this schedule. Time to get that caffeine drip going!

One of the people now running a blog on this site asked me about improving the look and feel of the pages. I'll admit, I'm no whiz when it comes to laying out web pages - I settled on what's here now more out of exasperation than anything else. The upshot of the request was for a few new, convenient API's for getting content from the back end - allowing for a more flexible layout. That's where the power of Smalltalk helped me out again. I fired up the test server here, wrote some new code, tested it out (against the running test server) - and then versioned it off. Once I did that, I posted two things to the server

• The incremental changes I just made
• The new version of the loadable components

I didn't have to restart the server - it has a convenient patch interface. So I loaded up the patch, and now the new interfaces are available for use. No fuss, no muss, no restarts. That's what I love about Smalltalk

Vassili Bykov explains why seemingly "little things" can't always be fixed right now - no matter how small you think the change is, there's almost always a snowballing effect of related changes that have to be made.

This is actually one of the constant tensions that exist between product management and engineering. In my role as PM, I want to see the product become easier to use and more consistent. This can often lead to my asking for "a simple tool" over here, or a "cleaner interface" over there. What I'm not always seeing (until it's pointed out!) is the downstream effect of those "simple" requests.

This is also where larger projects - such as Pollock are born. In order to really fix the current UI, it's not enough to simply tweak and tune - a general overhaul is called for. That general overhaul has its own downstream effects - all the tools have to be changed to match the new UI.

I've always wondered about the efficacy of team building exercises; this morning, I see that Frank Patrick has some thoughts on the subject as well. This is something project managers should definitely pay attention to...

This post I made yesterday generated a couple of comments, one worrying that I'd end up with a less readable site. That's certainly not the goal. The issue with the current layout is one of screen turf - there's way too much of it taken up by the top of the page search forms, and the the links at the bottom are not laid out at all well. In any case, it's all an experiment - we'll see what happens.

The Cincom Smalltalk site has moved from http://www.cincom.com/smalltalk to http://smalltalk.cincom.com. The old url will continue to work.

I've just posted a BottomFeeder update that cleans the UI up. The button bar is gone; all of those options exist in the View menu anyway. The feed icon is banished from the main ui, instead living in the Feed Properties dialog. That also eliminates a background process in the main UI, the one that fetched the image. You get notified of alerts (assuming you've set any) in a part of the status bar now. With all of those cleanups, I moved the rest of the UI to take up all the screen turf - no more wasted space at the top. If you grab this as a dev update, you should not load it on the fly; it's best to restart after grabbing it

I spotted this complaint over on Dave Winer's blog:

"...programs will express compatibility in terms of products, not formats. Then you'd have to use one aggregator to read BBC feeds, for example, and another to read SF Chronicle feeds." Well I guess we didn't have to wait too long for that to happen.

Funny - I have Evan's Atom Feed (and boy, does it have a lot of errors!) and Dave's RSS Feed in BottomFeeder - no need to use a different application to read both. This, even though I've posted extensively on what a huge waste of time I think Atom is. The bottom line is, it doesn't really matter what I think. My users are going to want to read Atom feeds, so I implemented support back when the spec was at 0.2. I now support 0.2 and 0.3. Looks to me like Dave needs a better aggregator....

Patrick Logan spots a gathering storm in the world of static languages:

When a language is formed by piling feature on top of feature, you run out of gas sooner rather than later. Such is the case with "partial classes". Could one have foreseen the desire for "partial methods"?

What do you do when your language is not dynamic enough, but the next feature may be the straw that breaks the camel's back? You resort to code generators.

Mind you, the developers living in this world think all of this is great - they have manifest typing, so the larding on of tons of cruft - cruft that makes it incrementally harder to actually understand written code - is seen as a good thing. What these people need is a few months of Smalltalk, Python, or Ruby immersion...

Via Patrick Logan, we see that Anders Hejlsberg doesn't understand development as well as he thinks:

There is clearly a performance aspect to it. One possible solution would be to say, "There are no value types. All types are heap allocated. Now we have representational identity, and so we're done, right?" Except it performs like crap. We know that from Smalltalk systems that did it that way, so something better is needed.

Anders solution - make the language immensely complex for the truly small number of cases where any of this matters. Yes, there are people doing maths in software where they need that level of performance on a day to day basis. And no, most people aren't part of that club. For most people, applications look like this:

• Pull data from the data store
• Massage data for screen display
• Allow user to modify data as needed
• Push data back into data store

Like it or not, the vast majority of developers are working on an application that looks, in rough terms, like that. Most of us aren't doing matrix manipulations or fast fourier transforms - but to hear Anders speak of it, we have to optimize for those few because... well, because he hasn't thought that deeply about the problem, that's why. When we do come across parts of our system that we have to optimize for those cases, we can call out to C (etc) - and that work-around is typically a much lower effort than having to deal with the world Anders wants us to live in. I know there are applications that have such strict optimization needs that this strategy is impractical - and I also know that such applications are not what most of us are building.

Here's another thing - as Patrick says on his blog, 64 bit implementations will erode the number of cases where that stuff matters even more - so the development time suckage of .NET and Java will persist, long after the supposed "need" for it has expired. Bonus question - I wonder when the last time guys like Hejlsberg or Gosling actually had to work on a real project for a real customer, so that they could see what they've wrought? I'd guess it's been a long, long time. Actually, that topic is worthy of a post of its own - developers who have been cut off from end users too long, and how easy it is for them to wander off the reservation...

Don Park comes up with a great phrase in the midst of a post on XML 1.1:

Another reason for not using XML 1.1 now is that next version of XML is likely to arrive before XML 1.1 is widely adopted.  Why?  Because engineers are like blacksmiths without a hobby.

Don has a definite way with the turn of a phrase....

I've started streamlining the look of the application; here's the in development main UI:

Here's a link to the application in zoomed mode
Here's a link to the application in "all new 2 pane" mode

Ted Leung discusses fervor in politics. It's funny, but I keep seeing marketing in many of these political posts. Like this:

You can do it -- if you can change someone's mind. But (ideally) you can't force them to change their mind, you actually have to persuade them. Persuasion is tough. There are different components to persuasion. There's the idea you are trying to push. That better look good in the other person's mind. Then there's the persuader. You can have a good idea, but if people don't trust you, you may not be able to persuade them. There's also relevance. You may have a perfectly good idea, and be trustworthy, but your idea may be irrelevant to the hearer. They just won't care. Many people believe that they know how to persuade, when in reality they only know how to give orders.

That's something that all Smalltalkers - and Lispers - should read and ponder. A lot. One of the problems we have in making our case for Smalltalk (and I've seen the same problem, possibly worse from Lisp people) is arrogance. We are so sure that we have a better answer than (fill in today's language of choice) that we tick people off. Instead of presenting what we have, and letting them start asking "how did you do that?", we insist on running down the other technology. The problem with that strategy is that it puts many developers right on the defensive. They chose to use that technology; by denigrating it so loudly, we implicitly impugn their intelligence. That's no way to convince; in fact, it's a sure way to get people walking out of the room.

That's one of the reasons I have started using BottomFeeder and this blog as examples - it's easier to point to fast turn around and ease of development by example than it is to do so by tearing down (Java, .NET, etc). Here's another interesting thing Ted quotes:

Imagine if a mailing list had to issue a formal opinion on the issues discussed, and lurkers got a vote. The high-flow posters would complain that the lurkers votes would not reflect the actual discussion that took place, merely the aggregate opinions of the group, and yet that is how the primaries work. Talking loudest or most or even best means nothing

One of the hardest things to remember is that most of the people you want to influence won't necessarily be asking questions. They'll be sitting back, and listening. And maybe not listening all that hard either - many of them will come away remembering more about the tone and attitude of the conversation - so if you come across as condescending, it'll leave a bad taste in their mouths. The tragedy is, you might feel like you walked away from a long conversation about the efficacy of manifest typing having won a few points - and never realize that lots of people walked away from it thinking "jerk". The longer I stay in this business, the more I realize that Alan is exactly right when he says that the person who leaves an argument without losing his temper wins

Vassili created a nice CSS for the blog, and I've gone ahead and added code support for the kinds of queries necessary to easily (and generically) support this. I'll likely try swapping my page out for the CSS page sometime this evening, and see how reactions go. If it all works out, I'll start making it possible for the userblogs to select from a small range of styles, or create their own and submit it.

With some help from Sames, I now have the entire BottomFeeder obeying the user's text size settings - including the menus, which previously ignored them. This makes the whole thing much more consistent.

Update - The html pane scales up and down with changes in text size as well. To get that work, you'll need to grab the updated Twoflower (html) as well as the updated BottomFeeder. Many thanks to Holger Kleinsorgen for making this possible!

Scoble explains metadata in the context of WinFS:

Anyway, if the file system itself had a concept of metadata, there are whole rafts of ways that metadata could get added to files without having users enter data into forms. Another one I talked about in the interview. What about if you had a QuarkXpress document. And you imported a picture. What if the QuarkXPress document had the words "Patrick's 10th Birthday." Wouldn't the file system be able to assume that "Patrick's 10th Birthday" could be associated with the file named DSCN6133.jpg that I had just imported? Isn't that metadata? Couldn't that be used to improve search? Shouldn't the photo come up now on searches for "Patrick's Birthday Photo?"

The problem with this scenario is the cases where it works badly. You could easily end up with files that have bogus metadata - and then have searches of your file system bring up some of the same crap that comes up on many Google searches. I have very, very little faith in auto-generated metadata - it's too easy to have tons of auto-crap

Here's Scoble on a Trippi (former Dean campaign manager) speech, wherein Trippi blames the media for much of what happened to the campaign. That's amusing. Why? Because that sort of spin is what happens in the media. Journalists are looking to simplify and "boil down" a story. Recall what they did to Dan Quayle, for instance. The same thing happens with the tech industry stories - look at the coverage of Oracle's attempt to buy PeopleSoft, and you'll see a heavy focus on Ellison - because that's a way to simplify the story. This is just the way it is, and it's hardly unique to politics or the Dean campaign. You can see it even in word choice - companies try really hard to make a name common, but then cry foul when said term becomes commoditized (by journalists) into overall usage (think xerox).

The interesting part is how and where blogs play a role in this. In politics, blogs didn't help Dean shape the general view of him - because most of the electorate isn't reading blogs. On the other hand, I think blogs such as Scoble's are doing a fair amount of good for MS - because a meaningful percentage of the developer community is reading blogs - in particular, many of the trade press journalists are reading blogs. The difference with the political world is pretty clear here - Dan Gillmor reads blogs, and writes one himself - the pundits you see on the Sunday shows almost certainly do not. That might change, over time - Virginia Postrel and Andrew Sullivan are examples of pundit blogging - but it's not (yet) enough to influence the voices on tv.

I've updated the site with a new look and feel - Vassili provided the CSS templates and the new layout (and images). It looks great in Mozilla - there are a few layout issues with the link bar in IE that may have to be looked into. I'll be updating the userblogs index page later today.

Panopticon Central has a good article on performance tuning - I especially liked this, and it rings very true:

Rule #1: Don't assume you know anything.

In the immortal words of Pogo, We have met the enemy, and he is us. Your biggest enemy in dealing with performance is by far all the little assumptions about your application you carry around inside your head. Because you designed the code, because you've worked on the operating system for years, because you did well in your college CS classes, you're tempted to believe that you understand how your application works. Well, you don't. You understand how it's supposed to work. Unfortunately, performance work deals with how things actually work, which in many cases is completely different. Bugs, design shortcuts and unforeseen cases can all cause computer systems to behave (and execute code) in unexpected, surprising ways. If you want to get anywhere with performance, you must continuously test and re-test all assumptions you have: about the system, about your components, about your code. If you're content to assume you know what's going on and never bother to prove yyou know what's going on, start getting used to saying the following phrase: I don't know what's wrong It's supposed to be fast!

That's something many of us forget - we know far less about even our own code than we think we do (BottomFeeder and the blog server have demonstrated that to me time and time again!

Another thing that came to me while reading this is this - release early and often. I don't care how good your benchmarks are, actual usage by real users will teach you a lot - far more than benchmarks ever will

With the latest stylistic change to this blog, the server needs a fair amount of weeding - there's tons of 'relic' code lying around that needs to be cleaned out. That will likely occupy me for awhile, as any such "spring cleaning" will need good testing before deployment

Every so often, Scoble posts about IE, or asks for comments on it. Well, I've got one. With the help of a colleague, I've got a nice looking site now thanks to CSS. We have had a few issues though, and have had to add some ugly hacks specific to IE - because the IE team refuses to do a compliant CSS implementation. Come on guys - are you telling me that the mighty MS can't keep up with the guys doing Opera, or Mozilla? I'd really, really like it if MS acted responsibly about this. Most people use IE, because way back when - when IE 4 and NS 4 were battling - IE was better. Enough resting on your laurels - get the heck back to work!

Dare Obasanjo questions the metadata ideas pushed by Scoble a lot better than I did

The Ottawa Carleton Smalltalk Users Group will be holding a general meeting on Feb 25, 2004.

Smalltalk in Eclipse: How to build your favorite language IDE

John Duimovich
Eclipse Tools
Project Lead
Feb 25, 2004, 7:00 pm

The Eclipse IDE is definitely not just for Java. This talk will describe the creation of a Smalltalk IDE on the eclipse platform and some of the architectural decisions that went into building it. We will explore the levels of integration that a language IDE implementor should consider when bringing their language to the eclipse platform. If you have a favorite language and you have been thinking about writing an eclipse plug-in to support it, this talk is for you.

Location Details:

The meeting will be held in Room 5115, Herzberg Laboratories (building 13 on the map ). Pay-parking is available in Lot 1, 2, and parking meters can be found along University Drive. Free parking is available across Bronson Avenue opposite Lot 5. Please RSVP to david@simberon.com if you plan to attend.

Visit the Ottawa Carleton Smalltalk Users Group web site at http://smalltalk.ottawa.on.ca for more details on the group.