Smalltalk Tidbits, Industry Rants

Register for StS 2004 so that you don't miss Michael Lucas-Smith present withStyle:

Smalltalk WithStyle
presentation
Michael Lucas-Smith: Wizard Information Services
Monday 2:00:00 pm to 2:45:00 pm

Abstract: Recent years have seen many software development projects moving away from desktop clients to Web Applications. Unfortunately, whilst today's Web Applications offer some benefits (particularly for implementors), they constitute a significant step backward for users. Usability and productivity suffer as user interfaces are 'dumbed-down' to fit a request-response model reminiscent of green-screen terminals. The IT industry has again manufactured new limitations that need not exist.

With:Style WebUI is a 100% Smalltalk user interface technology that frees user interfaces from the limitation of Web Browsers that were not designed to meet the UI requirements of business applications. The quality rendering capabilities of the With:Style technology prove the strength of Smalltalk as a first-class user interface platform that need not be fragmented and tied to Java or Windows-specific front-end technologies.

As a customisable XML presentation technology, With:Style offers many deployment models and even more possibilities for rich, 'hybrid' user interfaces through integration with Pollock. It fits in naturally with server-side Web applications and emerging Service Oriented Architectures. Demonstrations will include XML Editing and Scripting client-side behaviour with Smalltalk.

Bio: Michael Lucas-Smith currently works at Wizard Information Services as the head of Research and Development. While at Wizard he has worked on Smalltalk business applications ranging from an Audio/Visual Archiving system to web content management software.

He has been involved with computers since age 4 and first came in contact with the concept of "Online" when he ran a BBS from his bedroom in high school. His software interests range from Commodore64 assembler through to modern business applications.

He has spent the last four years using VisualAge and the last two using VisualWorks. Michael is a co-author (with David Murphy) of the TypeLess irc client written in VisualWorks, has helped with James Robertson's Bottom Feeder and has contributed goodies such as StackOverflow and ThreePaneSelectorsBrowser.

Michael has recently started Software WithStyle with three other partners to pursue the WithStyle WebUI technology, a Web-based User Interface thin-client using XML.

See you in Seattle!

Many C level managers have an almost magical faith in the ability to take projects offshore. The amusing thing is how many of the same managers distrust telecommuting. The issues for the two are very similar, although offshoring typically adds greater distance and cultural issues into the mix. I ran across an interesting case study in the Wall Street Journal on this - the summary is copied below:

ValiCert expected to save millions annually while cranking out new software for banks, insurers and government agencies. Senior Vice President David Jevans recalls optimistic predictions that the company would "cut the budget by half here and hire twice as many people there." Colleagues would swap work across the globe every 12 hours, helping ValiCert "put more people on it and get it done sooner," he says.

The reality was different. The Indian engineers, who knew little about ValiCert's software or how it was used, omitted features Americans considered intuitive. U.S. programmers, accustomed to quick chats over cubicle walls, spent months writing detailed instructions for overseas assignments, delaying new products. Fear and distrust thrived as ValiCert's finances deteriorated, and co-workers, 14 times zones apart, traded curt e-mails. In the fall of 2002, executives brought back to the U.S. a key project that had been assigned to India, irritating some Indian employees.

"At times, we were thinking, 'What have we done here?' " recalls John Vigouroux, who joined ValiCert in July 2002 and became chief executive three months later.

Shifting work to India eventually did help cut ValiCert's engineering costs by two-thirds, keeping the company and its major products alive -- and saving 65 positions which remained in the U.S. But not before ValiCert experienced a harrowing period of instability and doubt, and only after its executives significantly refined the company's global division of labor.

That last paragraph is the instructive part - eventually, they saved money. It required a lot of learning about what worked, what didn't, and a lot of uncertainty (and near disaster) in between. What does that mean? It means that offshoring work is not to be taken lightly - you have to look at as a project that is on a scale with installing a corporate wide ERP system. It's going to require changes in internal culture and processes. Consider how many ERP projects founder on those shoals, and you'll start to see why so many offshoring projects run into problems - changing culture and processes immediately gets into internal politics. Many people will fight against the changes based solely on inertia. In fact, if you know that large scale change like this is unlikely to work at your firm, then offshoring is likely going to be a very, very dicey proposition. If you have trouble with internal communications, sending work 12 hours away is only going to make things worse.

Bottom line - it's not that offshoring can't work (clearly, there are firms that make it work, just as there are firms that make telecommuting work). It's a big change though, and something that should get looked at seriously, rather than the almost offhanded "lets save a bunch of money" kind of thinking that seems to be all too common

For the most part, I like Eudora - it has a decent interface for setting up filters and is generally a nice email client. Today I ran across a limitation that ticked me off though. I get cc'd on all the mails from the NC download application - it's a useful backup of the information entered, especially if people don't receive the emails (likely do to spam blocks). I've never deleted or archived mail from that folder, and that got me into trouble today. I clocked over 32K messages in that folder at some point today, and Eudora crashed. That's always an irritation, as I get everything back in my inbox since the last mailbox compaction. However, it was worse today - everytime a new mail for that folder came in, Eudora would get baffled, and eventually crash. This got tiresome in a hurry. Eventually, I ended up having to open the blasted folder file in an editor and trim off old messages by hand, and then let Eudora rebuild the table of contents on startup. Yeah, I know that 32K messages is a lot. On the other hand, I was keeping them easily accessible for a reason. Why should there be a limit like that? Here's another place that static typing is "helping" me. Someone at Qualcomm decided that a specific size integer was all "anyone would ever need". Sigh...

Tim Bray has more on the MS funding SCO thing:

Business Week says that Microsoft did lead the Venture Cap horse to the SCO trough. I tend to trust Business Week. Uh, would Martin Taylor like to clarify his statement that the allegations "are not accurate"?

Back to Scoble :)

