Wednesday, June 29, 2005

Streaming Desktop Major League Baseball: Not Ready Yet

As this year’s baseball season started up, I decided to test Major League Baseball’s new option for watching my favorite teams: streaming video of their broadcasts. A subscription costs only $14.95/month and I can watch the games of as many teams as I want. At first, this was fun, but as time passed the limitations of the subscription have led me to consider cancelling it. The problems are technological and political.

The political problem is that Major League Baseball (MLB) has exclusive national TV contracts with various networks. “Exclusive” is the operative word. For example, due to these contracts there are no streaming video of baseball games on Saturday. MLB also has regional contracts, in which a network might broadcast a game I want to watch. Even if the network doesn’t broadcast it in my home market, the mere fact that they might have precludes me from seeing it on streaming video. So, in essence, I have a 6-day/week subscription with numerous holes in the remaining schedule.

The technology problem is the video itself. It’s delivered in a 2″x3″ screen in the browser. You can make the image larger, but you lose picture quality as you expand it. The video also has a problem that it frequently stutters and then blanks out all together. In the latter case, the screen just shows the MLB logo. You have to restart the transmission to get the picture back. This happens more in the Firefox browser than IE, but it definitely happens frequently (about once per inning) in IE as well.

The bottom line is that between the technology glitches and the politics, streaming MLB video is a frustrating experience.

[Update (April 2006): I subscribed again this year and had to cancel. The service has not improved in the intervening time.]

Wednesday, June 22, 2005

Google Desktop Search: good, but limited

Google’s enterprise desktop search (available here at no cost) is a useful tool. It does pretty much what you’d expect: it reads through your docs and e-mail and gives you an instant search capability. It has saved me several long searches for docs I knew were lying around but I couldn’t remember exactly where.

