Chris Oliver

Weird, rbenv should be in your path.

Edit post stuff should be fixed now gentlemen. 🍕

Yeah you can definitely do this route. So long as you can quickly update to the latest version if security bugs are fixed in a new version, that's the only real concern with using prebuilt binaries.

You could also just install rbenv on every machine and then copy in a precompiled binary for the version of Ruby you want yourself. You could compile it in a VM and then zip it up and just store it on S3 to download and extract on each of your production machines. That way you can always control the version of Ruby and get security releases out in just a few minutes where you might have to wait a long amount of time for some repository to get updated.

Hey Samuel, I haven't done this recently, but it's a fun one that I should definitely do a screencast on sometime.

Check out this post. He links to a couple other related posts that are worth reading and implements a SQL query to do ranking. You can probably do something similar to this: http://www.akitaonrails.com/2016/10/31/ruby-on-rails-implementation-of-a-proper-ranking-popularity-system

Hmmm, I can only think of the obvious places, .ruby-version and Gemfile to check, but I'm sure you've already done that. Did you get this figured out?

Mainly it's good convention to keep one class per file, and have the class inside the file named exactly the same.

Rails already does autoloads that path, it's just that it requires the class inside to match the folder+filename. So since it already does that, you might as well just follow the convention.

Exactly. And that's why I tend not to talk in buzzwords as best I can on GoRails. Most of what we do is really not that complicated, it just appears that way because we try to name every little detail. If you can get rid of all that, you can start really understanding things. And once you do, that's where the names come from, as succinct descriptions of things you commonly see. The trouble is trying to learn the names first without having seen the underlying patterns repeatedly in their raw, unnamed format.

For the sake of the example, the model is the easiest place to put it. To better organize the code I would probably move this code to its own class but since that's not the concept I want to focus on in this episode, I just placed the code in the model.

The class has to match the filename exactly. If you have app/models/reviews/create_review.rb you need to have a class Reviews::CreateReview defined in it. It must match the folder and filename for autoloading to work automatically. Folders equate to namespaces, and underscored filenames are converted to cased words.

No, you shouldn't need to.

I've had so many of these over the years, they were clear moments when I could tell I leveled up.

I think one of the big ones for me was realizing that Rails, Django, and all the other frameworks are simply text parsers. They parse HTTP requests, organize the request for you in regular old Ruby code and then you get to choose what to do based on that. It's so unbelievably simple, but yet hard to wrap your head around as you start. That was big for me.

It's a Javascript method, so it must be done in Javascript. You only need to call this if data changes during a request. If you're making a POST/PUT/DELETE not via Javascript, you wouldn't need this because your browser will not be loading the next page view JS.

Absolutely. It's the one I've used the most, even though it has plenty of warts. It's been on my list, just fairly low priority. I can make an episode on it pretty quick because I know it really well so I should be able to make it in some off time in the next week. :D

simple_calendar doesn't include any CSS for the links, so it must come from somewhere else. It only has some optional CSS for styling the calendar, but not links.

Sounds like you may have created a scaffold and the scaffold.css file is styling your links.

Nah, no reason to use gemsets anymore because Bundler does everything they do, but in a better fashion. Because your Gemfile is included inside your repository, you always know which gems and which versions to use for each app. That pretty much removes any need for gemsets these days.

Yeah, it sounds like you understand it correctly. If you install a gem like Rails multiple times, you can have multiple versions of it on your system. It will always try to use the latest version if you say "rails new", but you can also specify the version to an older one if you want to generate an older Rails app.

The list of installed gems on your system will show everything. However the gems in your app's Gemfile will only be the ones you're using (for example, Rails 5 and it's dependencies).

Bundle takes care of the discrepancy to lock the version numbers down to the ones that each version of Rails or each app has defined. It can look through all the gems you have and say okay you have 3 versions of this, I want version X. It does that so you don't have to worry about it.

I have Rails 3.2, 4.2, and 5.0 installed on my computer and run apps on various versions regularly with no issues because Bundler takes care of everything. 👍

Great to know, thanks for sharing that. I'm sure it will be useful to other people. 👍

Perfect. Yeah the groupdate gem is handy for that stuff. You can write it yourself, but it's pretty annoying to remember it all. Works super nice with Chartkick.

What do you have right now?

I forgot to mention this, but I just posted this episode yesterday!

https://gorails.com/episodes/recurring-events?autoplay=1