My jQuery Conference Presentation

As I’ve been talking about on Twitter since I first heard, my topic for the jQuery Conference Boston 2010 was accepted and I’ll be presenting at the event.  I want to give people some advance idea of the topics I’m going to cover so they can make an informed decision as to whether they want to attend my session or the session featuring Menno Van Slooten on increasing velocity.

What follows is the official abstract from the jQuery Conference literature for my talk, jQueryUI and HTML5 Video Play Nice:

With mobile device usage skyrocketing and Flash Player 10.1 failing to provide a “silver bullet” for developers, even on the range of devices that do support it, working effectively with HTML5 video is becoming more critical every day. In this session, we will walk through the basics of creating a jQueryUI-based interface for an HTML5 video player complete with ThemeRoller support.  With support for HTML5 video on mobile  devices incomplete in many cases, we’ll also talk about the nuances of HTML5 video element support on mobile devices including how to properly prepare your content for mobile delivery and common “gotchas” when deploying to these devices.

jQuery topics covered include jQueryUI widget creation, ThemeRoller integration, and how to leverage core jQuery functionality to build HTML5-based video players on mobile devices. Sample code will be provided to all event attendees for a sample jQueryUI HTML5 video player via GitHub.

So how does that abstract translate into what we’re actually going to cover?  I’m glad you asked!  For the first 15-20 minutes, I’m going to talk about various aspects of HTML5 video including what it is and the current state of mobile device support.  I’ll talk about some of the major roadblocks that can make development of players more difficult, and various ways to work around these problems.

From there, I’ve built a very simple jQueryUI based video player. I’ve done my best to build it using as many of the “out of box” jQueryUI components as possible including:

  • Slider
  • Button
  • Position
  • Dialog

All of these controls will be wrapped in a jQueryUI widget that acts primarily as a controller for interaction between the various components.  We’re going to walk through the code of how I set up the widget, how to enable ThemeRoller support on our own elements so they match the built-in jQueryUI widgets, and how to build the event-driven interaction between the various widgets and the video element.  All the while, I’ll be pointing out areas where we need to be concerned about support on mobile devices.

There will be some live-coding, but I’ve done a lot of work to break up various sections ahead of time so we don’t get bogged down in me making simple mistakes while trying to get through the material quickly.  I don’t consider this to be an “advanced” session by any means; with only 45 minutes, this talk will serve primarily as an introduction to jQueryUI, the video element, and the various implementations across mobile devices.  If you’re working in an environment where you may be tasked for creating a cross-platform video application, you’ll likely find the discussion of the various implementation bugs invaluable.

So whether you choose to attend my session on jQueryUI video or Menno’s presentation on Saturday afternoon, there’s going to be a ton of value during that 45-minutes for everyone.

Looking forward to seeing you and meeting you at the jQuery Conference Boston 2010!

Back from Hiatus

I’m back from my blogging hiatus. Between a wedding, honeymoon, and the whirlwind that is HTML5 video, I’ve been completely out of the loop blogging-wise. Add onto that that just 45 days after the wedding my wife got pregnant, and life has been very busy, and very good.

Upon coming back to my blog, I discovered that it had been hacked. I’ve upgraded to WordPress 3.01 and the latest versions of all my plugins. Some things are still screwy (code isn’t being syntax highlighted yet) but at least I’m no longer pushing out malware!

Webkit vs. Firefox on H264

I posted this as a comment on another thread; but I thought it warranted its own post.

Webkit is an open source project.
Webkit development is sponsored by corporations (Apple and Google primarily).
Webkit includes support for h264 video.

Firefox is an open source project.
Firefox development is sponsored by corporations (Mozilla Corporation primarily).
Firefox does not include support for h264 video.

…and yes, the webkit you can download from webkit.org includes h264 support. If Mozilla “can’t” include H264 in Firefox which has been one of the primary arguments by commenters; I’m failing to see a reason.

  

Mozilla’s Not Non-profit (And Other Thoughts)

Wow, I wrote my “Dear Mozilla…” post last night around 10:30 pm and in less than 12 hours it has generated more traffic than my Blog has generated in any single month since I launched it. As I expected, the open source pundits are out in force (and it’s a good thing, they are certainly some valid points in their arguments). As always, there are a few bad apples in the mix who want to make this a personal argument and want to insult me for expressing my opinion. I’ll ignore them for now because I don’t want to get roped into that.

