The logging in Capistrano could be so much better. Just for example, when a task is initiated, that log item should really pop out. At present, the log line starts with “executing” for both the indication that a task has been started, and for running a remote command. Because the same word is used, it is hard to see at a glance where you are in a long task. So at present it is:

   * executing task reload_apache
   * executing "sudo /etc/init.d/apache2 reload"

This is lame. Task initiation is important, and should be called out in the first word. Similarly, when a command is run sudo, the fact of “sudo” probably has priority over “executing.” So for my eyes, at least, something like this would be far more communicative:

*** Task: reload_apache
  * sudo: "/etc/init.d/apache2 reload"

And output and errors might be flagged with two stars.

I bet the changing the logging for the task, at least, would be a quick monkeypatch.

Hmm, it looks like a foreshortened Apple “wired keyboard” — but notice that extra key to the left of the shift on the wireless keyboard. That has been tripping me up big time!

Oh, well.

My development has switched to all-Mac-and-Linux 95% of the time, and so it was time to replace my aging ThinkPad with a Mac laptop. I have found that in the last two years, reducing the weight of my shoulder bag by even a pound or two can make my life much more livable, so the Air seemed like a good choice. Naturally I was concerned by the relatively slow speed, lack of connectors, and the RAM limitation . . . but . . . it sure is light!

Here are the pros and cons as I’ve experienced them:

Pro

• Everything that’s good about OS X and the Mac platform generally; good riddance Windows.
• Speed and memory has been good enough for Rails.

Con

• The lack of connectors is a huge deal, especially if you want to use the external superdrive. The Air’s external superdrive cannot be plugged into a hub (even if the hub is powered). Because of this, you cannot run the superdrive and, say, external USB keyboard, mice, etc., or use the Mac USB-to-ethernet connector. So when using the superdrive, you must rely on Bluetooth (for keyboard and mice) and on your wireless network. These are tough requirements, but if everything is working, it could be ok.
• Which leads me to my real gripe. The bluetooth connectivity between the Air and Apple’s new bluetooth keyboard is awful. I am constantly losing connections. This has been reported on all of the Mac boards. Despite a recent firmware upgrade that was supposed to help, the problem is ongoing. Some theorize that the issue is competition between bluetooth and 2.4ghz wireless — I can control that a bit, but I am in an area of Cambridge that is saturated with wireless connectivity at 2.4ghz across all channels. I am constantly using the superdrive to re-burn some old CDs, and I also use a separate keyboard, mouse, and monitor when working at home: So I must have reliable bluetooth. The only thing that seems to work is to completely remove all bluetooth devices, shutdown, start back up, and re-add (i.e., re-pair) the devices. That is very time-consuming. Another interesting tidbit is that the bluetooth system preference will lose the “don’t wake because of bluetooth devices” setting if you remove them all. So have to remember to re-set that. This is all a far cry from bluetooth on the ThinkPad, which in my experience was flawless.

So . . . I love the Air, but I may have to acquire a separate Mac just to rip CDs (so that I can use external devices with USB instead of with bluetooth). Or I suppose another option would be to use a non-Apple external CD drive that can work through a hub.

The new Amazon EC2 Elastic IP feature, which provides for a static IP for instances in the EC2 cloud, should resolve a lot of problems which I won’t go into here.

Note, however, that when you associate one of these static IP addresses with a running instance, the old IP goes away. So if you have DNS entries pointing to your servers, you will need to change them at the same time. And I hope that your TTL is low.

It is too bad that Amazon can’t have both IPs associated at least for a little while — like 48 hours so that users with evil caching DNS servers won’t be hosed in the interim.

The New York Times ran a fascinating article today on Cybersyn, which was a Chilean attempt to apply the ideas of cybernetics to the monitoring and management of their economy. Here’s a quotation and a couple of pics from the Times and Wikipedia:

A Star Trek-like chair with controls in the armrests was a replica of those in a prototype operations room. Mr. Beer planned for the room to receive computer reports based on data flowing from telex machines connected to factories up and down this 2,700-mile-long country. Managers were to sit in seven of the contoured chairs and make critical decisions about the reports displayed on projection screens.

While the operations room never became fully operational, Cybersyn gained stature within the Allende government for helping to outmaneuver striking workers in October 1972. . . .

