You Know What, Lets Just Get Into It & ONCE Campfire

Speaker 2: 0:00

This is remote rule have you any remote ideas to the meaning of the word.

Speaker 3: 0:08

Happy Friday or unhappy Friday, depending on how the week went.

Speaker 4: 0:13

Unhappy Friday, let's continue.

Speaker 3: 0:17

I'm just going to jump right in. Did you see David's video on deploying Campfire?

Speaker 4: 0:24

I did not watch it, but I saw that it existed. Yeah, tell me about it.

Speaker 3: 0:29

I mean it's pretty cool. You create a server, ssh in or use a digital ocean web browser to connect to the terminal and then you run one command which uses your off key for your license and bam installs Docker and everything into Blazor app and you will point your DNS record to the IP address. It does SSL and I'm not entirely sure how it's wired up because they've got file uploads and stuff, so those you won't want in your container. So I assume it sets up volumes and other stuff to back up your files and whatever. But looks pretty cool. He mentioned in his tweet something called thruster. What did it say? I just replied to his tweet.

Speaker 3: 1:13

Yes, if that was going to be open source. He said it's their new configless proxy accelerator for Rails Puma that gives HTTP to compression caching XSEN file. That is curious.

Speaker 4: 1:29

I'm starting to devos people over there, or what.

Speaker 3: 1:31

Yeah, curious what all that is. I mean it looks cool. It requires two gigs of RAM on your server and they're roughly saying 250 concurrent users for that, a thousand for an eight gig server and then 5000 for a 32 gig of RAM and 16 CPU and 10,000 users for 64 gigs of RAM and it's 300 bucks. So if you're using Slack with 10,000 users and want to save a ridiculous amount of money every month, then that's like a stupid no brainer to go buy. I just want to buy it and see the source code and walk through that. I don't know if I'll use it or not. Discord's pretty good and pretty centralized, you know, and I think we'll be like one of those things that like maybe for your work chat that needs to be private and not shared. Then campfire works really great for that. But I don't know about community kind of stuff. I'm curious what happens with all that.

Speaker 4: 2:32

I thought I understood once was all right. Once upon a time, I once thought I once knew what was now you started speaking and then I saw a tweet recently and I was like maybe I don't know what once was. First I thought they were giving you an app, then I thought they were giving you like a deployment thing and then at one point I thought they were literally going to ship you a server rack, like that.

Speaker 4: 2:56

I was like they're making actual server racks and they're just going to give it to you and they're like yes, this is the future, you run your app.

Speaker 3: 3:04

It's pretty much like buying Jumpstart Pro, but they have like a full install script that you just run on your server. I'm not entirely sure if it's using Kamal for deployment, but my understanding was they built an intended Kamal and solid queue for those purposes or whatever. So I guess we'll find out when it comes out. But it's just a Docker image that you can deploy however you want. If you want to throw it up on Heroku as a Docker image, you can. They also have a full setup script to do it on your machine.

Speaker 3: 3:41

They're selling software and he sets up some stuff over, you know running terminal commands and stuff. So I'm curious how many non-tech people will buy it, like Basecamp and hey Customers, they don't need to know anything at all about computers, but this will require some of that a little bit more, Not a ton, but it's like copying and pasting commands into DigitalOcean and servers and SSH and terminals and whatever. It's going to be a little strange for a lot of people. So I hope that a lot of people buy it that aren't developers. That would be awesome. We'll see. If it doesn't come out of CD-ROM I won't buy it.

Speaker 4: 4:23

I need a floppy disk. Floppy disk or get out.

Speaker 3: 4:26

Yeah, it's going to come into box on the shelf at Office Depot or something.

Speaker 4: 4:30

Well, like I said, I thought they were at one point going to ship you an actual box.

Speaker 3: 4:34

So I mean that could be somebody's service they do on top. We'll send you a Raspberry Pi and just have it pre-installed.

Speaker 4: 4:43

Plug this into your closet and this will power your business.

Speaker 3: 4:47

Don't worry, if it pings back home and starts mining crypto, closet will be very warm.

Speaker 4: 4:53

No, no, no. Ignore all calls to Arizona.

Speaker 3: 4:58

I'm like real excited, though, like that price point. I thought they said it was going to be under $1,000 and I was like, okay, so it'll be like $999. But 300 is very reasonable. I would buy a course that was $300 from them. David said he was going to do some videos and walk through the source code, so pretty much seems like for people who want to see how they write code, organize things and design stuff, that would be a great little product to buy just for the learning purposes. So I'm stoked for that.

Speaker 4: 5:33

