DEV Community: Pratha Avashia

Why Ruby on Rails is still a good choice in 2020

Pratha Avashia — Mon, 07 Sep 2020 05:42:46 +0000

We at SoluteLabs love meddling around with tech, especially if it’s something fresh off the oven like Flutter. Here, we were sitting around on a Wednesday noon, playing truth or dare and passing the 8-ball around, when one of our developers posed the question:

Which is your favourite application development framework?

Okay, this might not be as exciting as saying, “How many tequila shots can you down at one go before passing out?” but these are developers we are talking about.

The answers came quickly.

Django. Ruby on Rails. Laravel. Ruby. Symfony. RoR.. and so on.

Ruby on Rails won this popularity contest, despite being one of the oldest technologies on the list.

Interest in Ruby on Rails has been waining, this much we know, but the technology still seems to be popular among hardcore developers.

As you can see, the graph has flatlined over the past year, and considering the fact that RoR is more than two and a half decades old, this is quite an achievement.

To put things into perspective, we have almost forgotten about Psy’s Gangnam style song, which is just eight years old!

Image credit

So we did a deep dive to see what keeps this RoR engine ticking, and found the key reasons why developers still feel using the technology will lead to RoaRing success (pun intended).

Here are our top seven picks:

Ruby is highly mature.

For the first few years after the release of any new programming language, the developers take it apart and use it to build things that were unheard of before. The language becomes “trendy” there is a bunch of cool stuff coming out every week, and the excitement in the air is electric.

This was also the case with Ruby way back in 1995 when Yukihiro Matsumoto released it to the world, to create a language that was “natural, not just simple to understand.”

In 2003, an employee of 37 signals called David Hansson, made things easier for the whole developer community by creating Ruby on Rails, simply called ‘Rails.’

We won’t bore you with more Ruby history, but a little back story is required to get the proper context.

Now that you know how Ruby has been around for more than two and a half decades, the hype around it has surely died down, and what was once cutting edge has now become commonplace.

The language, in other words, has ‘matured.’

But does maturity mean the language has become boring? Hell No.

Maturity means that the Ruby code is now more stable and refined, and Web Applications written on Ruby are much more maintainable.

Good developers know that code need not be written in the hottest new framework if it becomes a pain to support for the coming years. Instead, code stability that comes with maturity directly translates to saved time, which can then be used to focus on improving the application logic-or playing more foosball. A winner all around.

In other words, Mature Ruby Code > Code in Hot New Framework.

A large developer pool for Ruby

A good starting point to see if a technology is “in” or “out” is to see the number of job openings the technology has.

So I ran a quick Linkedin search for “Ruby on Rails developers.”

The results? Well, see for yourself.

A whopping 31,000 openings worldwide. Now, if Ruby On Rails were a dying technology, that number is surely bound to be way lower.

A large developer pool also means that there is a large repository of Ruby gems ready to use. Ruby gems are self-contained library formats that help you carry out complicated tasks.

We wrote a detailed post on “How to create A Ruby on Rails gem,” which you can find here.

Interesting caveat: At this juncture, our HR team at SoluteLabs wants to point out an interesting fact. When scouting for talent, the HR team says that Ruby on Rails developers are particularly hard to come by. This is contrary to what the data says about RoR developers being easily available in the market, so we will have to wait and watch before we proceed further.

Let us see what else makes Ruby popular.

Best for developing MVPs

Imagine this.

You have an idea for a killer app, something that is an offshoot of the current technology that you are working on, and have an investor meeting coming up in three weeks.

You can either:

A — Create a complicated wireframe or a presentation that only developers can follow and which is sure to confuse your investors.

B — Create a working prototype of the app and have the investors go… Ooooohhhhhh!!

Image credit

Building a Minimum Viable Product (MVP) in the least amount of time is why Ruby climbed to the top of the developer’s favourite list and is continuing to stay there.

Ask yourself questions like:

Does my product need to go-to-market in the least amount of time?
Do I want to extensively test my product before it hits the market?
Am I low on money and need to build something good out of minimal resources?
Should I constantly be able to receive feedback and improve my product?

