Joseph Smarr

Thoughts on web development, tech, and life.

Category: Web development (page 2 of 3)

Implementing Open Social Web support on your site (Future of Web Apps Miami)

Implementing Open Social Web support on your site
Future of Web Apps Miami (workshop)
Miami, FL
February 28, 2008

Download PPT (3.8 MB)

I was invited to give a workshop and be on a panel at the Future of Web Apps in Miami. I attended the first FOWA in SF in 2006, and I really enjoyed it, so it was fun to get to be on stage this time. I’d never done a long workshop before, but I love talking about Open Social Web technologies, so I basically went through all of the various building blocks (OpenID, OAuth, microformats, OpenSocial, Social Graph API, friends-list portability, URLs as identifiers, etc.) and wrapped it in some high-level context about the emergence of a Social Web. The audience was very lively and engaged, and they asked a ton of great questions. So I was very happy with how it all worked out. These are the slides from my workshop; they’re a bit light since I was mainly using them as a reference to talk over. But hopefully they provide some useful jumping-off points to learn more.

I also gave a presentation on the main stage about the future of social networks with Tantek and Brian Oberkirch. Brian made the slides, which hopefully he’ll post too. My piece of the talk was called “Open for business” and it was about how being open can be good for your company, because it lowers friction to signing up and sharing, and it makes you a more relevant part of the online ecosystem. I showed demos of how you can sign up for Plaxo with an OpenID and pre-fill your registration info, discover and auto-suggest sites to add to Pulse using Google’s Social Graph API, and express yourself in new ways using OpenSocial gadgets. I think it helped the audience see that these open technologies aren’t just a cool idea, you can actually implement them today, as we have, and they work well enough to benefit mainstream users.

After the conference, there was a beach party at Nikki beach, and on Saturday, a bunch of us went with Leah Culver and Kevin Rose to attend the first Pownce Brunch to meet fellow users. We even managed to sneak in a little shopping and some beach volleyball. But of course we were talking about code and startups the entire time, since we all tend to lack that so-called “work-life balance”. :) Another highlight for me was meeting Gary Vaynerchuk, the star of Wine Library TV. I’m surprised I’d never heard of him (since I’m into both wine and disruptive technologies), and he was super cool and friendly and is clearly having a major impact. He taped an episode of his show live at FOWA, and he and Kevin and I even came up with an idea for a side project that we may try to spin up sometime…

I returned home late Saturday night (thanks to Pete for picking me up!) and tomorrow I’m back on the road: GSP, MIX, and SXSW. Gotta keep spreading the good word!

OpenIDDevCamp was hack-tastic!

DSCN5744I spent the weekend in SF at OpenIDDevCamp, hosted at SixApart’s offices. In the style of BarCamp and iPhoneDevCamp, the idea was just to get a lot of people together who were interested in OpenID, provide the space and amenities for them to work together, and let them loose. About 30-40 people showed up, including Brad Fitzpatrick, Scott Kveton, Tantek (with blinking wheels on his shoes), Chris Messina, David Recordon, Christopher Allen, John Bradley, Luke Shepard, and many more.

DSCN5748Over the course of the weekend, I got OpenID 2.0 relying party support deployed on Plaxo, and we found and fixed a bunch of little bugs along the way. You can now use directed identity (e.g. just type in “myopenid.com” as your OpenID and sign in on their side), and you can even use iNames (e.g. I can now sign in with =joseph.smarr). Thanks again to my hacker friend Michael Krelin, who did most of the hard work, and to John Bradley of ooTao for helping me figure out the subtleties of making iNames work properly. David Recordon and I also developed a firm spec for combining OpenID and OAuth into a single OP round-trip–it turns out it’s easier than we thought/feared; write-up to follow shortly. And Chris, David, and I came to a clear consensus on best practices for “remember me on this computer” behavior for OpenID RPs, which I’ll try to write up soon as well.

DSCN5747There was also a lot of great discussion about the future of OpenID, OAuth, microformats, and related technologies, as well as some lively debate on data portability (as you might expect). A personal highlight for me was when Christopher Allen (a co-inventor of SSL) regaled us with tales of how crazy and uncertain the process was to get Microsoft, Netscape, and the other big players at the time to all agree on a common set of principles that laid the groundwork for the development of SSL, which we now take for granted as an essential open web standard. It felt a lot like what’s going on right now in the social web, and the outcome there is an inspirational example to follow.

