Junfeng Zhang

Junfeng probably isn't going to win any prizes in literature, but his blog is just chock full of useful tech tips. The nitty gritty stuff that isn't documented (much).

And he's quite the friendly chap. For that, he makes my blogroll.

Java vs. C# vs. C++

Arno posted a little duelling performance test for a sudoku solver here. He has snobbily disabled comments on his blog (you hear me, Arno?) :)

So in hopes that he gets a trackback, I'd be really interested to see how much of a difference .Net 2.0 would make to his performance numbers, as well as java 1.5 and 1.6 (or against BEA's JDK).

And also see how much more g++ might be able to squeeze out of his code if it were thoroughly twiddled for optimizations.

I really need to hunt down the post I read long ago that argued that most application development these days is IO bound, and not processor bound, and that chasing these milliseconds doesn't really help us much. This is largely the argument made in defense of interpreted languages like Python, Ruby, and Perl. Your language choice doesn't change your bandwidth, your network latency, or the speed of your hard drives.

Perl is an unfortunate crime of history. But Python and Ruby are moving in directions we need to pay attention to. Need to break out Iron Python and see how I like it.

Of course, Arno posted his code and I could run it under those platforms, and even for fun port it to Python and Ruby (I need to get a little Ruby under my belt just to see what all the noise is about.)

At some point I'll blog my thoughts about the difficulties of a multi-language environment when you're developing with a team. Sometimes the best tool isn't the best tool when you're the only guy that knows it. And apparently I'm in a significant, but not majority subset of developers that think it's fun to learn new languages and get them to play nice with each other.

W00t! GPL Java!

With most (all?) of the "scary" viral components rendered non-issues for the average developer. And non-GPL'd versions will remain available to those still frightened off by the whole thing. (Sun retains the copyright/left, so is free to license it under multiple licensing models.)

The semi-official announcement is here.

I imagine this means that for Sun to accept contributions into their tree, you have to surrender the copyright to your contribution. Somebody correct me on that.

Java has really benefited from the competition .Net brought to the game, and it's better off for it. There's been a lot more velocity in Java in the last five years. And this will just kick in the afterburners.

New Toy! Script#

Looks like a really clean concept. I won't talk out of my butt about it, because I haven't played with it yet.

Oh, and thanks to Brennan for turning me on to this. Lot's of other nice stuff on his Power Toys post.

More reasons why a Web Application is a fundamentally unnatrual act.

Yes, more railing about the evils of browser-based "applications".

Follow the link for an MSDN article about how you can put a progress bar on your web page when the server is going to take a long time to process your request.

The rub lies in the fact that the operation runs on the server and there's no way for a server-side environment to push information to a page displayed in a browser (unless the server holds the connection open to the client, rendered to the unfinished page, but that's not recommended). Basically, when a classic postback is taking place the client page is virtually frozen and no other client activity can occur.

The advice in the article is actually pretty good. A perfect job for AJAX. ("A sufficiently advanced technology is indistinguishable from a rigged demo.")

But let's just not forget how much simpler it would be to accomplish the same goal in a thick client. Spin up a separate thread, and point it to a callback method that updates the progress bar. To be fair, it's a fundamentally difficult problem. You generally get fake progress bars when you'd have to pay a high cost for real progress information.

But the mechanics to accomplish all of that is much harder in a web client environment. AJAX does at least bring some sanity to the situation.

Don't chain yourself to your install base.

When I worked at The Very Bad Place, we had an MFC application with an install base of several thousand users spread all over the U.S. It talked DCOM to our corporate servers to get its data. DCOM wasn't a completely insane decision at the time it was chosen -- there were far fewer remoting choices for Windows back then.

What was insane, however, was the admins not knowing enough about DCOM and TCP ports so that the company had to leave the DCOM servers sitting outside the firewalls.

I arrived at that scene back when SOAP was the new Golden Hammer. We probably could have handled most of their security issues with the SOAP-tunneled DCOM that COM+ offered, but that involved some strange inter-departmental politics, so the idea never took flight. They also had the IT departments from a lot of their customers planting the word SOAP in upper management's ears. Thus is the nature of Golden Hammers. So they hired me to put SOAP shims on the client and server so that most of the rest of the system still thought it was talking DCOM. It was all about Microsoft's SOAP toolkit back then.

The basics of tiered design had been abandoned for so long, that not only was the client sending raw SQL straight up to the server, it was even providing the name of the server and the database instance that the SQL should be thrown at.

So, basically, a horror show. But I get my SOAP shims implemented, we release a new version, thousands of clients install it, there was much rejoicing. Even a small performance boost because of a horrid on-server temp-file hack I was able to get rid of.

So all better, yah? No. Because roughly 80% of the install base upgraded. Leaving 20% of the install base still talking DCOM. Meaning that DCOM servers still had to sit with their arses in the wind asking to be hacked at.

