&yet

People have a very special distaste for telecoms.

Between wiretapping, egregious data roaming and text messaging charges, the unreadability of our phone bills, and carrier lock-in, we have plenty of reasons. Add in the fact that we consider ourselves entirely dependent on them and we're all the more resentful and cynical.

But forget the traditional telecoms for a minute.

Google, Microsoft, Apple, and Facebook are truly the new telecoms—each within the last few years has built or bought a communication platform of their own.

Wouldn't it be cool if someone built a federated, interoperable, open source, and super hackable "Skype killer" built on WebRTC and XMPP and released it at RealtimeConf?

I had the privilege to attend EdgeConf 2013 as a panelist and opening speaker for the Realtime Data discussion.

It was an incredible, deeply technical conference with an interesting discussion/debate format.

Here's the video from the panel:

Hapi is a web framework created by Walmart Labs that has many bells and whistles, including built in support for input validation and authentication, as well as a powerful plugin system.

In this online course, Introduction to Building APIs with Hapi, you will learn how to create a simple API, including query parameter and payload validation. We will also look at how to load and configure plugins.

Plan on spending some time on September 25, 2013 say, around 11am (PDT) with Nathan LaFreniere, our resident dev/ops badass, as he guides you through Hapi land and leads a Q&A to fill you in on any lingering questions.

LaFreniere is an endlessly talented developer with expertise in both building custom production systems and supporting complex realtime web apps. He's also created and contributed to a number of open source projects, many of which have become fundamental to our development process at &yet.

Our response to another dev community's vulnerabilities says more about our personal insecurity than it does about their code's insecurity.

Full-stack web developers are generally a smart bunch—some exceptionally so, especially when you consider the increasing amount of complexity that must be navigated to build a modern web application.

Developers are universally defensive about the security of their code—and even moreso, their chosen tools.

Over the past year, there have been widely publicized vulnerabilities in Rails and Ruby. We've admittedly seen developers in other communities point and laugh. In turn, the Node ecosystem has seen its share of vulnerabilities, including one that a couple evenings ago generated a prominent Twitter dustup between leading developers in different communities (which I'm intentionally not going to link to).

We are canceling RedisConf 2013 due to lack of interest from attendees and sponsors.

We have contacted the handful of ticket holders and we will be doing our best to help them work out their preferences.

Ben Arent is still going to put together a great (but informal) Redis get-together on the same date in Portland, tentatively including a Redis hackathon in the morning and a meetup with talks in the afternoon where Salvatore Sanfilippo will be giving a full-length talk. These will be followed by an invitation to the RealtimeConf opening party.

(One good thing is most everyone interested in RedisConf is also interested in RealtimeConf. In fact, there are only a couple of people who bought a ticket to RedisConf without accompanying it with a ticket to RealtimeConf and we're offering them to convert their RedisConf ticket to a full RealtimeConf ticket, saving $300.)

Web technology and security change so rapidly it can be exhausting to keep up.

We like to have lunch-and-learn type meetings at &yet to help keep each other in the loop on what we're learning. In the spirit of these timeless "brownbags," we've decided to create a series of short, introductory online classes.

These bite-sized online classes will be focused on giving you a quick introduction to a topic and the chance to ask questions.

The first class, Securing a Node.js Express App, will be taking place next week on Wednesday, August 28, 2013 at 11am Pacific Time with your guide Adam Baldwin, &yet CSO, ^Lift Security team lead and founder of The Node Security Project.

First—some important news: We've changed the dates.

Early this year, we announced dates for RealtimeConf, RedisConf, and a brand new, WebRTC-focused event. A short time later, our friends at LxJS announced their dates—which were unfortunately the same. We immediately reached out, discussed the mix-up, and determined that we were in the best position to change our dates.

After getting back to the states after being part of a wonderful first-time RealtimeConf EU smashingly organized by Julien Genestoux, we've reset dates and, in the meantime, we've made tremendous headway on conference planning.

Last year, we had a full week of Realtime events and we're just ramping that up a notch, by adding a full day focused on the most exciting realtime technology to hit the web: WebRTC.

We’re happy to be able to announce Karolina Szczur (web, Twitter, GitHub) has joined the &yet team as lead interface designer/developer.

We’ve been familiar with (and in awe of) Karolina’s work for some time and it’s quite an honor to be able to add her to our team.

Karolina has been published in .Net Magazine, served as Editor at Smashing Magazine, and spoken at numerous JavaScript and design conferences around the world. She is also the former UX lead for Nodejitsu and has contributed design to The Node Firm, NodeCopter, and many open source projects.

Protocol buffer encoding is hard.

I really wanted to use them, though, seeing as there's a pretty significant speed increase when you don't have the overhead of HTTP.

Unfortunately, no one had written a node.js library for it. A couple of C bindings existed, but when I tried to use them, they either didn't even compile or I couldn't get them to work. That's when I had one of my all-too-common breakdowns, and decided to write my own. After all, anything for the sake of increased performance, right?

Using Google's specifications, I got started. In order to use protocol buffer encoding in any language, you have to start by writing a definition file to describe what messages exist, and what they contain. That definition is used for both encoding and decoding packets.