#RubyOnRails Posts

Rails ships with everything you need to prototype your application quickly, but when your codebase starts growing, you’ll run into scenarios where the conventional Fat Model, Skinny Controller mantra breaks. When your business logic can’t fit in either a model or a controller, that’s when service objects come in and let us separate every business action into its own Ruby object.

Your website is gaining traction, and you are growing rapidly. Ruby/Rails is your programming language of choice. Your team is bigger and you’ve given up on “fat models, skinny controllers” as a design style for your Rails apps. However, you still don’t want to abandon using Rails? No problem.

In this article, Toptal Software Engineer Eqbal Quran explains how you can decouple and isolate your Rails components using nothing Plain Old Ruby Objects. Ruby objects and abstractions can decouple concerns, simplify testing, and help you produce clean, maintainable code.

In this tutorial, Toptal Engineer Orban Botond demonstrates how to use the Grape gem – a REST-like API micro-framework for Ruby – to build backend support in Rails for a JSON API. Grape is designed to run as a mountable rack engine that complements your web applications without interfering with them.

One of the most misused, misunderstood, and neglected of all the Rails built-in structures is the view helper. Helpers often get a bad reputation for being a dumping ground for one-off methods used across the entire application’s view layer. But what if your helpers could be more semantic, better organized, and even reusable across projects? What if they could be more than just one-off functions sprinkled throughout the view, but powerful methods that generated complex markup with ease leaving your views free of conditional logic and code?

Let’s see how to do this when building an image carousel, with the familiar Twitter Bootstrap framework and some good old-fashioned object-oriented programming.

The publish-subscribe pattern] (or pub/sub, for short) is a messaging pattern where senders of messages (publishers), do not program the messages to be sent directly to specific receivers (subscribers). Instead, the programmer “publishes” messages (events), without any knowledge of any subscribers there may be.

This article provides insight in how to use the pub/sub pattern, in Rails, to communicate messages between different system components without these components knowing anything about each other’s identity.

Why are Rails Engines not used more often? I don’t know the answer, but I do think that the generalization of “Everything is an Engine” has hidden the problem domains that they can help to solve.

Which Ruby implementation is right for your project? While the reference implementation (Ruby MRI) remains the interpreter of choice, an alternate Ruby implementation may be right for your project, depending on your operational goals and constraints.

This article showcases the Ruby interpreter implementations and runtimes available today, discussing the advantages and disadvantages of each.

While Rails is easy to use, it is also not hard to misuse. This article looks at 10 common Rails pitfalls, including how to avoid them and the problems that they cause.

Elasticsearch provides a powerful, scalable tool for indexing and querying massive amounts of structured data, built on top of the Apache Lucene library.

Building on the foundation of Elasticsearch and the Elasticsearch-Ruby client, we’ve developed and released our own improvement (and simplification) of the Elasticsearch application search architecture that also provides tighter integration with Rails. We’ve packaged it as a Ruby gem named Chewy.

This post discusses how we accomplished this, including the technical obstacles that emerged during implementation.

I’ve been an Engineer at Toptal for just about one year now, working on the same project since I joined the network: Ondello, a service that connects doctors and patients over WebRTC.

When I first joined Ondello, I was hired as a Senior Ruby on Rails Developer, tasked to build a service up from scratch. These days, we’re a team of multiple developers working on a fairly large, complex system.

With this post, I’d like to share the story behind Ondello. Specifically, I’d like to talk about: how a simple application became not-so-simple, and how our use of cutting-edge technologies posed problems I’d never considered before.

Sometimes I hear people complaining about their clients, saying that they insist on using Rails, that they’ve had too much Kool Aid. If they are recruiters, they almost feel sick in the stomach from perspective of having to find yet another ROR primadona. From the programmers point of view it sometimes looks like clients don’t have a clue. However, I believe most clients know their options just fine and they still decide to go with Rails.

Sometimes, clients give us feature requests that we really don’t like. It’s not that we don’t like our clients, we love our clients. It’s not that we don’t like the feature, most client-requested features are aligned perfectly with their business goals and income. Sometimes, the reason we don’t like a feature request is that the easiest way to solve it is to write bad code, and we don’t have an Elegant Solution on the top of our heads. This will throw many of us on fruitless searches through RubyToolbox, github, developer blogs, and stackoverflow looking for a gem or plugin or example code that will make us feel better about ourselves.

Well, I’m here to tell you, it’s okay to write bad code. Sometimes, bad code is easier to refactor into beautiful code than a poorly thought out solution implemented under a time-crunch.