Smalltalk Tidbits, Industry Rants

Think again. Here's a post that sums up how many average net readers view RSS:

I am not a technically proficient user. I don't know what XML, RSS, or even HTML stand for. I think the internet is the web, and the web is the internet. I still haven't figured out that I can dial up without having to click on the blue 'E' first.

When I see an orange button, I wonder what it does. I push it. A bunch of garbage text fills my screen, so I assume the button is broken. I don't push the useless button again, and resent it being there.

There are more people in this camp than you would like to imagine. As I said here, for most people a computer is an appliance - they use it to do some task. They don't want to know about protocols, file formats, or network issues any more than they want to worry about the technical differences between the AM band and the FM band. We (technologists) forget this, a lot. For the opposing bozo view on this, read this Guardian article

Periodically, I've had people tell me that they get server errors when posting comments here. I figured out what causes that - the comment entry form had a dependency on cookies, and many people have cookies disabled. So, I've gone ahead and removed that dependency - commenting via the web form ought to work now whether you have cookies enabled or not

Hey, look at that. Those are BottomFeeder screen shots Wow.

Sjoerd Visscher talks about RSS Enclosures:

Christopher Lydon Interviews Adam Curry. I had not yet listened to any of these interviews, and as Adam Curry always as something interesting to say, I thought I'd listen to this one.

So I clicked on the link to the mp3 of the interview, expecting a Save to disk dialog. To my surprise a Quicktime bar appeared in page, and immediately started playing the interview. The download progress bar vastly outpaced the current playing position slider, and the interview played to the end without interruption.

In the interview Adam talks about RSS enclosures. I've never really liked enclosures because you can only listen to them the day after you've read the item it belongs to. So I always forget to listen to them because they are by then right at the bottom of the aggregator page, and it fills the harddisks with things you only want listen to once.

Adam specifically mentions the interview as a good example of an enclosure. So now I wonder if Adam actually knows about streaming mp3.

There's really nothing specifically in enclosures that specifies the "download later" action; that's a Radio specific feature. I recently added support for Enclosures to BottomFeeder, and I thought the whole "download to a folder later" thing sounded complicated and silly - especially in a broadband world. So here's what bf does - if there's an enclosure, you get a link to it right in the item pane. Clicking said link will spawn a browser. I leave it up to the OS/browser combo to figure out what to do with the data that comes from the link - that seems like the right thing to do.

Via Scoble comes word that Google is sending bots to IRC channels. Fascinating. I can't imagine what good that's doing them in search; I'd love to know the rationale.

Misbehaving points to Build a Bear as an example of savvy marketing. They don't know the half of it - my daughter and pretty much all of her friends love the place. The website is well targeted too - all the invitations for my daughter's birthday party were printed straight off the site. The people running that company figured out their target market really, really well.

Ted Leung responds to my response on the topic. I see what Ted is driving at as far as a "crutch" for the curly brace crowed - he may well be right. I do think type annotations as an option are important for inter-language interop (SOAP, CORBA, etc). The other side of those conversations is going to want type information; the less painful we can make it to provide that information, the better.

Cringely takes on MS plans and Ted Leung is thinking about the whole issue. Here's Cringely:

