Commentary – Page 47

Category: Commentary (page 47 of 982)

Google needs to get better at P.R.

As part of the announcement of its acquisition of Motorola Mobility, Google has posted a page of quotes from other Android handset makers offering support for the merger. One problem: all of the quotes are exactly the same, variations on this:

I welcome Google‘s commitment to defending Android and its partners.

I realize that PR people make up quotes for people, but it might not be a good idea to collect them all on one page. Ideally, you’d think they would want to avoid this effect.

101 ways to save Apple, revisited

August 9, 2011 / Rafe / 18 Comments

Just for fun, in light of Apple’s becoming the most valuable company in the world, I thought I’d take a look at Wired’s June, 1997 cover story 101 Ways to Save Apple. There’s some good advice, some bad advice, and a number of suggestions included to inject some levity into the proceedings.

A lot of the suggestions were to be more like Microsoft and embrace the Windows platform. Apple, obviously, rejected that path and has benefitted greatly from doing so. It’s hard to remember now, but many people thought that Apple should drop their operating system and instead turn to making high end Windows PCs. I think we’re all glad they never went that route.

On to the suggestions on the list:

Admit it. You’re out of the hardware game. Bad advice.
License the Apple name/technology to appliance manufacturers and build GUIs for every possible device – from washing machines to telephones to WebTV. Both good and bad. Apple’s resurgence is due in large part to broadening its product line, but not via licensing.
Start pampering independent software vendors. Good advice. Apple has succeeded by creating platforms developers like, not necessarily by pampering them.
Gil Amelio should steal a page from Lee Iacocca’s book – work for one year without a salary, just to inspire the troops. Bad advice. Steve Jobs earns a $1 salary but this has nothing to do with Apple’s success.
Straighten out the naming convention. Good advice. Apple’s simplified product lines are a competitive advantage.
Apologize. Bad advice.
Don’t disappear from the retail chains. Good advice. Apple outdid this and launched their highly successful retail stores instead.
Buy a song. Whatever.
Fire the people who forecast product demand. Good advice. One of Apple’s greatest advantages is that Tim Cook runs Apple’s operations so efficiently.
Get a great image campaign. Bad advice. Apple’s resurgence has been due to great products, not a great image campaign.
Instead of trying to protect your multicolored ass all the time, try looking forward. Whatever.
Build a fire under your ad agency. Bad advice. The meat of this suggestion is, “People want to know about power (the CPU kind, not George Clinton’s), performance, and price.” This is exactly what Apple does not do.
Exploit every Wintel user’s secret fear that some day they’re going to be thrown into a black screen with a blinking C-prompt. Good advice. “I’m a Mac.”
Do something creative with the design of the box and separate yourselves from the pack. Good advice. Apple went on to design packaging so ingenious that the “unboxing video” was born.
Dump (or outsource) the Newton, eMate, digital cameras, and scanners. Bad advice. They dumped these products in favor of the iPod, iPhone, and iPad — their latter day heirs.
Take better care of your customers. Good advice. See also: Apple stores.
Build some decent applications that the business community will care about. Bad advice. Apple’s success in the applications department has mostly been with creative users, as has always been the case.
Stop being buttoned-down corporate and appeal to the fanatic feeling that still exists for the Mac. Bad advice.
Get rid of the cables. Go wireless. Good advice. Apple has done as much as anyone to de-clutter our desks.
Tap the move toward push media by creating a network computer. Bad advice. Probably the most dated piece of advice on the list.
Sell yourself to IBM or Motorola, the PowerPC makers. Bad advice.
Create a new kids’ computer, an upgradable Wintel-compatible machine. Bad advice. Really, really bad advice.
Create a new logo. Strange advice. Apple introduced the monochrome logo in 1998.
Pay cartoonist Scott Adams $10 million to have Dilbert fall in love with a Performa repairwoman. Whatever.
Portables, portables, portables. Good advice. Compelling portable devices are almost entirely responsible for Apple’s ridiculous growth.
If you sell it, make it! Bad advice. Apple still can’t manufacture enough devices to meet demand. They seem to be doing OK.
Relocate the company to Bangalore and make it cheap, cheap, cheap. Bad advice.
Don’t lose your sense of humor. Bad advice. And besides, when did Apple have a sense of humor?
Work closely with Hewlett-Packard, Casio, or someone who understands power management. Good advice. Except that Apple has become the industry leader in power management without help from those other guys.
Reach forward by reaching back. Good advice. This is a suggestion to bolster the AppleLoan program. You can apply for credit right through the online Apple Store.
Build a PDA for less than $250 that actually does something: a) cellular email b) 56-channel TV c) Internet phone. Bad advice. Turns out you can charge more than that if your product is awesome.
Advice to Gil Amelio: shorter speeches, tighter pants. Remember Gil Amelio?
Change the visual presentation of marketing/advertising to signal that real change is under way. Bad advice. None of this really matters.
Port the OS to the Intel platform, with its huge amount of investment in hardware, software, training, and experience. Good advice. Switching to Intel was a huge, positive move for Apple.
Get MkLinux and BeOS to run on PowerBooks. Bad advice. Not a bad idea, but this never had a chance of changing Apple’s fortunes.
Clone the PowerBook. Bad advice. Apple succeeded by doing the opposite.
Take advantage of NeXT’s easy and powerful OpenStep programming tools to entice a new generation of Mac software developers. Good advice. Inevitable, though, once Apple decided to base OS X on NextStep.
Make it easier for ISVs to make applications for both Apple and Wintel environments – if not at the desktop, then certainly at the server. Bad advice. Mac ports of Windows apps have always been terrible. Apple did gain a lot of leverage by making Unix the underlying platform for OS X, though.
Build a laptop that weighs 2 pounds. Good advice. The original MacBook Air weight 3 pounds and was introduced in 2008.
Cash in on millennium fever. Bad advice.
Arrange venture funding for new, cutting-edge multimedia publishers – this is where you shine and where the public will become interested again. Bad advice. Multimedia was already marked for death when this article was published.
Organize a telethon. Whatever.
Remain committed to the openDVD Consortium, addressing the issues of implementing digital versatile-disc technology. Bad advice. Who cares?
Continue your research in voice recognition. Bad advice. Still irrelevant.
Don’t raise the Mac OS licensing fee. Bad advice. Apple killed licensing of the Mac OS in July, 1997.
Stop wasting time on frivolities like Spartacus, the 20th-anniversary Mac. Good advice. Apple has gotten out of the business of esoteric, small volume form factors entirely. I think the cube killed this off once and for all.
Work on ways to make your lower-end models truly upgradable. Bad advice. Apple introduced the iMac in 1998.
Get Ben & Jerry’s to name a flavor after you. Whatever.
Bring back Andy Hertzfeld and the other original Mac folks. Good advice. Apple just brought back Steve Jobs instead.
Give Steve Jobs as much authority as he wants in new product development. Good advice. Steve Jobs became Apple CEO in September, 1997.
Speak to the consumer. Good advice. Apple product announcements have become some of the most closely observed events in the tech industry.
Return to the heady days of yore by insisting that Steve Jobs regrow his beard. Whatever.
Recharge your strategy for Europe, where the PC market penetration is lower than in the US and the population is educated and interested in high tech. Not qualified to assess this one.
Sell off the laser printer business. Good advice. Margins in the printer business disappeared over the past decade or so.
Give the company that buys the printer business a contract to manufacture printers with the Apple trademark. Bad advice. The printer business is irrelevant.
Stick to your schedule. Bad advice. Apple released the first developer preview of OS X in August, 1997, the “public beta” in September, 2000, and the first production release in March, 2001. They still survived.
Bring back John Sculley. Whatever.
Create dollar incentives to attract software vendors to write for the upcoming Rhapsody platform. Bad advice. Bribing developers to code for your platform is not a strategy.
Invest heavily in Newton technology, which is one area where Microsoft can’t touch you. Bad advice. OS X was the future.
Abandon the Mach operating system you just acquired and run Windows NT kernel instead. Bad advice. Really, really bad advice.
Ink a promotion/development deal with Shaquille O’Neal; introduce designer Shaqintosh model. Whatever.
Build a computer that doesn’t crash. Good advice.
Make Java work on your OS. Then develop an enterprise computing strategy in partnership with Sun. Good advice. One reason the Mac stayed relevant in the early OS X years was that it was the ideal platform for writing Web applications that would eventually be deployed on Unix servers.
Team up with Sony, which wants to get into the computer business in a big way – think Sony MacMan. Bad advice.
Roll out the Mac Plus again as a hip retro machine. Good advice. Isn’t this what the iMac was?
Get the top systems integrators to push NeXT’s WebObjects as the ultimate intranet/Internet development environment. Bad advice. Apple actually sort of tried this but open source platforms won out.
Tighten the focus on your publishing niche – both print and electronic – and seek to dominate it in every way. Bad advice.
Retain your Apple Fellows at all costs. Bad advice. People who aren’t developing products aren’t really that useful.
Change your name to Snapple and see if you can dupe Quaker Oats into buying you. Whatever.
Simplify your PC product line. Good advice.
Become a graphic design company and dominate your niche the way Sun and Silicon Graphics do. Bad advice. Turns out Silicon Graphics didn’t have much of a future at all, and neither did Sun, in the end.
Try the industry-standard serial port plug. Bad advice.
Rename the company Papaya and begin an aggressive South Pacific marketing campaign. Whatever.
Solidify the management team. Good advice. Steve Jobs took over as CEO in September, 1997. Tim Cook joined the company in March, 1998. Jonathan Ive joined Apple in 1992. Scott Forstall came over from NeXT. Phil Schiller joined Apple in 1997.
Speed sells. Push your advantage on the speed of the processor. Bad advice. Apple moved to Intel, and competition based on hardware specs became a thing of the past.
Make damn sure that Rhapsody runs on an Intel chip. Write a Windows NT emulator for Rhapsody’s Intel version. Good advice. Apple moved to Intel in 2005. Virtualization has made it easy to run Windows software on Macs.
Lose the cybercafés idea. Good advice, quickly heeded.
Turn Claris loose so it can do some real damage. Bad advice.
Exploit your advantage in the K-12 education market. Good advice, in theory. In the end I don’t think it mattered much.
Maintain existing loyalty at all costs. Use incentives like free upgrades and stock certificates. Bad advice.
Merge with Sega and become a game company. Bad advice.
Give the first Apple made exclusively for Windows a cheeky name. Bad advice.
Develop proprietary programs that run only on Macs. Good advice. Keynote, Final Cut Pro, and Aperture are all good examples here.
Effectively communicate your game plan. Good advice. File under “obvious” though.
Quit making each Mac in a platform-specific case, with platform-specific parts. Bad advice. Well, it’s obviously bad if you read this whole item.
Organize a very large bake sale. Whatever.
Price the CPUs to sell. Bad advice. Apple never really went cheap.
Acknowledge that there are people with repetitive stress injuries. Good advice. Apple didn’t follow it, though.
Create a chemical that cleans the Mac’s pale gray plastic. Bad advice. Apple killed off the gray plastic computer instead.
Design a desktop model – call it La Dolce Vita – with a built-in cappuccino maker. Whatever.
Start a new special projects group led by either Jobs or another passionate and creative designer to create the next “insanely great” technology. Good advice. Apple basically just turned the whole company into this special projects group.
With each new Mac, include a CD-ROM that explains the Apple family tree and future plans. Bad advice. How many units would this have ever sold?
Develop a way to program that requires no scripting or coding. Bad advice. Unrealistic.
Maintain differentiation between Wintel and Apple. Good advice. Probably the best piece of advice on the list.
Fight back. Stand up for yourself with ads that respond to the negative press. Bad advice. Better to build things that don’t earn the negative press in the first place.
Partner with Oracle, using its technology for a backend database with your friendly face. Bad advice. I can’t think of a worse partner for Apple than Oracle.
Have Pixar make 3001, A Space Odyssey, with HAL replaced by a Mac. Whatever.
Testimonials. Good advice. Apple’s Switch ad campaign is basically this. Those ads were incredibly effective.
Reincorporate as a nonprofit research foundation. Funny.
Build a second graphics/video product based on the connection with Pixar (and therefore with Disney). Bad advice. This wouldn’t have saved the company.
Don’t worry. You’ll survive. It’s Netscape we should really worry about. Nailed it.

