Category Archives: Development

WebRTC: Live web audio/video chat without plugins

Most of the design and development technologies we work with every day are in ‘evolution’ mode, not ‘revolution’ mode. Enhancements are made, bugs are fixed, but the leaps are relatively small. A browser here adds support for the latest HTML5 canvas feature, a device there adds an API for better map coordination. Nifty, but a little light on the ‘wow factor.’

With the release of Firefox 22 this week, though, there’s a browser advancement that has the potential for a real leap: WebRTC is now baked-in and turned on by default. That means both Chrome and Firefox have it up and running in their latest versions. It will soon be ubiquitous (or perhaps ubiquitous-ish until IE follows along…).

Why is this so great? WebRTC is a W3C standard that allows for real-time communication (thus the RTC) in the browser — audio chats, video chats, whatever. No plug-in for users to download and install. Cross-platform and cross-browser compatible. Just code and go.

It will soon be much more trivial to just throw a video customer-service chat on a help-desk website. Or bake it into a community website to allow for in-site community chats. Or integrate it with the many more social networking sites with varying results depending on the site (you can let your imagination run on that one).

The possibilities are pretty remarkable. It’s a great case of where the technology itself has been around a long time, but by establishing a standard, the power is in the interconnection. Like, I don’t know, almost all Internet-based technologies.

There’s a good getting started tutorial over at HTML5 Rocks, and you can also jump off of the WebRTC home page. Either way, it’s worth a click-around. I think this will be big.

The Importance of the Side Project

Every job has its ups and downs, not just the job of elevator operator. (Sorry, old and bad joke.) There are parts of the work that are engaging and interesting, finding answers to problems and implementing those solutions. And then there are the other parts — the prerequisites, the occasional begrudging task.

That’s where the side project comes in. Around our offices, we make sure that everyone has a side project to keep them sharp and engaged, even when the primary project might be a little stultifying. This gives our team members a chance to step away, shift gears, and focus on a different matter for a while.

It’s useful not just to provide a palate cleanser for drudgery. Sometimes, we can get so enmeshed in the norms and expectations of a specific project that our vision begins to narrow. Keeping another project on the side enables us to shift that perspective and keep our sights broad.

For some of our team, it’s a passion project — helping reach out to an underserved community through Internet broadcasting, for instance. For others, it’s a project that might end up being commercial one day, like a new and improved nonprofit management system. Still others combine the two, exploring a recreational opportunity app, for instance. (For one of us, it’s writing for this blog!)

Regardless of the specific project, it’s something we prize greatly, and I think it helps us stay sharp and balanced. Because even with the most fun of projects, there’s always a chance to get sucked in a bit too far!

Creeping Dependencies

We had a client issue the other day where a system stopped working because a necessary third-party service just stopped, with little warning. It got me thinking about the nature of dependencies.

When building networked applications, there are necessarily aspects of which you don’t have control. You don’t usually control every mile of the Internet connection that reaches the user, for instance. So, for example, if it’s a user at home on a shared cable connection and it’s 4pm on a school day when every kid in the neighborhood just got home to stream video, they’re going to have a slower connection–and there’s not much you can do.

In this case, it was a service dependency, and that’s just as potentially problematic. After all, there are times when you can’t do it all yourself–maybe you need to poll an external database for information, or there’s already a cheap commodity service that will take care of an ancillary need.

But the trick, and one that we didn’t really execute as well as we should, is to note the risk upfront and do what you can to mitigate it. In our case, we had noted the risk and thought we had some ways to manage it, but when the outage occurred, we immediately saw breakdowns in the process. Paths for escalating the outage notification were unclear, and the error message created for the users was, shall we say, less than graceful.

Fortunately the outage didn’t last all that long, and the upstream provider of the service was very gracious and quick about getting things resolved. But it was a good reminder that every time you create a dependency, whether it’s an AJAX call that relies on a decently-fast connection or a threshold service for access, it’s critical to consider how to gracefully handle the situation where it fails.

Because it will. At some point. But in our interconnected world, what’s the alternative?

Finally! finally in PHP 5.5

PHP 5.5.0 was released yesterday, and there are a handful of helpful new features. Among them, there is one that looks the best to me — the try-catch block has the finally block added. After all, if you’re doing exception handling in your code with try-catch (and if you’re not, you really should be), there are often scenarios in which you want to execute some arbitrary code at the end of the block, regardless of whether an error got thrown or not.

In some cases, you can put it outside the try-catch block (at the end, of course), but there are at least two circumstances where that’s less-than-optimal. First, if the program flow is altered in the try or catch, yet you want to tack on some code at the end, you’re in luck. But in our case, most of the time, it’s a readability issue. We try to group code conceptually when we write, much as we do when writing in English. That means we use sentences and paragraphs. Well, when coding, we do the same thing. And the addition of the finally block will make that even easier.

Another nifty functional help is the addition of the list form in foreach structures.If you work with nested arrays, you can now unpack them in the foreach construct, exposing the underlying variables much more easily. Like the finally block addition, it’s not as though you couldn’t code around this limitation, but when you don’t have to, code gets more readable.

In a deja-vu moment for C programmers, you can now dereference arrays and string literals to access specific items and characters. So in PHP 5.5, ‘Square’[1] equates to ‘q’. Not too shabby.

You can now pass a function call to empty() to evaluate it, which is another keystroke-saver when coding. So if you have a function foo() that may return data or may return, say, false, you can evaluate empty(foo()) and see if false came back. Again, a minor assist, but an assist nonetheless.

There are other features in this release, too, including a new Zend optimization caching extension, some enhancements to the GD graphics library, a new yield keyword that allows you to do simple iteration without using as much memory, a class function that gives you the unqualified class name, and more.

It’s good to see PHP continuing to evolve and grow — it has come a long way since I first used it fifteen years ago!