This (having paid developers who's jobs are theoretically on the line) is nonsense. It is nonsense because Steve Ballmer, like Bill Gates before him, confuses market success with technical merit. Microsoft's product roadmap is a manifestation of a business plan, and what matters in Redmond is the plan, not the map, which is in constant flux. How many technical initiatives has Microsoft announced with fanfare and industry partners, yet never delivered? Dozens. That is no roadmap.

I'm not sure this is the right place to attack, because - in this area - I see little difference between open source initiatives and closed source ones. Here's the deal - Product Management comes up with a technical roadmap, based on how they see the industry with respect to their product(s). Let's say you take that roadmap out 3 years. What's the liklihood that, 18 months in, you'll see the industry the same way? Pretty slim - you'll have course corrections - sometimes big ones. There will be things you intended to do that now make no sense - think MS' big turn in 1993-1995 with respect to the internet, for instance. You think their 3 year plan for Windows circa 1992 really had the internet that much in mind? Things change, all the time

I see this every day in my job. We have planning meetings for the Cincom Smalltalk line after each release - and each release comes 6-10 months after the previous one. We look at what we've done, ongoing initiatives, product needs (based on customer and market inputs), and available resources for implementation. We then make plans for what we are going to do in the immediate future, with goals laid out beyond that. A record of those plans since 2000 would show quite a few changed/dropped plans Why? Because conditions - internally, externally, or both - changed. You simple have to react to those changes.

How is this going to differ for open source and closed source projects? Not a lot, I think. Sure, some of the answers are arrived at differently (particularly resources) - but the questions are the same. Cringely picked the wrong hobby horse here - As with war plans, business plans simply don't survive contact with the market - you have to adjust them

Then you need to read this article (via Scoble). Yet another buffer overflow problem. This comes from the continued usage of C and C++. Yes, there are ways of finding those problems. And no, most people won't use those ways most of the time. The answer? Use a managed language - Smalltalk, Lisp, heck, even Java or one of the .NET languages. Or, keep producing security flaws....

I've started adding application events to BottomFeeder - something which will allow plugins to take note of events that are happeneing in the main application. Here's what I've got in the dev stream right now:

This message is sent to the plugin class (the one registered with Bf) when the feedlist menu changes due to a feed selection

plugin 
	customizeMenu: menu
	forItem: anItem
	andFeed: aFeed

that's sent to the class, not to the instance

To get these events, interested objects should register as a dependent of class RSSFeedViewer

• #addedFeedList: feedUrl -- This is sent when a feedlist is successfully added, with the url as an argument
• #addedFeed: -- This is sent when a feed is successfully added, with the url as an argument
• #newItemsFor: -- This is sent when there are new items for a feed (after an update, manual or via the update loop). The argument is the feed object
• #newItemsForAlert: -- This is sent when there are new items for a feed (after an update, manual or via the update loop) which is set for alerts. The argument is the feed object
• #removedFeed: -- This is sent when a feed is removed. The argument is the feed url
• #removedFeedList: -- This is sent when a feedlist is removed. The argument is the feedlist url
• #quitting -- This is sent when the BottomFeeder image is going to quit. The image will not quit before your method returns.

That's what I've got for now; I'm open to input on this!

Then ponder this data from Giga:

Outsourcing Deals Fail Half the Time because most companies lack data on how well internal operations stack up against so-called cheap, external competitors. Pointing to market research by Giga Information Group Inc. and others, Jason Schroedl, director of corporate marketing at newScale Inc., claims that more than 50% of IT outsourcing agreements fail for lack of comparative information. "You need to know how well your outsourcer stacks up against your internal offerings," he says, or you increase the risk of having an outsourcing deal collapse. For example, companies often discover that much of the money saved by sending work outside is eaten up by the costs of managing the outsourcer relationship. Also common is for the outsider to bungle the service quality.

So outsourcing to save money - without a really solid plan - is like flipping a coin to save money.

NewsFacror asks "Is Java Dead?". Wow - not a question I expected to see in the IT press :)

I'm not going to post spoilers or anything - just a sense of disappointment. They could have wrapped the series up by tacking 3-45 minutes onto the second movie; the balance of this was fluff. Cool special effects fluff, but fluff nevertheless.

Want to reach a more targeted audience for your PR pitches? Then use RSS

Here's yet another example of a politically driven rewrite - one that is not taking account of user requirements - and why they are a bad idea:

Earlier this year, I put into production a new part of the UI system, using HotDraw. It allows the users to link two accounts by putting them into a "map" and drawing a line from one to the other. This causes a database update, cache refresh, yada yada yada. Users love it.