Based on this post by Dare Obsanjo, it looks like 'Generics' means one thing in C++, and something else in C# and Java:

Although Bruce didn't confirm whether the above limitation exist in the C# implementation of generics he is right that they have the same limitations as Java generics. The article An Introduction to C# Generics on MSDN describes the same limitations Bruce encountered with Java generics and shows how to work around them using constraints as Bruce discovered. If you read the problem statement described in the article on MSDN it seems the main goal of C# generics is to solve the casting problem in containers

Yet another case of developers being separated by terms used in variant fashions. Dare has a lot more than that paragraph; go read the whole thing

I just noticed Glenn Vanderburg's blog via the referers list on my site. He's writing some good stuff; subscribe here. I particularly like this post :)

If the rants here aren't enough for you, then visit the BileBlog. I really like this post on how insignificant we (developers) really are :)

Neither Scoble nor MS get it

So, if you want us to ship more often, you are asking us to ship lower-quality stuff. It's just human. There's only so much testing one human can do in a day (and, keep in mind that even though we have tons of computers running tests 24-hours-a-day a human still needs to fix the problems found). There's only so much testing that can be done. Only so many bugs that can be fixed in a day.

Hmm. Maybe if your teams didn't come up with (insert grandiose plan here) tasks that will:

• Take years to implement
• Be outmoded by the time they ship

You wouldn't have this problem. Here's a tip - go tell your project teams to start shipping every 6-9 months. Have them lay out long range plans, sure - but the teams will have to come up with actual deliverables that can be shipped in a short time frame. It will likely take a couple of cycles for them to figure this out, but they'll get it. You know what will happen? You'll deliver incremental progress to customers on a regular basis - and you'll have a chance to do course correction every few months

What do you have now? You have (insert huge monolithic plan here) a large set of work that will take years to complete (witness Longhorn). How do you course correct a 5 year plan (hint - it didn't work so well for the Soviets). It's time for your teams to get more agile, and ship more frequently. Your customers will see progress, and your marketers will get actual feedback as to whether you are headed in the right direction.

As to quality? I rather suspect that delivering incrementally and more frequently will improve that far, far more than what you are doing now...

Brian Marick defends the use of text files (as opposed to what most Smalltalks do):

Very tangentially, I'm reminded of those who claim that the failure of Lisp and Smalltalk was partly due to their being hermetic - taking all data on their own terms, not the world's. They failed to embrace the string and the regular expression.

Failed to embrace the string? What the heck does that mean? The regular expression? What, you would rather grep for text than uses senders/implementors? This is what I love about the complacent curly brace crowd - the sharp sticks and pointy rocks make them so happy :) But wait - there are wild assertions ahead!

(Not just to pick on Lisp and Smalltalk, two fine languages: how long did it take for a regex class to make it into Java? And a regex class is one significant affordance notch below regexps built into the language.)

All I can say to that is huh? Please explain how having regexp built into the language - i.e., inextensible - is better than having a regexp library which I can extend and modify? This just makes no sense...

Markus Kohler points out that SOAP is still less functional than CORBA, and slower to boot. I'm wondering what nifty RPC interop mechanism will be all the rage in 3-5 years instead of SOAP - maybe Markus already has the answer to that

Register now for StS 2004 so that you can hear James Foster on making apps test friendly:

Building a 'Test-Friendly' Application
presentation
James Foster
Monday 2:00:00 pm to 2:45:00 pm

Abstract: Your manager has just seen a demo of a popular automated testing tool, and decided it will solve your quality problems. The tool records a user's interaction with your application and then plays back those interactions so that applications "work flawlessly the first time and remain reliable." Of course, the devil is in the details, and you've been assigned to deal with the details. What happens next? In this experience report you will see how a Smalltalk application was modified so that the automated tests worked when a window has hundreds of widgets, many with the same label. Find out why the flexibility of Smalltalk prompted a WinRunner consultant to say that this was what he wished all development environments could do.

Bio: James Foster learned FORTRAN in 1971, Smalltalk in 1993, and a few other languages in between. He has been developing healthcare systems since 1987 and is presently Software Architect with BulldogIT. He has presented at prior Smalltalk Solutions and at OOPSLA conferences.

See you in Seattle!

I wrote about release cycles yesterday, and I thought I'd expand on the thought a little. As I said yesterday, I value "release early, release often" quite highly. To my mind, having a short release cycle improves quality quite a bit - and I think the proof is in the pudding (VW 5i.3 through the present have been on short cycles). There's a constant tension in this between Product Management, Engineering, and some customers though:

• Some projects cannot be done in a short (6-9 month, in our case) cycle. Pollock, for instance
• Some engineers want to extend the release cycle in order to get a long project done within a cycle
• Some customers object to short cycles, as they cannot possibly update to new releases given technical and political constraints in their shops

To my mind, all of these are

• Outweighed by the benefits of a short cycle
• Fairly easy to address

Ok, so how do you address them? Let's take them one at a time:

Long term projects
There are projects that will span multiple release sycles. Some will span multiple cycles while they are under initial development, and some will have only a partial implementation when they first hit the street. Pollock is an example of the former; the Web Toolkit is an example of the latter. Pollock has been an ongoing project for us for a very long time now. The engingineering team working on it has pushed early releases of it out in a pre-beta form over the last few cycles, and has made ongoing versions accessible to the vw-dev team. I think this has worked out well for us.

How so? Well, even though it's taken a number of cycles to get to the point it's at, it's been available for comment for quite awhile. There have been some very lively design discussions on the Smalltalk IRC channel - and some very good ones on our developer mailing lists. Pollock has been developed "in the open", across multiple short cycles. I think it's an example of how long term development is not only possible, but works very well in this scenario. The multiple cycles over the life of the project have also afforded us a lot of opportunities for course correction and adjustment - something I simply have not seen happen over long cycles (The development of ObjectLens for VW 2.0 being perhaps the best example in my memory).

