Mini book reviews

I buy and read a lot of computer books (for various definitions of "read" -- references often aren't page turners).

I always have my judgement about the book from my point of view, but I hesitate to share it with others, as I think there is no better opinion than the one a reader has after he's read the whole book on his own.

That said, when I buy books, I want to read what others thought of it. So to provide a service to my faithful readers, I am kicking off some mini-reviews of book's I've read, mostly in relation to my work.

About Face 3: Essentials of Interaction Design

For anyone like me, who hasn't formally studied Human-Computer Interaction in school but now finds themselves working on anything with a non-trivial user interface, this is the first book I recommend you read.

It's extremely easy to read, and spends a respectable part of the beginning of the book explaining why UIs need to be designed, before moving on to the how of designing one. If you're buying an interaction design book it's because you realize the need for UI design yourself, but may be first required to convince management that the interaction design process needs to be taken seriously; the beginning section will give you that ammunition.

However those who are already professional designers will likely find it fairly a waste of time, and spend most of the book skimming over repetitions of things they already know.

Those like myself, who feel they have a bit of intuition for user interaction design, will find a fair amount to skim over; however without any previous training HCI, it is reassuring to have your intuitions confirmed by the experts, and so even the skimming will be rewarding.

The reason why I chose this book over others is that it's a tutorial, and it proposes a simple design method that concentrates on the heart of designing any tool: people (personas) and what they want to do (goals). It's simple, direct, and resonates very well with my design sensibilities.

The middle part of the book introduces the core methodology (Goal-directed Design), and the latter part of the book moves on to placing that theory within the context of contemporary GUI design. An excellent combinational of motivation, leading into theory, leading into method, leading into example, in a comprehensive, intuition building manner.

Any software developer without existing library on user interaction design needs this book in their core library.

Content Networking: Architecture, Protocols, and Practise

I am not sure if the book defines "Content Networking" very well, but basically it amounts to "how do you get lots of cool content to lots of people on an Internet Scale?" This is very relevant question for our virtual world design efforts.

Printed 2005, this book is somewhat dated given that I am basically only looking out for state-of-the-art texts (or theory, which is undying).

It has chapters on web content, streaming media, IM, and P2P, but those chapters, for me, feel like very cursory survey chapters that don't tell me very much. I enjoyed reading them and found them useful, but I'd probably rather buy dedicated books on each of those topics separately.

What I found very interesting was the treatment of web content, and the secret weapon of the web that makes it so insanely scalable: load balancing and caching. Both of which are relatively simple techniques, but the book goes into specific methods in detail and really opened my eyes to what goes on that I merely took for granted. HTTP gets static for having higher overhead than UDP, but this book makes it pretty clear the stateless nature of HTTP means you can do amazing things with caching and load balancing that make the web scale to global levels.

If you're planning a large scale content deployment system I recommend taking a browse through this survey book, but otherwise it's not overly impressive. Borrow a copy.

Parallel and Distributed Simulation Systems

From the title it's appropriateness to virtual worlds is obvious. However its printing date of 2000 belies a different focus. The book assumes an audience of mostly military simulation designers, and makes direct reference to various standards published by the US military for use in war simulations. The book makes reference to "casual" uses outside tanks and jets, and may even use the phrase "virtual world", but it will take some imagination to remove the discussion from it's military context and place it in a VW one.

The book has a distinct academic feel, visible in its eagerness to categorize all different kinds of methods or system types and give them "helpful" acronyms. The reading is a bit dry, but not overly technical.

If you are looking for a systematic approach to simulations, and want to know what the baseline standards are, having been established in 2000 or earlier, it's worth spending some time to look through. It is probably reassuring to know some terminology within the book, and that you can't go wrong doing something the military has done previously. However there are no new or interesting ideas here at all. At best a reference for a fall-back implementation.

Level of Detail for 3D Graphics

Level of Detailing is quite possibly one of the single most critical linchpins for scalability in a virtual world. You can have a large number of objects sitting in a database, but at the end of the day, a camera sees everything up until the horizon, in all directions, and in some manner everything visible has to be brought into memory and drawn. Clearly the less work "drawing" all those things are, the higher your simulation can scale.

Sometimes reading a book is less about what it tells you as what it doesn't tell you, or rather what it tells you "don't worry, you're not missing anything":

Although the book is dated, the book told me the state of the art LoDing in 2003 boils down to the following decisions: when to LoD, what to LoD, and how far to LoD. LoDing itself is taken for granted as only mesh simplification, which was a bit of a disappointment in that I was hoping there were more magical techniques available, especially for textures which are a substantial burden in VWs. Perhaps there is more to LoDing, just all of it invented post 2003. I was also hoping to find some techniques that minimize loading of meshes, but perhaps the authors failed to consider anyone would be so reckless as to download meshes over the internet. :)

