Smalltalk Tidbits, Industry Rants

Mark Pilgrim says...:

IE users can blow me. It's the inline lists. I can either maintain proper markup, or I can make it look right in IE. I don't know how to do both.

Heh. I often feel that way about IE, but it is used by the vast majority of users. If you look bad in IE, you look bad to most people....

I've added a new RSS Feed - I'm scraping the UIUC Wiki, and have the feed here. It turns out that scraping the Recent Changes page was pretty easy.

If anyone has suggestions for other Smalltalk oriented sites that you would like to see scraped for an RSS feed, I'll be happy to take a look. If it's feasible, I'll take a shot at it

Earlier today I posted a link to a new feed - I scraped the VW Wiki. I've moved the feed here. The link I posted earlier will also still work.

So now, I have a scraping of the EzBoard Smalltalk Forum - the feed is here.

I've just finished scraping the C2 Wiki. The feed is here. There's always a lot of interesting commentary going on there, and I always forget to check. Now I can track it in BottomFeeder

I'm still mucking about with the C2 Feed. The item dates are wrong - although I do seem to be getting the right items. You may see some shifting in this feed as I experiment with it. See the C2 Recent Changes Page to see what I mean. I'm currently limiting that to the most recent 50 items, which is why there's a lot more on the site than in the feed....

The C2 Wiki has some good posts up on bad management theories:

First Law of Bad Management: When something isn't working, do more of it.

Self Sealing Beliefs are those where you're erroneously convinced that some desirable result is caused by taking some particular kind of action. Subsequent failure for the desirable result to occur is not used as disconfirming evidence that you're wrong to be convinced that way, but is instead used as evidence of a need for more of that action.

Performance related pay may be one of these. It seems obvious that more pay for better performance will result in better performance. Studies however have shown little or no effect other than an initial jump.

It will work this time After an idea is tried and has failed, been tweaked and tried again, been tweaked and tried again, etc. my inclination to reject the idea and look for alternative solutions.

However, management (and colleagues) frequently claim that that they "know why it didn't work", proceed to address the most obvious manifestation of problems with shallow solutions and chant "ItWillWorkThisTime". (They disapprove of my "negative attitude".)

Yeah, I've seen (and had to live with) these sorts of thought processes more than once. All too common...

If springtime in Paris isn't enough, check out the SmallNic in Paris this April:

The french Smalltalk community would like to organize the 2nd SmallNic in Paris. What is a SmallNic ? It's something like a mix beetween a picnic and a coding party around Squeak and Smalltalk. The idea is to show what you want around Smalltalk (demonstrations, tools, research projects, ...) in a very friendly environment around computers (and pizza ?). We invite all Squeakers and other developpers from all Smalltalk flavors to join this event to share their enthusiasm and knowledge.

