Friday, September 09, 2005

BEA’s AquaLogic: What is it?

I met with folks from BEA earlier this week about their recently released WebLogic 9.0 application server and the AquaLogic software the company has been promoting heavily. AquaLogic, I now understand, is the company’s entry in the ESB space. It includes the ESB per se and registry functions. The ESB is based on the company’s former JMS messaging middleware, which it developed in-house. I expect I’ll be reviewing the products at some point later this year.

[Update (March 2006): I did end up writing a review of AquaLogic for InfoWorld.]

Sunday, July 24, 2005

Search Engine Page Depth

In my post regarding Google’s Desktop Search Engine, I mentioned several objections I had to the technology. One of them was that it did not search past 5,000 words in documents.

Subsequent research has brought to light that this partial-search is a common trait of search engines (although most of them go much farther than 5,000 words). How far down the document the indexer will go is a metric known as page depth. And, according to searchenginewatch.com, there is considerable variety in the page depth. According to the site’s 2003 figures (the latest one they have), here is how the major search engines measure up in terms of page depth:

  • Google: 101KB
  • MSN: 150 KB
  • Yahoo: 500 KB

So, as you see: In terms of results, a search engine only gets you partial information on what’s known to be available. Such that the absence of a result should not imply that the item does not exist. In fact, the item might even be sitting in the search engine’s document cache. However, it is simply not in the engine’s index.

Wednesday, July 06, 2005

Rogue Wave C++ Library now Open Source

Rogue Wave (now a division of Quovadix) has open-sourced its implementation of the standard C++ library. The company gave the library to the Apache Software Foundation, which stuck it immediately in its incubator system, from which it presumably will emerge months from now. In its hey day, Rogue Wave was considered a vendor of some of the best-written libraries in C++, so I suspect quality on this will be pretty good as well. The link for more info is here.

Saturday, July 02, 2005

Portable Libraries: Slim choices

As I move forward with my book on Intel EM64T 64-bit extensions to x86, I want to present some complete programs. I want the code to be portable, and I don’t want to write every routine and data structure by hand. What I need is a portable library for C that can be used for free by readers. C/C++ developers with the same problem have a few choices:

For GUIs:

For everything else:

Most of what I need falls in the domain of one of the last three libraries. There are problems with each choice, however. The APR is the most actively supported of these, but it has one horrible failing: zero documentation. And because it uses a very specific model, if you don’t grok how it comes together, you will find it impossible to use.

NSPR is well documented, but is currently supported by only one person. The limitation of his time and his resources make it difficult to commit to the library with heart and soul. Although, of the three general-purpose libraries, this is probably the one that appeals to me the most.

The ACE library is another low-documentation product. In fact, other than Doxygen lists of API calls, the only documentation extant is a book. It seems to me that if you want the lib to be used a lot, the authors should make parts of the contents freely available, enough to get potential up to speed. If the library and the book are good, most every user will buy a copy. But I won’t commit to either one without some certainty going in that I will arrive satisfactorily where I want to go.

So, what to do? I will use the Qt library, which is actually much more than a GUI library. It provides support for threads, networking, sockets, database access, and XML–which are the features I need. The library is dual-licensed: free for GPL’d projects and licensed for a fee on all other projects. Since my code will be open source the free Qt solution works. Plus it’s a lovely crafted library. With great docs–not to say coverage via several books.

The oddest thing in this whole search is the APR’s lack of documentation. Despite having an active list of contributors, nobody has done docs. As a result, the only developers who use it are those who wrote or worked on the library. Seems like a stupid obstacle. I’d help out on docs if I had anyway at all to figure out how the library works, but there is literally no info.

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 Amazon.com’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.

    Friday, May 27, 2005

    Java IDEs Review Follow-Up

    My review of Java IDEs in InfoWorld generated a few corrections, which I’ll pass along here:

    1) Borland JBuilder 2005: I wrote that the Ant file generation was cumbersome. This is incorrect. It can be automated with ease. (Thanks to Jeff Wilsbacher at Borland for pointing this out.)

    2) IBM Rational Developer series: I stated that Rational Application Developer (aka RAD) was the RAD version and that Rational Web developer was the next level up in terms of feature completeness. But, in fact, the product named RAD (and called such inside IBM) is not the RAD tool; Rational Web Developer is. And RAD is the next tier up in terms of features. Go figure.

    Those are the only corrections I’ve received.