Remote Ruby
Three Rubyists having conversations and interviewing others about Ruby and web development.
Remote Ruby
Ridges on the Scroll Wheel
In today’s episode, Chris and Andrew tackle the eternal quandary of good versus evil
right out of the gate. Then they dive into the heart of tech talk with Andrew sharing his
candid challenges with React, to the struggle of getting code from the mind onto the
screen. They touch on the evolution of programming, reminiscing about the days of
DOS and games stored on floppy disks and reflecting on how ‘everything’ has been
critically designed by someone. They also share interesting insights about upgrades to
Rails and debugging, the efficiency of GitHub Copilot with JavaScript, the convolution of
JavaScript compared to Ruby, and the art of minimizing interruptions during coding flow.
There’s also a reflection on public speaking at conferences and the art of balancing
content and entertainment in presentations.
Honeybadger is an application health monitoring tool built by developers for developers.
Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.
This is remote, have you any remote ideas to the meaning of the word.
Speaker 1:Yo, yo, yo yo. What's good, what is good, what is good, what is?
Speaker 2:good and what is evil.
Speaker 1:Let's start off the podcast with these easy questions.
Speaker 2:Did I ever tell you I had a friend that made Evil LLC as his company name?
Speaker 1:That's kind of badass.
Speaker 2:He was like a leader of the Canadian pirate party and into a lot of those fun things as well, so it was particularly fitting for him. I was always jealous of that.
Speaker 1:That's cool. As a Wikipedia user, I do know deeply about what the pirate party's been up to. Yes. Oh man, what's new with you this week? Dude, I am writing, react, I am what Shipping stuff? And dude, I am burnt out.
Speaker 2:Are you capable of shipping things with React, or is it just a? I felt it was just so hard to like so much extra work that I wouldn't get to shipping things with it.
Speaker 1:I have been trying to work on my attitude about React, so I'm not going to tell you how I really feel.
Speaker 2:That's for the remote React, I agree.
Speaker 1:It's just a whole lot of ceremony and yeah, that's a good way of putting it we have to make this trade off, because we have to write this thing in React, because this other thing is React. It's like, come on, we're just shooting ourselves for no reason. Why don't we just slap a little more rails on the page?
Speaker 2:Definitely can still see some of the value in it where it's like you're building some complex. You're building Figma or something crazy, I'm sure.
Speaker 1:Yeah, that would be hard, but if it's something that justifies it.
Speaker 2:Okay, yeah, uh-huh.
Speaker 1:There's a very good reason why I'm doing this specific thing, in case anyone for work is listening to this. But no complaints, please don't tell anyone. I agree, I agree, but it has got to write this JavaScript code and I'm not the greatest JavaScript developer. I have fully admitted to that over the years. But I will say Co-Pilot has really helped out.
Speaker 1:Because I don't use Co-Pilot to write my rails code for the most part my rails specs. That's a different story. But for writing JavaScript dude, I just tell it what I want and I'm figured out and then I get whatever the rest I need in code review and we're good to go dude.
Speaker 2:It can feel very convoluted if you're coming from Ruby, like some of the weird things, where it's well, we wrap this function in a promise and then return the promise and whatever else, and you're like, okay, I just want to call this function and do something when it's done and I don't want to pass a call back.
Speaker 1:Yeah so yeah. We're like passing functions into functions that like send functions back or something, and I'm like yeah, I don't know, I don't know, what this means, but yeah.
Speaker 2:I feel like that stuff is the part that makes it hard for me to context switch, sometimes when I'm jumping between the two.
Speaker 2:If it's like a standard stimulus controller or whatever, I don't have any trouble jumping back and forth. But when it gets into a little bit more of the weeds of JavaScript nuances like that, then yeah, slows me down quite a bit because I'm like I'm going to stop and process this. And that's to me the biggest struggle, which is why, like I learned BIM and I try not to use the mouse a lot Like getting ideas out of my head into the computer with as few interruptions as possible so I don't lose my train of thought. And all of that has always been my goal because I'm like I know where I'm headed and I can think at a certain speed. But getting that into the computer is often slowed down quite a bit.
Speaker 1:I'm glad you said that, because I said something very close to that the other day and Jason and everyone else on the call looked at me like I was crazy. Because I was like I feel like it right now my biggest problem in life now my biggest one what feels like my biggest problem in life is that I have code in my head that I need to get into the code editor and I'm hampered by my ability to do that. I can't get it in fast enough and I was like does anyone else have that problem? Like I feel like I can't navigate fast enough, I feel like I can't get this code in fast enough. I feel like I can't replace fast enough, and everyone's like what are you talking about?
Speaker 2:I can 100% relate to that, because as you're thinking through a problem, you start thinking about the edge cases and like this and that If you were hindered by something and it's not going to go fix this problem and I forgot about the edge case that I was thinking about earlier, then you got to stop and like, redo all that thinking and try and get back to where you were, and sometimes I won't remember for five days. And then I'm like, oh my God, I remember now I got to go fix this and whatever, because it just hasn't come up yet or whatever. And that is to me one of the biggest struggles of roughly know what I'm trying to do. But how do I extract it from my brain? And maybe we just need Elon Musk's neural link and we just have the chip in our brains or whatever.
Speaker 1:I've been dreaming about. I had a dream for the neural link before. It was a thing I have to think about this my whole life Like. As soon as I can put a chip in my brain, I'm doing it and get rid of this crap, Dude.
Speaker 2:I got a raspberry pie we can put in there.
Speaker 1:Dude, I'm going to take the first flight, but do a garage surgery.
Speaker 2:Oh man, I feel like it's been one of the things that drove me the most nuts pair programming back in the day, and I'm a lot more patient now. But man, I would watch my pair write a little code, move his hands over to his mouse, scroll around a little bit, highlight some texts and like make a tiny change, and I'm like Jesus Christ, what is taking so long? Like I was losing my mind sometimes trying to pair, and those were things where I was like all right, I'm not going to use my mouse, I'm going to like get really good with keyboard shortcuts, memorize at least the minimum that I need to operate efficiently. And then that was one thing that led me into like all right, I've seen Ben Orrinstein, code Dude's a mad man and Vim.
Speaker 2:I guess I better learn Vim because this helps me accomplish that goal, because clearly he has mastered that and even if I'm 10% of what he is my best, then still probably worth it, still probably way faster otherwise. So yeah, I don't know, that's my personal thing, Maybe not everybody's like that, but I have had that experience pairing.
Speaker 1:It drives me insane too and it's like a personal problem, like I know that, right, but here with people in the past where I'm just like it is excruciating. I know it's a personal problem, right, I know this is something he think. I don't ever say anything, but it's like holy crap, you could do so much more if you could just use command P to open the like. I don't know, dude, it drives me insane. I think I'm at a little bit above basic level with Vim motions now. I use Vim motions everywhere. Now I've got that part down, I would and do want to switch to NeoVim. I just know that there's a cost, right, there's a big cost to like switching your editor like that, and I know with a really configurable system like NeoVim that's a trap for me.
Speaker 1:So I haven't switched especially because I'm in the middle of a big project right now, but I'm slowly. But instead of jumping full in, I've just been kind of like moving that way, like at minimum just being good at navigating with editing a file.
Speaker 2:Yeah, and that's one of the things too. It's like you can skip, delay that until later If you're in VS code or text me or whatever the hell it is, start memorizing those instead of clicking on the menu and going and find and replace. Next time you do it, look at the keyboard shortcut for find and replace and start memorizing those things. And the reason like I use Mac Vim for everything still was think sublime editor was like the big thing when I was like getting into more rail stuff and I had memorized a lot of their keyboard shortcuts. And then when I knew I wanted to transition to Vim is the same issue is like now it's even harder to get thoughts out of my head because I got to like think about Vim commands now.
Speaker 2:So I use a bundle of configuration stuff called Janice I think it was a GitHub or somebody that started that project or whatever but in Mac Vim you get a lot of the like same keyboard shortcuts you're used to, so you can command S to save instead of escape, colon W to save and whatever. So I was able to bridge Vim and my sublime knowledge kind of together, and I was definitely slower for three or four weeks, but after that I was considerably faster and noticed Wow, I am much better editing code and whatever. But you know, I don't think you have to use Vim. You can just get really good at VS code, shortcuts and stuff.
Speaker 1:You probably spend the most time in your text editor. Whether the text editor is shell, like a terminal, or VS code or ID, whatever it is, I feel like you should be a master of your tools, like, no matter the profession you don't want to carpenter, come into your house and like swing in his hammer all over the place Like some sort of jackass. You know, I feel the same way about developers. We should be masters of our tools. These are our hammers.
Speaker 2:Yeah, I totally agree. It's also one of the things where I like I bought a stream deck to have programmable shortcuts and buttons and stuff on there, and it's another one of those things you can use or there's countless other Write scripts as well to do common things. Whatever it is. Pay attention to those things that you're doing manually and slowly. And if it's oh, I've got postgres 14 and I need to upgrade to 16, I Search for that blog post and I copy the commands in one by one every time. Well, like next time around, why don't you write a script and you just input 14 and 16 as your arguments and then have it do the rest for you? It's totally doable and Would be like a lifesaver for you and then you could publish that as your open source project. There are all kinds of little things that I feel like. I love seeing other people's workflows and stuff and giving me ideas and like, oh man, I could change this or that and Program something for making my life faster or easier.
Speaker 1:Yeah, that's the way to start, though, for me. I started creating my own SOPs Because, like, in order to like script like a workflow, you have to know what that workflow is. I feel like I have a problem where, like, I'm like oh, I have this workflow, but I don't really think it through and so, therefore, I don't continue using it. Like I make it, it's fun to make it and enjoy the scripting, and then I don't ever use it again, so I started making, like, my own SOPs and then converting those into scripts. Okay, so these are the steps I do. Now I can just run this script so whatever I'm like oh how do I publish an episode of Ruby for all?
Speaker 1:I can just go search that up and then maybe I have scripts to do some Things and maybe I don't, but I feel like that's a good place to start. It helps you like, also think algorithmically right.
Speaker 2:Yeah, you're starting to like notice patterns and figure out what the variables in those patterns are and Pull them out. That was like the funny thing when I was learning when I was really Truly learning programming in high school. I thought I was gonna be a genius and cheat on its math homework or test or whatever. But what I really came to realize was like they give us a worksheet of problems to solve and Literally the only thing that changes from problem problem is the numbers and they're just very slightly different and those are variables. Then I just need to ask you to input these three variables and I can do the rest of it in a tiny little function and like to do my math homework. We had to show the work, so the teacher knew that you knew how to do it and I was like, oh, I'll just make each one of those a function or something that prints out what the problem is, and the last one will actually spit out the value or whatever. And that was like a really good experience for me to realize oh, you know this, the programming stuff.
Speaker 2:It first felt like all I can do is build calculators and really it's helping me learn how to think through problems more than anything, because that's really what you do as a programmer every day. You're just like how do I break this problem down from? Here's what I got, here's where I need to be, how do I get in between? And that's all you really do every day. But it feels a lot more complex when you're in the weeds. But that's the thing. If you can figure out what is my procedure for this type of problem, then that's a solved thing permanently for you. That's like extracting out a library that you can just reach for every single time.
Speaker 2:You need crazy countercaches, like I use counterculture, whatever, and boom all those cool things are done for me and I don't have to worry about the weeds on that level anymore. I can think about stuff at a higher level, which is awesome.
Speaker 1:My only problem is that, because of my ADHD, I have this problem where you can describe your problem to me and I'm like, all right, I got this idea and then I can see the solution. I don't see any part in between, but my brain bridges the gap somehow. So, like sometimes I'm really bad to pair with because I'm just sitting there staring at the screen and then I just start writing the solution. The person's like wait, wait, wait, wait. How did you just go from A to B? And I'm like I don't know. I just know that this is the answer and that this code is gonna work and it does.
Speaker 1:And I'm like, I don't know, I got you, yeah your work on math was also BS for me, because I'm like I just know that the answer is this.
Speaker 2:I'm like yeah, it's like the conceptual compression, like you've Intuited how these problems work, and doing the actual individual steps you don't need to do anymore. It's the same thing kind of is like memorizing your multiplication tables. I don't need to do the multiplication manually for these sets of problems because I've memorized how to get there. I can just skip straight to the answer, which is awesome and something that you want to cultivate. That because then you were more efficient and better at what you do, because you could just like skip over all that where you might have had to spend An hour in the weeds doing it from scratch, or something. That's great, that's the experience you've Gained, or whatever said that's awesome.
Speaker 1:It is helpful for me, but it's not helpful for you if you're on the call with which is something I've received feedback about and I'm trying to work on where I'm like Sometimes like someone will join, like a pairing call, and I'm like in it and like when I'm in it, I'm like in it so like I don't see anything else, like a fire could be going on outside. I wouldn't even know, and so I'm just like, yeah, so I think this is what we need to do, and I start talking and you're like Dude, you're in the middle and I need you to start at the beginning, but my brain doesn't work like that. I mean, they're in the fog or out of the fog. There's no.
Speaker 2:This is this is hilarious because this is pretty much how conversations often go with me and Brooke, my wife. She will do exactly the same thing, just kind of like have had this whole thing going on in her head. Then she asked me something. I'm like what the heck are you?
Speaker 1:talking about, or how did you?
Speaker 2:get to that. It is funny because we will sometimes get in arguments because she will just have made a decision on something and it's like boom, ready to go, and I'm like wait a minute, I need to think through the steps on how to get to that decision, because I also want to like Evaluate the other options.
Speaker 1:And she's like no, we don't need to do that. We need to go. Yeah, yeah, I can't. When I first met Brooke, I was like this is a kindred soul. I get what you just said, under some like why would you need to have Chris we talking about what are there? There's already a solution, dude. Why do you care about the other options? It was so funny.
Speaker 2:That is one of the things that we will Occasionally butt heads on it because it'll be like why can't I need to process this? And she's like nah, we're already way past that.
Speaker 1:Yeah, I'm like hold on a second Get on the train, dude.
Speaker 2:Yeah.
Speaker 1:I get that completely. That's hilarious. But that is what it's like to pair burger with me, like so much, like I've already made a decision and I'm already know what direction I'm going, and you're like, yeah, what's going on here? You've made that decision in your head and like a snap of a finger and like, yeah, something else a second ago.
Speaker 2:Oh, you reminded me too. This was the reason why. So when I started go rails, I wanted to do screencasts explaining how, basically, without edits, right. So like I wanted to build a feature, and then when something blows up, we just include that and I show you how to debug it, because that's what I really wanted to teach. Yeah, it's very, very hard to teach that. So I remember this so vividly First time it happens. And recording a screencast and I'm like big red-error screen, oh shit, something's wrong. And I stop, I'm like, oh yeah, and just fix it.
Speaker 2:And then I was like this is gonna make the worst, like yeah, I was like this is gonna be the worst screencast, because in a hundred milliseconds or less my brain just went back through the last three years of programming and I remember seeing this problem four projects ago, whatever time that was, and I remember it took me like eight hours and then I found this blog post and then I Modified it slightly and then was able to solve the problem and then that's how we fixed it. In these Hundred milliseconds of me just staring blankly at the screen, it was like I could never stop and explain what just happened right there, because it was just almost an innate thing that I cannot control. But I also cannot explain what just happened because, to you, the answer just magically appeared in my brain. I would love to explain that I've seen this before and Whatever, but it's not really a great sort of learning experience then, so pretty much just gave up on that and I was like this is probably more distracting than anything. And lately I've been able to do more of that where I'm like, all right, let's just break it down.
Speaker 2:We have this error. Let me Google the error. Let me look for this answer. Why does this answer make more sense than these other answers? Yeah, and try to explain it that way, even though I probably knew the answer ahead of time. But I tried to slow myself down and show you the flow of how I evaluate, debug things or whatever. But yeah, so vividly remember that now that you were Explaining that, because I remember being like there's no way to. Yeah, I just fixed it and I can never explain this to anyone because, like, they're not like now.
Speaker 2:There's an answer totally Just want to take a second to thank our sponsor, honey badger. Monitoring, like web development, can be complicated. There are tons of tools and techniques, but you just want to know that your app is up and your customers are happy. You, when your customers encounter a problem, you need clear, actionable intelligence, not walls of charts and reams of logs to tail. That's why they built honey badger, the monitoring tool.
Speaker 2:We've always wanted a tool that's there when you need it and gets out of your way when you don't, so you can keep shipping, know when critical errors occur in which customers are affected, respond instantly when your systems go down, improve the health of your systems over time and fix problems before your customers can report them. I know from personal Experience. I've fixed bugs when they've shown up in honey badger and then emailed the customer to let them know. Hey, I think I saw you get a 500 error, I fixed it and I just wanted to let you know you can try again. And Blows those customers minds to see that they didn't even have a chance to report the bug to you. It's wild. They love it. Honey badger is the application health monitoring tool built for you, the developer who cares about a quality product and happy customers. Start monitoring today at honey badgerio. It's free for small teams and setup takes as little as five minutes.
Speaker 1:Once again, that's honey badgerio we launched a new feature at Podia and someone was like well, is this thing supposed to look this way? And my project partner was like how are we possibly gonna debug this? And I was like we can render the Rails controller response from the Rails command line and just you know, got into the production and ran the thing and I was like I know where.
Speaker 1:I saw this. I knew exactly where to go to like find the code, to like do it. At the end of that I looked at my project. I was like are you surprised that I was able to do that that quickly? She's like, yeah, usually you're like I think something's over here at you can't find it. Yeah, and I can't go find it, but this time I was pattern, pattern, pattern. I was like I know exactly how to get from A to B here.
Speaker 2:It's just experience that really makes you good at it. And I don't know when people ask me like you're so good at Rails, how do you know all the stuff? And it's well. You realize that I've been doing this every single day for the last 12 years or whatever, and that's just Ruby and Rails Cause I started Rails in 2011,.
Speaker 1:so I guess yeah, it's been about that long. It's nuts.
Speaker 2:I've been programming even further since grade school. So, oh, speaking of, my parents came down and brought me this book that listeners will not be able to see, but this is the Atari basic for an Atari 400 and 800 book that I learned to code on and it's nuts. You had to write your own line numbers and all this stuff. I mean it was crazy, like all these diagrams and whatever else.
Speaker 1:Logical math.
Speaker 2:Yeah, it was like 10, let F equal one, 20, print quotes, f equals quotes, semi-colon, f, colon, let F equals F plus one, and then just the really basic loops and very basic programming stuff. But I remember going through like the entire book and doing all the projects and like the last one was sort of a calculator where you could choose what operations you wanted to do and it would just do them and I was like programming stuff sucks. The only thing you can do with it is math. But somehow these wizards over here made Super Mario Brothers and there's like a character and you can move and there's gravity and whatever else.
Speaker 2:And I just spent all summer reading this damn book and all I can build is a calculator and like that's programming. It's like just numbers. And then you look at what we do in Rails and it's like we don't do much really with numbers, we do a lot more with strings and it's like effectively the same kind of stuff. But I couldn't piece it together back then that it was like you can like abstract these things and whatever. But man, it's cool to have that book. I wish I still had our old computer, canon, a Nova book 10C, I think it was Windows 3.1, tiniest little screen.
Speaker 1:What is Windows 3.1?
Speaker 2:Dude when I-.
Speaker 1:Is that before 2000? Yeah, oh, there's a Windows before Windows 2000.
Speaker 2:Well, there was Windows 95, Windows 98. There was Windows 1, 2, and 3.1.
Speaker 1:I was thinking about Windows 98. Yeah.
Speaker 2:Windows millennium edition kind of kid?
Speaker 1:No, I was. I grew up on XP. Good Millennium edition was a level. That's what I remember. Xp for the most part.
Speaker 2:Yeah, I remember getting Visual Basic 1.0 or something, because I had a couple computers before that little Canon laptop. One was a Magnavox computer that had this. It was pretty much just DOS. We had like a Disney train game and little railroad simulator and other stuff on there, whatever. But it was like all just DOS. And I found that it had GW Basic on there, which is close enough to the Satori Basic and that's how I got into it, but there was no functions. You had to use go-tos and line numbers. But that's why when I found the laptop had QBasic that had functions and no line numbers. So life was like a million times easier than-.
Speaker 1:What is DOS for the people my age?
Speaker 2:Yeah, just basically. Just your terminal is all. You have. No mouse, no interface, nothing.
Speaker 1:So I had a big book about DOS that was in our house that he said that he had gotten years before and that's all I know about DOS.
Speaker 2:Yeah, that's all you need to know about DOS. I hope you never have to experience that it was-.
Speaker 1:That's my neighbors in college.
Speaker 2:Well, there you go. Different kind, but we can hit them with DOS. So there's a web framework that you could use if you would ever want to go down the rabbit hole called DOS on Dope, which is a DOS on Dope.
Speaker 1:Hell yeah.
Speaker 2:It's a web framework written in batch scripts or whatever from DOS Dope. I think the DOS version that we had on the one computer the oldest one didn't even had because there was DOS, and then there was like DOS with networking and I'm pretty sure the one computer we had no networking at all so you couldn't even interact with another computer, so you probably couldn't even run DOS on.
Speaker 1:Dope. So is it even a computer if it can't talk to other computers? I?
Speaker 2:mean it played video games, so as a kid, I didn't care, that's true.
Speaker 2:It was playing Duke Nukem. We would go to the bookstore and they would have a big old bin full of five and a quarter inch floppies and they were all like a dollar because it was like a demo of a game, not the full game, and my parents would be like you can get three of them? And I was like, yes, you had baseball. You got to choose from all these and all you see is the label with the word baseball on it, and definitely grab some that were not good at all, but it's funny how fast technology changes.
Speaker 1:Cause like, okay, we joke, but you're not that much older than me and I have never in my life seen a game on a floppy disk. I remember floppy disks Like I've obviously seen them, like our computer had a floppy disk reader. My parents have floppy disks. I'm pretty sure they just kept photos on them, If that's even a thing but I've never seen a video game on a floppy disk.
Speaker 2:Dude, my mom doesn't have it anymore. She had bought one of the digital cameras that saved images on floppy disks. The thing was a beast. It was so heavy.
Speaker 1:Nice.
Speaker 2:But those were the days where you, like, had a floppy that could hold like 15 images on it or something, not 15.
Speaker 1:Damn dude, chill out.
Speaker 2:That was the thing that like these were a lot of computers. Like my parents had a computer running XP and one with millennium edition, but these were like computers that my dad had back in like the 80s or whatever and they were just still there. Cause that Magnavox computer was like 1500 bucks and he told my mom, the last computer we'll ever need to buy. So like, let's invest in this one Age right, maybe it was a bit wrong on that one.
Speaker 1:See, that's not a fortune teller.
Speaker 2:But he used to be like really good with computers back in like the DOS days and stuff like writing scripts and all this, which was kind of where I remember like he was taking apart our Packard Bell computer that ran Windows 3.1 and putting in a modem in it and I was just like fascinated, cause I'm in like fifth, sixth grade or something like that. What is this? This is amazing. A lot of it was just older hardware we had sitting around that nobody was using but it was like, yeah, well, you can't get into trouble on this, so go have fun, you can't break it, so whatever. That was kind of a good times for me to learn on and settle with. And whatever we had flight simulator 1.0 or something on there we had flight simulator.
Speaker 1:I remember playing this. Yeah, that's like the first game I ever remember playing.
Speaker 2:Yeah, I remember simulator whatever, 1.0 or something. Yep, this is it. Oh my God, it looks terrible. There was like maybe one or two buildings in the game, because the rest of it was struggling to render just the ground, and I remember just consistently like I'm going to crash into that building. Yes, just because like what else am I going to do in this game?
Speaker 1:Yes, because it would kind of explode if you hit something.
Speaker 2:I think there was something where it was like you'd see a face or something in the window. I don't remember, but yeah, man, I have some crazy old stuff. I can't. Maybe it was 3.0. Flight simulator 3.0 looks pretty. Yeah, because it had the Learjet. I remember that and the Sop with Camel. Yes, oh, man Brings me back.
Speaker 1:Yeah, You'd space pinball. That's my jam.
Speaker 2:There's another one where I don't know if my parents or some family member gave us like all these CD-ROMs of demos of games and there was like this Android pinball game and if you played long enough you could turn the Android alive or something. And I just remember playing incessantly, never even remotely getting close. But one time I did and I was like this is incredible, and I go upstairs and come back down and the games like rebooted or something. I was like God.
Speaker 1:I remember like games that you would try to load in your computer and your computers be like no, I just crash. Yeah.
Speaker 2:I actually had that yesterday. I was doing a virtual machine for the upcoming Ubuntu release and they don't have any server additions built right now. So they had the desktop version and it was like very slow and I'd given it two gigs of RAM and I was like that's surely enough? Barely not, because I would get to the installer and it would start doing stuff and then it would just freeze. So I was like I'll give it three gigs of RAM or four gigs and see what happens, and everything was perfectly fine that time around.
Speaker 2:I've been having fun with that. Just, there's like command line script called multi paths that you can run Ubuntu servers locally and that's perfect for testing hatchbox. But it doesn't do the upcoming version yet and it doesn't do any of the in between versions. So I have to run my actual VMs through virtual box or something like it to use those other versions. That's what I was fiddling with yesterday. But, dude, something earlier we were talking about reminded me late last night. I was debugging and I've done this in the last two months.
Speaker 2:I know I ran into this problem before as well, but I couldn't pinpoint it last night because it wasn't giving me the same message. But there is a bug in Rails that if you spin up a new Rails app, the test environment will use the async adapter by default, unless you include the active job test helper, which will force it to use the test Q adapter. As it turns out, the async adapter just gets in a deadlock at some point and hangs. So I was like in the Postgres database statements code in the adapter trying to like debug what is the SQL query that's like causing this to hang or whatever, and it ended up like back in the Rails async Q adapter open issue that's been open for quite a while at this point. But your test suite will like be running. If you have it running in parallel. It will basically lock up your database and then your test just gets stuck. And this has been fine for a long time. But then in the last month our CI has gotten stuck a few times and then the timeout is six hours by default. So then I spent all of our budget on CI on this being hung for six hours multiple times and I was like this is going to be a pain to fix and figure out what's going on. And sure enough it was that async adapter where it's like surprise that the test environment just doesn't set the Q adapter to test by default.
Speaker 2:Yeah, it was another one of those moments where, as soon as I saw it, I was like, oh yeah, I've already seen this before, six months ago or whatever it was, and it was because of this, in this situation, and then we changed this and whatever. And then, all of a sudden, the answer started appearing 50 milliseconds later, because all these past memories come to light and you're like, oh, I've seen this before. I know what the answer is, I know what's wrong. I don't remember any of the details, but this is what you do to fix it. That's what you reminded me of earlier, because it was another one of those moments.
Speaker 1:If you're one of our listeners who doesn't have, like, a voice in their head and is a programmer, please reach out to us. Because I'm so interested, because, while you're thinking about that, I've been on this tear recently learning about people who don't have a voice in their head like 50% of the population, by the way and I'm thinking like how could you possibly grab without a voice in your head, like as you're saying, yeah, who do you talk to? It is speak out loud if they're like I'm hungry days, I'm hungry.
Speaker 2:Me hungry. I don't understand yeah.
Speaker 1:I'm trying to learn. I'm learning about it. I don't understand it. It's scary to me a little bit. I don't feel like this is something I should be afraid of, but it is scary to me.
Speaker 2:That's funny. Going back to like the early days, I feel like there was some eye opening moment where I was looking at a lot of stuff, just the shape of your phone or a computer mouse or literally anything. As I got into programming I was like I can see that someone had to design the scroll wheel on the mouse and they put these little notches in there. It's not on accident that there's little notches and the wheel is this size. For some reason they like decided that was the best size, but I'm sure they tested a bigger wheel, a smaller wheel. I remember just having that moment of I've never once in my life cared about any of the stuff and then all of a sudden, when you start building things, you're like, oh my God, literally everything that I ever interact with was designed by somebody and they put a lot of thought into it. And it may not be a good result at the end of the day, but like someone worked hard on that.
Speaker 2:Every bit of my life since then was like changed, because I couldn't look at stuff and just feel it anymore, because I had kind of be like oh interesting, this is how it was designed, this is how it works and whatever someone put thought into this. But I remember just being like before you could feel something was wrong with it. You're like this is just annoying, I don't like it. But I couldn't verbalize anything more than that. And now I could look at it and be like, well, this scroll wheel is too small or it's too smooth, too slick, something like that. And now I can like understand things a lot better and like articulate what's what I like and what I don't like. But yeah, that reminded me of that. That was a weird moment, because I remember being in school and I was like it's like putting on glasses for the first time, when you don't realize that you need glasses.
Speaker 1:It felt crazy Dude that just reminded me of that meme that he's thinking about other girls and it's like, oh it's weird, the grooves on like a mouse wheel, like someone put time into that Exactly. That's hilarious.
Speaker 2:That is very accurate.
Speaker 1:You're right, though there's a reason that's so funny.
Speaker 2:I love it. Before we started recording, I was going to ask you if you were planning on doing any conference talks this year, or what conferences you're planning on going to, because I just pulled up the rubyconferencesorg site. This is going to be a good year. I think there's two in February, one in March, four in April, one, two, three, four, five in May, three in June, one in August, three in September, one in October and one in November.
Speaker 1:so far, that is a lot of conferences. That is a lot of conferences. Excited yeah, none, I'm not doing CFPs this year. Yeah, I can't do it.
Speaker 2:I think I'm going to try, but I'm also trying and I will need your help. You need to nudge Colin to submit, yeah, and anybody else who you know that has talked about submitting but has never done it before or has and hasn't been accepted yet. Take that extra moment and go nudge them and encourage them to do it, because a bunch of these close in a week or a month from now. So it is like very good time to be submitting CFPs or practicing, because maybe you want to do one at a conference later in the year. You can still submit to one today and if you don't get accepted, that's totally fine. You can refine it and hopefully get some feedback on it and stuff. But yeah, it just feels like now is a really hot time because there's a lot of CFPs that are closing very soon, very, very soon.
Speaker 1:Yeah, there are a lot of conferences going on this year. I feel like this is the first year. It's like, okay, I feel like we're back finally, seriously Since 2020, I feel like finally, life is kind of resuming almost back to normal completely. I'm happy all these conferences are coming up.
Speaker 2:There was a lot in 2023. Looking at the West there was a ton, I went to a lot in 2023. Yeah, yeah, well, not as many as Marco.
Speaker 1:No, not as many as Marco. Marco championed it out.
Speaker 2:Seriously, he was all over the place.
Speaker 1:I've met up with him in Phoenix. I think that was last year, maybe it was a year before, I don't know. Time kind of is a concept or something.
Speaker 2:At this point. Now I'm excited, I've got some ideas, but it's also like a weird thing If you go give a talk and you submit a talk for a bunch of these. If you're going to go to a lot of these, like you're going to go to RailsConf and Blue Ridge, Ruby and whatever else I would love to give a different talk at every one of them, but I don't think that's yeah.
Speaker 1:No, I was literally thinking about this like before. I was like, with that many conferences, I know there's so many people out there who could give talks, but it's like I hope it's not just the same people. Like traveling from Conv, like not that some of the familiar faces aren't great, but it's like, come on, let's get new people in. I don't want to see the same person. Yeah, I think it would be great to see, like if you were going and speaking in mobile commerce to see a different talk at the same time, as your homie can't allow you to do that. Yeah.
Speaker 2:Because, like for anybody who hasn't I mean a lot of people I talk to is like between 40 and 80 hours invested into one talk, and that's sometimes minimum.
Speaker 2:A lot of people will spend more time, so that is a heck of a lot of work, and I might be able to do that during my work day, but a lot of other people have a day job and that has to be a side project for them and that's a lot of time to do on nights and weekends, or you could just be like some of us who procrastinate and do a lot of it last minute, but you got to at least put the CFP and everything together and have a pretty good outline of what you want to give is your talk, just to submit it. So, once it gets accepted, that's when you're like, when your 40 hour time starts ticking, because then you actually have to put it together, which is, yeah, it's pretty time consuming, and if you're someone who really likes to design your slides, that could easily take a lot more too, because I don't do a lot on that, mostly on the content. But remember Marco slides looking like an Apple keynote and I was like, good God, how much time did that take.
Speaker 1:I'm a slide designer. I'm a slide designer. I agonize over the color palette. I want things to be placed just so like. I need cohesion. I need to get a font.
Speaker 2:You're going to have the Craig Federighi power stance when you're up on stage.
Speaker 1:Yeah, I read like a book or two about like power communication. I've got like my shoulders like opened up broadly and I'm like you know your feet have to be widespread.
Speaker 2:You got to be. Yes, Just study it old Craig Federighi. Yeah no, yeah, definitely.
Speaker 1:See, for me yours are good because they got really good content. I'm more of a performer in my brain. You're not coming to me to learn the ins and outs of rails If you're coming to listen to one of my talk.
Speaker 2:You want to be the entertainer.
Speaker 1:Yeah, I want to entertain you, yeah, yeah. So that's kind of like the sense I took on it.
Speaker 2:Yeah, I know that was one of the things that I remember when I was doing screencasts for the first time and getting feedback on them was always kind of like scary, because it was like you're very monotone and boring as hell and whatever. And I was like I was like shoot. But then I quickly realized like anybody who was commenting on the actual like tone was not somebody learning anything from the content, but everybody who was like learning from the content could care less about the tone and the excitement and whatever. And I was like, well, okay, I think I can just ignore all that feedback and that's fine. And that really helped me get over that, because that's what I think most people are afraid of.
Speaker 2:When you're giving a conference talk or screencast or whatever. It is the public speaking aspect of I'm up here being judged and I'm scared that people don't like me or whatever. And that's almost never, ever the case, especially at these conferences Like we want you to succeed, we want you to practice, we want you to have the chance to do that, do something scary, get better at it. Every time you do it. I hate public speaking but now I'm like feeling better now that I've done several conference talks and whatever People think that. I naturally would love it because I do all these screencasts but I'm alone in my office. I can edit things. No one's here judging me. I just click publish and I don't even have to read the comments.
Speaker 1:So it's gonna be a ghost right for me. Yeah, there you go, Dude. That'll make it real easy. I'll just take your script. Yeah, then just spin it because I enjoyed the speaking part, like the public part of it, like that's the fun part for me the performance.
Speaker 2:So that's funny. Well, just yeah it's different.
Speaker 2:It's definitely different for everybody. I remember just like hating writing and public speaking and that kind of stuff in school. Now it's like I wish I cared back then, because it's not so bad. It was just like one of these things that you tell yourself that you're not good at or whatever, and like you just chose to demoralize yourself about it, basically no reason. And now I look back and I'm like it was pretty dumb. It was not very helpful for myself. I could have been more supportive of myself, but now, you can always do it.
Speaker 1:Yeah, you know God to support yourself. I'm working with a program right now. And then they know who they are and like, whenever they mess up, they are like damn, I'm stupid and I'm like dude stop.
Speaker 2:You gotta stop this.
Speaker 1:You gotta stop, because what does that say about me? Number two if I think you're smarter than me and you're over here calling yourself an idiot, I'm like dude. You got to stop this.
Speaker 2:It's funny, please. I had one of those moments last night where I had been updating the hatchbox to use the new, noticed version and I was like I've been spending like the last three months on the internals of this I know how it all works Been writing the upgrade guide and the docs and everything. I got this. So I like upgrade the hatchbox and deploy it and then it's like, oh, there's a few more errors coming in than normal. That's not good.
Speaker 2:So like I removed this method because, unfortunately, like the gem was so hard to refactor with the old bad decisions that I just like, straight up wrote a new version of the gem and in the upgrade guide I was like this method's been removed, use this instead. Whatever, I didn't follow my upgrade guide to a T like I should have. So I go and deploy this and I'm like that method's gone. You know what, instead of just fixing it, I'm going to go to the gem and put in the little placeholder method that calls the proper one and I'll either add a deprecation warning if I actually plan to remove this or, you know what, it'll just be here for backwards compatibility. These two methods now do exactly the same thing, but I don't care, that's totally fine. And yeah, it was just like, wow, I should have been doing this that way the whole time, but it, you know it didn't.
Speaker 1:As you were telling the story, I was like okay, I wonder if he put in warnings for like oh, we removed this method, Use this one instead. I was funny, like as you're working with this, or I'm like okay, that is.
Speaker 2:And then I learned the hard way I should have done that because didn't catch it in my own code. And yeah, I had one of those moments where I'm the worst frickin programmer. It was just one of those times really like, optimistically it should be good enough to just make the upgrade guide. But realistically you're going to miss things when you're upgrading this and we might as well add those backwards compatibility things in. We can mark them as deprecated and then drop them later on in another version. But right now it's better for us to have this like sort of a cruft on purpose that we're trying to get rid of.
Speaker 2:And I totally find that I was like at this point I've learned my lesson, should have done it. I knew I should have, but I was like I'm trying to simplify my life and if I don't have to have this cruft around, then great, it'll make it easier to maintain and whatever else. And I was like that's it, that's the way I want to do it. But even I couldn't update my own damn gem properly. So that's when you know that you made the wrong decision.
Speaker 1:I was like dang it, but oh well. One of my favorite shows is the boondocks and one of my favorite quotes from the boondocks is like there are known knowns and there are known unknowns, but there are also unknown unknowns. That's when you're saying that's something about. Yeah, like that's one of those unknown unknowns, right there.
Speaker 2:Yep, yep, oh man, that's funny. Yeah, that's a good example. Those are the times where I'm like I knew better. But I just brushed it off because I was so gung ho about this new version so clean and it solves so many of the problems than the original one and I had to change so much to get there. But I'm very, very happy with the end result.
Speaker 2:And then it felt like a massive step backwards to have to go ahead those deprecations and stuff. So I was like surely there's not too many of these and whatever, and got bit in the ass with that one. But it's also one of those things where, like, you're upgrading your Rails application and you've refactored some code, you don't have to do any of that. You can get rid of all the cruft. But if you're building a library, you are on a whole different level of programming. You are now dealing with those unknown unknowns of how people are using your library, because you don't control everything and to be a good internet citizen you got to keep some of those things. You probably have to keep them around for long. So if I do version 2.0, point whatever, and then 2.1 can drop them.
Speaker 1:Cool. I feel like that's the key. Like make it just like code tech debts, make a plan for removing it. Like this is added in 2.0, but in 2.1, this is going to be removed, so change your code. And then, if you don't change your code and you upgrade anyway, well, we gave you a warning.
Speaker 2:Yeah, luckily it was like pretty easy stuff for the most part. There are a few things that were like if you use a symbol to represent a method that we need to call later on, we now given an argument where it didn't take that before. Those are really impossible for us to like. We could check if it's a symbol, we can look up the method by name and then check the arity and then issue a warning and then maybe not pass the thing. But if you don't have that, the old version assigned this little variable in memory and the new versions trying to pass it, so like they're not really interchangeable for some of those things. So that was like a little tougher to catch because you'll see those errors like when it's trying to deliver. But what's also nice is if you did it wrong, as long as the jobs don't get removed from the queue, they will retry automatically and you deploy a new version of it and people will say, okay, I got that argument ready for you now and you accept it and then it's cool. So they're like fixing in production of those issues wasn't bad, but it was stuff like in your notifiers. You could say param and give it a name and that would basically say we require this to be in the params. And I was like in the refactoring I was like, well, if I'm making breaking changes, let's name that required param, because param by itself doesn't intuit enough or doesn't convey enough of why it's there. But if we say required params and you give it a list of names, then dang, is it pretty obvious.
Speaker 2:But I just like not added the params wrapper back and it was like this is basically an alias for the new method. Why the hell wouldn't I put that in there? I can put the deprecation warning, just pass the args straight on to required params and boom, you're done. So kind of stupid for not doing that. And then I realized yesterday yeah, it's worth it. It's four lines of code that I can delete later, not a big deal, pretty easy.
Speaker 2:So I've been making some of those. It feels like steps backwards where it was like it was so clean and so perfect before. But I can't imagine how many deprecation things are built into every Rails release, then managing to make sure that you actually remove what you say you're going to remove in Rails 8 and so on. That's tough. I just had a tiny taste of that, which is good, good learning experience. It's one of those times where you're like this is embarrassing. Now I'm going to publish a release with these sort of fixes or whatever a whole bunch of those deprecations that should have been in there from version 2.0, but whatever, if you're not publicly changing your mind about things, then you're probably not learning as much as you should be, if you're always on the same level or whatever.
Speaker 1:Yeah, but yeah that was fun.
Speaker 2:It was kind of awesome actually to like. Okay, I've experienced the upgrade process myself and now I can feel the pains that everyone using it has, whereas the initial run of refactoring the whole thing was kind of, imagine, a clean slate, which was really important to kind of get around some of the bad architecture things from the first version that couldn't support bulk deliveries very efficiently. So it was good, but it was also like tough.
Speaker 1:Yeah, I've always been very big on that in my Rails app because I use Flipper religiously. So I'm big about if I'm going to remove a method like putting a deprecation warning in it so that it'll show up when we are using it in the testing, especially, and using that as like a way to help continue to remove it and make sure new people don't use it.
Speaker 2:That's a good thing when you're on a team and stuff. We got to keep stuff around, but we want to get rid of this, so don't run any new code that uses this. That kind of stuff is cool. That's something I don't get experience a lot because I'm a tiny team, but I love that idea.
Speaker 1:Yeah, it's definitely not something you think about until it's unknown right Until you experience it? Yeah, I don't know, I feel like you got the exact right takeaway out of it. It's like, okay, well, now in the future, this is going to be something you think about. If you're just removing a method, Well, maybe I should remove that in version 2.1 and have reference it for now and just put a warning in it. That's like I feel like the best solution.
Speaker 2:Yeah, because it's pretty much just we need to change it anyways. So we're really just adding a method, we're not removing anything. We're moving stuff internally around, but we don't have to break the public interface or whatever. So it's a good play, especially for things like that, where you can be like effectively, this is just a alias for the new method, the old method just becomes an alias to the new way of doing things and then it's super clean, which is awesome. It doesn't always work out that way, but when you can, that's great.
Speaker 2:And I know that was one of the things that Collins made a pull request to Rails. When you are using form with, a lot of beginners struggle with accidentally passing a nil because instance variables if you make a typo and it's plural instead of being singular form with, just doesn't care and it's like all right, cool. So he had made a pull request to Rails to make that give you a better descriptive error. So if you pass it nil, it's going to be like hey, this variable you gave us probably should have been something not nil, and can help the beginners understand like, oh, my controller and my instance variable in the view are not named exactly the same. Or my controller queried the database and returned an object and it can be better developer experience and he had made that PR and I think he got accepted or whatever.
Speaker 2:But someone came back and was like well, actually you have changed the default argument here, which is going to be a breaking change for certain use cases. So the thing we actually need to do is, while we want this to be Rails eight or whatever the future, right now, we need to deprecate the current usage of it and then let you know that it will change in the future or whatever. And it's unfortunate that it makes progress feel, as a maintainer, so much slower. But at the end of the day, you have a bunch of applications and code depending on how it currently works today, and especially when people are doing crafty things, they are really depending on how it works today. So those things that you assume people aren't doing, they're probably doing. Especially in a project the size of Rails. It is even more important then.
Speaker 1:Dude all goes back to the ridges in the mouse dude, like there's a reason for it. Someone designed it that way, but someone designed this process for a specific reason.
Speaker 2:Yep. Oh man you brought it back full circle.
Speaker 1:Dude, we did it.
Speaker 2:All right, that's where we stopped today. We have to admit on that, dude, the train has reached the station. Yeah, we reached the same station we were just at, but either we went all the way around the world or we just went in the circle.
Speaker 1:I'm spinning in circles daily, so perfect.
Speaker 2:Done. All right, man, I will catch you next week.
Speaker 1:Yes, sir, have a good week.