I’m not the only person who has taken this on. Derek Warren compiled a detailed look back in February. I found his piece after I wrote this one.

Starting with the command line first

August 8, 2011 / Rafe / 0 Comments

Bagcheck, a company I’d never heard of, was acquired by Twitter today. In Luke Wroblewski’s announcement of the deal, he lists some of the things they learned in building the startup. One idea that really captured my imagination was building features starting with the command line interface:

We always add features to the Bagcheck API (and thereby command line interface) first. This provides us with a way to start using new things before we invest time in how they’ll look and work in a graphical user interface. In fact, the first bags ever made on Bagcheck were lovingly typed into the CLI character by character. Including my complete mountain biking set-up.

Obviously, we decided creating bags needed an easier solution than pure text entry! But starting with just the essential actions in the CLI gave us a great understanding of how bags could be created and managed in more capable situations. In fact, starting with the API and command line interface always forces us to distill things to their core essence and to understand them simply. What can go in and what will come out? That makes designing more enhanced versions of the same features much easier. We know what they need to do and why.

This reminds me of Josh Bloch’s talk on how to design a good API. In it, he argues that you should start coding APIs by writing a client for the API rather than implementing the back end of the API.

Designing from the API up is similar to designing from the schema up, either way, you’re starting with a data model, although in the API case you’re starting with a data model and verbs rather than just the data structure.

