Node.js is a platform for running JavaScript (ECMAScript) that is powered by Google Chrome’s JavaScript engine, V8. V8 pushed JavaScript forward in terms of speed when it was first released, but hasn’t been keeping up with the accelerated pace of the ECMAScript Standard. We’ll likely see a new release of the spec every year, but V8 is lagging far behind Mozilla’s SpiderMonkey and Microsoft’s Chakra in terms of support for ECMAScript 2015 (aka ES6).

Node.js developers that have been eager for ES2015 features that V8 doesn't yet support have turned to Babel.JS for compiling their ES2015 code into ES5 code, but this only works for syntax features like arrow functions. There are features within ES2015 that Babel.JS can’t emulate because ES5 fundamentally lacks the ability accomplish these features in any reasonable way, namely the Proxy constructor and extending built-in objects like Array.

[Update: This controversial statement has been too distracting.] The Node.js Foundation would be wise to migrate to Chakra, because Google’s updates are coming in at a trickle while Microsoft’s are roaring in like a river, but that’s not really the point. The point is that these features are coming regardless, and you can play with them now. With an annual ECMAScript releases adding new features, Microsoft's Node.js Chakra fork will continue to outpace Google's V8 engine by months. So long as Microsoft maintains their fork, we’ll be able to preview features that aren’t yet ready in V8.

In order to use Microsoft's fork, you need a Windows 10 machine with the November update. It’s a huge update, so just because you have auto-updates enabled doesn’t mean that you have it (this messed me up). For the full instructions, look at an individual release on github, currently v1.3.

Nathan Fritz and Sally Mohr will be presenting at the Node Community Convention on January 26-28th in San Francisco, CA.

The Node Community Convention's focus is to provide the learning space for best practices and new techniques to maximize the use of node.js, case studies from developers and companies who are changing the web, and a networking space to build the personal and professional relationships you need.

Nathan and Sally will be speaking on Convincing the Decision Makers to Use Node.

We are excited to see you in SF! Come say hi if you'll be there.

tl;dr: with adapter.js you can write WebRTC code that is spec-compliant and works in all supported browsers. That is the web we want.

We have come a long way since WebRTC was first enabled by default in Nightly back in February 2013 after interoperability had been achieved earlier that month. Since then a lot has happened.

One of the bigger updates to the specifications was the addition of a Promise-based version of the API instead of callback-based API in December 2014. Firefox has supported the Promise-based versions of the getUserMedia and the RTCPeerConnection APIs for quite a while now. Yay!

That means you can write code like this:

Back in June, Apple introduced bitcode as a part of their app thinning strategy, which allows them to implement some optimizations in the future without developers having to resubmit their apps. Unfortunately, bitcode must be enabled for the whole app, including third-party libraries. This is a problem if you use WebRTC as it does not currently have a build option to enable bitcode.

Because the Talky iOS app uses WebRTC, I decided to investigate what it would take to enable bitcode when building WebRTC. For this post, I assume that you're building a Release build of WebRTC with the steps outlined at http://www.webrtc.org/native-code/ios.

Step 1: Get the code

If you haven't already downloaded the WebRTC source, open a terminal window and follow the steps for "Getting the code".

Today I'm pleased to announce the release of a new feature of our video conferencing service, Talky.io. It's called Real-time Text (or RTT for short), and it lets other people in your Talky room see what you are typing into the room chat, as you type. Here's a screen capture of RTT in action:

RTT is not enabled by default as most people are inclined to hide typos or half-finished thoughts, but you can opt-in by ticking the "Send as I type" box beneath the chat input.

So why add RTT to Talky? Because at &yet we believe that software is about people, and there are people who use Talky that are not able to use the voice half of our voice and video service.

A piece of recurring feedback we’ve received is that the Talky web interface isn’t great for smaller screens, especially for those on Android mobile devices. There is a Talky iOS app, but there isn’t one yet for Android, and the web interface was designed for wider (desktop-sized) screens.

With the latest release, we’ve taken that feedback and designed a better experience for small screens. Our primary goal was freeing up screen space for the video streams. We changed the wide sidebar to a much shorter top navigation, but keeping the primary controls readily available. To gain back some space, we moved the less-frequently used controls into an expandable menu and removed the secondary roster of participants.

While these changes were made with mobile devices in mind, you can also see them on your desktop browser. Resize your browser window and free up some of that monitor space.

We’ve talked before about the revolutionary importance of WebRTC, because it brings the principles of the open web to voice, video, screensharing, and other applications that were traditionally closed off to fast innovation. This revolution has been led not by old-style telcos but by web and mobile companies, especially the developers of the Google Chrome and Mozilla Firefox browsers.

Until recently, both Microsoft and Apple have been standing on the sidelines as this revolution unfolded. Thankfully that’s starting to change, as Microsoft adds these capabilities to its upcoming Edge browser. (Apple, however, is still late to the party.)

There’s a twist to this story, though, because Edge supports an object-oriented flavor of WebRTC called ORTC, which most observers expect will eventually become WebRTC 1.1 or 2.0 or something. :-)

Thus we have a conundrum: in video conferencing apps like our Talky service, cross-browser calls work fine right now because both Chrome and Firefox support WebRTC. But adding Edge to the mix doesn’t automatically result in cross-browser calls to Edge users, since the signaling methods involved have different syntax even though the semantics are the same.

There have been some questions about what to expect at &yetConf next month. Here's a sneak peek at local artist Husaya Hama, from the Urban Poets Society, spoken word piece “Lazer Beams” in response to the themes we’ll be presenting at this year‘s event.

&yetConf Oct 6-8 from &yet on Vimeo.

We’ve also added lots of updates to the conference site (andyetconf.com), among them some very important ones like – the early bird ticket application process has come to a close! Regular tickets are now on sale for $1399, but they’re limited so don’t wait too long.

When writing your APIs for a microservice, special care should be taken to properly plan out auth and permissions since parts of your user system will be handled by other services. Previously, we introduced Yeti Threads as a case study for writing microservices in Node.js. This time, we’ll be diving into the Auth strategy in this case study.

“Auth” is really short for two things, authentication and authorization. Microservices don’t provide their own authentication, but they’re in charge of at least enforcing their own authorization, if not tracking the permissions as well. In this case, OpenID Connect gives us a JWT token encoded with a user identity and scopes of authorization (perhaps from Auth0, or one that we at &yet helped you customize and deploy). The microservice can trust these values because they’re signed by a private key that only the services themselves know, and can validate the signature. The scopes are a list of tags, typically indicating which sets of actions and endpoints are allowed.

In Yeti Threads, you might notice that we don’t have a users table in the database. Since we trust the identity and scopes in the signed JWT, we can simply treat the user id as an opaque string; it doesn’t matter what it is, as long as it uniquely identifies a user. I also decided that I didn’t need a scope for most actions, except for modifying permissions, in which case we need them to have 'forum_admin' in their scopes. Look at the access.js controller and you’ll see that the handlers specify an auth.scope (which is a handy hapi handler feature).

Node.js APIs shouldn’t have to involve any guesswork, so I set out to create a case study Node.js microservice API that had all of the rough edges smoothed off. It was also a good chance to play with some new Postgres JSON features. Thus, the Yeti Threads API was born. The Yeti Threads API is a conversation threading forum API. It’s MIT licensed, so feel free to use it to add conversation threading to your applications.

Writing APIs in Node.js should be really, really straightforward, even if you’re doing live eventing. You’re probably exposing a REST API that has basic Create Read Update Delete handlers that roughly translate to some database calls. You’re probably sending basic updates over a websocket based on the changes to the database. These things are so well established, that several products out there attempt to commoditize these sorts of APIs.

Let’s talk about tool choice first.

We humans are a funny bunch. By our nature, we’re both creators and consumers. You might even say those are the most basic instincts we act on for our survival. But, even though we’re both, when we’re in one role, we tend to do a pretty bad job of considering the other role. To wit, in the capitalist society that most of us live in, many businesses have been built around exploiting our own penchant for consuming for the sake of profit and not necessarily the betterment of the consumer or our society (broadly, “survival”).

Generally, those businesses are built on the idea that the business can most successfully extract maximum value from a customer by minimizing their costs, and by doing this they’ve met their requirement for existing.

This can create some success, but what creates long-term sustained success, for both the company and society? We strongly agree with the many people who are much smarter than we are, who say that it’s making a connection with your customer/client/consumer/user.

At &yet, we fundamentally believe that goods and services can be created in such a way that first and foremost creates a human connection between the person that uses or buys a product or service and the business that created it.

Conferences are an art form.

I didn’t always believe this, but I certainly have since I started going to exceptionally and intentionally designed events.

In an information dense world, connection and meaning are things we hunger for—and those are what the majority of people are really looking for in a conference.

It’s not the content. It’s the people. It's the connections between them and inspiration and personal reflection that the content makes possible. It’s the new direction in their life that attendees choose because of one long conversation in a corner. It’s the idea they are exposed to alongside meeting the person it originated from that sets their future trajectory.

It is with many yeti tears that we bid a fond farewell to one of our deepest friends, Henrik Joreteg.

Henrik has made the difficult choice to leave our team to pursue the many exciting and challenging experiences awaiting him. Although we look forward to working together with Henrik in the future, we will definitely miss hearing his puntastic dadcore jokes in the hallway and hearing the pitter patter of those weird toe shoes he wears.

All joking aside, while we are saddened to lose such an amazing teammate, we are 1000% behind Henrik pursuing his dreams. Henrik heavily contributed to making us one of the best Node consultancies around, and helped us push our capabilities within the bleeding edge of realtime technologies. He will be greatly missed in the many adventures ahead of our team.

To Henrik, Heinrich, and even, Roosterick — we wouldn’t be where we are today without you, and we are deeply grateful for the impact you’ve had on our work, our team, our ideas, and each of us individually. We wish you nothing but the very best in your next chapter. <&

Every once in a while something new comes along that just feels right.

When this happens, I get a tingly feeling in my left pinky toe. That’s how I know it’s not just a fad. It’s how I know it’s legit.

My pinky toe has a pretty decent track record:

• It first tingled when I moved an element on the page with jQuery.
• It tingled when Backbone.js came out. I blogged about it in 2010
• It tingled when I pushed my first message from server to client with Socket.io and Node.js
• It tingled with React after I got over “JSX shock”
• It’s been tingling for a few weeks straight now about a thing called Redux.

Today &yet’s favorite Node.js web framework, hapi, turns four years old. We’ve had some great experiences with hapi and are both excited and proud to continue to be a part of the community surrounding it.

Eran Hammer started working on what would eventually become hapi in November of 2010 while working for Yahoo on a project named Sled. Sled was shut down almost a year later in August of 2011 and opensourced as Postmile which has been one of the primary examples of building a complex application in hapi since day one.

Later that same month, Eran created the hapi module as a collection of components extracted from Postmile that were used to build on top of Express. The name hapi was chosen as an acronym for HTTP API, but once it was spoken out loud, the connection to Ren and Stimpy was made. Eran later presented hapi to Walmart, where the effort was referred to as Blammo. After years of continued development, hapi has grown into its own unique and powerful framework with an outstanding and helpful community.

&yet started using hapi over two years ago and quickly became enamored with it. After nearly a year of contributing bug fixes, writing plugins, and being a part of developing the new site, I was made a core contributor in March of 2014. Since then I’ve been super proud to continue helping out the community any way that I’m able.

It’s been a while since I last wrote about testing WebRTC applications. And guess what? There has been some progress. We’re now using Travis-CI for integration tests in combination with Selenium for UI testing.

The usage of Travis-CI has been described quite a while ago by our rtc.io friends. It is now being used by adapter.js which has recently become a dependency of our core modules like getUserMedia and RTCPeerConnection since it shims the differences between browsers and is maintained by people from Google and Mozilla.

What Travis does is run a series of tests on every pull request. Thanks to travis-multirunner this is running the testsuite (located here for adapter.js) in different versions of Chrome and Firefox. If the tests pass and jshint and jscs don’t find any style nits, there is a nice green badge:

With the amount of content available for us to consume it's very hard to pick what to dive into. People read at different paces, often times not in their native language. At &yet, we are quite keen on reading too. There are many books that have made us laugh or taught us about design or technology; but only a few truly challenged the way we think and act—some of them to the point of knowing excerpts by heart.

Today I want to share five publications that shed a light on collaboration, as well as a range of social issues. Each of these books have helped make us better partners, friends and teammates—and above all, better humans.

Whether you read one or all of them, hopefully they will have the same profound effect on you as well.

"Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration"

Yup. You can describe animations in JavaScript and generates CSS strings of @keyframe animations and insert them at runtime using <style> tags.

Sounds a bit wacky right? Why would you do this!?!

Well... because it’s fun, of course!

Here’s what I built with these techniques: SEE THE DEMO

Thanks to you, our loyal Talky users, today we’re launching an all-new version that’s better, faster, stronger. (We can’t say harder, better, faster, stronger because actually we’ve been making it easier!)

Among other things we’ve added a few of the features you’ve requested most, such as in-session text chat so you can share links and other information during a call.

The big deal, though, is that we’ve upgraded the entire technology behind Talky so that you can meet with 15 or more people, at once. We’ve been using it regularly at &yet and it’s been great for our weekly full-team hangouts.

This version has been in beta for a few months now and it’s finally ready for prime time. We’ve also released an updated version of the Talky iOS app that works with the new backend technology so you can join a Talky room on the go from your iPhone or iPad.

A few weeks ago we talked about the need for private video chat and the challenges involved with making that a reality in a cloud-based environment. That’s why we’ve been working hard to build a version of Talky you can run on your company’s network to keep your voice and video traffic safely away from the public Internet.

We’re proud to announce that Talky On-Premise is now available.

Talky On-Premise takes the same ultra-simple experience you’ve come to love for video chat over the Internet, and moves it in-house. The installation is almost as easy as using Talky in the first place and the price is surprisingly affordable (as we like to say, the only thing astronomical about Talky is the rocket game, Lander).

As a part of continuous efforts to make our events as inclusive as possible we are very happy to announce diversity tickets.

How will diversity tickets work?

The tickets will work in the form of full conference experience scholarships (travel excluded) and we will be opening the application process in the coming weeks.

They are targeted towards members of underrepresented groups, which includes, but is not limited to: women, people of colour, LGBTQIA+ people, disabled people, and people facing economic or social hardships, who couldn’t participate otherwise.

At &yet we strongly believe that a better world not only starts at an individual level but also requires the effort from all of us. As we share not only our work but also process in the open we’d also like to do so with the diversity strategy we’ve prepared for &yetConf.

Code of Conduct and harassment prevention

Apart from focusing on designing an unforgettable experience our first and foremost responsibility towards everyone is enforcing a safe, entirely harassment-free, inclusive environment.

The presence of a Code of Conduct is fortunately (albeit slowly) becoming a standard for the event industry. At &yetConf all attendees, speakers and staff are required to familiarize themselves with the Code and follow its rules—that includes the main event as well as fringe happenings and social get-togethers. The contents of the Code of Conduct can be found both at &yetConf and Geek Feminism sites.

We're super excited to announce that we've added a new member to our team! Everyone, meet Sally Mohr!

Sally comes to us with a ton of experience in the business development and client relationship world. Oh, also? She happens to be an infectious fireball of energy and we're huge fans!

Sally's joining us as our new Director of Business Development. As &yet has grown and matured, we've seen a number of folks take significant roles in our business development activities, which has brought us to where we are, obviously, but we recruited Sally in order to double our ability to focus and put attention on these efforts. The passion and energy Sally has for cultivating and growing relationships between people and communities is remarkable, and exactly what we value across the board here at &yet, so it made perfect sense to add her to our team!

Isaac Lewis and Sally will work closely together to develop and strengthen our client relationships, our business development strategies, and our product sales strategies for requireSafe and Talky On-Prem.

Today we are announcing &yetConf, a conference about the intersections of technology with humanity, meaning, and ethics for people who believe the world should be better and are determined to make it so.

In 2013, we presented the most ambitious thing we've ever made: RealtimeConf. You can see the timeline of RealtimeConf experience outlined here. That event featured a novel by Mike Speegle that went on to win a Kirkus Indie Book of the Year award that led into a play that ran through the conference with original soundtrack by Ben Michel and a spellbinding original theme song by Alana Henderson. Oh, and there were a bunch of amazing presentations. And it all took place in a world we'd been slowly creating since the first RealtimeConf—one that left people saying things like, “All my expectations we're blown away. Wasn't expecting the level of artistry. Unbelievable, over the top and amazing.” (Emily "Nexxy" Rose)

As we've pursued bringing back RealtimeConf for 2015 and worked hard on some of the ridiculous creative things we have in store, the more we really felt constrained by the name. We really want to make something greater than RealtimeConf in all elements, and we don't want to be held back. Ultimately, we see conferences as a unique art form and we want to create an event unrestrained in its expression.

And so, we'd like to introduce &yetConf.

The Kickstarter for our video chat service Talky has come to a close. Unfortunately we didn't reach our goal, but realistically this was a truth we faced at the very beginning of this project.

What we didn't gain in funding we earned in observation and good ole fashioned market research. And we've learned a lot!

First, we have an amazing and supportive community who truly loves Talky and wants to see us succeed in our endeavors. Thank you so much if you shared our project, tweeted about it, sent it to folks, commented on it, reached out to us about it — you are the reason we put our hearts into our products the way we do. Thank you.

At &yet we often talk about our design and development process as being highly iterative. To iterate, as we all know, means to do something repeatedly. But doing something once, then again, then again, and again, doesn’t singularly ensure that the project is moving in the right direction. It’s the rounds of feedback, sandwiched between iterations, that ultimately dictate the quality of the product.

The thing about feedback is, when given effectively, it is literally the only thing getting you from shitty first draft to shipping a truly quality product.

The first step is asking for help

Before we talk about giving great feedback, it’s important to mention that feedback is made valuable not only by those who give feedback, but by those who seek it as well. Most often, rounds of feedback happen when someone on the team says, “Hey team, look at this thing I’m making. Help me make it better.”

tl;dr download the Windows 10 preview and test the WebRTC getUserMedia samples in the Microsoft Edge browser!

The WebRTC samples that are made available by Google's WebRTC team on GitHub are a tremendously useful resource for starting with WebRTC. They are so useful that this year my favorite answer on the discuss-webrtc mailing list has been "there is a sample for that".

The samples are grouped into three categories:

• getUserMedia samples which show how to use the getUserMedia API to access the microphone and camera,
• RTCPeerConnection samples which demonstrate the use of the RTCPeerConnection API to establish a peer-to-peer connection (usually within a single page), and
• RTCDataChannel samples which demonstrate the higher-level data channel API to send and receive data and files.

A fantastic, but often underused, feature of hapi is the ability to use scopes for authorization.

In many frameworks in order to specify who has access to what resources, you have to perform manual checks within your route handlers. This can be a hassle since often these checks will be performed in many different routes. Sure, we can abstract them into a plugin or middleware, but with hapi we don’t have to since it’s all built right in.

Want to specify a route that only admins can access? It’s as simple as configuring it like this:

server.route({
    method: 'GET',
    path: '/something/adminy',
    config: {
        handler: function (request, reply) {
            return reply('Hello there, admin.');
        },
        auth: {
            scope: 'admin'
        }
    }
})

One of our goals with Talky is to make the service itself and its underlying components as secure as possible. For example, as Bear explained recently, we use a variety of industry-standard encryption techniques, including strong cipher suites to enable Perfect Forward Secrecy whenever possible.

Unfortunately, encrypting video conferences end-to-end with more than a few people is difficult. The challenge is that in peer-to-peer, “full-mesh” mode, your laptop or tablet or mobile phone needs to encode and encrypt one outbound video stream for each person involved. This works well for one-to-one video, but even the most modern computing devices simply can’t encode that much video data if you have more than a few people in the session.

