Andy Baio interviews the creator of Telehacks
0

Andy Baio interviews the creator of Telehacks

Telehack embodies everything I loved about the eighties. It’s a game that simulates a dialup session with a remote computer through a command line interface. From there you can “wardial” and explore other computers on the network. If you, like me, became totally fascinated with modems after watching WarGames, you must visit Telehack immediately.

Andy Baio has the details on the breath of the game (awe-inspiring) and an interview with its anonymous creator.

Anyway, on the off chance that Forbin reads this, he should know that the game is a masterpiece.

Links for June 12
1

Links for June 12

Jumping in:

  • Did you know that many people are released from prison owing a debt to the state for things like court fees and charges for public defenders? Our criminal justice system is intentionally cruel in so many ways.
  • And speaking of the criminal justice system, people who benefit financially from incarcerating massive numbers of people are generally in favor of maintaining and expanding the systems that put people in jail, even unnecessarily. The League of Ordinary Gentlemen looks at how the prison guards’ union has gained influence in California and the quality of prisons has gotten worse. This is a great piece of blog writing.
  • This is the sort of libertarian philosophy I agree with. The fair price of goods should include the negative externalities of their use.
  • The description of now-more-than-everism is useful, and not just for politics. I’ve certainly seen it plenty of times on engineering teams, and probably have practiced it more times than I’d care to admit.
  • James Governor talks about the advantages of giving engineers some responsibility for communicating with the public. Probably the smartest blog post I read last week.
  • Anil Dash explains how he uses the favorite and like features on social sites.
Links for June 10
0

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
0

Getting bug fixes into the pipeline

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
6

When platform vendors attack

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
0

How to handle logins in 2011

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
4

Two opinions on the Groupon IPO

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
0

On Google Chrome and other browsers

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
2

Blogs so good you’d never link to them

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?