Chris Oliver

Nope, This should be all you need.

Yes, Ruby and Rubygems get updated at different times. Everything looks good there but you should upgrade to Rails 4.2.1! :)

When you register for Mandrill, you have to sign up with an email address. That's the email you will put into the user_name field so it knows which account is sending the emails.

I don't think I've touched that for a bit. If you see it broken, send me a screenshot and I'll make sure to correct it. They should definitely be on the index page.

Good catch! That should actually reference @params in the PORO because it doesn't have access to lead_params in there unless you move that code too.

I think if that all happens server side, you should be fine. Since the session is encrypted, storing the token should be safe there. This is basically how login with mobile apps works. Make sure you're sending the token over SSL so it's not publicly accessible over the network and it's usually best to set an expiration on tokens if you can.

Devise is its own authentication system. If your registration API is in the PHP app, you won't be able to use it and you'll need to write your own code to handle that instead. Devise doesn't talk to APIs for authentication, just the database.

If you're putting the user authentication in the new Rails app, then you could use Devise.

Make sense?

My two suggestions would to either put this in the index or in an action called active with it's own route.

1. You create the active action with a route. This will let you create a separate view and render a different HTML template.

2. You just add it to the index by checking a query param:

def index
  @projects = policy_scope(Project)
  @projects = @projects.active if params[:filter] == "active"
end

Lots of different ways you could implement this, but the simplest example is just adding a scope to the Relation that you are rendering based upon a param like filter. This is nice for adding more filters in the future which you might want to do as well.

You might check out this gem: https://github.com/magoosh/...

Yeah that's what I would do. Remember to have this only: [:edit, :update, :destroy] so that it doesn't override your show action's lookup which is normally set in a before_filter as well.

The important part is making sure you edited your .bash_profile and added rbenv to your PATH. That will allow it to find the rbenv ruby before the system ruby.

This is the important line from above (after you installed rbenv)

echo 'if which rbenv > /dev/null; then eval "$(rbenv init -)"; fi' >> ~/.bash_profile
source ~/.bash_profile

They way you could solve the authorization problem is by updating your Edit/Update/Destroy actions to use current_user.books.find() instead of Book.find(). That will scope it to only the ones that user owns so they cannot edit other user's books.

This is awesome and I'm definitely going to check it out tomorrow!

If you're authenticating between different apps, then you want them to share the same secret key. The cookie_store is signed with that key (I believe) so you would simply want to modify both apps to use the same SECRET_TOKEN in your application.yml files in production. That should do the trick (along with setting the domain on the cookies in the other post you mentioned).

There is basically no difference in your workflow other than SSHing in for running the server. Like I mentioned, the folder is shared between the host and the VM guest. You have to install all the tools inside the VM to run the app, but since it's shared you can edit in either place. You debug your app exactly like normal through the terminal. It just happens to be inside SSH to the VM, but there is almost no difference.

I agree! It was also awesome to meet you in person Jared!

A combination of decorators and the null object pattern can go together quite well. Curious to hear how it goes for you!

Awesome, glad you liked it! :) Definitely want to cover more of these design patterns and their practical uses.

That turned out really clean! I'm glad you guys got it working. Airpair is pretty great.

Yes, the none method is super helpful for situations like that. I'm really glad they added it.