When I moved into a short-term apartment in January, my then-roommate had an espresso machine, a gorgeous Breville BES900XL. He taught me how to use it, and I immediately fell in love with making cappuccinos in the morning. My roommate knew all about the different types of art, and taught me how to froth the milk and make a simple tree shape. It’s trickier than it looks, and most of the time I would under-froth or over-froth the milk and pour it too fast or slow, yielding nothing at all or a vaguely-misshapen blob if I was lucky.

For a brief period of time after college, I ran a small consulting firm with a partner. During that time we had a short but insightful conversation with the CEO of a client company, asking for his advice and talking about general motivations. Several things he said really stuck with me - this post is about one of those things.

~

My partner and I incorporated an LLC for our firm. We had not attempted to hide the fact that consulting was not our end goal as a company; we hoped to consult to get a cash ‘safety net’ in the bank and make some contacts in industry with the ultimate goal of spinning off into a startup / product company, à la 37Signals (now Basecamp). We told the CEO this, and one of the first questions he asked us both was simple and direct:

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.