&yet

The web platform has evolved. Browsers are no longer just document renderers, they have become the most capable and ubiquitous application runtimes on the planet.

Right now, the most common term for applications that use the browser as a runtime is "Single Page App". I’ve even heard people pronounce it like the word "spa". If you’ve done this, we can probably still be friends :)

Personally, I’ve always disliked the term "single page app" because it fails to describe what my applications are. The fact that the app consists of a single initial HTML page is not what makes it interesting or unique. In fact, often times it’s plain wrong. A well-built "single page app" updates the URL as the user navigates around to different "pages" within the app, keeping their place if they refresh or share that URL. Perhaps at one time the "single pageness" was its defining characteristic, but these days the term makes it sound more like you’re building an application that doesn’t respect the URL and thus breaks the web.

When I was first writing Human JavaScript I struggled to find a good word for these apps that I could use throughout the book. Each of them has issues, here are a few in particular:

I've been always drawn to bringing structure where it was lacking, systematizing information and defining processes. Not sure if that's a designer's trait (along with a particular fondness of symmetry) but it continues to carry through all the work I do. One of the ways I utilise it is by creating standardized approaches for others to follow.

"Best practices"

When writing software we often look for guidelines on how to do it in the most effective and standards-compliant way. We search for patterns we can follow. Standards are obvious signposts leading us to valid code (which is why we call them standards in the first place). The other way of approaching this problem is to look for so-called best practices.

Why “so-called”? Because we don’t really know where these rules came from. Is it because of the broad adoption within a given community, or something else?

Node.js doesn't have the same problems as the platforms that you're used to—it has entirely new problems!

The landscape is so different, and there are so many libraries, packages, and approaches that it is tough to navigate. There are just too many opinions on the "best approach." Even the io.js fork of Node (which we're excited about and hope gets upstreamed to Node soon) is a good example of this unique ecosystem.

Ask 12 Node.js developers which is the best ORM to use, or how structure your HTTP handlers, and you'll get 15 answers. On these and hundreds of other topics, there is no consensus, and there are numerous approaches and philosophies to choose from. Many a developer has followed their instincts and gut feelings, only to make a mess.

This might be the complete opposite problem that you're used to. Maybe you came from Django, like &yet did, and were looking for something less focused on content-driven applications and sites. Maybe you came from Rails, like many of us, and were frustrated by the amount of convention, being railroaded down a single path. Maybe you're making a transition from Java or PHP.

When launching our Talky videochat service almost two years ago there was one thing missing: the TURN server.

WebRTC creates peer-to-peer connections between browsers to transfer the audio and video data, but sometimes it needs a little help to establish a connection. The TURN server is the thing that helps here: it is deployed on the Internet and relays data for two clients that fail to establish a direct, P2P connection (thus avoiding the dreaded "black video" problem). TURN is generally considered one of the hard topics when people start doing WebRTC and crucial to running a successful service.

When I started at &yet back in March one of the first things I did was to add a TURN server. We choose the open-source restund server because it had proven to be mature and very easy to extend earlier. The rfc-5766-turn-server is another popular choice here, but the design and extensibility of restund was more appealing to us.

In response to adding a TURN server, the number of "black video" problems that users reported went down to almost zero. The exception were Firefox users and this turned out to be a Firefox bug which was fixed.

So there you are, scrubbing bugs in your open-source project. Replying to the people who opened the tickets. But have you ever thought about who your actual audience is when you're interacting with your user base?

Your whole audience

Just who are you talking to when you're interacting with users? When you get right down to it, it's not just that person, it's everyone watching. It's the next person who comes along and reads that ticket. It's the person way in the future who is deciding whether or not to even use your software.

Still, it is also that person in that ticket. A real person who took their valuable time and decided to do all the hard work of finding out how to contact you, compose their thoughts, and reach out to you.

Underscore.js is the single most depended on module on npm.

It's impressive work from Jeremy Ashkenas, who also created Backbone.js and CoffeeScript, all hugely popular projects.

But how many of the modules that depend on underscore only use it for one or two methods? I'd venture to guess quite a few.

Conceptually, it makes sense. Why would you go implement your own debounce method when there's one in Underscore that works great and has clearly been put through its paces. Just install Underscore, be happy, and go fry some bigger fish!

We believe WebRTC is one of the most important technologies to hit the web in many years. There is a significant opportunity for WebRTC to help deliver on the promise of the open web—but for communication and collaboration.

In several of our colleague Henrik Joreteg's talks the past couple years, he's said, "WebRTC needs more Open Web hackers!" It's very true.

But WebRTC is much more complicated than other browser APIs that web developers deal with.

It seems, from our vantage point, like a large portion of the users of WebRTC have not been Open Web hackers.

At &yet we have become big fans of CoreOS and Docker, and we've recently moved a bunch of our Node applications there.

We wanted to share a little tidbit for something that seems like it should be easy, but ended up being a minor stumbling block: making CoreOS's Etcd cluster available in Docker.

Here's a little background for those not up to speed on CoreOS or Etcd. CoreOS bills itself as "Linux for Massive Server Deployments." CoreOS is usually deployed with Etcd, "a highly-available key value store for shared configuration and service discovery," giving servers in a cluster the ability to share configuration data. We have been using Etcd and Confd for some time, so we naturally thought: "wouldn't it be cool to configure applications and services within Docker from Etcd?"

This can be easily accomplished by passing an environment variable to Docker at runtime and tweaking a few iptables rules. CoreOS makes the Etcd HTTP API available on its private IP address at port 4001 by default. CoreOS also sets an environment variable called $COREOS_PRIVATE_IPV4 in /etc/hosts with said IP. Fortunately, Docker is networked to the host's private IP, so this is the easiest point of access for Etcd.

Hey folks! It's the holiday season, the goose is getting fat, the decorations are filling the air with glimmery goodness, and the yeti is plodding through the snow with gifts for all its web-loving friends.

But oh no! What if it doesn't know where to go?!

The yeti could shower its gifts onto the twitters, sure, but then how would it know you received it? It could leave it on this here blog, but what if–gasp–you FORGET? You might accidentally leave the yeti's gift out in the cold, cold snow where it could develop abandonment issues.

Hang on hang on. I have an idea. What about &you?

First: so hey, it looks like our novel, Something Greater than Artifice, was selected as a Kirkus Reviews Indie Book of the Year!

Which is nice.

Second: which means that the message behind the book is getting out there.