Chris Oliver

You can apply scopes to ransack search results to also include it in the query. @q.result.my_scope

You're right that you should get body in the controller in params. In the controller you should get params[:q][:subject_cont] with Ransack.

Yeah they are. Check out the Mandrill episode to see how I set that up. https://gorails.com/episode...

The only real time you need to use "self" in the model methods is when you want to assign an attribute. Not using self will create local variables. If you're just working with the values and not changing them, you don't have to use "self".

Unfortunately that wouldn't make a difference. That feature is controlled entirely by the browser on the device. It will work differently depending on the OS version and browser.

One thing you can try is to play with the accept and capture attributes on the file field itself and see if it will trigger different things on your Android browser. I can't find great documentation on it though, but check this out to get started. http://stackoverflow.com/qu...

You need to pass in params[:q] so it passes in both the name of the field and the search you want to do on it. Since it supports multiple fields in search, you pass them all in instead of just one.

Glad you like it!

I found another one recently called action_access that looks to have a wonderful API but I've never used it before. Hope to do a screencast on it soon.

My preference is Pundit over CanCan because I find it clearer to understand what's going on.

That's probably what I would do. I'd have a single User model, authenticate with Devise, and use Omniauth's Devise integration to manage that Facebook and Twitter login.

With Facebook you get an email, Twitter doesn't give you one. Since you basically need a User as the main account for everyone, you'll need to ask for an email (and preferrably a password) after they login with Facebook or Twitter. You can prepopulate with Facebook's email and leave it blank for Twitter. The user can then confirm this is the email they want to use on their account (and optionally a password).

Then you can create their User record, save their Twitter or Facebook account as an associated model to the User. I usually call this Service.

class User
  has_many :services
end

class Service
  belongs_to :user
end

And your Service would store things like the social network name, their username/ID on the social network, and any other metadata like their avatar url.

That way they can then sign up with Twitter or Facebook but you've also got an associated User record.

Signing up as User first and then being a contestant means that you simply look up the User with the email they provided and associate the Twitter/Facebook account with it instead of creating the User.

Thanks! I've added that to the instructions. :)

Awesome! I'll be sure to tweak those soon since the final release comes out soon!

Yes it does. It's basically creating an array with one item in it and that item is the User from the belongs_to relationship. You can't do "current_user" because it's a method that's only available in the controllers and views. In the model here, we only have access to the current ForumPost record and it's associations.

That's a great question. Do you think you want separation between your account as a contest creator and as a contestant? It may be easier to manage to separate them by doing something like Admin and User, but it might also be confusing. If I create an Admin account and then click on someone else's contest, I would have a separate User account from my Admin one without realizing it. That might work fine for your application, but I just wanted to see if you had any reason to keep them connected.

If you keep them connected, you could connect the Twitter & Facebook accounts to a User, skip the Admin model, and then allow contest creators to attach their Facebook and Twitter accounts so they can see both the contests they created and the contests they are a contestant in. Depends on what you're going for here.

Do you have any preference either way?

Whoops, actually that is going to call ".likes" on the "pin" variable, so you will need to double check "has_many :likes" on the Pin model. If that is there, then you potentially passed in a nil for pin. Then you'll need to check your controller to make sure that @pin got set to a Pin.

According to the error, it sounds like maybe you don't have "has_many :likes" set up in your User model correctly so it can't find it. Double check that you've got that in there.

And "likes?" is written in the User model as a cleaner syntax for determining if the user likes a an object. Basically you wouldn't want to have the logic for determining that duplicated in your app everywhere, so we put it in a method in the model to make it more readable everywhere else.

I'd say probably using a jQuery AJAX request. If you use a dropdown, set the value to the region's friendly ID and then write a jQuery callback to listen to the dropdown's change event.

Something like:

$("#my_dropdown").on "change", (e) ->
  e.preventDefault()
  $.ajax(
    method: "GET",
    url: "/runs/region/#{$(this).val()}",
  )

Of course you'll need to plug in your success callback to handle the response. You could have the controller return a JSON object that contains an HTML partial if you want to simply render it server side and update the page with that content. It would save you the trouble of using JS to update the page and having the view rendering logic.

Permalink being just a pretty ID instead of a number if you wanted. You can just search on ID instead of permalink too. I just tend to always use friendly urls anymore as my default train of thought.

From my perspective, I always use Devise and then make my overrides to it as necessary. The reason for that is because Devise is very well tested. I think it's much more likely that implementing our own auth systems is much more likely to have subtle mistakes and security vulnerabilities than going with Devise first and then customizing it. It gets constantly updated and is tested by thousands of developers and users all the time whereas my custom system is unlikely to get security tested that often.

That's my reasoning for using Devise as the basis and then customizing it. You're probably fine going with any system you want including rolling your own, but you'll want to keep in mind the more testing, the more secure it will be.

I'm not completely sure I follow, but what about this.

You could have a route that is like /runs/region/:id and then your code could just query for that. It would always hit one controller and that controller can query for Runs.joins(:region).where(region: {permalink: params[:id]}) or something.

Campfire, known for being the most popular chat application, was built using polling. You probably don't absolutely need to handle chat in realtime. It did a 3 second poll and updated the chat each time.

That said, Faye is great and so is something like Pusher. I don't know that it really matters either way you go other than going with the one you're more familiar with maintaining for stability reasons.