You're right.

People with dwarfism are disproportionally not software developers, too, but it's not trendy to care about them, so DevBootCamp doesn't care.

Transgender people are disproportionally not software developers, but it's not trendy to care about them, so DevBootCamp doesn't care.

White males born into poverty are disproportionally not software developers, but it's not trendy to care about them, so DevBootCamp doesn't care.

Hey, DevBootCamp: What makes an affluent latina more important to you than an impoverished white male? What makes an affluent white woman more important to you than an impoverished Indian with dwarfism?

Your organization is toxic. Go away.

Hey, I'm not the biggest "diversity" cheerleader in the world, but I think this criticism is over the top.

There is a significant difference between an organization's stated rules and what you can make a phone call and get just for trying. If you belong to the category of not being a white or Asian man, give it a shot.

Being a sourpuss precludes working with people and figuring out what makes sense together. It isn't a good idea.

Thanks for pointing that out! This really is impressive.

Why not NonCodersCode?

There are plenty of poor, uneducated white girls and boys who could benefit from programs like this.

Oh, what's that you say? We already have enough people with their skin color in the computer science field? Shame on me! You're right -- ignore the white trash.

The (attractive, affluent, privileged) whites who enjoy ignoring white trash are right -- poor, uneducated whites are unimportant. In fact, poor, uneducated whites (especially the toothless ones) are less important and less worthy of help than attractive, affluent, privileged people with more melanin.

Are poor, uneducated whites less worthy of help than wealthy, affluent blacks?

If you believe so, you're a bigot.

Also, are poor, uneducated whites less worthy of help than poor, uneducated blacks?

I can't reply to your comment, so I'll comment here.

Let's think about some poor, uneducated white kids living in a trailer park without an internet connection. What should they feel when they hear of programs like this? "I'm not important enough to help, because people who look like me already have good jobs?" How should they feel about the myriad of programs and scholarships which explicitly exclude them?

At this point, being black isn't a disadvantage in-and-of-itself. Being poor is a disadvantage, and blacks are more likely to be born poor due in no small part to slavery. But all things being equal, being a poor white person is more difficult than being a poor black person.

And they shouldn't be excluded.

> being a poor white person is more difficult than being a poor black person

Evidence? I'd especially like to see a video of you visiting the trailer parks and public housing projects of America and asking people if they agree with that. I'm not sure which group would take more exception to it.

Regardless, as a former poor white person, I think it's bullshit.

Poor uneducated people (yes including whites) are a disadvantaged group compared to rich people. We should set up a group targetting them.

There are numerous advantaged and disadvantaged groups. Some people are in 1 or 2 or lots. We should try to end all disadvantagness. I don't see a contradiction.

>Are poor, uneducated whites less worthy of help than wealthy, affluent blacks?

Of course not, but in most cases poor uneducated white people are not poor and uneducated because of the racial dynamics. In a lot of cases, the poor black women are poor because of the racial and gender dynamics.

Why add the "white" qualifier?

Think about it: By many measures, all things being equal, it's actually (institutionally!) easier to be a non-white (non-Asian) male.

The all things being equal qualifier is extremely important, of course—being born white is correlated with being born middle-class with loving parents. But it in-and-of-itself, it does not make things easier.

If you are born black, it's less likely that you will be born middle class, and it's far less likely that you will have loving parents. But that's issue we need to focus on.

Being born white does not make your life easier. Being born middle-class with loving parents does. Love your kids—don't teach them to hate themselves (and their peers) if they're white.

Why add the "white"? Because in general, it's true.

Tell this to an unattractive, poor white male[1] who watches enviously as an attractive, middle-class black male is given a subsidized college education.

"Your life is easier because you're white. Feel guilty. Feel sheepish about any of your accomplishments, because they were made easier due to your lack of melanin."

Perhaps this white male – with his lack of melanin – has sun-damaged skin with several large, prominent moles, all of which contribute to his lower self-esteem.

"Your life is easier because you're white. Feel guilty. Feel sheepish about any of your accomplishments, because they were made easier due to your lack of melanin."

