Node.js can't use multiple CPU/Cores

I just install Ubuntu 10.04 and got Node.js up and running.

It's scary how easy it is to create a highly scalable web / socket application.

Don't get too excited yet. The gurus at Yahoo had this to say:

But all is not sunshine and lollipops in NodeJS land. While single-process performance is quite good, eventually one CPU is not going to be enough; the platform provides no ability to scale out to take advantage of the multiple cores commonly present in today's server-class hardware. With current NodeJS builds, the practical limits of a single CPU acting as an HTTP proxy are around 2100 reqs/s for a 2.5GHz Intel Xeon.

While Node is relatively solid, it does still crash occasionally, adversely impacting availability if you're running only a single NodeJS process. Such problems can be particularly common when using a buggy compiled add-on that can suffer from the usual cornucopia of C++ goodies such as segfaults and memory scribbling. When handling requests with multiple processes, one processing going down will simply result in incoming requests being directed at the other processes.


And lastly, Alex Payne sums up what large scalability and why node.js might just remain the realm of the less than skilled programmers.

http://al3x.net/2010/07/27/node.html

Threads are not dead!

This looks interesting for javascript : http://documentcloud.github.com/underscore/

CQRS and User Interface Design

I am beginning to have a shift in thinking about user interface design as I study the CQRS architectural pattern. The pattern really forces you to think about design UI’s around tasks.

You have to ask yourself, “Why would a user want to change the state of the system?”

Why would the user want to change the address of a customer?  Was it a mistake?  Did they move?  These might be important to know.  If they made a mistake and they have pending orders about to ship it might imply very different business rules.

It also forces you to think about the experience from the user’s perspective.

Udi Dahan said it perfectly during one of his talks: "User Interface design is as much a part of architecture as anything else that you do"

Google Hates Internet Explorer

Just went to look something up and was using IE. Google is advertising Chrome in IE but not FireFox.

Open Source Code Review - A choice to name a method "Inscrutable"?

I've been reviewing various open source projects related to Amazon S3 and discovered the excellent Resourceful library and the related project SpaceBlock.  The following code is a utility class in the SpaceBlock project. 

 

The method I found offensive was named "Inscrutable" and is located in the class named F.  The definition of "Inscrutable" from dictionary.com is "incapable of being investigated, analyzed, or scrutinized; impenetrable."  This reminds me of a quote I heard 25 years ago from an old mainframe programmer at Westinghouse.  I was complaining about the understandability of his VMS code and he said "If it was hard to write, it should be hard to understand".  I couldn't have disagreed with him more.  I believe in intellectual manageability of the code you write.  You don't write code for yourself or the compiler.  You write it for other people.  By naming a function "Inscrutable" you are flipping me and everyone else the bird! 

 

I guarantee this will happen to you one day (if it has not already).  You will be reviewing your own code for a bug fix and discover a particularly tricky piece of code that you didn't comment or name your function properly.  If you were so arrogant as to name your method "YouAreTooStupidToUnderstandHowThisWorksSoDontEvenTry" you will be essentially flipping yourself the bird!  You will then end up spending way too much time figuring out and reflecting on exactly you were thinking when you wrote that code.

 

Now, I'm not saying I'm not guilty of doing similar complexities with my code.  In fact, I can hear my co-workers now shouting over the cubical walls "Hey, isn't that the pot calling the kettle black".  I'm posting this as a reminder to myself and all developers to never do something this blatant and egotistic as this in our code.

 

I am not slamming these projects. I think they are well written and have a great coding style. I plan to use them in the future.

 

C# 4.0: Meet the Design Team

Anders and crew meet in the room where C# was birthed and talk about the future.

C# 4.0: Meet the Design Team