Contact	Serge dot Stinckwich at info dot unicaen dot fr
When	12 april 2003
Where	INJS, 254bis, Rue St-Jacques, 75005 Paris (Metro/RER Luxembourg - Exit : Rue Abbé de l'Epée)

Please add you name, email address and Smalltalk interests at the end of this page (click on the edit button). Take your laptop if you have one!

I went to this week's codefest at the XP DC Group. We paired off - each Smalltalker with someone who didn't know Smalltalk, picked a story, and started writing tests. The RB with the SUnit extensions was a big hit. The only complaint I got - and a valid one - is the need for more and better keyboard shortcuts. This is one we know about, and intend to address in VW.

I went to this week's codefest at the XP DC Group. We paired off - each Smalltalker with someone who didn't know Smalltalk, picked a story, and started writing tests. The RB with the SUnit extensions was a big hit. The only complaint I got - and a valid one - is the need for more and better keyboard shortcuts. This is one we know about, and intend to address in VW.

A funny post on logical flaws with transporters on Star Trek:

Picard's brother owns a vineyard. (Jean-Luc Picard is captain of the Enterprise on STAR TREK: THE NEXT GENERATION.) That's cool--I dig gardening. But what does he do without migrant workers to pick the grapes? They never say, "Use the transporter to beam the juice from the grapes into the barrels. If they did, they wouldn't need surgeons cutting open Picard's chest; they could just beam in the new artificial heart.

Transporter field dynamics preclude it. Okay, I just made that up, but you know something like that'd be the justification if necessary.

Surgeons use micro-transport and micro-replication all the time. None of it is "point-n-click". That's why they are still surgeons.

I disagree, they never use transporter technology the way they should. They can beam themselves into the heart of a Borg ship when the plot requires it, but they can't beam in a truckload of photon torpedoes when they're getting their asses kicked. I think surgeons are around because no one in the 24th century ever figured out that they could beam fat globules out of your blood stream to avoid a stroke.

They transport only in carefully controlled circumstances, only specific materials masses and distances, and when they have time to plan.

They don't transport "in" a truckload of photon torpedoes, because transporter beams are too easy to jam - even certain planetary ionospheres can do it. (There's also the issue from whom they beam them - another StarFleet ship that's also under attack?)

And more like that. Very funny.

I spent the morning adapting BottomFeeder to the latest build of Twoflower from Holger. He's fixed some issues with the HTML display - this URL wouldn't display in the previous version. It works now. He also added a cleaner way to get mailto: links working - I had added a hack for it. The latest parcels are up, and should show up as available upgrades in the 2.8 dev builds. I'm in the process of replacing the full build downloads as well - new gzip files should be available later today.

Now, I've got to go update the collateral docs for VisualWorks - the old ones date from VW 5i.4, and are pretty dated. Ahh, the joys of Word editing....

This is interesting. There's a push to use something called MIME-RPC instead of either XML-RPC or SOAP. Here's the riff, and it makes a lot of good points:

• SOAP does not interoperate with existing browser based apps. MIME-RPC does.
• SOAP does not do generic object serialization
• SOAP forces the programmer to think about type coercion because it hides foreign data as base64encoded rather than labeling it with a useful type.
• SOAP does not handle delivery of XML or other types well. MIME-RPC does.
• The SOAP with attachments spec basically says to use MIME. If you are doing that, you might as well use MIME for everything (and therefore MIME-RPC).
• The SOAP with attachments spec is ambiguous about the type of attached objects. Should the type be interpreted according to its mime content-type or according to some XML schema? MIME-RPC provides an unambiguous interpretation.
• SOAP constrains method and variable names to be consistent with XML tag names. Many languages (e.g. SQL) allow method and parameter names that are not permitted in XML tags.
• MIME-RPC is much easier to implement correctly than SOAP
• MIME-RPC has less processing overhead than SOAP.

So will this call get any notice? Worthwhile though it is, I doubt it. As with Java in 1995, the industry will likely make a mad, uninformed rush to the more complex technology in favor of the simpler, easier to use, already proven technology. It's enough to make you think that the big consulting firms with thousands of bodies to sell control everything....

The updated parcels went up earlier; I've now got the new base builds up.

VW 7.1 and ObjectStudio 6.8 are close to gold. We have some repackaging to do, but the release is now ready to go. Unless something in the packaging turns up, we will be ready to release on time! Kudos to engineering for a great job!

Reflective Surface is trying out VisualWorks, and having a look at the BottomFeeder Source Code for an example. Let's hope my code doesn't scare him off :)

Installing VisualWorks is very simple. To me, it was enough to unzip the contents of two files, and create a shortcut for the application. The environment is familiar since I've used Squeak (an open source Smalltalk environment) a lot of times in the past years. Obviously, there are some notably exceptions as VisualWorks is more geared to professional development while Squeak is more intended for educational uses. GUI development is completely different, but one can always resort to tutorials and help files to get started in that kind of programming.

Although I never completed a serious application using Smalltalk (I didn't know VisualWorks when I started using Smalltalk, and I don't like Squeak''s deployment model), this time I intend to use VisualWorks to implement a personal project I've been planning for some months now. This project will allow me to work with a lot of the Smalltalk and VisualWorks libraries and get up to speed with Smalltalk again. In fact I have downloaded BottomFeeder's source code to take a look at how a real Internet application is done with VisualWorks (BottomFeeder is a RSS aggregator), and I will use the next weekend to study it.

So, the fun is just beginning.

Michael Lucas-Smith comments here - but it's worth posting in a more visible place:

Reasons to mock, taken from the C2 Wiki

