A rare re-post of our latest &you newsletter
This newsletter’s theme was supposed to be finding your place, inspired by Sarah’s move across the country. We likely would have shared something about the definition of “the good life” given by one of our heroes, Cheryl Broetje: living in the place you belong, with the people you love, doing the work that’s yours—on purpose.
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!
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.