Smalltalk Tidbits, Industry Rants

I was looking over my feed update this morning when I came across this item from the Loosely Coupled blog. It seems that Oracle has put Do it yourself portal capabilities in their latest release, and this has some of the control freak types upset:

The launch this week of DIY portal capabilities for Oracle's application server platform has not been welcomed in all quarters. According to Forrester analyst Nate Root, quoted in Internet Week, "Portal development isn't a business-user function. IT doesn't want it to be a business-user function ... The way to break the development bottleneck is to give IT better tools, not try to circumvent IT."

In my experience, the typical IT group wouldn't know a business function if it walked up and bit it on the nose. There was an encouraging thing in this for me; it showed me that I'm not the only business user who sees the words value and IT Group put together in a sentence and starts snorting whatever beverage he has at hand...

Richard Gabriel, author of Worse is Better, gave a talk last November title "Objects have Failed". The talk may be found here. I find this narrative interesting:

Objects, as envisioned by the designers of languages like Smalltalk and Actor - long before C++ and Java came around - were for modeling and building complex, dynamic worlds. Programming environments for languages like Smalltalk were written in those languages and were extensible by developers. Because the philosophy of dynamic change was part of the post-Simula OO worldview, languages and environments of that era were highly dynamic. But with C++ and Java, the dynamic thinking fostered by object-oriented languages was nearly fatally assaulted by the theology of static thinking inherited from our mathematical heritage and the assumptions built into our views of computing by Charles Babbage whose factory-building worldview was dominated by omniscience and omnipotence. And as a result we find that object-oriented languages have succumb to static thinkers who worship perfect planning over runtime adaptability, early decisions over late ones, and the wisdom of compilers over the cleverness of failure detection and repair

Now the ironic part: Richard Gabriel, distinguished engineer at SUN. I find this fascinating. The quote above effectively states that things like Java are part of the problem. And there he is, at Sun.

BottomFeeder has updated documentation, thanks to Rich Demers. Just pull down the Help>Users Guide menu item, and you'll browse the latest. Thanks to Rich for a great job!

But I am still baffled on my efforts to upgrade the server. Something in my new codebase blows up on the server, but works fine on my testbed. Sigh...

Interesting article on the O'Reilly site - Timothy Appnel writes that RSS is more than a syndication format - and is being used as a proto-web service. If you follow the early users of RSS, you'll see that - Pingback and Trackback are effectively web services enabling backtracking. Various blog tools support updates via other RSS features. Here's what Timothy writes:

DJ Adams writes: It seems that beyond carrying syndication information, RSS is a very useful and flexible way to get all sorts of application data pushed to a user over time. In the same way that a web browser is a universal canvas upon which limitless services and information can be painted, so (in an albeit much smaller way) an RSS reader/aggregator might also find its place as an inbox for time-related delivery of all sorts of information.

Amen DJ! As I asserted in a previous weblog post, Web Services We'd Like To See, I wrote Whether it is just assumed or simply overlooked, RSS is the most widely deployed Web service across the Internet. Granted, most RSS feeds have very simple interfaces with almost as simple backends that are unlike the Web services that usually come to mind. (Who says Web services need to be complex or sophisticated anyhow?) Under the principles of the REST architectural style that the Web was built on, RSS feeds do qualify. Consider that any site search engine becomes a Web service if it could emit results in RSS and the format's potential in the realm of Web services becomes more apparent. It is this perceived potential that I've been an advocate of getting the RSS format's house in order.

I can vouch for the value. I started monkeying around with RSS at the end of the summer, and Dave Murphy joined in and wrote the user interface for BottomFeed. Over the next few months, our engineering group added RSS feeds for our bug tracking tool (2 - one for all AR activity, and one for newly closed items). We added feeds for our source code databases. I added a feed for our public wiki and for this blog. I can see further possibilities as well; a nice, easier to use client interface to some of the cruftier web based tools out there, for instance. In any case, go read the whole article

I published the XML-RPC code that I got from Roger Whitney into the public store this evening. This is the code I used to get Pingback (which uses XML-RPC) working with the blog. This version was Wave (not Web Toolkit) based, and also came from VW 3 - so it does not use the stock VW XML parser. The code could use a port to the features of VW 7, but these initial hacks got me going.

I posted on RSS yesterday - and Steve Waring linked to it here. Today, I started catching up on the news in my feedlist when I came across this post from Mark Pilgrim:

