&yet

We’ve been getting a lot of questions about the weird thing we’re doing on our home page. Most of them are some version of WTF? So I thought I’d share a little about what it is, why we’re doing it, and where it’s going.

I believe strongly in the potential of digital spaces to foster amazing communities. So many of the people I care deeply about, I never would have met if it hadn’t been for Twitter and blogging and various pockets on the Internet. But 2016 feels like the year when so many of the places I’ve hung out have devolved drastically. Instead of feeling like a safe, exciting place full of amazing people, it’s started to feel like a company of strangers talking (often yelling) at the same time.

It’s gotten me thinking about how to be more intentional about the way we connect with people online. Is it possible to do it better than we’re doing it now? How can we reject the defaults and assumptions of social media and invent our own way of being with others on the Internet?

A little over a year ago, I stepped down as CEO at &yet, and Eric (at that time serving as our COO) took that position.

Just recently, I've returned to the CEO role. I've done so first and foremost at Eric's suggestion and request, yet I am also quite excited to be able to do so. (Eric has a blog post coming soon about this, too.)

I am grateful for the significant effort Eric put into this role, in the organizational improvements he made during his time in it, and I'm even more grateful that he is willing to resume carrying the responsibilities of being our COO. I have immense respect for Eric and for the work that he's done.

When I stepped down, I did so in large part because I wanted to focus on the people of our organization and work to invest in and improve things for the individuals on our team.

When building out an API for a service, you may find yourself building at least parts of an API you’ve already written before.

You may find yourself
In another part of the world

This is often the time you should write it as a microservice and share it between several apps, right?

Last month Lynn introduced a blog series, Design for Developers, which we’re super excited about. In upcoming posts, you can expect to learn things like how to tackle the fear of the ‘blank canvas’, how to use typography effectively, and how to customize and extend commonly used design patterns in frameworks like Bootstrap.

But today we’re taking a step back and starting with a more fundamental question - raised by our friend Ivana McConnell on twitter - which is basically: “Why?”. Why should a developer learn design? This is a fabulous question! Thanks Ivana for reaching out!

Why does anyone decide to do anything?

February 28th marks the completion of 8 years of &yet being in business. Being a Leap Year, we realized we missed a great opportunity to make our company’s inception date February 29th.

At this point in our company's history, we're very excited to say this is our 8th birthday! We're the 8 year old that is excited about being a year older! And wiser! And better at things! Because that's what comes with age, right?

Almost universally, that's exactly what comes with age. Of course, those things don't come to us by simply watching time pass, it's what happens during that time that we earn additional wisdom, skill, and experience. A number of things have happened in the past year that I firmly believe will make us wiser and stronger as we proceed into the years to come.

In Postgresql, generally an incrementing primary key is used, which SERIAL is an excellent helper type for. Sometimes though, an incrementing ID exposed in an API or URLs reveals too much about the service, like the number of users you have (see the German Tank Problem).

You could use UUIDs for this, but they're long and obnoxious if you're exposing them to a user via URLs. Instead, we want a short string, say 8 characters in length, that is a cryptographically-secure, random value. We need a cryptographically-secure generator because otherwise someone could guess the generator algorithm, seed the previous value, and we'd again be vulnerable to the German Tank Problem.

Postgresql comes with an extension called pgcrypto that has a generate_random_bytes function. We'll use this to generate 6 bytes, giving us 2^48 possible keys, and then encode them in URL-safe Base64. The Birthday Problem probability table says that we can expect a 1% chance of having had a collision once we've generated 240,000 IDs, 25% after 1,300,000 IDs, and 50% at 20,000,000 IDs. So even after 20,000,000 IDs generated, we may only have had 1 collision. We'll use a LOOP just in case we hit a collision.

I talk a lot about designers learning development and in most discussions someone will inevitably ask, “Well, should developers learn design?” And to that I say, “Absolutely.”

A great deal of development work already is design work (don’t let anyone tell you differently). But I also know developers want to improve their visual design, UX, typography, and illustration skills. Here’s some tips on how to get started. Spoiler: They’re all things you can already do.

Node.js is an ideal middleware solution for enterprises, with its accessible JavaScript, event system, and vast range of libraries for working with data.

Sure, HTTP is a first class citizen for Node.js, but so are raw sockets and files. Compare this to Rails, which was for building dynamic sites, or Django's original focus on building content management systems. And sure, often times Node.js is the middleware that connects a database and a website (both realtime and not), but it's also great at connecting all sorts of static and evented systems together.

The battle for middleware has always been configuration versus scripting. With products like Oracle Data Integrator, Apigee's API Exchange, and many others, they lean all of the way toward configuration. But if you've ever used one of these projects, learning the conventions of the configuration is akin to learning a new language, so you might as well have the control of programming.

Document-Stores, Key-Stores, and Relational databases all have different use cases that they work best for, but there is quite a bit of overlap. What if we were to have the advantages of all of these databases in one hybrid database?

Postgresql can store and query JSON, and now has a PUT/UPSERT equivalent with INSERT ... ON CONFLICT ... DO UPDATE so we can easily use Postgresql as a Document-Store like CouchDB as well as being able to take advantage of normalized tables with the same data.

In this blog post, I'll walk you through some postgres wizardry to treat 3rd party data in postgresql like a document-store and show you how to normalize parts of that data automatically.

Docker is an amazing product. In a very short amount of time it's drastically changed (for the better) how we at &yet deploy our applications. With everything containerized, it becomes very easy to run an arbitrary number of apps on a small cluster of servers.

However, there's one big challenge with adopting Docker for our developers: it doesn't natively work on OS X.

There have been several solutions for this, such as boot2docker and docker-machine. These tools create and manage a virtual machine for you that runs the Docker daemon. This allows you to configure the Docker client to communicate with the virtual machine, effectively allowing you to use containers in OS X.

At the end of 2015, we teamed up with AT&T to write a blog series on UX and WebRTC. We’re excited about the future of communication on the web and hope these posts will help teams get started in creating enjoyable user experiences with WebRTC. Check them out!

Post #1: Getting started with UX and WebRTC
An introduction to WebRTC featuring reasons to include it in your application, a handful of questions to consider during the initial stages of planning, and the importance of consistency and seamless implementation.

Post #2: UX considerations for initiating and joining calls
The first major interaction a user will have with WebRTC is initiating or joining a call. This post covers questions to ask and decisions to consider when designing this part of the flow. How do things like buttons, text, and user expectations affect the experience?

Post #3: UX patterns for transparent voice and video calls
Next, here are some useful patterns and techniques for the voice or video call itself. What information or context could help the user during the call? The theme here is clarity and transparency.