Smalltalk Tidbits, Industry Rants

Tip of the hat to Terry Raymond for this morning's wake up humor

I've posted a new TypeLess plugin to the BottomFeeder site. Just use BottomFeeder to download it and restart. I'll be working on a more reasonable update system today....

Matt Croyden quotes Brad Wilson:

At this point in my life, if a site doesn't offer RSS, I don't have the time to consume it.

What he said!. I find that I use BottomFeeder to follow news, and rarely bother with sites that don't provide a feed. it's just so much easier to have everything organized in one place, and updated in the background.

Hey, we got there first!. Seriously, this is a great idea. The Cincom Smalltalk team have been using RSS to track two different source code repositories (one public, one internal) for months now - and we have another two feeds that track our internal bug database. The developers have found these to be really useful, and I expect that the CVS crowd will discover the same thing.

I've changed the update mechanism for BottomFeeder. We were delivering patches automatically at startup. The next release (and current dev builds) don't do it that way. Instead, all components can be updated on the fly - just hit the update button on the Toolbar, and a list of appropriate updates will be shown. If you decide to upgrade, the update(s) will be downloaded and loaded into the running system.

This is also the way you select plugins for download now.

I keep seeing posts on how cool some complex blog API is. I have a client side API to this blog too. It's dead simple - I send an URL encoded form to a servlet interface - encrypted. This is truly simple, and required vitually no back end coding at all.

Compare that to a SOAP or XML-RPC interface. You have to set up a new server (yes, this is simple in Smalltalk). There are no real security standards using SOAP or XML-RPC, so you send everything in the clear. You spend tons of time creating the whole mess.

Or, you use technology that already works....

Is Marylanders panicking. There's snow falling, and more in the forecast. I think last night's weather made a mistake; they were calling for one to three inches starting tonight. Oops.

Scott Knowles has an interesting post on the trend towards corporate blogging:

I said a few days ago rule numero uno for those looking to use blogs to promote their business is to "get blogging." According to some fellow bloggers, it looks like some are already starting out of the gates without a clue. Jupitermedia CEO, Alan Meckler has started a blog of his own.

But according to Doug Fox, "I think Meckler's weblog misses the mark. His barrage of attacks against Fred Rosen, CEO of Key3Media, producer of Comdex, may get him some short-term publicity, but it does nothing for his contention that he grasps the premise behind weblogs. Yes, Meckler writes in the first person, but he doesn't seem to have the slightest notion that blogging is, for the most part, a communal, shared experience."

It's all about the links. Scott is right when he later (read the whole thing) points out that a blog without links is going to be an island. I've gotten a fair number of my readers (and commenters) by linking to articles I've found interesting; deciding against such outside links is going to limit that cross-fertilization.

I started blogging here on my own. Heck, in the early days I just thought it would be cool to have some blogging code written in VisualWorks, and that the blog would be a community effort. It's led down a twisty path though. Almost immediately, I got an email from someone asking for an RSS Feed. At the time, I had no idea what RSS was. But that pushed me into creating a feed, which led to BottomFeeder. That eventually led to the blogger meetup, where I met Scott - and now to my comments on his post.

It's all about communal knowledge and feedback.

The Fuzzy Blog worries about how google will treat blogs over time:

So here's my question -- When will Google start to view blogging as subverting the ranking system? Am I really the most important Scot Johnson in the world? Is Jeremy Zawodny the most important Jeremy? Is Kasia the most important Kasia? Right now bloggers just plain love Google but a lot of that is because of how Google treats us. They view our blogs as "legitimate link farms". So when are we going to become illegimate?

He's getting to this because of how Google deals with people who try to game the page rank system. One could view blogs as gaming the page rank system, I suppose - heck, I come up third and fourth in Google.

On the other hand, as has been widely reported, Google bought Pyra recently, so I would think that they have a positive view towards the whole blogging thing. Time will tell....

