bitdrift

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?).

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. :-)

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).

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).

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.