I’ve said it before and I’ll say it again–I love living and working in Silicon Valley with so many smart, energetic, passionate, and fundamentally nice and optimistic people. To wit: I just gave up a perfectly good weekend so I could stay up past midnight writing code and learning the finer points of XRI resolution, and it felt great! :)

PS: If you eat at Brickhouse cafe, I recommend the “half ass burger”–it’s just the right size. 😉

OpenSocial and Plaxo: What a week!

Wow, I’m exhausted, but incredibly happy! I’ve been working insane hours all week to get Google’s just-announced OpenSocial APIs implemented in Plaxo Pulse and launched live by the time of their announcement. And we did it! We released full support Thursday night, making Plaxo the first site to publicly implement OpenSocial. Yay!

I only found out about OpenSocial less than a month ago (I was on vacation in France when the initial disclosure event took place, but Marc Canter brokered an introduction when I got back; Thanks, Marc!). And the project inside Google was being developed fast and furious the whole time, which meant the specs were in a constant state of flux and there wasn’t a lot of time for such frivolities as “documentation” or “Q&A sessions”.

Actually I think it was a wise and bold choice by Google to run so fast and loose, rather than doing a more traditional big consortium with frozen specs and tons of details that would never have hit the mark in time. But it made the race to get things working in Plaxo all the more chaotic and exciting. The good news is when you’re dealing with known open standards like JavaScript and HTTP, you can pretty much always figure out what’s going on and devise some working solution, even if it involves some judicious use of proxies, mod_rewrite, and regular expressions (which, trust me, it did).

The launch of OpenSocial itself went better than anyone could have possibly planned. After spending several weeks under strict NDA and not even being able to know who the other container or gadget developers were, we were all a bit dismayed when a New York Times writer did enough digging to leak most of the story a few days early. Google decided that rather than try to keep the lid on any longer, they would release the embargoes early, so starting Tuesday night there was an explosion of public excitement in the press and blogosphere. The reaction was overwhelmingly positive, and by the next day the story got even more exciting: MySpace, Bebo, and SixApart joined as last-minute partners (previously there were several social networks agreeing to support OpenSocial, but none as big as these new entrants). Suddenly it looked like the whole world was going open (save, of course, for Facebook). This led to yet another round of frenzied reporting, which in turn made the OpenSocial announcement even bigger.

Since Plaxo was listed as one of the original supporting partner sites, all of these stories mentioned Plaxo, which means I could track them all in Bloglines via the Plaxo keyword search feed. This was like having a little web beacon plugged into all the stories posted everywhere, and it was just amazing to see how many different publications wanted to cover it. Bloglines (which I love) has this annoying feature that it won’t keep more than 200 unread items per feed. Normally the Plaxo feed gets 10-20 hits per day. Since Tuesday night, I had to check it every couple of hours or it passed the 200 mark. And, perhaps not surprisingly, our traffic at Plaxo also shot through the roof after the announcement went out.

Despite the early leak, Google kept its internal launch schedule the same. On Thursday night, I was invited to Campfire One: a small, invite-only gathering of some of the key developers participating in the launch. They actually built a campfire in the middle of Google’s campus and gave us all folding chairs, blankets, mugs of hot cocoa, and long marshmallow roasting forks to make s’mores with. They made a series of presentations on OpenSocial, showed demos of it working in sites like Hi5 and LinkedIn, and showed off popular gadgets like iLike and Flixster. Then they told everyone to roast marshmallows and mingle. To my surprise, I ended up next to Larry Page and Eric Schmidt standing around one of the fires. I was very impressed that not only had they showed up to this event, they totally got the vision for the open social web and were excited about seeing it develop further!

This was the first time I’d met many of the other participants in the OpenSocial project, so it was great to finally “step out of the dark” and be able to talk openly with them all about working together. I told everyone that Plaxo was planning to launch our OpenSocial support live right after the campfire ended, which became a source of much talk and excitement. Apparently all the other sites had just gotten internal demos running, but none of them had plans to go live until things settled down a bit and got more stable, say late ’07 or early ’08. The Google team said they had a spreadsheet a mile long of changes they planned to make in the short term, but if I didn’t mind fixing things as they broke, they were thrilled to have a real implementation available for people to play with. When Larry brought his marshmallows over share with some of the other Googlers (including Sergey Brin, whom I also hadn’t seen earlier), he exclaimed “hey, those Plaxo guys are launching OpenSocial support tonight!,” so I felt confident that the extra work required to launch support so early was well worth it.