If your answer is a Yes to most of the questions listed here, then you need to go ahead and build an MVP before you do anything else.

Ruby on Rails has a large community, as we stated above, and a tonne of gems available, which solves most of the problems developers face.

Ruby apps are easy to scale, and we can build apps much more easily for a bug user count, like GitHub.

RoR apps are easier to connect to a database, which means the technology offers a lot of flexibility.

All this leads us to one conclusion — “Think MVP, Think Ruby.”

Ruby on Rails is open-source.

What does an open-source framework mean to the end-user? Well, for starters, the source code is free to download for anyone wishing to play around with Ruby.

The RoR framework runs on Linux, which is also 100% free and is an open-source framework.

Ruby gems, which lets you add features quickly without having to develop them from scratch, also comes in handy here. The developer’s time and effort is saved, which also translates to saved costs.

Being open-source is what allows startups to compete with experienced players in the software industry.

Image credit

So if you are a Microsoft Windows and Java aficionado, consider switching to Linux and Ruby and watch your savings grow.

Moving on.

Ruby on Rails is easy to maintain and change.

One aspect of Ruby on Rails that all developers love irrespective of their other differences is the “Convention over Configuration” principle.

Rails has a very concrete idea of how to develop a web application and defaults to this set of conventions.

This means that not only do the developers save a lot of their time that is otherwise sunk in re-coding repetitive tasks, but Ruby code is cleaner and less prone to bugs. Convention over Configuration also means that it is easier to troubleshoot problems as and when they occur.

Ruby code structured so that there is no need for developers to leave behind detailed explanations as to why they took certain coding decisions. Instead, the Rails conventions act as a shared common ground for developers to write their code.

Rails is also good for Rapid Application Development (RAD), and the framework makes it super easy to accommodate changes.

Ruby on Rails is widely supported.

As we have mentioned earlier, the Ruby on Rails community is widespread across the globe, with developers constantly pushing out new Ruby on Rails gems.

Ruby on Rails community members pride themselves on keeping the technology updated and making the Ruby code clean and simplistic.

Image credit

A huge developer community means new users can quickly find solutions to any bug or coding problem they may be facing.

The RoR technology is so widely supported that an inside joke among RoR developers goes like “There is a gem for that.”

Is Ruby dying? A few drawbacks of Ruby on Rails

While we have talked about the advantages of Ruby on Rails at length, there are a few drawbacks of using RoR. Among them are:

Ruby on Rails is not Machine-learning friendly.

Remember how you see a list of Facebook friends you thought were long lost but seem to appear on your feed mysteriously? That’s machine learning optimizing your social feed based on past experiences.

When you drive from home to work, Google Maps shows traffic congestion in certain areas. That is machine learning at work too.

Machine learning has been an integral part of our lives for the past few years, without us even noticing it.

Image credit

Unfortunately, Ruby on Rails is not the best technology to use when dealing with Machine Learning. Languages such as Python or even Java offer much more features to integrate with Machine learning.

A major hindrance to Ruby and Machine learning is that there are just not enough libraries to support ML in Ruby on Rails apps. Considering the fact that Ruby on Rails is mature and was written a long time ago, when Machine learning was relegated to science fiction, this drawback can be easily forgiven.

Ruby on Rails is not fully flexible.

Ruby on Rails is highly opinionated and rigid. This is something that all Rails developers agree upon.

When we say opinionated, we mean that Ruby on allows you to create apps that “Rails wants you to.”

Ruby on Rails operates on some fixed rules and default code samples, which makes it difficult for developers to highlight their creativity.

Image credit

If you decide to build an unconventional architecture or extended features that fall outside Rail’s conventional guidelines, you will be in for a surprise. Developers have to choose between sacrificing time or originality.

Ruby on Rails has less operational speed and is not scalable.

RoR is the go-to tool if you want to build an MVP. That much is abundantly clear. But seasoned developers say that RoR is a bit slower compared to other frameworks.

Unlike C++ and Java, Ruby on Rails requires extra time to execute the code. Rails is a speed demon, and if you need high operational speed and low resource consumption, then Ruby on Rails is a big no-no.