As I said in last month's article, RSS is an XML-based format for syndicating news and news-like sites. XML was chosen, among other reasons, to make it easier to parse with off-the-shelf XML tools. Unfortunately in the past few years, as RSS has gained popularity, the quality of RSS feeds has dropped. There are now dozens of versions of hundreds of tools producing RSS feeds. Many have bugs. Few build RSS feeds using XML libraries; most treat it as text, by piecing the feed together with string concatenation, maybe (or maybe not) applying a few manually coded escaping rules, and hoping for the best. On average, at any given time, about 10% of all RSS feeds are not well-formed XML. Some errors are systemic, due to bugs in publishing software. It took Movable Type a year to properly escape ampersands and entities, and most users are still using old versions or new versions with old buggy templates. Other errors are transient, due to rough edges in authored content that the publishing tools are unable or unwilling to fix on the fly. As I write this, the Scripting News site's RSS has an illegal high-bit character, a curly apostrophe. Probably just a cut-and-paste error -- I've done the same thing myself many times -- but I don't know of any publishing tool that corrects it on the fly, and that one bad character is enough to trip up any XML parser

I can certainly feel for this problem. With BottomFeeder, we have had to catch lots of complaints from the VW XML Parser. We generally let them go by and continue on - because if we just rejected the feeds when they were invalid, there are precious few feeds that we would support. Marks goes on a bit further down:

There is a social solution to this problem: register at Syndic8.com to be a "fixer", and volunteer your time contacting the authors of individual sites to get them to fix their feeds. There is also a technical solution to this problem: don't use an XML parser. I know, I know, this is heresy. The point of XML is that content producers are supposed to put up with the pain of XML formatting rules so that content consumers can do cool things with off-the-shelf tools. Well, guess what? It's not happening. Judging by the sad state of affairs in the RSS world, content producers are either ignorant of the error of their ways, or too lazy to fix the errors, or too busy, or locked into inflexible tools whose vendors are too busy... Whatever the reasons, content consumers are rarely in a position to solve the problem. So we must work around it. We need a parse-at-all-costs RSS parser.

It's an interesting article with some controversial ideas. I think Mark's right though - we are headed down the road to heck, where we will end up with tools that deal with just about anything that stumbles by calling itself RSS - not unlike the current HTML mess...

This is amazing to me.

THE classic Beatles' Abbey Road album cover showing the band on a zebra crossing has been altered - to remove the cigarette in Paul McCartney's hand. The original image shows a barefoot Macca third in line holding his ciggie. The 1969 photo has been a poster best-seller since it was shot near Abbey Road studios in North London, where the Fab Four recorded most of their music. But companies including US giant Allposters asked for the cigarette to be removed by computer wizardry to make it more politically correct.

Wow.

I spotted this item via Gordon's log.

The trouble with XP is that its just the type of dogma that appeals to jerkoffs. And hence they want to letter of the law everything to the point where it has no meaning while violating its spirit. I think peer-programming is Awesome provided I get my "me" time and I find someone who's working style complements me. (which is my nice way of saying, "cold day in hell: ;-)) I've peer-programmed remotely quite successfully.

The post is actually not anti-XP - it makes some good points. I agree with Gordon:

That's the trouble with any methodology, I don't think it's a problem unique to XP.

I've also paired remotely - with BottomFeeder , we've used an IRC channel to communicate.

Catching up on my feeds this afternoon, I stumbled on this. Good thing I wasn't having a beverage:

SBC Communications Inc is enforcing a patent it owns that, it claims, covers the use of frame-like user interfaces in web sites, it emerged this week Kevin Murphy writes. . If your web site uses a frames or a persistent user interface, then you could be in infringement. Using SBC's interpretation of its patent, hundreds of thousands of web sites, including those of many SBC's own hosting customers, many of the web's biggest sites, and the United States Patent and Trademark Office itself, could be in infringement.

This is just insane. What next, books? Get the whole story from the Register

I've posted before on why I think Sun has problems. Here comes another story on that subject:

NEW YORK--Dell Computer has switched 14 of its internal servers from Sun Microsystems machines to its own systems running Linux and a new version of Oracle's database software, Chief Information Officer Randy Mott said Thursday. The new systems, which spread the database across a "cluster" of interconnected lower-end machines instead of using a single more powerful system, cost less and work faster, Mott said in a keynote address at the LinuxWorld Conference and Expo in New York.

That's got to hurt

Or, Why Java sucks for XP Go visit this Sun page. After I picked myself back up (ROTFL), I grabbed this text:

Suppose that you want to add some functionality to StockWatcher. For instance, suppose that you want to add a method that reports the current stock price, regardless of whether the value changed:

 
public interface StockWatcher {
    final String sunTicker = "SUNW";
    final String oracleTicker = "ORCL";
    final String ciscoTicker = "CSCO";
    
