Node toolbox

Node-toolbox

While searching for a node client for CouchDb, we came across quite a few node.js packages. 6 to be precise, to figure out the best fit for our project, we had to do a fair bit of Googleing and look at Github to see which ones are active and better fit for the project.

A lot of projects are defunct, have very little documentation or just experimental. It would be good to go to one place to find the right module and a general feeling of how good the module is. Turns out there is one, the Node Modules Wiki page. It shows simple wiki page  that lists modules by categories.

Coming from the Ruby world which has a similar vibrant community and tons of gems, we felt there needed to be a version of the awesome Ruby Toolbox 

So over a weekend we build a simple version of it and called it Node toolbox.

We pulled all the information from the Node Modules page  and  built the category mapping of each NPM Module. Whereas NPM Registry has almost 4500 packages, the Node Modules Wiki just lists  about 1000 of them.

NPM Registry does contain tags filled in by the package developers, but again only a few of the packages had this information.

There were more than 500 tags, from these we created about 100 categories, but merging them into one category, adding new ones or completely eliminating things we thought did not make sense. Along the way we removed duplicate tags like test/tests/Testing and so on.

Packages_for_categories

After putting the modules into their categories, we looked up github for the repository information, stuff like Watchers and Forks. Which in our opinion is a good indicator of the Project itself. And are currently using that to build our module ranking .

Ranked_packages

There are a lot of things missing now, The categorization and the categories themselves is arbitrary. We’d like owners of modules to categorize them correctly.

The choice of ranking the modules on github watchers/forks is also arbitrary. We could if it were available somewhere, leverage npm module downloads. User Feedback, repository information such as Open Issues Last commit time, Availability of tests, build status and so on.

As usual, feedback is appreciated and can be tweeted towards @nodetoolbox.

Filed under  //   node-toolbox   node.js   nodetoolbox   toolbox   toolbox.no.de  

NodeKnockout and Activenode.no.de

Last weekend we participated in the community driven 48 hour programming contest called Node Knockout. The idea is to go from an idea to production in exactly 48 hours using the wonderful Node.js. Noders from all over the world compete for the prizes that are awarded based on Innovation, Design, Utility and Completeness

We'd signed up long time ago, but we had no idea what we would be building till the morning 5.30AM( 0:00 GMT). Initially I was thinking of building  slick visualization over the Bitcoin transactions, but because of the limited scope and technical complexity, iI was wary about it. Eventually we decided to build a node.js equivalent the Rails' awesome New Relic's RPM. It also looked like something that could be build progressively, and be done quickly.

 

Another choice I had to make in the morning was the choice of deployment, We had to choose better the 3 official alternatives

  1. Joyent's No.de platform : It's easy to deploy and we get ssh access to the machines, but it uses Solaris and it's weird package manager, that we had very little idea about.
  2. Linode: Very flexible, and we get the choice of OS. But much harder to get the deploys right. We had to script our own, there was good documentation though
  3. Heroku: The an in between option, good deployment support but lack of ssh access and apps was a turn off.

We chose Joyent's No.de which remained our final deployment platform. We briefly switched to Linode, because for the first day of our usage No.de had broken web socket support, so the real time updates to the map was not possible. This issue was fixed the next day and we switched back to no.de for our deployment. It sucked a bit of time away but it was not really that much.

It is currently hosted here.

We used Redis for our storage, and later it turned out that it was a good choice, simpler storage format was a win. We used the Redis's monitor feature to build the live map. We'd pick the new request's Remote host and translate it to the city of origin which was plotted on the map. This gave us an awesome integration with socket.io. I am still at a loss of how we would have implemented it in any other database( couchdb's changes would also work)

We also used the awesome CoffeeScript to write the code, both of us were not CoffeeScript experts, but it was never a cause of any weird issue.

