Where Have You Been?

It’s been almost a full year since I last updated this blog; it’s high time I get back to it. Rather than diving straight into the technical conversation, I’ll take a moment to update folks on my life since leaving Brightcove in November 2010.

  • We moved to California
  • We got set up in a new house
  • We went to visit Atlanta for Christmas
  • In February, my son, Lucas, was born

Anyone who’s a parent will tell you that last one is enough to eat anybody’s time.  Completely. :)

Since joining Netflix, I’ve had the opportunity to work with some of the absolute best minds in Javascript engineering today. Seriously, I know you all think of Netflix as “that company that sends me red envelopes;” but, if you take a look deeper, you’ll see that we’ve transformed primarily into an instant-watch streaming company.  Moreover, you’ve probably heard that we’re delivering experiences on various TV-platforms using HTML5.  What you likely haven’t heard about is the incredible team of people that build these experiences, and the thought and execution around Javascript application architecture that goes into these apps. With perhaps a couple of notable exceptions, I’d contend that no one is doing apps in the browser quite like we’re doing.

It’s been an exciting time, and I’ve learned a ton. My hope is to become more active on this blog (and in the community at large) again to share some of those learnings beyond our walls. Now that my son is 6 months old and settling into more of a “normal” routine, I feel like I may actually have time to make good on that agenda.

Until We Meet Again…

Today is my last day with Brightcove; a company which I joined just over a year ago.  My emotions are mixed about this life change; but like the change that brought me to Brightcove in the first place, I’m confident that I’ve made the right decision.  Once again, I didn’t set out to find a new job; yet one came and found me anyway. And once again, I didn’t plan to move across the country; yet we’re working on packing as we speak.

My grandfather passed away on the day I graduated from Georgia Tech; as I was approaching the end of school and beginning the interviewing process in earnest he asked me a question, “So where are you going to live when you graduate?” Knowing my grandfather as I did, I knew it was a trick question but I wasn’t quite sure how to answer. Quickly, he answered for me, “The answer is always, ‘Wherever the job is.’” It’s a lesson I carry with me and that guided my decision to move from Atlanta to Boston to join Brightcove in the first place. And it’s a lesson still with me as we prepare to move less than a year later to California.

My father once told me that he’d become successful as much by his judgment of and willingness to embrace opportunities as hard work. He was a USAF pilot who got into the Air Force at the last possible moment (before he was too old to join) and got out and into the Airline industry at a time when they were hiring. He seized the opportunities that came his way and made the most of them. Once again, I’ve done the same.

I love Brightcove; I think this company is doing great things and will continue to do great things whether I am with them or not. I’ve been continually impressed by the talent of the engineering team, the dedication of the sales, account management, and customer service teams, and the constant belief that the company is a big part of the future of the Web. I really couldn’t agree more with that sentiment and I look forward to watching on from the outside as the company rises to new heights.

I get several emails a week through LinkedIn or other sources about “job opportunities.” I typically ignore or politely decline these messages as most of the are for companies that hold absolutely no interest for me or they’re not real offers; just recruiters looking for anyone who might be interested in anything. However, there are some companies whose name in my inbox would get me excited and when Netflix reached out to me to talk about joining their team, I knew it was worth chatting with them.  Aside from being a great company of which I’ve been a customer for many years, I had long known that my wife wasn’t thrilled with living in Boston and would jump at the opportunity to move to California. Several phone interviews, a 36-hour round-trip to Los Gatos, CA (which included a 3-hour flight delay, almost no sleep, and 5 hours of interviewing) and a weekend of recovery later, I’d accepted the job offer to join the Netflix team.

I’m really excited to join their “device platforms” group; the same group responsible for delivering the totally kick-ass implementation of Netflix for the Sony Ps3. I’m excited to work at a company that has completely embraced HTML5 and Javascript for delivering experiences across multiple platforms with multiple interface paradigms. I’m excited to be joining a team which, if my interview was any indication, is full of true, front-end engineering badasses. My wife and I are both excited about moving to sunny California!

At the same time, I’m sad to be leaving a family I was just beginning to develop in Boston. I’ve made some great friends along the way here and it sucks to have to leave so soon after it all began. I’m also sad not to be able to see Brightcove’s HTML5 players through to a state of real parity with the Flash players.  Ultimately, as is always the case, what I’ll miss most is the people.  I want to thank all of them for welcoming me so warmly to such a cold city and for the opportunity to do some amazing things with them!

So long, Brightcove; it’s been a pleasure!

Android “ended” and “pause” events on <video>

In working on implementing playlists for the Brightcove Smart Players, I discovered some pretty annoying discrepancies between the HTML5 video specification and how Android handles video objects.  I’ve created a droidfix GitHub repository which captures an example of how to solve these problems.

The Problems

On Android devices, similar to the iPhone and iPod touch, video is a modal experience; that is, rather than playing the video within the context of the page, the video is immediately expanded to a full-screen experience. We can debate whether this approach is right or wrong all day long if you’d like; but for now let’s just accept it and move on.

On the Android platform, the video player is opened as if it were a new page. To return to the page from the playing (or paused) video, the user must use the device’s back button.  Several things do (or don’t) happen when you hit the back button:

  1. An “ended” event fires
  2. The currentTime property of the video is reset to 0
  3. A “pause” event does not fire

The ended event is particularly troubling when building a playlist-driven player as the ended event can be used to signal to the playlist that it’s time to load the next video. It creates a funny (for the developer; probably not the user) inescapable scenario when the user pauses the video and the next item on the playlist loads immediately until the end of the playlist is reached.

Workaround