To overcome that challenge, a service like Talky needs to use a server in the middle (e.g., the Jitsi Videobridge) that accepts one incoming video stream and fans it out to all the other participants. Unfortunately, this kind of Selective Forwarding Unit has to decrypt the video streams that it receives in order to do its job.

We’re excited that one of our yetis, Henrik Joreteg will be teaching a Frontend Masters workshop on June 25-26 on Building Modern Single-Page Web Applications.

You can attend either online or in-person.

Here’s Henrik’s description of what he’ll cover in the workshop, but more imporantly, why:

Even the final feature set of the app you’re working on right now is probably a bit vague -- the future of the apps we build and the tools we use is vague at best.

Paul Irish dropped us a line about our Talky Kickstarter and asked:

Can you detail the open source plans? What parts of Talky are not open sourced right now, but will be from this kickstarter? What parts of Talky will not be released as open source components?

For starters, let’s be clear that Talky is not a simple turnkey open source project. It’s too powerful for that, and we want to put that power in developers’ hands.

One of the greatest lessons we can learn from watching internet platforms and applications grow in popularity is how crucial users' safety can be in utilizing those services. The safety of our Talky users is extremely important to us.

In keeping with discussing the security and privacy of our service, we also want to share our best practices for safety when using Talky. Below are some tips you can use to help ensure that you have great conversations with the people you choose, and avoid stumbling upon explicit, unwanted content.

Tip #1 - Don’t share Talky rooms publicly

By default all rooms within Talky are public. When two or more people land on the same link they will be connected with video and audio streaming to each other. Sharing a link to a Talky room via Twitter or Facebook is essentially inviting everyone else. To avoid having an Internet party with strangers, only share links via direct messages or other private methods of communication.

At &yet, we take privacy and security seriously. We even have a dedicated security team (Lift Security) that performs security audits for many well-known companies.

Talky security is more than just making sure the “lock” icon is present in your browser’s tab for your Talky.io session. It involves that, but also the connection between your browser and other people in the session, which can be direct (for one-to-one calls) or through the Jitsi Videobridge (for multi-party calls). Another aspect of security is what we do with any information gathered during the session, such as logging and log storage.

To answer these questions we need to examine the two primary ways Talky is used—making a one-to-one call with someone else or making a many-to-many call.

Next week, on Tuesday, June 2 at 10am PDT, ticket sales for RealtimeConf 2015 will officially begin! Early bird tickets for $1299 will go on sale.

What’s included

Tickets cover the following:

• admission to each day of the event
• three nights of accommodations
• six meals
• and a wall-to-wall experience starting when you arrive into town, so you don’t have to worry about logistics and can spend your time enjoying the conference and spare time activities

We’re continuing our series of Navigator Office Hours—next Thursday, June 4, I’ll be hosting a session focused on frontend development, design and community-related issues.

You might have heard me chat about technology at Shop Talk Show or recently on The Start.fm—this time we’re going to concentrate on frontend architecture; style guides, maintainability, all things HTML/CSS as well as topics circling around tech community in general, from running diverse events to enhancing team collaboration.

You can sign up here.

Talky is &yet’s premier plugin-less, just a link in a browser, group video and chat service. To add to the list of adjectives, we can also claim open standards-based, but not by inventing new ones.

So many services claim to be open, but roll their own API and call it open because they published a document; we didn’t do that. Our team has been contributing to real open standards for decades before we were even a team -- that’s part of why we recruited them.

Starting with WebRTC, the browser feature that allows us to do video, audio directly between browsers without a plugin, we get the core functionality of Talky, however not the intelligence of it. WebRTC wisely doesn’t include a means of signaling (connecting the call), so we’re left to “roll our own.” On the surface, this is pretty easy -- just set up a server that exchanges the WebRTC signaling payloads between the two browsers and let it go peer-to-peer -- but this is a very naive approach, and ends up being difficult to add features to, maintain, secure, and scale in the long run.

Did you know that group management, call signaling, presence, chat, federation, and all of those other features you might want to add later have been done before? Not only that, but these features have been painstakingly reviewed and iterated to ensure security, feature-extensions, and interoperability by large communities of professionals, and then documented as RFCs and XEPs.

Our Kickstarter has officially launched!

You can contribute to Talky — The First Truly Simple Video Chat project now.

Please help us spread the word!

For those of you with eagle eyes, yes we said we were going to launch it earlier this month, but when it came time we discovered we needed to tweak things just a little bit more.

Now we're ready.

I’m excited to share with you that at 10am (PDT) tomorrow, May 27, the Kickstarter for Talky will go live and so will the opportunity to help push forward both the open web and WebRTC.

Three weeks ago we announced the return of RealtimeConf and we couldn’t be more excited. While the conference still remains a curated experience (and you can see what we’re talking about in the 2013 recap on Vimeo) we’re doing something different this year—opening a Call for Speakers.

We’re looking for presentations on all the things related to realtime technologies and surrounding topics (not necessarily technical). Remember that this is an event meant to inspire and challenge the people pushing the web forward. Multiple submissions are more than welcome, and encouraged.

Need Help?