1. real object has non-deterministic behavior This is exactly why you need to test the realm object! 2. real object is difficult to set up Write the tests first, any object that is hard to set up was hard to make, but you did it with tests first, so.. not difficult to set up any more. 3. real object has behavior that is hard to cause (e.g., network error) (similar to 1) The hardest behaviour is often bugs. Testing bugs is essential so that we can say, "Yes, this bug will never occur again because we have a test for it". Extend your testing capabilities, don't dust it under the mat. 4. real object is slow Run your tests over night. Whether or not it's slow, you still need to know if it works or not! 5. real object has (or is) a UI So what? Do like I did and make yourself an SUnitView. Oh wait.. not using Smalltalk, are we? 6. test needs to query the object, but the queries are not available in the real object (e.g., "was this callback called?") Uhm? .. I've never had any trouble with this. Add the test as interested in the callback, then check if the callback happened. If it didn't, fail, if it did, pass. 7. real object does not yet exist Smalltalk - write it in Smalltalk. You don't -need- the real object yet. It fails nicely since you don't have code to test, but you do have tests.

Well

• sigh*

Good points all...

Patrick Logan has moved his weblog over here:

Anyway I have a new weblog, and I'd like to point out to you that I expect to increasingly mention Smalltalk over the coming months. (Call me born again.)

Welcome back Patrick! Pick up his RSS Feed Here

Matt Croyden has some good info:

We got the OBD-2 connection to work on my car this evening.  We plugging an old P75 laptop into my 98 Golf, and whadda you know, the check engine light was due to a misfire in Cyl 2 a few days ago.  (I remember it now, I went into second right after starting the car while going up the hill, it was a mistake)  Mike cleared the error, we ran diagnostics again, error gone.

I'm glad I didn't have to pay the dealer to find that out.

Very cool - I'll have to look into that!

The actor playing President Palmer on 24 played Cerrano on Major League.

Heh. Could you come up with 2 more different roles?

If you are thinking of optimization, don't yet:

There are many reasons to leave optimizations until later. The prime candidate is that the necessity to optimize is a very powerful force when writing the code. If it is applied too early, it can impact the codebase so powerfully that the code becomes unreadable from early on. If code is unreadable, it is unmaintainable, and it is unlikely it will function.

There's also the simpler problem - in my experience, developers typically don't optimize the right thing at coding time. They make assumptions about what will be slow, and pre-tune. The better bet is to write the code, see if it's fast enough, and then - if not - use a profiler before you do anything else.

I've been at countless customer sites where they told me - with authority - why something was slow. When asked if they had profiled, the typical answer was no. And usually, the profiler showed a different problem than their assumptions....

In creating BottomFeeder, one of the early requests we came across was coditional-get. What's conditional-get, you ask? Well, consider what an RSS News aggregator does - perioidically, it queries all the sites you have subscribed to, gets their information via HTTP, and presents it to the end user. In the process of doing this, it executes an HTTP-get against all the sites of interest

Most people have their readers set to update every hour - possibly more often! Sites really don't like to get hit by the same user over and over again that way - in the early development of BottomFeeder, we got complaints about that. The solution - conditional-get. What is that, you ask? Well, everytime you do an HTTP-get, you get a fair bit of information about the document back - including tags unique to the document, and a timestamp from the last modification time. If you save those, you can insert that information into your query, and get a well defined exception when the document you are requesting is not new. This saves the site the trouble of shipping you the whole document - it instead sends a short "no changes" response, which VW sees as an exception. Here's how you do it:

Say I get a document this way:

response := HttpClient new get: 'http://www.cincomsmalltalk.com/BottomFeeder'.

If I look for two header tags and save them, I'll be ready to do a conditional-get next time:

lastModified :=  (response header at: 'last-modified') value.
etag :=  (response header at: 'etag') value.

Ok, Now I have the information I need; what do I do with it to be a good net citizen next time around? I add that information to my HTTP query:

client := HttpClient new.
req := HttpRequest new.
req method; 'GET' url: 'http://www.cincomsmalltalk.com/BottomFeeder'.
req getFieldAt: 'If-Modified-Since') value: lastModified.
req getFieldAt: 'If-None-Match') value: etag.
^[client executeRequest: req]
     on: HttpRedirectionError
     do: [:ex | ex parameter code = '304'
                     ifTrue: [nil]].

Now, you should check for other exceptions as well - what this code demonstrates is how to look specifically for a 304 (not changed) error. When you see that, you know that the document hasn't changed. The beauty of this is, if it has changed, the query simply returns the new document - along with the header information necessary to do a conditional-get again next time.

This is pretty much how we do it in BottomFeeder. If you want to take a look at the code, then get an account in the public store, and grab the package Http-Access - it's loadable separately from the entirety of BottomFeeder.