I haven't taught the Smalltalk class in a couple of weeks - the snow storm last week blew away a class, and if the snow keeps up the way the forecast calls for, tomorrow's class will be off as well.

In the meantime, I was very impressed with what happened last time around. I decided to introduce them to some rteal coding - with a browser. We took a very simple example - a simple "calculator" application that could add numbers. So we defined a class:

Smalltalk defineClass: #Counter
	superclass: #{Core.Object}
	indexedType: #none
	private: false
	instanceVariableNames: 'counter'
	classInstanceVariableNames: ''
	imports: ''
	category: 'Calculator'

We actually use Squeak, since it has a lot of cool things for introducing programming - the Alice stuff in particular. Anyway, they stumbled through the creation a bit - but they got the basic class/instance split more quickly than I thought they would. Once we implemented the ' ' message, a light clicked - they got it!!. They they ran off and did subtraction, multiplication, and division - the biggest question they had was what sign to use for multiply - they were not familiar with the asterisk notation.

But they got it. Very impressive, and lots of fun.

I've updated the BottomFeeder toolbar. Dave pointed out to me the the binoculars icon was typically used for search, so I made it the icon for the search tool, and added a different icon for upgrades. The new parcel is up, and should show as available for people using the more recent builds. It's also up for download from the dev build page

There's an ad running on my local radio for a fitness center, but the first thirty seconds or so sound like a patio version of the old "Spam Spam Spam" Monty Python Routine. I hadn't paid any attention to it, so the first few times it ran, I actually thought it was an attempt at self parody - i.e., an ad for Spam.

This time, I heard the end. Still wasn't clear though - the whole thing was implicit. I think a lot of advertisers are getting to be too clever by half. I see this on TV as well - ads that I have no idea as to what they are for unless I pay close attention. Maybe that's the point, but guess what? If I don't see the point in the first few seconds, I'm gone.

I spotted this post on Clarence Westberg's blog:

If I do Type.GetType("MyClass") it doesn't work, that is it doesn't find the class. If I do Type.GetType("MyNamespace.MyClass") it works but only if I am in MyNamespace. If I have a using statement and a reference it doesn't work either Type.GetType("MyOtherNamespace.MyOtherClass"). How do I get the type of a class not in my namespace?

Chuckle. Yet another problem generated by manifest typing. Over here in the Smalltalk pond, we don't have that problem. Actually, if you read through his various posts on C#, it's as good an argument for using Smalltalk instead as any I've seen - bogged down in syntactical issues, and not addressing actual business problems.

Anthony Lander has just posted a SourceForge project page for Pongo. Pongo is also available as a plugin for BottomFeeder. If you want to help out, you'll need access to the public store.

Well, it's what I thought - Buffy is done in May. It's been a really great ride, and this year's show looks like it's going out on a high. I'll miss the show, but I think Virginia Postrel is right - the show would be a shadow of itself if they tried to drag it forward another year.

There's another base image update being uploaded to the dev pages. This one adds back in the Mouse Wheel support for X11, after Reinout Heeck pointed me to a new release of that code that works with VW 7.1. If you have a dev build already, just grab bottomFeeder.im.gz (non-Windows) or btfWin-2.8.tar.gz (Windows) and replace bottomFeeder.im or bottomFeeder.exe respectively. I'm replacing all the base builds as well, so that new downloads will get the right stuff.

The base image should settle down and require no full replacements once VisualWorks 7.1 is released, and that's scheduled for the end of March.

I just added referer tracking to this blog. Just hit the referer link at the top of the page to see what links we have today. I have a process running that updates the list every three hours, which should be often enough.

There's a facinating Register story today on a Paypal screw up. Apparently, they had the Pound Sterling to US Dollar conversion wrong for part of the day:

PayPal's dollar-sterling exchange rate today at 1 pound = 97 cents made some quick-witted individuals very happy. The real rate, as published at Xe.com's very fine currency converter, is 1 pound = USD 1.57861.

