And I quote:

I was interested the license terms that Microsoft will ask people to agree to under its new "Communications Protocol Program". I'm not that interested yet in looking at what they're selling, I just wanted to see the terms for buying it.

The DOJ is asking people in the industry to look over the license agreements to ensure that they really are "reasonable and non-discriminitory", and being a patriotic American, I thought I'd help them out. I set off to www.microsoft.com.

Of course, there was a snag. according to http://www.microsoft.com/legal/protocols/ , I have to sign an NDA before I can see the license agreement.

That sounds funny. The DOJ wants industry input, but Microsoft doesn't want me to talk about it.

I figure, "that's alright, it's a public document, DOJ will give me a copy." So I called up the DOJ Antitrust Documents Group. They tell me first that I need to get it from MS. Then I explain, well, no, I can't. They want an NDA, which might preclude me from talking to DOJ about it.

They need to mull this over, so they say they'll call back. I never thought I would be looking forward to a phone call from John Ashcroft's Justice Department.

A DOJ attorney called me back. He's no longer on the case, but he worked on the remedy phase, and knows the right people to pass stuff along to. Furthermore, he's happy to do it, and to help address my concerns.

We discuss the NDA, and he tells me he hasn't read it, but believes it is supposed to contain an exception for talking to the DOJ. My concern is, how do I know that the terms are "reasonable and non-discriminitory" if I can't discuss the terms Microsoft gives me with others in the industry? They collect information on your company before they'll show you the license agreement. How do I know I got the same deal MegaCorp down the street got if I can't discuss the terms with them?

He says good point, and scribbles down some notes. He then tells me that there is a meeting of DOJ attorneys going on at that very moment discussing the NDA. He asks me to simply go to the Microsoft site, get the NDA, and see if there is anything in it which would cause me a problem.

So the good patriotic American trots off again. I click the link to see the NDA. What's this? Oh, I have to sign in with a Microsoft Passport first.

I don't have a Microsoft Passport. I don't want a Microsoft Passport. I want to read the NDA to see if there's anything objectionable in it so I can read the license agreement for a piece of software I may or may not use.

Call back the DOJ. The guy is still very friendly and helpful, even though I feel as if I could be annoying at this point. He assures me it's ok.

Unfortunatly, he also says he doesn't think DOJ has a problem with Microsoft requiring a Passport to view the NDA for the license for the code I might or might not use. Unless there's something specific to the Passport agreement that makes the license agreement bad.

So that's where I am now. I finally have a legal document in front of me to review. It's not the one I wanted though. It seems as if the answer to keeping the public out of your hair is to simply keep throwing up barriers, one after another, until finally people get sick of fighting and one of them sticks.

Original source: none of your business.

...does it always take two weeks for a submitted article to get out of the queue & end up on the site? I'd like some feedback... *shrug*

Beginning Perl for Bioinformatics, by James Tisdall
Published by O'Reilly & Associates, copyright 2001.
ISBN 0-596-00080-4

As the banner above the title of James Tisdall's Beginning Perl for Bioinformatics indicates, this book is "an introduction to Perl for biologists". What the banner doesn't mention is that it's also an introduction to biology and bioinformatics for Perl programmers, and it's also an introduction to both Perl *and* biology for people that have never really been exposed to either field. The banner may not mention this, but the author has clearly thought a lot about making one book to please these different audiences, and he has pulled it off nicely, in a way that manages to explain basic topics to people learning about each field for the first time while not coming off as condescending to slow-paced to those that might already have some exposure to it.

Superficially, this book isn't all that different from a lot of introductory Perl books: the Perl material starts out with an overview of the language, followed by a crash course on installing Perl, writing programs, and running them. From there, it goes on to introduce all the various language constructs, from variables to statements to subroutines, that any programmer is going to have to get comfortable with. Pretty run of the mill so far. The interesting thing is the two assumptions that all of this is written with: [1] that the reader may never written a computer program before, and so needs to learn how to engineer a robust application that will do its job efficiently & well, and [2] that the reader wants to know how to write programs that can solve a series of biological problems, specifically in genetics and proteomics.

