Pankaj Kumar's Weblog

Although, almost all the stories are engaging, I found the the following most interesting:

1. Ford versus Selden: George B. Selden got a very broad patent on basic principles of automobiles and tried to use this to extract license fees from all auto manufacturers. But Henry Ford, a gifted mechanic who had developed his own auto designs, was determined to bring autos to masses at very affordable prices. He fought hard against the Selden patent and finally won.
2. Sarnoff versus Farnsworth: Who invented television? Was it Sarnoff of RCA or Farnsworth. A recent Google search of "Who invented television" returns links that all point to Farnsworth as the inventor of television. But this wasn't always so. You have to read this story to beleive the corporate power of twisting reality.


3. Edison versus Westinghouse: Edison may have been the biggest inventor of the century but he missed the importance of Alternating Current (AC) and stuck to hist Direct Current (DC) generators. Another fascinating story.


4. Wright Bothers versus Curtiss, and Others: Wright Brothers were probably ahead of others in building and flying controlled flying machines but they were certainly not alone in this endevour. Still, they got the patent and used that to their economic advantage.

It was a pleasant surprise to see my very first book review published at Slashdot!

The overall process of submitting and getting published was quite an experience. It started with me submitting the review draft day before yesterday. The submission process itself was quite smooth, although I did get the impression that Slashdot gets a lot of submissions than it could possibly publish.

So, I was pleasantly surprized to got a mail from one of the editors, Tim Lord, known as timothy, the very next day. It had some high quality feedback on improving the review as well as fair amount of lambasting that I hadn't read the Slashdot book review guidelines (which, BTW, was true!). Couple of email exchanges later, I had a fairly good idea of what was expected in a Slashdot book review. There wasn't anything new that isn't already covered in the review guidelines, but the guidelines are no match for the direct coaching in the context of a specific work.

Happy that I had the attention of Slashdot, I reworked the whole review and submitted it again yesterday night. The final version that appeared at Slashdot had some more editorial adjustments.

You can see what difference the editorial coaching made by comparing my original draft with the one that got published.

The intensity of the interaction and the quality of feedback amazed me -- it was much more detailed and substantial than those editorial comments I got on draft chapters of my book or other publications. Tim kept telling me that I should say *what and why* about the book than just saying *it is great*. No wonder Slashdot reviews are generally read much better (than reviews at other places).

I am still somewhat mystified about why Tim spent as much time with me as he did, especially considering the high volume of review submissions they get. Though I do have some plausible explanations: I perhaps had a few sentences that caught his attention:

• "Using a Hole-Hawg for the job of a homeowners drill can have deleterious effect on productivity by causing serious harm to the health of the inexperienced operator." Just identifying a tool for a task is not enough. You should also be able to match the demands of the task to the characteristics of the tool and your ability to handle the tool.
• What this book does is to create the right context, introduce the appropriate topics, and generate sufficient motivation to explore further. Fair enough. In fact, I believe this is the best approach for any book in this "Google era" -- the book should tell what you should look for and let Google do the rest.

This, coupled with the credibility due to author status, might have influenced him. Or that is what I think.

Apache Ant, the Java replacement for make, belongs to the rare breed of category killer software for automating Java software development tasks. As a long time Ant user, I have written many Ant build scripts, automating my builds and speeding up the overall development cycle, mostly relying on its excellent online documentation. As a Java developer, I have admired its simple and intuitive interface and the modular design. So on getting Ant The Definitive Guide in my hands I wasn't expecting a whole lot new to learn, and thought of using it only as a reference book for occasional use.

After having the book on my desk for more than a month, and occasionally reaching out to it and flipping through its pages whenever I would otherwise have consulted the online documentation, I must say that I was missing out on something very important: tasks like ftp and war deployment that I was simply not aware of and had never felt the need to lookup, but could very well use. The other interesting thing I noticed was that my build scripts became smaller, more modular and easier to read.

Like most books in the The Definitive Guide series, Ant The Definitive Guide assumes certain level of familiarity with underlying technologies such as Java and XML and focuses on providing complete, reference like details of Ant features and tasks. These description are generously supplemented with examples and code fragments.

But so is the the online documentation for Ant! Will someone gain additional insight in using Ant, or be able to work faster, or make better use of Ant capabilties, if he or she consulted the book, instead of the online documentation for a particular Ant task. To find the answer, I randomly picked two tipics -- filesets, an important and oft-used Ant datatype, and javac, a core Ant task -- and compared their online description with the one in the book. Here is what I found.

