Rafe – Page 52

Author: Rafe (page 52 of 989)

Links for June 10

Trying to spin up the link blogging again:

Kevin Carey explains why all those articles about the decreasing value of college degrees are wrong.
Mike Loukides thinks everyone needs to learn JavaScript. I agree, but I have little progress on that project this year.
John Scalzi has a simple rule of thumb for figuring out whether or not you’re cheating on your significant other.
Inbox Influence is a browser extension that shows the political donations people in your Gmail in box have made. It’s a very cool illustration of how easy access to various databases will affect user experience in the future.
Rands talks about notifications. His tangential discussion of RSS is noteworthy as well.

Getting bug fixes into the pipeline

June 9, 2011 / Rafe / 0 Comments

I don’t work at a company that does continuous deployment like Flickr, or Etsy, or Facebook. We are not close to doing continuous deployment. I’m not sure anybody at the company besides me is interested in continuous deployment. Generally speaking, when we create new features, the product team creates a spec, then developers write a short tech spec, then quality assurance comes up with a test plan, then we write the feature, test it, launch it, and then test it again.

There are many reasons why we do things this way, some of them good, some of them bad. For one thing, our product is aimed at businesses, and so our features are driven by feedback from customers and from people who work with our customers every day. As a developer, I don’t really know what sorts of features our customers would pay for. The second is that our product is a key piece of infrastructure for our customers. When we make changes that affect how it works, there’s pretty substantial risk of making our existing customers unhappy, so we have to be very careful about the changes we make to existing functionality in our product. Finally, our product and processes have been around since before continuous deployment or even automated tests were industry practices, and it’s tough to fight against history.

Anyway, one persistent problem we have is putting bug fixes for minor issues or general maintenance of the code base onto the schedule. The product people decide which features get implemented, and nobody wants to add testing time by approving additional development work that isn’t essential to whatever business requirement is the top priority at the time.

The trick is to find a way to hijack our process so that we can get more developer priorities onto the release schedule. What I realized recently is that there are gaps in our process — times when most of the team is focused on preparing for an upcoming release or we’re designing features and waiting between steps in the review process. We should be filling that time with work on other bug fixes and back end improvements.

So after discussing it with the team, we decided to create a new process. Generally we check all of the features and fixes for the release to come into trunk. Now we’ve created a new branch for each developer. They’ll claim bugs that they want to see fixed and check the fixes along with automated tests in them into their own branch. Then, as we review the bugs and fixes and our testers find time to verify those fixes, they will be merged into the trunk for the subsequent release.

If we were using Git instead of Subversion, I’d probably recommend creating a new branch for every bug fix or feature, but one branch per developer is the least painful approach with Subversion. It’ll be interesting to see how this new approach works. I get an email every night with a list of all the errors that are logged on our production servers on a daily basis, and I’m looking forward to making those email messages much shorter.

When platform vendors attack

June 6, 2011 / Rafe / 6 Comments

Apple announced a whole slew of new features for iOS 5 and OS X Lion today, and some of them step on the toes of popular third party applications. The New York Times has a helpful list of threatened applications. To gauge the reaction, check out the results of a Twitter search for “sherlocked.”

Platform vendors build in functionality that’s already being provided by third party applications all the time, and this has always been the case. It’s also always been the subject of some controversy. I’m old enough to remember when Dave Winer was feuding with Apple because AppleScript competed with Frontier. And of course, Microsoft’s decision to bundle a Web browser with Windows rather than ceding that turf to third-party developers like Netscape got them into trouble for abusing their monopoly on desktop operating systems.

Of course, today nobody can imagine operating systems without scripting languages or Web browsers. They’re fundamental features and both platform vendors and users benefit from the fact that they’re always available.

When deciding whether or not to add a third party feature to their platform, vendors have to do the math. Competing directly with popular developers costs them some good will with developers, but it also puts that feature in the hands of more users than any third party developer ever could. That, in turn, may help the growth of the platform.