Disappointments aside, mesh simplification is extremely important for future reX, but I suspect that loading those meshes from over the network is by far the greater bottleneck, hitting long before the graphics card breaks a sweat from excessive vertices, so for us mesh simplification would have to happen before the client viewer downloads it.

Recommended for anyone who is implemented a LoD system where huge meshes are bottle necking the G/CPU.

Disruptive Products, or Disruptive Technology doesn't apply to Software

Disruptive Technology

For a long time I've heard people use the phrase "Disruptive Technology" in conjunction with one idea or another, as if the invocation of the phrase was supposed lend some weight to the discussion I never quite fathomed. The people who tended to use the phrase also tended to be the sort of people who often used those kind of phrases in such a manner as to render them meaningless, so I never really paid much attention to exactly what it was that they meant -- because strangely enough, it turned out that whether declared "disruptive" or not, it made no difference as far as I could tell!

I've heard half-coherent explanations of the phrase, but I always took it to mean "technology that makes managers and business-types no longer understand how to make money", which I thought was nothing special considering I assume that most business types don't understand technology anyways, and their understanding of how to make money with it was always suspect in the first place.

However after Clayton Christensen's "The Innovators Dilemma" made its way to the bookshelf at work, I thought I would see just what it was I was missing the whole time. Turns out there is far more to the idea than the throngs of excessive catch-phrase users would imply.

Firstly, I object to the use of the phrase "Disruptive Technology", since that implies to me there is something inherent in the engineering or science that causes a technology to become "disruptive", which is just not the case. The things labeled disruptive technologies often have traits in common, but those traits are really all about how a market perceives them, and have nothing to do with technology itself. I prefer "Disruptive Products", because that captures the fact that this is a book about Business Management, not Engineering. The idea of "disruptive technology" as presented by Christensen cannot be separated from the fact that is is a product destined to be sold on a market.

I recommend you read the entire book yourself, because there are lots of noteworthy ideas for anyone interested the business of technology, but I will give a brief summary of the major themes as I saw them herein.

The author uses his extensive research into a collection of industries where certain technological innovations happened, which he characterizes as either "sustaining" or "disruptive", and how the affected the health of the businesses in that industry.

A Sustaining Technology is one where the market for the products made with the technology is well known, and the firm in question can use the technology to increase its profit margin by adding new features which increase the products performance in the market.

Higher profit margins mean the company can further grow, and invest that growth in tuning the entire operation of the firm to servicing the high-margin market. In many ways the firm becomes captive to its high-margin customers, because failing to invest in sustaining the growth in performance of the products, as its existing customers demand, will cause it to hamper its own growth in profit, and lose market position. The author notes that a firm's quest for continued growth, forces it to "trend upward" from the low-end low-margin area of the market, to the high-end high-margin, and that trend is essentially inevitable if a firm wants to satisfy its investors.

Disruptive Technology is one where there the technology has no proven market at the time of development, but eventually will develop a market outside the expectation of its developers.

That in and of itself is hardly surprising. The interesting thing about the book is that Christensen does his research, and finds there is a historical trend in disruptive technologies, that if known, can help businesses manage and succeed in turning disruptive technologies into profitable, and often industry changing, products.

He discovered that DTs have common traits, and the following traits serve as a definition of a DT