Here's an announcement from STIC on the re-establishment of the group:

Contact	Andrew Ignatow	Contact	Michele Gray
	Smalltalk Industry Council		Edelman
	513.612.2104		212.642.7746
	Andrew Ignatow		Michele Gray

LEADING TECHNOLOGY COMPANIES JOIN FORCES TO PROMOTE SMALLTALK

Newly Established Smalltalk Industry Council Includes Core Members Cincom, GemStone, IBM and Knowledge Systems Corporation

New Council Sponsors Smalltalk Solutions 2003 Convention and Trade Show

Cary, North Carolina, March 26, 2003 - To raise awareness and increase the demand for Smalltalk as the programming language of choice for application development, the Smalltalk Industry Council (STIC) today announced that it has reorganized. The new Council's core members include Cincom, GemStone, IBM and Knowledge Systems Corporation. Allen B. Davis, chief executive officer for Knowledge Systems Corporation, has been named executive director.

"Smalltalk is by far the best programming language available for Web and enterprise development," said Allen B. Davis, Executive Director, Smalltalk Industry Council. "Smalltalk is a mature technology and well supported. Since it is underutilized, STIC's mission will be to raise awareness of Smalltalk, which provides a simpler syntax, much higher productivity and easier maintainability than other languages. It is the logical next choice for software developers as well as for businesses interested in reducing their total cost of ownership for software systems."

STIC's first large initiative is the organization and sponsorship of Smalltalk Solutions 2003, the premier forum for Smalltalk users, developers and enthusiasts. Taking place July 14-16, 2003 in Toronto, Canada, Smalltalk Solutions 2003 will feature keynote speakers Scott Ambler, senior contributing editor for Software Development magazine and member of Flashline Software Development Productivity Council, and David A. Smith, co-developer of Croquet software and creator of "The Colony," the first 3D interactive game. It will also host a number of sessions, including "Smalltalk for .NET," "Smalltalk for Eclipse" and "Recruiting Object-Oriented Programmers."

"Smalltalk Solutions 2003 will bring together hundreds of buyers and sellers of Smalltalk products and services, while updating the industry on the latest in Smalltalk technologies," added Davis.

For more information on STIC, please visit www.stic.org. To exhibit at Smalltalk Solutions 2003 or for more information, please visit www.smalltalksolutions.com.

About the Smalltalk Industry Council The Smalltalk Industry Council (STIC) is a nonprofit trade association whose goal is to promote awareness and increase demand for Smalltalk. STIC was reorganized in 2003 by Cincom, GemStone, IBM and Knowledge Systems Corporation, creating a cohesive Smalltalk community where information, technical issues, new ideas and concerns are openly discussed to benefit businesses as well as the software industry. STIC's membership consists of users, service providers and vendors of Smalltalk tools, components, databases and services. For more information on STIC, please visit www.stic.org.

Copyright 2003 Smalltalk Industry Council. All Rights Reserved

Via Matt Croyden:

Until Unix and Linux programmers get over their macho love for low-level programming languages, the security holes will continue to flow freely, argues SecurityFocus columnist Jon Lasser.

...

To be sure, some software must continue to be written in lower-level languages: Database servers such as MySQL will inevitably be written in lower-level languages for legitimate performance reasons. And it would be both unlikely and counterproductive for the Linux kernel or the system library to be rewritten in Perl, Java, or Python.

But none of those concerns justify writing an IRC client in C. And if it seems unimaginable for a print server to be rewritten in a high-level language, the reality is the benefit would be substantial and the performance costs negligible.

This is a message that most developers have not yet absorbed. See my post on premature optimization, for instance...

There's a good take on programming language evolution over at Reflective Surface. I won't quote a lot; there's way too much good stuff to extract - go read it yourself. This segment stood out to me though:

Another concept that has gained wider acceptance in the last years is that of dynamic typing. Many modern languages have opted for dynamic typing to improve productivity and reduce errors. It's curious that Java and C#, languages created with market considerations in mind, use static typing, and are forced to provide resources to "violate" that concept because of its failings. (Boxing is one of such "violations", which tries to remedy the gap between value and reference types in those languages.)

Yeah, it's as if the language designers almost got it, and then fell back on more confortable, but less useful paradigms...

