I'd like to set some tone before I begin, primarily because I'm typically pretty bad at maintaining my tone throughout the course of a long response. I'd like to say that Eran Hammer holds a place on a rather short list of people that I particularly respect in the node community. He's been vocal on a number of issues, and I've always admired his ability to articulate and reason clearly through the various drama-llama moments that this community seems prone to.

It was with some surprise, then, that I read his reaction to the news that TJ Holowaychuk has sold ownership of the Express project to StrongLoop.

I'd like to be clear that there are aspects of this transfer of ownership that I'm not terribly fond of either. However, even when not in total agreement, it's important to approach situations with fairness.

Ok, with that as context, I've in-lined my thoughts below:

Last month the V8 team landed an initial implementation of ES6 Generators. Generators, of course, are nothing new - they first appeared in the CLU programming language back in 1974. Today they're available in several modern programming languages, including Python, C#, and Ruby (see the wiki article for a more complete timeline of language adoption).

Given that Node.js is built on top of V8, the inclusion of generators has, well, generated quite a bit of buzz in the world of Node. This is with good reason, too. In this post I'm going to attempt to explain what exactly generators are and why their addition is such a big deal in JavaScript (and more particularly, Node).

While opinions regarding the perils of callback hell (or the ominous sounding "pyramid of doom") vary greatly, it's hard to deny that every once in awhile some library support comes in handy.

After sifting through a dozen-or-so control flow modules, however, it is abundantly clear that callbacks are unavoidable. You can wrap them in promises, chain them, and even get funky with them, but you're still passing around functions to get the job done. The reason for this is quite simple - without using functions, JavaScript simply doesn't allow you to "pause" execution, wait for something else to complete (such as a database query), and then resume where you left off.

Or does it...?

Today I'm happy to announce a new, experimental module for Node that I've been hacking on: suspend.

Last week DevSmash went down for what I believe was the first time since I launched it back in September. The first thing I did was check out the Nodejitsu status page, which indicated that all their services were up and running. Since I was already hanging out in the #nodejitsu channel on Freenode, I mentioned my issue and was informed that MongoHQ (which Nodejitsu provides to customers for free) had experienced some hardware failure. Fortunately, the fine folks over at MongoHQ had things fully recovered within about 20 minutes, which represented the sum total of our downtime here.

So, why the story time? Well, given that DevSmash does rely on a few external services, I thought it would be nice to have a single place to look the next time something goes down. I had also been wanting to give TJ Holowaychuk's Commander a spin, so I took the opportunity to build a "cloud status" command line utility. In case it's useful to someone else, here's a quick overview of how it works:

While working on some recent projects, I had the need to run some basic dashboard analytics against moderate volumes of machine generated data. Already having some experience with MongoDB (and being quite the fan of it), I decided to do some research on real-time analytics with MongoDB.

A quick search turns up dozens of articles and presentations on how this can be achieved. However, after reading through quite a few of them, it became clear that most of the existing how-tos on the subject are based on pre-Aggregation Framework techniques, relying largely on MongoDB's atomic upsert, $inc, and $set operations.

These techniques are still largely useful, and are powering several successful applications. Unfortunately, however, they tend to be lacking when it comes to the ad hoc side of things - specifically, once multiple values from distinct events have been aggregated into a single value, the ability to slice and dice the results becomes limited. Additionally, these techniques typically require pre-aggregating at multiple levels to support pre-determined aggregation durations, rely on MapReduce, or delegate some re-reducing labor to the application itself.

Given that we now have the Aggregation Framework available to us (since MongoDB 2.1), I decided to run some tests to see how feasible it is to achieve real-time, interactive, ad hoc, dashboard analytics with MongoDB.

Note that this article is intended to be platform agnostic, so all tests are implemented as MongoDB shell scripts.

The most excellent David Walsh has graciously allowed me to author a guest post over on his blog. The topic of this guest post is: "Rolling Your Own RSS Feed with Express, Jade and Mongoose".

RSS feeds are a great way to facilitate a loyal readership. In fact, as I write this, the RSS feed in David's sidebar is touting over 11,400 subscribers. Hitting the front page of Hacker News is always nice, but for most sites that's not going to translate into a reliable source of traffic. Getting each and every post in front of thousands of intentional subscribers though (who have their own followers on Twitter, Google+, etc.)? That's a traffic generator.

Head over to the The David Walsh Blog to read the rest!

TLDR: Kwicks 2.0.0 is out, is awesome, and you can find docs and examples here.

I'm happy to announce that after 4 long years of neglect, Kwicks 2.0.0 is out! This is a major version release, and has been rewritten from scratch to support a much wider range of user interactions. The 1.x series of Kwicks had a horrid API, and made several assumptions regarding use cases. Kwicks 2.0.0 takes a much more flexible and programmable approach, and does a better job of following jQuery convention.

This post is Part 2 of a series on implementing secure username/password authentication for your Mongoose User models. In Part 1 we implemented one-way password encryption and verification using bcrypt. Here in Part 2 we'll discuss how to prevent brute-force attacks by enforcing a maximum number of failed login attempts.

This is just a quick announcement that DevSmash now allows comments on blog posts (powered by Disqus)!

I did some internal battling before choosing to go this route (eventually I want to build a custom solution), but I really don't like the idea of continuing to cover security related topics without providing a way for objections, concerns, etc. to be raised.

This post is Part 1 of a series on implementing username/password authentication for your Mongoose user models. In this first installment, we will discuss how to implement one-way encryption of user passwords with bcrypt, and how to subsequently use the encrypted password for login verification.

Thank you for checking out the inaugural post here on DevSmash! This is somewhat of a meta-post, as I really don't have an objective at the moment beyond introducing you to the site and getting the ball rolling.

Follow the link for more info on what DevSmash is, why it was created, and who it's for!