We have another project going on, our UI rewrite. This is being redone in Java, with a Web front end. It has to be done using the "anointed toolset", nothing else. I've known this was coming, which was the main reason I did the HotDraw thing. This is driving the Java guys nuts, because they don't have a similar tool with whatever cheezy toolset they're using. My users look at what they have, and say "But how come I can't just draw a line from one to the other like in the old system?"

My favorite complaint is "But you promised us we'd have everything we have now." They say "I meant you'd have everything you had at the time I promised it, not everything that'll ever exist."

And IT people wonder why there's so little sympathy for their jobs getting outsourced. When you utterly ignore users for years at a time, what do you expect?

The referers list on the blog has been broken for awhile, I think - I only just noticed. I took a look, and the break was because of an unintended side effect to a change I had made in the server a few weeks back. It's all fixed now, so the referer list is back.

Chris Admanson wonders if the problem with Java GUIs is that - since they are so easy to create - too many people who should not create GUIs are doing so. He writes:

A couple of people made the point that new and better GUI tools won't necessarily result in better applications. jeremyzacker writes:

The problem with Java GUIs isn't the language, its the notion that any Java developer can write a GUI. Java makes it so darn easy to write GUI code that people who would normally have nothing to do with a GUIs think that they can write one.

He goes on to note that the real problem is with developers who don't understand threading and the Java AWT event-dispatch/repainting scheme, who block the GUI and create apps that appear slow or prone to freezes. Good point, and one that was directly addressed in a recent java.net article by Jonathan Simon. I ran in to similar problems a while back and blogged on ONJava about it.

First off, if you don't have a GUI builder, GUIs aren't "easy to write". In fact, a lot of the issues with event hookups likely derive from people not following the intended practice with the frameworks they get - something a decent GUI Builder does by wiring that stuiff for you (which, incidentally, is one of the bigger complaints about the VW GUI builder - the fact that it leaves an inordinate amount of that work to the developer). If a system where it is "too easy" to build GUI's leads to constant performance problems, which in turn yields few mainstream GUI apps - then I really, really want someone to explain the prevalence of C, C++, and VB based GUI apps on Windows. Visual Studio (and Borland's tools, et. al.) make it very easy to slap together a GUI - much easier than it is in Java. So if the "too easy" premise held water, there would be a dearth of Windows GUI apps. Hmmm

Sean McGrath - and a lot of other people - have been piling on about how voting machines just have to be open source in order to be safe. I don't really care about the politics of this - let's look at the claim though. If no closed source system is safe for voting, then how safe is closed source for anything? i.e., if you advocate this position, then you should not be using WIndows, or Oracle, or SQL Server, or Solaris, or Java, or Smalltalk (outside of Squeak or Gnu ST) - etc. Somehow I doubt that all these advocates are quite that consistent....

Sean McGrath has some interesting observations on the issue:

Non-IT people looking at this smorgasbord of syntax quite understandably develop retinal glaze syndrome. They hope against hope that the whole thing will just goes away some day. The questions ripple out from the water cooler. 'Why do you guys in development want dozens of types of hammers when all you have are nails?'. 'Why doesn't everyone just use Java?'. 'Why doesn't everyone just use C#?'. And so on.

IT people are also inclined to see the diversity as bad or at least conclude that the benefits of a multilingual approach are outweighed by the costs. A consequence of this is that mono-lingualism is rife in commercial IT. Some of the uses I see Visual Basic being put to, or Java being put to - all because of a corporate edict of mono-lingualism - are downright sad. Sad because of lost opportunities - not only to deliver better product quicker, but also to deepen the knowledge of design and implementation techniques in the development team.

There is no single "silver bullet" - picking a hammer will make everything look like a nail, and not in a good way. What IT people ought to do is look at carpenters - or mechanics - and ponder what their way of thinking would translate to in those realms. Would you trust a mechanic who only used a screwdriver with your car?

