Chris Oliver

You would create a new "Lesson" record for each each video and have one video upload per Lesson. Do the same as this basically and you're all set. It would be just like creating multiple Film records for the same Actor.

There's a typo in the tutorial there. You actually want the .wrapper version commented out in the example config there. I'll get that fixed shortly!

Another option I just thought about is that you could use CSS to hide the weekends (the first and last TDs in each column) and render the normal week_calendar.

Yes, but you would want to create a custom class that inherits from the main calendar. You can take a look at this as an example and adapt it to be a business-week calendar. https://github.com/excid3/s...

I don't think I would consider that being a bad practice. It's going to be nice to have invalid url's redirected to the root. Potentially this is something that Google frowns upon because you're not returning a 404 response though. That might have negative SEO impact potentially.

The other thing this wouldn't handle is missing records. Imagine you have blog posts at /posts/:id. If you visit /posts/asldfjalsdf and a post with that ID doesn't exist, you'd get an error. There's a method called rescue_from that you can use in the controllers to catch from issues like that one. That might help if you want to have a more robust invalid url catching.

I'd say do some research to see if Google doesn't like redirecting to root for missing pages and see if that's a bad thing or not. Maybe someone else here knows too.

Make sure you run the ruby-build lines before that.

You could skip all this and use apt-get to install Ruby, but the reason we do this is so that when a new version comes out later, you can easily upgrade without losing anything. apt-get will stick you with one version and you won't be able to upgrade it until the Ubuntu developers get around to adding the new version which takes quite some time.

http://localhost:3000/forum_threads/4/forum_posts is the URL you want to POST to when creating a new forum post. This is what the form's action will point to so that part looks correct.

Your code inside the controller looks correct as well and should redirect back to the forum thread path.

"uninitialized constant ForumThreads" sounds like maybe your module on the controller specified might be with a different spelling? Was it singular :forum_thread in your routes? That would mean you need to do class ForumThread::ForumPostsController if so.

Yeah since bundler is a gem, you have to install it separately for each version of Ruby. Maybe they'll have it ship with Ruby at some point.

That definitely seems like the simplest approach that I've found over the years. I still haven't played with chruby, but it seems all the ruby version managers treat .ruby-version pretty consistently now so it shouldn't really matter what you use which is great!

I simply set the Ruby version manually per project.

cd my-rails-app
echo "2.2.1" > .ruby-version
git add .ruby-version

When you cd into the directory, it should autodetect and switch for you.

You probably would want to do the same thing in your 1.9.3 apps to set their versions. If you do that, then your global ruby version doesn't matter since each app specifies what they need.

With that approach, you won't have to worry about wiping out any of your existing rubies or gems. rbenv will just seamlessly switch between whatever is already installed.

Any uploader that submits the file to S3 will work with Zencoder. They expect that your original video file is already available on S3 so they don't have to worry about which uploader you use. You're free to go with Refile, Carrierwave, Paperclip, etc.

I'd say any time you're making supporting classes. For example User::Import should be a separate class from User to provide the functionality we want, but at the same time it's really closely tied together with User. That's usually a good sign it deserves being in a module like that.

If you use the generate model functionality, that would actually create a full ActiveRecord object and database table. In this case, I don't need to store the uploaded CSV files, so using an ActiveRecord model isn't necessary. We use ActiveModel::Model to give a regular Ruby class much of the same functionality as an ActiveRecord::Base object would have. That's what makes it easy to create a form_for @user_import.

Make sense?

Validating URLs is tough for the same reasons that validation on emails is tough. You can't verify the url or email is correct or live, only that it fits a format with regex.

It looks like Diego's regex here is the best option for correctness. https://mathiasbynens.be/demo/url-regex

Another great site for testing regex is http://rubular.com

It looks like on the Ransack docs, they do this:

class Artist
has_many :memberships
has_many :musicians, through: :memberships
end

artists = Artist.ransack(musicians_email_cont: 'bar')

Great post Andrew! That's a great approach and breakdown on the gotchas. You could either use a randomly generated ID of some sort, or you could add an incremental ID scoped to the company in as well. That can be nice so that you have more memorable ID numbers if you need them. This is how Github pull requests always start with #1. The real database ID is a separate number.

I'll be recording a couple episodes soon on how to set up multitenancy with subdomains. It's definitely not a simple thing, but really isn't too bad once you break it all down.

Oops, fixing!

Yeah the rollbacks only really happen when validations have failed to pass. That's something you'll pick up along the way and it helps point out what's wrong.

Best tip for debugging something like this is to make sure you've got the "byebug" gem installed and stick "byebug" into the controller before the save and then run the save manually from inside the byebug prompt. You'll get immediate output there letting you know if it worked or not and that can help save hours of debugging. :)

Looks like it's working correctly to me but validations caused it not to save. Double check all of those are passing.

You're really close. To create a form for a new comment on a recipe, you would do "form_for([@recipe, @comment])"

To create a new like on a recipe comment, you would do "<%= form_for([@recipe, @comment, @like]) do |f| %>"

I usually go for simplicity and don't use decorators for something like this. It's just a single method and I've already got a helper available so putting it there makes sense to me.

I find decorators are great for more complex things that manipulate record data into something more visible. A contrived example is a UserDecorator that has a "name" attribute that combines the "first_name" and "last_name" fields and does similar things for addresses. That rarely belongs in a model but it's a bit more logic than you'd want in a bunch of separate helper methods.

Ah! Thanks. You find my copy-paste job from last version. ;)