The official launch of OpenSocial brought yet another round of press frenzy, and the fact that Plaxo was the first site to go live with support became a story itself. We were already planning to have a party on Friday afternoon to celebrate getting the code live, but we decided at the last minute to open the party to the public and use it to give a public demo of OpenSocial running live in Plaxo. We posted the invitation to our OpenSocial “Open Social” on Thursday afternoon and on Friday at 4pm we had about 100 guests at Plaxo HQ with whom to share some pizza, beer, and talk of the open social web.

I talked a bit about Plaxo’s commitment to helping open up the social web in general (such as our support of OpenID and microformats, our Online Identity Consolidator, the Bill of Rights I co-authored, and plans for enabling friends-list portability) and then dove into a demo of OpenSocial gadgets running in Pulse. The first thing everybody saw was a bunch of RockYou emotes in the normal pulse stream–they were generated by the OpenSocial gadget, posted through the standard APIs, and then translated by Plaxo into a pulse feed and shared out just like you would with photos, your blog, or anything else that came from a social web site. (Raymond and Jia from RockYou both came over to Plaxo and stayed up late to make sure our container implementation was solid and that their apps ran well on Plaxo. Thanks guys, that was a huge help, and everyone in the office can’t stop playing with emote now, heh!)

opensocial-topfriends-in-plaxo-pulseI then showed a bunch of gadgets running in my Pulse profile page, including horoscope, iLike, and Slide’s FunWall and TopFriends, both of which are impressively sophisticated apps, and among the most popular apps on Facebook. I met Slide’s CTO Jeremiah Robinson at the campfire, and he was eager to make sure his apps ran well on Plaxo. After a bit of back-and-forth IMing and tweaking on Friday, they all ran beautifully–a testament to the well-executed design of OpenSocial!

It’s amazing to think that less than 24 hours after launching this major new platform, not only is it running live in Plaxo, we already have several first-class gadgets from top developers like RockYou and Slide. If Plaxo had tried to build our own proprietary platform, we could never have successfully wooed these developers to build exclusively for us, let alone had things up and running this quickly. That’s why open always wins, and that’s why we love open standards at Plaxo.

This is just the beginning–there’s so much more to do to truly open up the social web. But OpenSocial is a huge milestone, not only because so many large players are now supporting the open social web, but also because the launch was so large and successful that it introduced a ton of people to the concept of open and got them thinking about what more could be done here. It’s an incredibly exciting time, and you can bet I’m going to keep driving things the best way I know how: by talking about the vision, and then backing it up by shipping real code.

P.S.: Here’s a video I recorded earlier this week at Google talking about Plaxo’s involvement in OpenSocial.

P.P.S.: Here’s a video of the demo I gave on Friday, captured by Chris Heuer.

Advanced JavaScript (Widget Summit 2007)

Advanced JavaScript
Widget Summit 2007
San Francisco, CA
October 16, 2007

Download PPT (2.8MB)

Niall Kennedy asked me to speak at his second annual Widget Summit about “Advanced JavaScript” to a audience with a mix of business, product manager, and engineer types. Since I wasn’t sure how to target the talk, I decided to keep my prepared slides light and did a quick run-through of things to be aware of when developing with JavaScript (basically, how not to make your widgets slow or insecure). I then left the remaining time for interactive Q&A.

This turned out to be a good strategy I think, because we got a good 20-30 minutes of lively back and forth discussion in the audience, which drilled down on some of the areas I touched on but also brought up interesting topics I hadn’t covered at all. My main goal was make the attendees aware of enough important issues that they could go back and be able to dig into them in more detail as needed, and I think in that regard it was a success.

PS: I think it’s great to see more small, community-driven conferences like Widget Summit and last week’s Graphing Social Patterns popping up. It shoudn’t cost a fortune to meet and learn from your colleagues, especially since in the web / tech world, most of them are more than eager to share what they know!

My Ajax talk is now on YUI theater

