Save 36% for Black Friday! Learn more

Ask A Question

Notifications

You’re not receiving notifications from this thread.

Memoization Discussion

Discussion for Memoization

Great episode! I thought it was similar to Ryan Bate's old Memorization episode. Twitter method call was a great example, but I think it would be even beneficial for viewers if you have another episode where you show the best practices for storing those kind of external api calls in Redis or any other background gems.

Reply

thoughts on this? https://gist.github.com/blo...

Reply

I hadn't seen this before, quite an interesting approach. I like the intentions / goals a lot and a good discussion about it. There's a certain elegance to it that feels very clean.

That said, I'm not sure memoization is really necessary for any of this. It might be useful in post_params, but it's one of those cases like name where it's ultra fast to run and only usually gets access once, so unlikely to provide any speed benefits to memoize.

For example, you can just use before_actions to accomplish the same result: https://gist.github.com/exc...

The benefit of instance variables is that it provides you a way at a glance to determine which variables you have access to in your views, plus they're automatically available as well without having to expose helper_methods.

And like the discussion mentioned, for the index methods they tend to have scopes applied often, so I usually find them useful to always be written in the method so you can easily find it, rather than having to look at helper methods or before_actions for that. It makes more sense for member actions where you've always got to set @post for example and it's kind of assumed that it'll always be the same.

What do you think?

Reply

Thanks for another great episode Chris! I love this kind of "little tips and tricks" type stuff. Would love to see more caching and performance related episodes. Thanks for making these screencasts :)

Reply

Thanks for your support Ken! :D

Reply
Daniel Cruz Daniel Cruz

Please be careful with booleans. Your code only memoizes `true` values. If the result is `false` it will recalculate.
Instead, with booleans you'd better go with something like:
```ruby
def valid?
return @valid if defined? @valid
@valid = expensive_boolean_calculation?
end
```

Reply

Yes, great point! Thanks for mentioning that.

Reply

Since Twitter was brought up in this video I figured it would be a good place to check in and see if anyone knows of a solid resource or code base for testing against 3rd Party APIs. My specific situation is using the Twitter gem and trying to figure out what to actually test against and how to implement this in Minitest --preferably without mocks or relying upon gems. Any links would be appreciated.

Reply

Is there a way to check the size of cache, and is there a way to clear the cache if needed? thks!

Reply

The cache only works over a single request so it will be cleared automatically if user make another request

Reply

I don't remember if you mention when will the cache result expired and assign new value into it. So that's my question, when will the cache kind of expired? Is it only available over **a single request**?

updated :
From comment discussion here http://www.justinweiss.com/... and here http://railscasts.com/episo... it can be inferred that yes it's only available on a single request

Reply
Join the discussion
Create an account Log in

Want to stay up-to-date with Ruby on Rails?

Join 86,946+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.