We’re committed to facilitating both audience and speaker diversity. If you’re a first time speaker, worry not—we’re happy to walk you through the proposal process and talk preparations as well. Check the submission guidelines or simply reach out through email or Twitter to request assistance.

The other day I was trying to add some functionality to a project I was writing some code for. It was a project with many people on it, and it was well under way when I got there. I was told that some of what I was going to be writing had been figured out already by another teammate, so I went to see what I could learn from their work.

Turns out, a lot.

You see, it ended up taking me about a day to ship the feature. But that day of work was built off of the weeks of work that my coworker had spent shaking out all the quirks, holes in documentation, and edge cases already solved when they worked on their part of the project.

They made my job look easy. It was tempting in hindsight to say, “Of course this is the way to do it,” after seeing their code. It wasn’t though. If they hadn’t laid the groundwork before me I’d have spent the same amount of time (or more) than they did just to get to where things were at when I started.

Next week on May 28th I'm going to host the second Navigator Office Hours focused around Node Security.

For the last 3+ years I’ve been focused on helping developers build more secure Node.js applications. We found a lot of patterns and tools that work and have done significant amount of research into the Node ecosystem, which I’ll briefly talk about.

I will also give a quick demo of requireSafe and maybe give a sneak peak of some features to be included in the upcoming release.

Most importantly, this will be a collaborative forum to get your questions get answered. I’m here to provide guidance and offer whatever help I can.

We’ve come long way from the simple static sites of the early web, yet somehow, I really miss it.

It was so awesomely simple to be able to write some HTML, CSS, and JavaScript, then FTP those files to a server somewhere and “Bam!” a site is launched!

Of course we can still do that for simple static content, but what about native web apps (a.k.a. single page apps).

Can we build apps as static sites?

&yet CTO Peter Saint-Andre will make a guest appearance tomorrow at 9 AM Pacific on episode 541 of the VoIP Users Conference, a weekly, live discussion about VoIP, SIP, Asterisk, WebRTC, and all things telephony.

Likely topics will include:

• Our plans for Talky, including the upcoming Kickstarter campaign
• Our experience with XMPP & WebRTC, the Jitsi Videobridge, and other parts of the Otalk platform
• How to improve the developer experience for WebRTC
• Where we are seeing the most activity in WebRTC applications
• Is the age of the general-purpose communications app over?
• Will we ever see federation with WebRTC - or just more silos?

Visit the VUC homepage on the Interwebs for all the details on how to join the conversation in realtime (video recording to follow).

This month, &yet’s lead WebRTC engineer Philipp “Fippo” Hancke has been invited to speak at Tokbox’s TechTok on May 21.

As a veteran software developer, messaging and distributed systems have been a passion of Fippo for many years. He is also one of the leading non-Google contributors to the webrtc.org WebRTC library, which is used by Chrome, Opera, Google’s iOS and Android WebRTC SDKs, and others.

This TechTok will focus on Failing gracefully with WebRTC, or everything you need to know about how to handle failures with WebRTC.

Register to attend TechTok here however, if you can’t make it to this event, Tokbox will have a limited number of virtual seats available so tweet at them at @tokbox if you’re interested.

Microservice is a buzz-word we’ve been hearing a lot of lately, however, it’s neither a new concept, nor is it a bad idea. Writing your processes as APIs in such a way that they can be run many times enables horizontal scaling and availability and has been a common best practice for quite awhile, but the subtleties of dealing with user information in a microservice should be addressed.

Authentication and Authorization

Each microservice should not have to do its own authentication, but it does need to do its own authorization. At Seaworthy, we like to run an openid-connect (an oAuth extension) service that handles logins and token generation separate from the rest of the APIs, which lines up pretty well with the whole microservice way of doing things. In the end, the other APIs receive the webtoken either directly or are pre-validated through a gateway. The API can safely assume each request is authenticated, but this doesn’t give us much in the way of object-level permissions (AKA authorization).

Each API should keep track of its own object-level permissions, and it can do so without anything more than a pre-validated userid or groupid. Simply record an object or row that has the id of the object, the id of the user or group, and a set of flags for which permissions they have on that object. That way, when a user tries to do an action on an object, we can join to the appropriate permissions object if it exists, and determine what the user can and can't do to that object. The point is, object-level-permissions exists in the microservice database store without extra user context.

When we set out creating services under the Seaworthy banner (our Node, Frontend and Ops Consulting services), we quickly realized that the best way to help you out was to be able to answer your questions (or at least be able to find you an answer).

Quickly we realized that we needed to better understand a number of things:

• What are the problems you’re currently facing?
• What does your workflow look like?
• Do you maintain a set of best practices?
• What are some of the paths you’ve already tried?
• Did you try turning if off and turning it on again? (Just kidding about that last one.)

So, in order to start those conversations, we created Navigator Office Hours, a weekly hour-long session hosted by one of the many experienced Node developers on our team.

Lead &yet WebRTC engineer Philipp “fippo” Hancke has been very busy recently examining the inner workings of some of your favorite voice and video services. Just a few weeks ago, he wrote up his findings on the popular chat app WhatsApp for webrtcH4cKS. And this week, we have an analysis of Facebooks Messenger service, which recently added videochat.