When I gave my talk on High-Performance JavaScript at OSCON in July, I found out that I was speaking right before “Chief Performance Yahoo!” Steve Souders. To be honest, I was a bit nervous–we read everything Steve writes at Plaxo, and he runs a whole group at Yahoo that does nothing but focus on web performance. But our talks turned out to be quite complementary, and we really hit it off as fellow evangelists to developers that “you CAN do something to save your users from slow web sites”.

When we got back to Silicon Valley, Steve said “let’s do lunch at Yahoo! some time”. So I went over on Monday and had lunch with him and JavaScript guru Doug Crockford (also at Yahoo!). Doug is actively working on how to enable secure cross-site mashups, something near to my heart, so we had a great discussion. When we were coordinating lunch plans, Steve had said “hey Joseph, as long as you’re coming over, why not give your talk at Yahoo!, and I’ll give mine again, and we can put them both up on YUI Theater“. And that’s just what we did!

It turns out that Yahoo! has a set of classrooms in one of its buildings where employees regularly come to hear various talks (both from fellow Yahoos and outsiders), so they had a great setup there, and the room was filled with several dozen fellow web hackers. Eric Miraglia, the engineering manager for YUI (which we use in Plaxo Online 3.0), personally videoed both talks, and we had a great discussion afterwards. He told me it would take “about a week” to get the video online, so imagine my delight when I saw it already posted this morning! (He must have heard about that whole “under-promise and over-deliver” strategy, heh).

I was honored to be invited to speak in front of a company like Yahoo! and to a group of people like Steve, Doug, and Eric who are absolutely at the forefront of web technology and are also true believers in sharing their knowledge with the web community. I’ve learned a lot from them all, and I think Yahoo’s recent work with YDN, JSON, and YUI is the best example of open and pragmatic involvement with developers I’ve seen at any big company in recent memory. After the talk, I asked Doug Crockford if I’d done right by him, and he said “that was really great–I only disagreed with one thing you said.” Wow–that’s good enough for me! :)

My quiet twitter friends are getting lost

My Twitter friendsI like twitter, and I use it a lot (I even a twitter widget on my web site). A lot of my friends use it too, some more regularly than others. I use Bloglines to keep up with the stream of status updates from my twitter friends so I can check in periodically and pick up where I left off.

But increasingly I’m feeling like it’s too easy to miss updates from my friends that don’t post constantly. They just get drowned out in the surging river of tweets from the “power users” I follow. It’s a shame, especially because the infrequent users are often my closer friends, whose messages I really don’t want to miss, whereas the chattier users have (almost by definition) a lower signal-to-noise ratio generally.

I’ve been heads-down at Plaxo this week working on some great open-social-web tools, so when I checked my twitter feed this morning I had 200 unread items (perhaps more, but Bloglines annoyingly caps you at 200 unread items per feed). I scrolled through the long list of updates knowing that probably I wouldn’t notice the messages I cared most about. Technology is not helping me here. But there must be a way to fix it.

Since I’m a self-confessed data-glutton, my first step was to quantify and visualize the problem. So I downloaded the HTML of my 200 unread tweets from Bloglines and pulled out the status messages with a quick grep '<h3' twitter.html | cut -d\> -f3 | cut -d\< -f1 | sort | cut -c1-131 and then counted the number of updates from each user by piping that through cut -d: -f1 | sort | uniq -c (the unix pipe is a text-hacker’s best friend!). Here are the results:

      1 adam
      2 BarCamp
      1 BarCampBlock
      2 Blaine Cook
      4 Brian Suda
      1 Cal Henderson
      3 Dave McClure
     22 Dave Winer
      7 David Weinberger
      1 Frederik Hermann
      1 Garret Heaton
      1 Jajah
      3 Jeff Clavier
     52 Jeremiah
     12 Kevin Marks
     10 Lunch 2.0
     28 Mr Messina
      8 Scott Beale
      2 Silona
      5 Tantek Celik
     20 Tara
     10 Tariq KRIM
      4 Xeni Jardin

As expected, there were a bunch of users in there with only 1 or 2 status updates that I’d completely missed. And a few users generated the majority of the 200 tweets. I threw the data into excel and spit out a pie chart, which illustrated my subjective experience perfectly:

Twitter status pie chart