You left a little bit of a peek at yours. That is really interesting, though, like when David was doing that on writing software well, series, that was Chef's Kiss it was awesome. I was like a brand new Rails program, so it was like this is really interesting. This isn't the way I would have thought about doing this. When hey came out, we were all like trying to read the source maps and said how are they doing this? Like, how are they doing that? So yeah, it would be interesting to dive into that source code.

Speaker 3: 5:57

Yeah, I agree. I remember specifically watching the series that he did and noticing that, like you, spend an awful lot of time on naming and using modules that most of the applications I had worked on didn't take advantage of that like at all.

Speaker 2: 6:15

Yeah.

Speaker 3: 6:16

So I had seen that and been like well, this is a very different style than I have used to and it really got my eyes open and, like recently even we just went through and I mean still have the tendency of like, when I'm building a new feature, like put it directly in the models and then tell myself I'll come back later and refactor it and organize it. But I did recently go back and say, like the user model is going to have a notifiable concern, that's going to have the associations for notifications, and just include that in the user model and then do the same thing for OAuth or whatever else it is. I feel so much organization and the code helps so much. It was kind of tremendous, like how it feels in comparison. But that was stuff that like I learned from watching their videos and stuff. I always thought that was a particularly useful thing. And they also go and go the distance a lot of times on what's the perfect term for this and it will just be like user resource, something very generic or whatever and not truly descriptive. And that was another thing. That is like slow down, think about the English language and how to communicate and use the right terminology. It can make a massive difference on how comprehensible something is.

Speaker 3: 7:42

One of the tiniest changes I made in the new version was the old version. You would say deliver by email, deliver by action cable or SMS or whatever, and then the options for it were kind of like basically modeled it off of associations and rails. You just have comma separated list of options and you're like here's how we format the notification for email or SMS or action cable. It would often be like symbols pointing to a method that it would call, which is a pretty standard thing you do in Rails. But as things get more complex you end up building all these methods that are never called from anywhere directly in your code because it's called from the gem, which when you're reading through the class you're like what the hell is this method?

Speaker 3: 8:32

So the only thing I did was the deliver by method takes the list of options or the parameters, the keyword prams, and now accepts a block. If you do a block, we take those keyword prams and we yield them to the block as an ordered options object. So now you can say deliver by SMS, do config and configformat and organize it all right there in a little block. Man, that was a two-line change of code and then all of a sudden my classes were so well organized because everything was not randomly jumbled lower in the file in random method names, they were all self-contained. They didn't need method names because I could do them as lambdas in line and it would just be anonymous. That was fine because it was in the right context, so you knew where it was going to be. So that stuff, I feel like, is top of mind lately and I can't wait to see what they've done with a lot of that organization of code and campfire.

Speaker 4: 9:40

You're just talking about. I'm like, oh, that sounds nice. Then I was thinking about the code I was writing before this call the method names. It named a method foobar today and was like I'll come back to it, but will you? That one surely won't stay, but I want to name things. Well, I feel like there's two modes thinking about the naming in the organization and there's the writing of the code. I just need to write this down, get this algorithm out of my head and I'll just name it, whatever the hell, and then we'll come back to it and refactor it and rename things.

Speaker 3: 10:15

Yeah, I feel like you just need to make time for that or make space for you to stop and think about it and refactor and whatever, because that's one of the things. I was writing an email to the GoRail's newsletter out today about writing noticed and stuff. One of the points I made was Noticed came out like four years ago I guess, looking at the commits, which is kind of crazy and I solved a lot of the problems I intentionally went for in version one. There were definitely things that didn't make sense, like database delivery of a notification was optional. When we deliver the notification we check to see if it's delivering by the database and then pull that out and run it inline before everything else, and it was a weird exception. And looking at those things after some time to think on them helps you like solidify how you want to make it work. I don't really care if there's notifications that could skip writing to the database. They're just going to be an empty record. We'll just make that a requirement in version two. And then all of that was simplified into this elegant thing by that simple decision. And then there was bulk deliveries and other things people had asked for that I was like I don't know how best to solve this in its current state.

Speaker 3: 11:44

The five or 10 different times I tried refactoring it just left me in this weird mess because I was like too influenced by the existing solution. I didn't have the space to think about what if I did this from scratch? And what if I did it right? What would that look like? So I like rewrote the gem from scratch in this version two, which made it harder to migrate, but it gave me the freedom to be like I know all the problems, I know what we want to achieve in version two, but I don't want to be influenced by any of the crap in version one. So, like, giving myself that space just to think clearly helped quite a lot. That was another thing of refactoring code. You have to like separate yourself from what exists currently so you can look at it with fresh eyes and be like what do we really want this to be like?

