For me, like many others, Rails has a very “magical” feel. You don’t really even need to know Ruby to get started with Rails and in a few hours you’ll have a fully functional application, complete with users, sessions, and dynamic content. I probably made about 5 non-trivial Rails applications before I really knew what a block was (other than something I just passed to each). Never mind the inheritance structure, modules, mixins, and metaprogramming in Ruby. For me, it wasn’t until I started thinking about how various calls (attr_accessor, before_filter, etc.) work and what they’re doing that I really felt I had a good grasp on things.

Simple commands, before filters and validations for example, add a ton of functionality. A lot of Rails is clever uses of metaprogramming, but spend some time looking under the hood and you’ll probably stop feeling like things are just “magic”. That’s what I hope to help you accomplish in this post.

Ruby::attr_accessor

I want to start by looking at Ruby’s attr_accessor method. It’s pretty simple and has been used by almost everyone who’s ever written a line of Ruby; however, most people probably haven’t stop to understand how it works. It’s not Rails-specific but provides some insight into how we might think about certain functions.

Here we see that by calling attr_accessor on `start_at` and `end_at` we have given ourselves a lot of functionality.

• Public methods: [:start_at, :start_at=, :end_at, and :end_at=]
• Instance variables: [:@start_at, :@end_at]

Try this out for yourself. Copy the above gist into an irb and and check event.public_methods and event.instance_variables.

So when we want to implement attr_accessor we need to do two things, set instance variables and define public methods. Luckily Ruby comes with instance_variable_set, instance_variable_get, and define_method — providing just what we need.

Now we see how easy it is to define functions such as attr_accessor, or the similar attr_reader & attr_writer. The important piece to understand here is that attr_accessor isn’t a special or magic function — it’s just one that happens to take advantage of Ruby’s dynamic nature.

Rails::before_action

Rails provides filters to be run before, after, or around controller actions. A common use case is to require that users are logged in. Putting a `before_action` (formerly and aliased, `before_filter`) in the application controller, as seen below, means that any class inheriting from ApplicationController will receive the filter (note there are ways to skip filters), and it will be run before any action.

Action filters are slightly more complicated than attr_accessor since we need to deal with inheritance and run arbitrary methods before or after a controller action. But let’s get started. We’ll make some simplifying assumptions to begin, that each action will be in a separate call, and there will be no additional parameters. I’ll leave it up to you to play with ways of relaxing these simplifications.

We first note that each filter must somehow be saved for each class, and that the inheritance structure must be obeyed. With this in mind we can write a simple controller class.

Here we have a simple controller class with basic functionality for supporting before and after filters. Most of the code here is pretty simple and not too exciting. Storing & calling the methods (callbacks) is relatively straight forward. The only piece here that might be a little unfamiliar is the use of `self.inherited`. This method is invoked whenever a subclass is created and gives us the subclass itself. We can use this, and give the subclass our (already defined) before/after filters, conveniently passed through inheritance to our parent class.

Now when we inherit from the Controller class, we have a new class (ApplicationController) with it’s own filters.

Finally the EventsController class defines a few more actions. We can instantiate this and invoke the execute method to see our work in action.

$ EventsController.new.execute(:create)
Checking authentication…
Loading event…
Cleaning up…

We see the simple chain of actions run as expected. The parents classes will run first, which is exactly what happens in Rails.

Rails provides a lot of methods that seemingly augment the Ruby language with new functionality — in reality a lot of this is just Rails taking advantage of the extensibility of the Ruby programming language. I hope that seeing naive implementations of some of these methods will help you understand the dynamic nature of Ruby and embrace the “magic” within Rails. Some interesting things to think about are how ActiveRecord validations work.

Demystifying the Magic of Rails was originally published in Ruby on Rails on Medium, where people are continuing the conversation by highlighting and responding to this story.

BRANCH=master bundle exec cap production deploy

I was relatively sure things would work as long as I got this command right.

Over the past few months we’ve added more servers, more environments, and more employees. I have become increasingly nervous whenever a deployment is going out that something might go wrong. What if we deploy the wrong branch to the wrong environment, or what if we prematurely deploy to production?

I made a few changes to our deployment scripts to ease my worries. The changes are small and simple, but make me feel content that fewer things will go wrong as we grow. The two changes are:

1. Confirm any deployment to production.
2. Configure allowed branches per environment.

First, deploying to production shouldn’t be taken lightly, but a simple confirmation is (hopefully) enough to prevent careless mistakes. This is a task that can be called from any of our environments, production.rb for example. Now each environment is responsible for deciding if it’s confirm-worthy.

Second, we follow the Gitflow Workflow; as such, we maintain the invariant that “master” is always deployable, and it is the only branch that should ever be deployed to production. Similarly we want to restrict staging to branches that either match “master” or “release.*”. This should be simple enough with another Capistrano deployment task. We simply have to define allowed branches on our production and staging environment as necessary. An array of regular expressions does just fine, e.g. [‘master’, ‘release.*’] for staging.

While simple, these changes prevent a lot of things from going wrong. No one will accidentally deploy to production when they’re scrolling through their command history. We will only ever deploy “master” to production, and “master” or “release.*” to staging. I feel more comfortable now that things are a bit more explicit and these simple rules will be enforced.

Many companies have sophisticated methods for doing event processing. One common approach is to use Kafka for event logging and to write consumer services that process the data as it becomes available to them. This is nice because you can log a single event somewhere in your code, and consumers will pick up that event when they’re ready to process it. I talked about this a little bit in my last post, event logging in Rails. I think what I missed out on was the fact that setting up something like Kafka takes time and often what developers want, and really need, is a quick but robust solution that offers the same functionality, without sacrificing the abstraction model.

