Ruby, Rails and spRockets

One of the big issues when coming into a community is actually getting started. As a beginner in the Rubyscape you may try to first learn Ruby, then understand the Rails framework. Ok, now you have a handle on those, but what can you actually do with them? There are quite a few supporting components which compose the various layers of the stack. This post will cover a quick overview of the different components and tools made available by the flourishing community that surrounds Ruby and the Rails framework that sits atop it all.

To begin there are a number of different interpreters that can be used. There is the default one Matz Ruby Interpreter (MRI) which is the one found at the Ruby Language website. It is most likely the first interpreter you used and what many rubyists continue to use in their projects. For many cases MRI is used in projects, and unless there is a significant call for performance MRI can be used. Also, if true concurrency is a necessity then MRI might not be the interpreter for you. For more understanding  about concurrency in Ruby go here.

If there is either a need to improve performance, reduce memory footprint, true concurrency, or some combination of those, then moving to a different interpreter may be the answer. There are a multitude of different interpreters available. One way to not only test out different ones, but handle multiple ruby interpreters some times called rubies is to use RVM. RVM is a great tool which can be used not only in your development environment, but also your production environment. Whether you are looking to switch between rubies or use multiple ones simultaneously, RVM is a great tool in both scenarios. Even if you're working in the same type of ruby, but running different versions of them RVM provides mechanism to handle all of that.

Regardless of wether you decide to use RVM the rubies available to you each have their own advantages and disadvantages. This post won't go into the depth about the performance of these other interpreters, but some of the largely used non-MRI interpreters are: Rubinius, JRuby, and Ruby EE.

Rubinius has the primary focus of producing a much more efficient runtime to increase performance. It provides all the necessary subsystems to run ruby code, and the team prides itself writing as much of the functionality in Ruby as possible.

"A large aspect of popular languages such as C and Java is that the majority of the functionality available to the programmer is written in the language itself. Rubinius has the goal of adding Ruby to that list. Rubyists could more easily add features to the language, fix bugs, and learn how the language works. " - rubini.us

As of writing this Rubinius fully supports 1.8.7 and is working to be fully compliant with 1.9.3. It also supports true concurrency by having removed the the GIL.

JRuby another interpreter also allows for real threading by having removed the GIL as well. The focus for JRuby is to allow Ruby to run on the JVM. This provides any company who runs a Java environment to easily implement Ruby applications. While there are some limitations on which gems can be used, any gems fully implemented in Ruby should be compatible. Also, many gems with C extensions have JRuby ports which allow them to be run in the JRuby interpreter.
In addition to being able to run within on top of the JVM there is a package called warbler which will package up your application and allow it to run in any Java container such as Tomcat or WebLogic.

This is by no means an exhaustive list of interpreters, they however are some of the more popular ones around. Beyond interpreters there are a host of add-ons that are available for ruby in the form of gems. Gems are the libraries that that will provide additional functionality without writing a ton of code, but also allow you to alter the functionality to your needs. Unlike in Java where modifying or extending a library can be a little tough sometime there is often an easy way to override the code in a gem. There are potential dangers when updating gems to a different version when parts of a gem are overridden  but that is a discussion for a different post.

Some of these gems include the wildly popular Rails framework. Many websites have been built a top the framework, however there seems to be an increasing trend to build only the API in the rails framework and then use a javascript library such as EmberJS or AngularJS to build the actual interface layer. The rails framework is not just a single behemoth gem though, it uses a conglomerate of many dependencies, one of which is the server itself.

The out of the box server for Rails is WEBrick; it provides basic functionality to allow the applications written on the rails framework to server HTTP requests. However, WEBrick is not the only kid on the blog. As with everything else there are alternatives, many that promise greater performance, such as Puma, Thin and Unicorn.  Many of these can be dropped in with a few configuration changes depending on which version of Ruby and of Rails.

There is an ever expanding list of gems to explore, simplifying life as a Rubyist. If you're new to Ruby this may be a little overwhelming, but if you iterate through then there is no limit to the things that can be created and discovered. To all I say keep learning, and happy coding.