How I got automated texts to originate from one number

August 7, 2011 / Rafe / 3 Comments

Being that we live in a DevOps world and all, the application I work on sends me texts when it looks like things are going wrong in production, even though I am a developer and not a systems administrator. For months, I have been mildly annoyed that these texts originate from a variety of phone numbers preventing my phone from categorizing them nicely and forcing me to delete them individually to keep my texts organized.

The texts have been sent through the email-to-text gateway provided by AT&T. My scripts email a message to [email protected] and it arrives as a text message on my phone. Unfortunately, there’s no way to control the originating phone number when you use that approach.

It occurred to me that I may be able to use Google Voice to get around this problem. You can send texts from a Google Voice account, and I figured they had some kind of API that would let you do it. I went and set up a Google Voice account associated with my work email and then quickly discovered that there is no Web service that you can use to access Google Voice.

However, some enterprising person has created a Python library that accesses Google Voice through the regular Web interface. I did some testing and found that I could send the texts using the library. Unfortunately, I’m not allowed to install random Python libraries on our production servers. I had been hoping I could just use the curl utility to send the texts so that I could avoid having to ask our systems administrator to install anything but the Python library was the only option.

Fortunately, I have my own virtual server, so I wrote a simple Python CGI script that sends the texts and installed it on that server. Here’s the source:

#!/usr/bin/env python

import cgitb, cgi

from googlevoice import Voice
from googlevoice.util import input

cgitb.enable()
form = cgi.FieldStorage()

phoneNumber = form.getfirst("phone", "")
text = form.getfirst("text", "")

if len(phoneNumber) == 10 and len(text) > 0:
    voice = Voice()
    voice.login("USERNAME", "PASSWORD")
    voice.send_sms(phoneNumber, text)

    print "Content-Type: text/html"     
    print  
    print "<html><body>SMS Sent</body></html>"

So now my monitoring script sends the alert using curl to access the CGI script on my personal server, which in turn uses pygooglevoice to access Google Voice via screen scraping, which then sends me a text from a specific phone number. I don’t rate this approach very highly in terms of robustness, but at least my texts are now properly organized.

The opportunity cost of a broad skillset

August 6, 2011 / Rafe / 2 Comments

Tim Bray laments the feeling of productivity you get when you work with tool set that you’re intimately familiar with. He talks about constantly experimenting with the next great thing as part of his job, specifically the downside:

But it means that I’ve been sort of a perpetual newbie. There’s another big piece of the software experience, one I haven’t shared in for years: where you’re concentrating on some problem and you know the codebase and tools, so your time goes more into doing and less into learning. In fact, that kind of work, in particular maintaining a large running production system, is where most of my professional colleagues spend most of their years of service.