Image credit

Speed again is a relative term, and you may not need a lot of speed if you are building an MVP.. Unless you plan your app to go viral and be used by hundreds of millions of users, speed is not generally a dampener.

But does your app need to scale quickly? Ruby language poses a drawback here too.

When Twitter moved out of Ruby on Rails to Scala, the framework’s inability to scale was seen as a major drawback. However, many developers would argue that each element in the server’s system architecture is responsible for scaling, and not just the web app’s backend.

But does it mean RoR is not completely suitable when building an app that scales? Not exactly. Shopify was able to scale and support over 500,000 businesses at a time using Ruby on Rails.

Who uses Ruby on Rails today?

Ruby on Rails is still going strong, with a host of companies swearing by the technology’s robustness and flexibility.

Here is a look at some of the big names using Ruby:

Both Ruby and Rails are scheduled to release updated versions this year, to address many of the pain points the developers are facing.

Ruby 3, aimed for a Christmas 2020 release, aims at making the framework faster, improve memory and CPU performance, and make Concurrency a cornerstone in development.

Rails 6, released last year, offers better text-editing features with Action Text and faster reply rates with Action Mailbox, and the ability to use multiple databases that make the app that much more secure.

As you can see, Ruby on Rails has been here for long and looks like it is here to stay. If you want an app developed using Ruby on Rails, remember to give SoluteLabs a shoutout.

How to create a gem in Ruby on Rails? [From Scratch]

Pratha Avashia — Wed, 29 Apr 2020 06:02:31 +0000

Being web developers, we all love Ruby on Rails. And we have our own reasons. But, one of the reasons why we love Ruby onRails (RoR) is the simplicity, which eases the way we code.

One of the simplest functionalities, which most RoR developers love is, creating gems in Ruby.

What are gems in Ruby?

A gem in Ruby programming language is a software package in which Ruby applications or libraries can be distributed in a single format.

But, then most of our newbie web developers ask these questions-

Why should we create a gem? It is ultimately a rails code, so why can't we add a code in one of the module files and use it in our projects?

And to that, the answer is Yes. We can use that method. But sometimes, if the code seems more general than the project-specific code, it should be converted to a gem so that it can be reused and shared with multiple projects. This will ultimately help you to maintain a clean line of code as well as will reduce the duplication of the code.

Recently in one of our projects, there was a functionality of sending notifications using FCM. FCM gem already exists in Rails to fulfill the functionality. But we wanted to integrate upgraded APIs from FCM itself, which the existing gem was not using.

And, how do we do that?

To adapt the newer APIs, one way was to code manually to send the notifications using FCM APIs. But, that is not a good idea because the "notifications" functionality is something that is going to be used in the majority of the projects.

So, we thought to have a private gem which will have a core logic of sending notifications to the devices using FCM non legacy API, which can be further used in many such projects.

So, we will see the step by step process of how we can create a gem in Ruby onRails. So here we go!!

Creating a Gem from Scratch

Now let's start with setting up our gem. Here we will be creating a gem with bundler. So to begin creating a gem using Bundler, use the bundle gem command like this:

1. Name your gem:

Before running above command we should know how to name your gem. There are some naming conventions to be followed.

Use dashes and extensions (every dash represents a structure (folder, module))

-- For example if we have a gem name like gem gem-structure-demo_notifier

-- It will be included in one of the files like require 'gem/structure/demo_notifier'

-- And its class or module will have a name like module/class Gem::Structure::DemoNotifier

Use underscores (represents a joining in the class name)

-- For example if we have a gem name like gem demo_notifier

-- It will be included in one of the files like require 'demo_notifier'

-- And its class or module will have a name like module/class DemoNotifier

Don't use uppercase letters

The command we have specified above will create the following file structure for creating a gem.

If this is your first time running the bundle gem command then you will be asked whether you want to include the CODE_OF_CONDUCT.md and LICENSE.txt files with your project.

We will see what all files are generated with gem bundle command and have a brief description for each file:

Gemfile: This file manages gem dependencies for our library's development. File contains a gemspec line meaning that Bundler will include dependencies specified in demo_notifier.gemspec. It's best practice to specify all the gems that our library depends on in the gemspec file.
Rakefile: Requires Bundler and adds the build, install and release Rake tasks by way of calling Bundler::GemHelper.install_tasks. The build task will build the current version of the gem and store it under the pkg folder, the install task will build and install the gem to our system and release will push the gem to Rubygems for public consumption.
CODE_OF_CONDUCT.md: Provides a code of conduct that is expected from all contributors to your gem to follow. It will only be included if you chose to have it included.
LICENSE.txt: Includes the MIT license. It will only be included if you chose to have it included.
demo_notifier.gemspec: The Gem Specification file. This is where we provide information for Rubygems' consumption such as the name, description and homepage of our gem. This is also where we specify the dependencies our gem needs to run.

In the gemspec file as you can see there are dependencies called development dependencies. So what is this exactly?

It's what you use while creating the gem. Things like rspec, rake and bundler should be in this file, because those might not be necessary for the people adding this gem to their Gemfile.

In this file we will also have to include the version of a gem we are creating. This version will reference DemoNotifier module's variable VERSION.

lib/demo_notifier.rb: The main file to define our gem's code which will be required by Bundler when our gem is loaded. This file defines a module which we can use as a namespace for all our gem's code. Here we have added the core logic of sending notifications to devices in demo_notifier.rb file like this:

lib/demo_notifier: This folder should contain all the code (classes, etc.) for our gem. The lib/demo_notifier.rb file is there for setting up our gem's environment, whilst all the parts of it go in this folder. If our gem has multiple uses, separating this out so that people can require one class/file at a time can be really helpful.
lib/demo_notifier/version.rb: Defines a demo_notifier module and in it, a VERSION constant. This file is loaded by the demo_notifier.gemspec to specify aversion for the gem specification.

Versioning of a gem requires some conventions to be followed as follows:

A gem version is a string of 3 numbers divided by dots - 'X.X.X'.
Incrementing any one of the digits has a different meaning i.e what level of the change has been made to the gem at the time of releasing.

-- Increasing the third number, means the 'build' number means that the change was small and did not affect the functionality of the gem.

-- Increasing the second number (A minor number) means the changes include adding new functionality, but the gem did not lose compatibility with the previous versions.

-- Increasing the first number ( A major number) means that the changes made to the gem were so severe that it's no longer compatible with the previously released versions.

2. Test your gem:

Now after configuring all the above-mentioned things, it is important to test the written code.

Testing the gem is a very important part when building a gem. It helps to assure you that your code works, and helps others know that the gem is working perfectly fine. When going through any gem, Ruby developers always check a solid test suite as one of the main reasons for trusting that piece of code which they want to include in their applications.

For writing test cases gem file structure also creates rspec related in which you can write the test cases using rspec guidelines and test your code through the test cases. Here in our file structure, the main rspec test cases will be written in*demo_notifier/specs/demo_notifier_spec.rb*

To run the test cases you can run rspec or bundle exec rspec. If the result is green then the code is working fine and good to go.

3. Generate the build:

Now that we have completed the coding of a gem we want it to be used in other projects. For this, we will run the build command.

This command will build the gem and output a gem file as follows:

4. Push the Gem:

Finally, after building the gem it's time to push the gem. There are two ways of pushing your gem.

For pushing the gem to RubyGems you will need to create an account on RubyGems.org. Once that's finished, use your email and password when pushing the gem (RubyGems saves the credentials in ~/.gem/credentials for you so you only need to log in once).

After that, it is just a matter of making it available to rails communities around the globe through rubygems.org. This is done with two simple commands:

And once its done run following command

With this command, the gem will be pushed and will be available on RubyGems.

Sometimes we want to keep our gem private and don't want to share it with the world. But RubyGems doesn't support that.

So to keep the gem private you can push your gem to a private Github Repository and include the gem to your project using github url with oauth credentials. And if we don't want to include oauth credentials to the url then you can add the ssh key to the gem repository and gain access from where you are installing the gem.

This way your gem will become private and will only be accessible to limited people.