I’ve been asked by a few people for my thoughts regarding the ‘gendered pronoun’ incident that’s occupying the node community this week. I am purposely not linking to that thread. I appreciate Ben Noordhuis contribution to node, and I think that contribution merits a more nuanced response from me than a Twitter one-liner.
First, because it is worth saying, there is no argument that Ben is a very smart guy, has made a significant contribution to node and libuv, and has been tremendously generous with his time and talent. I do not believe the node community is “better off without him”. I hope he comes back.
To me, this is the core of the issue: Ben has an established history of dickishness. This attitude has been tolerated by the node community longer than anyone else’s inappropriate behavior because of Ben’s clear talent and contribution. But this is never sustainable and at some point, one more slip is enough to cause an uproar, and this is what happened here.
If the response from individuals and companies feel exaggerated and over the top, it is because for many insiders, this is not a single incident but the last straw. Whether that is fair or not is a matter of opinion.
I witnessed this behavior in a response to a node issue a member of my team opened a few months ago. I sent a private letter to Ben’s company explaining why I felt it was inappropriate and offensive. The response I received suggested that this was simply a result of Ben’s work load and his need to sort through many issues quickly. I was unsatisfied and expressed that. Shortly after, Ben corrected his behavior on that particular issue and provided thoughtful and patient feedback.
There wasn’t an apology or an acknowledgement of wrongdoing, and that stuck with me. Ignoring all the ‘gendered pronoun’ debate, what is really at the core of this incident is lack of empathy. It’s failing to say a simple ‘sorry’. It might sound trivial or petty but the incident a few months ago left enough bad taste in my mouth not to want to engage Ben further. I’ve actively directed my inquiries to other members of the node core team.
Ben is by no means unique in his attitude. I am sure half the people I interacted with when I was working on that “awful 2.0 security protocol” feel the same way about me. But when I offend people unintentionally, I immediately apologize publicly and privately, and when I choose not to, it is done with the clear understanding of the repercussions. When I quit that working group, the negative reaction I received was very much earned by my actions.
Every community has to decide what is acceptable behavior within its boundaries and especially what it allows its leaders to do. Whether it is an open source project or the workplace, there is always a balance between someone’s attitude and contribution. One often does counter-balance the other, but only to a point.
My behavior within the node community is in sharp contrast to that of my behavior in other communities. It’s not because I’ve changed, matured, or evolved. It is simply because it is the only acceptable behavior within the node community. Context matters.
Ben had multiple opportunities to back out of the corner he put himself in – and he still does. It really doesn’t take much. At least not in word count. People are just looking for some empathy, for acknowledgement that their feelings were hurt, and that the offender understands and regrets their actions, especially now that they know how offensive it was to people.
I hope Ben comes back from his break and continues to contribute. And when he does, it will be our turn to show empathy and move on.
Download the slides as a PDF document.
For the past 2 years I have had the pleasure (and luck) of working with node full time. It’s an amazing technology and a remarkable community. Oh, and it’s crazy fun. My focus this year was rethinking web services at Walmart Mobile, from the business layer all the way down to the tools and process we use. A significant part of this effort focused on developing hapi, a new web services framework for node.
But before I write my traditional ‘Introducing’ post, I wanted to first discuss the evolution that led us to build a whole new framework. To truly understand the judge a new framework, it is important to understand the context and objectives leading to its creation. Continue reading
Another adventure begins.
Two months ago I’ve joined @WalmartLabs to lead the mobile web services team. Surprised? I was. After working for one of the largest web companies in the world, all I wanted to do was go to a startup. That’s not exactly right; I wanted to be part of a tiny team with a big mission, a place where the size of the challenge is matched by the freedom and resources to address it. Oh, and a lot of node.js!
I am excited to share this and tell you all about it, especially on the heels of this morning announcement of the acquisition of Small Society. But I’m not going to lie to you: I have an agenda and I am trying to recruit you. If you are contemplating a career move and I “had you at node”, feel free to jump right to very end of this post to find more about the team we’re building.
As is often the case when working on a startup, virtual or not, things don’t work out according to plan. I had the privilege to spend the past year working on Sled, from product inception to execution. At the same time we were launching Sled, I experienced some significant management changes at Yahoo! which eventually led to shutting it down. Continue reading
I’ve spend the past week participating as a judge in the 2nd Node Knockout competition – a 48 hours worldwide hackathon using node.js. The event included 720 contestants organized in 294 teams and resulted in 178 entries submitted for review. Overall, a fantastic event and a testament to the awesomeness that is the node community.
The competition includes prizes for the best hack in the following categories: fun or utility, design, innovation, completeness, popularity, and overall, as well as overall for a solo participant. While judging is still on-going, and while many of the top entries do deserve to be there, I found the categories to be a bit uninspiring.
Also, as the only crazy person to judge every single entry (including some that dropped out in the process), I wanted to highlight some entries that might not get the attention they deserve. The following are the nominees and winners in my unauthorized awards.
There wasn’t much of selection 6 months ago when I started coding Sled when it came to Node frameworks. Node itself provides very little. You create an HTTP server and get a callback when a new HTTP request comes in. Modern web applications require session management, request routing, and view rendering at the very least. These functions are provided by frameworks.
At the time, the only two popular frameworks were Connect and Express. Connect provides a basic middleware framework with some built-in facilities such as a static file server, route management, cookie parser, form-encoded and JSON-encoded body parser, and logging. Express, built on top of Connect, adds a much more robust routing facilities, view rendering and other goodies. I’m not doing these frameworks justice with this descriptions.
I use Express extensively and it is fantastic.
Express’ biggest asset is its maintainer, TJ Holowaychuk. I have seen first-hand how Express grew and matured into a stable and powerful framework. Express made it easy for me to write the application server used for login, registration, account management, and other static assert (developer pages, about) with very little extra effort. If you are going to develop a traditional web application in Node, you should probably start with Express.
I plan to open source some of the additional functionality I’ve added on top of Express to validate request bodies and query parameters, a flexible authentication configuration facility for routes, and a light layer to make it easier to building API servers. Given my focus on OAuth, I’m going to share my OAuth + Express experience in a followup post.
Express really shines when you combine it with Jade, another brilliant brainchild of Mr. Holowaychuk – a simple templating language for HTML which is easy to learn, easy to read, and unlike all the rest, doesn’t suck. We had to restrain ourselves from converting some static HTML files into Jade because once we started using it, we didn’t want to read actual HTML ever again.
Socket.io is Magic
I am willing to bet that a large percent of those taking a look at Node for the first time are doing it because of a Socket.io -powered demo they have seen. Socket.io provides a trivial-to-use server and client library for making real-time, streaming updates between a web server and browser client. It makes building cool real-time games a matter of hours, and it works on every crappy browser known using the best available option from Flash to WebSockets.
We use Socket.io to power Sled’s real-time features which include live updates to your shared list as changes are made. To put this in perspective, it took us one day to add real-time streaming updates to the API server, and another day or two to add it to the client. So in three days we got full, real-time updates going between multiple browsers. What used to be months of work when Google Docs was first introduced, is now trivial with Socket.io.
So yeah, it’s magic.
Socket.io comes from Guillermo Rauch and the team of superstars at LearnBoost. There are days when I have to wonder if these guys get anything done for their own startup, given the amazing open source projects they push out on a weekly basis. I’m bummed that I’m not the target audience for their product because looking at the technology it must be amazing. I consider them part of the Sled team, given just how much of their code we are using.
In fact, I appreciate their work so much, I’d like to get a small fundraiser going to send these guys to dinner or whatever else they feel like doing for fun. I hope you join me in showing our appreciation. Without their continued work and dedication, Node would be an amazing platform that is just too raw to use.
Thanks to Blaine Cook for the idea.
Working with CouchDB was fantastic. It took no time to learn the REST API and jump right into building the application. I had the first version of the base API ready in 2 days, including full database integration. Couch is a document store using JSON as the document format. Combined with an HTTP REST API, it makes Couch an ideal fit for Node. That’s exactly why I picked it.
I dismissed MySQL from the very beginning for two reasons. First, I had no idea what my schema would look like, and knew I was going to change it a lot over time, as well as allow unstructured data. Second, MySQL is a block database in nature (e.g. database deadlocks, atomic actions, etc.) and while you can use it with Node, it really wasn’t designed for this kind of environment. Also, at the time, there was no quality driver for Node. Oh, and I really wanted to play with a NoSQL database.
I started talking directly to the database but within a few hours switched to use Cloudhead‘s excellent cradle module. The module provides a light layer for managing the HTTP client calls, error handling, simple caching, and common macros for performing multiple database requests in a single function call. It is a very light abstraction layer (and it doesn’t abstract too much either). This worked very well for a few months. I didn’t use cradle’s built-in cache because of the expected size of my database and my constant tweaking of data manually.
Node is all about non-blocking, asynchronous architecture. This means any activity taking a long time to finish, such as file access, network communication, and database operations, are requested and put aside until the results are ready and returned via a callback function. Instead of asking to read a file and waiting for the operating system to come back with a file handler or buffer, the a callback function is invoked when the operation is completed, freeing the server to handle additional requests.
What gives Node a bit of a negative reputation is how this architecture affects its style of programming and the difficulty some people are having in getting used to it. When I first started, I described this convoluted style of coding like scratching your right armpit with your left hand by twisting your left arm over the shoulder, behind the neck, and under the back of the right armpit. There are days when it still feels like that, but at least now my arms are much more flexible.