People in the past with his same skin color have done bad things, so belittle at him when he complains that it's acceptable and politically correct to be bigoted toward pale people. Call him backwards for feeling resentful and bitter. Remember, you are better than him—his life is easy.

Some people feel powerful and superior when they bash their perceived peers. John Scalzi is one of those people.

[1]: Excuse me—I meant "white trash".

not buying. an "unattractive, poor white male" will still have it easier then an "unattractive, poor black male".

Re-read the article. People do indeed get different numbers of "points" to start with, and the variation within a group is still bigger then differences between the groups, so someone can be black, and yet attractive, physically fit, extremely intelligent and from a wealthy family - a very 'easy' difficulty level to play at, and yet, replace 'black' with 'white' and it will become even easier still.

Congrats on the release!

I'd love to take this opportunity to dive into Node, but I have yet to stumble accross an effective way of organizing medium to large Node projects. What tools do you guys/gals use?

Late response, apologies..

Node is still young, and for its primary use case (multiuser/messaging-oriented apps) it seems like the actual LoC stays pretty low. However, here are some things I've picked up in my studies that seemed to make sense to me as an Express user. Keep in mind I'm still a relative nodenoob, so take this with a grain of salt..

- Keep the actual 'route code' (i.e., code that handles your end points) in a folder, named by the function: i.e., routes/login.js

- The overall route map (i.e., app.get()) lives in the main app.js file or routes/index.js

- Use underscore.js where possible; this raises the cognitive level of your code and its become a 'standard part' of Javascript to some degree. Unfortunately the Node repl treats _ as a special value, so you can't really test with it there. Kinda sucks..

- Use config.js to contain database settings, default port, middleware settings, etc.

- Develop the more complicated parts of your code in libs/. Think of them as open source components; keep them generic and disconnected from your app itself. This increases reusability (obviously) and testability. I think it creates better code overall. Some people even npm the core "hard parts" of their code! This is a really interesting and freeing strategy.

One thing to note is that there is no standard library. Most of your code will be dealing with modules. The most important thing is to get those dependencies right. Node comes with node package manager (npm), which is a great tool for the job. Still, be aware that you might be dealing with a lot of moving parts. Any tool that helps you with this should be worth checking out.

You should also check out modules like step or async, to make your chained callbacks look nicer. This way you will avoid long code pyramids.

Use a tool such as JSHint or similar, to detect errors and potential problems in JavaScript code. Try to integrate it with your editor or your complete development environment.

Regarding editors or an IDE, well, you basically have a standard pick here.

Although there is one interesting and somewhat new player you might want to check out - Cloud9 IDE, an online development environment for js and Node (amongst others). Since the code is available on github you can also deploy it on your own machines if the hosted options don't suit you.

I'd love to take this opportunity to dive into Emacs, but the past few times I've tried, it's felt like my keyboard was fighting against me. For those of you using Emacs on a Macbook (or an Apple keyboard), which key do you use for 'alt'?

I use the "Apple" key ...