As such, there is at least as much material about the problems that a biologist faces and the places she can go to get the data she needs as there is about the issues that a Perl programmer needs to be aware of. The author introduces the reader to the basics of DNA chemistry, the cellular processes that convert DNA to RNA and then proteins, and a little bit about how & why this is important to the biologist and what sorts of information would help a biologist's research. The main sources of public genetic data are noted, and the often confusing -- and *huge* -- datafiles that can be obtained from these sources are examined in detail.

With the code he presents for solving these problems, Tisdall makes a point of not falling into the indecipherable Perl trap: this is a useful language, well-suited to the essentially text-analysis problems that bioinformatics means, and he doesn't want to encourage the kind of dense, obscure, idiomatic coding style that has given Perl an undeservedly bad reputation. Some of Perl's more estoeric constructs are useful, and they show up when they're needed, but they're left out when they would only serve to confuse the reader. This is a good decision.

Rather, the focus is on teaching readers how to solve biological problems with a carefully developed library of code that happens to leverage some of Perl's most useful properties. The result is pretty much a biologist's edition of Christiansen & Torkington's _Perl Cookbook_ or Dave Cross' _Data Munging With Perl_. The author presents a series of issues that a working bioinformaticist might have to deal with daily -- parsing over BLAST, GenBank, and PDB files, finding relevant motifs in that parsed data, and preparing reports about all of it. If a bioinformaticist's job is to be able to report on interesting patterns from these various sources, then the programming techniques that Tisdall explains in clear, easy to follow prose would be an excellent way to go about doing it.

And when I say "programming techniques", note that I'm not specifically mentioning Perl. The code in this book is clear and organized, and all programs are carefully decomposed into logical subroutines that are then packaged up into a library file that each later sample program gets to draw from. Each new program typically contains a main section of a dozen lines of code or less, followed by no more than two or three new subroutines, along with calls to routines written earlier and called from the BeginPerlBioinfo.pm that is built up as the book progresses. This sample is typically proceeded by a description of what it's trying to accomplish and followed by a detaild description of how it was done, as well as suggestions of other ways that might have worked or not worked.

This modular approach is fantastic -- too many Perl books seem to focus so heavily on the mechanics of getting short scripts to work that they lose sight of how to build up a suite of useful methods and, from those methods, to develop ever more sophistocated applications. It isn't quite object oriented programming, but that's clearly where Tisdall is headed with these samples, and given a few more chapters he probably would have started formally wrapping some of this code into OO packages.

If I have a complaint with the book, that's it: everything is good, but it ends too soon. Seemingly important topics such as OO programming, XML, graphics (charts & GUIs), CGI, and DBI are mentioned only in passing, under "further topics" in the last chapter. I also have a feeling that some of the biology was shorted, and the book barely touches upon the statistical analysis that probably is a critical aspect of the advanced bioinformaticist's toolbox. I can understand wanting to keep the length of a beginner's book relatively short, and this was probably the right decision, but it would have been nice to see some of the earlier sample problems revisited in these new contexts by, for example, formally making an OO library, showing a sample program that provided a web interface to some of the methods already written, or presenting code that presented results as XML or exchanged them with a database.

But these are minor quibbles, and if the reader is comfortable with the material up to this point, she shouldn't have a hard time figuring out how to go a step further and do these things alone. It's a solid book, and one that should be able to get people learning Perl, genetics, or both up to speed and working on real world problems quickly.

+---------------+
Personal footnote
+---------------+

When the karma cap kicked in, I was somewhere just under (I think) 80 points. They've been slowly bleeding off since then, but had been at 64 for I think at least the past couple of months. Looks like someone noticed -- when this article was submitted, I got kicked down to 50.

Nice to see that I can try to be a positive contributor to Slashdot for a while now, and all that surplus karma evaporates because I submitted a book review. Oh well, it was fun while it lasted... :)

Testing new journal page. Slashdot has just upgr^h^h^h^h^h converted (upgrade seems too generous) to a new version of Slashcode, thus completely shooting itself in the foot and severely damaging the ability of millions of linux nerds to multislack while at work. Or hundreds of 'em anyway. But at least it has made first posts easier, so clearly the quality quotient around here is only skyrocketing... :(