And those SQL queries going across the line? It means we can't change our tables until every last client is gone. But we really need to change our tables because they're basically a mirror of a COBOL database, most some 50 columns wide, and it takes 6 hours for the nightly population script to run.

So these are the reasons most shops are so keen to go with web-based applications, and it certainly sounds like I just made a fine argument in favor of them. But we've been lost in this knee-jerk web-enablement world for so long, that I think most have forgotten how much easier it is to develop a thick client app. Besides the fact that they are a lot nicer. It's not the memory consumption anymore. Right now the two biggest memory consumers on my box are Firefox at 48MB, and IE at 40MB. (Sorry, Firefox, Task Manager doesn't lie, maybe it's all those silly plugins I installed.) Microsoft had to stop calling them thin clients. Right now Visual Studio is only taking up 36MB.

But AOL figured out another solution a long time ago, and Microsoft a little (okay, a lot) later. Automatic Updates. And that whole concept is built right into .Net smart clients. Security sandboxes, code verification and signing -- everything you'd want out of a web app without sucking. Gmail is really impressive, but I'll take Outlook, thankyouverymuch. Or Thunderbird.

If you're trying to reach a huge audience of previously anonymous customers, then a web app is obviously the right way to go. Amazon has to be a web app (and an impressive one it is at that, but if they wrote a thick client, I'd sure as hell give it a spin. You hear me, Amazon?). But what if you're just going to have a few thousand users? A few hundred? And they already have to register with you and write you a check? Do you think they enjoy waiting for the page to refresh?

Obviously, there would be a tremendous increase in time spent testing installers, and the upgrade process, and OS version compatibility, and yadda yadda yadda. But development time would go down by just as much, I would think. And developers cost more than testers and admins.

And .Net has done a lot for getting rid of the compatibility and library version issues that an MFC or VB app used to have.

Of course, my Linux brethren are hissing at me right now. And I say -- Mono!

Bamboo Technology

I googled around a little bit, and apparently this expression is not as popular as I thought. And no, I'm not talking about the content management system by that name.

Its inspiration is The Professor on Gilligan's Island. Well, I'll be darned, there's a whole article about it on wikipedia. (I go there a lot to make sure I don't say something patently stupid on here.) The coconut Geiger counter is an all-time classic.

Normally I use it as a negative, but it doesn't always have to be. I'm sure you all have your own bamboo technology you have to deal with -- you're just calling it something else. If I had to define it, I'd say it's stretching an old or limited technology well beyond its intended use. Usually you run across this in a bad way. Our accounting system runs on a "database" called Universe which is almost as old as I am, and you program it in Pick Basic. It calls itself a "multi-value database" which really means, "This group of flat files are fixed-width delimited, but sometimes inside a column you might see multiple values delimited by an unprintable character."

I had heard of neither Universe nor Pick Basic until I got here. You hit the application with a terminal emulator. It has since been bought by IBM, who, clearly by magic, have written an XA JDBC driver for it that actually works. We update our Oracle back-end and the accounting system inside a distributed transaction. I can't begin to think how it actually accomplishes that. Hat's off to IBM for that -- I'll buy their coconut Geiger counter when it ships.

I'd call AJAX an example of good bamboo technology. We've been stuck with javascript since before the dawn of time (assuming time dawned sometime after '95). And we'll continue to be stuck with it for the foreseeable future. AJAX is getting a big bang for the buck in a sensible way that makes the best out of what we have.

But I should save that up for a rant about knee-jerk decisions to do everything as a web app.

NStatic

(Until I figure out a more intuitive way to lay it out, the title of this post is the link to the article.)

Wesner Moise is a former Microsoftian who is working on a group of super-top-secret apps using an AI engine he has developed and is still tweaking.

He's using the AI engine as the back-end to a code analysis tool that he's calling NStatic. (N for .Net, Static for static analysis, which is the technical term for what it does. I believe the term static is used to distinguish this approach versus profiling.)

Think FxCop with a brain behind it instead of a set of rules. It explores your code with all kinds of "what-if" scenarios and can show you where things might go wrong. Kind of like virtual profiling, if I understand correctly. It doesn't actually run your code, and you don't have to provide input. It just analyzes what your code might do.

The idea is that it would just be something running in the background, analyzing your code deeper and deeper the more time you give it, and popping up warnings about the things it finds as it finds them. Like much of AI, it's all about exploring nodes in a tree. I say that like I could just whip something like that up over the weekend.

I would envision using it as part of a Continuous Integration process, so that you could have a dedicated machine digging really deep. He seems to be putting his focus on immediate feedback during development, though. Hmm, think I'll pop him a note.

And he's big into usability, so his UI looks all whiz-bang. Check out the code markup he does to show execution flow. Definitely a toy I want to play with.