You can also follow the series of reports at andyet.com/webrtc-reports.

Later this month, he’ll be speaking candidly about more of his discoveries at Twilio’s SIGNAL Conference in San Francisco. In “WebRTC exposed: What we can learn from blackbox exploration of popular voice & video services” fippo explains the findings as well as the lessons that can be learned for WebRTC.

If you’ll be at SIGNAL be sure to ping fippo) or Peter to say hello!

This Thursday Ampersand.js and Human JavaScript author Henrik Joreteg is speaking at SeattleJS in—you guessed it—Seattle!

Fresh from his appearance at this year’s Fluent Conf, Henrik will be speaking to the crew at SeattleJS on his opinions about Native Web Apps.

Check out this quick interview from Fluent on Native Web Apps (or is it Single Page Apps??).

As founder, I (Adam Brault) have served as CEO of &yet since day one, and today we're making a change.

Our website says, "&yet is about people."

I believe priorities are what you do, not what you say they are.

We say that &yet is about people not as a cute feel-good line, but because we think it's the right thing to do, it's effective, and it works.

We want to make Talky into a fully open and people-friendly alternative for realtime communication on the web and on mobile devices.

But we don’t just want Talky to be an open alternative to existing video chat options. We want it to be the absolute best solution.

We’ve already added some of the key features you’ve requested to the beta version of Talky:

It gives us really deep joy to be able to officially announce that RealtimeConf will return in full force for 2015.

No, we aren’t telling you anything about it.

Yet.

Okay, we’ll tell you some stuff.

Yesterday Microsoft announced Vorlon.JS, an open source tool for remotely debugging and testing your JavaScript. The team behind it wants to make debugging easier, quicker, and more consistent for developers across multiple platforms.

That’s a goal we very much support and we’re excited we could play a role in getting Vorlon.JS ready for this release.

We’ve built and contributed to a handful of open source projects ourselves, so Microsoft asked us to help them in open sourcing Vorlon.JS. As open source veterans, Henrik, Philip, and Bear helped improve the developer experience of using the software and setting it up for community contributions.

Talky started as an interesting demo two years ago this February, but it became a product that has seen thousands and thousands of new users each month.

We believe Talky can be an independent communication platform built entirely on open-source technologies (both our own code as well as great projects like Jitsi, Prosody, and restund). We believe we can do it bootstrapped without VC funding or the support of a telco—and with security and your privacy in mind.

In fact, it already is all of these things!

Fippo and I gave a talk this week at Fluent covering:

• The basic fundamentals of WebRTC
• How easy it is to get started building an app with SimpleWebRTC
• What 'signaling' means
• Why IETF controversy over multiparty signaling led to ORTC
• What's different about ORTC and why telephony engineers such as Fippo like it (and why web developers won't care)
• &yet's future plans to support WebRTC and ORTC with SimpleWebRTC

Gar even was able to make a cameo appearance to kick off the talk with an acapella Stevie Wonder and Paul McCartney cover with some twisted lyrics:

WebRTC and ORTC live together in perfect harmony side by side on my laptop keyboard Oh, Lord, hopefully...?

Node has changed the way we write applications at &yet. Not just sort of changed, in fact, if it didn’t sound so cliché I would use “revolutionized” to describe it.

How so? Well, if I were forced to pare it down to a single word it’d be “modularity.”

Annoyingly, the word “modular” doesn't really mean much. Of course every developer strives to write modular code, so let’s disambiguate it a bit.

Modularity across applications

&yet has long been a rambling crew of professionals.

We love making products for clients, but we also love helping other teams solve particularly annoying problems or augmenting their talent with some of our focused expertise.

In spite of our penchant for bleeding edge technologies, we have an extremely veteran crew. Most of our engineers are more than halfway through their second decade in the software field, quite a few starting their third—and some longer than that.

When we set out to build a security consulting offering, we did so by creating a distinct division: ^lift security. ^lift has gone on to be a fixture of the Node community, leading the way in all things security.

Earlier today our friends at Digicoop released Kaiwa, a great new text chat app for the web with a super-friendly user experience. We’re keen on the fact it's built on top of some of the open source code we’ve been working on for years, such as the Stanza.io library for XMPP in JavaScript.

Yeti Lance Stout created a prototype application called Otalk.im along these lines a while back (as demonstrated at RealtimeConf 2013 starting around 16:45), and through the beauty of open source software the Digicoop team forked that code as the foundation for Kaiwa.

Congratulations, Digicoop!

Recently, Chrome’s WebRTC product manager, Serge Lachapelle, asked a critical question about WebRTC “product of the year” awards:

I see all these webrtc product of the year awards... And here I am wondering how come Chrome has not won one yet.

— Serge Lachapelle (@slac) March 25, 2015

We agree!

If you need a database feature, Postgres probably has it.

Recently, in versions 9.3 and 9.4, the Postgres devs have added JSON support in the form of JSON types, functions, and operators.

JSON functionality ends up being pretty handy for REST APIs, which I will get into in a later post, but it also has some other uses.

You may not have known this, but Postgres has Publish-Subscribe functionality in the form of NOTIFY, LISTEN, UNLISTEN. This is commonly used for sending notifications that table rows have changed.