Put this in your .emacs file

  (setq mac-option-modifier 'super )
  (setq mac-command-modifier 'meta )

I also use the System preferences to map the Caps-Lock key to Ctrl - A lot easier especially since a lot of keyboards tend to move the CTRL key around

The worst are the Thinkpad keyboards that have Fn where the left Ctrl should be. This is the sole reason I started to use Caps Lock for Ctrl and now I'm in love with it.

That's my favorite feature of Thinkpads: that means I cannot damage my pinkie any further :)

I remapped the Apple key for alt on my MBP. It truly is frustrating; alt is not in a very nice position at all. FN is where I would prefer ctrl to be.

When I really need to get writing at home, I plug in a MS N4K and go at it.

See the sibling comment by raju for the specifics, but you can actually bind the Fn key with the `mac-function-modifier' variable.

I'd thought for a long time that Fn was a hardware/OS-only key based on the lack of apps that use it, but it seems Emacs has found a way.

I use 'option', also labeled 'alt' on my keyboard. You can set it to act as 'meta' via your preferences. Use iTerm 2.

I use CarbonEmacs [1] on my Macbook. The default 'meta' is the cmd key, which I prefer, as it's closer to what I'm used to on other keyboards. I also remap (globally) caps-lock to be a second ctrl.

[1] http://homepage.mac.com/zenitani/emacs-e.html

For the record, Carbon Emacs is Emacs 22, which is very old (c. 2007) and deprecated.

I pretty much only use emacs on a mac. This means I don't care about having a keymap that is the same on a linux box.

So, I use option for 'alt', but here's the great thing. You can use the command key for other stuff! I've got keybindings for my most common actions.

command-j -> ido-find-file

command-d -> anything

etc

I use the Apple key as Meta and the Caps Lock key for Ctrl. On a Linux box I use the Alt key as Meta and the Caps Lock Key for Ctrl. With this setup the keys are in the same location for every keyboard and I don't get so confused.

Alternately, go the Steve Yegge way and rebind meta to C-x-C-m and C-c-C-m:

  (global-set-key "\C-x\C-m" 'execute-extended-command)
  (global-set-key "\C-c\C-m" 'execute-extended-command)

These bindings are only for M-x. This is still useful (M-x is really common), but it's not a full replacement for all meta bindings.

Exactly. The problem with keyboards is that the alt key is right under your thumb, right where Ctrl should be. You might take a look at http://xahlee.org/emacs/ergonomic_emacs_keybinding.html , which is a remap of common emacs keybindings to fit underneath the alt key.

Sure, this is an invasive change, but it saved me from RSI.

Esc

option

I use option like the others have said. I am like you, diving into Emacs; in my case purely for the swank/slime lisping environment.

It's been pretty difficult as I am a dyed in the wool VIM user. Someone on HN recommended the Evil plugin (http://gitorious.org/evil/pages/Home) for an approximation of VIM movement and other bindings. It surprisingly works pretty well. It's letting me remain productive while I slowly adapt to the emacs key-bindings over time.

I am using emacs-prelude as well (https://github.com/bbatsov/emacs-prelude) which is a startup scripts kit.

I'm still not sold on emacs yet, but I am giving it time.

I've been using Evil for a couple of months and love it. I switched from Viper+vimpulse and haven't missed a beat. It works really well and was easier to setup. Any VIM user considering Emacs should give it a shot - the best of both worlds, really.

I've been using evil mode and don't really see why you'd even want to move away from the vim bindings. Get the best of both worlds, the nice vim movements and model editing, plus all the nice emacs packages and being able to use elisp instead of vimscript.

I had the very same thought.

This mentality is fine if you don't want to (or have to) maintain and support anything—and from looking around the author's site, it appears he makes dozens of small things and then leaves them to rot.

Making dozens of quick things to try them out (and then abandoning them) isn't such a bad strategy when searching for a good business idea. Obsessing over the backend of an mvp might be a net negative.

And if he had spent time obsessing over internal code details would the project rot less?

Things change fast in software. It's one thing if you're building the backend system behind a billion dollar bank. Obviously that's not what the author is talking about.

If you're trying to make the next Angry Birds, or Facebook, or Google, you need to get something out there now, the MVP, and iterate.

What's the purpose of complex testing frameworks like this? What's wrong with using a simple framework whose tests must simply return a bool?

For example:

         var myObject = new Something("foo", "bar");	 
	
	 assert("simple operations", function() {
		return myObject.doSomething() == "baz";
	 });;
	 
	 assert("post-operational state", function() {
		return myObject.state() == 123;
	 });;
	 
	 assertAync("async polling", function() {
		return myObject.poll().length > 0;
	 });;

Note that those tests would be much prettier in CoffeeScript.

Is the purpose of heavy testing frameworks purely for the useful functions like "deepEquals"? If so, why not make a library with functions like "deepEquals" and use that library with a simple testing framework? Surely, there must be something I'm missing.

Edit: I should note that the beautifully written CoffeeScript compiler/translator doesn't use a testing framework (favoring a few simple hand-rolled functions), and it has a massive suite of tests.

One advantage is debugging failures. If the test framework only knows that a test passed or failed, but not why, then you don't get to know why either, because it can't tell you.

For instance, many test runners will show you the expected and actual values when a comparison fails. If they're large blobs of text, it can show you a diff, etc.