Tales from the Evil Empire

Developing good software at a large scale requires the collaboration of several disciplines, that are not, contrary to your boss’ opinion, interchangeable. You need developers, of course, but you also need designers, PMs, QA, writers, usability people, localization, pointy-haired bosses, etc. There has been a tendency in some companies, however, to try to get developers to do more and more beyond coding, or even to magically transform test engineers into developers.

In Node, each module has its own copy of its dependencies, under its own node_modules directory. Each of those modules in turn can have its own dependencies under its own node_modules, and so on, in matryoshka doll fashion. This is not a bad way to deal with dll hell: module A can depend on a specific version of module B, and cohabitate within the same application with other modules that depend on another version of module B.

ASP.NET v.next is definitely an interesting beast. It’s open-source, developed in the open, and the team has clearly studied the competition, Node.js in particular, very closely. Its killer features, however, the ones that may be hardest to reproduce by others, are not new features: we already have them.

One of the main appeals of Node is how it encourages asynchronous code. You may very well write synchronous code in Node, but if you do, you’re not going to reap the benefits, and you should probably use another platform. I’ll talk in another post about some of the challenges associated with JavaScript asynchronous code, but there is one specific consequence that made me trip more than a couple of times while I was learning Node: it is very easy to create wrong expectations about when or whether a specific callback will get called, and then things can go really bad.

I spent a lot of time on planes last week (which explains why I haven’t posted anything), on my way to Barcelona, where Microsoft had invited me to talk on the .NET Open Source Showcase. It was a great experience and opportunity, and I hope I did justice to Orchard in the time I had to present it. I focused on what makes Orchard a success story, and how to reproduce that success on other open source projects.

I had a fun discussion with Rob on my last post, which led me to think about global variables and what we mean by “global”. Rob was arguing that a Node module is not strictly speaking global because it isn’t accessible unless you require it. That’s accurate, of course, but I’d still call that global in the sense that any code in the application that calls require will get the exact same object. The trick however is to only export from your modules constructors or factories. This way, the exported object may be global, but only in the same sense that a .NET class is a global object: everybody sees the same System.String, but it doesn’t matter in the least, because the string instances that you create from it are not global unless you make them. It’s still a little easier to shoot yourself in the foot in Node because functions and class constructors are ordinary objects, and the wrong pattern of exposing a singleton as a module is quite easy to write, but I’ll admit that it’s a mistake you’re probably going to make only once. So. On the same page here, I think.

I’ve been teaching myself Node over the last few weeks, by building a non-trivial application. In the process, I’ve been faced with a number of difficulties that I think are worth blogging about. First, let me say that I really like Node. It’s fast, powerful, smartly-designed, and has a liberating effect on my programming style. It is definitely trying to steer developers to a pit of success. It tends to do so, however, by surrounding the pit of failure with deep holes with spikes on the bottom…

It’s a simple thing, and it will make it immediately obvious when one of your files contains accidental indentation tabs instead of the spaces that should replace them, or trailing spaces. All IDE and code editors have an option to show whitespace. I always have it enabled. The subtle glyphs that will materialize the spaces and tabs are hardly noticeable while you’re working, except when something unusual is where it shouldn’t be: