Ruby on Rails Posts

The Toptal Engineering Blog is a hub for in-depth development tutorials and new technology announcements created by professional freelance software engineers in the Toptal network.
Subscribe for daily updates today and check out the wealth of technical resources published by the Toptal network.

Fragment caching in Rails provides an easy yet a powerful way of improving your application’s performance. However, some real-world scenarios do not work quite well with how the Rails cache behaves by default.

In this article, Toptal Ruby on Rails Developer Orban Botond shows how you can implement a small DSL to optimize how the cache for related entities is invalidated to improve template rendering performance.

In back-end software development, increased productivity often comes at the cost of performance. In this article, Toptal Software Engineer Eduardo Bautista shows us how the Phoenix framework builds on the familiar concepts from the Rails world, and makes it even easier to build robust concurrent applications without compromising performance.

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.

Exceptions are as old as programming itself. An unhandled exception may cause unexpected behavior, and results can be spectacular. Over time, these errors have contributed to the impression that exceptions are bad.

But exceptions are a fundamental element of modern programming. Rather than fearing exceptions, we should embrace them and learn how to benefit from them. In this article, we will discuss how to manage exceptions elegantly, and use them to write clean code that is more maintainable.

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.

With modern image editing tools, we often take for granted the ability to extract or identify color on some part of any image. However, doing it programmatically is not exactly so straightforward. Camalian, a Ruby gem, changes that, making extracting and manipulating colors in an image as easy as possible. In this article, Toptal engineer Nazar Hussain provides some insight into how various color spaces work, introduces Camalian, and gives an overview of how to use it to build a color-based image search engine in Ruby.

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.

In an attempt to make web applications a lot more dynamic, front-end Javascript frameworks like Angular.js, Backbone.js and Ember.js have gained a lot of popularity. However, these frameworks often require a back-end application to be useful, so they are used in conjunction with web frameworks like Ruby on Rails and Django.

On the other hand, Volt is capable of managing the back-end and a dynamic front-end; since both functionalities are tightly integrated into its core.

A thorough and practical introduction to concurrent and parallel programming in Ruby, presenting and contrasting a number of techniques and options available, from the standpoints of both performance and complexity. Discusses forking, multithreading, the Global Interpreter Lock (GIL), and more.

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.

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.

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.

It’s a well known phrase, but as we know, most of the human technological progress was made by people who decided to fix what isn’t broken. Especially in the software industry one could argue that most of what we do is fixing what isn’t broken.

Fixing functionality, improving the UI, improving speed and memory efficiency, adding features: these are all activities for which it is easy to see if they are worth doing, and then we argue for or against spending our time on them. However, there is an activity, which for the most part falls into a gray area: refactoring, and especially large scale refactoring.

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.

At Toptal, we’re always looking for the best freelancers around. But what makes a freelancer truly great? Luis Martinho, one of our top developers, is beloved by his clients — so we sat down with him to talk about freelancing, technologies, and paying your taxes.

Starting a new remote gig, be it a contract project or a full-time job, can be a little intimidating if you’re used to going into an office day after day.

But this style of employment is growing in popularity, with some very notable companies lending it their endorsements.

I’ve worked remotely for years now on projects of various scales and durations. With this post, I hope to enumerate some of the best practices that I’ve picked up for working in a variety of situations. The advice here ranges from specific recommendations for software and hardware, to tips for hitting your team’s deadlines.