Speaker 4: 12:37

I call that slash and burn coding. I do that too much.

Speaker 2: 12:42

That's all you do.

Speaker 4: 12:44

It, honestly, is all I do. I love starting fresh. Take the same problem, remove everything and then start fresh, knowing what you know now, but I like to do that so many times that I never actually solved the problem. But yeah, I love doing that style of program. It was like OK, I take everything I've learned, all the resources I have now no existing code, start fresh. Yeah what does my brain do?

Speaker 3: 13:08

Yeah, and that was pretty much what we did, but keeping in mind we have these existing database records and we'll need to like preserve them, I still split it out into two tables and stuff. I knew we'd have a migration between the two, but that's OK. So that is one of the most fulfilling things. When I like taught myself to code back in like grade school I wrote the same programs like 14, 15 times. Every time I knew that I understood the problem better. I'd go back and refactor it and it would be so like a joyful moment to look at it and be like it's half the lines of code and it does more features.

Speaker 3: 13:50

It's so awesome.

Speaker 4: 13:53

Yeah, I love refactoring especially for components, because they're kind of like an easy, like no consequence place to do it. Let me go back and make the best base component possible, like that covers every possible thing, and then just kind of going back and revisiting like what is the best API for these types of objects?

Speaker 3: 14:13

I love that style of programming, yeah for some reason, the word API triggered me. Yesterday I was looking at Battle Buildings API again. I don't know why. Their documentation says like you can provide an ID or null for filtering the list of results for something. When I tried it I was like, ok, so I can submit an ID and it filters it. That works and I'll just submit nil and Faraday will convert that to an empty value and put that in the URL params and they'll see that it's null. And it didn't work and it was like invalid request and I was like, oh, you got to be shitting me.

Speaker 3: 14:58

So, I tried again with the string of null as the value and it worked and I was like, oh my god.

Speaker 4: 15:09

That's when I literally start banging the desk like just pounding it and like screaming, like why yeah?

Speaker 3: 15:16

Why are you like this? Yeah, I was like. You know that it's a null value. Because there is no value, it's a URL param. That's how they work.

Speaker 4: 15:26

Very cool.

Speaker 3: 15:27

Mind you, this is the same developers that version one of their API had status or state in one of the, in either in the API request and then web hooks would give you the same column but it would be the opposite name, like state in one and status in the other, to represent the same thing, and they couldn't be bothered to do an update of their API that just sends both status and both state.

Speaker 3: 15:57

You made a mistake. You can fix it. You can just provide both values so it's consistent whichever one you want to use. But they didn't do that. And then they released a whole new version of their API that is not backwards, compatible with the previous one and stuff. And I'm like just take some time, write it all out at a time so you know exactly what you're building and you can also roll out fixes, like Stripes even talked about some really awesome way that they do gating of things where it's like well, it used to be status, now it's state or vice versa, and we accept both inputs. But if we see the old one, we'll rename it in your request internally and take care of it, and it's like it's freaking awesome.

Speaker 3: 16:45

Fantastic, yeah, and it's like they could learn from all these other people who have written about these problems before, but they apparently haven't. And it just is one of those things where, as a user, I'm like I'm a little concerned about the internals of their product if the externals are not very well-written.

Speaker 4: 17:06

I wish we did Time Machine A long time ago, when Paddle first became a thing, because it wasn't in pay to begin with. Right, you added it in later.

Speaker 3: 17:15

Yeah, it was Stripe and Braintree, because I was trying to add PayPal support to Go Rails. We used Braintree and I was just trying to make a standard interface over both of them.

Speaker 4: 17:28

I can literally take myself back all the way, Like I was still in North Carolina and I remember Chris Oliver saying Paddle is going to be great. It's this new API. It's going to be the thing. It's going to resolve all the Braintree issues. It's just going to be the unifying API. I'm so excited for it. I feel like that's what my brain is telling me that there is like a memory somewhere in my head of that which one?

Speaker 3: 17:53

Paddle is going to be great. It's this new API. It's going to be the thing. It's going to resolve all the Braintree issues. It's just going to be the unifying API. I'm so excited for it.

Speaker 4: 18:04

Preach it, chris. Sweet, that must be my hootie seafood from that awesome new ghost kitchen.

Speaker 3: 18:13

Which, like it sort of did, but there was a it's a whole layer of problems in there. That was like, oh my goodness.

Speaker 4: 18:22

There truly is no one good solution to payments.

Speaker 3: 18:26

Yeah, that's paper checks. That's what it is Paper checks.

Speaker 4: 18:30

