Rails

When you hear the word “linter,” you probably think about particular widely used tools. But there’s a different kind of linters.

In this article, Toptal Back-end Architect Robert Pankowecki introduces you to linters implemented by Ruby libraries and details their capabilities.

If a web application is big and old enough, there may come a time when you need to break it down into smaller, isolated parts and extract services from it. Some of these will be more independent than others.

In this post, Toptal Full-stack Developer Viktar Basharymau explains how his team extracted an app from the monolithic Rails application that powers Toptal, and how the new service’s technical stack was selected.

Rails 6 is finally here, featuring major improvements and clever new features that should make development easier and faster than ever.

In this article, Toptal Ruby on Rails Developer Avant Mittal dives into the Rails 6 changelog to introduce you to these new features and explain how you will be using them in your next Rails project.

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 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.

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.