• DT often appear as an innovation stemming from an existing industry.
• DT provide value in areas that the current market places no value in. Historically this means they are low-performing and low-cost, but provide benefits such as reduced size, or improved flexibility.
• DT, due their perceived lack of value in the existing market, begin their life as a product by taking the low end of the market, left under served as established firms climb to the high-end in pursuit of growth.
• Existing firms are completely unable to capitalize on DTs because their high-end cost structure means they cannot grow with low margins, and thus development of DT into products for the emerging market is left entirely to small firms.
• DT improve in performance in traditional metrics over time, as well as retaining the benefits that gave it access to its first emerging market, and thus begins to move into the high-end and cannibalize the previous market (for which it initially appeared ill-suited), and the existing firms, caught flat footed, find them selves in serious trouble.

To make that more concrete, the classic example used throughout the book is the hard drive industry. The story there is

1. market demands higher capacity and speed for their existing computers, which existing well-managed firms deliver, and thus grow and move upscale
2. someone develops a smaller form factor drive, with dramatically reduced capacity, and the existing market soundly rejects is as unsuitable for their needs
3. new markets emerge for smaller computers (mainframe -> minicomputer -> pc -> notebook -> appliance (ipod, car-navi)), which find the smaller form factor indispensable
4. density on the small form factor drives increase to the point where it cannibalizes the market for large high-margin drives, and the once small companies who were able to market the small drives grow larger and displace the incumbents
   
5. repeat (14 -> 8 -> 5.25 -> 3.5 -> 2.5 -> 1.8 etc inch drives)

Disruptive Products

However while reading the book, I kept trying to see how the concepts there applied to what I was doing, which is programming in the software industry. I couldn't help but come to believe that this analysis was a little bit dated, being published in 1997, and only seemed to apply hardware products.

Hardware products have a easily quantifiable manufacturing and distribution costs, and thus have a clear relationship between price and profit. That is expensive hardware is expensive because the physical bits involved in making it are expensive, and the overhead of moving those bits to market is expensive.

Software however, has no fixed costs except programmer salary (among which programmer talent and pay can vary widely), and some minor managerial overhead. For a shrink wrapped software product, you could charge $1000 one day and $1 the next, and it would cost you nothing but your profit margin to do.

And here is the controversial point coming up:

I don't believe that, ultimately, software is really a product at all. It's a service. The days of being able to hand over an application in exchange for $X will soon be gone for good.

Ultimately, there will be two models for commerce in the software industry:
1. Custom whole application development
2. Customization of existing open source solutions to emerging, specific, business needs

Although the first case you might assume that since there is an integrated deliverable, you might consider it a "product", I would assert that what the developer is being paid for is to solve a problem, and so the compensation is proportional to the problem, not to the cost of manufacturing the good.

I foresee that so long as there exist new and different niche businesses, there will always be a demand for new and niche software; things not complete serviced by any pre-existing software package, and have to be built from scratch.

The second case makes a lot of assumptions in excluding proprietary software from the picture. Let me try to follow the history of open source in the software industry, and use that to justify my extrapolation.

• Most open source projects are born out of existing industries, either because the a firm needed some software for its core business, and found that once completed it was valueless to keep it secret, or because engineers trained in an industry felt like putting their skills to use outside of a corporate setting.
• Open source solutions at first held no value for anyone outside hobbyist and hackers. It was hard to use, poorly supported, and lacking important features. However the one value proposition it did provide, access to the source code, gave it flexibility that made it absolutely indispensable for certain applications such as research or highly customized niche applications, where the code would have to be heavily modified, but there was no justification for starting entirely from scratch.
• Due to the perceived inappropriateness of open source for business or personal use, open source use often started out as skunkworks style projects running under the radar of management, in small low-end roles where other existing solutions were inappropriate.
• Existing firms software firms, Apple, MS, Adobe, etc, at first treated open source with derision, then fear, and tried to ignore it for the longest time, because their dependence on high-margin software sales could never allow it to move downscale and compete with something that was free. It would be corporate suicide. This allowed smaller shops to capitalize on the commercialization of open source.
  
• While at first constrained to only the low end, open source has been on a trend of steadily increasing quality over time, and is now at the point where MacOS has significant open source portions, Adobe is open sourcing the basis for its strategic Flash platform, and Linux is seen as a credible alternative for Windows on low end machines.
• I predict this trend will continue to the point where open source has so complete dominated the software world, from the bottom up, that firms like Apple are constrained to sell their OS as value-added perks on top of a mostly open OS for their hardware, Adobe becomes a seller of boutique software, and MS becomes a systems integrator and software as a service provider.