When I think about implementing something like this in Rails, I want it to be clean and out of the way. In the example above, I could imagine a naive approach calling two separate service objects after creating a post — one call for sending an email, and one call for checking content and flagging posts. This to me seems like poor design. What I’d really like to do is just trigger an Event on a post creation and have configuration around event listeners out of my API. This allows anyone to listen (or consume) an event without continuously adding code to the API. All that is really needed here is to add an event consumer and have it listen to the appropriate events.

Working backwards with this problem, we have a few different consumers that need to somehow be called when an event is triggered. Looking to Rails for help we see that ActiveSupport::Notifications is used by Rails itself for a similar problem, logging and instrumenting various events. The next step is to figure out how to tie each consumer to a given event. This is super easy with Notifications and writing the initializer is trivial.

Here we have a POST_CREATION event being mapped to several consumers — one for emails, one for spam, and another for logging to Kafka. The functionality of the consumers is understood, and this nice thing is that they’re logically different and do not need to interact with each other. I do want to note that the above functionality could be abstracted into the consumers themselves, but I prefer explicitness of defining the mapping in this scenario.

Because we want ultimate flexibility with our consumers, we define them to take in a Ruby Hash called a payload. We’ll define a method named `call` on consumers, one that will be called when an event is triggered.

Now, any consumer can do with the payload whatever they want or need to. Writing a new consumer for an event becomes really easy and doesn’t need interaction or coordination with the API controllers at all.

Let’s say that we wanted to add a new consumer to do something when a post is created. Perhaps we want to do a bit of text analysis (a little tf-idf trickery) and determine what the post is about so that we can either add it to a category or surface it in recommendations.

Here we have written a simple consumer that enqueues the analysis for asynchronous execution. While there’s obviously post analysis code missing from here, the only changes we really needed were to write the consumer and update our EVENT_CONSUMER_MAPPING.

The final step is to define what an event is and create an easy way to trigger them. Here, I have defined a base class for such an event, and defined a few methods to help keep things clean.

Now we can finally define our post creation event.

With all of this in place, the last part is to trigger the event, and that can be done with a single line of code.

PostCreationEvent.new(@post).trigger

Removed from the above code snippets, for simplicity and clarity, is default asynchronous behavior, and the ability to opt-in to synchronous processing. Extensive use of this abstraction shouldn’t block or slow down requests, so asynchronous behavior is desirable. But, it might make sense for some consumers to specifically opt-in to synchronous behavior though, so that could be an option, though I might advise against it.

While there are other ways of achieving some of the functionality outlined above (active record callbacks, etc), the point of this is to offer an abstraction — and a damn useful one. ActiveSupport::Notifications takes care of a lot of the heavy lifting and allows us to focus on the important details and the business logic. The ability to trigger arbitrary events and further allow for arbitrary consumers enables application developers to iterate very quickly on new ideas, keep great modularity, and work within a scalable model that allows for future improvements or optimizations when necessary.

Event logging has the benefit of separating the “producers” of data from the “consumers” of data, and allowing each to perform individually. For example, you most certainly don’t want a real-time anomaly detection service running synchronously in your API. A first step might be to throw a resque background job at the problem. But then you’ll soon realize that you’re doing the same thing over and over for each new type of service you need, and that each service might need the same data as other services.

Enter Kafka. I’ve been a huge fan of Kafka ever since reading Jay Kreps’ The Log. The short of Kafka is that it allows you to have different and disparate producers and consumers of data/events, and separate the logic into services to meet your needs. The best part is that producers don’t need to know about each other, inform each other of their existence, or coordinate beyond agreeing on data transport. Producers just produce data (throw it at Kafka) and consumers just consume data (read it from Kafka).

I wanted to add a naive Kafka event-logging service to my Rails app. I had a couple of self-imposed requirements to make the service easy to use and avoid cluttering my code.

• Logging must be encapsulated and easy to change what’s under the hood.
• Events should have some standardized format, but also encapsulated enough to change them around when necessary.
• It should be very easy to add new event types.
• It takes a single line of code to log an event — this wasn’t a strict requirement but I really didn’t want to litter my API with a ton of lines (more than 1) of logging code.

After a few hours and a couple iterations I came up with something that I was generally pretty happy with, knew fit my needs right now, and pushed it to production. Below is a simplified version, removing clutter such as experiment groups, etc.

I created a base Event class that contained all of the common code/setup for each event, an event class for each event type — LoginEvent for example, and an EventLogger class for actually logging events.

The above shows an example event, this one being an event for login attempts. The Event class uses the event_type method in order to nicely structure the payload, simply adding an event_type field. The topic method is used by the EventLogger to decide which topic to write to (admittedly I’m least happy about this mixing of concerns). Finally the payload method provides the data that will ultimately be logged to Kafka.

Adding this to our SessionController, we might do something like,

The final piece to this setup is the actual EventLogger. The nice thing is that the API doesn’t really care what the event logger does, as long as it’s not blocking. Without Kafka, you might just do some simple statsd logging, or even write to a local file for later manual inspection and analysis.

Here we have a single method that calls out Kafka producer with the appropriate topic and payload.

It is really easy to begin logging with this setup in place. We only have two steps: First create a new event class for the new event to be logged, then log that event from the API. The nice part is that each event fully own’s its payload function and has the ability to log whatever information it wants. Moreover the logger is fully encapsulated and we, as in the API, don’t need to worry what’s actually happening under the hood.