Besides the datatype definition, explanation of various attributes, sub-elements, and the examples, the book also covers how to specify conditional inclusion or exclusion of certain filename patterns when a property is set (or unset). Though this can be inferred from online documentation by a determined user, this particular use is far from obvious. The coverage in the book also talks about relationship of fileset datatype with the javac task, pointing out that the fileset attribute dir is equivalent of javac attribute srcdir, as attribute dir will be confusing in javac: is it referring to source directory or destination directory. This is the kind of insight that really helps a user.

The treatment of the javac task in the book is not much different from the one in the online documentation. Both have almost the same material, though the information in the book is better organized for new users. On the other hand, I found the online documentation to be more complete, especially with respect to the compiler specific options and behavior idiosyncrasies.

Here is a run down on what the book covers: Chapter 1, Getting Started is a quick primer on Ant, with sufficient details for a new user to start using Ant for very simple build tasks. Capter 2, Using Properties and Types introduces the building block tasks and datatypes, such as property, condition, fileset, path like structures, selectors and so on, used in other Ant tasks. Chapter 3, Building Java Code covers the tasks and activities around compiling Java source files (ie; javac), organizing the build steps in various targets within a single build scripts and/or across multiple scripts, genrating documentation using javadoc and creating distribution jars and zip files. Rest of the chapters are devoted to tasks for specific purposes: such as launching external programs (Chapter 7, Executing External Programs), copying files and manipulating directories either on the same machine or over the network (Chapter 4, Deploying Builds), running JUnit tests (Chapter 5, Testing Builds with JUnit) and so on. There are also separate chapters covering interation of Ant with XML and XDoclet (Chapter 9, XML and XDoclet) and with Exclipse (Chapter 11, Integrating Ant with Eclipse). The last chapter, Chapter 12, Extending Ant, talks about extending Ant by doing things like adding your own tasks, creating custom filters, writing your own build listeners and loggers etc. This chapter also has a small section on how to embed a script written in one of the supported scripting languages within an Ant script.

As you can see from this outline, the book covers almost everything that is to know about Ant and other related software.

So, what is not so good about this book? Well, I didn't find anything wrong with whatever has been covered. Ofcourse, there are additional things that I would have liked to see in the book: (a) A good sample Ant script which could be used as the starting point for most small to medium size projects; (b) A more thorogh explanation of how dependencies among targets determine the execution sequence and how does this fit-in with explicit invocation of targets; and (c) use of pictures to illustrate some of the concepts such as life cycle of an Ant task, selection of files in a fileset, dependency tree of targets.

Overall, I found this book by Steve Holzner to be comprehensive, well organized, easy to read and good value for money.

The Best Software Writing I is a collection of essays and articles on Software, selected, compiled and introduced by Joel Spolsky of Joel on Software fame. Most of articles in this collection refelect the contrarian style of Joel's own writings -- a story telling approach, mixing of humor, preference to simplicity and sloppiness (over complexity and rigor), disregard for the established, and acknowledgement of the diversity (in programing talent).

Read the rest of the review here.

The business of software usually gets tons of footage by the tech media covering its various facets: products, people, organizations, its economics, business models, technology trends and myriad other related things. So one would think that it would be difficult, if not impossible, to say something original. However, this collection of blog entries by noted blogger Eric Sink, founder of SourceGear, a vendor of source code control system, and developer of a Web browser at Spyglass that later came to become Internet Explorer, manages to do just that. He does so by focusing on workings of a lesser known niche in software business, that of privately held small ISVs, relating to his own personal experiences in a very engaging manner.

Imagine that your content-sharing website has been wildly successful and the number of uploads and downloads, along with users, are rising exponentially. This should have been cause for celebration but there is a little problem: although you are able to increase capacity by throwing more hardware, the site is not able to keep up with all the file transfers across different servers. You have looked at the file transfer protocols like FTP and SMB, and have tried NFS and SCP but they all turned out to be inadequate in one way or other.

What would you do? Keep buying more and faster hardware or optimize the application by rolling out your own specialized file transfer protocol?

When faced with this question, flickr.com went with the second option -- it designed a simple and light-weight file transfer protocol and developed an implementation tailor-made for its environment in just 600 lines of PHP code. Given the overall popularity of flickr.com and resultant increase in traffic, I would bet that this 600 lines of code has saved good amount of money in server, power and cooling costs.