Chris Oliver

Another code smell of the real problem is that you're doing

if @invitation.nil?

Which means that you're not creating an Invitation correctly. If you were, you'd be checking if it was valid or not. So you're not running validations and you're not creating the object in memory. There's something else going on here.

Why does ActiveModel not automatically define this for you? The method is thrown on an instance of ActionController::Parameters which is what the params hash is, right? Are you sure you're instanciating the new model instance in the controller correctly?

You'll have to swap the MySQL instructions with Postgres ones. This tells Chef how to setup a MySQL server inside the Vagrant box, so you'll need to do the same for Postgres. I'm not sure of all the differences off the top of my head but a quick google search for postgres + chef should find you exactly whaty ou need.

Yeah, you may run into a few problems, but upgrading Homebrew and possibly a recompile or two and you won't have hardly any troubles. I updated my Macbook Air during the beta and didn't have hardly any trouble.

If you set this up remotely, you need to manually run the rails server in an SSH connection and then visit the server IP with the port of 3000. So http://SERVER_IP:3000

A better thing to follow for AWS is the deploy tutorial where your Rails apps are hosted on something remote like AWS or Digital Ocean. It uses Nginx & Passenger so that your Rails apps are always running.

I just updated the notes to include the link to the Github project but it's here too! https://github.com/excid3/g...

I did actually. I ended up deciding to leave out a few pieces because they were ending up making the episodes really long without a lot of useful/interesting things.

Instead, I decided to put everything up on the Github repo so it you can still review those parts! https://github.com/excid3/g...

I think aside from the suggestions mentioned in that thread, the topic of estimations is important to have a conversation on. Over time, I've learned that if I estimate X hours to complete a project with my gut feeling, the actual amount of time I will spend is between 2-3x what I feel like. Therefore, I always give the clients the estimate of 3x my initial gut feeling. It adds in some safe padding being at the high end in case I totally misinterpreted something plus it also gives me a good bit of freedom to impress the client if I'm actually on the lower end.

Your multipliers will vary and you'll have to make estimates and measure the actual results over many projects to feel out where you naturally judge. As time goes, you'll get better at this and you'll have attempted certain pieces of the project enough times to know almost exactly how long they'll take which reduces the overall fragility of your estimations.

Javid, check out my zsh theme here: https://github.com/excid3/dotfiles/blob/master/zsh/themes/excid3.zsh-theme#L27-L29

That's a good question. I think it downloads the primary image once and clones it for each project. You should be able to run "ls -la" to determine the directory size and see just how much it's taking up. I'd guess it's a couple GB for each project.

For personal projects, Vagrant isn't really necessary so I wouldn't really say you need it for that. Mostly just like team environments like you mentioned.

I'd guess there is a way of sharing the Vagrant VM, but I'm not sure off the top of my head.

The goal is really to use a separate Vagrant box for each project. The reason for that is that each time you can be sure you have everything separated out nicely and you can trust that you don't have some accidental dependencies you forgot about it or weren't aware of.

SSH does get pretty cumbersome when you've got a bunch of different keys. Here's some ideas on how to make it better: http://stackoverflow.com/qu...

Oh sweet. I remember seeing dom_id before but absolutely forgot about it!

That's what will happen if you missed the echo lines to write that code into your ~/.bashrc file. Without those lines, it won't load your ruby environment so they're important!

I think that's because on the index you want an array of records, but on show you just want a single record.

When you pass in the array into policy_scope, it's going to call the .where(company_id: X) method on it. This works when you return Item.all but when you pass in just an Item record, that does not have a where method because it's a single instance of the Item class.

In your show action, you can change it to:

def show
    @item = Item.find(params[:id])
    authorize @item
end

And this will load the record and Pundit will know to authorize it against the right method in the policy without hitting the Scope.

I'm using pygments.rb inside of Github's html-pipeline with a handful of other gems to improve the Markdown parsing:

gem "html-pipeline", "~> 1.9.0"
gem "rinku", "~> 1.7.3"
gem 'github-linguist', '~> 3.1.2'
gem "github-markdown", "~> 0.6.4"
gem 'pygments.rb', '~> 0.6.0'

Awesome find! Thanks for sharing this.

Updated. It got eaten in my markdown parser I believe. :)

This looks awesome. I'd love to see this stuff standardized and included in Rails core. Is the plan for this shipping with Rails 5?

Glad to help and thanks for the kind words. :-)