So what about ordinary Joe Punter who simply wanted to pick up a bargain or two? Today was not the day to use PayPal if you were paying in sterling, as this sad tale from Reg reader Bryan MacErlean, shows.

I paid $669 for a watch today got charged 680 pounds. Contacted paypal support initially they were adamant that 'the rate is blended and calculated by the computer so must be right'. 20 minutes later at international rates I managed to get put through to someone in finance only to get fobbed off to yet another person. They still didn't admit it was their fault - they think the USD is worth more than sterling. I am unsure about my legal position on this one...

Whoops....

Gordon Mohr found another absurd patent claim. Just listen to the claim:

Claim link

A system and method for file management is comprised of hierarchical files systems, referred to as "areas." There are three types of areas: work areas, staging areas, and edition areas. A work area is a modifiable file system, and, in a work area a user can create, edit, and delete files and directories. A staging area is a read-only file system that supports select versioning operations. Various users of work areas can integrate their work by submitting the contents of their work area to the staging area. In the staging area, developers can compare their work and see how their changes fit together. An edition is a read-only file system, and the contents of a staging area are virtually copied into an edition to create a frozen, read-only snapshot of the contents of the staging area. One use of the system and method for file management is as a website development tool.

Go read Gordon's take; I'm not going to improve on it.

This is amusing - hat tip Gordon Weakliem

I hope there's more to this story than this:

During the afternoon, Neil came over to me and said that some of the other speakers (no names) had been incensed that I covered Java in my talk and said they had asked that I not participate in the evening Q & A.

And this:

The "Java Jam" cruise doesn't seem to include any speakers with a .NET background, and given this story, ".NET Nirvana" meetups in the future don't hold much promise for a second chance.

There's politics everywhere...

A lot of people commented on David Stutz's letter to Microsoft this last week. I gave the whole matter a few days to settle in before deciding to comment. He's got a lot of good points to make:

During this period, most core Microsoft products missed the Internet wave, even while claiming to be leading the parade. Office has yet to move past the document abstraction, despite the world's widespread understanding that websites (HTML, HTTP, various embedded content types, and Apache mods) are very useful things. Windows has yet to move past its PC-centric roots to capture a significant part of the larger network space, although it makes a hell of a good client. Microsoft developer tools have yet to embrace the loosely coupled mindset that today's leading edge developers apply to work and play

This is dead on - and some of the DRM rumblings could make it worse. If that stuff comes in, mobile use of Office tools is going to be hard - and that's not in tune with where things are headed at all. Then there's the crap that is Word HTML format - bleah!

There's more good stuff:

As networked computing infrastructure matures, the PC client business will remain important in the same way that automotive manufacturers, rail carriers, and phone companies remained important while their own networks matured. The PC form factor will push forward; the Pocket PC, the Tablet PC, and other forms will emerge. But automakers, railroads, and phone companies actually manufacture their products, rather than selling intangible bits on a CD to hardware partners. Will Microsoft continue to convince its partners that software is distinctly valuable by itself? Or will the commodity nature of software turn the industry on its head? The hardware companies, who actually manufacture the machines, smell blood in the water, and the open source software movement is the result.

This is, I think the crux of the matter. Everything is network connected, and it's only going to go more that way. Software spaces are being relentlessly commoditized - it started with tools, and is rapidly moving through other aspects of the business. Microsoft is not unique in this - most software vendors (including the one I work for!) are still not clued in on this, and will be in for a series of nasty shocks as it rolls through the industry. It's more than offshore outsourcing; it's an entire market changing shape.