For features that are infrastructure, making the feature part of the OS may in turn make life easier for other developers as well. For example, iCloud Documents clearly competes with Dropbox. For developers who want to be able to share documents through the cloud, iCloud is much more compelling than DropBox because every iOS user will have it. Adding iCloud Documents is a no brainer, no matter how unhappy Dropbox and its fans are about it. (For what it’s worth, I’m a huge fan of Dropbox and I expect that they’ll be fine.)

When it comes to other features that are more about convenience, the case is less clear. For example, Apple has added a new Reading List feature to Safari that enables users to store articles for later in an easy-to-read format. There’s already a wonderful third-party solution to this problem called Instapaper that Reading List competes with directly. The author of Instapaper, Marco Arment, publishes an excellent blog.

Reading List is something to brag about, but it doesn’t add anything fundamentally new that other iOS developers can build on. And it competes directly with a very, very popular third party iOS application. On the other hand, Instapaper is amazingly convenient and basically makes the concept of being bored while waiting in line obsolete. I’m sure Apple’s developers decided that the functionality was too great not to build into the platform. Why shouldn’t every iOS user have it?

This is the thing every third party developer has to worry about; will Apple or Google or Microsoft or whoever look at their application and decide that the core functionality should be built into the platform. More importantly, they have to figure out how to build a sustainable business in a world where that’s always a possibility.

In the end, I’m not entirely sure that this sort of competition is always bad for application developers. In 2007, Slate published a piece explaining why Starbucks was actually good for independent coffee shops. Starbucks teaches people to appreciate fancier coffee and soon discover that independent shops offer better coffee at a lower price than Starbucks does.

Instapaper is almost certainly already better than Reading List will be when it’s released, and even if it isn’t, Marco has a few months to make improvements that will make it better before iOS 5 is out. In the meantime, people who are intrigued by Reading List can go out and get Instapaper right now. In the future, people will try Reading List, and some of them may decide that they want the more powerful features Instapaper offers, just like Starbucks customers eventually try independent coffee shops.

So while Reading List can clearly be seen as a threat to Instapaper, it may also turn out to be the best thing that ever happened to it, depending on how Marco responds. And I’d say the same for many threatened applications.

The real worry isn’t fair competition, but rather the ability of platform vendors to make life harder for rivals. Platform vendors can use APIs that they don’t provide to third parties, and of course Apple can abuse the application review process in any number of ways to cut off third party developers. As customers, that’s where we need to be attentive. Adding a feature to Safari that competes with Instapaper is fair as far as I’m concerned. Later denying Instapaper access to the App Store because its functionality overlaps with a feature provided by Apple would not be.

Addendum: I should note that for a long time I was on the other side of this debate, and fiercely argued against platform vendors adding features to their platforms that cannibalized the work of third-party developers. What I realized was that this sort of thing is inevitable and often a positive for users. It’s not debatable that Microsoft creating Internet Explorer was good for end users and was of course great for the Web. Some of their business behavior was problematic and probably illegal, but Microsoft was completely right to go into the browser business.

How to handle logins in 2011

June 5, 2011 / Rafe / 0 Comments

Nelson Minar suggests the proper way to handle login names in Web applications:

The right way to do logins right now on the Web is use email address as the login name and let the user choose their own display name which does not need to be unique. That’s not ideal (email addresses can change) but it works pretty well. If you absolutely have to not use email as the login name, please at least let my login name have a space in it.

Seems reasonable to me.

Two opinions on the Groupon IPO

June 3, 2011 / Rafe / 4 Comments

David Heinemeier Hansson takes a look at the numbers behind the Groupon IPO:

At the moment, it’s costing them $1.43 to make $1, and it doesn’t look like it’s getting any cheaper. They’re already projected to make close to three billion dollars in revenues this year. If you can’t figure out how to make money on three billion in revenue, when exactly will the profit magic be found? Ten billion? Fifty billion?

On the other hand, Matthew Yglesias says that Groupon is an example of how to achieve growth through aggressive deficit spending:

Maybe this will work out, or maybe it will be a disaster. But it’s worth noting that absolutely nobody thinks it’s categorically absurd to think that what a firm needs to do to maximize long-term profits is boost spending over revenues.

It’s an interesting way to take a jab at critics of economic stimulus.

Update: Jason Kottke points out that Amazon.com operated at a loss for a long time before becoming the profit-generating machine that they are today.

On Google Chrome and other browsers

June 2, 2011 / Rafe / 0 Comments

Tim Bray wrote up the browsers he uses on a daily basis. Impressively, he uses Google Chrome, Firefox, and Safari consistently.

These days, I’m using Google Chrome for most things and Firefox for Web development. I’m hooked on Firebug and I like doing development in a browser that’s sequestered from the browser I’m using for email and standard Web surfing. Unfortunately, Firefox loses the basic speed test to Google Chrome, so I can’t use it for day to day browsing. If I were going to put up with a slower browser, I’d stick with Safari because it is a better behaved OS X application.

Like Majd Taby, I have various nits to pick with Google Chrome, but I’m using it for most everything these days. In the end, speed is the key. It renders Web pages very, very quickly. My biggest problem with it is that Google Chrome hangs a bit when you click on a link and then click on a different link on the same page in hopes of hijacking your original request and going somewhere else.

Until recently, I was using Safari for my day to day browsing. I love it as an application, but the speed difference with Google Chrome is noticeable enough to lure me away. I do still use Safari in a standalone Fluid app to read my work email (a Google Apps account) in its own application window with an unread email indicator in the dock.

It wouldn’t surprise me if Safari took another big leap forward soon and I went back to it. For whatever reason, I’ve found Firefox to be consistently uncompetitive with Google Chrome or Safari for a long time, but I’d be happy to use it for everything if they can catch up with the WebKit-based browsers.

Whenever I look at software markets with healthy competition, like the browser market, or the market for smart phone platforms, or the market for Web application platforms, I can’t help but think about the opportunity cost of the Microsoft desktop computing monopoly in the nineties. How much better would word processors and spreadsheets be had Microsoft had a real competitor for Office? How much better would desktop operating systems be had they faced real competition in that market?

Blogs so good you’d never link to them

June 1, 2011 / Rafe / 2 Comments

Here’s Patrick Nielsen Hayden on Ta-Nahesi Coates:

I don’t link to Coates as often as I’m tempted to because I assume most of our readers read him already. If you don’t, you should; his blog is one of the Great Works in our little genre, and as good now as it has ever been.

It occurred to me that there a number of blogs that are so good and so popular that I can’t imagine anyone spending their time reading this one and not reading those others as well or instead.

I just assume that everyone reads kottke.org and Andrew Sullivan. I think they remain at the top of the field. I’ve had my disagreements with Andrew Sullivan over the years in matters of both substance and tone, but I still think that in terms of volume and quality, his blog is hard to touch. Jason keeps mining interesting stuff on the Internet. Reading his blog will make you smarter.

Ta-Nahesi Coates’ blog is brilliantly written and incredibly thoughtful. James Fallows produces perhaps the most consistently interesting blog around on a day to day basis. There’s never a dud.

At this point, I assume that anyone who cares about politics and more importantly, policy, is reading Ezra Klein. There are a lot of good political blogs out there, and even some great ones, but his outshines them all. Matthew Yglesias‘ blog is worth reading daily for reasons that I’ll write about in a separate post at some point. Basically, he’s exploring some really interesting ideas that he’s fleshing out over an extended period of time that don’t fall neatly across established political lines.

Anyone who cares about Apple is, I assume, reading Daring Fireball and Asymco.

In the “not a blog” category, I read everything that Chris Adams shares in Google Reader. The blog posts he shares are as consistently interesting as any one blog I read.

Which blogs do you read that you assume everyone else reads as well?

Are movie theaters misdiagnosing their problems?

May 30, 2011 / Rafe / 2 Comments