    void valueChanged(String tickerSymbol, double newValue); 
    void currentValue(String tickerSymbol, double newValue); 
}

However, if you make this change, all classes that implement the old StockWatcher interface will break because they dont implement the interface anymore! Programmers relying on this interface will protest loudly. Try to anticipate all uses for your interface up front and specify it completely from the beginning. Given that this is often impossible, you may need either to create more interfaces later or to break your customers code. For example, you could create a StockWatcher subinterface called StockTracker that declared the new method:

public interface StockTracker extends StockWatcher {
    void currentValue(String tickerSymbol, double newValue);
}

Now users of your code can choose to upgrade to the new interface or to stick with the old interface

Read that again: Try to anticipate all uses for your interface up front and specify it completely from the beginning. Given that this is often impossible, you may need either to create more interfaces later or to break your customers code So, YAGNI isn't possible, and using Java interfaces demands that you over-build up front. Bah.

David Buck pointed me to a thread on slashdot. I had noticed, but I rarely delve that deeply into the slashdot threads. Dave points out two interesting replies: From the "Java is great (but they don't realize Smalltalk does it better)" camp and From the "They just don't get it" camp For instance:

no stack objects; I don't know the internals of the stack management and the complexity of C++, but since C++ managed it, why not Java ? why should I have to create an object on the heap just to use it locally ?

As Russ Pencin used to say in Smalltalk classes, Why do you care? or this:

I don't know why the garbage collection is such an advantage. In the place that I work we have written apps with milions of lines of code using C++ and we never had a problem with memory leaks. Of course, being military and scientific apps, there was a good design before coding, so we had a pretty good knowledge of when to allocate/free stuff. But it is not hard to make C++ objects garbage-collected. All that is needed is a base class that upon its construction puts the object in a global list and a template pointer that increases/decreases automatically the reference counter of the garbage-collected object when assigned to it; later, the list will be traversed and objects with no reference will be deleted.

Chuckle. Either he's effectively written his own GC system and doesn't realize the sunken investment, or he's just clueless. Then there's this:

For the second point, I don't like either interpreted or byte-code languages with virtual machines. I think they are a waste of CPU time and resources. I am 100% certain that there is no point in having static Java apps executed by a virtual machine: they are very slow, even with top-of-the-range Pentiums. And when we say slow, we mean slow enough for an experienced user to handle: for example, I have personal experience of a versioning and control application that we use at work which is very slow, although it runs on a P4 at 1.8 GHz. It may not be slow, but it definitely feels slow.

That's right, one badly written app condemns an entire paradigm. Why doesn't he write machine code?

I posted a new DEV Build - there was a bug that prevented look policies from being restored at startup.

I posted yesterday on this, and this morning this pops up in my feed list from Linux Today:

In the short term, Linux is mainly a threat to companies that make computers based on variations of the Unix operating system, the dominant system driving corporate mainframes and servers. But the company that could eventually find itself in the line of fire is Microsoft, whose position in the computing industry rests heavily on its Windows family of operating systems. "We see Linux going over the moon," says Larry Ellison, chairman and chief executive officer of Oracle. "We have never seen anything with this much of an uptake in 25 years in the industry..."

Now I don't necessarily take Ellison as an authoritative source - after all, he was sure that network computers were going to overtake Windows. Still, the signs don't look good for the Unix vendors. Especially since IBM is on the Linux bandwagon...

Rich Demers has found a few more bugs, and made some more suggestions. A new DEV Build is up.

This is why we don't use SQL Server for the Cincom Smalltalk server.

"Since about midnight EST almost every host on the internet has been receiving a 376 byte UDP payload on port ms-sql-m (1434) from a random infected server. Reports of some hosts receiving 10 per minute or more. internetpulse.net is reporting UUNet and Internap are being hit very hard. This is the cause of major connectivity problems being experienced worldwide. It is believed this worm leverages a vulnerability published in June 2002. Several core routers have taken to blocking port 1434 outright. If you run Microsoft SQL Server, make sure the public internet can't access it. If you manage a gateway, consider dropping UDP packets sent to port 1434." bani adds "This has effectively disabled 5 of the 13 root nameservers."

Sooner or later, some attack is going to take down a critical mass of those root servers, and no one will be able to see anything.

I posted this morning on the worm that was apparently slowing net traffic; there's also a CNN Story on it. If you point your browser here, you can see what purports to be a "health" meter for the internet, showing a distinct problem this morning. I found all this refs here. As I said this morning, I doubt things are going to get better in this regard anytime soon.

