How to create a User and an Account in one form with Devise

November 22, 2015 By Austin Story Leave a Comment

Most of my apps these days that are pure html with a backend are written in Ruby on Rails and use the Devise engine to handle password and account creation type things.

For this example we will be assume a few things

You have rails 4+ and Devise Setup
Devise routes are setting the registration controller as your custom controller.
models are User and Account
User belongs_to Account (so User has an account_id)
User responds to set_admin to deal with however admin is setup.

I was reading through the source the other day and saw this block option in the RegistrationsController for devise

[ruby]

class Devise::RegistrationsController

# POST /resource
def create
build_resource(sign_up_params)
resource.save

yield resource if block_given?
#other devise stuff
respond_with resource
end
end
[/ruby]

[ruby]yield resource if block_given[/ruby]

means that we can pass some code in as a block (which is just an anonymous function) that will receive the resource as a parameter.

In your resources controller you can override like this

[ruby]

class RegistrationsController < Devise::RegistrationsController
def create
super {|user| user.create_account }
end
end

[/ruby]

So with this code, super sends the block up the chain. So the result is that when we get to the yield resource, the resources receives the message ‘create_account’.

This is great, now we are able to delegate all of our registration logic to devise. But wait, what if we now want to set the user as admin on the account and make sure that it is all wrapped up in a transaction? That is easy, just expand the block.

[ruby]
def create
ActiveRecord::Base.transaction do
super do |user|
user.create_account
user.set_admin
end
end
end
[/ruby]

At this point, we have fulfilled the feature that we create the account along with the user and set that user as the admin on the account, so ship the feature!

Testing Action Mailer with Rspec

May 7, 2015 By Austin Story Leave a Comment

This is more so that i have this documented for later.

Say you are wanting to test that an action mailer instance receives a mailer. Here is the code in RSPEC

[ruby]
SomeNotifier.should_chain_receive(:delay, :mailer_message_you_are_sending)
[/ruby]

Ruby/Rails Metaprogramming – Creating a custom alerting module

April 19, 2015 By Austin Story Leave a Comment

I recently needed to be able to dispatch some very context specific alerts when some of my classes are saved. However, the alert and who gets it are completely different based on the class and the context of quite a bit of business logic. This could be accomplished is several ways, I will explain these and then show how i accomplished it with metaprogramming and modules.

The most straightforward way to have done this would be to just add an alert method in each class and then implement the logic there. There are several reasons to shy away from this including polluting your model, strong coupling and harder testing. However, I shy away from that because it promotes bad coding. Each time you tack on just one more method to a class it makes it that much easier to do it again. I’m not saying never just add a method, but think about whether it could be it’s own thing first.

The next would be to have a giant class that handle the logic. This would be better because all the logic for alerting in the app would be in one spot. However, the logic would have several branches (i.e is this a comment or an image or a new post?).

Ultimately i created an alertable module that I included in my models.

[ruby]module Alertable
extend ActiveSupport::Concern

included do
after_save :alert
end

def alert
"Alerts::#{self.class}".constantize.new(self).call
end

end

class Comment < ActiveRecord::Base
include alertable
end
[/ruby]

From the top, ActiveSupport::Concern gives me both class level methods (after_save) and instance methods (def alert). Pretty neat.

The alert method is a bit of metaprogramming that allows me to put the alert logic in it’s own module namespace (aka directory) like this

models/comments.rb #Normal ActiveRecord Model Location
models/alerts/comments.rb #our new Module

Because alertable is include in Comment, when a comment is saved it now does a callback for the method ‘alert’. That is also included from Alertable so after it sees that there are no alert methods defined in the Comment class it calls “Alerts::Comment”.constantize.new(self).call Which is located in models/alerts/comments.rb

The comments.rb file under models/alerts will look something like this.

[ruby]
module Alerts
class Comment
def initialize(comment)
@comment = comment
end

def call
#Do alerting stuff
end

end
end
[/ruby]

So now any time that i need to do some alerting in my program, i include Alertable and then i can either implement the alert method on the class i’m including it into or (preferably) create a new Alerts::#{class_name} file.

I think this setup is better than the 2 previously mentioned because everything that is related to alerting is not located in a single area of the application. The alerts are their own thing in their own area of the application. The downside is that we have callbacks for the Comment class that are completely encapsulated in a module. So that could cause trouble for newer programmers to the project or if the alert ever returns falsy it would halt the save of our comment and not be immediately apparent as to why it was failing.