Ramone

I droned on and on about it in a blog post once if you're interested: http://caines.ca/blog/programming/in-defense-of-the-office/ .

In my experience, it's waaaay more efficient for developers to be in the same room if you do it right, though I'm starting to think I might have a minority opinion on that.

We do this too, attaching req and res objects to a domain, as well as databases and other network related objects (like smtp clients, etc). This is a huge improvement, but I'm still seeing occasional uncaught error events in our logs on a very large codebase and only in production. Some of them are just ECONNRESET events with no details given, so their origins are REALLY hard to track down. Have you got some magic for catching everything without explicitly having to find all objects that could be emitting? I'd love to hear it if so...

I actually think I understood you, but I'm saying that in that case where statelessness should be an advantage, node.js is actually a much less fault tolerant environment when you compare it to most other web application servers. Most other web app servers offer

(1) request isolation (so most failures in one request can't break other requests) and

(2) a way to catch all exceptions/errors in a single request (and domains don't accomplish this, unless you know what to expect errors from, or wrap everything).

Since node.js doesn't offer those features, it's not even as fault tolerant as PHP was 15 years ago. I'm a huge fan of node.js, but one of the hardest things to do on a large application with a large number of users is to keep an instance of the server from restarting and dropping all the other in-progress requests. If you write your node.js code to be crash-only (like one might do with erlang) your clients are going to have a terrible time.

It's actually pretty silly to write node.js apps in a crash-only manner. Since they often handle thousands of connections concurrently, a failure in one client's processing is pretty horrendous if it brings down a whole server (even if the server thread gets immediately restarted). This project doesn't try to solve that either though.

I know you feel like you just explained its flaws, but there's nothing here that couldn't also be said about any other mainstream language.

I consider that to be a bright spot in this post. What would a performance comparison for this very specific app prove? The way I read it, the only goal of the rewrite was a more easily maintainable code-base with performance that was "good enough". It sounds like he was successful in meeting that goal.

With that said, comparing Python and Erlang on the basis of performance is a bit like looking for the world's tallest midget isn't it? Performance isn't the point at all, within a certain threshold.

That's actually a solved problem (in node.js at least). npm builds a node_modules tree where each package gets its own copies (with the correct versions) of its dependents. Gone are the days when people took on dependency hell for a few MB of diskspace.

There are a benefits, but most people won't notice them without first actually using a hypermedia API.

* It's self-documenting. Client developers can find all the endpoints just by clicking around (instead of reading mountains of docs).

* Client apps don't need to keep a list of hard-coded urls for random access, removing one of the most brittle parts of client apps (they should know about rels of course, but those end up being easier to keep track of).

Once you actually use an API like this, other APIs feel like they're in the stone age and how to do things with them seems like a continual guessing game. And it's still simple as hell -- remember it's just json with links. It's not like that requires a lot of extra effort.

GET being cacheable/idempotent is part of the HTTP spec, and has nothing to do with REST: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13...

Looks more like JS the java way. Singletons make no sense in a language that has global variables and never lets you stop an object from being duplicated. The command pattern makes no sense in a language with first-class functions. I'd steer clear of this resource if you want to write javascript the right way.

Well every team is different, so I shouldn't try to say I know the right thing for your team. What you're talking about though is farming out your branch builds/tests/deploys to jenkins, which has nothing to do with CI, but still sounds like your team finds it useful. Carry on if that's the case. While I wouldn't personally solve the problem that way, I'm wrong to suggest that jenkins should only be used for CI.

I'm saying a CI server is unnecessary for these branches that aren't ready to integrate with master. These are short-lived branches with 1 or 2 contributors, right? Just run the build/tests locally. There's no advantage to this overhead with branches that won't last longer than a day.

It sounds like we agree that long-lived branches are not continuous integration at least. We probably differ in that I think short-lived branches and pull requests are more overhead than most teams require. Keep in mind that CI does expect daily check-ins to master. That's how short those branches can live to satisfy that requirement. Anything else is not CI... which is not the end of the world either, but I don't see the point of using a CI server at all anymore. Just build/test your stuff locally.

But then it's not really continuous integration anymore is it? Having a CI server and practicing continuous integration are not the same thing.

The normal usage of the term "Lean" (ie from Toyota) actually has little to do with validated learning and more to do with the elimination of wasteful aspects of production that don't directly lead to customer value. Usually that means "pulling" work out of a team based on need rather than trying to anticipate need that might never materialize (like the need to scale workforce and infrastructure, which is the case here). FTA: "The idea, he says, is to be “global from day one and have scalability built in.”". Of course in any pull system, validated learning is built-in, because new customer demand is new information, but the focus of Lean is actually the reduction of wasteful production. He'll have wasted a lot of time/money if demand doesn't match the infrastructure he's built.

I think the argument that we shouldn't rely on the parser for certain language features is a bit silly (including interpreting end-of-statements). The language is precisely what the parser says it is, and nothing more or less. JSMin is free to not do what the parser does of course, but that won't be Javascript.

I think calling it "superficial beauty" undermines the quality he's looking for, which in my opinion is "human readability". A human has to make multiple passes to parse something like this, and that's entirely unnecessary.

It's really all about factoring. You'll notice now that you have model logic in your controller. If you want to reuse that elsewhere, you'll first have to extract it to another class. That class is effectively a SQL generation library, except it's not useful in a general sense and it's not as well tested. The more you do this, the more you converge on reinventing a full blown ORM.

I'm not saying there aren't downsides to ORMs, but the counter-arguments to SQL in your controller are pretty obvious.

Figure out how to log only what you want. Don't let your choice of an inflexible logging system affect your external API.

What do you get? Well many things, but specific to your inquiries: using GET tells the client of your API that the request is cache-able (for better performance -- a browser won't cache POSTs), and it tells that client that it's safe to call without unintended consequences. A search engine spider should be safe to just hit every uri via GET that it finds, because those are supposed to be read-only.

You're light on actual counter-examples and heavy on words like "shills", "hocus", "criminal", and "idiocy", so that most of your argument has to rely on your ability to paint TDDers as stupid or evil. The vast majority of thinking people will be unmoved by that.

Conversely, some might say that input from the user and output to the user are really the only important i/o.

Smart people are involved. What more do you need to know?

It's hard to buy the competitive advantage argument. Why open source it if that's the case? I think they must realize it's not a core part of their business.

I'll never understand how people can equate type correctness with value correctness, regardless of the language.

Well... God chose Ultraedit: http://www.ultraedit.com/company/IDM_full_story.html

;)

The article misses an important point: People who've done TDD know that it is the easiest/fastest way to unit-test. Few aspects of programming are more painful than trying to unit test code after the fact, especially if it was written without testing in mind.

The advantage really isn't in the ability to self-host. It's in the ability to find alternative hosts (ie, not a single point of control).

"Another way to explain this is to say that Agile can't make you succeed, but it's the fastest and cheapest way to fail."

Well said... That really cuts through to both the reality of Agile, and the key advantage.

Waterfall doesn't have multiple passes. You have to have all your requirements before you move on to design. And that has to be complete before you move on to implementation. That's why they use the waterfall metaphor, because waterfalls don't flow back up. And if waterfall seems completely braindead now, keep in mind that the old software guys used to be hardware guys, and it makes much more sense for hardware.

You're right about Spiral though... Spiral is iterative, so its much more compatible.

I think you'd find an agile sprint actually isn't a mini-waterfall at all. It'd be more accurate to say each story goes through its own mini-waterfall, but even that's wrong as the stages are almost completely different and not in the same order. For example, few teams write requirements beyond the story's acceptance criteria, specifications are almost never written, testing occurs throughout the lifecycle, and maintenance would come in the form of another story. They actually are very different methodologies.