Tagged: ruby

Now that the dust has settled from Square's acquisition of Framed, I wanted to take some time to talk about the building blocks of simple software, and the things I think we got right at Framed.

The Framed platform was written entirely in Clojure, and at its peak it was processing hundreds of millions of analytics events per day and running machine learning models over tens of millions of input points with thousands of features.

If you've ever spent any time reading about functional programming, you may have heard about "partial function application" or "currying". For the longest time these were just big scary words to me, but it turns out they're relatively simple concepts. I've read plenty of posts describing what they are , but it wasn't until recently that I really came to grasp why one would ever need them. In this post, I'll briefly go over how partial application/currying work (and the subtle difference between them!), but I mostly want to talk about why you should care and when they can be used.

This is part 3 of a series taking an in-depth look at how the internals of Rails handle requests and produce responses - be sure to catch up on previous parts!

• Part 1 - Introduction + Unicorn
• Part 2 - Routing

Last time we focused on how requests are routed to controller actions through Journey and the ActionDispatch stack. This time, we'll look at ActionController and how controller actions turn into a rendered view.

The last post ended with the #dispatch method of the ActionDispatch::RouteSet::Dispatcher, which actually calls the controller action. Here's that method as recap:

This is part 2 of a series taking an in-depth look at how the internals of Rails handle requests and produce responses - you can read part 1 here.

Last time we took a brief look at how Unicorn workers accept clients from a shared socket and call our Rails application, and how requests bubble down through the middleware stack before arriving at Blog::Application.routes. We're now at the routing stage, where we need to match the request URL to a controller action and invoke it to get a response.

I've been developing Rails applications for personal and work projects for several years now, and I recently realized that my understanding of the Rails internals was relatively limited. I'm totally comfortable wiring up routes and controllers and working with all of the MVC goodness that comes with Rails, but I didn't really understand how it all tied together under the hood. I decided to change this by diving into the Rails source code to really understand what happens from the point that a request comes in to when a response is rendered and sent back. The result is a series of posts with some findings that I hope will be interesting and informative to anyone who works or has worked with Rails.