If someone asks you "what's RSS, anyway?" - then point them to this handy summary

Paul Graham shares some words of wisdom about software development:

For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.

For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.

Realizing this has real implications for software design. It means that a programming language should, above all, be malleable. A programming language is for thinking of programs, not for expressing programs you've already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that's not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.

Spotted in The Doc Searls Weblog:

Novell Buying SuSe. Interesting...

This story has an interesting case study of the development of a web app. The developers ended up going with Lisp rather than Java for productivity reasons - based on their evaluation, they would have done as well with Smalltalk. Take a look - here's an interesting snippet:

As software developers we had the most experience building web applications using Java technology. In the Java world you find all the necessary tools, frameworks, libraries and servers to build almost anything. Java is very good at absorbing all the great abstractions like object technology, garbage collection, model-view-controller, layered systems. However, the Java world is becoming very large and complex. And all things touched by Java (especially the J2EE part) have a tendancy to become overly verbose and cumbersome. This is partly because of limitations in the Java language itself (full static typing, no interactive or dynamic modifications at runtime, little room for data driven programming) and partly it is a community thing (standards reached by consensus and political motivations).

Because we had a past exposure to both Lisp and Smalltalk, we knew that there were very good alternatives to Java. Thanks to Java, a type-safe runtime with automatic memory management and garbage collection became accepted both on the client and server side. People now know that the small price in performance is dwarfed by the advantages in productivity. Lisp and Smalltalk easily match Java feature-wise, but add full dynamic typing, allow interactive and dynamic modifications at runtime and allow for much easier data driven programming. The best part is that current Lisp and Smalltalk implementations often consume less memory and run faster than Java.

The bottom line - if you build the same way as everyone else, the liklihood of your gaining an advantage over the competition is very slim. If, on the other hand, you are willing to look at alternatives - and gain productivity in the process - you have a decent shot at getting a leg up.

Charles Miller has an amusing idea about credit for bad code - adopt the Alan Smithee crediting system

Scoble is excited about using a GPU for Longhorn. Meanwhile, say I wanted to run a server. Value to me: Zip. On the other hand, I could likely run a server using Linux or FreeBSD on an old Pentium.

Steve Maine shows how to "reverse" a dictionary (make keys the values, and vice versa) in C#. It takes about a page of code. The Smalltalk?

dict associations do: [:each |
	dict at: each value put: each key.
	dict removeKey: each key].

It's kind of sad watching the curly brace crowd produce a page of code and call it a major leap forward....

Tim Bray clearly hasn't seen enough people swearing at web based email apps. And when he says people only prefer rich clients for content crteation - what the heck does he think most non-techies do all day, anyway? They create content, using word processors and/or spreadsheets, for the most part. Sheesh.

Scott Knowles links to some interesting notions on business development. Go have a look; it's worth looking at.

I haven't posted a new survey in awhile, but there it is - a new one. Check out the previous survey results here

I've been talking to a BottomFeeder user in the Smalltalk IRC Channel, and the issue of figuring out what version of a plugin he had loaded came up. Bf didn't report that info until about 20 minutes ago, and now it does (assuming you grabbed the update). Seeing this, the following comment flew by in the IRC:

Oh, this is just too great: "[13:47] anyway to have the runtime show its loaded version number?" ... "[14:08] User - grab the update.. it will show plugin version info in the about box"

Now that's the power of Smalltalk in action...

Getting started in VW is likely easier than this - after you get it downloaded and installed. None of this:

First question: "what's a PATH"? I indulged in a brief description of command processing shells. This only led to obvious follow up questions which quickly forced me to confront the fact that, despite ten years of experience with computers, this teenager had never spent any time typing commands at the DOS shell. That's because he never needed to. Returning to the key question of how exactly to "add Java to your PATH" I was greatly relieved to find out that my student had already found a likely looking chat forum, asked about doing this, and within a few minutes recieved the proper incantations. Which was a good thing, since my memory of hacking the DOS PATH has me struggling to edit a long line of crytpic text through a small window in some kind of shell environment editor dialog mess. For the last N years I've been using Cygwin and bash and although that's more familiar to me, I'd hate to have to try and convince a teenager of its charms.