BottomFeeder 2.8 has been released! There have been a lot of enhancements to this release - not least of which is the Feedster integration. Download the newest release now! Kudos to Rich Demers for the documentation, and to Dave Murphy for his work on this and on TypeLess, a truly cool IRC tool.

Via the C2 Wiki:

After an idea is tried and has failed, been tweaked and tried again, been tweaked and tried again, etc. my inclination to reject the idea and look for alternative solutions.

However, management (and colleagues) frequently claim that that they "know why it didn't work", proceed to address the most obvious manifestation of problems with shallow solutions and chant "ItWillWorkThisTime". (They disapprove of my "negative attitude".)

Lots more good stuff on this topic over there.

After releasing BottomFeeder 2.8, Dave created a new set of settings pages based on the VW 7.1 settings framework. I had held off on doing that for the 2.8 release, since it seemed like a big change. Looks like I should have gone ahead! The new pages work like a charm, integrate just fine with my settings backend, and - look way, way better. Vassili deserves a lot of credit for the new settings framework - it was so much easier for me to work with.

I'm going to add a new server side directory for upgrades - specifically for the dev stream. This way, I can upload new versions of the application that are under development, and have people willing to test them out do so - while not impacting people who would rather stay on a stable release. Since I haven't actually added any new development code, nothing much has changed. However, if you want to track the dev stuff, change the upgradeURL setting from:

upgradeURL='http://www.cincomsmalltalk.com/BottomFeeder/upgrades/'

to

upgradeURL='http://www.cincomsmalltalk.com/BottomFeeder/upgrades/dev/'

Keep in mind that dev builds are just that - DEV. That means they might break something; YMMV...

VPS = Value Prevention Society. In my experience, most IT departments are charter members of the VPS - they can't spell empowerment, much less practice it. Here's where I came across this notion, from Bob Lewis in Infoworld:

In late 1997, the U.S.S. Benfold was stationed in the Persian Gulf, one of the destroyers responsible for inspecting all ships entering and leaving Iraq . An average ship inspection required five hours.

The Benfold performed its inspections in half that time. How? A junior petty officer, Fire Controlman Derrick Thomas, built a PC database on his own that automatically filled out the boarding paperwork -- a 100-item questionnaire, for which most responses didn't and couldn't change for any given ship undergoing inspection.

Pull out your IT policies and procedures manual and ask yourself whether you would have allowed Fire Controlman Thomas to build his database in your company. If so, you're among the enlightened ones. Many corporate IT departments, led by charter members of the Value Prevention Society (VPS), prohibit end-users from making use of a personal database such as Microsoft Access.

Sounds familiar, doesn't it? The question is, how do we get past this problem?

Via the C2 Wiki:

I'm a serious Java proponent, I program only in Java now, and haven't programmed in anything else for over two years (except for one, short back-slide early this year). My job title has the word "Java" in it, for goodness' sakes.

However, the bitter truth is that it's not as productive, or as useful for rapid, bug-free programming, as Smalltalk. I used Smalltalk day in and day out for over six years. That followed almost two years of day-to-day use of C++. Out of the three, Smalltalk is still the hands down winner for productivity. I can develop probably 1.5X as fast in Smalltalk as I can in Java, which is probably 4X the speed with which I can develop in C++.

The Smalltalk libraries had at their inception things that are just now starting to make their way into the JDK 1.2 (e.g. real collections). There is nothing I can think of in Java that I have today (except possibly servlets) that Smalltalk did not have, usually better, two or more years ago.

So, why didn't Smalltalk win? Because in the marketplace the best solutions don't always get picked. It's the Dvorak vs. QWERTY effect, or the Beta vs. VHS effect. Java had Sun's massive marketing muscle behind it. It was the first language demoed in a browser, so it forever had the internet "shine" attached to it. The JavaBandwagon is a real phenomenon. Some jump on without knowing where's its going because it's flashy and hip, some leave their old, worn-out horses for a better, faster ride, and some sadly leave behind their first loves because it's quickly becoming the only show in town.

Sigh....

I updated the 2.8 parcels on the site - if you are running 2.8, it should detect the new parcels as being available and allow you to download them. You'll have to restart BottomFeeder - that's the way the update is implemented in 2.8. That could change in the next release, but I'm not quite sure yet. So what's new?

The Feedster and Google searches were having problems on error conditions due to a namespace lookup problem. That's addressed, and one other tweak as well - if you search from the item pane, the search uses the title of the item. Searches from the HTML pane will use the selected text in the item pane.

