Wow. The multiple tabs + account switcher thing works surprisingly well.

Have you ever run into problems using it this way? Seems like this is somewhat outside of the normal usage (maybe because of all of the disclaimers when you add extra accounts?).

So far, no. I've been doing this for about a week, and - as far as I can tell - it works fine. I don't know if this is actually a supported thing, or something that only works by happenstance, or what. But for the time being it seems to work. <shrug />

Agreed. I spent the last few months building my first Node.js app (and MongoDB) and I resonate with a lot of what's being said here. I wouldn't want to discourage anyone from exploring Node or Mongo, because I think both are amazing projects and have huge potential, but I do think anyone considering either should stop and think carefully before taking the plunge.

Things that stick out in my head:

1. What the author says about the Node community moving fast is absolutely true. Be prepared to spend time upgrading to the latest versions often or deal with dependency hell as you try to ensure you've got matching legacy versions of libraries.

2. Coding async is weird at first, but you may grow to love it (as I have). Over the months, I've discovered many cool tricks and patterns that help keep the nesting to a minimum.

3. Be prepared to fill library gaps, and submit patches if necessary. This means not being afraid to dig into the source code of the libraries you're using. Most libraries have limited documentation so often the only way to figure out how to use them is to get in there and see how they work.

4. Best practices may not apply. In the case of MongoDB, I had to redesign my schema in order to run certain queries now that MongoDB won't support until sometime in the future.

All in all, I'm really glad for the experience and will definitely consider both Node.js and MongoDB for future projects. What will really be interesting is seeing what I miss about Node/Mongo after jumping back into Python/MySQL. :-)

> 2. Coding async is weird at first, but you may grow to love it (as I have). Over the months, I've discovered many cool tricks and patterns that help keep the nesting to a minimum.

Can you share a few? Either here or as a blog post?

If you have a function foo() that takes a callback as an argument i.e. something like:

  foo(..., function (n) {
     // closure over q, r, s
  });

Then what you can do is create a separate function, bar() that takes q, r, s as an argument, and returns a function:

  function bar(q, r, s) {
    return function(n) {
      // still has dependency on q, r, s
    }
  }

Once you have bar(), the foo() call above can be written as:

  foo(..., bar(q, r, s));

and you save one level of nesting. (This also makes the dependencies explicit, which is helpful.)

The main loop of

https://github.com/ithinkihaveacat/node-fishback/blob/ce5f9c...

does quite a lot of this, if you want a real example.

This technique reminds me of Lambda Lifting: http://en.wikipedia.org/wiki/Lambda_lifting

Why not to write it in a much simplier way? Like this:

  function bar(n) {
    // still has dependency on q, r, s
  }
  foo(..., bar);

Yeah, that's nicer if bar() can be defined at the same "level" as foo() but if it makes more sense to move it somewhere else the closed-over variables need to be passed.

We've been using the flow control helpers in async.js to help us with the nesting issue: (https://github.com/caolan/async).

We use the waterfall most, as it allows one to run an array of function in a series with a callback at the end of the series.

Sorry about that. Should be fixed now. Drop by at http://banter.ly/bitdrift/bugs and let me know if you run into any others.

Actually--we already do this, as long as the URL is the only thing posted in the comment. The next step, parsing URLs from comments, is on my TODO list. :-P

Thanks! We do too. :-) Naming websites is one of our least favorite things to do, so we consider ourselves lucky to have one that fits our idea so well.

Thanks for your feedback! Very well put.

As we've been working on Banterly for the past few months, we've had a lot of the same thoughts. That's a big part of the reason we decided to focus our product on the Twitter community first. Our hope has been that as people discuss topics around various #hashtags that they will have a way to take the conversation to a deeper level rather than overwhelming their followers with @replies.

The comparisons to Convore are more at a feature level and prompted because many of our original ideas were geared toward giving the IRC community something more "up-to-date" (though it's hard to say whether or not open source programmers currently using IRC will ever really leave for anything else anyway).

The hard part about being a solo founder -- you take body-blows like this and you can get hung up on the competition. You need to guard against trying to match Convore feature-for-feature-- definitely stay the course and execute on your core vision. Good luck!

Actually, push and pull in the case aren't all that different. Using a reflector address, the system could send a single message to each server.

Ideally each server has more than one user and if a distributed system looks anything like our current email infrastructure, there are would only be a handful of large service providers, each with millions of users.

Of course, there might be thousands of followers also using smaller providers, but sending a few thousand emails is not a big deal (and not that much different from a few thousand providers pulling from a central hub).

Presumably the value of building on existing not-particularly-well-loved protocols would be that only a small part of the stack needs to be extended. If you have to extend mail servers to support discoverable multicast endpoints, at that point you might as well just make a new protocol from scratch.

Another big problem with push, besides the overhead, is that everything is transient. If you aren't subscribed to a source when it sends something out, you will never see that thing, even if you subscribe later. That might possibly be acceptable for status updates, but definitely not for blog posts, photos, and other permanent content.

Of course, there are various request or sync schemes that could address this problem but anything like that would push this whole idea into Rube Goldberg territory as far as I'm concerned.

> you might as well just make a new protocol from scratch

This is the approach that so many new social nets are taking and then struggle to "convert" users. OTOH, "flipping some switches" to enable social features in someone's email client would probably be more straightforward for the majority of email users.

Besides, the "augmented email" would actually be a transitional model to "educate" the users into the distributed social net. After that, changing the underlining protocols to be a better/faster/cheaper ones would be natural for the techies and transparent to the average user.

> If you aren't subscribed to a source when it sends something out, you will never see that thing, even if you subscribe later

Well, from my POV, this is actually a benefit: I get the power to choose if the "new" friend gets to see all my history or not. As you later suggest, syncing wouldn't be a big problem anyway...

I was also thinking about something similar a while back until I discovered oStatus (http://www.ostatus.org) and its related projects (ActivityStreams, PubSubHubbub, Salmon, etc). While I think an implementation over SMTP could work quite well, I think using PubSubHubbub has a reasonable advantage in that doesn't require app developers to use ports other than standard HTTP ports (80 & 443). This isn't a big deal for major websites, but part of the advantage of having a truly distributed social network is that even the little guys can join the game--which means it should be as easy as setting up something like say, WordPress.

At my last company, we used FogBugz for almost two years but started exploring other systems the last few months I was there.

I initially chose FogBugz because I loved how easy it was to create a new issue in the system (which at the time was significantly better than the others I tried). It only requires a single line of text for the description. There are additional fields you can use, but they are never required. That said, FogBugz's UI hasn't quite kept up with the latest and greatest, so we found it to be somewhat unsatisfying and even quite annoying at times (not enough inline editing for example). Ultimately the reason we started exploring other tools was because of its slow performance (although I'm not sure if it was due to having it deployed on a Linux server rather than Windows).

We tested Jira with the GreenHopper plugin (agile development) for about a month. Most of the team made the transition quite easily (a few guys wanted to go back to FogBugz) and it was significantly faster than our FogBugz system--which made the team much happier. For our planning meetings, we all really liked the user story board view in GreenHopper, and overall I found the user interface more usable than I expected. However, Jira definitely feels like a typical old-school 'enterprisey' Java app that has been quickly updated to stay current (not to mention the sprawling feature set it has accumulated over the years). Its UI definitely lacks the cohesiveness of FogBugz (and especially Pivotal Tracker).

In the end, our company was acquired by a company also using FogBugz, so the team never had a chance to make a decision one way or the other.