As fate would have it, the fun was only beginning. Our Java programming book began with the legendary "Hello World" example. Creating the text in WordPad was easy enough, but where to put the file? No, not in the C:\J2DSK Folder (what's Java doing there anyway?), and not at the top level in the "My Documents" folder. I advised creating a HelloWorld subfolder for the app. More confusion about getting the "Command Prompt" started in the correct working directory and then (finally) typing:

> javac helloworld
javac: invalid flag: helloworld

With hands waving I explain that javac isn't going to just guess that the file you're referring to is "HelloWorld.java". Software that can't be relied upon to DTRT isn't common in the teenage world of game consoles and web sites and chat clients; but we persevered. Sadly, it feels like climbing up a steep hill with a backpack. And the backpack just got heavier.

heh. VW - in a workspace, type: Transcript show: 'Hello World'. Highlight with the mouse, pick 'Do it' from the pop up menu. Yes, there are issues with getting started in Smalltalk

• The download/install experience needs work
• You can get buried in the blizzard of classes

However, the latter is true if Java as well, and the former - we are working on. In the meantime, we don't have the arcana seen above...

The next release of Cincom Smalltalk is fast approaching. A quick summary of new features can be found here. Here are some of the big things to look for:

• Opentalk for ObjectStudio - We are delivering this in preview (beta) for this release, with full support in the next cycle. This allows object to object communication between VW and OS; OS developers can take advantage of VW features like Web Services, Web Toolkit (etc) - and VW developers can ship a fully native Windows GUI - all with full object level communications back to the main application
• Better searching in VW - it seems like a small thing, but a type ahead matcher in senders/implementors/find class/Store makes for a much nicer development experience.
• Better scalability in VW web applications - a lot of R&D has gone into creating a more scalable application server
• VM plugin support - the Squeak plugin system has been ported to VisualWorks. This will allow for easier integration of platform services
• Beta Support for WinCE - we have started adding support for small devices to VW - and, unlike Java and .NET - not with a cut down library
• Beta Support for dotNET Connect for VW - Conceptually similar to DLLCC, allows you to connect VW applications directly to the .NET runtime

There's a lot of other new stuff as well - check out the summary page. We should be shipping the new VW and OS versions later this month. Stay tuned!

Ole Eichorn is not excited about LongHorn:

If you're still reading and haven't clicked your back button in disgust, let me explain. The most important thing is not how easy it is to build code, the most important thing is how well the code runs once it is built. This concept seems to have escaped the Longhorn developers, and from this viewpoint Longhorn and its underlying technologies are pretty unexciting.

Ole goes into quite a bit of depth as to how and why performance will suffer in LongHorn - along the way, he makes a number of interesting observations - one of which I disagree strongly with:

I can appreciate that there may be debug code and features which haven't yet been optimized, but performance isn't something you add in later. It has to be designed in from the start. There were zero cases where I heard a presenter at the PDC say "this was done for performance". Functionality for developers was the guiding design principle.

Uh, no. The mantra is:

• Make it work
• Make it fast

In that order. In that regard, MS might even be approaching things the right way (although I have my doubts about their ability to get there). I suspect that this thought comes from Ole being a C++ developer - C++ being a language that is painful to refactor and introduce change into. Using better languages, one can rip out layers that cause problems and replace them (I've done this with parts of BottomFeeder all along, for instance).

Even so, the article is a good read, and is something that the LongHorn cheerleading squad should read and respond to.

Blaine Buxton points to John McIntosh's OOPSLA 2003 Report. As usual, John takes excellent notes. Sounds like it was a fun show.

I've ignored Enclosures for about a year now. With 3.2 of Bf just shipped, I figured I'd have a look at them again. I added simple support for enclosures this evening. What does that mean? It means that, if an item has an enclosure, then you'll see a clickable link in the item pane. I decided against the whole background/overnight downloading thing for a couple of reasons

• complexity
• available bandwidth

I think most people using an aggregator, at least at this point, are on a high speed connection - so the time savings for downloading overnight are vanishingly small. Additionally, I didn't really want to have an extra (easily forgettable by users) directory of large content that would build up - building the software infrastructure for managing that just doesn't seem reasonable to me at the moment. Heck, maybe I'm wrong - if I am, Bf users will tell me. In the meantime, just providing a link to the content in the item pane is the simplest thing that could possibly work

Charles Miller contributes his 2c on what a weblog is. Quicktime required to read the presentation.

I linked to a d2r piece on "what's a weblog" here - today, he covers syndication. The only flaw is that he doesn't mention BottomFeeder :)

I've just released BottomFeeder 3.2. A summary of what's new:

• Proper handling of Http Moved responses. 301 is followed, with links updated. 302 is followed, but links are not updated
• With 301/302 responses, relative urls are now supported
• Added filtering of feed items. Users can filter on title/category/content, and do so at a global level or on an individual feed level. Filters at the feed level override any global filter
• The 'New' view can show the 2 pane view, or show a tree that is restricted to feeds with new items (and folders that contain such feeds)
• Added support for defining Amazon search feeds. This uses the Amazon API for defining RSS enabled queries
• OPML feedlists are more properly supported; in previous versions, the defined OPML directory structure was not followed. It is now
• Instead of proxy settings being off when the server name is deleted, there is a checkbox in settings for turning proxy support on and off
• Updated the Http access to properly handle proxy responses of 100 Continue
• When Feed Auto-Discovery fails, we return a more useful error message
• Fixed some inconsistencies in menu items that were enabled/disabled based on the online state of the app
• Added an optional ability to track timeouts on feeds across multiple updates, and mark a feed as 'bad' if it failed too many times
• If updates fail on 10% or more of the feeds in a row, the user will be prompted as to the online state (unless the setting is turned off)
• A new, updated version of TypeLess ships with this version of BottomFeeder
• Addressed the problem whereby images in the html view sometimes overlaid text.

There's a lot of new stuff, and a lot of improvements to what was already there. The upgrade tool can be used; no need to re-install.

Spotted in StronglyTyped - you can build PacMan in it! Who knew Excel was a game platform?

The .NET guy is protecting his blog from comment spam - so far, I think I'm protected mostly by obscurity. Entropy seems to be increasing in the blog world, just like everywhere else...

Doc Searls puts his finger right on it - the things that keep the RIAA up nights:

Just 'cuz it's new water doesn't mean you can't learn how to swim in it. In fact, the networked world is one where you get to make your own water. The big industries aren't in charge here, much as they like to think they are, or should be. This is the People's Market. Nothing communist about it, either; because the Networked World loves to support markets, commerce, transaction, conversation, relationship, opportunity, enterprise and fun - all those qualities that make real markets the real cradle of real civilization.

In fact, this is the chance that artists finally get to make markets the way they'd like. To love business, even. Trust me, you can do it.

Cutting out the layers of separation between producers and consumers is what scares the crap about the RIAA - the rest is all just sturm and dang in concealment of that baseline fear.

Via 0xDECAFBAD comes word that Windows might actually have a decent shell in LongHorn. Now that's the sort of improvement that Scoble should talk about, instead of the fluff he normally gushes about in LongHorn....

Hey this is pretty cool - a set of RSS feeds for comics. You can get Dilbert via RSS now - very cool.

BottomFeeder has had an issue with images overlaying text. Basically, the support in the html component we use for tags with layout information embedded is somewhat limited. I found a work-artound for this issue yesterday, and images should no longer show up on top of text in the item pane - which makes things much nicer. I should have looked into this long ago....

Heh. KIds come to my door:

Them: Trick or Treat!

Me: We'll take the trick

Them: Huh??

Me: What, no trick? I'll have to take all your candy

Funniest response to that yet? One kid yelled No! and ran off. Yes, I do give them candy after the exchange :)

What do you want, I'm wearing a jester outfit this year...

If you get asked "What's a weblog?", then read this. I'll have to consider my answer to that question sometime, but the post I linked to is a great summary.

Java Today has an article on rolling your own vs. buy - an old argument, actually. The "Huh" part for me came here:

He changes the too frequent parsing of the feed that he described in his first article by adding "a new class to handle the selective updating of feeds based on the provided update information." In the second half he creates a blog roll using " the JSTLforEach tag to loop through the feeds, creating a list of links to the home pages for the feeds. For good measure, we also print the dates of the feeds, so we can see when each one was last updated."

Huh? Why would I be parsing xml when I create a feed? I have an actual object model here - the blog entries are all objects - I push a static xml file out whenever there are new entries/updates/comments, and have the server create XML from the objects using a Sax driver. Having the static feed files reduces load on the server as well. As to update times, well - that's part of the object model I created for the entry objects. As to the blogroll, that's a list of what I read on a normal basis (i.e., created by hand) - not a list of things I happened to link to....

We are throwing a Halloween party this evening, so we are deep into party prep. Happy Halloween all!

Presidential Candidate Howard Dean gets carried away - literally :)