What about Web Toolkit? It came out for VW5i.4 - with some limitations and issues, but in a usable form. People - myself included - started using to build web applications, and the development team was able to see what kinds of things were actually important to end users - as opposed to what they might have thought would be important. Development has continued across VW 7, 7.1, and 7.2 - with quality improving at every step, and course corrections possible at every step.

I think these two projects illustrate how long term development is not only feasible within the context of short release cycles - properly planned, it can actually improve things. The issue with a long cycle is that developers tend to "hunker down" and build to their original design - without much feedback from the outside world. Shorter cycles force that feedback. Sure, one could posit a long cycle with feedback - but in my experience, it just doesn't work out that way. Long cycles encourage a "specs over the wall, product back from the wall much later" approach. That's an approach no one's happy with, except for the insular engineer who doesn't actually see that as a problem :)

Engineers who want a longer cycle to "just get it done"
I think this one is easy to push aside simply based on the entire history of softeware development projects. Extending the time doesn't help. Why? Software developers are notoriously bad at estimation. Give them 2 years, and they'll see an endless expanse of time, and shoot for the stars. Give them 6 months and they'll still aim too high - but it will be obvious a whole lot sooner. Engineers are also no better than anyone else at visualizing what the marketplace will look like in 2 year's time - and giving them a long cycle to develop "the next big thing" will likely result in "the last big thing". Everyone needs check points - if you don't have time for course correction, you'll wander down a lot of ratholes. With short cycles, you'll still wander down a few - but at least it'll be for less time, less money, and with more of an opportunity to see the mistake early. Go pick up any number of trade journals and you'll see stories on projects that were disasters simply due to delivery past the point of impact

