Chris Oliver

I actually haven't used JRuby much at all personally, but I'm really curious about how this works as well. JRuby is a really fantastic project especially when you need to integrate with existing Java libraries.

Analytics is a super good topic to cover. There's so much of it to take into account with all the tough questions of: Should I track this in the frontend or the backend? What should I call it? How should I save the metadata? How can we design this so it'll be valid data for a long time?

Also this is an awesome list of other production-ready topics. A lot of this is stuff I end up taking for granted, but absolutely needs to be in some screencasts.

Oh good question. Subtle thing here, but very important. The reason it's in the controller is because you're probably going to use the same logic to do authorization in the controller actions. You can easily expose the method as a helper using helper_method for the views, so this allows you to write it in one place and use it in both the controller and the views.

You'll have to make sure to modify your theme to use the image_tag or asset_url helpers in the views to point to the correct version of the image when it's compiled for production. There's also an asset-url helper for CSS that you'll want to use for any images referenced in the CSS.

Rails compiles these assets and the urls for them can change in production so you must use these helpers when you reference assets. That's the main modification needed to most themes.

You can do that, but you can also just use your normal text editor to create and edit the file. Macvim is just what I use.

Thanks for much for that Zachary! :)

Yep, I'm sure it can. You may have to build a custom handler for it based on their Subdomain one, but definitely could work. Check their docs / Github issues for more on it as I haven't done that before so I don't know the details of what you'll need.

Yeah, check your JS, verify the token gets submitted, something's definitely going on around that.

Are you sure that params[:stripeToken] is set to the value from the JS? Check your params?

I think the easiest way to do this is just to upgrade the Ruby version and see what happens. If they have tests, run the tests to see if they still pass. Other than that, you're probably good.

Yes! I'm getting a new camera tomorrow, so this will be something I cover first with that. :D

Definitely planning to! I think it helps explain things a lot better with the discussion.

It works everywhere. You might need to make sure you have Puma running on the correct IP (I think in this case you'd want 0.0.0.0) and that you're accessing the host with the correct port as well.

And here you go! :) https://gorails.com/episode...

You got it! :) So question for you: what are you trying to accomplish exactly with these queries? It might make sense to structure your data a little bit differently to make this more efficient. Your models sound like they're designed to separate everything, but your queries sound like you want don't actually want things separated.

For example, you're wanting to treat activities on notes and activities on comments the same, but your database is structured such that they're separate. It might make more sense to only have activities on the Note level and then include metadata for the related objects like Comment instead.

Multiple polymorphic associations can be tough because you can't do direct joins in SQL with polymorphic relationships since you're setting the table name in the column itself.

You'll have to make two separate queries along the lines of this:

@comment_ids = Comment.where(commentable_type: "Note", commentable_id: [1,2,3]).pluck(:id)
@activities = Activity.where(trackable_type: "Comment", trackable_id: @comment_ids)

That will first query for the comment IDs on those notes, then it will load up all the activities for those comments on the notes.

That's what making 100+ screencasts will do to you. ;)

I've been using Gravatars a lot lately so I haven't touched this in a while. Good refresher for me. :)

For avatars, I'm pretty sure resize_to_fill normally works best because it will resize the image to the proper dimensions and then crop from the center so that you get the best square images for it.

process :resize_to_fill => [400, 400]

This would always resize your image to fill a 400 by 400 space and then crop off the edges that are wider. In the case of landscape, it would adjust the height to 400 and then crop the sides out so the image is square. Portrait will do the same just cropping the top and bottom instead.

In general, API calls are pretty lightweight. They are significantly cheaper requests than regular page views because they don't require you to generate a full page, you only have to render some JSON which is easily generated from Rails. You'll notice most of these requests should complete in a smaller portion of the time that a full page request would take in your Rails logs. An example might be like 50ms to produce the JSON instead of 100ms to produce the full HTML page depending on how complicate your pages are. Of course, this all depends on the work you're doing server-side to make it happen. Some things can be slower like if you have to hit an external API.

There are many ways to optimize as well. For example, in an SPA, if you request a resource (like an Episode) you can pre-load the Likes inside of the JSON so the SPA can handle that all at once. Then when you click "Like" it can do the AJAX request just like I showed in the episode. If you take this approach, it's almost no different than what we did in that episode, except for the fact that the frontend is managed and rendered by the JS. That will make for a significantly slower first page load as it has to download a lot of Javascript the first time, but from there it mostly just needs to request JSON from the server after that.

One big issue with SPAs is that you have to still make these indexible by search engines, therefore requiring you to figure out a way of server-side rendering HTML still to have SEO for your site.

Now having explained all that, these approaches are significantly different. You've changed from producing HTML to JSON and moved a giant amount of logic from the server side to the frontend JS. This might be what you want, but Turbolinks is designed to be a middleground for these two approaches. You get the speed benefits of an SPA while keeping the same HTML the backend produces and writing minimal JS. The other giant benefit of this approach is that with the mobile adapters, you can operate with a smaller team all using the same Rails app HTML responses. The mobile devs get to focus on what they need to make a great experience native on mobile without having to rebuild the entire UI for mobile which is awesome.

Of course, SPAs make a lot of sense when you need to expose an external API for random people to consume. You can use the same API internally as what they would consume externally which is a strong reason for why you might want to go that approach over Turbolinks. Either way you can kill two birds with one stone, just depends on what your end goals are (and how much money you have to invest in a team to build it).

Clearly I should make a video on this asap. :-)

These are really good questions

1) Nope, bundler will do that for you. However, there will be a global default, so that's why you get the rake error and why you want to run bundle exec rake whatever instead of just rake whatever. Bundler handles this separation for you.

2) Not a thing. You can add a .ruby-version file to your repository if you want to set it to a specific version of Ruby which rbenv will detect and switch to. That's pretty handy if you're working on an old app that needs a specific version of Ruby.

1. Same as #2, the .ruby-version from the repository should do the trick for you, but possibly you will need to make sure you install the proper version of Ruby if you don't have it installed. Each version of Ruby lives entirely on its own, so you get entirely separate sets of gems between versions. You will notice, for example, that Bundler won't exist in your new installs of Ruby and will want to reinstall that.

2. If you want to start fresh, all you'll have to do is install Ruby and bundler and then run bundle install in your app directories. That is really all there is to it.