Dave Winer has linked to a bunch of new feeds from ABC News. The feeds are a little funky, but BottomFeeder handles them ok. RSS is spreading wider and wider...

Michael Lucas-Smith is not amused by the things MS calls refactoring.

Microsoft tries to create greater lock in with LongHorn:

Michael Wallent in this morning's Longhorn UI panel: "We want to make existing applications look like DOS applications when they run on Longhorn."

His point was actually that Longhorn applications will exhibit not just different visual style but different behaviour. It is not a matter of applying Avalon chrome to an existing application. The actual interaction must change to fit the Longhorn Way. That means WinFS integration, shell visualisations and so on.

Hey - what if Windows isn't the only platform I care about?

Update - Apparently, I'm not the only one thinking this

Here's a perennial favorite in VisualWorks: You have a dataset widget, and you would like to dynamically add a column at runtime. How do you do that? Well, there's been a support tip on this for years - and I made use of that tip in BottomFeeder. The all new view has 2 modes:

• Show a restricted tree, with only the new items
• Show all new items in a 2 pane (no tree) view

For the latter view, we add a column (with the feed name) to the dataset, so that you can tell where the item in question came from. So how is that accomplished? Here's the relevant code snippet:

	table := self widgetAt: #feedListID.
	columns := table columnDescriptors asOrderedCollection.
	columnSpec := self class zoomedColumnSpec decodeAsLiteralArray.
	columns addFirst: (columnSpec columnWithBuilder: self currentBuilder).
	table setColumnDescriptors: columns.
	table invalidate.
	self hasAddedColumn: true 