If Microsoft is unable to innovate quickly enough, or to adapt to embrace network-based integration, the threat that it faces is the erosion of the economic value of software being caused by the open source software movement. This is not just Linux. Linux is certainly a threat to Microsoft's less-than-perfect server software right now (and to its desktop in the not-too-distant future), but open source software in general, running especially on the Windows operating system, is a much bigger threat. As the quality of this software improves, there will be less and less reason to pay for core software-only assets that have become stylized categories over the years: Microsoft sells OFFICE (the suite) while people may only need a small part of Word or a bit of Access. Microsoft sells WINDOWS (the platform) but a small org might just need a website, or a fileserver. It no longer fits Microsoft's business model to have many individual offerings and to innovate with new application software. Unfortunately, this is exactly where free software excels and is making inroads. One-size-fits-all, one-app-is-all-you-need, one-api-and-damn-the-torpedoes has turned out to be an imperfect strategy for the long haul.

Digging in against open source commoditization won't work - it would be like digging in against the Internet, which Microsoft tried for a while before getting wise. Any move towards cutting off alternatives by limiting interoperability or integration options would be fraught with danger, since it would enrage customers, accelerate the divergence of the open source platform, and have other undesirable results. Despite this, Microsoft is at risk of following this path, due to the corporate delusion that goes by many names: "better together," "unified platform," and "integrated software." There is false hope in Redmond that these outmoded approaches to software integration will attract and keep international markets, governments, academics, and most importantly, innovators, safely within the Microsoft sphere of influence. But they won't .

There's a lot of wisdom in that for us Smalltalkers as well - this is a bad time to live on an island. We are addressing that in VW - Web Services, truly headless servers, the separation of the tools from development.... but the train is on the tracks, and hurtling towards us.

Go read the whole article - it's well worth your time.

I've done a fair bit of work on BottomFeeder over the last two days, and also integrated the latest Twoflower work from Holger. The latest stuff is available as new parcels from the dev page. The upgrade mechanism now works properly, and Twoflower now supports the # links and horizontal scrolling - and the text copying has been improved as well. Lots of good stuff - I think a 2.8 release is pretty close.

I've seen this idea posited before - that development of software is a lot like the development of a movie. i.e., the process is very expensive, and the end results of the project (ROI, profit, whatever) are up in the air until the very end. Comes this post on the subject, relating it to the innovations of Disney early on:

The work seems to have been structured around a core consisting of Disney himself, and a handful of people that were responsible for the music, the visuals, and so on. The entire machinery was no doubt coordinated using very high volumes of face-to-face communication, model sheets(guidelines for how to draw the specific characters), and written guidelines describing the mood or tone that should characterize the movie in production. They used rough prototypes to get a feel for each scene, which were discussed by a group of people before being done full-out. (I guess they did another round of prototypes if the first was deemed not good enough.)

Reading this book has convinced me that there's much to learn for programmers in studying how movies are made. (See also my post Storyboards: a pragmatic tool for coordination) Movies are very expensive to make, and a flop can often be disastrous for the movie company; yet, straightforward methods such as face-to-face communication, sketches, and storyboards, are seen as effective means of executing a project. In software, however, the tools must be advanced and expensive, or they are ridiculed; the obvious simple ones are often not even considered.

Read that last part again - there's a lot of truth there. Consider the plethora of (to my mind) nearly useless modeling tools out there - they are hard to use, expensive, and don't relate to the code well at all. And yet most large teams use them, typically as part of some godforsaken process.

Now consider storyboards. Sounds a lot like what the Agile Alliance guys have been talking about, doesn't it?

Here's more:

In software, however, many people seem convinced that building software is like building bridges or houses, and therefore try to adopt processes from those worlds.

From reading The Art of Walt Disney, it's obvious to me that the Disney process was based on exploration, communication, feedback (adaptation), freedom. Despite the image of Walt Disney as the master planner, I'm convinced that the animators were free to be creative both regarding the film and the aspects of the process that involved them. The team constantly tried new things, and met to discuss them and find out how they could improve things. Today in the software business, the followers of the agile movement talk about agile as if it would be something new. In fact, Disney were agile (because they had to be).

Nothing new under the Sun, I guess - except for this insight. What the software development world needs is a good kick in the pants. Or more succinctly, let me post one of my all time favorite email signature lines:

"I think we've shown simplicity to the world ... but I don't think we've jammed simplicity down the throat of the world to the extent that we really should have" - Ron Jeffries

I've had a feedback icon on the toolbar for some time now, but it was using an API fairly specific to this blog. I changed that behavior today, based on some feedback from Rich Demers (who's been doing doc, and is now lending a hand with the code):

• If the feed supports textInput, enable a "Feed Input" action in the Tree feed popup. BF opens a "Feed Input Window" that simply displays the description of the textInput, provides an input area for text entry, and provides a button that is labled as required by the title of the textInput. This allows for other, apparently ill-defined, uses of textInput.
• If the feed supports textInput and provides a title of "Comment", then enable an "Item Input" action in the item popups for the feed. BF opens a "Item Input Window" that displays the description, has input areas for "Posting Name" and "Comment" and has a button labeled "Submit Comment". In this way, feeds (like you blog) that want to support item comments have a way to tell aggregators to associate the item's timestamp with the feedback.

By keeping these two types of feedback architecturally separate, we could propose this convention to the RSS community and we could easily adjust to other proposals.

I haven't updated the UI to this full extent, but the behavior is now implemented that way in the dev builds (latest parcels on the site).

I posted a couple days ago on the way blogs cross reference just about everything. I was catching up on the feeds I follow when I came across this post from Sam Gentile:

The other thing you touched on is the continual fustration of sites that I frequent that still don't have an RSS feed. I have come to the viewpoint that if you don't have an RSS Feed, you shouldn't have a blog. Maybe thats harsh and there is a whole another model but I can't spend the time to surf a 150 sites a day. If its not on an RSS feed, I won't see your site or read it, and you know what? Most other people won't see it or read it either.

Certainly that's true for me. I tend to follow links out from my aggregator, BottomFeeder. If I don't see it there, I'm highly unlikely to see it at all.

is it that I hear this over and over:

After backing up all my important data and a 2 hour install process, I've managed to get Visual Studio.NET installed on my desktop machine. Some of my friends have had their machines munched by the install, so I'm grateful that I can still get work done -- and yes, I have friends who use VS.NET.

Let me tell you, I have never worried about an installation of VisualWorks munching my desktop.

Have a look at this Tucows listing for ElastoLab, and this one for FreeCAD. Both get 4 cows (on a scale of 1-5). Very cool. I haven't used FreeCAD, but hear good things about it. ElastoLab I can personally recommend - my daughter liked it, and my nephew was enthralled.

Awhile back I made this post is response to this set of criticisms of BottomFeeder. I've addressed the layout issue (the tabel displays far more items), and the application is now delivered as a runtime and a set of loadable components (including plugins). The runtime is changing fairly often right now, since VW 7.1 (on which BottomFeeder is built) is still being developed - that will settle down at the end of the month. At that point, updates will be delivered on demand, when they are available - as small downloads.

In the meantime, I came across this post by Sam Ruby, comparing Syndirella to Radio's aggregator. Well

But Syndirella requires an additional step of marking every blog entry read in each weblog. Or for one to lean on the space bar for a while.

All by itself, that's a problem, IMHO. In BottomFeeder, you can toggle the status of individual items, all items in a feed, all feeds in a folder, orf all feeds, period. It's a feature I use a lot - there are feeds I subscribe to (such as SourceForge) where all I want to do is scan the headers and then mark them all read, unless some project I'm interested in pops up. Is the Bf UI perfect? Heck no, there are warts we aren't happy with.

The BottomFeeder UI will be getting a facelift after the 2.8 release as well. We would like to get 2.8 out in conjunction with VisualWorks 7.1 (end of this month). After that, we are looking at a more Outlookish style interface.

So Dr. Pepper has noticed that weblogs are big, and is trying to promote a new drink with them. This Instapundit comment is humorous:

I don't think it'll work, though, and the reason isn't weblogs, but the drink, "Raging Cow," which is described as a "milk-based product with an attitude."