Software should solve real-world human problems, and the most important problems will probably be the hardest.

Nowhere is this more apparent than when developers come face to face with people who depend on a software app for their lives.

I am currently attending the ISC Project's Global Workshop, which brings together technologists and activists from all over the world. Most of the attendees are activists from different communities across the globe fighting for human rights, political freedom, and independent media. All of them use technology to advance their work, but the choice of which tool to use requires vastly different criteria than societally privileged people typically consider.

Most of us answer "Which tool should I use?" based on some pretty simple criteria:

A training story

In three weeks, the &yet training team is excited to lead Fluent Conf 2015 attendees in three training sessions covering subjects like Native Web Application development, Node.js security, and WebRTC. One of our latest training offerings is Building Native Web Applications, led by Henrik Joreteg and Luke Karrys.

Henrik, prolific module creator, is a foremost developer tackling the subject of Native Web Applications (aka Single Page Apps) in the JavaScript community. He has pioneered many techniques for building stateful JavaScript applications, especially those with a realtime aspect.

User experience is very important to us. Almost a year ago, Chrome changed the way screensharing works in WebRTC in a way that increased the usage for Talky by 300%. Still, the onboarding process for your first screen share was not as nice as it could have been.

It used to be, if you tried to share your screen, you were required to install an extension. Once that extension was installed, you would have to reload Talky before you could share your screen. Until today, it was also necessary to click the "Share Screen" button again after the reload.

Now, after you've installed the extension, you're able to screenshare immediately, making the first-time experience faster and easier.

Hi! Remember this post introducing amp?

Unsurprisingly, JDD from the lodash project took notice. All things said and done, he made sure that in the 3.0.0 release they addressed all the concerns I mentioned in that post, which is great!

Specifically:

• Individually published, and semver versioned modules. This was the big one.
• Shallower dependency trees.
• Memorable names and not having to remember folder structure. All the functions are now available on npm as lodash.* where * is the function name. So, you can now just npm i lodash.bind for example.

We are excited to announce that in a month’s time, &yet is teaming up with O’Reilly to bring training to Fluent Conf 2015 in San Francisco, California.

On April 20–21, our training team will be leading three cutting edge two-day sessions on native web applications, Node Security, and WebRTC.

Henrik Joreteg and Luke Karrys, creators and core maintainers of Ampersand.js, will be teaching a course on “Building Native Web Applications.” The focus of the course is building a modern, well-structured application from scratch by combining best-of approaches and a carefully curated set of tools including Ampersand.js, React, WebPack, ES6, and Node.js. (Read more about our thoughts in Native Web Apps here.)

“Securing Node.js Apps” will be led by ^lift security Team Lead Adam Baldwin with Ampersand.js and requireSafe developer Michael “Gar” Garvin. This popular Node Security Training is a hands-on experience building, exploiting, and fixing security issues in the most used Node.js frameworks, templating engines and database drivers.

Today, we're announcing a public beta of the next generation of Talky - &yet's simple video chat and screensharing app for groups.

And, in a few weeks, we'll be announcing a Kickstarter. But more on that later—first I want to tell you about what's new in the Talky beta.

I hesitate to go all Jonny Ive on you, but seriously: the new version of Talky has been reconsidered, reengineered, and redesigned from the ground up. And everything we've been building has been open sourced as part of Otalk, our open WebRTC platform.

Here's the key improvements

Firefox is starting to roll out Firefox Hello to more users. Hello is a videochat, very much like our own Talky.

In the WebRTChacks analysiѕ, I described it a small button to your browser that generates a call URL which you can share.

A question by the palava.tv team got me thinking:

&yet is a highly distributed team, with yetis all over North America and Europe. To keep in touch, we use Talky on a daily basis for impromptu discussions among our teammates. Unfortunately, Talky doesn't quite work for our all-hands meetings because "full-mesh" media sharing only functions well when the number of people in the conference is small. To change that, we are working on an improved version that we've tested up to 20 people, internally known as Talky 2.

Last Friday we had another weekly update meeting and Talky 2 would not work - all the videos remained black. Switching from Chrome to Opera resolved the problem for a while, but at some point every participant in the conference had their browser crash. We had to switch back to Hangouts. Which was embarrassing.

What happened?

Crashing every browser (including Opera) was something I had been expecting. We had seen it before and currently it is being investigated by the WebRTC team. It is quite a serious issue and getting them more data to investigate what is going on helps. Showing black videos, on the other hand, was a behavior I had not seen before, so I went to investigate. I could not reproduce this behavior on my Linux laptop and It seemed to happen only on the Macintosh computer we use in our meeting room.

Recently, several members of our team participated in a week-long business simulation called Enterprise Week for a local school district. It was featured in an earlier post here and was also described in one of the December dispatches for our online community &you.

The week culminated with a touching and personal closing talk by former Enterprise Week participant, illustrator and yeti, Jaime Robles. We are very proud to now be able to present Jaime's talk to you.

Jaime Robles 2014 Pasco School District's Enterprise Program from &yet on Vimeo.

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!