Yeah, you've got to balance the checkbook. Sorry, mom and Dad are going to be on the kitchen table all night.

Speaker 3: 18:36

Yeah, and it's going to be like the old days, which you may not remember, but when you would buy DOS video games you could get the demo version and they'd be like mail us a check and we'll send you floppy disks.

Speaker 4: 18:48

So I don't know what the hell that is, but that sounds interesting.

Speaker 3: 18:52

I plan to send you floppy disks for your GoRail's subscriptions and stuff. Today's screencast is on these 35 floppies.

Speaker 4: 19:01

If I can walk to my mailbox, open it up and receive a VHS tape of a GoRail's episode. Walk back to my house, slap it in a VHS player that I get a good will. I would be a happy dude. I would be it. It would be a good day. Oh man, that would be awesome.

Speaker 3: 19:16

I'll have to get some of that VCR playback effects on the video or something.

Speaker 4: 19:22

That'd be sweet. Why don't you just go backwards in time and go to where Netflix was in, like the early 2000s? Just start sending people DVDs of GoRail's.

Speaker 3: 19:32

Screw these streaming DVDs and a DVD Rewinder is an upgrade. Yeah, yeah, yeah.

Speaker 4: 19:39

Maybe you get Blu-ray for $5 extra.

Speaker 3: 19:42

Blu-ray Rewinder.

Speaker 4: 19:44

Yeah yeah.

Speaker 3: 19:45

I'm talking.

Speaker 4: 19:47

Damn.

Speaker 1: 19:49

Let me ask you one quick question. Are you currently using one service for uptime monitoring, another service for air tracking, another service for status pages and yet another service to monitor cron jobs and microservices? Paying for all of those separately may be costing you a lot of money. If you want to simplify your stack and lower those bills, it's time to check out HoneyBadger. Honeybadger combines all of those services into one easy to use platform. It's everything you need to keep production healthy and your customers happy. Best of all, honeybadger is free for small teams and setup takes as little as five minutes. Get started today at HoneyBadgerio. That's wwwHoneyBadgerio.

Speaker 3: 20:37

I was watching a review of this device called the RetroTink 4K, which is like you plug in your Super Nintendo or your Nintendo or whatever into like a modern OLED TV, reintroduce scan lines and all the other like artifacts and stuff from old CRTs. I was like we're definitely at that point in time where those people who grew up on that are now old enough to afford. The thing is like $750 to play your old games on a modern TV, but with that retro sort of perfect look to it. And I was like it's only people our age who have the money to appreciate that, because that is a stupid amount of money for input.

Speaker 4: 21:24

an old game. I went home and I remember the Wii being like this pinnacle of technology. There's a great South Park episode about it too. But I went home and my little brother busted out a Wii Sports on me and I'm like yo, this is pixelated dude. I thought this was 4K HD, but it was crazy.

Speaker 1: 21:50

How much?

Speaker 4: 21:50

does old games go for now? Getting Smash Bros, now it is.

Speaker 3: 21:55

Pokemon like for the Game Boy. Yellow, red and blue were like $50 each now, which is nuts.

Speaker 4: 22:03

So yeah, there's been an upsell.

Speaker 3: 22:06

It's crazy. You have an old DMG Game Boy that's got a modern backlight on it and a white and black Stormtrooper theme for the buttons and stuff and it's awesome, Like if you ever do want to play those like, oh my God, a Game Boy color. I thought that was the coolest thing back in the day. And then you look at the screen today and you're like how the hell did anybody see anything on this? Yeah, Like they are terrible. Right now you get one of those little modern IPS display is for them for like very cheap and then swap it out and I mean it's incredible how good they are.

Speaker 3: 22:43

So it is cool to see some of that like coming back. And a lot of those devices are like the battery contacts of Corota and other stuff over time because they just sat in a box for 30 years or whatever. So it's nice to see a lot of that stuff is able to be revived and whatever or analog makes like FPGA replicas of the chips and stuff. On there you can get basically a modern but like as close as possible to the original hardware functionality wise and HDMI outputs on your Nintendo or whatever. It's freaking sweet. Yeah, it's been a couple of days. It's always crazy to see to. The new Raspberry Pi's are quite a bit faster than the four B's and whatever else I forget. I don't know. I think everybody always bought the B model or whatever.

Speaker 3: 23:38

I don't know if there was even an A now that I'm thinking about it, but those can play like PlayStation games and whatever else, like emulate them pretty well. And there was a quote that I saw earlier today that was in the seventies there was the cray one super computer. Yeah, 1978 cray one super computer cost $7 million, weighed 10,500 pounds and had 115 kilowatt power supply. It was by far the fastest computer in the world Then. Today the Raspberry Pi costs about $70 for CPU case, power supply and SD card. It's a few ounces, has a five watt power supply and it's four and a half times faster than the cray one.