We published a npm module activenode-monitor (npm modules are equivalent of ruby gems) for usage in the express applications. But since it needed to talk to a central Redis on the no.de machine, which was not accessible from outside the machine(no.de has weird ssh setup) we could not get it to work. It took us a lot of time to realize that we could just use the free Redis plan of redistogo. And it just worked wonderfully well once we integrated it.

We store a lot of interesting client/server information into redis(though we did not get the time to implement views for all of it) and we are filling up the 512K of memory available on the free plan in about a day. So I need to flush out all the data almost every day.

It's an amazing experience to compress so much learning into 48 hrs, sometimes we were dazed and confused and sometimes in a wonderful flow. Having a usable app at the end of it is definitely a bonus.  Right now the judges are rating the final 180 entries out of the 302 that started. Some of the feedback we've got is pretty encouraging. We seem to be scoring high on utility and design and low on innovation and completeness. So any chance of our winning or being in the high ranks is unlikely.

I can excuse myself for the completeness, because of a conincidence of devops conference occuring on the same weekend and i had signed up to talk about Devops on Cloud. Finishing the slides, preparing and delivering the session sucked a lot of time out of my Sunday.

All in all it was good fun and a wonderful learning experience. We are looking forward to NodeKnockout 2012.

If you have reached the end of this. Please show us some love by voting for the app here.

 

Filed under  //   activenode   coffeescript   javascript   monitoring   node.js   nodeknockout   redis  

Goodbye Rails, Hello Node.js

A few months ago, I decided to play with node.js. The new server side JavaScript hotness and now I am hooked onto it. I use Ruby on Rails for most of my work. Though I am not a big fan of Rails, it is better than most things around and it's in Ruby which I really like.

Off-late most projects that I have been working on, have much less ruby and a lot more of JavaScript. My typical application consists of thin RESTful API transporting data as JSON, which is consumed by JavaScript in the browser. Can we not use JavaScript for the whole application instead? And get significant other benefits as well?

This is where Node.js fits in. Sitting on top of the highly performant Google V8 JavaScript engine, it gives you a bunch of libraries to write your networking code. In other words, it is JavaScript on the server side. FTW

As a side note, I used to be extremely scared of the JavaScript funkiness, till I apprenticed with some JavaScript masters. Over a period of time working on more and more JavaScript, I have gotten pretty proficient. I still don't have the same control with JavaScript as I have on Ruby and  I still forget to add the semicolons to the statements, but it's not that often now.

Asynchronous event driven API that leads to high scaling and lower memory footprint, we all know that (The now famous C10K problem). I have used EventMachine in Ruby and it always felt like working against the grain in ruby. Blocks typically are thrown for instant execution and rarely as a callback. The lack of Fibers in Ruby 1.8.7 does not help. Turning non-evented ruby code into evented ones is mind-bending exercise till you get it.

On Node.js it's the most natural way of programming, it doesn't even feel like a shift in style. JavaScript programming is all about callbacks invoked later in time. There is no such thing as EM.defer and EM.run, and checking if you are in a reactor loop.

There is some serious innovation happening around Node.js. Some are being built over experiences of other Languages. There is no such thing as Rails for node.js (which I consider a smashing thing). Most people use Express which is similar to Sinatra. Coffee script became popular because of and in the Node.js community. Now the Rails community is trying to make coffee script the default . RVM became popular only in recent times in the Ruby Community, We already have NVM doing the same thing for node versions. I can't forget to mention the fantastic Socket.io for realtime push applications and it is truly trivial to use.

The mushrooming of cloud hosting for node.js is also a proof that a lot of vendors think it's interesting. Just off the top of my head, there is Joyent's no.de, Cloudfoundry, Duostack and Nodester all in some sort of beta stage. Although from my brief experiments, I prefer the CloudFoundry to no.de and Duostack.

And Rails definitely does not have a rap theme song as cool as this. http://soundcloud.com/marak/marak-the-node-js-rap. (Listen with headphones, please)

 

 

Filed under  //   architecture   evented   javascript   node.js   rails   ruby