The last time I had a milk-based product develop an "attitude," it was because of insufficient refrigeration.

Heh.

Dell seems to think so

Dell and Sun executives provided one of the more interesting behind-the-scenes battles at last month's LinuxWorld.

In one corner was Randy Mott, Dell CIO. In his keynote presentation, Mott urged IT managers to consider a cultural revolution that would involve ditching Unix. Mott's opening slide was a mock obituary with the headline, Unix is Dead.

In the other corner was Jonathan Schwartz, Sun software czar. Dining with journalists and customers, Schwartz reminded us that there are some tasks for which Unix remains the only viable solution. To underscore his point, he noted that Dell still uses Sun-based systems to manage its supply chain.

Although such hyperbolic sparring is typical of this industry, I decided to probe a bit deeper into Dell's talk of revolution. Dell's response: The company is in the process of migrating off those Sun-based systems. If true, this would be consistent with a key point in Mott's presentation: CIOs and IT managers need to focus the lion's share of their IT resources on innovation rather than maintenance of the status quo. Otherwise, said Mott, companies and even entire industries will never realize their full potential.

All part of the relentless commoditization going on in the entire IT sector. I think Dell's right

I'm on a 2 day trip to customer sites. I'll likely be posting during the evenings. During the day, I'll be visiting with customers.

Here's an article of interest on the O/R topic. i first learned about Prevlayer at an XP event in Brazil; think BOSS in memory, with constant checkpointing:

A reader writes:" Persistence for object-oriented systems is an incredibly cumbersome task to deal with when building many kinds of applications: mapping objects to tables, XML, flat files or use some other non-OO way to represent data destroys encapsulation completely, and is generally slow, both at development and at runtime. The Object Prevalence concept, developed by the Prevayler team, and implemented in Java, C#, Smalltalk, Python, Perl, PHP, Ruby and Delphi, can be a great a solution to this mess. The concept is pretty simple: keep all the objects in RAM and serialize the commands that change those objects, optionally saving the whole system to disk every now and then (late at night, for example). This architecture results in query speeds that many people won't believe until they see for themselves: some benchmarks point out that it's 9000 times faster than a fully-cached-in-RAM Oracle database, for example. Good thing is: they can see it for themselves. Here's an article about it, in case you want to learn more.

Check it out.

Gordon writes on a topic brought up by Sam Ruby. Here's what Gordon said:

The most important RSS element: title. Jon Udell has said it before today Dave Winer says "Unless the RSS has a title element, it's going to be kind of goofy". And here I sit, blogging via email to Radio, creating yet another RSS item without a title. I usually try to fix it when I get home; I hate it when other bloggers don't use titles. Forget about the aggregator on the Start menu. How about putting title support into mail-to-weblog? Just look for emails that start with a title element, extract that and make that the title of the post. Come to think of it, Sam Ruby's idea to create a weblog API that simply accepts RSS items makes more and more sense.

Maybe. That will involve some SOAP or XML-RPC interface to dump stuff up. While it's not hard to create such things, it is work. I really don't like the email to blog idea either - I have less than no interest in getting into the ever escalating battle with spammers. So what do I do? I have a simple Form (a BottomFeeder plugin!) which creates an URL encoded form. It then does a POST to the blog server. That meant a servlet - a few lines of Smalltalk - and a client GUI that does an HTTP POST - again, a few lines of Smalltalk. Additionally, I encrypt everything I send up that way - using Base64 encoding to handle the binary that results from encrypting. This is simple. I can send data via port 80, using simple web protocols, and not have to worry about spam or custom servers.

Rob Fahrni posts that he misses his RSS feeds while he's traveling. I don't; I'm on the road, on a slow dialup - but BottomFeeder is getting my feeds. All I had to do was fill in my proxy information, and off I went...

Rob Fahrni posts that he misses his RSS feeds while he's traveling. I don't; I'm on the road, on a slow dialup - but BottomFeeder is getting my feeds. All I had to do was fill in my proxy information, and off I went...