That captures what I always liked least when I worked as a consultant. Moving from one project to the next, often on a different technology stack, meant never really feeling comfortable with what you’re working on.

On the other hand, working on maintaining a large, established system is often frustrating in its own way. You’re saddled with a code base that’s tough to change, with libraries that are often out of date, and with processes that aren’t cutting edge.

I have a friend who has worked at the same small company for nearly 10 years, and they seem to rarely update anything that currently works. I describe his skill set as being trapped in amber. He is a complete master of the way Java applications were built ten years ago, but the industry has changed a lot in that time, and he’s missed out on benefitting from those changes because the company he works for is hidebound.

Keeping an existing application up to date is difficult. I’d love to see some statistics on how many applications that were built in Rails 1 have been upgraded to Rails 2 or Rails 3.

In the end, this is one of the toughest parts of a software development career to manage. Walking the line between having the sorts of deep skills that enable you to be spectacularly productive and having a wide skill set that enables you to contribute in more situations is tough. Personally, I’ve always envied developers who are hyper-specialized. I know a guy who’s an expert on C compilers and always has a job with whatever company is trying to push gcc forward. If nothing else, he doesn’t have to sit around wondering whether he’s making a big mistake by not picking up Scala.

Our current situation in a nutshell

August 5, 2011 / Rafe / 6 Comments

You call file this as the greatest subhead of the year:

The debt-ceiling debacle revealed that politics is broken in every possible way and there’s no point in explaining complicated matters to the American people.

The column is by Jacob Weisberg at Slate, and I urge you to read the whole thing. It sure feels to me like America has chosen an irreversible path of decline.

The tax implications of Diablo III

August 4, 2011 / Rafe / 1 Comment

One interesting and controversial aspect of Diablo III from Blizzard is an auction house where players can sell items they find in the game for real money. Players can put items up for sale and Blizzard will take a cut. Jamais Cascio notes that game prizes that have cash value must be counted as income, whether or not you sell them:

When you win a prize in a game that has cash value, that prize is taxable at the fair market value, even if you do not sell it. This is true in the United States, and (from my cursory Googling) appears to be true in the UK and India (and likely many other locations). So when you stumble across that Massive Staff of Infection or Red-White-Blue Shield of Copyright Infringement, items that could be sold in the Diablo III Market for $20, $50, or even $100, you’re legally supposed to declare those winnings on your taxes. While that might seem like common sense if you sell them and end up with a few hundred dollars in your PayPal account every year, it will likely come as a surprise if you’re just playing and avoiding the auction house entirely.

It’ll be very interesting to see how this shakes out.

El Bulli and the impetus to create

August 2, 2011 / Rafe / 0 Comments

As I was watching last night’s No Reservations episode on the last days of El Bulli, the world’s greatest restaurant, I wondered a bit about the future of Ferran Adria and the foundation that he is working on to continue the groundbreaking work he did at the restaurant.

For those who are a bit in the dark, El Bulli was a restaurant in rural Spain where chef Ferran Adria created and popularized many of the molecular gastronomy techniques that make up the foundation of modern cooking.

The restaurant closed for good this weekend, to be replaced by some sort of creativity center. What I wonder about, though, is whether the closing of the restaurant will, in the end, stifle Adria’s creativity in some way.

For many people, myself included, the greatest impetus to create is the necessity of delivering something. Everything else aside, Ferran Adria knew that every summer when El Bulli opened for the year, the people lucky enough to get reservations would expect to encounter a menu more interesting and impressive than the last. In addition to his annual deadline, Adria’s creativity was always constrained by the fact that the dishes he created had to be replicated by other chefs every night for dozens of diners. It will be interesting to see what he produces without that framework.

As the old saying goes, real artists ship. I’m reminded of this post on the dangers of producing concept products.

Who says programmers aren’t superheroes?

August 1, 2011 / Rafe / 1 Comment

I just wanted to point you to a post I really enjoyed, under the innocuous name Safari Keychain Woes. In it, developer Daniel Jalkut explains how he used OS X development tools to figure out why Safari 5.1 wasn’t filling in passwords properly from his Keychain. Interesting from beginning to end and a great illustration of what you can do when you understand how things really work.

rc3.org

Strong opinions, weakly held