Author Archives

Business — Comments Off
19
Sep 11

Netflix vs. Qwikster

Today Netflix announced the formal division of its business into two separate businesses, Netflix (streaming) and Qwikster (DVDs by mail). When Netflix originally announced its pricing plan changes in July, I suggested that this could be the inevitable outcome. But what’s next for Netflix? Following the separation to its logical conclusion, Netflix could spin off Qwikster into its own separate company, with no remaining ties to Netflix. Alternatively, they could create a tracking stock, allowing private or public investment in just one of the two businesses (this is most often done for the high-growth subsidiary). Or Netflix could retain the Qwikster brand, with its own management team, and that team could focus on ways to grow the DVD business (which, IMHO, is in an inevitable decline).

The action to take depends on Netflix’s corporate strategy and goals. I speculate that Netflix is attempting to become a streaming-only business, with no DVD operations to consider when negotiating for content streaming contracts. I also suspect that, if Netflix looked at its customer behavior data, they’d discover that people stream different content than they request on DVD. So, as Netflix separates itself from the DVD business, they will attempt to acquire different content libraries entirely, not just different content streaming terms.

So what content are people streaming? To answer that, let’s look at two separate indicators of actual user behavior: InstaWatcher, which offers an advanced searching/sorting interface to the Netflix instant queue, and the Pirate Bay, possibly the best-known source for finding a Bittorrent (peer-to-peer) file sharing cloud. Neither of these sites distributes content, but both make it easier for users to find the content they want and start downloading it.

InstaWatcher tracks which content users add to their queues via the site (or begin playing via the site). The most popular content since the site started tracking statistics in March 2009 are overwhelmingly movies (Mad Men season 1 creeps into the lineup at number 38). And virtually any way you view the InstaWatcher stats on most popular content, movies top the list.

The Pirate Bay, on the other hand, tracks the most torrented content — a good indicator of what people will choose to watch when they don’t restrict themselves to readily-available content (i.e., in Netflix’s library or via on-demand streaming from a cable/television service like Comcast or Verizon FiOS). And here, the data shows a different story: following 9 movies (including new DVD releases like Thor and the as-yet-unreleased Rise of the Planet of the Apes), the 10th most popular torrent is WWE Night of Champions, followed by the Vampire Diaries season 3. True Blood season 4 follows shortly behind.

And this is before most of the new fall television season premiers (the major networks start premiering this week and next).

The Pirate Bay’s “top 100″ list has a much more dramatic recency bias than InstaWatcher, whose “most popular” listing considers all activity since March 15, 2009. Taken together, this suggests a trend: people are starting to stream content they otherwise would have watched on television, as shorter shows (hour-long dramas and 30-minute sitcoms). This makes sense, because these shorter shows are shows of convenience, things you watch when you have an hour or 90 minutes free. Watching a 2- or 3-hour movie on a DVD takes a bit more advance planning.

So what does this mean for Netflix? It means that, if I were Netflix, I wouldn’t be overly worried about losing the Starz content (which was Netflix’s largest source of movies), and I’d be more concerned about working deals with TV content providers to “syndicate” entire seasons of popular shows. I’d be negotiating for True Blood, Weeds, the Sopranos, and other premium content people can watch a show at a time. And I’d be thinking about doing deals to finance the production of television shows, by going directly to studios. Warner Brothers studios, which produces popular shows like The Big Bang Theory and the Vampire Diaries, comes to mind; so does the BBC, which produced Coupling, the forerunner to Friends, and Doctor Who, whose re-imagined series enjoys surprisingly mainstream popularity. And I might consider working with Hulu to offer new network television via Netflix streaming.

Whatever Netflix does, the next year or two will be fascinating to watch, and I suspect Netflix will be at the forefront of the evolution of streaming media for years to come.

TwitterFacebookLinkedInXINGViadeoRedditDiggEmailShare
Business — Comments Off
14
Jul 11

Some Reflections on the Netflix Pricing Foofaraw

This week I’ve seen three general reactions to the recent announcement by Netflix that their “DVD + streaming for $9.99″ plan will be replaced by two separate plans totaling $15.98. The first was summed up neatly by one of my Facebook friends:”Netflix just jacked our monthly price up by 50%. Time to cancel. Jerks.” The second places the blame squarely on Comcast, or Hollywood, or the MPAA, or the RIAA, or whoever it is that makes movies cost so much to begin with. And the third points out that the combined price for these services is actually less than you would have paid for the same service from the same company several years ago (if only Netflix had then offered streaming at today’s prices).