Speaker 4: 24:27

It is wild Like how far it's insane. Yeah, I mean, what is the point now where we're just trying to get past like space issues right, like we can't even pack enough in there anymore. There's none of space.

Speaker 3: 24:40

It's crazy and it's funny to like. The evolution of it is our computers are lightning fast compared to where they were, but that's what enables us to do like Ruby as fast as we do. This is interpreted. It's not compiled, it's not optimized like the compilers for C and whatever else. Computers are doing a whole lot more work but they're still super fast at running Ruby and whatever else. It's awesome because our ability to like, ship productive software is insane compared to somebody who is fiddling with hexadecimal and memory and allocating memory and all that stuff and writing assembly and low level C and whatever. Like 37 signals can go and build a product like campfire on the side as a side project while they're building a calendar and hay and base camp and they're like yeah, we just kind of like, did this is a fun thing to see what happens and whatever. And they can be that productive, build it whole chat system that kind of replaces your other ones for work and stuff and 300 bucks and it runs on a $10 month server. Crazy.

Speaker 4: 25:59

It is wild what we can do with Rails sometimes, but then other times I'm like Rails is, I can't do anything with this piece of shit.

Speaker 3: 26:08

You don't do anything, I'm slapping it. It is interesting to work day to day and for some problems you're like this is incredible. I can make an API request in 30 seconds and it used to be a real pain to set up a Request, parse JSON, yada, yada, yada. That stuff was not easy, but now it's super-duper fast. There are also now these other abstractions that we're trying to get to that are like why is it so hard to do notifications? That was when I was like all right, screw it, I'm going to take on that and try and build a notification system. Or payments. I'm still working on trying to make that easier, where last night and this morning I've been prototyping if you use paddle checkout and stripe checkout and whatever else checkout we ever support lemon squeezy having sort of like a. You set up the request, you send them into checkout and then one endpoint you can return them to in pay. That will be like all right, I see the pram for lemon squeezy or for paddle billing or for stripe. Then we will just route and sync whatever it is. Just give me the ID, I'll go look it up and find if the payment for a subscription or a t-shirt, and then we'll save it in your database and then return the user back to wherever you want. We're trying to set it up now. It's like the fulfillment of whatever you purchased and, like this syncing stuff is not there's kind of abstracted away. It's just like send them to checkout when they come back, send them to us, we'll take care of it. Right now it's kind of like you send them to paddle Okay, well then when they come back, set up a controller and then you sync it yourself using this method in pay and it's like it's fine. But our users don't want to know anything about how that syncing process works. If they did, they'd go read the paddle docs and spend the weeks or months integrating properly in those payment processors.

Speaker 3: 28:20

I've been on that kick lately to like how do we conceptually compress that piece of things? So it's much easier for that, because the initial stuff was always like let's start the payment and get that working really easily, which is good, and then usually it was kind of like leave it up to web hooks. But in order for you to deal with web hooks that are delayed, or if you're in local host, you don't have web hooks running. If we redirect you to somewhere that manually hits the API and syncs it just like the web hook would do. Then you save the trouble from that, and so that's where we've been headed trying to like make that as easy as some of these other things. I feel like that's a lot of.

Speaker 3: 29:05

What's happening too is like the screencast series I was doing this week was let's build a little web scraper, like I've been trying to get a Raspberry Pi five. So let's build the one that will hit the website a few times a day, see if it's in stock and then email us when it changes. So I built a little thing use solid queue, a cron job, to run every six hours or four hours or whatever you want. And then it was about it and it's pretty simple to build that. And what's even cooler is like the Puma management of solid queue. You don't have to run a separate process for that, it just runs whenever Puma boots up. It's freaking awesome.

Speaker 3: 29:50

But of course I like record all these videos this week and then this morning I hop on to record, like the conclusion, and I walk through the app and I'm like there's errors in Puma, saying solid queue won't start because the constant's undefined, and I was like what? So I start looking and there's a new release of solid queue that I hadn't seen before. And then I was like, oh, january 19th, that's today, so three weeks ago that bug was fixed in Maine and then it got released today and I was like, well, what timing was perfect to show off like this issue and then how to walk through like solving a bug like that, like looking up the error and where to look for that stuff and whatever. But man, that was one that was like the plug into Puma was that conceptual compression that I loved and it's like this is just easy and convenient.

Speaker 4: 30:54

Yeah, running those extra processes is always. It's a pit of confusion for people.

Speaker 3: 30:59

