Chris Oliver

I personally store my configs in a Git repo, clone it on each machine, and symlink the configs.

It depends on their SMTP system, I've seen the same delays at times. They might be queuing or batching emails behind the scenes or any multitude of things between them and GMail could be slow. I'm not quite sure.

Just leave that part out. For example:

class NotifierPreview < ActionMailer::Preview
  def welcome
    Notifier.welcome(User.first)
  end
end

Start a new thread to discuss those features? I like the idea of not just building features but also comparing it to how a production site uses them.

Yeah, it's the items in the row in order. I just used a Ruby trick to split the array of items into separate variables.

irb(main):001:0> a, b, c = ["a", "b", "c"]
=> ["a", "b", "c"]
irb(main):002:0> a
=> "a"
irb(main):003:0> b
=> "b"
irb(main):004:0> c
=> "c"

The main purpose is for making a website that has a lot of interaction where reloading the page would be intrusive. Look at Facebook and Twitter. If every action you took reloaded the page...it would be really hard to use them.

jQuery can get you pretty far, but it's going to be very disorganize because it isn't built for the same purpose. It's good for smaller things, but when you're building realtime chat like Facebook has, you're going to want something more robust like one of these frameworks.

In a lot of cases, you will be good just using jQuery, Turbolinks, and no full JS framework if you want just want your pages to render faster and to have some decent interactivity. Shopify went with this approach and they're doing really well with it.

Haha no worries! :) Feel free to ask questions on the forum too.

You can pass in the object into the mailer as an argument. Just set that to an instance variable and render it in your mailer view. If you're using Mandrill templates, you can pass the values over as merge variables instead.

If you want them to be editable, then storing them in a model makes sense. You can easily add and update them.

Otherwise if you really want them to be true constants, you could set a constant in Ruby in a Rails initializer file like so:

# config/initializers/countries.rb
COUNTRIES = [
  "United States",
  "Canada",
  #... etc
]

And then you could reference the COUNTRIES variables in your code in other places.

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?