These are all interesting perspectives, and they all have some truth to them, but what everyone’s missing is this: it’s too early to tell whether this is a brilliant business move by Netflix, or the beginning of a very long end.

In 2006 a similar calculus was going on at AOL. I was part of a team that provided executives, marketing, and operations a somewhat independent view of how client operations were running – were people able to connect, could they stay connected, and how engaged were they with the service? These were the sorts of questions we answered. There had been a long trend toward customers connecting by what we termed “third party transport” – AOL-speak for any internet connection we didn’t provide, usually broadband – and this worried executives. After all, AOL was still very much a dial-up access provider, and the loss of a core part of the business would be a critical blow to the company.

But other parts of AOL relied on the rapid uptake of broadband across the U.S. (notably, AOL’s short-lived VoIP program). So very quickly there were at least two AOLs: one dedicated to the largest dialup network on the planet (at $23.90 a month) and one trying to cram as much content down the pipe as possible. The conflict was obvious and inevitable.

Eventually, AOL did the unthinkable: it raised prices – while hemorrhaging customers – on its core dialup product, from $23.90 to $25.90. This made a lot of people angry and was widely regarded as a bad move (with sincere apologies to Douglas). But it had an interesting effect: it pushed those people teetering on the edge of dialup versus broadband away from dialup, and left AOL with a core group of customers who would not be dissuaded from using their modem at any cost. Later, when AOL sought to break itself into different companies and sell off the pieces, any potential acquirer of the dial-up business could count on a known, stable customer base as part of the acquisition.

Today, Netflix is two separate businesses with two completely separate supply chains, controlled by entirely separate contract vehicles. They are a DVD rental company that shuttles disks through the US Postal Service to their customers. They are also a streaming service. The growth of one hurts the other; there are only so many television watching hours per person in the market they serve (this is similar to Coca-Cola’s idea of “stomach share”).

Is Netflix preparing to sell off its DVD business entirely? Or spin it off as a separate company? I don’t know, but if they did, they’d leave behind a leaner, hungrier company with a singular focus. And they might come out of it with a large enough chunk of cash to placate the Hollywood studios, Comcast executives, or RIAA trolls.

As for me: I’m keeping my Netflix account (streaming only, thanks).

TwitterFacebookLinkedInXINGViadeoRedditDiggEmailShare
Architecture — Comments Off
5
Jul 11

The Mobile Experience – Mobile Layouts With Rails

So, you have this great web app and you’re targeting mobile users (for our purposes, this means Android, iOS, and anything small/hand-held with a full browser and a touch screen). How do you make sure your app is usable on small, hand-held devices?

There are a number of interface strategies, including:

  1. Design only for mobile, and particularly the phone (iPhone/Android phone only).
  2. Design for desktop only, and assume mobile users will zoom as needed.
  3. Design separately for mobile and desktop, and figure out which interface to use somehow.

and there are permutations here based on whether you want to have a different experience on tablets versus phones, tablets versus desktops, Android vs. iOS vs. Blackberry, and so on.

For our system, we’re starting small – designing for iPhone – and scaling up to the tablet and desktop as we go. This will allow us to make sure the interface really works when all you have is your phone. We’ll test the app on both the iOS simulator and the Android SDK simulator on several versions of Android and the two latest iOS, and again in various Desktop browsers (Safari, Chrome, Firefox, and some reasonably intelligent version of Internet Explorer – just as soon as Microsoft releases one).

For our initial purposes, we need different layouts for both desktop and mobile. So we need to figure out how to serve mobile differently. Again, there are a couple different strategies:

  1. User-agent testing on the server-side (check HTTP_USER_AGENT or its equivalent).
  2. User-agent testing on the client-side, via JavaScript and DOM manipulation.
  3. User-agent testing on the client-side, via specialized CSS calls. A List Apart has a great explanation of how this is done.

#2 and #3 both seem overly complicated to me. For now, we’re going with sniffing the user-agent string. The strategy for implementing this in Rails is to do something like this:

# app/controllers/application_controller.rb
before_filter :check_layout

def check_layout
case params["layout"]
when "mobile" then session[:layout] = "mobile"
when "full" then session[:layout] = "full"
when nil then
  session[:layout] = ua_is_mobile ? "mobile" : "full"
else session[:layout] = "full"
end
end

def ua_is_mobile
uastring =
  request.env["HTTP_USER_AGENT"].downcase rescue nil
# you could check several patterns here
return true if uastring =~ /mobile/
return false
end

and then you can either use layout :mobile or the default layout depending on the value of session[:layout]. In our case we have separate layout files entirely, which reduces the number of if statements in the layout. We can then DRY up the layouts using shared partials and helpers. I also seek to minimize repetition in the views by having view snippets be device agnostic, and leaving it to CSS to make things look right for mobile.