Seriously, it's not as bad as like the Webpack days, but with CSS bundling and JS bundling, and then you have to run a proc file, which you have to run form in, but form in doesn't allow you to use binding IRB or pry or whatever, or find gang, yeah, so you form wrote over my game.

Speaker 3: 31:19

But then you've got to learn the hard way that it doesn't support that. So binding IRB just breaks. And then you start googling it and then you're like so I got to learn what the hell this overmind thing is and switch from form into that.

Speaker 4: 31:30

And overmind bro.

Speaker 3: 31:32

But it's like that kind of stuff.

Speaker 4: 31:34

That's got to learn T-Mux, no sweat.

Speaker 3: 31:38

Yeah.

Speaker 4: 31:39

It's a little.

Speaker 3: 31:39

T-Mux.

Speaker 4: 31:40

Then you got to learn the Linux kernel and how to compile it, and and the Unix shell and the born shell. What's a shell? What is a shell Is? It a shell, the thing that runs the process, or you know, is the shell the thing? What is the shell programming language? I don't know.

Speaker 3: 31:55

And then you're at the age of retirement and you still haven't figured it out. And it's just time to relax.

Speaker 4: 32:02

Yeah, You're all the way at the end of like what is one and a zero?

Speaker 3: 32:05

Yeah. Yeah. It's weird because there's all these times of like where we have to introduce complexity, but then we have to have those times, too, to pull the complexity back. And we're in one of those phases in Rails, I think, where it's pulling the complexity back but we still have the asset pipeline. Prop shaft is going to become the default in Rails 8.

Speaker 3: 32:31

That's going to like mess with so many things and it's just going to be another one of those moments where, like, we're still not done pulling back the complexity, but we're in the headed in the right direction, which is good, and seeing stuff like solid queue, solid cache, using caching in your database, like there's some great things going on because of that that we can see and benefit from. But it just felt like there was the last like five years or more, where it was just like added complexity. I've been on a kick since like October of like let's get rid of everything we possibly can that we don't need. And if somebody says like, hey, I'd like to add this feature, cool, but who's going to maintain it and is it really worth the effort of maintaining this? And could it just be a plugin or something they maintain in their code instead of you maintaining in the library or whatever.

Speaker 4: 33:30

You're ascending right now into your next state, next evolution.

Speaker 3: 33:34

Yeah, it has been one of those like last few months of transcendence. Pretty much it feels like that just things are way simpler, way more manageable. Less stuff to worry about, less stuff can break and then you can spend more time on what you actually want to do, which is like build a product and features and to help people, which is why we write software in the first place. Helping people accomplish things. That is to me the fulfilling bit, not the constant maintenance, burden and crap. But you sometimes run into weird things, a specific weird thing have you ever done anything fancy in your gem file?

Speaker 4: 34:15

How fancy are we talking here? Because I've been known to do some things. I like living on the edge.

Speaker 3: 34:25

Yeah, well, I did too, until I fixed it sort of. So here's what I did. I originally had jumpstart. When you would have a jumpstart, when you would configure it, it would generate a gem file for you and you would have your main gem file that would eval the other gem file. And I was like this is sweet.

Speaker 3: 34:44

Problem with that is like every time you resave the configuration, we got to update that gem file. And if you modified that, what do we do? Do we blow it away? Probably have to. Or we have to get real in the weeds of like is this in there, is it in the group and whatever else. We'd have to actually pretty much parse the whole damn thing and understand it. So yeah.

Speaker 3: 35:10

So what I said was like we'll just override it, whatever. You can look at the diff and you'll see the changes and you can change it back to whatever you needed if it got over it. That was my solution for a long time. Then I realized, instead of just writing this, why don't we just put it's a Ruby script, so why don't we just like put if statements in there instead? So that's what I did was like we'll just have all of the options in the file and then it's like just include this gem if enabled, include stripe, if you enable stripe. And then we're not overriding anything and we just read the YAML file. And that's where the rebel hole began, because it was like, well, I'm going to require YAML to read the YAML file, but I'm inside the gem file which is defining which gem to load, and, as it turns out, requiring a gem while you're inside the gem file, defining the gems that are available does not work very well. Yeah, you really want that all to run separately before you do requires. So what happens is, if you do that, you'll require psych, which you generally don't care and want the latest version of, but you'll end up where psych is the version that ships with Ruby. Your gem file might be like let's use the patched version that comes or that just got released, and then you get a conflict because those two versions don't match.

Speaker 3: 36:45

