Chris Oliver

Yep! I think a lot of people do 'whatever-rails' and that's probably what I would recommend. You can do any naming scheme you want, but that seems to be the most common and it's good for SEO too.

Yeah, it's definitely designed for that purpose. You may need to figure out if you can make sure that the new edits don't go live immediately and can get marked as "to be reviewed". I'd give a shot, but I'd also say it isn't too hard to build your own if you find that doesn't meet your needs or it's inefficient for what you want.

Awesome! I'm glad I could be of help! :)

That's exactly what I do. Mine is a little different, but just make sure you return a class that inherits from CanCan::Ability and you'll be fine.

module Abilities
  def self.ability_for(user)
    if user
      if user.admin?
        AdminAbility.new(user)
      elsif user.editor?
        EditorAbility.new(user)
      elsif user.member?
        MemberAbility.new(user)
      end
    else
      GuestAbility.new
    end
  end
end

1. Unless it is an action (with a view), you always want to put those methods in the private section. You don't have to, but it's a good idea to.

2. Yep, that's it! That's basically just going to call the method instead of using the param directly. The method is the one that looks it up directly and then makes sure it gets converted to a sane integer.

You'll need to use a block and filter by the ID in the user's list.

This isn't exactly what you'll need, but this is one way of checking if a project is in the user's associated list. You can modify this for your authorization.

can :manage, Project do |project|
  user.projects.map(&:id).include? project.id
end

And here's more information on this: https://github.com/ryanb/cancan/wiki/Defining-Abilities-with-Blocks

The page method he suggested should work nicely. I have had this issue before on GoRails too.

You can add this to the bottom of your controller or ApplicationController and just replace all the params[:page] references with this method page

def page
  p = params[:page].to_i
  p > 1 ? p : 1
end

I'm kinda surprised will_paginate doesn't handle this internally.

Absolutely can. I'm a fan of Pundit over CanCan, but choose whichever one you are more comfortable with.

You can just filter them out with a scope that says where clocked_out IS NOT NULL. That should do the trick.

Hey Gareth, when you do a soft delete, there should be nothing that happens other than a database field called deleted_at getting set. This won't affect images at all because they should only get removed when destroyed. Are the images actually getting removed?

You could calculate the total and cache it. That would make for editing to be easier. For totalling, that might make it easier where the total defaults to 0 until the clock_out time is added so the sums are always correct.

I don't see any real downsides to that off the top of my head. Do you?

You could do

def set_uuid
  return if persisted? # Don't run if this record has already been saved

    begin
      self.minecraft_uuid = MojangApi.get_profile_from_name(minecraft_uuid).uuid        
     rescue Exception => e
     end
end

You could use something like Pundit to count the number of subscriptions and cause something else to happen or prevent it from working at that point. Check out this episode https://gorails.com/episodes/authorization-with-pundit

Recurring events get complicated quickly! :)

You may need to do a find_or_create for all the recursivedates when you do an edit. It also might be easier to delete all the existing ones before adding the new dates. That will save you some trouble. I'd take a look at how Google Calendar does it and work backwards from there if you like the way it works.

I think they may calculate on the fly the recurring ones so they don't have to insert records for X years into the future and your calendar will always work. They probably separate individual dates and recurring ones and query for both each time the page renders.

That's not a bad solution for now to handle it manually.

In general, you simply want to lookup and validate the UUID only when the username changes. There are a bunch of different ways you could do that, but I forgot that you could use ActiveModel::Dirty to check if the username field had changed. This works because when you set the field the first time it technically "changed" from nil to one the user submitted.

before_validation set_uuid, if: :username_changed?
validates :minecraft_uuid, presence: true

def set_uuid
    begin
      self.minecraft_uuid = MojangApi.get_profile_from_name(minecraft_uuid).uuid        
     rescue Exception => e
     end
end

The best way to handle that is authorization with Pundit. You can load up the project and verify if the current user has access to the project based upon the associations set. They will be able to change the ID in the url, but Pundit will throw an error if they try to access one they aren't a part of. Here's an episode on Authorization With Pundit that I did a while back.

Basecamp follows this approach and doesn't have any troubles. It will always depend on how intense your JS ends up being, but you can also cache the results of these queries in the constructor and reference their results for faster access.

At the end of the day, if you're not doing that much constant manipulation, you're not going to run into any performance problems with this. Obviously when you're doing a lot, you're going to want to know exactly how the browser handles each manipulation.

Agreed, this was my point that was hard to get across in a simple example. It's not hugely beneficial on small projects or teams, but it adds up the larger a project becomes.

As soon as you have a designer or two fiddling with the .todo class in CSS and moving things around, you're likely to see things break really quickly. They won't understand how they broke functionality and it's much harder to track down when things go wrong.

I'd say the main benefit of using data attributes instead of classes is that it's a clear separation of responsibilities. Designers can fiddle with all the classes and IDs they want so long as you remind them not to mess with the data attributes. It's just a little easier recognizable than "js-" prefix.

Yes! There were a few episodes that I did sloppily in the past that don't have it but most all of the recent ones have source code linked in the Resources section underneath the video. Some of them I use the same repository for so you can see the evolution of the code in the various commits like this one: https://github.com/excid3/gorails-episode-56

Sounds like you've got an issue with your internet connection.

http://stackoverflow.com/qu...