Customers and their ability to keep up
This is the most serious one - because now we are talking about the people who pay our salaries :) Short cycles do make it harder to keep up, even if each incremental update is "painless" (and they won't be). In the end, it doesn't matter though. Why? Well, most customers will only be ready to update when they have a large milestone on their own projects. At that point, they can take what you have and migrate to it. That may be at 12 month, 18 month, or even longer intervals. But so what? If you had a longer cycle, there's no better chance that yours will align with theirs anyway - and that might mean 3, 4 (or even more) years between upgrades. That's going to be much harder for them to deal with (and believe me, I have experience with this). Counter-Intuitively, a short cycle actually makes it easier for customers to keep up.

As they hit a milestone, it's likely that you shipped some incremental release recently - so they can move up to that. Moving to something that's seen 18-24 months of churn is going to be easier than moving to something that's seen 24-48 months of churn. It turns out that short cycles do a better job of keeping customers on something current - long cycles make the eventual upgrade look very scary, and keeps a fair number of your customers on ancient back releases. An incremental cycle has a far better chance of minimizing that risk.

Ultimately, I believe that shorter cycles are better for engineering, better for your product's quality - and most importantly - better for your customers.

According to Sun, it's not good enough. Researchers are looking for more dynamism. The failure rate for Java projects is still atrocious. Sun's researchers don't believe in the language. C# is a sideways step to the same place.... heck, we even have hard data on some of this. And yet, many analysts will still tell you that you should stay in the "mainstream" - apparently, failure is better than unpopularity if you're an analyst (I guess it's still high school prom time for them).

And developers wonder why outsourcing and offshoring are popular....

Now this is an interesting thing - MS' HR department has a blog, complete with an RSS feed. Sort of makes the MS doesn't get RSS comments by Sun's Jonathan Schwartz look even stupider...

In response to this post, I got a question about release cycles and their relationship to product pricing. That's a great question, and it allows me to expand on something that confuses a lot of people - the pricing model we use for Cincom Smalltalk. Let me talk about our pricing model first, and - in the process of doing that - I think I'll be able to address the release cycle/pricing thing

First off, I'm going to say something that a lot of you are going to question at first:

We don't sell development tools

That's right campers, we don't sell development tools. We sell a platform on which you can develop and deploy applications. Think about it - you develop and deploy on the same system - it's a platform (like J2EE or .NET) as opposed to a development tool (like Eclipse or VisualStudio).

Now, with that small bit of explanation out of the way, let me switch gears to pricing. We have a small number of pricing plans:

• End user based (for internal, client/server applications)
• Server based
• VAR (for resellers)

We offer these on an annual subscription basis. In most cases, the number of developers are unlimited - which goes along with the idea that we aren't selling development tools - we don't price on the basis of developers, we price on the basis of platform usage. Now, how does any of that relate back to the release cycle? Well, if we are going to sell on an annual subscription basis, there had darn well better be some value. That's a large part of why we have short release cycles - it's a way of demonstrating value for the annual subscription. We not only give full support, but - during the span of a subscription, our customers get each and every release we put out. That's value back to them in a few ways:

• New features on a regular basis
• Incremental, hopefully easier to update to releases
• Concrete evidence of progress

That last one is perhaps the most important one for many people - they want (and need) assurance that their investment in our product is safe. With any commercial venture, the proof is in the pudding - all the words in the world from me (or anyone else) are just that - words. Steady, ongoing releases, on the other hand - that's everyday proof of stability and commitment.

Dan Fernandez writes about early access to the (due in 2005!) next release of VisualStudio. Simply having these thoughts at all should push you towards a shorter release cycle, IMHO:

Does Microsoft Give Access too Early?
After reading these posts on Whidbey and in thinking about the backlash on Longhorn (too much info too early), it occured to me that maybe its not such a good idea to give the broad developer community early access to code. I'm not saying this because we don't value everyone's opinion, but because it might be dangerous to set such high expectations.  What happens when you see a great feature and you see that it won't be available until the next release?  Some features you like may or may not make Whidbey, it's a technical preview, we really cannot give any guarantee as to what the final product will look like.  As Jay points out, we're even starting to give developers interim builds in a continuous effort to make Microsoft more open to developers.  I would assume this would be a good thing, but there is risk in this approach. The risk is that we over-promise and under-deliver which leads to developers being angry, which is the exact opposite of what we're trying to achieve.

Well, if you release every 6 to 9 months, that ceases to be a problem. We have given developers access to our ongoing builds for quite awhile now - and I'd have to say that it's been overwhelmingly positive - we get bug reports, bug fixes (admittedly, this is easier for us - a Smalltalk system ships with all sources), and we set expectations very concretely - over time, developers have gained a feel for what we can and can't do within one cycle, and they evaluate the builds based on that. It's interesting to see just how many negatives start to flow from having an extended release cycle...

Register now so you can hear Michael Lucas-Smith talk about using XML with Smalltalk. This is a not to be missed talk; Michael's been doing some very cool work with both VisualWorks and VisualAge.

Smalltalk, XML on the Web presentation
Michael Lucas-Smith: Wizard Information Services
Monday 2:45:00 pm to 3:30:00 pm

Abstract: Although much XML-related work is being pursued in the systems integration and Web Services arenas, the way in which Object Oriented software can benefit from an XML Architecture at a more fundamental level has been largely overlooked. Software Architectures can benefit greatly from the unity and flexibility of a loosely-coupled XML-on-HTTP model that talks to Web Applications and Web Services natively. This experience report discusses how Wizard Information Services is adapting it's core applications architecture to be XML-based whilst taking full advantage of Smalltalk and its Object Oriented paradigm.

Wizard has taken business objects stored in a relational database and opened them up to the XML world by adding an XML server built on VisualAge's Server Smalltalk technology. Internal SOAP transactions are transparent to clients that may choose a simple HTTP access method. A powerful XML transaction infrastructure can then be built using the Apache Group's Cocoon XML publishing server on top of a Smalltalk server writing XSLT to process XML updates. This experience has provided some insight into the effectiveness of SOAP for running services in a Smalltalk image.

Bio: Michael Lucas-Smith currently works at Wizard Information Services as the head of Research and Development. While at Wizard he has worked on Smalltalk business applications ranging from an Audio/Visual Archiving system to web content management software.

He has been involved with computers since age 4 and first came in contact with the concept of "Online" when he ran a BBS from his bedroom in high school. His software interests range from Commodore64 assembler through to modern business applications.

He has spent the last four years using VisualAge and the last two using VisualWorks. Michael is a co-author (with David Murphy) of the TypeLess irc client written in VisualWorks, has helped with James Robertson's Bottom Feeder and has contributed goodies such as StackOverflow and ThreePaneSelectorsBrowser.

Michael has recently started Software WithStyle with three other partners to pursue the WithStyle WebUI technology, a Web-based User Interface thin-client using XML.

See you in Seattle!

The NYSTUG has a fascinating meeting coming up - a fifth grade teacher in New York is going to talk about how he uses Squeak (EToys) to teach programming at the elementary level:

Please join us for our next meeting to be held Wed March 31st

Presenter's Bio:
Seth Orbach is Director of Academic Technology at St. Bernard's School in New York City. He has a B.A. in Architecture from Yale College and a M.A. in Mathematics Education from Teachers College, Columbia University. He first began teaching Squeak to fifth graders at Trevor Day School several years ago after hearing Alan Kay speak at the NYSAIS Conference on Information Technology in November of 2001.

Presentation Abstract:
"E-Toys is a version of Squeak designed for use with school-aged children. I will present some of the introductory lessons that I use with students, some of the more advanced challenges, and examples of student work from my 3 years of teaching with this tool. I will also discuss and demonstrate the pedagogy used in my constructivist classrooms."

Details:

Date:	March 31st, 2004
Location:	Suite LLC offices
Address	440 9th Avenue, 8th Floor
Time:	6:30pm to 7:00pm -- Open house
Time:	7:00to 8:30 pm -- Squeak in NYC presentation.

Directions:
Take E or C train to 34th (Penn Station) walk to corner of 34th and 8th. Walk up one block to 9th.

RSVP is requested. Please send mail to: charles@ocit.com with subject line of: NYC Smalltalk March 31st 2004. Our meetings are opened to the general public. Invite a friend ! To join our mailing list simply send mail to nycsmalltalk-subscribe@yahoogroups.com

Joining our list will give members access to all of the presentations and articles maintained on our site.

Sounds interesting - check it out

Register now so that you can hear all about Cross Dialect Smalltalk Portability at this year's Smalltalk Solutions:

Dialect Portability
presentation
Giorgio Ferraris: Elevensoft
Monday 2:45:00 pm to 3:30:00 pm

Abstract: This talk describes work on creating a dialect portability layer. This more than just translating syntax between dialects, but also having a base of services in different areas such as GUI, Compiler, and file handling.

Bio: Giorgio Ferraris is a chemical engineer totally devoted to software. After years of work as a software free-lance consultant he co-founded, 15 years ago, Eleven srl, a small (20 people) Italian firm developing turn-key software solutions.

He started using Smalltalk more than 15 year ago (Smalltalk/V). He began following the international community first using Compuserve and the Digitalk forum, then participating in Smalltalk and OO related user conferences, starting from the Digitalk one, to SmalltalkSolution and OOPSLA.

He has been involved on OO analysis, design and architecture definition for 10's of customers (from small to medium to large). He follows his company's internal projects like lead technical mentor.

He has held several tutorials on OO, Smalltalk, OO analysis and design for 100's of Italian people and has worked as a mentor and supervisor on several OO projects. He is currently working as a mentor on several OO projects in Italy (Smalltalk, Java and C#), and helping a big italian customer on migrating to Smalltalk.

See you in Seattle!

I've been watching Stargate SG-1 for quite awhile now - I think it's the best Sci-Fi show on TV now. Sure, there are a few issues - the expeditionary teams are too small (4 people) and the wrong service (they play Air Force, they should be Marines). Those are nits though; the team size is a compromise to allow for character development. What's good about the show is the writing - contrasting it with Star Trek: Enterprise is particularly bad - for Star Trek

What do I mean by that? Well, there's always "and then a miracle occurs" moment on Star Trek - one where some seemingly unsolvable conflict is solved, typically without force. I fully expect last week's cliff hanger to end the same way, without any difficult choices having to be made. Stargate, on the other hand, does confront the characters with crappy choices and "least bad" alternatives (look at how they ended the replicator threat, for instance - no "everyone ends up happy" outcome there)

I'm wondering how things are going to progress this year - they have done a couple of things that offer some interesting possibilities, but also some areas that could be hard to deal with:

• The Stargate program has been revealed to other major nations (last year)
• There's just been a change in administrations in the series world, with their political opponent Kinsey becoming the new VP
• It looks like next week's episode will make the existence of the Goauld public (world-wide) knowledge

I'm very curious to see how well they deal with that - it's a big change in the dynamics of the series. For the most part, I'm happy with changes in that direction; I think X-Files washed all the interest (at least for me) out of the "evil government conspiracy" back story. I guess we'll have to see how it develops - but I'm interested in seeing how it does. With Enterprise, I tend to miss shows, and just not care a lot...

Artima has an interview with Bertrand Meyer where he goes into exception handling. Meyer, for all his erudition, seems to have no real familiarity with dynamic languages (Smalltalk, Lisp, Ruby, Python, etc):

The exception mechanism in Eiffel is quite different from those that exist in other languages, and it surprises many people. When you have an exception in Eiffel, you only have two ways of reacting to it. The reason that you only have two ways is that exceptions are something that you don't want to see happening. So it's quite different from the approach that says exceptions are special cases that we are going to expect and process in a special way. In Eiffel, exceptions are really a sign that something quite wrong has happened, so you have only these two ways of reacting. One is to accept that you can not do anything better, and to just pass on the problem up to the next routine up the call chain, which of course will be faced with the same dilemma. That is often, especially for operations deep down in the call chain, the only real world reaction, because the operation does not have enough context to do anything smarter. The other reaction is, if you actually do have some elements that enable you to think you're smarter, to attempt to fix the condition that led to the exception and try the same operation again after correcting the context. This is the kind of mechanism that provides direct support for what I was calling software fault tolerance, and I think it can be quite effective provided it's used with reason, that is to say, not as another algorithmic mechanism, but as a mechanism of last resort

Somehow, I doubt any Smalltalkers are surprised (we have a fairly rich exception framework, and one I take good advantage of in BottomFeeder). I guess Meyer's world view goes as far as the C language family and Eiffel - and no further....

There's a new language that's gotten some press - Scala. Sounds like an interesting merger of OO and functional languages...

There's been a lot of interest in Continuation based web frameworks lately - come to StS 2004 and hear how to use Seaside, the most mature of them. Seaside has been implemented for both Squeak and VisualWorks - this Tutorial will show you how to make it sing:

Seaside
tutorial (extra cost applies)
Julian Fitzell and Andrew Catton: UBC
Monday 2:00:00 pm to 5:30:00 pm

Abstract: Dijkstra may have taught us a half-century ago that GOTO was a bad idea, but web development has yet to catch up. Even modern frameworks, such as Struts and WebObjects, offer no alternative to the web's inherent GOTO: moving from one page to the next is still a plain one-way jump. This hands-on, half-day tutorial will show participants how to harness the Seaside framework to bring the power of subroutines to the web.

Seaside avoids the tangled and brittle mess of interdependent pages common to web applications by hiding the mechanics of the HTTP request/response loop. Each page or form acts much like a subroutine, returning a value to its caller based on user input. Complex workflows can be described by using existing conditional and looping constructs and "calling" other pages -- just as you would write any other application logic. The improvements this brings to web applications, in terms of reusability and maintainability, closely mimic the advances made by structured programming long ago.

Seaside sports callback-based form widgets (no manual request processing), transparent embedding of pages or even whole applications, and a library of prebuilt components. It also provides a complete web-based development environment, with code browsers, inspectors, debuggers, and profilers, all implemented using Seaside itself.

Along with coverage of framework basics, special attention will be given to three topics:

• writing cleanly reusable pages and components;
• separating page logic (how an individual interaction works) from application logic (how interactions are strung together to form workflows); and
• proper management and support of the all-important browser back button.

Participants should bring a laptop or be prepared to pair up.

Bio: Julian Fitzell is one of the lead developers of Seaside and an active contributor to the Squeak Smalltalk community.

Andrew Catton is a longtime Seaside user and contributor.

Both are located in Vancouver and use Seaside in their development roles in the Agile Projects Group at The University of British Columbia.

See you in Seattle!

I've just added digest authorization support to BottomFeeder - this allows users to deal with protected feeds on LiveJournal. Grab the Http-Access update from the server, and you should be all set.

Adding this was made easier by Smalltalk. The basic Http libraries in VisualWorks do not handle digest authorization. All the support for Basic auth was in, but not for digest. Fortunately, I can extend those libraries in Smalltalk. Sure, it would have been simpler yet had the support been in the libraries, but face it - no matter what vendor and language you pick, you aren't going to find support for everything. VW supports most of what I needed in Http, and it was a fairly simple matter to extend the support to digest

The hardest part for me was reading the spec and following it - I'm not normally dealing with IETF specs, and I'm more of an application level developer than I am a framework/library developer. Fortunately, all of the code necessary to produce an md5 hash are already in VisualWorks - the basic code for creating what the spec wants looks like this:

stream := WriteStream on: String new.
stringToHash asByteArray md5Value printOn: stream base: 16.
hashString := stream contents.

Now, that's a mouthful to write everywhere I needed it (digest auth has you hash a bunch of stuff). So, I added a method to class String, so that I could just call it naturally:

md5Hash
	"answer a hexadecimal encoded hash"

	| stream |
	stream := WriteStream on: String new.
	self asByteArray md5Value printOn: stream base: 16.
	^stream contents asLowercase

Which allowed me to get the hash string easily, That's one of the niftiest things about Smalltalk, actually - the ability to toss extension code exactly where it belongs, which ends up empowering the developer later on - it's just that much less code to write downstream

In any event, Digest Authorization is now in Bf; enjoy! I'd like to thank Mark for providing a test site for me to hit (and a nice sample request!), and Michael Lucas-Smith for some useful tips when I was a little stuck

After my last post on adding Digest Authorization, I ran across this from the NewsGator guy, Greg Reinacker

We had a show-stopper bug in the .NET 1.1 framework, which would pretty much grind NewsGator to a halt on certain (fairly rare) configurations. This problem was costing us dearly, in a measurable way. Working with PSS, they issued a hotfix for the problem, which solved it nicely.

We then worked with Microsoft to get a limited redistribution license. The bottom line? We can distribute the fix to our customers who need it. It took a little paperwork, but it made sense for everyone.

Now, contrast that with a system where you get all the sources, and have the ability to modify them. VisualWorks isn't "Open Source" in the OSDL sense, but it's Open Source in the access sense - you have access to all the sources, and can modify them as you see fit. I've had similar show stopper bugs in VW (admittedly, as the Product Manager my access to the engineers is a little better :) ). I started building BottomFeeder in VisualWorks 7.0, and there were a number of issues back then - in some of the widgets and in the Http access libraries. I've been able to extend and enhance the libraries when I needed to, and shipped Bf with those fixes in. Sure, I updated the relevant engineers on what I was doing, and sent along my code as an example of how I was solving the problems. The nice thing is, none of this was dependent on my status as Product Manager. We have customers who create fixes and send us their code all the time. It's not always the case that their fix is what engineering considers to be the ultimate answer, but it gets the job done without their having to wait on our schedule.

That's the crucial piece - it's not always the case that you can afford to wait for the vendor to issue a fix - but if you pick the mainstream solutions, that's the hole you dig yourself into.

Ben Hammersley asks Dave Winer a few questions about his RSS/Atom merger proposal:

"The format would differ from RSS 2.0 as little as possible" and "It would be backward compatible with RSS 2.0, so that any 2.0 feed could become an RSS/Atom feed by changing (fill in the blank, as little change as possible)."

What's the difference between this and saying that Atom should be abandoned? Currently, Atom documents are very different from RSS 2.0 documents, so adhering to these two points would basically mean leaving Atom completely, or do I have it wrong?

The question isn't wrong, but it does touch on something interesting at the technical level, which is this: there's little difference between Atom and RSS at the document level. The two formats convey exactly the same information, in exactly the same way. Atom simply changes the tag names, and adds in three (instead of one) date fields. Heck, in BottomFeeder I use the same exact domain objects for both kinds of feeds. That's the fun part of all of this - at the end of the day, Atom is effectively just another form of RSS

It's Time to Register!

Early Registration for StS 2004 ends soon!

In just a few short weeks, beautiful Seattle, Washington will play host to Smalltalk Solutions 2004. From May 3-5, Seattle's Crowne Plaza Hotel will be known as "the place to be" for Smalltalk users, developers, and enthusiasts ... people just like you! Why not join us?

Some of the top companies in the world of Smalltalk will be exhibiting at this year's conference, including Cincom, Gemstone, Knowledge Systems Corporation, IBM, and many more. Keynote speakers will be offering insightful, dynamically charged presentations and you'll be treated to informative, in-depth, educational tutorials as well as discussions and information on future Smalltalk plans and directions.

O.K., you know about the conference, you've seen the posted agenda, and you've received information regarding our three exciting keynote speakers. All that's left to do is register!

Why not register right away? Don't forget that registering before April 3, 2004 can result in significant savings to you!

To register, please visit http://www.smalltalksolutions.com/registration/register.htm.

Hope to see you at Smalltalk Solutions 2004!

Roy Osherove lists some RSS impediments. His big ones:

• Find out what RSS means
• Find a news reader
• Download and install it
• Find sites that give out RSS feeds

He then goes on to say that the technology won't go anywhere until MS embraces it and integrates it with Outlook. I'm not that cynical. Clearly, you have to know what RSS is before you can be interested in it. There have been a number of recent articles in the trade press (and in the general press even) - so I think that one is getting easier. Download and install? Well, I can't speak for the other tools, although I'm led to believe that most are pretty easy. BottomFeeder installs easily for every supported platform except Mac OS 8/9 - I don't have a Mac, but would be able to fix that one with access to one. On other plats, Bf installation is a pretty simple deal.

The last one, finding content? Well, that can be an issue. That's why BottomFeeder ships with feed building Wizards for:

• Google
• Feedster
• BlogDigger
• Amazon
• Headline News Service
• Yahoo News Service

It also supports auto-discovery, faulting back to Syndic8.com when scanning a site doesn't turn anything up. Sure, finding authors you don't know about (yet) is hit or miss - but so is finding them via the browser. And regardless of what the rdf/semantic web folks seem to think, it'll stay that way, IMHO....

Charles Miller voices some concerns over Continuation based web frameworks. I don't know enough to have an answer, but I'm sure Avi will. Of course, this is exactly the kind of question that I'm sure Avi will address in his keynote - come to StS 2004 and hear it from the horse's mouth, so to speak :)

Scoble links to this blog post which questions the viability of technical publications. I subscribe to a lot of tech journals - and truth be told, I like the paper versions. Sure, ComputerWorld, InfoWorld (et. al.) have online versions, where all of the content resides (heck, ComputerWorld uses a quicklink scheme to make it easy to find content you are reading about). Why do I like the printed versions? It's a whole lot easier to read with my lunch, or on a plane. There are still many places where I either cannot (no connectivity) or won't (not carrying my laptop) go online. I still like to read in many of those places though. I seriously doubt that printed content will go away - but it's going to have to make accomodations - as ComputerWorld has done.

Register for StS 2004 so that you can learn all about FIT from Dave Astels. Dave is a winner of one of this this year's Jolt awards for his new book, Test-Driven Development: A Practical Guide

The FIT testing framework
tutorial (extra cost applies)
Dave Astels: AdaptionSoft
Monday 2:00:00 pm to 5:30:00 pm

Abstract: FIT is the latest gift from Ward Cunningham (who was involved in the beginnings of CRC cards, design patterns, test-driven development, Extreme Programming, wiki, and assorted other important things... and a Smalltalk master to boot). FIT was designed to write customer acceptance tests. The idea is that anyone (including testers and even end users) can use FIT to write tests for the requirements before any amount of design or programming had begun, moving testers from an afterthought to an integral part of the development process.

This is possible because FIT allows you to separate the data related to a test from the code required to load the data into the system being tested. In other words, test data can be written separately from (and in a different language than) the code. Subsequently, that data is used to exercise the system and verify its behavior.

In FIT, the test data is represented as a table. Test data can range in complexity from simple rows of input and expected results to a sequence of actions and checks for testing a user interface.

While SUnit provides a framework and tools to test at the unit level, Fit provides the same for testing at a higher level: functional, system, acceptance, etc. This tutorial is hands-on, so please bring a laptop with either VisualWorks (7.1 or 7.2) or Squeak (3.6 or later) installed. It may be helpful to contact the speaker and get a copy of the FIT software to pre-install as well.

Bio: Dave has over 20 years of experience in the software field. For over 14 years he has been using object-oriented technologies almost exclusively (including Smalltalk, C , and Java).

Dave has been studying, practicing, teaching, evangelizing, and coaching XP and Agile Processes since 1998.

Dave co-authored "A Practical Guide to eXtreme Programming" (ISBN 0-13-067482-6) and authored "A Practical Guide to Test-driven Development" (ISBN 0-13-101649-0), both with Prentice Hall. He's recently written an article of Fit for "Better Software" magazine, which appeared this spring.

Dave is a founding partner at Adaption Software, Inc.. Adaption's offers a variety of OOAD, eXtreme Programming, and Test-driven Development related services, including training, mentoring, and outsourcing.

Dave attends, and speaks at, a variety of conferences including the XP conference in Europe, JAOO, SDWest, SD Best Practices, XPAU, Smalltalk Solutions, and OOPSLA.

Dave was largely responsible for the Smalltalk port of Fit.

His favourite quote:
Question: "Why are languages like C , C#, and Java so prevalent?"
Dave Ungar: "Why do people smoke tobacco?"

See you in Seattle!

Bjarne Stroustrup discusses static and dynamic typing in an Artima interview:

In a dynamically typed language, you do an operation and basically hope the object is of the type where the operation makes some sense, otherwise you have to deal with the problem at runtime. Now, that may be a very good way to find out if your program works if you are sitting at a terminal debugging your code. There are nice quick response times, and if you do an operation that doesn't work, you find yourself in the debugger. That's fine. If you can find all the bugs, that's fine when it's just the programmer working 14but for a lot of real programs, you can't find all the bugs that way. If bugs show up when no programmer is present, then you have a problem. I've done a lot of work with programs that should run in places like telephone switches. In such environments, it's very important that unexpected things don't happen. The same is true in most embedded systems. In these environments, there's nobody who can understand what to do if a bug sends them into a debugger.

Hmm. I suppose Bjarne is unaware of the widespread usage of Erlang in those kinds of apps? I suppose further that he's unaware of Erlang's dynamic nature? Bear in mind, when he's talking about safety and static typing, he's talking about C++ - so his definition of safety is slightly at variance with mine....

The HPANA Harry Potter site has a news feed. Now even my daughter will want to run BottomFeeder :)