It is often the case that applications - be they client applications, or server applications - need to make network connections via standard internet protocols. VisualWorks supports a wide variety of such protocols, including HTTP and HTTPS. It's becoming more and more common for applications to expose what some call REST (REpresentational State Transfer) as a way of opening up some of their internal API's to the world.

What, do you ask is REST? Simply put, it's an HTTP based interface to an application. While that sounds complicated, it's not. For instance - searching my web log for information on REST could take the form of this HTTP based query:

http://www.cincomsmalltalk.com/blog/blogView?search=REST&searchTitle=true&searchText=false. The interesting thing is, the results of a query like this need not be parsed solely by a web browser - they can be parsed by an application that doesn't even expose the results directly to the end user. Now, this is a simple example - the query above is a GET, and the results come back in the HTML body as text. What if you have a more complex interface?

Using my weblog again as an example, let's look at exposing POST interfaces. In the weblog and RSS world, there's growing interest in being able to trace posts, comments, and related posts on other web logs. Two examples of this are Trackback and Pingback. Both are interfaces that accept HTTP POSTS from clients. Handling those in a VisualWorks server is easy; you just create a servlet, a post handler, and grab the form elements. But what about the client end?

In the RSS/Web log world, a web log should not only be able to receive these notifications, but be able to send them. How do you create a POST in code? Very easily, as it turns out. Using the NetClients libraries, here's an example of creating and sending a trackback POST:

doPostTBFor: tbToSendUrl from: entry
	| client content |
	client := HttpClient new.
	content := self postTBFor: tbToSendUrl from: entry.
	request := HttpRequest method: 'POST' url: tbToSendUrl.
	request referer: entry getPermaUrl.
	request contents: content.
	request contentType: 'application/x-www-form-urlencoded'.
	^[client executeRequest: request] on: self httpExceptions
		do: [:ex | ex return].

In this example, #postTBFor:from: looks like this:

postTBFor: baseUrl from: entry
	| stream settings excerptLength myUrl |
	stream := WriteStream on: (String new: 500).
	settings := BlogSaver default settings.
	excerptLength := entry blogText size min: settings excerptLength.
	stream nextPutAll: 'title=', (entry getHTMLEncodingFor: entry title).
	myUrl := settings mainLink, '?entry=', entry timestamp asSeconds printString, '&showComments=true'.
	stream nextPutAll: '&url=', myUrl.
	stream nextPutAll: '&excerpt=', (entry getHTMLEncodingFor: (entry blogText copyFrom: 1 to: excerptLength)).
	stream nextPutAll: '&blog_name=', (entry getHTMLEncodingFor: settings blogName).
	^stream contents

What I've done here is created a POST object, set the type to 'application/x-www-form-urlencoded' - which will allow the remote end to interpret it as a form being posted - and then placed the URL-Encoded form data in as the contents. That's the second method. Note that the code is simple streaming; I just create the URL-Encoded data manually. If this is something you need to do a lot of, you could pretty easily add convenience protocol to automate this.

In any case, using the above two methods, my web log sends trackbacks and pingbacks whenever I refer to an enabled site in a post. It's all pretty simple - a few lines of simple Smalltalk code, and you have an interface into any site on the web!

I posted on some issues in RSS the other day. It's been a widely discussed topic; I saw this just now on Reflective Surface.

But there are still some problems. Obviously, not all tool developers care about generating well-formed feeds. Some even have a history of providing feeds that are almost garbage, if feeds are provided at all. That's the problem I see with any solution other than parsing at all costs: it may be harder to convince some providers to create tools that generate correct XML than write liberal parsers. And even if those developers could be convinced, there are still large amounts of deployed tools that won't be upgraded and will continue to generate invalid feeds. I don't like this situation. As Dare Obasanjo said, it's quite depressing. XML was supposed to bring a new age to information processing. But real life is always different, and now we must deal with those problems in a way users can benefit. After all, there is no point in creating technology that cannot add value to people lives.

So it is back to the future, just like the wild world of HTML - wild variations and client front ends that have to handle just about any darn thing that comes their way.

This post on Sam Ruby's blog, and this one on Ken Coar's blog got me thinking. Are there any bloggers in the greater Washington DC/Baltimore area interested in a similar get together?

If you don't read Joel on Software, then go and read this now. It's an amazing series of bad events...

THis idea of RSS as The Web Service we have Now seems to be common. I posted on this a few days ago, and yesterday I made some additional comments. Now I've just spotted Matt Croyden's Blog, and he's been making the same kind of noises:

Jeremy Allaire notes that there have been over 10,000 sightings of RSS Web Services spotted in the wild:

As I've been reading and writing today I've come to a somewhat obvious conclusion: there's been an explosion of 'web services' in the past year, and it has nothing to do with SOAP, WSDL and such standards as described in the industry but with the ascending role of RSS and RDF as XML data and syndication formats.

Jeremy has a point. Another interesting tidbit from his post:

Today's count of RSS feeds from Syndic8.com: 10408 feeds Today's count of SOAP APIs from xMethods.com: 275 APIs

That's a huge difference.

Infoworld has a big story this week on packaged applications and their hidden costs.

A NOSTRUM of the late '90s was to dump internally developed, custom applications in favor of packaged applications. But the hidden costs of those packaged apps are coming back to haunt many companies that implemented them too hastily. The motivation behind that lurching, tectonic shift was the horror generated by over-budget attempts to build systems internally. An entire generation of in-house programmers was pulled from projects and thrown at ERP and CRM systems -- or out the door -- because executives believed that packaged apps would fix the problem of hidden costs. "Companies that had been building their own software for 40 years started thinking maybe they didn't need all those people, and that was a sign of something bigger: a crisis of confidence," says Tom DeMarco, a Camden, Maine-based principal at Atlantic Systems Guild and co-author of Peopleware. DeMarco thinks the rush to packaged software was accelerated by organizations losing confidence in their ability to invest wisely in IT and the creeping belief that original works of code were merely a cost, not an investment. But the hidden-costs problem didn't go away with the adoption of packaged apps, which can hide even more expenses.

That's an understatement. Very few companies take packaged applications as-is. Instead, they customize. This has two problems:

1. The application is now forked from your vendor's version, making upgrades harder
2. The application wasn't necessarily written with the kinds of customizations you had in mind

