Hire the best Ruby developers & Programmers

Ruby, along with its framework, Ruby on Rails (“Rails”), is an incredibly efficient, high-level back-end programming language—a big draw for start-ups and small development teams that need to get complex, heavy-traffic applications up and running in a short time. Rails lightens the workload for developers with a library of “gems”—prepackaged code that streamlines development in a big way.

But what really sets Ruby apart—especially when stacked up against its biggest competitor, Python–is “programmer happiness.” Ruby is attracting lots of developers who prefer its elegant “do more with less” philosophy—and these developers are in demand.

The first step to determining the cost to hire a Ruby developer will be to define your needs. Rates can vary due to many factors, including expertise and experience, location, and market conditions. Learn about the cost to hire Ruby developers.

Overusing method_missing: Nobody likes repetitive code, and metaprogramming with method_missing is one of those guilty pleasure catchalls we like to throw into our code to avoid errors at runtime and just make it work.

Need to allow one class to quickly use the methods available in another class?

Use method_missing.

Have numerous methods but don’t want to name them all explicitly?

Use method_missing.

Need to build lots of methods that are virtually identical except for a few slight differences?

Use method_missing.

There’s just one problem with method_missing: It’s slow. Every time you call method_missing, the Ruby runtime must climb up your class chain hierarchy to find the method that actually does the heavy lifting that allows your code to work. Most benchmark tests show that method_missing is significantly slower at runtime than if you were to use plain old Ruby methods. A faster metaprogramming tool for the example cases above is define_method, which allows you to dynamically define methods that load when your classes are loaded.

So when should method_missing be used? When you’re dealing with dynamically named methods based on a pattern and you can’t reasonably expect to be able to predict all the possible method name combinations. Ruby’s own Active Record dynamic finders are probably the best example of this. For example, if you wanted to find a user by email from a large data set of users, and your user has an email attribute, you could use User.find_by_email(‘john.doe@example.com’) even though you never explicitly defined that method under the User or ActiveRecord::Base classes.

Relying too heavily on gems: Every new Rails developer reaches a certain point in their careers where they fall prey to the siren song of the RubyGems repository. And how can you resist? Ruby’s extensive catalog of gems is supported by a vibrant open-source community. Need help with authentication? Try Devise. What about authorization? CanCanCan’s got you covered. If there’s a task that you need help with, chances are good that there’s a gem for that.

Unfortunately, as with all other things in life, it’s possible to have too much of a good thing. As powerful as gems are, there comes a point where you’ll begin to notice a trade-off between programmer productivity and performance with every new gem. Too many gems can slow down performance, drain resources, and make tests take longer.

A bloated Gemfile can become a nesting ground for future application-breaking bugs. Higher-quality gems try to minimize dependencies as much as possible, but if you aren’t careful you could find yourself managing hundreds of gems. At that point, whatever productivity you gained from having to write less code is eaten up in managing dependencies, chasing hidden bugs, and keeping your application up-to-date.

What’s the solution? Moderation. Before you download a gem, ask yourself whether you can justify its use of resources and whether you need all the functionality that it has to offer. Being selective about your gems can help keep your application lean.

Application logic seeps into the view: Ruby on Rails follows the MVC (model-view-controller) pattern, where the model is responsible for data, the view is the visual representation of that data, and the controller forms the bridge between the two. The goal of this pattern is to decouple the major roles of an application in order to promote efficient code reuse and allow parallel development. Realizing that goal becomes difficult when you start to deviate from those roles.

Views should be concerned only with visual representation. However, it can be tempting to sneak application logic into your ERB templates like so:

Not only can the inefficiency of placing application logic into individual views lead to repeating code, but managing a large jumble of Ruby and HTML code can make maintenance more difficult as your application scales. It is far better to encapsulate that logic into a reusable helper function, presenter, or decorator.

Taking “fat model skinny controller” too far: Controllers do a lot of things, from session handling to rendering and redirecting—but it basically boils down to a middleman between the model and the view, receiving requests and providing the appropriate output. By default, the controller already has a lot on its plate. To prevent the temptation of stuffing model or view logic in the controller, the “fat model skinny controller” principle was born. Problem solved, right?

Not really. Now the problem of bloat has just been moved to the model. Every model should correspond to a data table in the database. The model’s corresponding data table should be its single responsibility. In a bid to keep views and controllers lean, it can be tempting to toss anything that doesn’t quite fit into the MVC paradigm into the model. It turns out that many of the maintenance issues that plague bloated views and controllers also extend to the model. The solution is to use POROs (plain old Ruby objects) to encapsulate things that don’t quite fit in any of the MVC categories.

Leaving your code vulnerable to SQL injection: It’s one of the oldest tricks in the hacker playbook—SQL injection, which involves taking advantage of user input fields to gain direct access to a SQL database. In Rails, this vulnerability is found where user input is required (for instance, typing in a search field) to query data from a database. The traditional approach to handling a query for a username would look something like this:

This approach is vulnerable to SQL injection. Fortunately, in Rails we have Active Record dynamic attribute-based finders, which work as parameterized queries that can properly handle the passed argument, avoiding SQL injection.

Besides using dynamic finders, it helps to only accept and construct values from external inputs such as search queries and forms. Never construct SQL commands like INSERT and DELETE, and don’t send untrusted inputs to methods in the Active Record library that accept raw SQL queries, table names, or columns.

Take advantage of the Ruby developer community

Ruby may not be the most popular back-end scripting language, but those who use it love it. Ruby was created with programmer happiness in mind, something that is readily apparent when you look at Ruby’s huge library of gems—ready-to-use solutions for common software development problems. If you need to rapidly prototype a project, you can virtually assemble an app from gems and boilerplate code in a snap.

Use symbols instead of strings in hashes

Ruby has a special data type called a symbol for storing the name of a variable that does not have to be changed. Symbols are prefixed with a colon denoted like so, :symbol. Unlike strings, which are mutable, symbols are immutable and take up only one spot in memory.

Immutability is perfect for hashes because you don’t want your hash keys to change. Hashes are similar to arrays, except they can use any object as an index.

Symbols are also more space efficient than strings, as setting multiple variables equal to the same symbol will access the same spot in memory.

Test your code often

Test-driven development famously takes a test-first and code-later approach to software development that looks something like this:

• Red: write a test for a software feature that fails
• Green: write the minimum code needed to pass the test
• Refactor: rewrite your passing code to best practices

Unless you already practice TDD, it may seem difficult to see regular software testing as anything more than a necessary evil to catch as many bugs as you can before you push to production.

Thankfully, Ruby tries to make TDD easier by giving you everything you need to practice it within its standard library: minitest/unit and test/unit. Between these two testing frameworks you should be able to get into the habit of writing safer code by regularly creating unit tests. Once you get comfortable writing unit tests, practicing TDD in its entirety isn’t so daunting.