The spec is the spec for a single column - I extracted a column spec (copy) from a dataset spec, changed the attributes to match what I wanted, then saved the result as a class method. Then, at runtime, I can grab that spec object, and just slam it into the dataset. It can be removed just as easily. That's it!

Supporting the new in tree view in BottomFeeder, I had to get the tree widget - the one holding the feeds and folders - to dynamically change based on attributes of the contained items. As it turns out, the tree widget already supports that quite easily - Have a look at class TreeModel. From the class comment:

childrenBlock:  block with one argument.  Is evaluated to get an
object's children.  The result is expected to be a
SequenceableCollection.  Defaults to: [:ea | ea children].

So the childrenBlock is what determines what the tree shows. Change the block, and you change the items displayed. In my case, I simply had to add query methods to the folder and feed objects. These methods look like this:

RSSFeed>>displayChildren
	"custom display of items"

	^#()


RSSFolder>>displayChildren
	"custom display of items"

	^self children select: [:each | each hasUnreadItems]

Feeds have no children; they are nodes. Folders, on the other hand have to be tested. The #hasUnreadItems method actually does the work of drilling all the way to the bottom of a given folder, in search of unread items. The main point is though - in order to change the way the tree displays, all I had to do is send this message in response to a user request:

	self feedTree list childrenBlock: [:each | each displayChildren].