Bob Congdon points to this post, which explains that there are 11 different ways of shipping content along with an RSS 2.0 feed. Now you know why we aggregator developers swear, a lot :). The tragedy is, Atom won't be any simpler, regardless of what kind of fantasy thinking the designers engage in....

Register for StS 2004 and hear Bruce badger talk about his Open Skills project:

The OpenSkills Skillsbase Project
experience report
Bruce Badger: OpenSkills
Monday 4:00:00 pm to 4:45:00 pm

Abstract: The OpenSkills SkillsBase is implemented using the Swazoo HTTP server running in GemStone, all hiding behind a Squid reverse proxy. Bruce will discuss the goals of OpenSkills, and how you can help out

See you in Seattle!

I just found out that there's a new blog search site around - BlogRunner. It seems similar to Feedster, but with one important difference - Feedster offers support for ad-hoc (search) feeds (as does BlogDigger, and BlogRunner doesn't. Limits its usefullness, to my mind. Not as bad as the hokey email registration scheme that pubsub uses, but heck - you would think a service that indexes blogs would grok the importance of syndication...

One of the interesting things you can see in software (probably anywhere) is the overly developed sense of importance many developers attach to themselves and their projects. Certainly we Smalltalkers are not immune to this; we often talk about Smalltalk as if it's the second coming or something :) There's a larger thing at work here though - it's touched on in this rant from the Bile Blog - and while the commentary there is a little rough, there's a good point hidden in all that anger - we often choose the complex over the simple for reasons that have nothing to so with the actual problem. Here's an example, related to me by a friend.