For all its benefits, however, the technology does have some distinct limitations:

  • it only searches the first 5,000 words of any document
  • you cannot remove or add items to the search database. (You can prevent it from looking in certain directories, but once its sucked up a document, you can’t remove it from its database.) The software crawls how and when it wants to. If you want it to perform a new crawl, you have only one option: uninstall it and reinstall it. No kidding!
  • There’s no concept of security. You cannot password-protect access to the search engine.
  • The engine does not search Eudora mailboxes.
  • The display does not highlight the searched-for keyword in the document.
  • For these reasons, true enterprise search tools such as IBM’s Information Integrator OmniFind do not have much to fear yet from this free offering. “Yet” is the operative word. Obviously, all these limitations are intentional, as Google has demonstrated it has the technology to get around them in its other products. So, at any time it could fold these features into its free offering.

    If you can live with these limitations, you’ll definitely find the search engine useful.

    Sunday, June 19, 2005

    Preparing for JavaOne 2005

    This year’s JavaOne conference is around the corner. This guide tells you how to prepare properly. Enjoy!

    Saturday, June 18, 2005

    ISVs: Use Embedded Databases, Please

    This week, I completed my review of CodeAssure, a static source checker that focuses on security problems. It ships from Virginia-based Secure Software Inc. The product analyzes a C or Java codebase and generates a file of project vulnerabilities each time it’s run. This data is then shown to developers to help them locate possible security weaknesses. A separate manager’s console can compare these files, quantify project progress, and display this in a dashboard for project management purposes.

    For this comparison, CodeAssure requires and enterprise DBMS (be it Oracle, DB2, or SQL Server) to store these data runs. (Up to the customer to cover the cost of obtaining the license for this.) Primarily because of this DBMS, Secure Software flies out an engineer to set up and install the package each time a customer buys a copy of CodeAssure. The question is: Why not make this database embedded? If the company used an embedded database, it could:

  • ship the product as a turnkey product
  • save the cost of sending out an installation engineer
  • lower their customers’ implementation costs
  • Those are compelling benefits.

    There are some great embedded databases out there. Sleepycat software’s Berkeley DB being probably the best known and arguably the best implemented. But it’s certainly not the only choice. There are many others, some of which are completely free for commercial use, such as Apache Derby.

    The reason for not using them, I believe, is that ISVs simply don’t think in terms of this kind of solution. CodeAssure is the defining example of a product where embedded databases should be used: it’s an applaction that is the sole consumer of the data it generates. I asked the Secure Software why it had not chosen the embedded model and the staff responded that they generate so much data, it could be handled only by an enterprise DBMS. This suggested to me that they had not tested embedded products sufficiently.

    Embedded databases are robust and highly scalable. A case in point is Sleepycat’s product, which is thefront-end cache for’s product/inventory database. By size, that database is among the top 20 commercial databases in the world.

    In the hybrid enterprise/embedded space, there are products like MySQL, which to my knowledge have not exhibited scalability issues.

    Secure Software did allow that it was beginning to examine embedded options for future releases. I encourage them to do so, as I do all ISVs who cannot articulate a specific reason that an embedded solution is insufficient for the need. This design will make installations and deployments easier, plus save customers the cost of paying for new and expensive DBMS licenses. And so, we’ll all be a bit happier.

    Thursday, June 16, 2005

    Choosing a programming language

    Programming languages rise and fall in popularity. This fact places pressure on managers to choose the right language when starting in on a big project. In my case, it places pressure on authors when choosing the language with which to exprese a concept in code. I have always chosen C, reasoning that C is readable and understandable by all C++, C#, and Java developers–which is about as broad a base of readers as I’m ever likely to reach. (Knuth’s discusses this difficult choice in the just-released Fascicle 1 of the Revision to Volume 1 of “The Art of Computer Programming” from Addison-Wesley, ISBN 0-201-85392-2)

    An interesting website list the interest in specific languages based on counting Web searches for topics relating to the language. Results are normalized to avoid spurious one-off results. The methodology is explained in detail on the website. The results for the last few years are shown. I am surprised that C is still #1 (actually, it reclaimed the prize from Java a few months ago.) What is surprising is that C and Java lead C++ by such a wide margin. If I’d been asked to guess, I would have swapped the positions of C and C++ and/or possibly placed Java in first place.

    There are two other interesting items. Despite rumors to the contrary, COBOL is still thriving. It’s in the most active class (those assigned a grade of ‘A’) and a fair bit ahead of Fortran and Pascal. Also, the conventional wisdom about the ‘P’ scripting languages (the three candidates for the letter P in the LAMP stack) appears to be correct. In descending order of interest, they are: Perl, PHP, and Python. Which I suspect is what most people would have guessed.

    Anyway, use this info as a data point for your own decision making and in your choice of language skills.

    Tuesday, June 14, 2005

    Qt 4.0 from Trolltech

    I met with the folks from Trolltech last week for a presentation on Qt 4.0, which ships at quarter end. For readers unfamiliar with Qt, it is a highly portable toolkit (that is, GUI, collections, database, threading, XML functions and others) that’s used by many ISVs. It is dual-licensed, meaning that if you use it on a free, open-source project, you can get it at no cost. For anything else, you’ve got to buy a license from Trolltech. The free version is the basis for Linux’s KDE (the K Desktop Environment).

    I worked with Qt 3.x for well over a year and I was very impressed. Qt is one of the cleanest libraries available. It is written C++ and is well thought out, well designed, and after a little experience it becomes intuitive to use. On Windows, I think it’s a better interface to the operating system than Win32 is. Not only because it’s better designed (You soon know the APIs without looking them up because they’re so consitently named.), but because it’s portable (to Linux, Mac, UNIX). Version 4.0 is a major upgrade. The Trolltech folks told me that they added numerous functions and also redesigned the painter so it renders far more-advanced graphics far faster. And, indeed, the demo blasted the screen.

    Qt 4 also adds considerable threading support, which I think will be an important, even if underappreciated, benefit. When I was co-authoring the book on Hyper-Threading Technology for Intel Press, I had to write the same program twice. Once for Windows threads and once for Pthreads (the Linux/UNIX threading model). I really wanted a portable way to write the code. If Intel Press had allowed it, I could have used Qt 3 (I didn’t even ask because prior to Qt 4, Windows versions of the library required a paid license–there was no freebie for open-source projects.), but Qt 4 with its greater threading coverage and friendlier Windows license would be a slam-dunk today.

    Qt 4 looks like an important release. (I suspect I’ll be reviewing it once it ships.) And with Macs soon migrating to Intel platforms, some code will need to be rewritten. Qt 4 probably represents a better solution than porting and tweaking old Mac code, especially for Mac developers who are entertaining any ideas of moving to Windows later.