The illegible crowd of names at the top is a wonderfully apt visual representation of the problem. They’re getting trampled in the stampede. And over half of the messages are coming from Jeremiah Owyang, Chris Messina, and Dave Winer (who I suspect will consider this a sign of accomplishment, heh). Now don’t get me wrong, I really want to know what Jeremiah, Chris, and Dave are doing and thinking about, I just don’t want it to be at the expense of that squished group of names at the top, who aren’t quite so loquacious.

But just by doing this experiment, an obvious solution is suggested. Allow a view that groups updates by username and only shows say 1-3 messages per user, with the option to expand and see the rest. This would ensure that you could get a quick view of “who’s said something since I last checked twitter” and it would put everyone on equal footing, regardless of how chatty they are. I could still drill down for the full content, but I wouldn’t feel like I have to wade through my prolific friends to find the muffled chirps of the light twitter users. While there’s clearly value in seeing a chronologically accurate timeline of all status updates, in general I use twitter as another way of keeping in touch with people I care about, so e.g. I think I’d rather know that Garret said something since I last checked in than exactly when he said it.

What do you think? Would this be a useful feature? If so, do we need to wait for Twitter or Bloglines to build it, or would it be easy to do as a mashup? The only hard part I can see is keeping track of the read/unread status, but maybe just keeping a last-read timestamp in a cookie/db and then pulling down all statuses since then and grouping them would be sufficient and quick enough? Now if only I had time for side projects… :)

High-Performance JavaScript (OSCON 2007)

High-Performance JavaScript: Why Everything You’ve Been Taught is Wrong
O’Reilly Open Source Convention (OSCON) 2007
Portland, OR
July 25, 2007

Download PPT (7.3MB)

This talk describes many of the counterintuitive lessons we learned at Plaxo while building Plaxo Online 3.0 and trying to make it fast. 

In addition to sharing technical tricks and gotchas, I try to talk at a higher level about how to approach building fast web apps and how to change your normal assumptions as an engineer or designer when working inside a web browser. When I first practiced giving this talk, it took me about an hour, so I had to cut it down quite a bit. If you’re hungry for more, you can check out the “director’s cut” with all the extra slides still in. :)

This is my second year it OSCON, and like last year I am really impressed by the quality and the attitude of the people here. Hearing smart people talk passionately about topics they’re experts in is inspiring to me, even–or perhaps especially–when I don’t know much about the topic. It’s also nice to catch up with friends and colleagues (many of whom actually live in the bay area, but somehow we only meet up at events like OSCON!)

Twitter status and upcoming events now on my blog sidebar

BTW, I’ve added my current twitter status (using Twit-Twoo) and events I’m attending (via upcoming.org) to the left sidebar of my blog. It’s cool how easy it is these days to integrate data from third-party sites without having to write any API client code. Like we found with Plaxo’s widget, when you can just give people some HTML/JavaScript to copy and paste, the barrier to adoption is dramatically lowered compared to requiring even simple direct API consumption.

Of course, as someone who reads blogs exclusively inside Bloglines, I rarely see the actual web pages where people host their blogs. If you’re like me, now you know I have this extra info on my site. But from what I’ve seen, it appears many (if not most) people still read blogs by typing in the URLs and seeing if there’s anything new. It seems crazy not to take advantage of RSS, especially given how user-friendly many blog readers are these days, but I guess old habits die hard. :)

The hidden cost of meta-refresh tags

We just discovered at Plaxo that redirecting using meta-refresh tags has a surprising performance penalty as a side-effect: it causes all cached resources on the redirected-to page to be re-requested (as if the user had hit the “refresh” button). Even though most of them should return 304s (if you’re caching them properly), this still results in a ton of extra requests and round-trips. A good workaround is to replace the meta-refresh tags with JavaScript redirects.

A bit more detail

A standard technique for redirecting users from one web page to another is to put a “meta refresh” tag in the first page that says to immediately redirect to the other page, e.g.

<html>
<head>
<title>Redirecting...</title>
<meta http-equiv=refresh content="0; url=http://new-page" />
...

When browsers see this, they go to the URL specified, and if the time specified before redirecting is (the “0;” in the above example), they’re even smart enough to remove the redirecting page from the browser history so when you press Back you don’t get re-redirected.

