&yet

In just a few weeks on April 30th, the ^lift security team will host their first secure development training on building secure Node.js web applications in Portland, Oregon.

The ^lift team has designed this training to help you understand the security challenges you will face when developing Node.js web applications and help you build habits that turn security from a worry or an annoyance, into a comfortable part of writing your code from the very beginning.

Seats at this first class are extremely limited, so grab your spot with the team that’s been trusted to secure tools you use everyday like npm, Github and Ginger, as well as leads the Node Security Project. Also discounted tickets are available if you want to bring your dev team (or hack the system and bring a couple friends, we won’t tell anyone).

So Heartbleed happened, and if you’re a company or individual who has public facing assets that are behind anything using OpenSSL, you need to respond to this now.

The first thing we had to do at &yet was determine what was actually impacted by this disclosure. We had to make list of what services are public facing, which services use OpenSSL directly or indirectly, and which services use keys/tokens that are cryptographically generated. It’s easy to only update your web servers, but really that is just one of many steps.

Here is a list of what you can do to respond to this event.

The setup

Eleven days ago, Jon Lamendola was asking Adam Baldwin in our team chat how to do something with JavaScript. The discussion went like this:

---

Today we’re honored to welcome a few new amazing individuals to the &yet team.

Here at &yet, we strongly believe that each person who joins our team should fundamentally improve what it’s like to work here. We also count on our new teammates to help lead us toward being the type of company we want to see ourselves become. So you can bet that we take extra care and consideration when adding new folks to the team.

Here’s a tiny (but brilliant) glimpse of the direction we’re heading, represented by the newest additions to &yet team:

David Dias

Are you frustrated over how much of your JavaScript code is dependent on too few members of your team?

Our team was there too. Over time, we’ve built a set of practices that have helped our team and clients write complex but sane JavaScript apps without depending heavily on one or two people.

Using approaches Henrik Joreteg and &yet introduced in Human JavaScript, after just two days you and your dev team will walk away with a practical, more sensible path to building JS apps. And your code base will look like it was written by one solid JS dev.

Introducing JS for Teams, a clear and simple approach to building complex JS apps—but it’s a bit more interesting than that.

When I was 17, two things occurred which changed my life forever.

My grandfather passed away and left me a book by John Lomax entitled, Cowboy Songs, and I discovered Pete Seeger’s seminal “American Favorite Ballads” record series produced by Smithsonian Folkways.

Growing up as a ranch-hand in Silver City, New Mexico, the “real” history of the American cowboy was always important to my grandfather, and Cowboy Songs was one of the only genuinely untainted collections of that oral tradition with lyrical content that wasn’t screened or edited by its publishers to be “safe.”

As more and more people are enjoying the Internet as part of their every day lives, so too are they experiencing its negative aspects. One such aspect is that sometimes the web site you are trying to reach is not accessible. While sites can be out of reach for many reasons, recently one of the more obscure causes has moved out of the shadows: The Denial of Service attack. This type of attack is also known as a DoS attack. It also has a bigger sibling, the Distributed Denial of Service attack.

Why these attacks are able to take web sites offline is right there in their name, since they deny you access to a web site. But how they cause web sites to become unavailable varies and quickly gets into more technical aspects of how the Internet works. My goal is to help describe what happens during these attacks and to identify and clarify key aspects of the problem.

First we need to define some terms:

A Web Site -- When you open your browser and type in (or click on) a link, that link tells the browser how to locate and interact with a web site. A link is made up of a number of pieces along with the site address. Other parts include how to talk to the computers that provide that service and also what type of interaction you want with the web site.

Last week, Eran Hammer came to the &yet office to introduce Hapi 2.0.

Hapi is a very powerful and highly modular web framework created by Eran and his team at Walmart Labs. It currently powers the mobile walmart.com site, as well as some portions of the desktop site. With that kind of traffic, you could definitely say Hapi is battle-tested.

Hapi's quickly becoming a popular framework among Node developers. Since mid-2013, &yet has been using Hapi for all new projects and we've begun porting several old projects to use it, too.

Before he started his presentation, Eran casually mentioned that he planned to at least touch on every feature in Hapi, and boy did he succeed.

It's an honor to introduce Peter Saint-Andre as a new member of our team and as the CTO of &yet.

Peter has a long history of leadership in Internet standards as an IETF Area Director, Executive Director of the XMPP Standards Foundation, and his involvement in standardizing technologies like WebSockets and OAuth. He's among a handful of people who've (with quite little fanfare) helped pave the Information Superhighway™.

His experience and involvement with Internet security, distributed systems, and collaboration is a boon to our team as well.

Peter's one of the original members of the Jabber, Inc. team who created the most widely distributed protocol for realtime communication (XMPP). He's given over a decade of deep consideration to the ways people use technology to collaborate and has a personal passion for making that better.

It used to all make sense.

The web was once nothing but documents.

Just like you'd want some type of file browser UI to dig through files on your operating system, obviously, you need some type of document browser to view all these web-addressable "documents".

But over time, those "documents" have become a lot more. A. lot. more.