Bad things happen. Have a look at these bills pending in Florida and Massachussetts:

The (DMCA) Digital Millennium Copyright Act clearly isn't enough for some people. Massachusetts and Texas are - in curious formation - considering bills that will extend it to make firewalls (among other things) illegal.

The strange synchronicity is illustrated by a quick look at the draft of the Texas bill then comparing it with the Massachusetts one>, which you'll find in RTF format at Ed Felten's Freedom to Tinker, here. The strikeouts indicate that both, for whatever reason, have decided not to repress video this time around.

The repression that remains is however impressive. Felten points to this wording:

(b) Offense defined.--Any person commits an offense if he knowingly:

(1) possesses, uses, manufactures, develops, assembles, distributes, transfers, imports into this state, licenses, leases, sells or offers, promotes or advertises for sale, use or distribution any communication device:

(i) for the commission of a theft of a communication service or to receive, intercept, disrupt, transmit, re-transmits, decrypt, acquire or facilitate the receipt, interception, disruption, transmission, re-transmission, decryption or acquisition of any communication service without the express consent or express authorization of the communication service provider; or

(ii) to conceal or to assist another to conceal from any communication service provider, or from any lawful authority, the existence or place of origin or destination of any communication

That's right campers - these bills would outlaw NAT and encryption. Ahh, the joys of the clueless leading the blind....

Spotted in CLS:

Matisse Software Inc. is pleased to announce the availability of Smalltalk binding for VisualWorks 7 on the Windows and Linux platforms for its flagship product Matisse 6.0 DBMS.

Matisse 6.0 is an Object-SQL DBMS which natively supports objects, SQL, and XML based on the language-independent object model. Matisse supports many languages like Java, C++, C#, Smalltalk, Eiffel, Perl, Python, and PHP. These bindings share the same object model, so the database objects can be accessed through all the interfaces including SQL and XML.

The Smalltalk binding for Matisse is designed to directly map the database objects into VisualWorks avoiding the Object-Relational mapping and support the bi-directional schema evolution.

The binding is open source along with other language bindings, and has been placed on the public STORE repository

The binding and the free evaluation version of Matisse 6.0 can be downloaded from our download site

Cameron Shafie Matisse Software Inc.

The Fishbowl writes;

Peter Ghali asks about testing private methods:

So how do people test private methods....my opinion is that you should test private methods at all. Adequate test coverage should cover these methods through testing of the public and protected methods that use the private methods. However....

I don't test private methods. Being able to quickly create, move around, and change the functionality of private methods is vital to remaining agile while developing.

There is a significant cost involved in changing the behaviour of your public interface: you have to make sure each caller can cope with the change. Sometimes you even have to write new tests for each caller because you have introduced some new edge-case that wasn't there before. Private methods, on the other hand, can always be tested by running the tests for the enclosing class. If you've introduced a new edge-case, you only ever have to write new tests for that one class. It's all self-contained.

This sounds reasonable. The only problem I have with it is that too often, the public interface for something is either under-specified or simply inadequate. I think the best you can do is call this a goal, not an iron clad law of development...

I've started light - so far, there's ctrl-n for next unread, and ctrl-p for previous unread. All by itself that's pretty cool; now a few more - search and browse at least.

I added a bunch of keyboard shortcuts to BottomFeeder this evening. The shortcuts are as follows:

• ctrl-b - Browse (either the feed or item)
• ctrl-l - Close the selected folder
• ctrl-n - Select next unread item
• ctrl-o - Open the selected folder
• ctrl-p - Select the previous unread item
• ctrl-r - Mark all items (in feed or folder) read
• ctrl-s - Open the search tool
• ctrl-u - Mark all items (in feed or folder) unread

Makes it a lot easier to use, that's for sure.

I've been adding a bunch of shortcuts to BottomFeeder over the last two days. They are only in the dev versions - to see that, just change your upgrade settings as indicated here. I listed the initial set of shortcuts here, but I've since done more work. The full listing can be found on the Wiki project page.

Suggestions Welcome.

Via Reflective Surface comes this amusing urban myth that's been making the rounds:

"We don't believe this guy's story - either he's either a lunatic or a pathological liar," says an SEC insider.

"But the fact is, with an initial investment of only $800, in two weeks' time he had a portfolio valued at over $350 million. Every trade he made capitalized on unexpected business developments, which simply can't be pure luck.