So indirect, I think was the person that mentioned that on Jumpstart and was like yeah, this is why in Bundler there's actually like a custom YAML parser that can load YAML without any requirements, like any dependencies, interesting. So that didn't have. I forget there was something like there was. It's a pretty simple YAML parser. There was something that I couldn't use in there, so I basically use that as inspiration to write our own. We just load our own YAML file now and then that runs in the gem file, which is great. It's been running wonderfully for almost a year now no issues, other than a couple of days ago.

Speaker 3: 37:32

Someone was like what happened to Dependabot? And I was like you know what? That's a really good point. And turns out Dependabot does the same sort of thing where it will analyze the gem file but it will only go one layer deep on evals and require relatives. So we were doing an eval gem file and then requiring the configuration from Jumpstart and then that was requiring relative, a couple other files and Dependabot would run it and it would be like the heck are you doing? It's too deep, yeah.

Speaker 3: 38:12

So this morning I'm looking at it and I'm like all right, let's just do, instead of the requires at the top of our Ruby file, the configurationrb file, let's just put those in the gem file and require them there, because that should appease Dependabot and, sure enough, push that up to GitHub. If you didn't know, you can go into insights and Dependabot and actually look at the previous logs of it running. So that's where we found, confirmed, it doesn't know what the hell to do in these nested files because it can only do the one layer. And someone found a comment of one of the Dependabot maintainers that was like, yeah, one layer only for that. So then, sure enough, fixed it. And then I was like let's put the require relative in our eval gem file and see what happens there. That doesn't work. So you got to be putting it in the main gem file or whatever Tiny, a little bit of refactoring.

Speaker 3: 39:15

Later it was like let's just merge this stuff into one file and then do our requires in the main and we're good. And now Dependabot works again. But it's stuff like that where you're like you know you get in the weeds so freaking fast you could spend your entire life in there. But I want to step back and like keep it simple so I'm not going down the rabbit hole of how the hell does Dependabot work internally so I can make it work on my code. It's valid rails and Ruby bundlers understands it properly. But your hacked version of bundler to do Dependabot stuff doesn't work, so I've got to piece it as well. Like. Those are the weird things that you end up spending way too much time on and they provide absolutely zero value. You know like you shouldn't be having to fiddle with these kinds of things because it's correct, like it works with bundler just fine, but not in this one weird context or whatever drives me nuts, man.

Speaker 4: 40:22

Hey, you paid the fancy price, though right, you did. If you did something fancy, you got clever and then you paid for it.

Speaker 3: 40:31

Yeah, and that was like overriding the file was a trade-off between this fanciness that was more automatic with less get conflicts when you updated, and that was like, oh beautiful, there's my answer. I'm going to go switch to that. But, like, the rudimentary version that I shipped with originally was actually the like more reliable version because it wasn't going to be anything fancy at all, because it just was this file, read that file, boom.

Speaker 4: 41:10

I'm like, damn, this is so freaking nice. I come back and I'm like, why, why did I let myself do this? Now, what's going to cost me?

Speaker 3: 41:20

It's wild how many moments like that that you will have. It's all the time too. It's not. It's like your regular code, your regular features. Definitely happens a ton when you're using libraries and you're trying to do something with third-party code. That's where it gets real gnarly. A lot of times I've noticed Pun intended noticed it's too bad.

Speaker 4: 41:45

the web has to talk to each other.

Speaker 3: 41:48

I know, If computers were just like no networks, no databases it would be so much easier.

Speaker 4: 41:57

It would be, wouldn't it? Because then I wouldn't be trying to like find the Apple Health SQLite file to parse and write queries. I wouldn't be doing things like that if this wasn't a thing.

Speaker 3: 42:07

Yeah, if there was no database, you'd be fine.

Speaker 4: 42:10

Yeah, what happened to the single table, single column inheritance feature that we floated last year? Bring that back, yeah.

Speaker 3: 42:18

We need a create table called data and then we have a one JSON column on it, also called data.

Speaker 2: 42:26

Exactly, and then?

Speaker 3: 42:27

we just put everything in there.

Speaker 4: 42:29

Yeah, and name all the keys data yeah.

Speaker 3: 42:34

Or oh, I know what we could call it. You say in your MySQL or Postgres database, create table MongoDB. All right.

Speaker 4: 42:44

Now you just call him database data.

Speaker 3: 42:47

Now you're just taking the piss, dude that's crazy.

Speaker 4: 42:53

Imagine you're a brand new developer. Right First day of the job you come into the shop. You've learned all this stuff about relational databases. You're excited. You sit down and the lead architect comes over and they're like, yeah, well, here's the database schema Slides you over Single sheet of paper.

Speaker 2: 43:12

It just says cable name MongoDB.

