1. Aug 28th, 2008

    Rounded Corners 216 – Hug a developer

     

    We can predict the future. Once it happened. From the exaggerated rumors of Steve Job’s demise:

    (IF STOCK DROPS): The decline is no surprise to investors and analysts, many of whom considered Jobs irreplaceable. Gene Munster of Piper Jaffray & Co. in Minneapolis had said if Jobs left the company for any reason, Apples stock might plummet as much as 25%.

    Speaking of telling the future once it happened …

    XMPP stock down 25%. From beyond REST we learned that the failure of FriendFeed to poll Flickr for updates is best solved by switching to XMPP. From FriendFeed we learned that the solution is just a smarter feed. I’m going to make a prediction that:

    (IF SUP WORKS): The ability to scale REST is no surprise to developers and pundits, many of whom consider REST irreplaceable.

    I also have a contra prediction lined up, just in case the other hindsight proves right, in which case I’ll just categorize the entire thing as a “streaming problem”, for which we know XMPP is a damn good protocol. Always be prepared.

    But does it scale? Unfortunately, Ruby developers don’t.

    Getting around one bottleneck. I managed to shorten my tab list to three (keeps Firefox happy) by saving everything else with Read It Later. I still have a bottleneck reading/blogging through that list, but at least it’s no longer crowding my tabs. Give it a try.

    Pound per dollar. How do you change the perception that bigger is better?

    In a sign of today’s ecoconsciousness, almost every student asked about the Peugeot’s fuel economy. Most were unimpressed that the 207RC’s direct-injection, turbocharged, 172-hp, 1.6-liter four-cylinder manages an average of about 30 mpg in a mix of city and highway driving. As foremost as economy seemed to be, many of the students also said that the 207 (and most European cars) was too small for their taste. Two seemingly contradictory demands kept popping up: the need for lots of interior space, plus the desire for good fuel economy.

    Above, hug a developer. Via Mark Blomsma.

    1. Aug 28th, 2008

      al3x

      “a “streaming problem”, for which we know XMPP is a damn good protocol”. Do we really now? Perhaps we should have words about this, sir.

    2. Aug 28th, 2008

      Assaf

      (IF XMPP FAILS): The failure was no surprise to developers who realized the complexity of the stack, or were aware that it has only been field tested with non-demanding applications like instant messaging. Al3x of Twitter Co. said, “Perhaps we should have words about this, sir.”

    3. Aug 29th, 2008

      Rhett

      Re: Read it later. I use a service called Instapaper ( http://www.instapaper.com/ ) which uses a javascript bookmarklet to mark pages for later reading. It doesn’t have as many features on the record side as that Firefox plugin, but it does have a paired iPhone application. The application syncs to your Instapaper account and downloads the pages to your phone for later offline reading. Pretty cool.

    4. Aug 29th, 2008

      Assaf

      I’ll give instapaper a try.

    5. Aug 30th, 2008

      Bill de hOra

      XMPP won’t fail for basic point to point messaging, but the idea of a link to a feed of etags gives new weight to HATEOS. You can read this as the sky’s not falling in (again), or another hack that gets us a Four More Years.

      Where XMPP is operationally hard is when you have a lot of clients (50,000+). HTTP LBs don’t work well for that at all, and become bottlenecks on open connections. The only answer seems to be to get said LBs off the path. Which puts us back to about 1996, the web’s stone age, and begs the question – how to tell a client to bind to a node in the cluster without pushing load balancing logic down to the client and exposing your server topology? DNS SRV isn’t the complete answer; good for federations, not so much for clustering. Also even if you could figure out binding, the XMPP stacks themselves don’t seem to have clustering entirely figured out (openfire and djabberd possibly being further along there). I’ve been surprised at where some highly performant servers start to buckle.

      And here’s the kicker – if a cluster communications swarm doesn’t kill you, the database writes quickly start to dominate how many people can connect, and well before sockets management does. All the stacks I’ve seen are writing on connection (to setup presence and sessions). So, Yet Another Database Scaling Problem, and around we go.

    6. Aug 31st, 2008

      Assaf

      Sky is not falling. I’m not a believer in OneTrueArch, constraints are there for a reason, which means some things are impossible (or unwarranted) by design. But it’s reaffirming that by following REST — which means hypermedia, not the Four Verbs — we got more done under the HTTP pub/sub architecture.

      It always comes back to the database, doesn’t it?

      I thought XMPP allows you to hold session/presence in memory. If you go down, you just re-establish the session and ask for presence information again. Not so?

    7. Oct 2nd, 2008

      Geoffrey O’Brien

      [...] Hug A Developer No Comments so far Leave a comment RSS feed for comments on this post. TrackBack URI Leave a comment Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> [...]

    8. Jan 16th, 2009

      Guignol

      The application syncs to your Instapaper account and downloads the pages to your phone for later offline reading.

    Your comment, here ⇓