&yet

Our general approach to consulting at &yet goes something like this: If we have a knack for something and we think it can help make you better at what you do, help your team eliminate risk, or move more confidently down the right path, we should do it. Starting today, we're offering 3 new WebRTC consulting packages.

In addition to building products and open source software, our team has offered consulting services as long as we've been a company. But now we've started focusing in on how to better package the skills and expertise our community (that's you!) needs.

After reaching out to and talking with teams actively working with WebRTC, we're hearing a lot of the same questions that need answering. Questions like:

• What open source tools are out there and where should we go to get started with them?
• How do we configure TURN/STUN servers so our WebRTC service can work consistently across firewalls?
• What is the best way to go about implementing WebRTC on iOS?
• How can we ensure we're providing a secure and private service? (Including HIPAA-compliance)
• Is it possible to build and scale a WebRTC service on our own infrastructure?
• How can we scale beyond a couple people in a group conversation?
• How could we add chat or whiteboarding alongside our video solution?
• How would we create a massive broadcast live video service?

For the past year and a half, it's been our pleasure and privilege to serve CAA, an agency representing many of the most successful professionals in film, television, music, sports, and theater.

Glenn Scott leads the team there. Over the past few years, they've transitioned their IT to building custom applications in Node. We're proud to say we've been able to partner with Glenn's great team at CAA, playing a key role in their work during that time.

Recently, Glenn gave a nice presentation as part of Joyent's Node on the Road series. In it, he described the way CAA builds applications.

Glenn talks about the challenge of maintenance in traditional IT and how building Node and JS web apps make that much less painful.

Karolina shared a thoroughly researched and powerful closing keynote at CSSConf EU last month titled, Validate Me.

Imposter Syndrome is something we talk about a lot around our team at &yet.

This is definitely a must-watch if you, like many of us, struggle with self-doubt.

What is Talky?

Jenna and Speegle explain it all.

With apologies to Clarissa. #sorrynotsorry

We’ve been hard at work on the next generation of Talky for months and we're getting close.

We think Talky 2 is going to help make group meetings better and simpler.

What's new in Talky 2?

• HD video group conversations with 25+ people
• text chat
• audio-only modes
• low-bandwidth modes
• dramatically improved UX

TodoMVC is a neat project with a simple idea: to build the same application with a whole slew of different frameworks so we can compare how they solve the same problems.

The project's maintainers asked me to contribute an example in Ampersand.js, so that's what we did.

There are a few aspects of the implementation that I thought were worth writing up.

First, some highlights

Two of our core values on the &yet team are curiosity and generosity. That's why you'll so often find my yeti colleagues at the forefront of various open-source projects, and also sharing their knowledge at technology and design conferences around the world.

An outstanding example is the work that Philip Roberts has done to understand how JavaScript really works within the browser, and to explain what he has discovered in a talk entitled "What the Heck is the Event Loop, Anyway?" (delivered at both ScotlandJS and JSConf EU in recent months).

If you'd like to know more about the inner workings of JavaScript, I highly recommend that you spend 30 minutes watching this video - it is fascinating and educational and entertaining all at the same time. (Because another yeti value is humility, you won't find Philip boasting about this talk, but I have no such reservations because it is seriously great stuff.)

&yet has long been a wandering band of souls—like a mix of the A-Team and the Island of Misfit Toys from Rudolph the Red-Nosed Reindeer.

Over five years, one thing that's been a constant for &yet is realtime. We've worked our way through many technologies—some ancient, some nascent, and many of our own. We've stayed focused on the users of those technologies—end users and developers.

Our path forward has become clearer and more focused than it's ever been. Some of the terrific people we've added to our team this last year have had tremendous influence on honing our focus.

We know the type of company we aspire to be: people first, and always determined to make things better for humans on all sides of our work.

A web application is not the same as the service it uses, even if you wrote them both. If your service has an API, you should not make assumptions about how the client application is going to use the API or the data.

A successful API will likely have more than one client written for it, and the authors of those clients will have very different ideas about how to use the data. Maybe you'll consume the API internally for other uses as well. You can't predict the future, so part of separating your API concerns from your clients should be feature detection.

For a real time application, feature detection is a great way to manage client subscriptions to data.

As I discussed a few weeks ago, for realtime apps it's better to send hints, not data. When a client deliberately subscribes to a data channel for updates on changes, that is an explicit subscription. By contrast, an implicit subscription occurs when a client advertises the features and data types it is capable of dealing with, and the server automatically subscribes it to the relevant data channels.

Every Operations Team needs to maintain the system packages installed on their servers. There are various paths toward that goal, with one extreme being to track the packages manually - a tedious, soul-crushing endeavor even if you automate it using Puppet, Fabric, Chef, or (our favorite at &yet) Ansible.

Why? Because even when you automate, you have to be aware of what packages need to be updated. Automating "apt-get upgrade" will work, yes - but you won't discover any regression issues (and related surprises) until the next time you cycle an app or service.

A more balanced approach is to automate the tedious aspects and let the Operations Team handle the parts that require a purposeful decision. How the upgrade step is performed, via automation or manually, is beyond the scope of this brief post. Instead, I'll focus on the first step: how to gather data that can be used to make the required decisions.

Gathering Data