Alright then, so that works just fine, but how do we test it? A major problem we run into is in making sure the right layout is rendered for the right user agent. You have to adjust your test to pass in the right user-agent string:

# test/functional/users_controller_test.rb

  test "should detect mobile" do
    @request.env["HTTP_USER_AGENT"] = "Mozilla/5.0 " +
      "(iPhone; U; CPU like Mac OS X; en) AppleWebKit/420" +
      "+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a " +
      "Safari/419.3"
    get :index
    assert_template :layout => "application.mobile"
  end

which will assert the appropriate layout is used. See the description of assert_template for more goodies.

TwitterFacebookLinkedInXINGViadeoRedditDiggEmailShare
Technical — Comments Off
9
May 11

Full Circle: the Return of Client Server

Once upon a time, I wrote simple client server applications in Visual Basic (VB3!) with an Oracle database back-end. My government client, who dictated requirements to me by reading DOS Clipper code aloud, was mystified by the whole client-server revolution, and impressed at what we could get done by leveraging the desktop computer to do some of the number-crunching required for this system. It turns out that, since everyone had increasing amounts of CPU power on their desktop, this newfangled client-server thing meant reduced costs in owning and maintaining mainframe server assets (which, in most cases, could be pushed off the nearest cliff).

This was the mid 1990s, and the government was finally catching on to this whole client-server thing. But the web revolution was brewing, and the hottest new language, Java was about to change everything. You see, client-server solved a lot of problems, but introduced a new one: version inconsistencies in the client could break your server. This meant paying strict attention to Progressive Enhancement, that paradigm in which each new change is magically backwards-compatible (or, at a minimum, wouldn’t break things for people on older clients).

With Java, though, this didn’t matter: since the applet actually lived on the server and was distributed via the web, each client would download the latest version of the software at the start of every session. But what about the server? In the database, subsequent enhancements to the data model have to be done in a way that prevents corruption or integrity problems in the existing data. So we still had to obey the Gods of Progressive Enhancement, lest the whole thing come crashing down around our heads.

Eventually, the N-tier system won out, and today we have the familiar architecture of browser (view-only client), web server/app server (functional/procedural business logic), and database (data storage and integrity rules), with other services thrown in as needed (server-side observers/notifiers, periodic taskings, etc.). The so-called Services Oriented Architecture can be thought of as a bunch of highly promiscuous application servers existing in a series of XML-over-http-wrapped cocoons. It’s still N-tier, but N is a really high number indeed.

Throughout all of this, the paradigm of Progressive Enhancement remained: there’s always *something* out there relying on your service continuing to meet the contracts you established when you published the service. There’s a reason that features are deprecated long before they are removed. And there’s a reason why languages and platforms are pilloried for breaking older code (I’m looking at you PHP 5.3, and you, Python 3, and I just don’t even want to look at Facebook).

So then there’s this post by Nick Morgan suggesting the end of Progressive Enhancement may be near, at least for JavaScript. Interestingly, it’s occasioned by a bit of history repeating itself; what’s happening now is that JavaScript is increasingly becoming a tool for building an independent client application that just happens to be deployed by the browser. If you don’t believe that’s really happening, then try updating your resume on Monster.com while you have JavaScript turned off. I’m betting you won’t get past the login prompt.

So, with JavaScript, we’re working our way back to the way things were under Java. Everyone gets the latest app! Only, they don’t all have the same runtime environment, so now our applet has to check for browser versions and behave differently in each one … sound familiar? We know how this ended for Java – with a move to well-controlled server VRE (and the slightly less well-controlled Android SDK) and eventual deprecation in the browser by Google (who recently disabled Java by default) and Apple (who gave up maintaining their own Java VRE).

One possible path for JavaScript, which I agree is essential to the current web experience, is that changes to the JavaScript, HTML, CSS and to browsers will make it possible to write your app DRYly, rendering HTML in exactly one spot, while exposing a JSON or JSON-like API for JavaScript clients. And another possibility is that the rise in mobile devices may make JavaScript irrelevant. The web server would then exist as a glorified API, spitting out HTML for web-based apps and JSON (or maybe Objective-C Object Notation, or Python Object Notation?) for use in mobile devices.

TwitterFacebookLinkedInXINGViadeoRedditDiggEmailShare
Technical — Comments Off
30
Apr 11

Dear Git, Please Give Me Uncluttered Sparse Checkout

Dear Git project,

We really need a working, uncluttered sparse checkout feature. With Subversion, CVS, and numerous other version control systems, I used to be able to store multiple subprojects in a single large repository, so I’d have a setup like this:

foo-incorporated/
→foo.com/ # Foo's web site
→app1.foo.com/ # rails app
→app2.foo.com/ # some other app

which would allow me to build a single system composed of multiple related apps, guarantee the relative directory structure of those apps, and then publish to production with a single command. I could also decide to work just on an app:

svn checkout /svn/foo-incorporated/app1.foo.com/trunk app1.foo.com

and put that working copy in my local web-served directory (~/Sites on Mac OS X), and then access http://localhost/~me/app1.foo.com to see my running app.

With git, however, if I want the same workflow, I have to maintain foo.com, app1, and app2 in separate repositories entirely, or else the local URL becomes http://localhost/~me/foo-incorporated/app1.foo.com. Then, when I want to work on app1 I have to descend an extra directory level to get there. It also means I can’t easily rely on objects defined externally. I could use git submodules, but that would require maintaining a “collector” repository with nothing but submodule definitions alongside the separate repositories for each subproject.

This gets really bad when projects get large but are still related. Then git’s sparse checkout could give me several levels of depth before I get to the one small piece of a project I really care about. The git solution seems to be to create new repositories to solve this problem, but it’s really much simpler to deal with a profusion of folders in a hierarchy than it is to deal with a profusion of repositories.

I’m really missing the strict separation between working copies and repositories that I had with Subversion and CVS. Please let me have it back.

Thanks,

Scott

TwitterFacebookLinkedInXINGViadeoRedditDiggEmailShare
Technical — 2 Comments
16
Apr 11

Signup Form Woes (with thanks to Jim of NY)

Good news: ResumeEverywhere was mentioned in US News & World Report’s article 8 New Websites for Your Resume. Bad news: the signup form failed to, well, do anything at all.

Someone (Jim, of NY) noticed the issue and commented about it. I’ve now fixed it, by axing the offending Ajax calls. So, thanks to Jim (who I’m pretty sure is @HRNewsFeeds on Twitter).

Two important questions remain – first, what was the actual root of the problem? I don’t know right now; it was faster to remove the offending script than to analyze it. Analysis will wait until next week. Second, why did it occur on the live site, and not in our testing prior to deploying the script? This is an excellent question, as I’m convinced the signup form was working on the live site when it was deployed in February. So something must have changed since then. FRIN.

Apologies to anyone out there who found us, tried to sign up, and then gave up when the sign-up form failed. I hope you’ll consider giving ResumeEverywhere another chance.

TwitterFacebookLinkedInXINGViadeoRedditDiggEmailShare
Architecture / Design / Technical — Comments Off
8
Apr 11

Why We’re Using Ruby on Rails

Because it’s faster to get started. Also we’ll probably be able to keep my work once we hire the next person.

Really, it’s that simple. The web framework decision tree is surprisingly straightforward, assuming you even need a framework at all. For our purposes at Resume Everywhere, we’re building a multi-user transactional application that helps track things, their states, and their attributes through a workflow. Most of the critical data is highly structured and can be expressed easily in a normalized database. We want the app to be accessible via the web (in a browser) and feature a RESTful API.

This screams Model-View-Controller (as do most transactional web apps). A good framework will provide RESTful routing resources and make it easy to dummy up views and manage a database.

Aside from Ruby on Rails, there are dozens of web-based MVC frameworks. So why Rails? When it comes down to it, of all the possibilities, it’s the one I know the best, and it’s my problem to solve. This means I can be productive with it from day 1. And it’s easy enough to find people who know the framework – and may know it better than I do – that when we add someone else to the team, they should be able to make progress right away. In other words, using Rails reduces the intellectual start-up costs.

That’s a pretty shallow (if accurate) assessment.  But using Rails is a good choice for a couple other reasons:

  1. RESTful API out of thed box (or nearly so) using respond_to do |format| blocks.
  2. Use of convention in place of configuration means I spend less time configuring things at the outset (although this might come back to bite us later).
  3. Rapid deployment via Capistrano, which is surprisingly easy to set up.
  4. Rapid develop-test cycle: make a change, reload a browser window. This means code gets written in small, testable chunks that work right the first time.
  5. Existing libraries for oAuth, OpenID, RESTful authentication, and just about anything you might need.

Not that other frameworks or languages don’t offer these advantages (they do). But we only need the framework to be “good enough” on the critical points. Actually, the respond_to do |format| and routes together get us much of the way toward a workable API with almost no effort on the programmer’s (i.e., me) part. I’m all about judicious use of laziness.

TwitterFacebookLinkedInXINGViadeoRedditDiggEmailShare