Open Source is a Disruptive Product

Surely, I'm not the first person to think of this...

The way of virtue

Failure is an opportunity.
If you blame someone else,
there is no end to blame.

Therefore the master
fulfills her own obligations
and corrects her own mistakes.
She does what she needs to do
and demands nothing of others.

-- Chapter 79

My words always mean precisely what I define them them to mean -- that's a Tautology!

'I don't know what you mean by "glory,"' Alice said.

Humpty Dumpty smiled contemptuously. 'Of course you don't-- till I tell you. I meant "there's a nice knock-down argument for you!"'

'But "glory" doesn't mean "a nice knock-down argument,"' Alice objected.

'When I use a word,' Humpty Dumpty said in rather a scornful tone, 'it means just what I choose it to mean--neither more nor less.'

--

Mini-review of Foundations of GTK+ Development

Foundations of GTK+ Development is definitely recommended for anyone doing any serious GTK+ development. The authors style is easy to read, and the book serves as both a decent tutorial for any programmer fluent in C looking to learn GTK+, and a reference for intermediate programmers who want to broaden their knowledge of GTK+.

The author wisely spends his chapters on the most useful and most often misunderstood parts of GTK+, leaving the hand-holding chapters to a blessed minimum. This means there is little fluff, and a lot of meat. Since its based on GTK+ 2.10, we are able to skip the deprecated, or just plain old crufty parts, and get straight to the modern usages, such as GtkTreeView, GtkUIManager, and Glade. There is even a couple pages on cairo, within the context of GTK+ 2.10's new printer support.

His entire chapter on deriving existing types, and creating new ones (in the often arcane GType system) is sure to be a god-send to beginning programmers, and a well worn reference point for programmers in code mode. Add in the over 100 pages of appendix material documenting GTK+ properties, signals, styles, stock icons, and error types, and you've got a handy resource.

While all the information in the book is available somewhere free online, including the indispensable devhelp, the GNOME website, and even the GTK+ website itself, having a coherent narrative in handy physical form, I think, is worth the purchase.

Even though the book weighs in at over 600 pages, given the degree to which GTK's abstractions leak, I would have liked it if the author spent a little bit more time explaining the design issues that lead to these leaks.

For example, the author briefly mentions GObject's inherent ability to support the Pimpl (pointer to private implementation) idiom, and gives the boiler-plate code to achieve it (which is good). But when reading the code, one notices that MyObject appears to contain no reference to MyObjectPrivate, while the class constructor for MyObjectClass contains the function

g_type_class_add_private (klass, sizeof (MyObjectPrivate));

(which is mysterious, to me at least). If abstractions are going to leak, I would like it if the author could spare a couple sentences to give me an idea why such a call is necessary, if only avoid a mild state of incongruous bewilderment.

Lastly, I would have liked to get a bit more insight into some of the more fringe, but related, technologies, such as cairo or D-bus; and more details into tricker parts like threading, or a full working example of how to integrate foreign sub-systems using Glib. However this may be asking too much for one book, so perhaps we will have to wait for the author to spring "Advanced GTK+ Development" upon us!

The Social Animal

Required reading for anyone who spends any time around other people.

http://www.amazon.com/Social-Animal-Elliot-Aronson/dp/071675715X
http://en.wikipedia.org/wiki/List_of_cognitive_biases

And while we're at it, I't tired of constantly finding these when talking to people:
http://en.wikipedia.org/wiki/Fallacy
http://en.wikipedia.org/wiki/List_of_fallacies

The only places I've found for english language computer books in Tokyo/Kanto is Junkudo in Ikebukuro, and Yurindo in Landmark Plaza (Sakuragi cho). If you don't live near either place, your best bet is Amazon.com.

If you are a programmer spending any time at all working on gnu/linux -- beginner or intermediate, this book is highly recommended. Even if you think you know it all already from skimming the table of contents, there are enough gems in this book to make it worth while to anyone short of master.

For me, pinfo libc was worth the price of admission.