Carlssin declared that he had traveled back in time from over 200 years in the future, when it is common knowledge that our era experienced one of the worst stock plunges in history. Yet anyone armed with knowledge of the handful of stocks destined to go through the roof could make a fortune.

"It was just too tempting to resist," Carlssin allegedly said in his videotaped confession. "I had planned to make it look natural, you know, lose a little here and there so it doesn't look too perfect. But I just got caught in the moment."

In a bid for leniency, Carlssin has reportedly offered to divulge "historical facts" such as the whereabouts of Osama Bin Laden and a cure for AIDS.

Officials are quite confident the "time-traveler's" claims are bogus. Yet the SEC source admits, "No one can find any record of any Andrew Carlssin existing anywhere before December 2002."

I've always wondered how these urban myths get started - once they start making the rounds, they just circulate via email, newsgroup postings, and now blogs. But I'd be curious to know how one gets initially established.

We tried to have dinner out tonight with friends, but the three kids (their two and our one) simply couldn't sit still and agree on who was going to sit next to whom. We ended up having to bail on the restaurant and get carry out - and that caused a small problem, as they lost an order.

That made us all nice and perky for board game night. What with the war on, we considered Tigris and Euphrates, but that looked like it would require too much thinking. So we settled on a game we hadn't played in awhile, Ra. Unlike my recent string of successes with Puerto Rico, I got washed and waxed right from the first turn - I messed up all the bidding. Better luck next time - and with any luck, better behaved children....

Over at Strongly Typed I saw this riff on Prevlayer:

Joshua writes about the delusions between "prevalence" and database systems.

"...in terms of functionality, Query Processing, Storage and Indexing are rarely things that a programmer can implement better than the professionals. Most of the innovation in terms of "persistence" layers revolves around the Data Access layer, and the fundamentals of the rest of the storage stack remain relevant."

.....

I don't think it's quite fair to compare the two systems in most respects. They are each best suited for areas that lightly overlap. In this case both are not a hammer.

Interesting. It's a fair point, and one that extends to other areas. You need look no further than the huge number of buffer overflow exploits to see that memory management is another area that the average developer should not be dealing with. Based the quality of the RSS Feeds I see, production of XML is another.

More snow is falling!!!

Too warm for it to stick to the roads (yet), but it's late March already....

Every so often, I've had feeds that produce errors and kill the update process in BottomFeeder. That's why there's a manual restart, and a watchdog process. However, that can cause cycling issues with a feed that is busted - the update loop dies over and over again in the same place, while the watchdog keeps restarting it.

With the latest dev build (if you have your 2.9 dev build set to the correct dev build directory, you'll see it as an available option), I'm trying a fix for that. It's hard to test; I don't have a bad feed at the moment. What should happen is that a bad feed should get visibly marked as bad and not get updated any longer by the update loop.

I still need to add a menu option to allow setting a feed from bad to good - but more importantly, I need to know if this works, or causes problems. Please let me know if you get feeds marked as bad (all black) that you think shouldn't be, or if this attempted fix causes problems.

Not only are there a variety of blogs covering the war from the field, but now - potential Presidential candidate Gary Hart is running a blog. I'm not commenting on the content of either blog here; merely pointing out that blogs are being used by more than just pundits and tech weenies now.

I ran across an interesting problem today. I was trying to add a feed, and it wouldn't parse. Nothing looked wrong on a casual view in IE, so I inserted a break point at the start of the XML parsing to see what was happening. The RSS feed in question is here - if you look carefully, you'll see an invalid character in the first entry. At least as of the time of this posting :)

I decided that I ought to allow such feeds through, so I took a look at the XML Parser. Overriding #next in StreamWrapper did the trick, but I wasn't satisfied with that - if BottomFeeder was loaded into a dev image, my hack was going to affect all uses of the XML parser. I had already subclassed the XML parser to prevent that problem; I wanted to subclass StreamWrapper as well.

It turns out that it's referenced 6 places - changing all six from direct refs to something like this:

StreamWrapper blah

to

self streamWrapperClass blah

did the trick. Modified the six methods, and implemented the method above in XMLParser and in my subclass. That allows me to modify as I want, without hosing off other XML clients (like, say the source manager in VW). It also allowed me to add the feed I mentioned above to my subscribed list, which was my original goal. I think I've made the parser more pluggable by doing this. Anyone else have thoughts on it?