Joël has been fighting autoloading in a Rails app recently, and it's been really unpleasant. Stephanie has been experimenting with how she interacts with Slack.
What are "the fundamentals"? People often argue for the value of Computer Science classes for the jobbing programmer because we need "the fundamentals." But what are they? And does CS really provide that for us?
This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack.
RailsConf talk on autoloading (https://www.youtube.com/watch?v=57AsQrxjLEs)
Joël's RubyConf Mini talk (https://www.youtube.com/watch?v=PHMOsTK1jSE)
Stephanie's RubyConf Mini talk (https://www.youtube.com/watch?v=S-ukCrsrTNw)
Fun, Friendly Computer Science by Mercedes Bernard (https://mercedesbernard.com/speaking/fun-friendly-cs)
Achieving Fast Method Metaprogramming: Lessons from MemoWise by Jemma Issroff and Jacob Evelyn (https://www.youtube.com/watch?v=c2Pa6W_O8oo)
Episode on specialized vocabulary (https://www.bikeshed.fm/356)
Episode on what to learn (https://www.bikeshed.fm/362)
Transcript:
AD:
thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.
We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.
STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn.
JOËL: And I'm Joël Quenneville. And together, we're here to share a bit of what we've learned along the way.
STEPHANIE: So, Joël, what's new in your world?
JOËL: I have been fighting autoloading in a Rails app recently, and it's been really unpleasant. This is an older Rails 4 application, so we don't have Zeitwerk, any of the fancy modern things. But the problem I'm encountering is that people write code that references a constant somewhere. And if that constant is not named in the conventional way so that it would load from the proper file, it will raise a NameError at runtime when you try to execute the code.
And then you want to reference that constant with a big asterisk there because if anybody else has happened to have loaded that constant correctly either by a manual require or some other method, then that constant will already be in scope, and so you don't get a NameError. So it causes a situation where you have a lot of non-deterministic failures in the code that are not easy to always reproduce either locally or even in the test suite.
STEPHANIE: That sounds really frustrating because you must be getting errors left and right that you weren't expecting and then have to deal with. I'm curious, though, because you use the word non-deterministic. But in some ways, I'm thinking that you could perhaps grep or search the codebase for places where we're requiring constants like that and perhaps even audit that. Has that been something you've thought about, or do you think that's possible at all?
JOËL: I don't think just grepping is going to be good enough because it's anytime you use a constant, and that's a class name, a module name. Things like that are probably the most common cases. If you're just referencing a constant like an array or a string, it's probably defined in the same file, so you're probably good. But if you're trying to include a module, or inherit from another class, or you want to instantiate another class somewhere, then you can run into issues if the class name or the namespacing for it doesn't line up with the file name so that when Rails tries to autoload it, it doesn't find it where it expects.
STEPHANIE: Got it. Okay, that makes more sense to me now.
JOËL: W