I’ll point you to the GitHub version of droidfix.js to see the code; including an example page showing the code in action. Here’s a quick description of the workaround:

First, when timeupdate events are fired, we store the furthest forward position in the video that has played. We have to do this because of item #2 above; once the video actually ends, we’ll lose the last time index.

Now, when an ended event is received, we check to ensure the video has really reached the state specified for an ended event. In other browsers, we check that the currentTime property of the video is equal to the video’s duration; if that’s true, we’ve reached the end of the video.  For android, we check that the furthest forward position variable we stored earlier is within 2 seconds of the end of the video. Why 2 seconds? Well, the Android browser doesn’t fire a timeupdate event at the end of the video; furthermore, it also doesn’t seem to be consistent as to how far from the end of the video it fires its last timeupdate. In my testing, 2 seconds was a long enough buffer to include all examples; it also has the side-effect of being short enough that we can reasonably assert that beyond that point, the user has “completed’ the video.

If we determine that the ended event is legit, we fire a series of custom listeners set up in droidfix. However, if we determine this is android telling us that the video has ended when it hasn’t, we create a custom pause event and fire it so handlers bound to pause will be triggered.

Go fork and wreak havoc!

I put the example code on GitHub with a pretty descriptive README of how it works along with the current known issues / caveats. Feel free to grab it, modify, comment, etc. If nothing else, it provides an example that you can integrate with your own video solutions.

Meeting people at jQuery Conference

As far as I’m concerned, one of the most under-appreciated and most wonderful things about the jQuery community is the humanity of the people within it.  Though I’d met several people at last year’s conference and made efforts to speak to several of them in the year since, I wouldn’t say that I went to the conference with any expectation of being “in” with the crowd. I reintroduced myself to several people and caught up briefly with those who did remember me.

I soon found that I was involved in conversations that I never would have anticipated at a tech conference. Take, for example, an hour long conversation with @codylindley and @mennovanslooten about our families, my wife’s pregnancy, and the excitement and life changes that my impending fatherhood has in store for me. Or talking about cocktails with @tdreyno (one of my favorite topics, by the way).  Or sharing stories about our misspent youths with @dainbrain. Honestly, these aren’t the conversations I’d been expecting to have and I completely welcomed them! It was great to go beyond the concept of, “this is a person who really knows their stuff,” and get to the people behind the twitter accounts.

I met these, and many other people at #jqcon this year (too many to list, honestly). Even if the conference hadn’t been technically top notch, it would have been 100% worth it just to meet and interact with the incredible jQuery community.

As John @unscriptable Hahn said in a note to the jQuery speakers just after the conference:

JavaScript wouldn’t be where it is today without its awesome collaborative community.  You gals/guys exemplify it.  You all rock!

We’re striving for technical excellence; but the community around jQuery (and Javascript at large, for that matter) is really something we should all be proud to be a part of!.

Early thoughts on jQuery Conference 2010 Boston

Having just spent a whirlwind of a weekend in-and-around Boston for the jQuery Conference Boston 2010, I wanted to share as many thoughts as can as quickly as possible.  I was struck by how much different the tone of this year’s event was; and it was really refreshing to see.

Last year, and indeed in any jQuery-focused event, the tone has always been about people using jQuery to “do cool stuff (easily).” It’s really great; this reason is exactly why so many people gravitate to jQuery in the first place.  However, in his first-day keynote, John Resig hit us with an interesting statistic: jQuery is now used on nearly an third of all websites.  That figure, aside from being absolutely staggering, suggests that the message has been heard loud and clear already: You can use jQuery to make your life better as a developer!

So here we are in October 2010 and the trends of what people are doing with Javascript on the web are changing; the focus is clearly shifting to building what Adobe loves to term “Rich Internet Applications (RIAs)” in Javascript, HTML, and CSS. And I’m happy to say that the jQuery community, especially the wonderful group of speakers, really stepped up and understood that this year’s challenges were new to these developers raised on jQuery.

I think I really realized how different this year’s event was when Rebecca Murphey started talking about design patterns in her presentation. Mediators, Pub / Sub, the Observer pattern; these just aren’t topics that I’m accustomed to hearing about when talking to (most) Javascript developers.  I even think I heard mention of a factory (though, I admit, that thought terrifies me as the factory pattern immediately brings Java to mind with its AbstractDeckOfCardsFactoryFactory implementations).   Could it be that we’re close to inviting the Gang of Four to Javascript conferences? Well; maybe not. But Rebecca’s talk really crystalized the thought in my mind; Javascript, you’ve come a long way, baby!

It’s not that design patterns are new to Javascript; take for example the Prototype pattern which is an integral part of the language. Event bubbling can certainly be viewed as an implementation of the Chain of Responsibility pattern. But these concepts are likely very new to a great many Javascript developers. And, to be honest, why shouldn’t they be? For years, Javascript has been derided as nothing more than a toy language practiced primarily by designers with delusions that they were capable of “writing code.”

Instead of talking exclusively about fun effects (which Karl Swedberg did, wonderfully, by the way) we had talks on code structure and best practices. Garann Means talked about how utilizing template techniques helped her team reduce 12,000 lines of code to 4,000.  Thomas Reynolds talked about structuring multi-thousand-line applications using MVC. And there were multiple talks on testing including conversation of TDD, and systematic integration testing! These aren’t “form validation” and “pop up a modal” examples; these are real applications built in javascript and it’s quite exciting to see our community embracing the future.

I’ve got more to say, and a ton more thoughts on the conference. For now, if what I saw this weekend at #jqcon was any indication of the way not only the jQuery community is going, but the JS community in general, the future looks pretty damn bright!