For many of us web developers, we work on the highest levels of abstraction when we program. Sometimes it's easy to take things for granted. Especially when we're using Rails.
Have you ever dug into the internals of how the request/response cycle works in Rails? I recently realized that I knew almost nothing about how Rack or middlewares work, so I spent a little time finding out. In this post, I'll share what I learned.
These days, there are so many different choices when it comes to serving data from an API. In many cases, you just want to bring something to market as fast as you can. For those times, I still reach for Ruby on Rails.
When building an API in Rails, you need a good solution for structuring your JSON. ActiveModel::Serializers (AMS) is a sensible choice. It's powerful alternative to jbuilder, rabl, and other Ruby templating solutions. It's easy to get started with, but when you want to serve data that quite doesn't match up with the way ActiveRecord (AR) structures things, it can be hard to figure out how to get it to do what you want.
In this post, we'll take a look at how to extend AMS to serve up custom data in the context of a Rails-based chat app.
Request specs allow for higher-level testing of a Rails application (as compared to controller specs, for example). They still run in the same process as your application code, but instead of directly instantiating classes and invoking methods, they make requests to endpoints and validate the responses.
If you're like me, you love to code because it is a creative process.
In another life, I am a musician. I've always loved music because it represents a synthesis of the concreteness of math and the ambiguity of language. Programming is the same way.
But despite the creative potential of programming, I often find myself spending days working out the kinks of HTTP requests or dealing with SSL certificates. Some part of me yearns for a purely Apollonion environment in which to use code to make something new and unseen.
When I feel a void for purely creative coding, I turn to the Processing language.
One of the biggest challenges of object oriented programming in Ruby is defining the interface of your objects. In other languages, such as Java, there is an explicit way to define an interface that you must conform to. But in Ruby, it's up to you.
Compounding this difficulty is the problem of deciding which object should own a method that you want to write. Trying to choose between modules, class methods, instance methods, structs, and lambdas can be overwhelming.
In this post, we'll look at several ways to solve the Exercism Leap Year problem, exploring different levels of method visiblitiy and scope level along the way.