That said, some of the content of the comments has struck a chord with me so I want to add some additional thoughts. I encourage open and good natured discussion and I’ll take the opportunity to remind everyone that one of the great pleasures of life is that we’re allowed to disagree.  There are a lot of supporters on both sides of this argument that bring very valid concerns to the table.

First, I never said that Mozilla shouldn’t support Theora (or that any browser shouldn’t). My letter was about supporting H264; not dropping support for Theora.

I completely agree with the assertion by many that Microsoft’s reason for supporting H.264 is to basically “throw egg” on Mozilla’s face. Simply put: good strategy; my post is certainly not the only one out there talking about how Mozilla needs to add H.264 support now.

I’m going to say it: I don’t care about Opera despite its users being quite possibly the loudest out there. They have abysmally small market share and,  I’m surprised it’s closed source nature doesn’t horrify those of you who are so concerned about “free as in speech” software. I have to say; it’s a bit contradictory.

Mozilla’s Not a Non-Profit

The most common argument has been that “Mozilla’s just an open source project, they can’t afford a license.” I’m calling a great-big, giant bullshit on this one and I congratulate the Mozilla Corporation for so successfully pulling the wool over the eyes of so many people (even their linked in page for the Mozilla Corporation describes Mozilla as a non-profit; choosing to describe only the Mozilla Foundation and not the Mozilla Corporation itself). The Mozilla Corporation (which owns the rights and trademarks around Firefox - Colby Russel correctly points out in the comments that the Mozilla Foundation does actually own the rights to Firefox and its trademarks) is an extremely profitable company.  The browser is Free Software, but Mozilla’s not this small project with no finances. They are very well funded and completely profitable.

Whether they should pay for a license is up for debate and we can have some really constructive discussion around that topic; but make no mistake, the Mozilla Corporation is not non-profit. Driving your profit back into your business does not make you non-profit; it means you’re reinvesting your profit rather than paying shareholders.

I Really LIKE Firefox

But I’m sorry to say that pragmatism wins out over idealism every time; and I fear that if Mozilla chooses to continue on this path, Firefox will see its market share dwindle as it becomes about as popular as desktop linux (used by open source purists, but that’s really about it). Personally, I don’t want to see that happen. But the truth of Firefox’s rise is that it was just a categorically better product than the competition. By not supporting the video format that is clearly emerging as dominant on the Web, that will no longer be the case.

  

Pass that Interview 2: Understanding Recursion

Recursion is one of the most misunderstood concepts in software development. Truthfully, in modern software development it has been almost completely replaced by iterative control structures (loops). In front-end UI-layer development, it is very rarely used. However, it’s very common that you’ll be asked questions about recursion during an interview. Why? I compare it to airlines hiring Air Force and Navy fighter pilots. No, they’re never going to need to barrel roll a commercial jet-liner but the fact that they understand and know how to do it makes them more complete pilots. Similarly, understanding concepts such as recursion opens up new ways of thinking for engineers.

In its most simple terms, a recursive function is a function which returns a call to itself. Naturally, one has to be careful with this type of construct as it’s easy to create an infinite loop. A typical recursive pattern involves breaking a problem into smaller pieces (such as searching a large data set) rather than performing a process multiple times as in iteration.

A common interview question may involve implementing a factorial function using recursion. Let’s take a quick look at how we could do this:

function fact(x) {
    if(x > 1) {
        return x * fact(x-1);
    } else {
        return 1;
    }
}

By including a call to itself in the return, the program builds up and subsequently tears down a call stack. Rather than looping over an operation, we’re breaking the problem into smaller pieces until it’s simply returnin the value we passed in.

Drawbacks of Recursion

Now that we have an understanding of how to create a basic recursive function, we need to be able to discuss the drawbacks of this approach. First, in most programming language, the loop control structures (for, while, etc.) are optimized for speed and will (in the vast majority of cases) be faster.

Second, the memory overhead for allocating all of those functions can grow massively; especially in dynamic languages like Javascript. In our above example, if a user called fact(200) we would incur the overhead of creating 200 function instances in memory. You can see that for large operations this will get very heavy.

Stand Out

For the most part in front-end development, you won’t be delving deeply into recursion; but armed with this basic understanding of the topic, you’ll stand out from other candidates who aren’t familiar with a wide array of software engineering concepts.