Speaker 3: 43:16

And he's running in Postgres.

Speaker 2: 43:19

If you don't get up and walk out the room, then oh Lord.

Speaker 3: 43:24

So here's the plan you create a new repository in Podia called actual Podia. And then any new hires, you invite them only to that repo. It's just like single code.

Speaker 2: 43:42

Single migration Create table MongoDB. That's the sample app. We need to pass out the new hires.

Speaker 3: 43:53

Yeah, just like for the first hour on the job, you only give them access to that repo and just I'll be right here if you need anything. Yeah.

Speaker 2: 44:03

Do you?

Speaker 3: 44:03

have any questions.

Speaker 2: 44:05

Just like running actual Podia in an iFrame like encoded in base 64 somewhere, like no, that whole app works, we can talk about it. I can see it right there. There's only one table called MongoDB.

Speaker 3: 44:22

Yeah, and if you look in there there's a user yeah, and you got courses, we got comments, everything's there.

Speaker 4: 44:32

Oh my God, bro, I need to do. I'm going to go float this idea to Jamie and get myself a raise, Not actual Podia.

Speaker 3: 44:41

I feel bad for whoever the next new hire is.

Speaker 4: 44:44

Dude. I mean they're going to have a really easy time learning the new app yeah.

Speaker 2: 44:49

Everything is real thing, it's easy.

Speaker 3: 44:52

What's really great is we can just use one database model for all this. Just say create, shove the user JSON in here, the course JSON, it's perfect.

Speaker 4: 45:04

It's basically GraphQL inside and MongoDB mind into one. You get it. We're kind of ahead of our time.

Speaker 3: 45:11

Yeah, Well, then you can cache it right, just take the data straight out of react on the front end, send it to the API, which is just one post request endpoint. That's it.

Speaker 2: 45:25

It just always returns, no authentication, no matter what.

Speaker 3: 45:28

Yeah, okay, but it has a JSON field with the hierarchy in it.

Speaker 2: 45:33

Of course, yeah, of course.

Speaker 4: 45:37

Yeah, but with the status of okay, the state of error.

Speaker 3: 45:41

Yeah. Yeah, I mean it was okay. It got the error back to you successful.

Speaker 4: 45:46

Yeah, I mean obviously right.

Speaker 3: 45:47

Dude why aren't?

Speaker 4: 45:48

we teaching workshops. We need to bring this theory to the people.

Speaker 3: 45:51

Yeah, maybe that's an April 1st. We just replace all the videos or go rails with the same nonsense.

Speaker 4: 46:02

Yeah, that would be fun. It would be a pain to actually make it happen, but it would be hilarious.

Speaker 3: 46:08

The best trolls are always that way.

Speaker 4: 46:10

Yes, they changed characters names in South Park. They're like, yeah, his name was always this and they committed to the troll so hard that they're like only this one character doesn't know his name and they went back and changed all the subtitles. All the subtitles and all the episodes past that have happened like since 96, they changed all the subtitles, so only this one character says his name a certain way and everyone else used to like dude, you got to. I love the commitment.

Speaker 4: 46:38

Wow, I'm about to do that Midwestern like me, slap, slap top of car yeah.

Speaker 3: 46:45

This podcast going to hit so many memes.

Speaker 4: 46:48

Dude. We could shove so many more memes in this Dude. Imagine if we got like a meme soundboard.

Speaker 3: 46:55

We just need the roadcaster or pro or whatever we had at rail.

Speaker 4: 46:59

Yeah, dude, those are expensive. Yeah, they are. Do so many influencers on YouTube have these. These things are not cheap.

Speaker 3: 47:08

Maybe they're sponsored.

Speaker 4: 47:10

Freaking nerds.

Speaker 3: 47:12

I would happily do the sponsorship for that stuff.

Speaker 2: 47:16

Oh heck yeah.

Speaker 4: 47:17

We could go for a soundboard. Yeah, dude, just about Jason would love it. We wouldn't be able to focus on what we were talking about, just be hitting button. Can we even focus anyways?

Speaker 3: 47:28

We record now the worst time of the week, where we're like it's Friday, it's the afternoon. We've already worked on Friday morning anyways, so it's just like so tough to be on the ball.

Speaker 4: 47:43

I was staring, I was trying to listen so hard and I think I'm so burnt that you're talking about code. I'm like what is the code?

Speaker 3: 47:54

I'm venting about. Code is what I'm doing. Yeah, like what even? Is a web hook Enough for this week? We can burn ourselves out next Friday.

Speaker 4: 48:05

Oh yeah, same time, same great place, same great people. All right, we'll see you next week Later. Peace out.