Smalltalk Tidbits, Industry Rants

I taught the last Smalltalk class for the winter today - I've been using Squeak to introduce 4th and 5th graders to programming. We had a look at EToys today, and we went through the make your own car tutorial. The kids picked it right up - after I walked them through the car, they were able to add the steering wheel and get going. They had a lot of fun, and learned something while they were at it. I'll be better prepared next time, and start with the EToys stuff.

Eliot Miranda posted up an explanation of the VW threaded API call mechanism. While this is a feature VW has had since 2.5.2, many people still seem to not know about it....

Scott Johnson is not amused by ATT support:

I start to traceroute and give him feedback about the broken routes. I ask him: What's an email address so I can mail it to you? "I don't have one". What's a hot mail account I can send it to? "I can't give that to you either." So I ended up reading him the bad routes. Pathetic. And this from a company that sucks $50 from me monthly for broadband?

I finally give him the info, he checks it from there after a 5 minute hold session and B I N G O ! I was *right*. They have a problem on their internal network and then I had to wait on hold for another 5 minutes while he filled out a trouble ticket. Then I got the really bad news.

"It'll be resolved within 72 hours. Not necessarily fixed but hopefully a solution decided upon." What the fsck does that mean ? That within 3 days from now, you'll decide how to fix it and then take as long as you like? Utterly, totally pathetic.

Yeah, I've had to explain networking to Comcast before - and trust me, I am no networking wizard. Just say the word "Linux" to a Comcast rep and watch them try to claim that it's all your fault, even when the problem is signal strength. And then there was my happy times with Sonic Blue support. Are these vendors just trying to drive us away?

Over Here. Cool!

At least, once this sale goes through

Navigate your way here and have a look. There are many more details in the Release Notes, which will ship with the product. Make sure to have a look at those after 7.1 ships

Camp Smalltalk 6 is gearing up, June 22-26 in Germany. Have a look at the projects, the attendees, and the registration. There are tips for getting to CS6 here. I won't be going - Smalltalk Solutions is shortly afterwards, and the schedule for CS6 doesn't work for me - my daughter's summer vacation will just be starting then. Looks like a good camp though!

I'm preparing for the last Smalltalk class for this group of kids - I'm going to have them work on this today. We worked on extending the demo last week - this week, we will work on creating it from scratch. The kids should enjoy that.

I'm teaching this again in a few weeks, and I think I'll start with the EToys stuff right off the next time. It's fun for the kids, and also gets them experimenting. Highly useful stuff!

This post pounts to some good guidelines for development. While they are aimed at Java, the design goals - numbers 1-35 at the beginning - are applicable to Smalltalk as well. For that matter, easier to accomplish in Smalltalk....

While watching the wall to wall war coverage, I found and fixed a nastly little bug in the 2.8 code. I was missing a method implementation! Found that in testing. Hopefully, no more of those lurking on the code....

Then I saw these pictures from the Denver storm. Wow

I can point to two things:

• This document on migration issues
• If that doesn't convince you, look at this from comp.lang.smalltalk

Here's some Smalltalk code:

aminoAt: aString
     ^self aminoList detect: [[:amino | amino name = aString] ifNone: [[nil].

Now the equivalent C#

public CodonAmino getAmino (string aName)
{
    bool found = false;
    CodonAmino amino;
    IEnumerator e = this.AminoList.GetEnumerator();

    while ((found == false) && (e.MoveNext()))
    {
        amino = e.Current;
        found = (amino.Name == aName);
    }
    return found ? amino : null;

The extra typing alone.....

And doing bad things with HTML while they're at it. Go see what Scott Johnson has to say on this:

Someone needs to teach the "gotdotnet" folks what RSS is. Also I couldn't believe their HTML source when I was poking around. So get ready for a vent.

Go look here and look at the __VIEWSTATE input element. To me that's just plain lame. Use a session, send a cookie and use your horsepower for this, not my bandwidth with every page view. And if you really want to barf then click around a bit and go here. They seem to be encoding the entire viewing history in a really nasty way and shipping it back to you every single time. It just gets bigger. After navigating thru like 3 pages I had 6,554 bytes sent down the wire that did nothing for me. Thanks for nothing.

I guess its not all that bad actually but it just seems damn silly. I hope that's not a dot net feature but I'm afraid that it is. Sigh.

Just look at the kind of crusty HTML produced by Word when you do a "Save as HTML". Bleah...

I said this morning that we had one issue that we knew had to be dealt with before we ship VW 7.1. well, engineering found and fixed that issue, and the fix is in code review. There's a build going forward today that won't have that fix, but it loks like we are down to the last little bits here. This is going to be a great release!

As he posts here. Yeah, I've been there with the mini-van. Last year the engine light started blinking periodically. Oil was fine, nothing else seemed to be wrong - and the mechanic I trust couldn't find a problem. It turned out to be one of the sensors in the engine giving a bogus reading, and that required replacing the sensor. It cost way more than was reasonable - and they tried to baffle me with BS on the whole deal, telling me that replacing a chip was complex. Get ready to open the old wallet Matt....

The next release of Cincom Smalltalk is getting close. There was a last issue with menus on the Mac (OS 8 and 9 only) that we were having trouble tracking down, but my email tells me that we have a fix for that. That means that release by the end of this month looks good

BottomFeeder 2.8 will go out as soon as VW 7.1 does - I don't want to ship on a pre-release, and I would like to have the "goodie" parcels in VW match an actual release.

Meanwhile, check out this page to see what's coming!

Got caught by a silly lazy intialization bug - the method that answered a collection of urls to send web log pings to after each post was just answering self, and that caused entertaining problems. fixed now, and I should be pinging all the usual suspects again. Ahh, the joys of on the fly updates....

The traffic in the DC area has been utterly snarled ever since this started. I sure don't need that kind of thing adding to the joy of drive time...

Willow is on Angel tonight!

Gotta get those priorities straight....

Have a look at the Smalltalk Solutions site - things are gearing up for the show. We have a nice set of presentations, and the program team is in the process of sorting out, organizing, and scheduling them. Sign up to attend now!

I posted yesterday on security and posting - the Blogger API in particular just passes usernames and passwords in the clear. I'm following the CommentAPI discussion on various blogs - mostly here.

The theory seems to be to replace various ad-hoc HTTP posting methods with some XML based posting/comment API. And again, security has gone missing. Sure, comments don't need a security story. But posts - updates and new - need authentication of some sort or another. I encrypt everything in my tools.

Come on people, get serious!

I've considered adding support for the Blogger API for awhile now. It's not hard; I could get that working in no time flat. I have a rather hard time with one aspect of the API (1.0 and 2.0) though - Usernames and Passwords are passed in the clear. You just create an XML doc, shove unencrypted user info in there, and send it across the web. Well.

Unfortunately, many people use the same password for everything. So right off the bat, the Blogger API just asks for trouble. Not to mention that a popular blog could easily get masqueraded posts that way.

So thus far, I've said no. I create a form, encrypt all the data, and URL encode it. That gets sent to the server from my blog tool, and the servlet there decrypts and validates it. Much better. I guess what I want to know is, why in the heck doesn't the new blogger API specify encryption?

Clarence Westberg rediscovers the ease of Smalltalk, and gives us some advice:

Day 2 of smalltalk programming, I forgot just how productive this is compared to 'C' style programming (like C#). I can actually do what I want without wasting development time figuring out why a cast didn't work or what type something needs to be. I hate typed languages. I also don't have to declare what I am 'using' and all that other compile crap. I wish Cincom would get the smalltalk dll stuff done so I could do as little coding as possible in C#. I do like how easy it is to make a web service in C# though. It would be nice if I could create a class i smalltalk and have something generate all the plumming.

We are in the process of building tools for all that nasty WSDL stuff - a rough cut will arrive with 7.1, with better to follow. 7.1 is due soon.

I've added a Feedster search option to the blog - check out the top of the page and try it out!

it works again. I suppose it's time I set up a local blog ping server for testing before I run live with stuff like this ;-)

We have posted a new Cincom Smalltalk Survey - the topic this time around is web application development.

Results from past surveys may be found here

Thanks!

On each post here, I'm now pinging (as per this spec) the following sites:

• weblogs.com
• blo.gs
• Blogrolling.com

Those are the ones I know about; my ping interface is extensible to an arbitrary list of supported interfaces. Is there anywhere else I should be pinging?

So I'm reading Ted Neward's post on AOP. I highlight AOP, and hit the Feedster it! menu item. Bam, I get a list of other blog entries on AOP. Very cool. If I was writing an entry of my own on AOP, I'd have all the necessary material immediately at hand, in one tool.

I got a great suggestion this morning from Jason Ayers for BottomFeeder - allow the user to select text in the html pane, and immediately execute a Feedster or Google search on the selection. So I added that just now, and the new version of the parcel is already uploaded. I'll do a dev build for the whole thing later.

So now, you select some text, and can immediately do a contextual search on it in blogspace. Now that's cool

From Irrational Software. This is a really good explanation of where and how XP will and won't work:

Laurent Bossavit's article The Unbearable Lightness of Programming: A Tale of Two Cultures (unfortunately no longer available onlineavailable here as PDF) is very good. He looks back on two failed Extreme Programming (XP) projects (at two different companies) and finds the reason for the failure in the organizational cultures clashing with XP. He examines the cultures and what it was about them that caused the clash.

Also interesting was David Putman's article Are You Mature Enough for XP? (not available online) where he identifies two extremes: emergent and enforced cultures. An emergent culture is, basically, one where both employees and management have the power to influence the culture. In an enforced culture, management defines the culture, with little or no possibility for employees to influence. Putman writes that an emergent culture is required for XP to work.

That's an excellent point - your corporate culture has to be XP enabled before you have any chance of success with it. Go read the whole thing - there's lots of good stuff there

The DC XP group is using VisualWorks NC for a codefest - the project we picked is a blog implementation. I bet the code ends up being cleaner than the code that runs this blog ;-)

I was going to comment on this post by Ted Neward, but decided that this comment said everything that needed to be said about it:

And believe it or not, there are some people who fall in a mysterious third group, that I call "competent developers"

Thank goodness I didn't have a full cup of coffee when that went by on the IRC...

then it's due to a patch I briefly put out and removed. Here's the fix:

• Remove the file BtfFeedster2.7Patch.pcl from the BtfPatch directory
• In the btfSettings.ini, change the line that reads patchSiteFilename='patches.xml' to patchSiteFilename='patchDefinitions.xml'

I apologize for the problem...

There's a whole lot of good information on it over here

I've been using client side posting tools with my blog for awhile now, but had a problem with the URL Encoding - on the server side, I was doing two unencodes. This caused obvious problems with '+' signs and '%' signs. Figured out the silly error and patched it up. I figured out that I had a problem when my earlier post changed all the '+' signs to spaces, and made it look like I was referring to C rather than C++

Ted Neward has a post up on OO. He's got a lot of cynical thoughts today:

Languages like C++ and Smalltalk were going to enable a revolution in the industry: Object-orientation was going to make it easy to build complicated systems out of atomic parts, solve world hunger, bring about world peace and make us all rich. For quite a while there, if you didn't throw the term "object-oriented" into a conversation, you obviously weren't a hip developer or manager and therefore obviously weren't worth listening to.

Ten years later, and we're still waiting for the object utopia promised us. It's not like we can blame the languages, either--several additional object-oriented languages, most notably Java, emerged over time, and still no utopia. Vendors even sought ways to put object-oriented extensions into other places, like the relational database (but this was only when object-oriented databases themselves failed to materialize in any large-scale way), to no avail. The promised "object marketplace" just never seemed to happen--certainly object-oriented frameworks (like MFC, OWL, and several other libraries) came about, but these weren't "objects", but basic technology-specific scaffolding for building more objects. Where was the "object palette"? Where were my "SavingsAccount" object and my "BankTeller" object and my "ArcadeGame" objects, that I could just reuse and extend as necessary? It's as if objects failed us somehow.

Let me disagree strongly with the "can't blame the languages" theory. C++ was and is a crappy way to do objects. It's a mixed metaphore language, neither fish nor fowl. Primitive data types get in the way of clean object models, and the lack of garbage collection gets in the way of decent object models. Then we have Java - it adds in gc, but still has primitive data types, and makes a few more horrible mistakes:

• Final classes
• No extension mechanism

Java is fundamentally broken from an OO perspective. I suppose one can do OO in it, but the language (and C development culture) sure don't help you move that way. Ted's just wrong - we can and should blame the languages.

Then he goes on this riff:

Even worse, the marketplace grew around a decidedly non-object-oriented technology. Starting with its 3.0 release, Visual Basic, the butt of programmer jokes, that "technology to keep journalism majors employed", that language that wasn't even object-oriented, for heaven's sake, saw a huge, multi-million dollar industry spring up almost overnight around selling "things" that could be dragged, dropped, and reused without hesitation. This was a language that was developed around BASIC, for crying out loud--no implementation inheritance, no pointers, no overloaded methods or even basic encapsulation. And yet, it was reaping the benefits of binary reuse left and right. It was like watching the dorky guy at the dance, the guy wearing the red-and-green plaid tuxedo, go home with the prom queen.

You can pretty much see the problem with the C language crowd and OO here - (and they call us Smalltalkers arrogant!) - pointers are part of OO? The syntax (Basic, in this case) is disqualifying? (Only curly brace languages may apply, apparently!).

And this:

GUI frameworks, like MFC, succeeded in capturing a significant portion of the complexity associated with building GUI applications, but not in the way objects were originally envisioned. We thought we could just inherit from a base class, thus reusing that base class' functionality, but found that when the next version of the framework shipped, everything broke for some reason.

Broke for some reason???? How's about lack of care for backwards compatibility on the part of the vendor? This has nothing to do with OO - more of a vendor culture issue, IMHO.

Ahh, now here come the not terribly well informed criticisms of Smalltalk:

The first problem, the idea that reuse was achieved via inheritance, was originally conceived out of experience with the only other serious object-oriented platform at the time, Smalltalk. In Smalltalk, all reuse was done through inheritance--if you wanted to make use of a class, you inherited it, and added whatever specialization, overriding, or new behavior desired. Unfortunately, while this works in a loosely-typed environment like Smalltalk, it doesn't work in a strongly-typed one like C++ or Java. What results is a nightmare scenario where the base classes in the hierarchy can rarely, if ever, be modified without breaking (usually in spectacular fashion) every single one of its implementation derivatives. This was commonly called the fragile base class, or FBC, problem. In the long run, it prevented successful evolution of base classes once released into wide use.

Yeesh, where to start. Loosely typed? Sigh.... How many times can we point out that C++ is loosely typed, while Smalltalk is strongly typed? People consistently mistake manifest typing for Strong typing. You would think a few core dumps along the casting path would have taught them, but no....

Then, the statement - "if you wanted to make use of a class, you inherited it, and added whatever specialization, overriding, or new behavior desired. Unfortunately, while this works in a loosely-typed environment like Smalltalk, it doesn't work in a strongly-typed one like C++ or Java". Hmm. Apparently, Ted's not seen class List in VW, or any of a number of other delegation examples. Sure, languages like Self make delegation easier. But it's used quite heavily in Smalltalk. Developers figured out a long time ago that deep inheritance trees tended to have issues - and it's not simply because of Manifest typing.

Regardless of the actual implementation or API of the collection class, it's a well-understood pattern that obtaining the items within the collection should be done through an alternative, separate object instance--an iterator. The iterator focuses on traversing the objects contained within the collection, and has implicit "deep" knowledge of the container's internals to enable this. And here we see the problem of reuse at an object level: these two objects make no sense without one another.

Hmm. We don't have this separation in Smalltalk. Closures, anyone? And in case we thought the industry might be learning, C# has no closures either. To paraphrase the old riff on DOS vs. Unix - Here's a nickel kid - buy yourself a real OO implementation.

However, his riff on Component reuse makes sense:

Quietly alongside the object revolution, a second revolution was also taking place. Born out of the object revolution but focusing more on solving a different set of problems, the idea of building mostly-independent "things", called components, began to take shape. These would be "things" that were of larger granularity, completely self-contained and reusable without any sort of inheritance relationship. Microsoft's Component Object Model was one of the first technologies to embrace this idea completely, and was often criticized roundly for it: because COM focused on building components rather than objects, COM was often denigrated because it offered no mechanism for allowing implementation inheritance, a key cornerstone in "object-oriented" approaches. Unfortunately for the object purists, COM's viability got a huge boost from an unlikely source: Visual Basic. After demonstrating that the "VB control" concept was in fact a viably useful one (as witnessed by the market that sprang up after its 3.0 release), Visual Basic then took the step of effectively abandoning the 16-bit VBX format it created in 3.0, and moved to a 32-bit, COM-based OCX (Ole Control eXtension) format for VB 4.0. This in turn was simplified to create the ActiveX control, which could be either visible or invisible, and later embedded on an HTML page for downloading across a network.

It's the same critique I used to make of PARTS - that individual widgets in a GUI were not really the right level for wiring. Same thing here - individual objects are not the right level for reuse either. We are starting to see some coarse grained reuse in some of the open source projects I'm associated with - BottomFeeder, TypeLess, and Pongo. In our case, it tends to be at the package (component) level.

Go read the whole thing - the component discussion at the end is interesting.

My RSS feed now validates again. You can check here

It turns out that my RSS Feed wasn't validating here. I've patched the code up and tested it, and should be posting it up soon.

So I come back to my PC after shopping - somehow, it's decided that it should hibernate after 30 minutes when plugged in. I had explicitly turned that off. Well, after it came back, my network connection was frelled again, because the settings had (inexplicably) toggled again.

I am not a happy camper....

While I generally like Windows XP (Pro), there are some real oddities. my wife's machine (XP Home) still will not share devices; it's completely unclear why. There was no change made to her machine or the network; one day it just up and stopped allowing access to her printer from anything but her machine. Since I have two other printers, I haven't spent a long time looking at it. Her machine can see my shared printer though.

However, I had a weirder problem pop up 2 days ago. Suddenly, my machine ceased being able to use the Wireless (802.11b) network. Very odd. I have a 100 mb wired LAN, so it wasn't a crisis; damned inconvenient though. So today I sat down to look at it in depth. Windows had reset my wireless connection settings - once I restored them to the way they had been set, it all worked again.

This sort of oddness is very disturbing. ME was awful, and NT wasn't as stable - but I can't recall either OS ever spontaneously changing access settings on me. I have auto-updates from MS turned off - I have to approve everything that comes in - so it's not some service pack hosing me off. At this point, I have no idea what it is, and I find it very odd....

About this comment to my earlier post, there's a bit of a story there. The party we went to today was the 7th birthday party of our best friend's older daughter. The party went well, compared to one we through here for my daughter a few years back.

It was November, and pretty warm. We took the kids outside so they could burn some sugar off. They were playing tag, and one of the girls (who has three older brothers) got a little wild and shoved one of the smaller boys to the ground. We had the separate the two, and bring all the kids in.

That's when we discovered that the boy was missing. We called his parents, figuring he might have run home - just a half block away). No, but they panicked. We started looking in the woods, across the street, and in the house. We finally found the boy hiding in a closet....

Much relief (and embarrassment) all the way around. We got apology letters from both kids, but we always felt like we screwed it up....

But is the Smalltalk community ready for the world? I saw this post on some of the cool things about Python:

Subclassing the built in Python types is cool. We're subclassing dicts in PyBlosxom and it contributes greatly to the readability of the code

Python is catching on - and many of the things people like about it are (and have been) core parts of Smalltalk. Developers are ready to listen - we obviously have to respond better than we have been...

At Michael Lucas-Smith's request, the TypeLess plugin for BottomFeeder has been renamed - to BottomFeeder-TypeLess-Plugin. There's a new one as well - a Telnet client. It also looks like some dev time tools are being built into TypeLess - the VW internet console projects - BottomFeeder, TypeLess, ane Pongo - are picking up a head of steam!

Always a challenge when you go to a child's birthday party - how many toys will get lost (one so far, down the sink), how many fits will be pitched (one major one so far). Most of the kids left, and we can all settle down for some pizza...

Uche Ogbuji has doubts about the value of SOAP:

Jonathan Bartlett has a spot-on rant on why CORBA is still superior to SOAP. I think a lot of people know this, but fear to say it. Duncan Grisby, the lead developerof the superlative omniORB came to the tenth International Python Conference (IPC10) and was on a Web services panel. I think he came expecting to have to defend CORBA's honor and was surprised when just about all the panelists agreed with him that CORBA is better than SOAP in practice.

He wasn't done there; he posted later on SOAP vs. CORBA:

This is a more in-depth comparison of SOAP to CORBA than the rant I blogged earlier. It is quite sharply biased against SOAP (I've never been much swayed by "eeew XML is so verbose" arguments). But I think many of its points are fundamentally sound. Mike Olson also ran some SOAP/XML-RPC/CORBA performance tests on Python, with remarkable results.

Those benchmarks came out with SOAP being dramatically slower than CORBA. Not a big surprise; sending reams of uncompressed text over the wire - as opposed to a binary protocol - isn't going to be fast. But he wasn't done yet - read here as well:

Rem acu tetugit Paul Prescod. IOW, He nailed the point, as he so often does. I think the idea of merging header and body into a single document is the single biggest flaw in SOAP. Yes, SOAP section 5 (the RPC datatyping section) was probably the largest overall mistake in SOAP's evoution (as even heavyweight SOAP boosters have started admitting now), but it is far less fundamenal than SOAP's monolithic design.

We (Cincom Smalltalk) support SOAP well; it's got a bandwagon of support, and there's no way we can just tell developers to use CORBA instead. Still, Uche makes some very good points here - well worth considering if your technical options have not been closed off ahead of time....

I'm feeling pretty confident about the BottomFeeder code at this point - I think 2.8 is pretty much done. All I am waiting for now is the gold CD for VW 7.1 - when that happens, BottomFeeder 2.8 will be released

I've noticed that you can subscribe to Feedster queries as RSS Feeds. For instance, this query will produce all the BottomFeeder references found - as an RSS feed.

That has possibilities.

So much for a nice meal - my wife's car had a flat, so I got to spend quality time with the jack. Joy. The meeting went pretty well - the customer I was meeting with looks like they will be expanding their use of VisualWorks. Always a good sign when the decision makers stay in the meeting, and the meeting goes for 90 minutes. So now I'm catching up on the day's mail and feeds...

I am off visiting a customer in Washington, DC this afternoon. I'll have more to post later

After a power outage a few days ago, I forgot to restart the application that generates the feed. Dohhhh!

Spotted in comp.lang.smalltalk:

We're planning on going to Java because it seems to have a larger community right now and because we just don't have anyone left that can program in Smalltalk.

Before committing youself to this plan, I recommmend sizing Dome (I'm sure Reinout or Bruce could give you rounded figures on no. of classes, no. of methods, and no. of statement and cascade lines, if you are not set up to get them yourself). Then compute how long the Java rewrite will take you by assuming only a sane number of lines of code per day written by whoever does it. Check this by getting a rough estimate of how many years of effort wrote it in the first place (find someone who was on the project, ask them how long and average team size, thence fudge up a guestimate), then multiply by three (it's slower to program in Java) and divide by your 'porting is easier than writing' fudge factor.

The above should take you very little time (there's no point in getting very accurate numbers as software metrics is a very imprecise science). If the two figures that result are

• within even very rough hailing distance of each other
• both way over any realistic budget the rewrite could ever have

then I recommend you stop even thinking about it (and, even more important, stop even talking about it as it will just block more sensible solutions). Instead, devote your limited budget to specifying what changes you want and posting them on Dome's pages. Invite people to convert the requirements into XP tests, agree their tests with you (good Smalltalk XP tests are very readable even by non-Smalltalkers) and thence solve them. It might happen even if you offer no money. It will happen if you offer money. It will be much cheaper than the rewrite even if the latter were feasible.

I think you should provide a parcel load of your vw7.0nc port as the first thing.

Just my 0.02p. HTH.

Yours faithfully Niall Ross

That's as good a summary on this topic as I've ever seen, and I've written about this before.

The Fuzzy Blog has a nice post on BottomFeeder's support for Feedster this morning.

I had sent Scott an email, and got back a very nice response. I had only just added this support into the 2.8 dev stream, so I went ahead and posted a 2.7 patch last night that adds this to the shipping version. Bf should pick it right up; if not, here's a download link.

People wanting performance may want to ponder the stats on this page:

Table 1. Results of the benchmarking applications

Technology	Connect time	Send string (21,000 characters)	Receive string (22,000 characters)	Send 5,000 integers	Client LOC	Server LOC	Actual message size sending 1,000 characters	Actual message size sending 100 integers
Raw sockets	0.002242	0.001377	0.001359	6.740674	57	25	2,279	85,863
CORBA	0.000734	0.004601	0.002188	1.523799	37	18	2,090	27,181
XML-RPC	0.007040	0.082755	0.050199	100.337219	29	17	4,026	324,989
SOAP	0.000610	0.294198	0.279341	1,324.296742	32	10	4,705	380,288

Making the RPC mechanism human readable sure has helped. snicker.

That I have added it to BottomFeeder as a search option. Check out Feedster here

I saw this interesting post from Ted Leung's blog:

David Czarnecki states his reasons for not using a database to store blojsom's entries. Most of the reasons that he lists are quality of implementation issues in other blogs.

I have a different take. The reason that I liked blosxom's filesystem based approach is that ultimately, I view my blog as a part of my personal information infrastructure. And I want to be able to take that infrastructure with me wherever I go (especially after today's Centrino launch). The biggest problem that I have with using a regular SQL database is the disconnected operation problem. The blog has to be up and running on the web all the time. But I want to be able to work on entries on an airplane or on the ferry, and I want an easy way of synchronizing the web version and my private version. I'd rather not write a database synchronization package. So at the moment, the use of the blosxom filesystem seems to be the best that I can do. But the nasty mtime sorting is really a pain.

While I never gave it this level of thought before, this is why I've not moved this blog to a database. Setting up a test environment was vastly simpler - I just ftp all the files from the server - and I can have the whole thing on my notebook as well. With my offline posting tools, being able to post to an offline version of the blog is less relevant for me now, but still possible - and it makes for nifty demos.

I posted on this earlier, but I just realized that it supports another truly cool feature: you can have the feed search returned as an RSS Feed.

So now I have this query coming back as an RSS Feed, so that I can see if anything new on Smalltalk has popped up recently.

This is truly, truly cool.

Here's an interesting post on the Fishbowl:

One of the tricky aspects of API design, especially when designing the base APIs for a programming language, is deciding what goes in, and what stays out. Think of a string. There are an enormous number of things you can do with strings, but to put all of those operations on the String class would just be impractical and bloated. So as the designer, you take those operations that you feel would be most generally beneficial, such as finding the length, searching for and extracting substrings, and so on, and leave out the rest.

Some languages, such as Smalltalk, Objective-C, Ruby, Python, Perl, CLOS... Okay, a great many languages allow you to add behaviour to existing classes. So, for example, if your application really needs a method that reverses a string in-place and the language designer has decided that's not necessary for the supplied String class, you can add your method directly to the String class and be done with it.

Some languages, and this is where Java sits, don't let you do this. If you want to extend a class, you have to subclass it. And then you're stuck with whatever the superclass has made visible. And you can't do it with String anyway, because String is final. This is why most projects I work on end up having a StringUtil class, and every project ends up with a DateUtil. There are things we want to do to strings and dates all the time, but there's no way to put those things where they really belong, on the String and Date classes. Which is why having a Util class isn't a code-smell per se, it's a smell in the underlying language.

This is an area you can get into wonderfully interesting discussions on. IMNSHO, it is language smell when you can't slap code where it belongs. In VisualWorks, everyone always had their own version of CommonApplicationModel - subbed off of ApplicationModel. What that told me, as Product Manager, was that there were vast unmet needs in the current implementation.

That's what it always means

Internet News has a story making the complaint that MS' XML format in the upcoming version of Office will not be terribly interoperable:

Edwards said that Office 2003 beta's handling of the XML file format means that firms will not be able to tap the rich collaborative features of Open Office 2003 without resorting to proprietary Microsoft file formats. And to truly unlock its collaborative potential, firms will have to standardize on the Windows XP operating system (Office 2003 won't run on Windows 9x), as well as Windows 2003 Server, SharePoint Server, Exchange Server, etc. As for the file formats, he called Office 2003's XML "crippled," because it strips XML files of all presentation and formatting information when saving them in the XML file format. It does not do this when saving files in Microsoft's proprietary file formats.

"Although it's still early in the review process, it does look as though XP XML has been so seriously crippled as to be useless to anyone but the big content management and collaboration system providers," Edwards said. "Reports are that when saving to XML, [Office 2003] strips out the presentation and formatting information, leaving near raw content. It appears, at least from the non-enterprise systems user's perspective, that all the really cool collaborative advantages are based on saving files in the XP proprietary format. Which means that "all" the users in the collaborative effort must be on the XP platform, using XP Office, connecting through XP servers. What kind of universal connectivity and exchange is that? XP users won't even be able to collaborate equally with the 200 million Win9x users. Not unless they upgrade."

And why exactly is this a surprise? Regardless of what you think of MS vis-a-vis anti-trust - if you had the hold on the Office market that they have, what would possess you to make it easier on competing (and free) tools?

Eliot Miranda recently spoke at Stanford - a video feed of his talk is available. Check it out!

I have to give a lot of credit to Scott Johnson for his work on the Roogle RSS Search Engine. There have been a lot of comments on this tool, but this one

Here's a homework project. Go to the RSS Search engine. Now go to Google. Search for these words: "InfoPath" and "OneNote." What do you notice? I like the quality of the RSS results a LOT better

I think I understand why Google bought Pyra better now. Try doing a search for Smalltalk in both places as well - for fairly obvious reasons, I like the results better ;-)

Getting the replay tv hooked into the various a/v components was the usual holler fest - my wife and I reduced to jello before we got things working in something resembling the way we wanted. The stumbling block was audio going out of the TV. Instead of having to set the Receiver, VCR, and TV on separate inputs, we wanted to have the TV pumping audio back out from whatever it was tuned to.

This was harder than any reasonable person would want

The nicely labeled Audio out always took out whatever was coming in from the antenna/cable feed - regardless of what input it was tuned to. Arghhh! We had to shudder open the manual.

Sidebar - how is it that Sony has such brilliant folks building hardware, and then hires people with a minimal grasp of English to write the manuals? Would it be too much to ask to get an understandable manual?

Anyway, back to hell. The manual claimed that we could get what we wanted by plugging the jacks into the Audio out "var/fixed" plugs on the back of the TV. That was obvious (not).... and it didn't work, at least not right off. The "var/fixed" referred to the volume being pumped by the TV. For reasons not at all clear to me or my wife, setting it to "variable" on the TV silenced the audio output, while setting it to "fixed" gave us audio - but controllable only by the receiver's remote, and not the TV's remote. That led to some swearing. The TV and the receiver are the same frelling brand!

So this morning, I'm reading Ellen Goodman's column, since Instapundit referenced it. Now, I'm no luddite - I have a 100 Mbit house (wired) LAN, and an 11 Mbit wireless house LAN, two replays, and a number of computers on the LAN. But heck, there was a lot of common sense in that article. A lot of the electronics are getting too complex - maybe audiophiles understand it all, but I sure don't. My Living Room Receiver seems to constantly forget whether the CD input is analog or digital, and the readout on the blasted thing requires me to lie on the floor to read it!

There's a market opportunity for some vendor that makes a sharp break with current component plugs, and goes to something simpler, like a USB based interface whereby the receiver figures out what it's got plugged into it when it powers up. The current ugly proliferation of remotes and oddball cables can't be making anyone happy

I've learned at least as much this time around as the kids I've been working with. This looks like a good place to start next time around. Today, I'm going to use the EToys demo that is in Squeak, and then next week, try to come in with a new one. When I teach this class in the spring, this is the way I'm going to go about it.

According to this post, BottomFeeder is in the same ballpark as Radio, and a fair bit smaller than Syndirella. Bf weighs in at 36MB of RAM on my machine, with the contents of 100 feeds sitting in memory.

The 80 hour replay is back and set up, with the new 51" widescreen TV. We are busy configuring it now. My wife's first word's when we got it back:

"My Preciousssssss"