This guy has recently taken a new job - same kind of work he's always done, but with a different consulting outfit. During the initial process of looking at available projects, he's talking to someone about a job that involves getting data from a database, allowing users to interact with it, and possibly updating the database - you know, the standard CRUD thing. He asks what approach they are going to take, and is told that it'll use and EJB server, a big database, and a Java client - a three tier system. This is when my friend made the mistake of asking the following:

Question: How many users will this system have?
Answer: 10 at first, maybe 20 eventually
Question: Why not just use an Access front end to the database?
Answer: Heretic!

He says that the lead developer on that project distrusts anything he says now. Stop and think about that, and about the general problem - most of the systems we build are not big. Most of them need to scale to small numbers of users, and most of them are simple CRUD systems. What do many, many developers immediately do? Over complicate them. Suddenly, it's not such a surprise that the failure rates for software development jobs are so high - we tend to over estimate the importance of projects and over complicate them

Take this blog, for instance - I've had a few people ask me what database I use, and they are often horrified when I tell them that I don't use a database. Why should I? I save the data in serialized object files, with the date of the postings encoded in the file name (one file per day). It's easy to find posts that way (the GUID is also an encoded date), and the file system serves things up pretty darn fast. I can back all the content (and infrastructure) files for all the CST blogs in less than 3 MB using a shell script. All my data is still in object form; I didn't have to worry about any impedance mismatch between Smalltalk and an RDBMS (or about db architecture issues, about which I know very little). Sometimes, simple problems only need a simple solution

