Scheduled tasks are a fact of life in any non-trivial Rails app—whether it’s sending out nightly digests, cleaning up stale data, or syncing with external APIs. If you’re using Heroku Scheduler to kick off these jobs, you’ve likely run into its limitations: fixed time windows, separate logging, and the hassle of managing multiple “one-off” dynos. In this article, I’ll show you how to consolidate your cron jobs into Sidekiq Cron, giving you unified monitoring, richer scheduling options, and the performance benefits of Sidekiq’s threaded workers.

It’s all too easy for ActiveRecord models to balloon into monolithic “God objects.” You start by adding a validation here, a callback there, maybe a little business logic in a class method—and before you know it, your User or Order model is hundreds of lines long, has dozens of dependencies, and is terrifying to test or extend.

APIs are the backbone of modern web applications, but Rails controllers can get unwieldy when you try to support multiple versions, complex parameter validation, or JSON representations that change over time. The Grape gem offers a lightweight, Rack-based DSL for building RESTful APIs in a clean, object-oriented way. Pair it with the grape-entity plugin, and you get Ruby classes that encapsulate your JSON representation, keeping your controllers thin and your business logic organized.

Knowing how to use testing frameworks is one of the most important skills any developer must learn. In particular with the Ruby programming language, testing is even more important because a compiler will not catch syntax errors or little slip ups! Such is life when using interpreted languages. Despite testing’s importance being obvious, it is surprising how many Ruby on Rails apps have deficient test coverage or no code coverage at all! Why is this?

Ruby’s Standard Library is full of many Objects that ship with just about any Object Oriented programming language. We have String, Hash, Array, Integer, and Float. However, there are several more “niche” Objects that many code schools and programming books overlook. In this article, I’m going to show off one of Ruby’s lesser utilized Objects: the Rational Class. What are they and what can you use them to do?

Did you know that most of your favorite websites use the web application Ruby on Rails? Among them are Twitter, Airbnb, Bloomberg, GitHub, GoodReads, Groupon, Jobster, Sound Cloud, and Spree Commerce. Are you planning a website or online component for your small business? Read on for the reasons why these companies prefer Ruby on Rails.

Recently we were working on a project in which we needed a subscription based payment system to manage different user plans. This was an MVP so we did not necessarily want to roll our own subscription system if we didnt have to. Enter Koudoku, a Rails based subscription engine that integrates into Stripe out of the box and uses Stripe Event to hook into Stripe’s beatifully simple subscription plan system.

Over the course of my experience as a developer, I’ve often found that when things get complex - they get really complex. Often times the key to a solution isn’t finding the one thing that solves a problem, but rather the combination of different functionalities that ends up being the solution that works the best. In the case of one of our pro-bono projects, I had a particularly difficult problem that I needed to solve - and the solution that I arrived at involved a combination of Postgres’ Common Table Expressions, Window Functions, SearchLight, and Rails Query Scopes. What on earth was I trying to accomplish that could possibly elicit this witches brew of open source technologies? Simple: I needed to take user-supplied input, sanitize it, geocode it, then ensure that the result set did not contain duplicates. Each of the tools listed above contributed in some fashion to the working solution!

In an app I was working on recently, there was a requirement for a document (these were agreements of one type or another) to have many parties. In turn each of these parties needed to have an owner—and here’s where things began to get a little more complex—the party owners could be one of several model types. Ugh. Building a working select box for this functionality was going to be a mess. Or that’s what I thought initially. That’s when I happened across a few blogs about using Global IDs in Ruby on Rails. The Global IDs module became an official part of Ruby on Rails with the release of version 4.2. This module only includes a few methods and the one I ended up using most often is #to_global_id.

It doesn’t take much reading in regards to rails before you hit the “Convention over configuration” line. In my early days of development I had little idea of what that meant, either in terms of implications or for concrete uses. Now when I see that, I immediately think of arranging files within your application, how everything has a place, and how putting things where they belong make it quick and therefore efficient to find the files that need to change, make those changes and then update specs or associated files easily. That’s less headaches, more features and happier client and developers at the end of the day.

Time is money. If this was a movie and I was a learned monk, I’d leave it at that, turn around and walk away into the mist, leaving you on a journey to figure out the full meaning and implications of that for yourself. But this is a brain dump of where I currently am in how I develop, so I’ll go into the details of what I do to insure my time is well spent.

Fast Server, Slow Browser

Here’s the situation: Your amazing developer team has rocked your world with caching and other optimizations to get data from your client’s Rails server over to the users’ browsers. Your monitoring shows requests that were taking a whole 80-90 seconds to serve are now only taking 1500ms (and all that time is actually spent transferring megabytes of html to the browser, actual data retrieval is ~10ms). These numbers come from a recent project I did for a client with production data. Now, to tackle the last piece of speeding it up… Chrome browser is taking MINUTES (6 minutes, actually) to fully build and render the page after it’s received the data. 100% unacceptable. Time to drop in some asynchronous data transferral and a specialized Javascript library to keep things performant on the client side!

It’s inevitable that as you develop applications, clients and users will want searching added. Completely inevitable. What happens when you need to extend beyond searching fields that are saved on your models? There’s also the ever present need to keep things scalable. Having a solution that grows with you and isn’t tied 100% to your schema can not only impress, but save you time in the long run. Check out Solr, the incredibly powerful search solution from Apache. In this article, I’ll show you how to set it up and how to do a basic search.

Thinking about starting a business? Have an idea that you want brought to life?