I had lunch with a client today - actually, a group of consultants who have outsourced work at (insert big company here). They told me that the client would ideally like to see all work done in blah, so that they could more easily redeploy developers from project A to project B. For this reason, they aren't that interested (yet) in .NET, since they don't want developers using any old language.

I think that's just silly. I bet none of that management believes that the same screwdriver can be used for all home repair jobs. And I bet most of them have a vacuum cleaner and and something like a dust buster. So why do they develop blindness with regard to development?

I don't know, but there's a related post on Meerkat today:

Artima.com has published a short article suggests that not only can systems and scripting languages co-exist in the enterprise, they can co-exist to great advantage in individual developers as well. Here's an excerpt:

To me, attempting to use one language for every programming task is like attempting to use one tool for every carpentry task. You may really like screwdrivers, and your screwdriver may work great for a job like inserting screws into wood. But what if you're handed a nail? You could conceivably use the butt of the screwdriver's handle and pound that nail into the wood. The trouble is,

1. you are likely to put an eye out, and
2. you won't be as productive pounding in that nail with a screwdriver as you would with a hammer.

There's more; go check it out

Gordon has updated his post. There's a lot of good stuff in there - it sounds like the email problem I posited yesterday isn't a problem for his usage:

Second, I've been running email to blog for nearly a year, and I've never had a problem, for a couple reasons: I use a separate mailbox, and because Radio will download only those emails with a specific subject line, so it's doubly unlikely that a spammer would get into my blog. You could set up a whitelist, because you want to really restrict who posts. If you wanted to get really crazy with it, you could require signed messages.

Ok, I'll buy that. I was mistaking his post for the testing Sam Ruby has been doing with an open interface for comments. I still think that's just asking for trouble.

And yes, in answer to Gordon's question further down:

James says "This is simple. I can send data via port 80, using simple web protocols, and not have to worry about spam or custom servers." I won't dispute the simple part, but it does sound like he has in fact written a custom server. No doubt it's less code when written in Smalltalk instead of Java, but I'd bet that it'd be no worse implemented as SMTP. In fact, I contend that you could make it all work in bloxsom with a shell script. Of course, the Radio implementation is pretty simplistic, but the more I think about it, the more I think this could make a really nice weblogging system.

yeah, this is a custom blog written in VisualWorks. It's a pretty simple system, actually. At the moment, it's single user, but I've been meaning to make it possible to run multiple blogs off of it for awhile now. Given the codebase I have, that's going to be easy. The code is freely available too - just grab VisualWorks NC, then get an open repository account. Load the CST-Blog bundle and have a look; comments, suggestions, and help welcome ;-)

The newest version of BottomFeeder delivers updates on demand. Older versions delivered patches at startup, but I decided that an on demand, user controlled system would be better. What I have now is a system where the application (BottomFeeder) loads at startup - it's a parcel. That means that I can deliver either patches, or full replacements, and have BottomFeeder detect that new updates are available, and offer them to the user. How does that work?

Well, the first thing to do was to set up a manifest of available updates on the server. I have an XML file, containing a manifest of all available updates. The updates are a collection of objects that look like this:

Smalltalk.Patch defineClass: #ComponentDefinition
	superclass: #{Core.Object}
	indexedType: #none
	private: false
	instanceVariableNames: 'parcelName parcelFilename version oldVersion releaseDate vwVersion isPlugin descriptiveName '
	classInstanceVariableNames: ''
	imports: ''
	category: 'PatchFileDelivery'

so I have a description of the new stuff by release date, version, name, etc. How do I know what I already have? Well, that's pretty easy as well. Since the application is a parcel, I merely ask for the list of matching parcels (i.e., onces that match by name with the available updates) in the image, and then query for their versions and release dates. If an update is not loaded, then it's available. If it is loaded, I compare release dates and versions, making available anything that's newer. Then, if there is anything new available, a toolbar and menu item becomes enabled, allowing the user to download any or all of them. The UI for that looks like this:

The user can select any or all, and upgrade. So what happens when they do that? First, BottomFeeder does an HTTP GET to the server for the file (as specified in the manifest). The file in question is a parcel, and the code that grabs and saves it looks like this:

download: patch from: url
	| fileUrl client bytes response |
	fileUrl := url, patch.
	client := HttpClient new.
	[[response := client get: fileUrl]
		on: RSSFeedManager netExceptions
		do: [[:ex | | error |
			error := RuntimeError appError: ex.
			RuntimeErrorLog addError: error.
			^false].
	bytes := response contents.
	self savePatch: patch bytes: bytes.
	^true

savePatch: parcel bytes: bytes

	| file  dir |
	self inProcess isPlugin
		ifTrue: [[dir := 'plugins']
		ifFalse: [[dir := 'app'].
	file := dir asFilename.
	file exists
		ifFalse: [[file makeDirectory].
	(file exists and: [[file isDirectory])
		ifTrue: [[| stream |
				file := file construct: parcel.
				stream := file writeStream binary.
				[[stream 
					next: bytes size 
					putAll: bytes asByteArray
					startingAt: 1] ensure: [[stream close]].

Once I get the data, I simply extract the content and then drop the binary data to disk into the appropriate directory. Once it's there, I simply load the parcel. Since I haven't stripped the compiler out of the BottomFeeder runtime, that all works pretty well.

What does this allow me to do? It allows me to offer very simple upgrading to BottomFeeder. There's some additions to this as well - I plan to offer the option to just download, but not actually load, the new component. That way, someone could grab the new stuff, but backup their local feeds before upgrading.

The interesting thing is, this is a generic update capability. There's nothing specific to BottomFeeder here; take a look at the PatchFileDelivery package in the public Store. Other than application level error handling, the code is entirely re-usable. It uses a few very simple mechanisms:

1. An XML manifest file, specifying the available components. I use the XML Config Files package, but the cross Smalltalk SIXX should work as well
2. HTTP access to the manifest
3. HTTP download of the available components
4. Standard VW parcel loading after the download completes

Simple and easy to implement.

I've just extended my blog tools to allow for deferred posting - so I'm writing this while on the way home from Atlanta at 30,000 feet. Pretty Cool

At the same time, I'm catching up on my feeds, since BottomFeeder has handled offline viewing for a long time now. as I'm doing that, I come across this post on the Fuzzy Blog:

For myself, I see Zope's reliance on its built in object database as a huge drawback. And I know lots of people will disagree with me on this but I'm a professional. I want my tools to be reliable. And I simply don't trust object databases. Period. I've worked with everything from the old fashioned Smalltalk/V image files which crashed to ObjectStore which crashed to Poet which crashed. And don't even get me started on the lack of utilities and tools for fixing crashed object databases.

Huh? Sure, tools fail. So do RDBMS' - I've seen truly horrid problems with corrupted database files. IMHO, this is not a reasonable prejudice. The objection to a lack of tools - yes, that's reasonable. Certainly there are far more reporting tools (etc) for RDBMS products than for OO databases.

At the same time, it's kind of odd that he calls Smalltalk's image a database. Sure, it holds objects, and could be used as a database. At the same time, one typically stores the source code in a source code control system, and one rarely uses the image as a db at runtime.

As for trust, heck - I trust my Smalltalk image a whole heck of lot more than I trust SQL Server. When was the last time you heard about a network exploit against VisualWorks?

I posted on the prevlayer concept here. That generated this comment from Alan Knight;

I'm pretty skeptical that this would actually work in any sort of real situation. Apart from data that won't fit in RAM, no generalized indexing (it's fast as long as you don't have to search all of memory for something), race conditions and deadlocks in access to data, and the absence of transactional semantics, it should be fine. Except for all the things the relational people complain about with OODBS, like no language-independence, no program or version-independence in the data, etc.