which replaces the default block of:

	self feedTree list childrenBlock: [:each | each children]

And that's all there is to it. Modify the block that determines children to display, and create any necessary support protocol in the objects you put in the tree. I had been resisting looking at this, as I somehow convinced myself that doing this would be hard. I got constant prodding from Micahel Lucas-Smith though, and - as a result - got a new feature added to BottomFeeder

Tests are fine, but - If your test sucks, it proves nothing. That's what I took away from this afternoon's little discovery. I had not been able to reproduce the reported problems with the all new in tree view for Bf - and it was the sample feed setup (the test) that was wrong. My tests weren't deeply nested enough to show me that I simply wasn't following the tree nodes down all the way - and thus, missing some of the nodes. Having fixed that, the view now works as expected. That gets me a step closer to allowing 3.2 out the door - it was the last known issue.

Post 3.2, the code will switch to VW 7.2 - and a new runtime. With a new runtime, I'm breaking the system into more loadable components, so that updates are less monolithic. I'm also going to start looking into a way to save/load the feeds and feed info faster.

Geek Humor in movie titles....

I saw this news yesterday - Microsoft laid this guy off because of a picture he posted to his blog. The issue seems to be security - MS is a large company with a number of enemies, and they have policies dealing with physical plant security - i.e., no photos. This photo seems pretty inocuous, but it also looks like they were simply following policy. It's another thing you have to be careful about in corporate blogging - bottom line, you kind of need to imagine that everything you write is actually a phone call at corporate headquarters - and ask yourself whether such a phone call would be appropriate.

The Register reports that there are emerging issues with outsourcing in India:

India's business process outsourcing market is expanding rapidly, but cracks are beginning to show. Concern is growing over a tightening supply of skilled IT workers, and a high rate of attrition among workers in the sector, particularly in offshore call centers.

So - demand for these jobs is up - which tightens supply, makes people move between jobs more quickly - and raises costs. Not a terribly big surprise - Silicon Valley watched that progression in a big way during the late 90's, and it's simply repeating itself in India. Watch for costs to rise enough that over the next few years - given the inherent overhead of outsourcing - savings will pretty much evaporate in India. That will drive the business elsewhere, but:

• English language skills aren't as prevalent elsewhere as they are in India
• The problems brought up in this article are going to repeat no matter where the outsourcing goes

Basically, the savings associated with outsourcing are going to be a pretty short lived phenomenon.

Ted Leung has a suggested Python project - creating an automated type annotater for Python programs - the stated goal being to provide a tool that could be used on Python files to give some confidence that type unsafe operations were not going to happen. IMHO, there's a better goal for that kind of thing, and it's something we see the need for in Smalltalk - communication with external systems. Whether we think it's a good idea or not, the majority of the non-Smalltalk development world is manifestly typed. In particular, the popular RPC mechanisms - CORBA, SOAP, RMI, DCOM - all expect manifest type information. What that means for a Smalltalker (or Python developer) is a need to annotate the interface - IDL, WSDL, etc. Having something that reliably inferred types for the purpose of generating those interop specs would be highly useful - and, IMHO, far more valuable than any other output. A good set of tests proves more about correctness IMHO.

Via Doc Searls comes this link - a shot of the smoke plumes from the California wild fires from space. Whoa