Rails

Service objects are a handy tool to use in any ruby application, that has complex logic that needs to be extracted out of a controller or model. There are some nice benefits to extracting complex things into a more testable interface. To avoid providing a contrived example, I will use similar code to how uploads on rubyfm are handled. class UploadService attr_reader :user, :logger, :upload def initialize(user, options = {}) @user = user @logger = options[:logger] || NullObject.new @errors = {} end def start(params) @upload = build_from_params(params) unless @upload.save logger.error { 'failed to save the upload' } # more logging info on why return false end unless transcode logger.error { 'failed to transcode upload' } return false end true end def transcode AmazonTranscodeService.new(@upload).start end end And the UploadsController that utilizes the UploadService with the following. ...

As I work on API projects I find myself having to track down status codes and ensuring a consistent response code for any given error. Keeping these status codes consistent throughout the application starts to become a hassle. A solution that I stumbled upon happened to be something very simple. # /lib/errors/unauthorized_access_error.rb module Errors class UnauthorizedAccessError def status 403 end def message 'unauthorized access' end def to_hash { meta: { code: status, message: message } } end def to_json(*) to_hash.to_json end end end In my controller I would do the following: ...

A state machine is an interesting design pattern. The state_machine gem is a great library. It provides a nice structure to declare states and transitions. It also provides nice callback hooks that can be utilized to run specific actions before or after a transition happens. It has hooks into ActiveRecord and saves the model when the transition from one state to another is successful. The gem also works just fine with plain old ruby objects as well. Here is a simple example of a state machine. ...

As a Rails application grows and evolves. Fat models often become rampant in the application. ActiveRecord callbacks are used and models start interacting with other models in ways they should not. Enter the idea of “dumb data objects”. It is nothing more than a simple data structure. It holds state and that is it. Only methods that display data or modify the internal state should be on the model. ...

Rails is a wonderful library. It’s a framework that is opinionated and requires some footwork on the developers part. One such issue is returning nil when the return type is an object. Returning nill doesn’t provide the view enough information about what actions to take and leads to complex whack-a-mole scenarios. The solution to this problem is to introduce a NullObject into the application. There are null object libraries already available, but they are so dead simple to write that it’s not necessary to use one. For example, it would be trivial to declare this basic NullObject. ...

Recently I’ve been playing with Ruby’s class_eval and define_method to append methods to an object. Meta programming is something new for me and I had a problem that would benefit from using some of Ruby’s cool features. The Problem There was a model that had 6 fields that needed to be generated at some point in time. Some fields had to be unique and others had to be generated a bit differently. Here is a contrived example of what I was doing: ...

One day I found myself riding in a car with my family and it was a long road trip, with little to no internet and realized that my tests required internet connectivity. I was also heavily dependent upon code examples that I could find. I’ve been absolutely horrible with testing my code. I would write code, test it out in the ruby console and then push it live. It felt like I was moving fast. I was being agile. Wrong! Testing is necessary in order to succeed. Often I would push code and do the good ole’ cowboy code em’ up. This is a horrible idea, don’t do that. ...