I see this at Cincom - we have an internal bug tracking system that is a heavily customized version of (an external vendor's software) product. We are now 2 or 3 versions out of date, because our internal staff could not upgrade the product and the customizations in synch with the vendor. The vendor can't support our version with normal support, since it's so heavily customized. So we spend precious dollars on support of an out of date application. I'm not beinging this up to embarass our IT group; it's hardly a unique problem. My point is that, in general, packaged applications end up being at least as much trouble to maintain and upgrade as custom ones. While you may become dependent on a particular version of a development tool or set of libraries, upgrading - given source - is typically a resource issue. With a packaged application, you likely don't have source, and API's you depend on could disappear. You can end up just as far down the river. Basically, TANSTAAFL. Here's another interesting snippet from the article:

"If companies were feeling defeated by custom software, then packaged software has proven an even greater defeat. The fiasco with Oracle last year indicates that even upgrading a package isn't affordable," DeMarco adds, referring to the snarled application-migration problems last August that purportedly cost Agilent more than $100 million.

Read the whole article - it's thought stimulating.

Infoworld has a thought provoking story on outsourcing. The conventional wisdom seems to be that 40% or more of IT jobs could be outsourced by 2005:

AS MANY AS 35 percent to 45 percent of U.S. and Canadian IT workers will find themselves replaced by contractors, consultants, offshore technicians and part-time workers by 2005, according to a report issued this week by New Canaan, Conn. based Foote Partners. And though some analysts and IT labor experts said those figures, while eye-popping, may not be far-fetched, four high-level IT managers said the predictions probably won't apply to their companies. For them, outsourcing hasn't proved to be a lower-cost alternative to keeping IT inside corporate walls. "While there are times where I'd love to throw something to the outsourced den, so far we've found that it wouldn't be cost-effective for us," said Amy Courter, vice president of IT at Valassis Communications Inc., a Livonia, Mich. based marketing services firm. "We do everything in-house," said John Studdard, senior vice president and chief technology officer at Lydian Trust Co. in Palm Beach Gardens, Fla. "The reason we've been successful in light of 9/11 and the economy and the bursting of the dot-com bubble is that we're in control of our own destiny and not locked into long-term contracts that may or may not be relative to our business anymore."

I can state pretty unequivocally from my experience (see my ReplayTV support saga that outsourced level one support is a fine way to irk customers - they get to deal with distant support people who are empowered to do nothing except follow a tightly controlled script. Still, it looks a lot like application development could be going the same way manufacturing went 20 and 30 years ago:

Nevertheless, David Foote, president and chief research officer at Foote Partners and a Computerworld columnist, said American companies "can't afford to do application development in the U.S. anymore. The nature of the business has changed." Foote said he based his estimates on surveys his company conducted last year with 1,880 private-sector and government employers, which were asked what percentage of their future IT workforces will be in-house vs. external.

Discouraging though that sounds, I expect the effort to be tried. I also expect that it won't go nearly as well. Software development is not nearly as well understood a field as is manufacturing - in most respects, an assembly line doesn't care where it's located. Software development is different - it's a communications heavy field, and I question the ability of development staffs 12 hours (in time zone) away to adequately communicate with the end users. Agile Development and XP are a response to the seeming inability of local development groups to communicate well; somehow I doubt that adding language and time barriers will improve that.

I had a nasty layout issue with the blog that Roger Whitney pointed out to me. After some investigation, I found out that the code I was using to place trackback, pingback, and comment links was just atrocious. I fixed that and patched the server, and the presentation should be back to normal now. Thanks Roger!

The intelligent folks at my local WB station had a sports event earlier today - a college hoops game. Ok, I set up the Replay to record Angel long in case the show got started late. The bozos at WB ran the show 1/2 hour early. Early!??? What's up with that? It's bad enough that the college basketball season bounces the show from one day to the next - but now I can't make any kind of educated guess at all as to the airtime. Sheesh.

Victor Goldberg pointed me to a meeting of the Washington (DC) Object Oriented Architecture and Design Group this week:

WOAD 1/28 - Java Impossible : What can't be done with Java and how to do it anyway RSVP quickly to reserve a seat. Space WILL be limited to those who RSVP. WHAT: WOAD (Washington Object-Oriented Architecture and Design) WHEN: Tuesday, Jan 28th, 2002 at 7:00 PM WHERE: Best Western of Rockville (in the Restaurant) DINNER: Buffet $12.50 (includes tax $ tip - to get the space, we have to eat) TOPIC: Java Impossible SPEAKER: Michael Trachtman Already excited about a talk on "Java Impossible"! Or are you wondering why in the world WOAD is doing a bits and bytes language talk? Even if you don't code, if you design, architect or manage anything in the Java or J2EE space, you need to know what can and can't be done. This will be fun and given WOAD, controversial. Michael will present prepared challenges with solutions and invite new challenges. Some of the topics that Michael will discuss include how to create a distinction between "public" and "published". We'll also discuss how to make a simple general mechanism for creating light weight transactions in Java, and show their use in enforcing Design By Contract and Componentization in Java. For new challenges, bring your toughest problems, give them to Michael and build toward a solution. We'll welcome challenges from Java gurus and .Net folks alike. Challenges with solutions are of course especially welcome. The only restriction is that the challenges should useful.

Well. I have one, and I've been discussing others on the IRC Channel. My first question: I have a web log where the daily entries are stored as serialized object files (to disk). I need to add attributes to the objects that are serialized to disk. At the same time, I need to

1. Make the change to the running server - i.e., Not take the server down
2. Not modify any of the existing serialized object files as part of the change

In VisualWorks, I have actually done this - the files are BOSS files, and you can add code to any object that allows for schema migration of existing objects. I last did this when I added pingback and trackback support to the blog - and most of the data files are still in the older format, as they haven't been resaved in the newer format. I'll be curious to see how a Java solution to that works out.

Picked this thought up today.

But there is one SQL Server box that I almost forgot about: my laptop. I tend to connect to all sorts of foreign networks with my laptop. Had I done so with an unpatched SQL Server running on my laptop, I would have brought the Slammer worm back home behind my ISA server firewall. Then all hell would have broken loose. So the lesson here is: beware of laptops. They can easily subvert the security provided by your network's perimeter defenses. And make sure you patch ALL SQL servers regardless of whether they are behind your firewall or not!

Yeah, I run mine all over too. I should be more careful....

I've seen this idea in cls recently, and now in this article on O'Reilley: Prototype in (Smalltalk, Python), then build in Java.

I like programming problems where you think, "There has to be something really interesting over there, but I can't see it clearly." All you can do is move one step over there, with a small bit of code, and start exploring to see it more clearly. And maybe it actually wasn't there, it was over here. Or it had a different shape than you thought initially. Maybe it wasn't interesting at all, and you didn't waste a lot of time. The danger of planning is that you plan for the contingencies you know about, but by definition you don't plan for things you don't know you'll encounter. So when you do encounter an unexpected event in your programming endeavor, you have to fix many interfaces and change multiple method signatures. If you've already committed to your original plan and that's no longer where you're going, then you have a problem. I'm not particularly worried by the fact that people say you can prototype more easily in Python, but eventually the Java version makes it easier to build a robust large system. You can prototype in Python. Once you've explored the space more, you can do the planning and design that the Java version requires. If you start writing in Java knowing as little as you did when you started writing the Python version, you'll waste way more time exploring than actually building the system you'll eventually build.

Here's a hot tip - just build the system in Smalltalk or Python. If you skip the (unproductive) porting step, how much further along would you be?

I spent some time this morning fighting HTML tables...... After I pulled out what little hair I have left, I got rid of the table I was using for the main view (the entries). I now just have the links and blogroll at the bottom, and a link to it (and back from it). This should make the display cleaner in most browsers....

Would do well to read this article on VHS vs. Betamax.

VHS won because "the whole product" did what people wanted at a price they were willing to pay. And when people use the VHS vs. Beta analogy, they are not indicating a market failure but their own ignorance.

Definitely worth pondering

Looks like Microsoft doesn't always take its own medicine:

Microsoft's policy of relying on software patches to fix major security flaws was questioned Monday after a series of internal e-mails revealed that the software giant's own network wasn't immune from a worm that struck the Internet last weekend. The messages seen by CNET News.com portray a company struggling with a massive infection by the SQL Slammer worm, which inundated many corporate networks Saturday with steady streams of data that downed Internet connections and clogged bandwidth. "All apps and services are potentially affected and performance is sporadic at best," Mike Carlson, director of data center operations for Microsoft's Information Technology Group, stated in an e-mail sent at 8:04 a.m. PST Saturday to other members of Microsoft's operations groups. "The network is essentially flooded with traffic, making it difficult to gather details concerning the impact."

Well, there's some rich irony for you. The exploited flaw is a year old - and even MS' internal IT group had not patched the various SQL Server db's they run. Oops.

I saw this interesting post, which I'm extracting in its entirety:

Cameron Purdy wrote,

So I saw this interesting blog entry. The interesting thing with .NET is that you can actually run the JVM inside the .NET process and use a product like JNBridge to semi-transparently access the one from the other. The best of the Java world easily available in .NET, sans the web services overhead. Could that mean software-level peer-to-peer clustering for .NET? (Heh.) Stay tuned.

It goes the other way, too. The CLR can be hosted from a process started by the Java bootstrapper, just as well. For example, I've got some JNI code called from a webapp that loads the CLR and calls into the ASP.NET runtime. At this point, all I'd need to do is (a) build the appropriate HttpRequest class in .NET that knows how to extract the HTTP request data from the servlet HttpServletRequest and HttpServletResponse objects (as well as a few associated others), and (b) set up the webapp to map .aspx, .ashx, .asmx and a few other extension types to a servlet that does this call-transition, and lo and behold, we have ASP.NET running behind a Tomcat front-end. Depending on how the bindings take shape, you could conceivably have shared session state between both environments, all running in-process. The fact that both environments have a well-documented interface for hosting their respective managed environments and that both environments run entirely in-process is what makes this possible. (About the only thing left, then, is to bind in the Python runtime and we've got just about every language in use today covered. Of course, that process will consume about 100,000 megs of physical memory, but hey, memory's cheap, right? :-) )

So that gets me thinking.... What about from VisualWorks? I take the above stuff as glossing over the difficulties and making it sound too easy, but still....

This is interesting - Jupiter Research has some of their analysts blogging now. If this is a trend, it's likely a good one - the more feedback people looking at the industry get, the better. I think Jupiter is doing the right thing here!

I guess I'm going to give a talk on the Web log at Smalltalk Solutions. This whole blog started as a way for me to express opinions and rant in public ;-) Over time, it got a lot more complex than that - the whole web log could be taken as an exercise in scope creep - the addition of an RSS Feed, comments, a comment RSS Feed, support for Trackback and Pingback - it's gotten a lot like normal projects. Next up, I'll have to go fill out the abstract....

I drove down to Rockville for the WOAD meeting, where the speaker was giving a talk on things that are "impossible" in Java - and for which he was going to show solutions. First problem: He wanted to show how to emulate the C++ friend feature. This was somewhat amusing to me - here's a language with all these levels of call security, and the first thing we talk about is how to get around it. Anyhow - the solution involved creating an exception object, peering up the stack, taking the name of the calling method's package as a string argument, and then checking whether the calling package was allowed to call in. It was a page of complex code. As opposed to, say, thisContext in VisualWorks. With which one could create arbitray call leve security.... Ok, then we went on to Design by Contract. What he wanted here was to be able to create an object, and ensure that the object created was valid - i.e., that the object is in a valid state after the multi-part constructor was called. This involved the creation of a lightweight transaction framework. The transaction framework involved caching a copy of the object for rollback, and custom copying code. As opposed to, say - block closures, ensure: and become:. The solution wandered along for 8 pages, most of it code. I was kind of stunned, actually. This is how Java developers look to solve these problems? Last, he brought up a lock question - a desire to have what amounts to a timed semaphore. I've seen such creations in Smalltalk. His assertion was that it's not possible in Java. At the end of all this, it just seemed like everything in Java took so much work. The interesting thing was, lots of the people I spoke to are using Java at work, but actually interested in Python, or Ruby, or Zope. I handed out a number of NC CD's. I got the distinct impression that this group uses Java, but has no great love of it....

First there was the town for sale. Now, ebay is selling an IT staff:

Complete staff of ZDNet Tech Update, formerly a vital division of one of the top ten highest-trafficked sites on the Web, currently available to instantly implement professional Web site or print magazine. (...) Resumes available to highest bidder. Bidders should be prepared to make a total annual commitment for salary and benefits in the high six figures. Sellers will also consider contract work. Please e-mail any questions before bidding.

Whoa. I'm waiting for the first country to be sold on ebay. Picked up via Reflective Surface

Looks like my Linux Replacing Unix theory is getting traction. During Linux World, IBM announced that Unilever was adopting Linux. Unilever has been and HPUX and AIX shop, according to ComputerWorld (who did not provide an electronic version of their cover story...). Looks like the Unix vendors are shifting to Linux - HP and IBM figured this out awhile ago. Sun has a different problem, since the bulk of their revenue comes from their proprietary hardware - and IMHO, there are fewer and fewer reasons to consider buying Sparc and Solaris instead of intel and Linux. It's going to be an interesting next couple of years for them.

From Travis Griggs via the Smalltalk IRC:

Three types for the Lispy-things up there so high. Seven for the Fortran in their days bygone. Nine for the Algol ones, doomed to try. Just One Type for the Code Lord all alone, in the land of Smalltalk where the messages fly.

One Type to rule them all, One Type to find them, One Type to bring them all and so enlightened bind them.

Sun says here that Java's survival depends on the injunction forcing MS to ship Java:

In a court filing, Sun Microsystems claims that a federal judge's order to include its Java programming language in Microsoft's is imperative to prevent Java from extinction.

It's nice to see Sun taking responsibility for their own success instead of gaming the court system. Oh, wait....

Maybe I'm the last person to notice this, but the Google Toolbar is pretty cool! Steve Waring referenced it on his blog, and it's a neat thing to have installed. Highly recommended.

How many of us have seen large projects crash and burn? How many have seen them turn into Death Marches? I would guess that most of us have. Dewayne Mikkelson writes about this on his weblog:

This is really frustrating. True, but frustrating. I've got alot of thoughts about why this is true. Most of them break down when I start trying to draw parallels to very large construction and other engineering projects (avionics, etc.) Perhaps the fundamentally abstract nature of what we're doing removes the ability to "rely" on lower level component results. (i.e. when a die is milled you can test whether its shape, size, and material strengths are within acceptable tolerances.) Is there even an analog in software? Are there just unknowns at even the smallest component level that "prevent" us from architecting aggregate systems without exponentially reducing reliability? Are these issues Architectural? Design? or do they have to do with the nuts & bolts code-monkey work? Of course it's at the very least a combination of the three. But it SHOULD be possible to design reliability criteria that we can blast a component with and see if it holds up.

IIRC, This is the exact problem that Agile Methods and XP are solving. Write Unit tests, all the time, every time. Make sure that the bar is green, all the time, every time. Too many of us (myself included) simply don't do this. We then have constant small problems on our own projects. These become large problems on medium sized projects, and become absolute killers on large projects. This is where, IMNSO, death marches come from - problems crop up all the time, and it takes huge amounts of extra work to crawl past the problems.

Travis Griggs came up with a fascinating summary of the inherent problems with reliance on comments:

In reality, I'm not so much against the idea of class extension comments, as the percolating push to "comment more". Comments lie. Code doesn't. Good comments are really helpful, and usually very hard to find amongst all the others. I haven't noticed that encouraing programmers to use more hooks to comment stuff improves the situation.

That's brilliant, actually - Comments lie. Code doesn't

This morning I pointed out an odd ebay sale. Now the Register is reporting that it's been pulled - and that it might have been a hoax:

A spokesperson for Ebay told us that the listing fell foul of a technicality. "We do advertise professional services," he told us. "But the reason we removed it was that it contained wording that made it appear that there was a price to be determined. It appeared that winning bidder would have to determine what the individual would be paid." Gallows humor from insiders, or a prank? The debt-laden tech behemoth, which had run up $2.4 billion in accumulated deficits last fall, employs 1,500 staff and laid off five per cent of its workers a fortnight ago.

It was amusing while it lasted...