Last week, Roger Ebert wrote a piece about the effect improperly operated projectors have on the movie viewing experience. Most of the time, when you go to the movies, the bulb in the projector is insufficiently bright, usually because movie theaters are too lazy or incompetent to configure their digital 3D projectors to project 2D movies properly. (3D movies are inherently less bright than 2D movies, it’s a drawback.) He also points out that improper projection goes back before digital movies, it’s a long term problem in the movie industry.

The decline of movie theaters is blamed on many things, usually the rise of home entertainment. It’s funny, though, this is an area where the market has a perverse effect. Movie theaters compete on the comfort of the seating, but not on the quality of projection. You never see an ad that says, “Brightest projector bulb in the city.” So people go to the movies and have a subpar experience because the picture is difficult to see and then choose to watch something on Netflix Instant or get a DVD from Red Box. Movie theaters don’t have a feedback loop to tell them that the real problem might be the bad job they’re doing operating the projectors.

His piece reminded me of an essay from Slate last year, on the vanishing of professional projectionists. As is often the case, removing skilled professionals from the equation seems economical, but there are also costs, and those costs are probably being lost in the noise.

Links for May 26

May 26, 2011 / Rafe / 6 Comments

How DRM may have made it more difficult for the Amazon.com MP3 store to fulfill orders for Lady Gaga’s album when they put it on sale.
The Affordable Care Act is increasing the number of people with health insurance.
“In matters of cooking, authenticity is a joke.” This statement is important and true.
Edouard de Pomaine’s tomatoes a la creme. Incredibly tasty and easy to make.
An explanation of Pivotal Tracker’s client-side architecture. These days, all of the advanced Web applications are client-server apps written using JavaScript and HTML instead of Visual Basic or PowerBuilder.
Tim Bray thinks about what may happen to our stuff when we’re gone.
The Cassiopeia Project is a library of free science instruction videos. Funded by a retired scientist who wants to improve the quality of science education.
Journalists appear to be noticing that Republican politicians and pundits are not engaging with reality. Hopefully it’s the start of a trend.
The New York Times explains the lengths to which hotels must go to protect their staff from guests. Depressing.
Researchers find that cultured people feel less stress. Perhaps you’d enjoy a trip to a museum this weekend.

On the misuse of Occam’s Razor

May 23, 2011 / Rafe / 3 Comments

This weekend I read an interesting post about Occam’s Razor but decided not to blog about it, until I came across someone misusing Occam’s Razor and couldn’t suppress the need to clear my throat. In a post about digital camera pricing, I read the following sentence:

Occam’s Razor tells us that the simplest answer is the most likely one.

This is not correct. Here’s how Wikipedia defines Occam’s razor:

Occam’s razor, often expressed in Latin as the lex parsimoniae, translating to law of parsimony, law of economy or law of succinctness, is a principle that generally recommends selecting the competing hypothesis that makes the fewest new assumptions, when the hypotheses are equal in other respects.

The important part of the sentence is not about simplicity, but about selecting a hypothesis. When you’re trying to figure out which explanation for something you’ve observed is correct, the best approach is to test the hypothesis that you can eliminate most quickly. This has nothing to do with the fact that the simplest answer is probably correct, but rather that it makes sense to start with the possibilities that are easiest to eliminate.

This is particularly relevant to scientific experimentation, but it applies to problem solving in general. When you find a bug in your application, Occam’s razor would suggest that it makes sense to start by examining the code you just wrote yourself rather than checking Google to see whether there’s a bug in MySQL that has suddenly manifested itself and caused the incorrect behavior.

Blaming your own code requires only one new assumption — that you made a mistake when you were writing code that has yet been tested. Blaming MySQL requires you to assume that there is a bug in MySQL that has not been fixed or perhaps even detected and that your code (which is theoretically correct) somehow causes this bug to manifest itself. Perhaps to you, looking at your own code first may seem blindingly obvious, but to many developers it is not.

The point here is that Occam’s razor is a tool for problem solving (or experiment design), not a short cut that lets us skip problem solving entirely. In many cases, the simplest explanation is not correct, but it’s hard to be sure until you’ve eliminated it as a possible explanation.

rc3.org

Strong opinions, weakly held