I've seen the same sorts of things in many shops over the years. I recall one large development project in particular, on which I and a few other Smalltalkers consulted back in the late 90's. At its peak, there were 170 or so Smalltalkers, and nearly double that working in Cobol on a mainframe. Over lunch, a few of us determined that the entire thing could have been done with 2 dozen or fewer people, and likely in a matter of months - but that wouldn't have helped the management there build their empires. Well after I left that project, I learned that large parts of it had been outsourced. No surprise there - years of game playing and complexity adding had to be paid for at some point.

What's my point? Well, next time someone starts waxing rhapsodic over the need to use a whole set of complex technologies to solve some problem, sit back and ask yourself just how complex the problem really is, and shed any prejudices you might have about the issues of client/server development - it's really not the case that all problems require a 3 tier solution...

Danny Ayers was apparently noodling around in Smalltalk and came across the "NonBoolean receiver - proceed for truth" error. I remember when I first hit that one, many years ago - it baffled me. Even now, I usually do a double take on it :)

You can adjust the font scales globally in BottomFeeder in settings - the pane under "user interface". If you want to adjust the scale of the HTML pane only, the third toolbar button from the right (Glasses with a bi-directional red arrow) allows you to adjust the font scale just for the browser pane.

If Seaside and continuations are of interest to you, then you'll want to read the following items:

• Peter Lount's questions (no better links available; he's runing an older SmallBlog implementation)
• Avi's response
• Learning Seaside's take

It's great to see a lively technical discussion on this stuff - and the general interest that is being stirred up by it

Charles Miller defends Wiki style markup for wikis:

Sure, you end up with something that's significantly less powerful than HTML. This is a feature. A wiki page isn't a place for complicated markup, it's for writing stuff down. The more power you put in the markup language, the more people are going to be wanking around with the precise arrangement of angle-brackets that will make their paragraphs step from left-to-right in pixel-perfect harmony in lieu of saying something.

I support the same style of markup in the Comment poster in BottomFeeder, and in the client-side posting tool for this blog. I'm going to add it to the web comment form as well, for the reasons outlined by Charles. Most people - techies included - don't want to use html markup....

Georg heeg will discuss outsourcing and whether or not software development is financially feasible in the developed world - in this session at StS 2004. Register today so you can participate in this timely discussion

Is Software Development in Developed Countries still affordable?
presentation
Georg Heeg: George Heeg eK
Monday 4:00:00 pm to 4:45:00 pm

Abstract: This is political/technical talk about alternatives to outsourcing.

Bio: 50 years old, founder of Georg Heeg eK, Germany oldest Smalltalk enterprise

See you in Seattle!

One of the interesting things to me is how many people will say things like "Yes, Smalltalk is more productive, but...". The next thing you'll get is some statement about how hard it is to find Smalltalkers, or about how the syntax is wrong (what, developers can't learn a new language?). You'll get the same complaints about any niche language - Lisp, Ruby, Python, Scheme - they all get tarred with the same brush.

Heck, the major analyst groups are particularly bad about this - Gartner will admit that Smalltalk is more productive (i.e., will deliver results faster at a lower cost) - and then tell you to use Java or C#. It's always high school in the hallowed halls of Gartner, and all that matters is being close to the "popular" crowd. When you look at the data from SPR (I'm getting the actual tables from SPR; they charge for them now) - you can see hard data backing this up. The tragedy is, this is old news.

Need a more recent example of the productivity? Have a look at all the excitement surrounding continuation based web applications - and then note that none of that is happening in C# or Java (there's some in JavaScript). Why is that? Well, Java and C# - i.e., the mainstream so valued by the analysts - simply doesn't support it. If you want to have a chance of finding the next big thing, you can't find it in the mainstream. If you want a chance to find something truly innovative, you have to be willing to look elsewhere....

I upgraded to Eudora 6 awhile back, and I've been mostly happy with it. The spam filtering seemed mostly good as well, until recently - when I started noticing that scads of good mail was being junked. I spent the last week or so fishing things out of the junk folder, until it finally dawned on me that maybe there were settings for this. Lo and behold, there is.

It turns out that Eudora assigns a "spam ranking" to each incoming mail - a number between 0 and 100. There's an option to set the minimum ranking before having something get junked, and that was unset. I'm hoping that setting that will result in fewer lost messages.