Chris Oliver

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.

Definitely. You can use this a bit too early and it just is more painful than anything. The example of the navigation is bad because right now, I'd rather have the if statement, but in the future as it gets way more complex, null objects would make more sense.

There's certainly a balance to find when applying this (like any pattern).

Awesome! Glad that worked. The error came from trying to install a gem into system ruby. Some people will tell you to use "sudo" to fix it, but that's not fixing the real problem which was that it was using the wrong version of Ruby.

Good rule of thumb is that you should *never* use "sudo" when working with Ruby. It's always a sign you're doing something outside of rbenv and something's configured wrong.

Fingers crossed the rest of your setup goes well!

It sounds like you aren't using the proper version of Ruby and it's trying to install in your system Ruby. Make sure you didn't miss any commands and try restarting your terminal. When you run "which ruby" you should get something like "/Users/chris/.rbenv/shims/ruby".

Most of my projects are private and I put them on Github (paying for private repos) and you could easily store them privately on Bitbucket. In either case, your Capistrano URL will securely authenticate with Github or Bitbucket using your SSH key to check out the code. It logs in using that so you don't need to use a password to clone the code on a deploy.

Always the file named Gemfile in the root of your Rails application. It's the defining list of dependencies for each Rails app. You save it in each app so that all of them can use different versions without fighting each other.

Hey,

Forms normally send a POST request and since the user is saving data, you definitely want a POST.

You'll need two routes for this, one to show the form and one to save the data after the form is submitted. I would recommend changing your controller to Links plural so you can stay with the standard naming.

get 'links/minecraft' => "links#minecraft"
post "links" => "links#create"

Then you can make your controller:

class LinksController < ApplicationController
  def minecraft
    # This is empty so the view can render the form
  end

  def create
    if current_user.update(user_params)
      redirect_to action: :minecraft, notice: "Successfully saved your Minecraft ID"
    else
      redirect_to action: :minecraft, alert: "Please input a valid ID"
    end
  end

  private

    def user_params
      params.require(:user).permit(:minecraft_uuid)
    end
end

And your form would be a normal form_for current_user using the minecraft_uuid as the field to render out.

Since you've got some code to look up the Minecraft UUID, you can add that to the model as a validation to look up and verify it. Add an error to the record if it is invalid and that will cause the update call to return false.

I'd definitely just stick with one.

Ah yeah, you're right. I have always been careful about hashes when it comes to ordering because I wasn't sure it was a requirement for the ruby implementation.

Yep, you can call the "render" method like you normally would and send it as an attachment to email or upload it to S3