&yet

Enterprise Week is the name of a week-long activity for high school seniors in the Pasco School District. It's loosely affiliated with Washington Business Week, which is our state's incarnation of a program that many states run aimed at exposing young folks to the business world.

During Enterprise Week, every senior from the three high schools in the district are pulled out of school and dropped into their "offices" in a local convention center. Volunteers from the local business community are asked to be a "Company Advisor" for each group of about a dozen students. I volunteered to be one, and I had no idea what to expect.

The first, most important thing a Company Advisor (CA) should do, we were told, is to sit back and let the kids do the work. Each "company" would have a CEO, a COO, and heads of other various departments, much as you'd expect from a real business. It was the CA's job to select the CEO, and then let them run the show.

Henrik follows up on his "Opinionated rundown of JS frameworks" blog post with a presentation at FFConf, in which he explored topics related to single-page apps, including:

• Should we build apps that require JavaScript to run
• What is a "native web app"?
• What about progressive enhancement?
• The performance implications of clientside apps
• Twitter’s move away from clientside back to server-rendered
• The two classes of web apps
• User expectations of modern applications
• Installable web apps
• True offline support for web apps: ServiceWorker
• Isomorphic (dual-rendered) applications
• Picking tools for a rapidly changing environment
• Optimizing for change
• Building for the future of the web

Yesterday Fippo talked about applying the principles of the open web to realtime communication with WebRTC. Consider this post the first installment of providing in-depth descriptions of what that means in practice.

Where codecs fit in

A key component of realtime audio and video systems (like Talky) consists of methods for encoding the light waves and sound waves that our eyes and ears can understand into digital information that computers can process. Such a method is called a codec (shorthand for code/decode).

Because there are many different audio codecs and video codecs, if we want interoperability, then it's important for different software implementations to "speak the same language" by having at least one codec in common. In the parlance of industry standards, such a codec is specified as "mandatory to implement" or MTI (often an MTI codec is a lowest common denominator, but software can use better codecs if available - a model that has also worked well for cipher suites in SSL/TLS and other technologies.)

There's a lot of talk about this topic of "the web we want," and a lot of it has focused around WebRTC lately.

I have been working with WebRTC since mid-2012, both in the Chrome and Firefox browsers, as well as the native webrtc.org library. So far I have filed more than sixty issues in the WebRTC project issue tracker and the Chrome bugtracker. I'm especially proud that I've crashed the production version of Chrome eight times.

I am among the top non-Google people to file WebRTC issues. And I managed to get quite a few of them fixed, too. I visited Google's Stockholm office in September and had a conversation with the team there about how I use the issue tracker and how that process works. Full disclosure: I got a t-shirt (even though it turned out to be too large). And I even started reviewing the Chrome WebRTC release notes before they're sent out.

Justin Uberti's description of WebRTC as a "project to bring realtime communication to the open web platform" is still the vision I cling to.

For those of you who don't know, hapi is a web framework with a rapidly growing community led by Eran Hammer.

Over the last month, a lot of work has gone into it to prepare for the release of version 8.0.0. hapi 8 represents the biggest release since the start of the framework, and with it come quite a few changes.

No more packs

That's right, those confusing pack things are gone. If you used them, though, don't worry. The functionality still exists, just in different ways. Instead of a pack that contains servers, we now have a server that contains connections. You can still create a server with multiple connections, but if you only need one; everything will feel much more straightforward and intuitive.

As a semi-official part of the &yet Blog Team and a super-official, semi-professional antagonizer, I spend a lot of time kicking in office doors and demanding that people write things. Some of those folks (once they’ve come to the realization that I will not stop making this pose in their doorframe)

…will buckle down and whip out some words about JavaScript or Node or NodeScript or JavaNode or BackBonemBerGular or whatever in a jiffy, and if only to dislodge my presence from their immediate vicinity for one more day. Others flatly refuse, and that's okay too.

But there are others.

Despite how we mostly share what we've learned about making great software, software really isn't the point of what we do at &yet. Writing code and designing interfaces and helping build software products and teaching what we know is all just an excuse to spend time on what we really care about – which is people.

Getting to be with our favorite people while we figure out challenging, interesting problems together is the whole point. If we were good at building ocean liners, that's what we'd be doing. It just happens that we're good at building software.

Last month, we started sending out a bi-weekly dispatch that we're calling &you. Close to 4,000 of you are signed up, and we're really grateful for the conversations we've been having with many of you.

So far, we've shared stories about what's on our minds these days, asked questions about what you're doing, spotlighted people in the &you community and their projects, and shared some of our favorite reads and resources.

You're looking at your todo list and pondering what code to write during one of the brief moments of free time that appear on your daily schedule, when all of the sudden you get a message in team chat: Is the site down for anyone else?

It can be a frustrating experience, but never fear; you're not alone. We here at &yet experienced this type of outage once before, and then again this week. In fact, nearly every operations team has experienced at least a variation on the above nightmare. It is just a matter of time before you have to deal with people thinking your site or service is down when the problem is really with the Domain Name Service (DNS). Even shops that spend a lot of money to work with DNS vendors who themselves have some serious redundancy and scale will eventually fall prey to an orchestrated Distributed Denial of Service Attack.

So what did we learn when we were faced with an attack this week? Mainly, a reminder of the importance of redundancy. The best solution is still the simplest: have more than one DNS vendor. Now don't be fooled by the use of the word "simple" - while redundancy is the simplest, it is not a simple process to implement at all, but let's walk through what we will need.

Pick the two (or more) vendors. The crucial part for this is that both vendors have to have an API for changes to your DNS Zone records. If they don't have an API, you will be forced to make updates using their web interface and that just is not a recipe for success at all! Another criterion is that both vendors should have solid track records with dealing with DDoS events - no use picking a vendor that falls over at the slightest attack.

This is how I've felt about every project I've ever done.

Starting

Starting a project is fun. There's infinite possibility. There's no pressure. You haven't messed it all up yet.

Middle

Six years ago, around this time of year, I met this turkey for the first time.

It was on a flyer for a little local music venue called The Red Room that had received quite a bit of acclaim. I'd heard of the venue, but hadn't been there yet. I hadn't met anyone who'd been to it yet, so somehow it wasn't really real.

The flyer sat on the counter of a tiny print shop on the far side of Pasco. I say "shop," but this was a warehouse. I could hear the giant analog four-color press churning out Spanish-language phone books, going "chkunk-shhhh-chkunk-shhhh-chkunk!" faster than I could possibly onomatopoeticate.