Whilst doing some work in a library I maintain, I needed to add in the ability to calculate the hash of an included file for an integrity check feature I was adding in. The resulting solution is simple and not really boast-worthy, but given others might encounter a situation where they need a hash of a file, this might help.

const crypto = require('crypto');
const fs = require('fs');

const fileBuffer = fs.readFileSync('myfile.js');
const hashSum = crypto.createHash('sha256');
hashSum.update(fileBuffer);

const hex = hashSum.digest('hex');

console.log(hex);

For the createHash method you can supply different supported algorithms including; md5, sha1 and sha256. To the digest method, you can supply hex or base64. If speed is important to you, sha1 and base64 are the two fastest options in most cases, however, all options are fairly fast anyway.

In Npm version 3 we finally got what we had been asking for the last few years: a flattened module structure for Node modules. Unfortunately as a result Npm has slowed to a crawl when installing or updating Node modules, well mostly just installing.

Recently it was circulating that disabling the progress bar resulted in at least a three times speed increase. I first saw it on Twitter and dismissed it initially.

Could a loading bar really be the cause of the slowness? By itself, not entirely. But disabling it will result in a lot less banging your head against the desk while you wait for Node modules to take 20 minutes to install.

Open up a terminal prompt and type the following to globally set Npm to disable the progress bar and feel the speed:

npm set progress=false

If you are interested in knowing why Npm 3 slows down, someone over at Github has done a tremendous in-depth investigation into the slowness issues and you would be surprised.

If you were a startup trying to get an MVP out the door in 2010, admittedly you probably used or considered Ruby on Rails. In 2015 you are probably more than likely going to opt for Node.js instead. But why?

Once upon a time it seemed as if Ruby on Rails was destined for global dominance. Twitter was originally built on top of it before moving for scalability and performance reasons, but many companies still use Ruby on Rails.

Some notable companies still sporting the faded Rails band t-shirt include; Github, Shopify, Twitch.tv, Imgur, Airbnb and the list goes on.

Rails is definitely not dead, however you can’t deny the trends for Rails usage are going down, not up. It is no longer considered to be the only darling of the startup world like it once was.

So.. what happened?

While the appeal of Ruby on Rails was very much its plethora of generators and other CLI goodies that made it easy to scaffold an application in a matter of minutes: Node.js happened.

The appeal of Node.js was the fact that developers could apply their existing skillset and Javascript knowledge to the server side. The issue with Rails is even though you could use it with next to no knowledge of Ruby, to truly harness its power, you had to learn Ruby.

Then there is the history of well-documented performance problems plaguing the framework, more publicly Twitter&#8217’s move away from the framework.

Ruby on Rails was never marketed as a performance-first framework, it was marketed as a framework you chose when you wanted to get shit done and as quickly as possible. There is no denying that Rails delivered on that promise.

As you can see comparing Google Trends data for Ruby on Rails and Node.js paints a very clear picture:

The appeal of Rails was not only attributed to the fact there was nothing really like it at the time (unless you consider Django and Django). PHP was the dominant language when Rails made its debut and people jumped ship because the PHP hate-train was speeding down the tracks.

Of course, there were other reasons that can be attributed to the early success of Rails. The inbuilt ORM, the scaffolding functionality and ability to generate an entire application using a few simple CLI commands appealed to many of us as developers.

Ruby on Rails isn’t dead

While RoR is alive and well, it just isn’t the flavour of the week like it used to be. It seems Node.js has won out, but that isn’t to say that Node itself won’t be replaced by something in the future.

There is still a community behind Ruby on Rails, albeit not as vocal or big as the Node.js community. It is far from dead, but we have to wonder if there will come a day when Rails falls behind even further.

The stats

It isn’t exactly a fair comparison to compare NPM modules and Ruby Gems, as Gems are not Rails specific but rather the package manager for the Ruby language itself.

The activity on the Gems stats page does give you insight into the number of downloads there have been of Rails though.

So let’s compare the number of downloads of Express (a framework for Node.js) and Rails (both installable via their respective package managers). Both similar in that they are frameworks built on top of an existing language/library.

In the last month (so February 2015) there were 2,171,225 downloads of Express. Compare that to the number of downloads via Ruby Gems for the latest version of Ruby on Rails released December 20th, 2015 which have only totaled 541,249 in a two month period since its release.

Express had four times the number of downloads in the last month compared than Rails has had in the last two months. The numbers paint a picture of a framework not nearly as popular as it once was.

For update stats on Ruby Gem packages click here. For Node Package Manager statistics, simply visit their site and they’re displayed at the top of the homepage, individual stats are available on a packages detail page.

Looking to the Github repositories of Rails and Node.js, you can quite clearly see that Rails is being updated on a regular basis. Comparing the two, however, is more difficult stat-wise as Joyent don’t adopt such an open community model like Rails does.

Conclusion

Rumours of Ruby on Rails’ demise have been greatly exaggerated. Rails is not dying, you just forgot about it along with most of the other trend-riding chumps. Or your needs outgrew what Rails could provide you.

The stats quite clearly prove that Rails is not dying, but they also prove that it isn’t growing as much as Node.js is (or to be more specific and fair: Express). The community is still contributing to it and people are still using it.

You are only as good as your community and while Rails has a chance to turn things around in V5, for the moment, the low barrier to entry for Node.js thanks to Javascript makes it more appealing.

At the end of the day, use whatever works for you. Don’t believe the hype around a framework or language, if you like it and it meets your needs, then there is no wrong choice.

If you are like me you not only develop in PHP, but you also dabble in other languages like Javascript and Node.js, then this blog post is for you. I like to write API servers in Node.js and interface with them in my AngularJS applications.

Because MAMP Pro comes with a useful feature of allowing easy hosts/URL aliasing creation, we can create a virtual URL for our API and then interact with it in our applications.

Before we continue, this post assume that you are using MAMP/MAMP Pro version 3 or greater. It will work in earlier versions too, some menus and screens might be different.

– In the hosts tab, add the URL you want to proxy. So if you want to proxy a url: api.mycoolapp.com to a Node.js server running on port 3000 on http://localhost:3000 click on the plus and add it in. Specify a folder, however this is not important as the folder will be ignored as we are redirecting our request, not loading files from a server.

– Now that we have added in our host, click on it and you should see four tabs; General, Extended, SSL and Extras. By default General will be selected, click on Extended.

– Now that you are in Extended, at the bottom you should see: Additional parameters for VirtualHost and a text area you can write stuff into. This is where we are going to modify the Apache VirtualHost rules and make it redirect. Copy and paste the below code into this box and hit the save button.

ServerName MyCoolApp
ServerAlias api.mycoolapp.com
ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/
ProxyPreserveHost On

And there you have it. You have just created a ServerAlias and ProxyPass modification inside of MAMP. This is powerful in that it allows you to create virtual URL’s for Node.js servers or anything else including Ruby on Rails, Python, etc.