Chris Oliver

Haha! I don't think we would have done the acquisition if it wasn't to make things better.

Rails is definitely a tough nut to crack. It took me a long time to learn it and I was already familiar with building things in Python.

With some simple gems, you'll probably just need to upgrade the core Rails code and the rest of it should be pretty good to update just buy updating gems.

I can't remember where I grabbed that from exactly, but some documentation somewhere. If you want to host your own, check out https://github.com/HenrikJoreteg/emoji-images and you can serve up the pngs folder in your app. Of course, you'll want to put those in your public directory and not the asset pipeline so they stay the same filenames and don't get compiled.

Correct for most cases, but when you don't want to expose any deleted records, default_scope is perfect for this.

This definitely deserves a screencast. I should have recorded one when I upgraded One Month's site to 4.2.

My approach to this is to update your app and configs with the changes you get at http://railsdiff.com. Then I run bundle install, see what breaks (usually gems) and then start picking away at things. It's most likely that your code isn't the one that breaks, but gems will. Then it's often just going through each gem that stopped working, looking at their documentation and seeing if you're any major version numbers behind. Follow their upgrade process and one after another, you should get there slowly.

It took me 3 weeks or something (not fulltime) to upgrade our app from Rails 4.1 to 4.2 because of all the gem dependencies we have that needed changing.

On a side note, I think you can just use render text: "asdf" on Rails 4.x and earlier without having to use render plain: "asdf" plus you can pass in an option if you need to change the content type.

I think Carrierwave does and I use it for almost everything right now.

Not at the same exact time just yet, but that's on his todo list to add as a feature. https://github.com/elabs/re...

The main difference is usually the Free episodes are basic or common things people need to do and Pro episodes are more advanced or deeper looks into those things.

Great idea. I need to go update my markdown parser to add target: :blank into the links soon. I'll add that to my todo list. :)

So the problem with this (as you've already noticed) is that you can no longer assume that the slug references a Product anymore. It might be a product, or it might be a Technology, or it might be an Industry. My personal suggestion would be to use the routes like this instead:

/products
/products/:slug
/industries
/industries/:slug
/industries/:slug/products
/technologies
/technologies/:slug
/technologies/:slug/products

That would let you create nice restful routes for each of the industries and technologies plus the products inside them. The way to think about this is that you start with the most generic thing (Industry or Technology) and then you narrow down into Products inside them.

Now I know while that may be ideal, it might not be a practical solution, so here's how you can merge those into one controller like you are asking.

Normally you have a before_action that sets the product. In this case, you actually want the ones that don't match a product to render the index for a technology or industry. Your controller will first look up the product by name and if it doesn't find anything, you need to try your alternatives.

My solution would basically be this:

1. Try to find the product. Continue as normal if found.
2. If no product matches, look up a Technology or Industry.
3. Once we have a Technology or Industry, let's render a view for the products. This is going to look just like the regular products index at the simplest, but you may want to render different templates for Industry and Technology results instead.

class ProductsController < ApplicationController
  before_action :set_product
  before_action :find_products_if_not_found

  def index
    @products = Product.all
  end 

  def show
  end

  private

    def set_product
      @product = Product.friendly.find(params[:id])
    end

    def find_products_if_not_found
       # @product gets set in the before_action
       if @product.nil?
         @parent = Technology.friendly.find(params[:id]) || Industry.friendly.find(params[:id])
         @products = @parent.products

         # Render the index template if we found a parent for products
         # Since we are in the before_action this should halt rendering of the show action
         render action: :index
       end
     end
end

Basically everything comes in the same route and you start checking each type. If one fails, try the next. Continue doing that until you run out of things to match and then you can let the view fail if there are no matches at all.

Let me know if that helps!

Absolutely! Two of my favorites are RubyTapas (i'm on the homepage!) and Destroy All Software

That'll work. :) I've just exported as a plain CSV similarly because it's hard to tell the encoding of the file sometimes.

As for the Pundit issue, sounds like the variable you're using Pundit against is nil (which is why it looked up NilClassPolicy). Double check that variable is getting set correctly and that should fix it.

Yeah it's very picky. You can google it and lots of people have similar problems. http://stackoverflow.com/qu...

I will definitely record a screencast on this soon! Several people have been asking about it.

Also, check out this blog post that Patrick McKenzie just posted about his advanced CSV upload that he built: http://www.kalzumeus.com/20...

CSV upload is definitely a topic I need to cover soon. I usually don't save the CSV files so I traditionally just use a file_field and let the file get deleted after the request is done in most cases.

Refile could work for storage of the CSVs though and then the model could access the file and parse it as necessary if you want to store the CSVs permanently.

Definitely a worthy discussion to be had with the author of the gem.

I'm using patch because we want to modify the record. You don't ever want a GET request to update a record because that would be unsafe so either a PUT or a PATCH is best in this case.

Yep, shouldn't be a problem. You'll just skip the image processing parts.

Fixed!

Unfortunately you can't because it doesn't allow HTML inside of it.

You could remove the expires_in option and set up a nightly cron job to expire the fragments and then immediately request the page instead. When you do it with an expiration like this, you can't know when it expires exactly so it would be hard to expire and then request the page again.