Chris Oliver

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.

Looks similar but I've never used Dragonfly. Unless you need some other feature, it probably isn't worth switching yet.

I did! Thanks for your work on paranoia! :)

Very good to know! Thanks @Marklar

That's a great question and I don't particularly know the answer to that. I'm sure you can open an issue on Github and get a response.

I like that approach. And dang, 1.5M data points is a lot to import.

That's a really great point. What do you think is a good way to handle that case? Do you let them attempt it, count the lines in the file, and then return an error telling them to contact support if it is over a certain number?

I definitely need to cover ActionForm soon. I'm glad the Rails core team members are actively working on it.

You're welcome!

Yeah, that's an issue with redirects and AJAX. jquery_ujs tries to combat that by following the redirect, but it obviously doesn't help since you need to handle that response separately. The simplest solution and what you should generally do is to just disable those links when users are logged out.

If you want to keep them enabled, but then show a sign in form, it's quite a bit more complex and would require you to write your own handler in JS to capture that response and handle it separately.

Very cool. I really like this idea and certainly something that should be in Rails core if they continue supporting JS responses.

I believe FasterCSV got rolled into Ruby 2.x at some point so you don't need to use it anymore.

Their repo is fantastic for people familiar with how to setup Ruby. This guide's goal is to teach newcomers the basics.

I can't quite remember. You can try without and see if things like update work correctly and don't create a new forum_post. It might be required so it knows which record to update, but it might not. You may need to play with that to verify.