He wanted to use the telex communications system — a network of teletypewriters — to gather data from factories on variables like daily output, energy use and labor “in real time,” and then use a computer to filter out the important pieces of economic information the government needed to make decisions. . . .

Cybersyn’s turning point came in October 1972, when a strike by truckers and retailers nearly paralyzed the economy. The interconnected telex machines, exchanging 2,000 messages a day, were a potent instrument, enabling the government to identify and organize alternative transportation resources that kept the economy moving.

The strike ended within a week. While it weakened Mr. Allende’s Popular Unity party, the government survived, and Cybersyn was praised for playing a major role. “From that point on the communications center became part of whatever was happening,” Mr. Espejo said.

Here’s a Mixwit mix-”tape.” Neat idea.

ISO certification is what destroyed the U.S. manufacturing economy. With ISO 9000 there was suddenly a way to claim with some justification that a factory in Malaysia was precisely comparable to an IBM plant on the Hudson. Prior to then it was all based on reputation, not statistics. And now that IBM plant is gone.

(http://www.pbs.org/cringely/pulpit/2008/pulpit_20080321_004574.html)

Ben Casnocha, My Start-Up Life: What a (Very) Young CEO Learned on his Journey Through Silicon Valley (2007). [Amazon]

This short book is packed with sensible observations from the real experiences of a CEO who started a company (Comcate) with a raw idea, raised money, and built the company up enough to have real customers, real employees, revenues, and, I hope, profits (though this last detail is either not confessed or buried in the story and I missed it). The product was a hosted app allowing small towns to manage their “customer” feedback on-line; each town was billed $10K to $30K / year (p. 151). The product eventually morphed into a “code enforcement” package (p. 154) which became their real money-maker. The story is supposed to be more provocative than the usual CEO/start-up story because the protagonist in this one is . . . 15 years old. I actually didn’t find the youth of the CEO to be as amazing as other readers have. The culture of business now permeates teenage life in a way it didn’t when I was Casnocha’s age: Parents are more open about their own businesses, and are more eager to mentor their kids in entrepreneurship. So let me say a few things about how the book might serve a wannabe-CEO or business-founder as a vade mecum.

Because the author is young, he has to get a lot right to be credible. So Casnocha trained himself at finding the right resources, the right examples, and the right books to serve as guides. He knows some things that a lot of business owners don’t learn right away: He knows that his business is all about customers with real problems (p. 21); he rightly disdains utter slavishness to the customer (citing Henry Ford, p. 22), in favor of judicious listening; he determines the price of his product from its cost (p. 24). I could go on and on. Some of his formulations were fresh for me:

“How critical are these problems?” I asked. Some problems only require “vitamins”–that is, a product that’s “nice to have.” Some issues require “antibiotics,” which means they’re mission-critical problems. Most profitable businesses solve mission-critical problems, or the “must-haves.” I learned customer service is not mission-critical for organizations (whereas financial, payroll, and purchasing systems, for example, all are). My product, then, would be a vitamin. At the time I did not fully understand the challenge of trying to sell a vitamin, instead of an antibiotic. This is probably because I personally had no real “needs.” Like most other kids, I had wants, but I didn’t think about needs. Food, shelter, clothes were all taken care of by my parents. I didn’t view the world through a lens of improvement, a perspective all great entrepreneurs carry. (pp. 23-24)

There are a lot of people who want to found businesses who also have never experienced true need.

As I mentioned at the start of the review, eventually Comcate latched on to providing software for “code enforcement,” and he makes a number of astute comments about the difference between “good revenue” and “bad revenue.” Basically, if it scales and can be automated, it’s good. If not, it’s bad. This is hard-won advice, and Casnocha presents the contrast in a couple of pages. (pp. 154-155). A lot of start-ups never figure this out.

On the technology side of the story, Casnocha had a pretty tough time. He always went for the cheap solution, hiring a weak engineer for the first version, and had security and uptime issues (pp. 102-103). Here we have exactly the experience of the non-techie CEO of a web-based business: A missing player in the early game for Casnocha was a good CTO; when he got one, the CTO almost quit: “The technology folks . . . believed the business folks . . . didn’t grasp the nature of the technology. They believed we made too many unrealistic demands regarding what product functionality could be developed and at what cost. The business folks thought the engineers were unnecessarily vague in their time line and cost estimates (’It’s done when it’s done’ always justifiably infuriates managers who need to stick to a budget)” (p. 138). (Clearly both sides here are screwed up when the CTO says “it’s done when it’s done”; perhaps true, but the opposite of diplomatic in a startup.) Reading between the lines, I would have to say, as well, that seeing the CTO as a non-manager is highly problematic in a web-based product. I.e., the CTO should be more of a peer and less of an underling. Casnocha knows some of this, and says: “Technology start-ups take note: when a programmer isn’t on the founding team, it is difficult to find engineers who are both high-quality and affordable” (p. 139). But I think the problem is much deeper, and implicitly you have to read Casnocha as acknowledging that is was a mistake not to have such a founding CTO, because it affects all aspects of the business, not just hiring. In any case, Casnocha must be a good listener, because rather than accept the resignation of his CTO, he got everyone talking again, and made concesssions (p. 140), i.e., reorganized work to fit the engineering mindset.

There are many other good bits; as a teaser I’ll mention the thoughts of a 15-yr. old who wonders why his new COO would haggle over a few extra days of vacation . . . It will be interesting to hear how Casnocha will read his own book in twenty-five years.

Start-Up CTO Bookshelf

Each grade is on a 100-scale; 75 is a C, 85 a B, 95 an A, 100 and A+.

My Start-Up Life:

Book category: Start-up stories

Impact: 80
Utility: 80
Authority: 85
Good story: 87
Reference: 75
Writing: 87
Humor: 85 (intentional, nut unintentional . . .)
Nudge: 75

Start-Up CTO Score: 82

Tim Berners-Lee (with Mark Fischetti), Weaving the Web (1999). [Amazon]

We are coming up on the 10th anniversary of the publication of Tim Berners-Lee’s Weaving the Web, so it seems appropriate to reflect on it about ten years later. Re-reading it now, it is striking how utopian it is. Berners-Lee ended the book on an incredibly hopeful note, talking about how the Web models the real-life web of human relationships, and there is a lot of stuff about how the Web will be about everything, and will be the vehicle for human/computer augmentation. It may be hard for you to remember it, if you read the book when it came out, but it finishes with reflections on faith, as Berners-Lee talks about his personal discovery of Unitarian Universalism which in his view “match[ed . . .] the objective I had I in creating the Web” (207). He saw Unitarianism and his practices for the Web allowing for “decentralized systems to develop” emphasizing the value of individuals and the common good (208).

I wonder what Berners-Lee thinks now? In the last chapters of Weaving the Web, we hear of many technologies sponsored by the W3C that, while they are everywhere, have hardly become dominant. Most images on the web are still GIF or JPG (not PNG), SVG is not available on all browsers (IE requires a plugin), PICS doesn’t seem to be in use, and P3P was a bust. The semantic web is still a project of the universities and startups (though perhaps it is about to explode, through simplified analogues such as microformats). Compared to the explosion of activity in the years covered by the book (1989-1999), 1999 to the present has represented a refinement of the standards created before 1999. Perhaps the most significant triumph of the W3C has been the emergence of a mostly standard DOM on most browsers, and the advent of XML as the most important data-exchange standard; while its low point has been SOAP and a disdain for REST.

And it would seem to me that the idea that the Web emphasizes the value of the individual and the common good is contested on all sides.

Still, the book has significant high points and sections that deserve re-reading today. Throughout the book, there is a critical drumbeat around the failure of browsers to provide an easy means to edit an arbitrary page, which is still a huge gap. In Berners-Lee’s view, the whole point of the Web client was to provide for both reading and creating content. Nowadays, content creation has largely been relegated to hosted apps, and those apps rarely respect nicely the idea of the URI, which Berners-Lee considered the most important standard element of the Web, ahead of HTTP and HTML (p. 36). (The idea that the Internet should balance production and consumption of content was everywhere in the late 90s — you also saw it in Negroponte’s Being Digital [1995], where he strongly advocated having the same bandwidth upstream and downstream to facilitate home video production and transmission.)

Other fascinating areas where Berners-Lee is prescient regard “code” and net neutraility. He agonizes over the tension between human-made laws and the protocols of code (pp. 123-124) — it is almost as though he is writing the brief for Lawrence Lessig’s later work on the real-world primacy of “code” in dictating how things (really) work in society. Regarding net neutrality, Berners-Lee is an absolutist, and provides the core reasons for preventing companies from making certain types of content privileged on their public networks (p. 130).

The last thing I would want to say about the experience of re-reading this book is that the core structure of the web is still pretty basic compared to the visions of hypertext from the 1960s and 1970s. Anyone who has read Ted Nelson knows that he was onto something when he advocated micro-payments as a part of the core infrastructure of hypertext systems. We still don’t have decent micro-payments. Another gap is around transclusions: links are great, but transclusion remains a hack. But the book answers the question as to why the web is so basic in its protocols: It’s because the process of introducing these standards was inherently political, and the raw standards were about the most anyone was willing to adopt.

Dean Wareham, Black Postcards: A Rock & Rock Romance (2008). $25.95. [Amazon]

This is Dean Wareham’s story of his experience as the lead singer and principal songwriter of two of indie rock’s greatest bands, Galaxie 500 and Luna. It’s a memoir told in historical sequence, and seems to pretty honest (for a lead singer/songwriter . . .) about the joys and miseries of collaboration in music. If you have even passing interest in either of those two bands, you must read this book. If you’re interested in indie rock from the 80s and 90s, you’ll enjoy it as well; he relates provocative stories about Damon and Naomi (the rhythm section, and much more, for Galaxie 500 and beyond), the producers Kramer and Tony Visconti, the scenester Terry Tolkin, and many others. It’s also a good read if you’ve wanted proof of intelligence out there in rock world. It’s well written, and frequently droll. Wareham has a nice stylistic tic of deflating a phony with the final sentence in a paragraph:

Neil Hagerty of Pussy Galore was hanging around during our sound check. I’m not sure what he was doing at CBGB at five in the afternoon, but he seemed to be out of it on smack. His eyes were pinned and he stood by the side of the stage, scratching his legs and telling about the suede pants that he had picked up on the street for $5. Admittedly, that is a very good price for suede pants. (p. 58)

For each band there is a narrative arc from inception though self-discovery and self-knowledge, down to acrimony, depression, and boredom. A parallel story is how it has become increasingly hard since the 80s to stick out from the crowd even if your band is great, and to make any decent money — Wareham tells this story with frequent acknowledgement that with the advent of digital music downloads, you just can’t get the big advances anymore. And by “big advance,” we mean: Big enough to live without constant touring. There are incidental comments along the way about the awful economics of rock nowadays: For instance, clubs will ask for a cut of t-shirt sales (see pp. 290-291) . . . Now that’s sick and greedy. There are loads of stories here about hotels and clubs all over the world, drugs, people lost all along the way: I’ve read a lot of rock books and Wareham’s story of the routinization of road pleasures is perhaps the best. Wareham is good, too, about recovering details that were doubtless hugely significant in their moments: E.g., the relative merits of a Dodge Dart vs. a Datsun B-210.

A fair amount of the book is devoted to mentions of the decline of his marriage and his affair with Britta Phillips, a latter-day bass player for Luna; now, after Luna, Wareham is half of Dean and Britta. I won’t spend much time on that here, but the emotional story is a bit thin for a memoir. Balancing this thinness, though, are copious quotes from the songs. So when you’re wondering whether Wareham felt much about anything or anyone, it is worth pondering the lyrics he quotes near these scenes (which Wareham discusses on p. 259). Or, perhaps obviously, the true emotional story is about the “family romance” of being in a band: Wareham represents the two other band members in Galaxie 500 as acting like his parents (and thus making him yearn for a certain kind of freedom from them), and later acknowleges that break-up, and that of Luna, as a kind of divorce.

There’s also some rock wisdom in these pages:

Good drummers tend to come from the suburbs. They have a distinct advantage–garages, basements, extra rooms–all things that are in short supply in New York City. (p. 119)

Towards the end:

You can generally add a star to the review if you announce that the band is breaking up. (p. 283)

I read this fine book on a plane to Arizona without access to my tunes; but the narrative is so compelling that I could hear them in my mind as I read.