However, there is a side effect that none of us knew about or expected. We only discovered it while performance-tuning Plaxo Online 3.0 (coming real soon now!!) while using HTTPAnalyzer. For some people, after the initial visit to the site, on return visits none of the images would be re-requested (we send long cache expiration times, so this is good behavior). But for others, they’d be requested each time they went to the page.

The difference turned out to be that some people were accessing the site by a slightly different URL that uses a meta-refresh tag to go to the actual site. Since “http-equiv=refresh” means “treat this as if I’d sent the equivalent HTTP header ‘refresh'”, the browser (especially IE) acts as if the user had hit the reload button and re-requests all cached images on the redirected-to page with If-Modified-Since and If-None-Match headers. If you’ve got the right cache headers, these requests will all return 304 (i.e. the images won’t actually be re-downloaded), but it still results in a big–and unnecessary/unintended–performance hit because you’re now sending a bunch of extra round-trip requests while loading the page.

The ideal solution for redirecting is to send a 302 redirect response from the web server itself to avoid even loading the intermediate web page. However, there are times when this isn’t feasible, e.g. if you don’t have that level of control over the server or if your template system wants to only do this if certain variables are set. Another case is if you want to redirect from an HTTPS page to an HTTP page–if you try to do this on the server, you’ll get a browser warning about redirecting from a secure page to an insecure page, but if you do it with meta-refresh, it works fine (bravo, browser security dudes, heh). So in these cases you want to redirect client-side, but you don’t want to incur the side-effect of re-fetching all the cached resources.

A good solution is to use JavaScript (while some web developers like to degrade gracefully when JavaScript is disabled, we’re redirecting to a rich Ajax app, so this isn’t really an issue). Wherever you’d use a meta-refresh tag, instead insert the following script block:

<script type="text/javascript">
location.replace('http://real-page');
</script>

By using location.replace (instead of, say, location.href=), the browser will purge the redirecting page from the browser history, just like a meta-refresh tag with 0 wait time, which is a good thing. And you won’t get any bad caching side effects, which is also a good thing.

Thanks to the two Ryans for figuring this out! Now you know too. :)

I’m so impressed with f8

Facebook Platform Launch (photo by Ted "Dogster" Rheingold)

As f8 would have it, I was in San Francisco yesterday for Facebook’s platform launch and hackathon. What a day it was!

The event itself quite a spectacle (they filled the SF Design Center with about 800 people, Mark gave a Jobs-esque keynote, and the hackathon was set up with tons of couches, tray-passed hors d’oeuvres, a DJ, and Facebook engineers a plenty to help out with the hacking).

But the platform itself was the real star–Facebook really wants developers to be able to build apps that are as powerful and as integrated as the ones Facebook could build themselves, and the Platform really delivers on that audacious goal. You can host your app pages inside Facebook’s chrome, add items to news feeds, send notifications, and basically hook into all the places that Facebook’s existing apps do.

The technology to make this work–and still be safe–is quite clever: basically they curl your page with enough query args to let you access their APIs, you construct the page results, and they display it inside Facebook. Instead of returning straight HTML, they have a modified version they call FBML which, in addition to stripping out JavaScript and sandboxing your CSS, lets you insert special facebook tags to easily do things like link to your friends, use Facebook-styled UI widgets, and even some basic AJAX (they proxy the call through Facebook and then give you a limited-but-still-quite-powerful set of options for what to do with the results, like injecting them into a given DOM node). And since they’re just calling your page via HTTP and it’s up to you to interact with Facebook’s REST API while constructing your result, there’s no need to even write your Facebook app in PHP (which is good news for me, since I’m no Terry, heh).

But the most impressive thing to be about f8 is just how much Facebook “gets it”. They could have continued to be a walled garden–they were doing quite well at it!–but it’s clear from their words and their actions that they really believe they will be more successful by being an open platform and letting developers have real power to extend the experience and take advantage of the social graph they’ve built up. They’re pushing the limits of technology to enable deep integration, they’re providing prominence to third-party apps inside Facebook to help them spread, and they’re even letting the apps keep 100% of the ad money they generate. It’s of course quite defensive for Facebook inasmuch as it disincentivizes people from trying to build new social networks and gives them a multiplier on the features they can offer their users, but it still shows great vision and I couldn’t be happier or more impressed with what they’re doing!

Older posts Newer posts

© 2016 Joseph Smarr

Theme by Anders NorenUp ↑